asp.net - 在必须显示25万条折线的Google Map应用程序上需要指导

Question

我正在为我正在开发的使用Google Map的应用程序寻求建议。

摘要：
用户具有用于搜索满足条件的街道段的条件的列表。街道路段将用3种颜色着色，以显示低于平均水平，平均水平和高于平均水平的部分。然后，用户单击街道路段以查看一个信息窗口，该信息窗口显示该特定路段的属性，直到他/她关闭该窗口并隐藏其他折线后，这些属性才会被隐藏。这看上去就像一个月前的“垄断城市街道”游戏孩之宝（Hasbro）的区别在于我不使用Flash，我不能使用“开放街道地图”，因为它没有列出街道路段（如果是ID，则不会还是一样），而我不必再展示Google草图。

信息：
我有一个具有ID，折线点和质心的路段数据库。
该数据库中有6,000,000个街道段记录。为了稍微缩小生成的数据，我们将重点放在城市上。我们必须显示的最大城市有250,000个街道段。这意味着要显示250,000条线段折线。

我们最长的折线使用9600个字符，这些字符存储在SQL Server 2008中的两个8000 varchar列中。

我们需要使用API​​ v3，因为它比API v2更快，并且该应用程序将移植到iPhone。目前，它是带有SQl Server 2008应用程序的ASP.NET 3.5。
性能是重中之重。

问题：
大多数演示项目都是使用API​​ v2进行的。因此，除了Google API v3参考页上的教程之外，我没有其他东西可以比较实现目标的性能或技术用途。
目前尚无适用于API v3的.NET包装器。

生成250,000条线段折线会创建一个繁重的文件，这需要花费一些时间来传输和解析。 （我发现一条390,000点的折线的demo。我认为编码器的效率会大大降低，而折线越少，折线越多，因为舍入会更少。）
由于街道段是根据条件显示的，因此必须动态创建折线，并且不能使用缓存。

一些想法：

KML / KMZ：

优点：
由于这是一个标准，因此我们可以轻松加载Bing地图，Yahoo!。地图，Google地图，Google Earth和相同的KML文件。数据生成将是相同的。

缺点：
KML中的LineString不能像Google Map API可以处理的那样编码为折线。因此，它可能会更大或更慢地显示。将文件压缩成这样的大小将需要更多的处理时间，并且需要客户端解压缩数据，而对于250,000个数据，我不太确定iPhone将如何处理以及服务器将如何处理40个同时浏览的用户。

JavaScript文件：

优点：
JavaScript文件可以具有encoded polyline，并且将大大减少要传输的文件。

缺点：
必须创建我自己的剥离的API v3版本以添加覆盖，创建折线等。这比仅创建KML文件并指向源代码要复杂得多。

GeoRSS：
我认为此选项不适合我的需求，但我可能会错。

MapServer：
我看到一些建议使用MapServer生成叠加层的帖子。不确定与数据库的连接及其性能。另外，它还需要用于生成KML的插件。在我看来，这比创建自己的KML或JavaScript文件做得更好。没有它，维护会更简单。

垄断城市街道：
游戏现已结束，但是对于那些知道我在说什么“垄断城市街道”的人，它们以最大缩放级别显示的只是质心位于窗口边界内的街道。移动地图是向服务器发送请求以显示新街道。虽然我认为这很巧妙，但是我不知道如何实现类似的功能。我唯一想到的是比较长线是否在地图区域X的边界内并且与Y相同。虽然这可以在高缩放级别上显着提高性能，但是在显示整个城市时什么也没有。

聚类：
虽然聚类对于标记来说很棒，但看来我们无法聚成折线。我本来希望对折线使用MarkerClusterer之类的东西，并且能够通过3种折线颜色进行聚类。这可能会保留下来，因为“本来会吓死人，但算了吧”。

箭头：
在将来的版本中，我将显示折线的方向，并且必须在质心处显示箭头。加载图像或标记只会使我的数据加倍，因此创建自定义叠加层可能是我唯一的选择。我发现demo可以达到类似的效果。不幸的是，演示非常慢，但是我只希望每条折线显示1个箭头，而不是演示中的多个箭头。由于我认为KML不支持自定义叠加层，因此此功能将取决于数据格式。

条件：
当应用程序使用ASP.NET 3.5完成时，iPhone的端口将不会使用Web来显示应用程序，并且在选择标准时屏幕尺寸受到限制。这就是为什么我更着重于基于根据参数传递的标准生成文件的服务或页面的原因。该服务将生成我需要在地图上显示折线的文件。我也可以创建一个执行此操作的aspx页面。 aspx页面比服务方式更具文档化。应该是有原因的。

问题：


我应该创建一个Web服务来返回街道路段文件还是创建一个返回该文件的aspx页面？
我应该基于最大经度/纬度折线包含9600个字符的事实创建带有编码折线的JavaScript文件，还是创建具有经度/纬度的KML的JavaScript文件，并且必须渲染最多250,000个线段折线。还是应该使用生成叠加层的MapServer？
我可以在下一个版本的折线上显示简单箭头吗？
在生成KML的情况下，使用XDocument，XmlDocument，XmlWriter手动创建文件或仅序列化流中的街道段是否更快？


与实际的代码问题相比，这更是集思广益的堆栈溢出问题。任何有助于缩小可能性的答案都和拥有所有知识的人指出我的更好选择一样好。

Answer 1

大量的短GPolyline的运行速度大大慢于少量的长GPolyline。

Google Maps v2和Google Maps v3之间的速度差异不会太大，因为大多数CPU时间将由浏览器的实际图形系统占用。 Google Maps使用VML，SVG或Canvas图形系统，具体取决于浏览器。其中，VML迄今为止是最慢的，并且只要浏览器是MSIE就会被使用。

在着手处理250,000条线段之前，建议您先看一下quick speed test of 200 random polylines。尝试在MSIE中缩放和平移该地图。

然后，还要考虑需要从服务器发送到客户端以指定250,000行段的数据量。数据量会有所不同，具体取决于您选择的是KML还是JSON或GeoRSS，但是如果最终每行段有20个字节，那么在提取1兆宽的宽带连接时将花费50秒。考虑您的用户是否准备好坐50秒钟。

真正有意义的唯一解决方案是执行Google对其流量叠加的操作，将线绘制到服务器中的图块上，并使这些图块在客户端中显示为GTileLayerOverlay。

您需要的是一个具有空间意识的数据库，以及一个服务器端图形库，例如gd或ImageMagik。客户端要求从服务器获得图块。如果缩放比例在某个级别以上，则服务器会在数据库中扫描具有边界框的线段，这些边界框与请求的图块的边界框重叠，并使用图形库进行绘制。

缩放级别限制可以限制数据库和服务器需要完成的工作量。您不希望最终在单个缩小的图块上绘制250,000个线段，因为这对服务器来说是非常艰巨的工作，并且对用户而言意义不大。

关于点击处理：

要做的一件简单的事就是侦听地图（而不是对象）上的点击，并将点击详细信息发送到服务器。然后，服务器使用单击位置搜索空间感知的数据库，如果存在，则返回单击对象的详细信息。客户端代码执行以下操作：

  GEvent.addListener(map,"click",function(overlay,point) {
    var url="clickserver.php?lat=" + point.lat() + "&lng=" +point.lng();
    GDownloadUrl(url, function(html) {
      if (html.length) {
        map.openInfoWindow(html)
      }
    });
  });

较难的事情是在指针位于折线上方时处理光标的更改。有一种用于更改小标记的光标的已知技术，其工作原理如下：

每当获取磁贴时，.getTileUrl（）也会调用服务器，该服务器返回该磁贴的热点框列表。当鼠标移动时，客户端会不断计算鼠标悬停在哪个图块上，然后扫描相应的热点框列表。

Google本身在其GLayer（）代码中添加了执行四叉树搜索的复杂性，以加快对图块内热点的搜索，但是其他在自己的代码中实现了该策略的人则认为这是不必要的，并且可以进行线性扫描热点列表的速度足够快。

我不知道如何将其扩展到在折线检测上处理光标。