Osrm-backend: Distance to end?

[mqln]

Is there any way to access a metric for the distance from destination duringprocess_way within a profile?

I'm hoping I can access the distance as-the-crow-flies, because the actual routed distance wouldn't make sense 😅

My goal is to have certain types of ways be preferred if they're near the destination. Is this possible?

I've been trying to figure out wether or not this data is contained within the relations parameter of process_way, but I'm having a hard time with this documentation.

[danpat]

@mqln There are two things I guess you'll need:

1. The location of the coordinates along the way being processed
2. The location of the destination of interest.

You can solve (1) by enabling node locations inside process_way. To do this, create an empty GeoJSON file, and run:

osrm-extract --location-dependent-data emptyfile.geojson yourmap.pbf

Passing in an empty .geojson file will enable the internal "location cache" feature, which means that way.get_nodes()[1].location will be populated with coordinates in the Lua function.

To solve (2), Once you have the node locations available, you'll need a way to figure out which destination you need, and do the math to calculate the distance. That sounds like it'll be specific to your situation, I don't know of any general purpose data in OSM that'll be usable for this. You'll need to implement the as-the-crow-flies measurement math as well, but that should be relatively straightforward.

[mqln]

This is great, thank you.

Additionally, I don't believe that there is any way to set preferences PER ROUTE REQUEST with OSRM, since everything is pre-processed, is there? Like an additional flag one could add to a request, to exclude ways within an area that contain a certain tag? My current understanding is that all of that tag data is stripped by the time osrm contract is finished, correct?

[danpat]

@mqln Excluding ways is actually the one aspect where you can do some runtime selection. OSRM supports this by creating duplicate subgraphs with the "excludable" road types enabled and disabled. It costs a little bit of extra memory, but it's not too bad.

You need to adjust the Lua profiles to attach "classes" to the ways you care about, then enable excludable combinations for those classes. The default car.lua profile does this here:

https://github.com/Project-OSRM/osrm-backend/blob/f9289565848246c02ffaafbafe106e07a00b5261/profiles/car.lua#L117-L126

This allows you to do ?exclude=motorway in your API request, and motorways will be completely excluded. Note that in order to do combinations, you must explicitly list these in the Lua profile, as separate sub-graphs need to be created for each combination (by making the excludable Sets have multiple members, rather than just one as in the example above).

Otherwise, yes, you're correct, runtime customization isn't generally possible - OSRM pre-calculates optimized graphs that basically bake your routing preferences (from the Lua scripts) into the shape and structure of the graph itself.

[mqln]

Ahh beautiful! I didn't realize that that was possible, thank you!

Upon reading the docs for this feature, I've now got another question:

Does the size of this allocated memory increase to the squared of the set, or is it a linear increase?

I'm asking this because I'm basically trying to create a rough sort of include flag for routes, which I could achieve by having a list of excluded tags from which I could drop a tag (I was thinking around 50 excluded tags).

[mqln]

Upon further inspection, I found a comment stating that only there can only be a max of 8 exclude classes. I assume this is still true, and an issue from the compounding complexity of multiple sub-graphs?
Here's the comment I'm referencing

[danpat]

Yes, there's a maximum of 8 - the way @TheMarex implemented this feature, it uses a single byte per edge (8 bits) to indicate which classes are assigned. On a global graph (with 600 million+ edges), adding a single byte uses quite a lot of memory, so this was seen as a reasonable compromise.

It should be not too difficult to hunt through the code and adjust the size of that property to get access to more classes, but you'd need more RAM to do it. If you're so inclined, I think we'd accept a pull request that makes it a compile-time configurable option :-)