Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

correctness vs. speed: astarbi.epsilon #2995

Open
karussell opened this issue Apr 30, 2024 · 0 comments
Open

correctness vs. speed: astarbi.epsilon #2995

karussell opened this issue Apr 30, 2024 · 0 comments

Comments

@karussell
Copy link
Member

karussell commented Apr 30, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant