对于GIS业务来说，路径规划是非常基础的一个业务，一般公司如果处理，都会直接选择调用已经成熟的第三方的接口，比如高德、百度等。当然其实路径规划的算法非常多，像比较著名的Dijkstra、A*算法等。当然本篇文章不是介绍算法的，本文作者会根据pgrouting已经集成的Dijkstra算法来，结合postgresql数据库来处理最短路径。
一、数据处理路径规划的核心是数据，数据是一般的路网数据，但是我们拿到路网数据之后，需要对数据进行处理，由于算法的思想是基于有向图的原理，因此首先需要对数据做topo处理，通过topo我们其实就建立了路网中各条道路的顶点关系，下面是主要命令：
其中test_road是将路网数据导入到postgresql中的表名。
处理完topo之后，基本就够用了，我们就可以借助pgrouting自带的函数，其实有很多，我们选择pgr_dijkstra
从函数输入参数可以看到，我们需要一个查询sql,一个起始点、一个结束点、以及是否考虑方向，好了了解到调用函数输入参数，我们就来写这个函数。
二、原理分析一般路径规划，基本都是输入一个起点位置、一个终点位置然后直接规划，那么对于我们来说，要想套用上面的函数，必须找出起点位置target ，以及终点位置的source，然后规划根据找出的这两个topo点，调用上面的函数，来返回自己所需要的结果。
如何根据起始点找到对应的target呢，其实就是找离起点最近线的target，同理终点的source，其实就是找离终点最近线的source,当然将这两个点规划规划好之后，基本就可以了，但是最后还需要将起点到起点最近先的target连接起来，终点到终点最近线的source连接起来，这样整个路径规划就算完成了。
下面我们来看具体的实现存储过程：
上面这种实现，是将所有查询道路返回一个集合，然后客户端来将各个线路进行合并，这种方式对最终效率影响比较大，所以一般会在函数中将道路何合并为一条道路，我们可以使用postgis的st_union函数来处理，小编经过长时间的试验，在保证效率和准确性的情况下，对上面的存储过程做了很多优化，最终得出了如下：
上面的函数，其实对于大部分情况下的操作，基本可以满足了。
三、效率优化其实在数据查询方面，我们使用的是起点和终点之间的线性缓冲来提高效率，如下：
当然这在大部分情况下，依旧是不错的，然后在有些情况下，并不能起到很好的作用，因为如果起点和终点之间道路偏移较大（比如直线上的山脉较多的时候，路就会比较绕），这个时候，可能会增大缓冲距离，而增加缓冲距离就会导致，部分区域的查询量增大，继而影响效率，因此其实我们可以考虑使用mapid这个参数，这个参数从哪来呢，一般我们拿到的路网数据都会这个字段，我们只需要生成一个区域表，而这个区域表就俩个字段，一个是mapid，一个是这个mapid的polygon范围，这样子，上面的查询条件，就可以换成如下：
这样就可以在很大程度上提高效率。
四、数据bug处理其实有时候我们拿到的路网数据，并不是非常的准确，或者说是录入的有瑕疵，我自己遇到的就是生成的topo数据，本来一条路的target应该和它相邻路的source的点重合，然后实际却是不一样，这就导致最终规划处的有问题，因此，简单写了一个处理这种问题的函数
五、后续规划上面的函数已在百万数据中做过验证，后续还会验证千万级别的路网数据，当然这种级别，肯定要在策略上做一些调整了，比如最近测试的全国路网中，先规划起点至起点最近的高速入口，在规划终点至终点最近的高速出口，然后再高速路网上规划高速入口到高速出口的路径，这样发现效率提升不少，当然，这里面还有很多逻辑和业务，等所有东西都验证完毕，会再出一版，千万级别路径规划的文章。
到此这篇关于基于pgrouting的路径规划处理的文章就介绍到这了,更多相关pgrouting的路径规划内容请搜索七叶笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持七叶笔记！
