将带有房屋的地图转换为图表

Question

我很好奇地图软件（Google/Bing 地图）如何在后端将地图转换为图表。

现在，如果我们在交叉口 1 和 2 之间添加房屋，那么图形将如何变化。地图软件如何跟踪房屋的位置？

它们是否为交叉节点编制索引并且还具有较小的“子节点”（在本例中为 1 和 2 之间）？还是他们通过多层来做到这一点？因此，当用户输入住宅号码时，它会查找住宅的位置（即住宅位于哪些顶点之间）。之后，他们只是在这两个节点之间应用最短路径算法，并且在开始和结束时，它们基本上使主节点到达主要顶点之一。

有人可以详细解释一下这是如何工作的吗？最终，我想了解如何确定最短路径，给定两个“家”（或“子节点”）的“地址”。

Answer 1

我只能代表 GraphHopper，不能代表你提到的闭源服务；）

GraphHopper 具有节点（交汇点）和边（这些交汇点之间的连接），几乎与您的草图完全相同。这对于路由算法来说非常快，因为它避免了子节点的大量遍历开销。例如。在早期版本中，每当连接不直（例如弯曲的街道）时，我们都会使用子节点，这会慢 8 倍，因此我们避免使用那些“支柱”节点，只使用“塔”节点进行路由。

你仍然需要处理两个问题：

• 如何处理从边缘开始的查询，例如1号房子？这是通过为每个查询（可以包含多个位置）引入虚拟节点来解决的，并且您还需要额外的虚拟边并隐藏一些真实边。在 GraphHopper 中，我们围绕处理所有这些的原始图（称为QueryGraph）创建了一个轻量级包装图。然后它的行为与每个“路由算法”（如 Dijkstra 或 A*）的正常“图形”完全相同。当您在一个边缘有多个查询位置时，它也会变得有点毛茸茸，例如对于具有多个通过点的路线。但我希望你明白主要的想法。另一个想法是为两个源和两个目标进行路由，但使用实际距离初始化，而不是像通常对第一个节点所做的那样使用 0。但我猜这会使路由算法更加复杂。
• 如前所述，交叉路口之间的大部分连接都不是直的，您必须将此几何图形存储在某处并使用它来绘制路线，但还要“捕捉到最近道路的位置”最后做实际路由。有关代码，请参见 LocationIndexTree。

关于有向图。 GraphHopper 通过无向边存储图形，为了处理单向，它分别存储每条边和每辆车的访问属性。因此，我们避免存储两个有向边及其所有属性（名称/几何形状/..），并使用例成为可能“汽车单向，自行车双向”等。它还允许以相反方向遍历边，这对于某些算法很重要，例如双向 Dijkstra。如果图表用于对访问属性进行建模，则这是不可能的。

关于“您的草图看起来几乎完全一样”：节点 1、3、7 和 8 将不存在，因为它们是“支柱”节点。相反，它们只会“存在”在边缘的几何形状中。

Answer 2

为了表示道路网络的连通性，您希望有向路段是图形节点，而您的交叉点是有向边的集合。如果您可以沿 X 行驶然后转向或继续沿 Y 行驶，则存在从 X 到 Y 的有向边。

考虑以下示例。

a====b====c
     |   
     | <--one way street, down
     |
     d

下面是这张图片的连接图示例。

• 节点

  ab
  ba
  bc
  cb
  bd
  

• 边缘

  ab -> bc
  ab -> bd
  cb -> ba
  cb -> bd
  

请注意，这对以下信息进行了编码：

• 十字路口不允许掉头，
  因为边缘ab -> ba 和cb -> bc 被省略了。

• 从右侧来时，允许左转进入垂直道路，
  因为包含了边cb -> bd。

通过这种表示，每个节点（有向路段）都具有沿其跨度的所有地址作为属性，每个地址都标记在沿有向路段的一定距离处。