Foot-walking profile doesn't seem to avoid highway trunk

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!

Hey,

this only happens with the shortest preference. Therefore, we guess it is related to how the avoid-part for these highways is implemented. It looks like it’ll assign a priority to these tags, instead of hard avoiding them by filtering the corresponding ways.

The shortest preference however disregards all priorities, since for shortest only the length of the way is used in finding a route.

This should be fixed, so that these ways are only used if they have a sidewalk, as the name suggests.

It’d be great if you could open an issue regarding this :slight_smile:
Best regards

Thank you for your reply!

I’ve gone ahead and submitted an issue.

In an attempt to support the development team, I’m going to spend some time today looking at the source code to determine where a fix could be implemented. Though I will admit that my knowledge of Java and the code base is definitely not the best. With that said, if you know of any place in the source that I should focus my attention on or start from, please let me know!

Thanks again!