Using a type field to indicate road type during preprocessing

[DennisOSRM]

@systemed wrote

I'm not 100% sure that removing type is a good idea.

At present OSRM's instructions are a bit arbitrary in what they determine as a 'turn' - see #879, #956, >#684, #686, #282. Sometimes turns will not be shown in the instructions at all, or sometimes they'll be shown as "continue" even though they're a modest left turn. Conversely, sometimes a bogus turn will be generated just because the road changes name.

One way to fix this (and the way I'm intending to do it at cycle.travel) is to compare types. So, for example, if the route goes from a motorway to a motorway_link, that is by definition a left/right turn, even though the angle will be small. Or if the road changes name, but the angle is 0° and the road type remains the same, that isn't a turn.

By comparing road types, we should also be able to give a penalty when a minor road crosses a major one (without a crossing), which would be great for bike routing.

@DennisOSRM, any thoughts?

The idea is a good one. Unfortunately, @emiltin was right when he replied

@systemed yes penalties for crossing big roads is something we miss too. see #592.
however i don't think the current type field is the way to solve it.

I am in favor of properly implementing a type field that can be used during preprocessing / generation of instructions. OTOH, it should be set from the LUA script and then the instruction generation should also be handled by a LUA function as it doesn't make too much sense to hard-code road types in C++ land.

CC: @emiltin @systemed

[systemed]

That makes sense.

So this could be one way of doing it:

• Set .type in Lua profile (as at present)
• Move AnalyzeTurn into Lua
• Alter AnalyzeTurn parameters so that it receives a complete list of edges at this turn, with their types and bearings, plus the index of the one currently being considered
• Potentially move parts of JSONDescriptor into Lua (e.g. BuildTextualDescription)

[DennisOSRM]

Sounds reasonable, but moving the Descriptor into LUA has performance implications.

[emiltin]

sounds great

[systemed]

Thinking on this some more, another advantage of a type field could be as an optional preference for FindPhantomNodeForCoordinate, as used in the /nearest and /viaroute calls.

If you're planning a route by clicking on (say) z7 tiles, which might only show trunk roads, you probably want your route to start on a trunk road 300m away from your click, rather than a random service road 5m away from your click.

Similarly, if you're dragging a route, it's easy to 'misclick' and release slightly away from the main road, in which case you get an unwanted out-and-back diversion along a track or something. (Or a footpath off a cycleway, in my case!)

[hmaeda]

I am a bit new to this discussion, but was wondering how possible it would be to get road type in the instructions. Failing the instructions from a viaroute call, how about when using a nearest call. It sounds like by carrying out some pre-processing some new .osm files would be generated, and by using them, it might help...if so any suggestions on how that would be done?

[TheMarex]

@hmaeda usually people just encode the type in the street name that you can set from the lua profile.

[hmaeda]

@TheMarex Can you please give an example of how the profile.lua file would be changed to include type?

[emiltin]

take a look at the bike profile. it encodes the way type in the way name, when the normal name is empty:
https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/bicycle.lua#L225