graphhopper / graphhopper

Open source routing engine for OpenStreetMap. Use it as Java library or standalone web server.

Home Page:https://www.graphhopper.com/open-source/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

correctness vs. speed: astarbi.epsilon

karussell opened this issue · comments

Currently a simple request like:

{
  "points": [ [11.539421, 48.118477], [16, 48] ],
  "custom_model": {
    "priority": [{ "if": "road_class == MOTORWAY || road_class == TRUNK", "multiply_by": "0" }]
  },
  "ch.disable": true,
  "profile": "car",
  "points_encoded": false
}

leads to a ~420km route and triggers a calculation that traverses 3.4 million nodes (for LM) or even 4.6 million nodes for A*.

If I use the "epsilon"-trick (e.g. "astarbi.epsilon": 1.4) the request will be lighter (and faster): only 2.4 million nodes are traversed (or 2.5 million nodes for A*) or even under 1 million for 1.8 (with a worse weight of course). We could investigate this to get a better understanding and advertise this parameter (or give it a better name) to improve speed by sacrificing correctness. Or even use a value greater one by default for the custom model and distances above 400km.

On this website they mentioned this paper where they created this visulation. It seems that they use a similar approach. What they found with pxWD was (I think) that they started with a stricter heuristic (epsilon=1) at the beginning of the traversal and then increased it while they traversed. This sounds interesting.