OSRM displaying cardinal direction variables in directions as plain text

[omgitsgela]

I have a segment of roadway marked as a motorway with a large relation, where the role is "north" and the motorway name is "I 495".

What's happening is generated directions are interpreting the role "north" as $north, and it's being displayed that way to the end user.

The expected behavior would be to resolve $north internally, and display the value of it instead of the variable so it looks clean to the end user.

[danpat]

@omgitsgela The reason for this is translation. The car.lua embeds $north as a machine-readable value, the intent is for user interfaces (like osrm-frontend and the openstreetmap.org website) to substitute that value with the user's preferred language.

The reason we can't simply expose the role value capitalized is that there are Spanish and French variants even within North America (e.g. some Canadian highways in Québec should will be signposted as Nord/Sud/Est/Ouest), and the role is defined to be machine-readable north/south/east/west English values, which don't always directly match the signage.

The OSRM API doesn't do any translation itself - we leave the generation of descriptive strings and translation up to client-side libraries.

[omgitsgela]

Thank you for the thorough reply. It sounds like the proper location for this bug report is the osrm-frontend githib. Are you able to move the ticket over, or should I close and create a new one?

[danpat]

@omgitsgela Honestly, I'm not sure. Emitting the $north token is kind of lazy on our part, deferring the decision about what to say to clients, who hopefully know better.

The problem is that it's not super clear to me what we should be saying. For example:

1. You're an English speaking driver in Québec, and you see a sign like this one - do you expect the instructions to say "370 Est" as signed, or "370 East" in your language ?
2. You're a French speaker in the US, and you see a sign that says "I-80 South" - do you expect your software to say "I-80 Sud", or should it match what the sign says?

If the overall opinion is that we should match the signage, then we've got a problem - OSM only encodes the english strings north, south, east and west in the role part of the route relations, there's no indication as to what the sign actually says. We'd need a database of "what language signage is in" to know how to translate these on the server side.

If the overall opinion is that we should emit cardinal directions in the user's native language, then we'd either need to support a "language" parameter on the OSRM API, or make it clear that clients need to do some translation on their own (perhaps via https://github.com/Project-OSRM/osrm-text-instructions).

My personal opinion is that we should probably try to match the signage, but that's a hard problem because of a lack of data :-/ I'm open to discussion on this one though.

The other alternative is that we simply turn this feature off on the demoserver.

[danpat]

And then there are also annoying problems like the A-5 route in Ottawa, which changes signage from English to French when you cross from Ontario into Québec, but everything is just tagged as north or south in the route relation in OSM:

https://www.openstreetmap.org/relation/215690

[1ec5]

Separately from relation roles or direction tags, the de facto standard for destination:ref is to append North etc. in the local language (so Nord or Norte in some regions). OSRM preserves these words in the destination property, because it doesn’t attempt to parse them out of the destination:ref tag.

[github-actions[bot]]

This issue seems to be stale. It will be closed in 30 days if no further activity occurs.

[1ec5]

This is still an issue, but it no longer reproduces on osm.org or the demo server because FOSSGIS has disabled cardinal directions outright in their car profile:

https://github.com/fossgis-routing-server/cbf-routing-profiles/blob/24eaec0c5534a711349d166b43a454e64c6c9243/car.lua#L39