编程语言
首页 > 编程语言> > python-OSRM对2点之间的距离给出错误的响应

python-OSRM对2点之间的距离给出错误的响应

作者:互联网

我试图通过projects-osrm获得两个地理位置之间的距离.
通过python.

import requests
source_coordinates = '18.21231,42.50830;'
dest_coordinates = '18.20971,42.50075'
url =  'http://router.project-osrm.org/route/v1/driving/'+source_coordinates+dest_coordinates

payload = {"steps":"true","geometries":"geojson"}

response = requests.get(url,params=payload)

data = response.json()
print(data)

`
{
  "routes": [
    {
      "geometry": "oksbGmvonB??",
      "legs": [
        {
          "summary": "",
          "weight": 0,
          "duration": 0,
          "steps": [],
          "distance": 0
        }
      ],
      "weight_name": "routability",
      "weight": 0,
       "duration": 0,
      "distance": 0
  "code": "Ok"
}
`

如您所见,我将距离设为0作为响应.

但是当我在站点上输入相同的坐标时.

http://map.project-osrm.org/,并输入相同的坐标,我得到2.5公里和6分钟.

以下是快照:
    enter image description here

我能知道为什么会这样吗,还有其他方法(开源)来获取两个地方之间的距离和时间.

提前致谢

解决方法:

捆绑我们讨论中出现的所有不同部分.

1.主要问题-给出0行进距离.

可以找到该API的当前文档here(适用于> V4.x).请注意,在“请求”下,坐标以lon,lat顺序提供:

String of format
{longitude},{latitude};{longitude},{latitude}[;{longitude},{latitude}
…] or polyline({polyline}) or polyline6({polyline6})

您所提供的当前坐标将两个位置都放置在海中,前提是它们是长期配对.因此,您有可能改为以更自然的纬度顺序提供坐标. Web界面期望lat,lon以便产生您期望的输出.老实说,我不知道API为什么要坚持lon,lat.

2.其他路由服务

在OSM数据之上构建的当前路由软件列表可在其Wiki here中找到.其中,我已经广泛使用了Graphhopper和OSRM,但没有一个使用.关于使用过的内容,我可以说几句:

>对于大型查询,OSRM明显比Graphhoper快
因为它支持矩阵调用而Graphhopper不支持
开源格式).位置之间每秒查询少于300次
对,没有区别.
> Graphhopper带有内置的前端.OSRM front-end是一个
需要JavaScript进行整合的独立实体.
> Graphhopper提供便宜的API service,如果您不想
自我主持.

3.自托管.

您用于OSRM的当前API受公平使用政策的约束.这并不意味着要进行任何重要的工作,而只是不经常打电话.您还担心它的更新频率不够高.可以通过自行托管自己的软件版本来解决这两个问题(Windows不再支持OSRM,但您可以在虚拟机上构建,然后桥接端口5000,以便可以从Windows调用API,这就是我所做的) .

>构建OSRM指令可参见here.
>可以找到地图文件的提取说明here
> Geofabrik每天都会更新地图文件.您可以随时从here以.osm.pbf格式下载新的地图文件.

OSRM矩阵调用的旁注.关于矩阵API返回距离和时间的争论,我没有完全理解here.如果需要该功能,则应在niemeier-PSI here之前加载分叉项目的table-distances分支.我从未加载过全局映射文件,仅基于每个国家/地区,因此对这种方法的任何内存问题对我来说都无济于事.

标签:openstreetmap,osrm,python
来源: https://codeday.me/bug/20191110/2013690.html