OSRM profiles removed

[Luab]

Hi guys!

Thanks for the amazing library. I was wondering for the reasons of OSRM profiles being removed from the library by #64.
According to OSRM api docs there is a concept of "profile" and in fact our team was using routing-py with multi profile OSRM. This is usually achieved by using a proxy, which maps different OSRM instances by url. Using profiles in routing-py router was extremely convenient for us.

Is it possible to revert #64 and restore previous API, while setting default version of profile to driving?

[nilsnolde]

I guess you then have somehow named your osrm base url according to the previous osrm "profiles" routing-py was referencing? honestly, I have no idea how that ever worked before #64 . I realized finally that osrm doesn't have any notion of a profile for its endpoints. the endpoint urls for osrm are always postfixed with e.g. /table/v1/driving, no matter the "profile". if you'd want to offer multiple profiles, you'd have to host multiple instances of osrm and route the traffic according to a profile with your webserver, similar to what the public instances at FOSSGIS are doing, e.g. https://routing.openstreetmap.de/routed-foot, but note that it still needs /table/v1/driving?. before that pr, the url would be /table/v1/{profile} and that wouldn't work with those public servers. to be honest , apparently I was must've been using the osrm routing-py provider the first time just before that pr, because that's when I realized that it didn't work (our tests are unfortunately a little self-fulfilling, we'd have to change to live requests, especially now that all routing engines have one public instance, valhalla was missing for a long time).

so I'm curious how it could've worked for you before #64 and doesn't work now? can you share an example URL?

[nilsnolde]

ah, I'm just seeing in the api docs what you mean.. for parameter profile:

Mode of transportation, is determined statically by the Lua profile that is used to prepare the data using osrm-extract . Typically car , bike or foot if using one of the supplied profiles.

that's weird though.. the osrm-routed instance one requests is loading a single .osrm dataset which is derived from a single lua file, which is osrm's way of describing a profile. or wait.. is that somehow related with osrm-datastore? I saw recently in the osrm repo some post mentioning that one can put multiple datasets into osrm-datastore. is that how you look up profiles?

just seeing that I was wrong: it doesn't have to be /table/v1/driving, it can also be /table/v1/walking: https://github.com/Project-OSRM/osrm-backend/wiki/Running-OSRM#running-multiple-profiles-on-one-machine. somehow I was imaging that osrm-routed adds/expects the /v1/driving..

can it then be any URL? osrm must know which service to use and where the coordinates are, so e.g. /table/v1/driving/<coordinates> has at least the first and last component fixed. what about /v1/driving? at the very least that can be /v1/walking or /v1/cycling as well, but can it also be v1/sliding? Or even /my/osrm/profile/rocks?

you're right, #64 is not doing the right thing either. I'm wondering if we'd need to let the user have full control over the URL part after /table//route and before the coordinates?

(sorry, I edited quite heavily after posting initially)

[Luab]

So the way we are using it is that we have several OSRM instances running, each has it's own profile (according to lua preprocessing script). Then we use nginx to route the requests by simple url matching. For example /table/v1/walking goes to instance one instance and /table/v1/driving to another one. It's a bit hacky, but does the job.

I think each OSRM instance just discards the {profile} part of url, so requesting /table/v1 would result in a valid response. Have changed your test OSRM instance somehow?

Here is an example from public OSRM instance.
https://routing.openstreetmap.de/routed-bike/route/v1/driving/8.316650390625,49.930008124606886;8.664093017578125,50.00597379753065
And this URL produces the same response
https://routing.openstreetmap.de/routed-bike/route/v1/test/8.316650390625,49.930008124606886;8.664093017578125,50.00597379753065

The main benefit of profiles was that we only needed one instance of OSRM router from routingpy, that would make requests according to vehicle type. The previous version did the job, so I don't think full url customization is needed.

[nilsnolde]

yeah right, thanks, don't know why I didn't try myself 😅 I find that whole URL architecture super strange..

but alright then, I'm convinced to revert the PR. and put some more comments in the docstrings so people aren't confused that profile=bike for the public instance is not automatically a bike response.

[Luab]

Hi, thanks that great.