Hello folks!
I discovered some oddities while using the foot-walking
directions API endpoint. My understanding is (please tell me if any of my assumptions are wrong!) that the foot-walking
profile should avoid highway=trunk
and highway=trunk-link
unless there is a sidewalk. As seen here in the source code. From my testing, this doesn’t appear to be the case given my understand of everything (which again, could be inaccurate).
So my first question is, does the FootFlagEncoder
impact the foot-walking
profile for directions? Assuming it does, is it safe to assume that avoid doesn’t necessarily mean it will never use that road even if the OSM data does not have a sidewalk tag. Or does it mean it will always avoid that road unless there is a sidewalk tag.
Below I’ve provided information/screenshots showing what I am seeing.
Here is the payload and uri that I used:
POST: https://api.openrouteservice.org/v2/directions/foot-walking/geojson
{"coordinates":[[-83.033492,42.312440],[-83.039040,42.317549]],"preference":"shortest"}
Here is a screenshot of the resulting geojson payload (taken from the api playground)
And here is a screenshot of the way tags (taken from openstreetmaps data explorer)
This could also be an edge case because the roads tagged with name=Detroit-Windsor Tunnel
is not somewhere you can just walk into. It’s a boarding crossing between Canada and the USA which is only open to car traffic. So maybe these roads need to be properly tagged so that the profile will never recommend them for walking? Which means it’s an issue with the underlying OSM data.
I’ve also tested this locally using updated OSM data to create a slice of the area.
The area slice I used can be downloaded here: http://download.openstreetmap.fr/extracts/north-america/canada/ontario/southwestern_ontario-latest.osm.pbf
The command I used to slice produce a smaller slice:
#!/bin/bash
osmosis \
--read-pbf southwestern_ontario-latest.osm.pbf \
--bounding-box top=42.3316 left=-83.0802 bottom=42.2923 right=42.2923 \
--write-xml sculpture_gardens.osm
gzip -c sculpture_gardens.osm > sculpture_gardens.osm.gz
Using the sculpture_gardens.osm.gz
file produced, I see the same results as with the API playground.
I think this rules out the possibility that the API playground is using outdated data. With that said, is there a way to know when the API updates its planet file?. Note that the OSM tags for the Detroit Windsor tunnel has been updated within the last couple months.
Screenshot from the local server using up to date OSM data (used QGIS to show the route). Payload is the same as above.
I can post the local server’s ors-config.json
file on request but since the results are the same, I don’t think it’s related to the server configuration.
If what the server is returning is the expected behaviour, links to the source code or documentation would be greatly appreciated and is there a possibility of creating a conversation around changing this behaviour?
If it’s not the expected behaviour then what are the next steps? Should I open an issue on github and include all the information I posted here?
Thanks!