-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Query-time conditional edge-weights #2377
Comments
This should probably be considered along with #77 - if it seems feasible to do, we may want to "avoid tolls", but not affect ETAs if a toll road is forced. |
This approach is very problematic in my view. I will try and elaborate using the example to avoid If we want to avoid highways, we are looking at a pretty important part of the hierarchy. Not contracting the highway network, could be suitable, since we are removing unnecessary roads and keep the important part of the network. In the contraction process, we need to construct shortcuts. Whether to omit a shortcut depends on the actual search parameters and whether a setting exists in which we can say the potential path is a shortcut. Consider the following simple graph:
(a,b) and (b,d) are local streets. (a,c) and (a,d) is a highway. Now if we consider the desire to avoid highways. The shortest path without highways between For some parts we can use the mechanism, e.g. adjust travel time on the fly. In these cases we can use the lowest possible travel time for shortcut computations. I don't think it can reasonably work for avoid/other possible flags though. |
@MoKob Am I correct in assuming the CH just add "short cut" edges with said "short cut" know which edges it's actually short cut over (so in your example, the a->d shortcuts "knows" it's shortcutting over a->c->d)? |
@SuberFu while it only adds shortcuts, it also doesn't add shortcuts that might be needed. So lets look at the most simple example here:
Lets say a - c - d is faster than a - b - d So if we contract in the order b, a, d, c we end up with the hierarchy:
So you can see, not even a shortcut is added, but we only know that if we search from a to d, we can ignore b. A can only reach c, the same for d. Only b can reach all vertices. In addition, it is not an easy question to define affected. Because in the moment when you add a penalty to any shortcut, next to any location in the graph can be affected. TLDR; no, its sadly not that simple. |
One addition here: the CH does not load all edges into memory. The routing graph only contains edges that are directed upwards. So |
This issue seems to be stale. It will be closed in 30 days if no further activity occurs. |
This ticket is to discuss our options with CH for implement conditional edge weights - the ability to adjust some edge weights at query time.
The implication here is that we would not contract nodes involved in these edges. This will obviously hit query performance on two fronts:
Why are we considering this:
The basic idea would be this:
I can currently picture four conditional operators we might want to support:
For relatively small numbers of conditional edges (example: conditional turn restrictions) this might work fairly well - routing would only touch the core (uncontracted) network occasionally. We would lose the benefits of a full CH, and add some additional query overhead, but we would not need to re-process the data in order to change routing behaviour over time. As long as the number of conditional edges remains fairly low, the performance penalty may not be too great. This would need to be measured to be sure, but is likely similar to the current
--core
feature.@MoKob @TheMarex Feasibility?
The text was updated successfully, but these errors were encountered: