Project-OSRM / osrm-backend

Open Source Routing Machine - C++ backend
http://map.project-osrm.org
BSD 2-Clause "Simplified" License
6.34k stars 3.36k forks source link

Easiest way, to provide max planned speed on API call and not in LUA / from OSM max speed #6581

Closed SamuelBrucksch closed 2 months ago

SamuelBrucksch commented 1 year ago

Hi,

I know this is not possible right now, so i want to know, if there is an easy way, to get this in somehow.

Sometimes people just want to drive slower, for example on an EV, to consume less energy and get a higher range. If you would reduce the speed from for example 130 to 100, motorways should not be the main preferred road anymore, as many primary roads (in Germany and many other countries) have the same speed limit, but are way shorter.

However as far as I understood, the speed limits which are provided by OSM and OSRM are already cooked into the map, while preparing it for running OSRM routing.

Is there still any way, to hack in a custom max speed, that could be considered while calculating the route? Same for avoid highways or custom weights requested on the API call.

I don't need a full solution, i can also do some things on my own, however I would need a good starting point to check this out myself.

danpat commented 1 year ago

The graph optimizations that OSRM performs are perfectly in conflict with dynamic requirements like this, so generally the answer is no, OSRM simply can't do this kind of thing, any changes to runtime weights of edges invalidates the optimized graph and would give invalid routing results.

If you can reduce your needs to a limited set of specific values, then you might have options - OSRM does support "multiple versions" of the optimzied graph. Currently, this is only implemented for the "excludes" behaviour - OSRM bakes multiple copies of the optimized graph, one for each set of excluded roads you want. See https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua#L123-L128 for the things you can "exclude" from routing using a request-time API parameter.

The code doesn't currently directly support doing this for different road speeds, but conceptually it could be done - OSRM would create a "low speed" and a "high speed" optimized graph, and you could pick between them at query-time.

I don't think you could hack it with the current functionality - your description requires speed A on a road in one mode, and speed B on a road in another - that's not quite how the current feature works, but I think it would be possible to modify it to work that way. Either way, it'd require some changes to the C++ code, not just the processing scripts.

SamuelBrucksch commented 1 year ago

Hey @danpat ,

thanks for replying.

~Could you please let me know, how i can set the exclude as parameter for each request? Because that is something we need as well, like exclude motorway, ferry or toll roads based on user settings. Right now we have seperate instances to deal with that somehow.~ Just found this in the changelog. So this is easy.

The low and high speed profile would be good enough for now, i think. So if you have more details on how to achieve this please let me know.

nilsnolde commented 1 year ago

That's (almost) what top_speed is doing in Valhalla, implemented that like 2 years ago: https://github.com/valhalla/valhalla/pull/2667. (urgh, awkward early time for me in Valhalla haha)

SamuelBrucksch commented 1 year ago

Yes i saw that param on Valhalla and we also evaluated that for our use case, however right now we can not really use Valhalla due to different reasons. So i need something similiar on OSRM, even if it only means having a low and a high speed profile, as long as i can specify it as request param.

danpat commented 1 year ago

Honestly, if you're not willing to make C++-level changes to OSRM, you should probably just run two copies - and add a small HTTP proxy in front that picks between the two.

SamuelBrucksch commented 1 year ago

It's fine to make C++ changes. If it can be done with acceptable effort we would be fine with it. But as the code is quite huge and complex it's always hard to find the starting point for something like that.

github-actions[bot] commented 3 months ago

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