support relations in lua profiles

[emiltin]

for our bike router we need to prioritize certain ways that are part of routes; green routes, regional routes, etc. the routes are marked in OSM using relations.

maybe the way function could get a list of relations that the way is part of?

this issue is a follow up on #300 by @karme.

[mjoris]

If it is really urgent you could try to replace the highway-tag-values of those way that are related to the routes, by for example 'greenroute' in the OSM-file. And next prioritize the highway type 'greenroute' in the OSRM speedprofile...

[emiltin]

you're right, that would be a potential work-around. but i would rather discuss what a more solid solution would look like :-)

[emiltin]

two ideas:

1. processing relations, and add custom tags to the ways, and then let the lua way_function handle those tags
2. when calling the lua way_function, pass in a list of the relations it's part of

a preprocessing step could be used for other things as well, like adding synthetic ways for connecting train lines and platforms that are part of stop_area relations, or for adding ways across squares.

[emiltin]

i implemented parsing of routes in this branch: https://github.com/ibikecph/Project-OSRM/tree/parse_routes

the lua way_function gets a list of the relation the way segment is part of, and can read the various relation tags. this way it's straightforward to modify setting on (for example) national cycle routes.

however, the ability to modify speed and impedance separately is still lacking, leaving you basically no other option than to change the speed, at the cost of getting unrealistic travel times.

to see it in action run: cucumber -t @route

@prozessor13

[emiltin]

i tried processing data for Denmark (110M pbf), where it increased extraction time by a few seconds only. i guess it doesn't affect ram usage a lot either, since there are few relations compared to ways and nodes.

[emiltin]

there are some problem with how data is read using threads. on real world data it seems some ways are parsed before relations. still experimental..

[karme]

another solution would be to use the denormalized data produced by the waysplit tool

[emiltin]

the branch https://github.com/ibikecph/Project-OSRM/tree/parse_routes works correctly now

[karme]

Emil Tin notifications@github.com writes:

the branch https://github.com/ibikecph/Project-OSRM/tree/parse_routes works correctly now

i think using the denormalize relations on ways approach would be
simpler / more general, but i don't have a real preference here

[emiltin]

how would you handle a way being part of two similar types of way relations? you would have to use an akward tagging scheme. it would also be akward to handle route member roles.

[karme]

Emil Tin notifications@github.com writes:

how would you handle a way being part of two similar types of way
relations? you would have to use an akward tagging scheme. it would
aalso be akward to handle route member roles.

at the moment all key value tags of all relations a way is member of are
added as key value tags where the original key is prepended with
"rel[x]:" (where x is some number):

rel[0]:key1 val1
rel[0]:key2 val2
...
rel[0]:keyn valn
rel[1]:key1 val1
...
rel[n]:keyn valn

[emiltin]

thanks. you can see the relation object approach at https://github.com/DennisOSRM/Project-OSRM/blob/experimental/route_relations/profiles/bicycle.lua.

i think it's more straightforward to pass the route objects themselves, instead of having to copy all the tags to all the involves ways.

it might also be faster, since you don't need to store new tags, just keep pointers to the relation objects? did you do any performance test on your code? for Denmark, the object approach adds a few percent of processing time, if i recall correctly.

btw, your scheme above doesn't mention the member roles. for example, some parts of routes are only forward or backward.

[karme]

Emil Tin notifications@github.com writes:

thanks. you can see the relation object approach at
https://github.com/DennisOSRM/Project-OSRM/blob/experimental/route_relations/profiles/bicycle.lua.

nice

i think it's more straightforward to pass the route objects
themselves, instead of having to copy all the tags to all the involves
ways.

it might also be faster, since you don't need to store new tags, just
keep pointers to the relation objects? did you do any performance test
on your code? for Denmark, the object approach adds a few percent of
processing time, if i recall correctly.

no, didn't do any benchmark specific to that part

btw, your scheme above doesn't mention the member roles. for example,
some parts of routes are only forward or backward.

will take a look at that

your solution is just fine

the motivation of my approach was/is:

• it was really simple to do
• for the waysplit¹ it is much better to get rid of osm relations
  altogether as early as possible (otherwise you have to fix way
  references in relations - at the moment i only do that for restriction
  relations)

all the best
karme

¹ splitting ways at way intersections