There were a couple of things that I had to fix. Additionally you have to provide the weighting at import time. Now the name of this weighting is not “flex” but the name that used in the configuration:
Store this in
path/to/custom1.yml and do:
Then, if you do the import you should see something like
GraphHopperOSM: start creating graph from ...
GraphHopperOSM: using custom1|RAM_STORE|...
And if you do a POST (or GET) request you should see a log entry:
… RouteResource: … astarbi|landmarks-routing …
If you see something with “astarbi|beeline” then it still does not use the faster landmark routing.
One remaining task for me is to enable landmark
fastest-routing in case of
base: car. But the conceptional problem is that with the new approach there is no clear “vehicle” and just the “weighting” so we should better do
or something. That’s good that I stumbled over this problem in an early phase
This is also the reason that you currently have to specify
vehicle=custom1&weighting=custom1 for the GET request, see the fire_truck test.
If I understood correctly LM has effects on /route GET requests only, not on /flex POST, correct?
I have tried this now and it should work. Have not tuned speed that much at the moment but the LM algo is triggered for me via the process above. Please let me know if you make it working and see the landmark-routing in the logs with the latest master
Is fastest a bit slower than shortest since additional calculations are needed to compute time (distance*speed) vs just distance, right?
It shouldn’t be that much but have not done speed tuning that much yet for this proof of concept.
I don’t see any major performance improvement for the 3500km route test case
Routes above 1000km are indeed significantly slower than with CH (again if you add landmarks then you can get similar performance but RAM quickly gets an issue in case of such big areas). We could introduce a heuristic parameter to improve speed but sacrifice quality (optimality guarantee). But I hope that the landmark routing was not enabled and so the routing should be now roughly 10-15 times faster with the procedure described above.
Edit: there is another limitation of this simple JSON approach: it is not easy to say AND. E.g. set speed to 90km/h if road is primary AND in Germany AND not in the city. So we probably have to introduce a bit scripting here, but then we loose control to tune performance.