For the next version 0.14 we plan to start work on “external vehicle profile definitions”. In previous work this was called “flexible branch”, but the profile stuff is also handy for CH e.g. for defining the weighting, vehicle and U-turn cost for the CH-profile, see this discussion.
Here some other open source routing engines and how they do it:
- OSMAnd defines profiles via xml and supports language features in it like this “if” and “select” stuff: https://github.com/osmandapp/OsmAnd-resources/blob/master/routing/routing.xml
- valhalla allows tweaking the profiles per request in the API: https://valhalla.readthedocs.io/en/latest/api/turn-by-turn/api-reference/
- OSRM defines profiles via lua profiles. Possible only for import: https://github.com/Project-OSRM/osrm-backend/tree/master/profiles
- BRouter has its own scripting language and allows to define profiles: http://brouter.de/brouter/costfunctions.html
Although it is very cool to have the scripting feature (see the flexible branch) we’ll not include this, at least not at the beginning due to the security implications. So more like OSMAnd does it. Or less flexible, but easier for users like valhalla.
The short term goal is to make it possible to change profiles without Java knowledge, so probably we need to define kind of unit tests in a non-Java way too like OSRM does, but I’m unsure. The long term goal could be to make creating profiles possible without compiling GraphHopper (not sure if this is really required).
When we introduce this profile stuff we’ll go with an iterative procedure, start quickly and see what is possible. We’ll very likely also break old API, so this stuff will have breaking changes in 0.15 (coming from 0.14). We’ll allow the profile definition e.g. in the config.yml or one file per profile. Additionally it should be somehow possible to create a hierarchy e.g. define motor vehicle and use this as base in car and use car in the truck profile definition or something like this to avoid starting from scratch.
It will be possible to include such a “profile” per request and send this via yml or json data as a POST request. Also, when you have tuned it enough it will be possible to use exactly the same content to define a CH profile e.g. via a separate file or part of the config.yml. This means that we need an endpoint that supports POST requests. We’ll start with a new endpoint for that and improve not only the request stuff but likely also the response like commented in this issue. Due to these changes the endpoint needs a new name, e.g.
/route? This is hard …
On Android this will be possible via a FlexModel class and so no jackson should be necessary as separate dependency to parse the YML and JSON. But this is not yet 100% clear because we need the YML parsing at import and CH preparation time. Maybe we have to split CH core to avoid this or find another solution.
If anybody has input, questions or suggestions, please let me know about them