brouter
brouter copied to clipboard
abrensch
Some thoughts on rerouting – app only
The app already includes a simple and effective rerouting function. This means that only a fraction of the time is required for a recalculation
How it works: BRouter app saves a RAW track from the last routing request. This applies to the RAW points (way starts, way ends only), the routing destination and checksums for the profile, the Nogo instructions and the profile parameters used.
Try: Plan a route of approx. 50 to 150 kilometers. The feeling will be something like 'this is taking a long time'. If the starting point is now moved, the route should be finished much faster - rerouting in action. This function can be used to start a recalculation of a running route.
Problem 1: Reference is made to the old route. And not as expected with the 'heading=270' statement.
This was already discussed under #589 and one solution was a weighted no-go point behind the 'old' route. The problem with this is the rule old route is not the same as new route, the checksum of the Nogos becomes different.
The change: This Nogo point is only formed after the route check from the direction.
Problem 2: Maybe just in my person - when planning happens, it doesn't start straight away. Means the last saved RAW track is not valid for the route started from database.
The change: There is a new EngineMode that only creates the RAW track. BRouter is prepared at the start time and can then be used later. Needs no other output.
Problem 3:
The current logic only applies to a start - destination segment and is not usable when via points are used.
The change: Connecting the individual segments to one overall RAW track.
Test: So that all of this can be tested, I also activated the RAW track in the BRouter class.
Example of 3 segments start route Rerouting shortly after start Rerouting after the first via point
Source for this playground
@afischerdev thanks for the detailed description.
1 + 3 are very important as many users need routing with forward direction and use many via points.
-
So now we must set engine mode 6 for rerouting and 0 for routing?
-
About the heading, is nogo now added automatically?
- Can the weight be parameter? (9999 may seem safer, but motor tests prefer 10000)
@devemux86
So now we must set engine mode 6 for rerouting and 0 for routing?
No, routing and rerouting goes as always engine mode 0 The idea behind engine mode 6 was to precalculate the RAW track to get the time benefits from this logic.
About the heading, is nogo now added automatically?
Yes
Can the weight be parameter? (9999 may seem safer, but motor tests prefer 10000)
Could you please explain this motor tests?
The reason for the weighted nogo is to avoid entering a dead end.
@afischerdev
The idea behind engine mode 6 was to precalculate the RAW track to get the time benefits from this logic.
How does it work for the users, who sets the engine mode to 6?
The reason for the weighted nogo is to avoid entering a dead end.
BRouter with 9999 might return a backward route even when there is a valid forward route (returned with 10000). Perhaps when the backward route is significantly shorter than the forward route.
At least this is what I found when I implemented nogo for heading in Cruiser (https://github.com/abrensch/brouter/issues/589#issuecomment-1678772869). I do not have examples right now, need to review the BRouter routing in such cases.
How does it work for the users, who sets the engine mode to 6?
This is not transparent for the user. It is just a call from the routing app, that started routing, to inform BRouter this is what I'm doing and please preload a RAW track. The caller is the routing app - just inform to BRouter (BRouter has nothing to do at this time), not a must, but then the user have to wait for rerouting a longer while.
May be we find a sample on this weighted nogos later on. If the future brings us a public server with the current traffic situation for our areas.