谷歌地图的数据结构如应用程序？

Question

我正在做一个maprouting应用程序。有几个人建议我，我做了一个数据结构，我将地图拆分成一个网格。理论上它听起来真的很好，但我不确定，因为我实现它时会遇到糟糕的表现。

在最糟糕的情况下，你必须画出每一条路。如果将地图划分为网格，则网格中所有单元格中的道路总和将比将所有道路放入列表中的要大得多。（如果道路通过，每个单元格必须具有比实际需要的更多的道路它）。

如果我必须放大，我可以看到使用网格的一些智能，但如果我将它保存在列表中，我可以在每次放大时减少道路数量。 现在（通过使用列表）它并不是很快，所以我全力以赴加快速度。但实际上划分网格会让我慢一些。

对于我应该使用什么数据结构和/或我可能做错了什么的任何建议？

Answer 1

如果你想要快速行驶，你可能最好将道路安排在主要和次要道路上。

使用次要道路列表查找到最近的主要道路的路线。 使用主要道路可以到达目的地附近。 然后回到小路上完成路线。

如果没有像这样的分裂，很多道路都会被搜索，其中大部分路线都很慢。

Answer 2

每次刷新屏幕时，谷歌都不会绘制每条道路。他们使用了地图的预先绘制的瓷砖。他们可以根据需要重绘它们。例如当有地图更新时。他们甚至使用透明覆盖层，堆叠的瓷砖来添加和删除细节层。

非常聪明，但很简单。

你可能想看看openlayers javascript库。免费，可以做任何你需要做的地图。

Maptraction JS也可用 - 它不像OpenLayers那样完整

Answer 3

有关相关信息，请参阅此问题：

What algorithms compute directions from point A to point B on a map?

以此类软件为生的人已经回答了这个问题。

同样用于渲染：

What is the best way to read, represent and render map data?

我不太确定你是想尝试快速路由还是渲染！

Answer 4

然后使用网格作为空间数据结构更加优化，可能是四叉树，因为它以对数方式分解地图。通过研究来源，我的估计是谷歌使用（或）类似的数据结构。

至于获取路线，您可能希望首先查看分层路径查找以近似方向并加快过程;在这种复杂程度下，通用路径查找算法往往很慢。