需要有关必须显示 250 000 条折线的 Google 地图应用程序的指导

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

Summary:用户具有用于搜索满足条件的街道段的条件列表。街道段将用 3 种颜色来表示，分别是低于平均水平、平均水平和高于平均水平。然后，用户单击街道路段，查看一个信息窗口，显示该特定路段的属性，隐藏那些未选择的路段，直到他/她关闭窗口并且其他折线再次可见。这看起来很像孩之宝几个月前制作的大富翁城市街道游戏，区别在于我不使用 Flash，我不能使用开放街道地图，因为它没有列出街道段（如果列出了，ID 将不会是无论如何都是一样的）而且我不必展示谷歌草图的构建。

信息：我有一个包含 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 条线段折线会创建一个繁重的文件，需要时间来传输和解析。 （我找到了一个demo http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/fractalLog5Log4.html一条包含 390,000 个点的折线。我认为编码器的效率会低得多，因为多段线和点较少，因为舍入会减少。） 由于街道段是根据标准显示的，因此必须动态创建折线并且无法使用缓存。

一些想法：

KML/KMZ:

Pros:由于它是一个标准，我们可以轻松加载 Bing 地图、Yahoo!地图、Google 地图、Google 地球，具有相同的 KML 文件。数据生成是相同的。

Cons:KML 中的 LineString 无法像 Google 地图 API 那样编码折线。因此它可能会更大并且显示速度更慢。压缩文件的大小会花费更多的处理时间，并需要客户端解压缩数据，我不太确定 iPhone 将如何处理 250,000 个数据，以及服务器如何处理 40 个用户同时浏览。

JavaScript 文件：

Pros:JavaScript 文件可以有编码折线 http://code.google.com/apis/maps/documentation/polylinealgorithm.html并将显着减少要传输的文件。

Cons:必须创建我自己的 API v3 的精简版本来添加叠加层、创建折线等。它比仅仅创建 KML 文件并指向源更复杂。

GeoRSS:我认为这个选项不适合我的需要，但我可能是错的。

地图服务器：我看到一些帖子建议使用 MapServer 生成叠加层。不太确定与我们的数据库的连接及其所提供的性能。另外它需要一个插件来生成 KML。在我看来，它不会让我比创建自己的 KML 或 JavaScript 文件做得更好。没有的话维护会更简单。

垄断城市街道：游戏现在结束了，但对于那些知道我在说什么的人来说，《垄断城市街道》在最大缩放级别仅显示质心位于窗口范围内的街道。移动地图是向服务器发送请求以显示新街道。虽然我认为这很巧妙，但我不知道如何实现类似的东西。我唯一想到的就是比较长线是否在地图区域 X 的边界内并且与 Y 相同。虽然这可以在高缩放级别显着提高性能，但在显示整个城市时这不会给出任何结果。

聚类：虽然聚类对于标记来说非常棒，但我们似乎无法对折线进行聚类。我会喜欢类似的东西标记聚类器 http://googlegeodevelopers.blogspot.com/2009/04/markerclusterer-solution-to-too-many.html对于折线并能够按我的 3 种折线颜色进行聚类。这可能会继续作为“本来会很棒但忘记它”。

Arrow:我将在未来的版本中显示折线的方向，并且必须在质心处显示箭头。加载图像或标记只会使我的数据加倍，因此创建自定义叠加可能是我唯一的选择。我发现demo http://wtp2.appspot.com/ArrowLine.htm对于类似的事情我想实现。不幸的是，演示速度非常慢，但我只想为每条折线显示 1 个箭头，而不是像演示那样显示多个箭头。此功能将取决于数据的格式，因为我认为 KML 不支持自定义叠加。

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

问题：

• 我应该创建一个 Web 服务来返回街道段文件还是创建一个返回该文件的 aspx 页面？
• 基于最大经度/纬度折线有 9600 个字符并且我必须渲染最多 250,000 条线段折线这一事实，我应该创建一个带有编码折线的 JavaScript 文件还是一个带有经度/纬度的 KML 文件。或者我应该使用生成覆盖图的地图服务器？
• 我能否在下一个版本中在折线上显示简单的箭头？
• 在生成 KML 的情况下，使用以下命令创建文件是否更快XDocument, Xml文档,XmlWriter这是手动还是只是序列化流中的街道段？

这更像是一个集思广益的 Stack Overflow 问题，而不是一个实际的代码问题。任何有助于缩小可能性的答案都与拥有所有知识的人为我指出更好的选择一样好。

运行大量短 GPolylines大规模地比少量长 GPolylines 慢。

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

在开始处理 250,000 条线段之前，我建议您看一下这个200条随机多段线的快速测试 http://econym.org.uk/temp/200polylines.htm。尝试在 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() 代码中添加了执行四叉树搜索的复杂性，以加快对图块内热点的搜索，但在自己的代码中实现此策略的其他人认为这是没有必要的，并且线性扫描热点列表的速度足够快。

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