abrensch
New Roundtrip function
Here comes the new engineMode for roundtrips.
Parameters to play with:
direction - angle around start point (default random) roundtripDistance - distance from start point (default 1500m) roundtripDirectionAdd - changes the angle added to the direction (default 20 degrees) allowSamewayback - go back the same way (default false)
exportWaypoints - export the generated points (default false) profile:correctMisplacedViaPoints - correct the results (default false) profile:correctMisplacedViaPointsDistance - distance for correction, 0 = don'r check distance (default 40m)
some samples:
direction = 90
direction 360 correctMisplacedViaPoints off
direction 360, correctMisplacedViaPoints on
direction 180 roundtripDirectionAdd 45deg
direction 360 allowSamewayback true
@afischerdev Thanks for this long awaited feature! :+1:
roundtripDirectionAdd - add an angle to the direction (default 20degree)
Can you explain more how this parameter works? Does it add an angle tolerance to the direction (± 20°)?
Some routers have a seed parameter to get different tours. See the GraphHopper documentation.
Is this something to consider for BRouter or it generates the same route for the same parameters?
roundtripDistance - distance from start point (default 1500m)
@afischerdev What is this distance? Not length of the route (as in other routers)? Distance of the start point from the longest point of the route or something else?
@devemux86
Does it add an angle tolerance to the direction (± 20°)?
may be better: It replaces the default of 20 with e.g. 45 degree.
Is this something to consider for BRouter or it generates the same route for the same parameters?
Both are correct.
If you define a direction of 180 degrees, it will be used for all calls.
If you do not define the direction value, however, a random direction will be generated. Therefore, you will get different routes for each call with the same parameter.
@devemux86
What is this distance?
We have two via point and this is the distance start point to via point.
Is it also available in BRouter test server?
No, I could port it, but we currently don't have a web client that could take advantage of this new feature. May be later on ;-)
direction - angle around start point (default random) roundtripDirectionAdd - changes the angle added to the direction (default 20 degrees)
@afischerdev So, if we set direction 90 degrees, why would we want to use roundtripDirectionAdd and change the direction again to a different value?
@devemux86
why would we want to use roundtripDirectionAdd
The direction is something like a main angle we want to place the route. E.g. North of parking space
But we want to have a more or less round trip and with the roundtripDirectionAdd we open the left and right area of the direction.
Please see:
with the
roundtripDirectionAddwe open the left and right area of the direction.
@afischerdev Thanks, also for the image, now it is clear! :+1:
allowSamewayback - go back the same way (default false)
@afischerdev It would be interesting if the allowSamewayback option could also be available outside of round trips in normal route planning.
direction 360, correctMisplacedViaPoints on
@afischerdev What correctMisplacedViaPointsDistance did you use in the 3rd image?
Even if we use a large correctMisplacedViaPointsDistance, we may have via points that go back and forth on the same road with u-turns that we want to avoid.
Is it because the distance is a strict requirement in the calculation? Or can calculate a bit longer round trips and avoid such u-turns?
Even if we use a large
correctMisplacedViaPointsDistance, we may have via points that go back and forth on the same road with u-turns that we want to avoid.
@afischerdev I mean if we can avoid round trips like the following with u-turns on the via points:
@devemux86
It would be interesting if the allowSamewayback option could also be available outside of round trips in normal route planning.
Yes, I'll prepare that.
Even if we use a large correctMisplacedViaPointsDistance, we may have via points that go back and forth on the same road with u-turns that we want to avoid.
Yes, these routes doesn't look very well. I used correctMisplacedViaPointsDistance=0 to disable the distance check.
But it is also dependent on MAX_STEPS_CHECK. I set that to 20 point, but could change that again.
At the moment I am trying to find the optimal setting, e.g. 20deg add angle.
Some mere results:
The current version (add angle = 20, no misplaced correction) produces this routes (direction 0 to 315, step 45 deg):
the new version runs with an add angle of 45, missplaced correction and a nogo point in angles center
Not perfect but a little bit better results.
Source coming soon. I will change the new same way back function.
I'm really looking forward to this feature. I use it a lot in Garmin Connect (Web) and directly on my Garmin Edge device to just go for a new lap of running or cycling without worrying too much about the details of the route. My use case: I want to go for a 20km run/ride, start and finish are the same, give me a route that goes in a circle.
I actually asked about this feature @mjaschen last autumn (in German): https://en.osm.town/@mcliquid/113517162799095813
One thing that we could learn from Garmin (actually Strava used to offer this feature, but it's no longer available) is to take elevation into account. Where I live, I have very steep mountains on one side and a wide valley on the other. Garmin often chooses the mountainous route because there are more suitable paths (no traffic, no traffic lights, etc.) but with extreme elevation changes. For a run, I would prefer to have it as flat as possible. The Strava elevation setting is shown in this video at 0:34: https://www.youtube.com/watch?v=CWdYhHsFNqk&t=34s
trailrouter.com has actually a few settings, including the elevation setting. See also their help page.
My technical experience is probably not enough to install BRouter local and test it, but as soon as there is a beta available, I would be very happy to volunteer as a tester!
The last commits enabled a same way back function for both: normal routing and round trip routing. This will also work when via points are used. But it doesn't necessarily have to be the same route back. And it changes the defaults: angle add 45 deg, more points to go back a line (snapp when two lines are concatenated).
@mcliquid Thanks for your suggestion.
- route length limit: BRouter works for roundtrip with a distance and a direction to start. I think it could be client function to calculate the distance for BRouter with e.g. desired length / pi.
- use elevation: I guess you already be able to generate with the current profiles a less steep route.
@afischerdev I tried the allowSamewayback in normal routing and it seems to do strange things.
allowSamewayback=1 should be like the old routing where we allow the same way back. Then allowSamewayback=0 is the new option we meant to implement in normal routing. But checking the code if allowSamewayback=1 then it adds no-go areas. Should be reverse?
@afischerdev Also it seems the waypoints (by user) are modified by the routing engine?
e.g. we have 2 user waypoints Start + End on a highway with distance a few kilometers.
In RoutingEngine line 207 a new waypoint (with radius) is added with the start's coordinates.
So the route goes start > end > start with the double length of the expected route.
@devemux86
allowSamewayback=1 should be like the old routing where we allow the same way back. Then allowSamewayback=0 is the new option we meant to implement in normal routing.
May be I didn't understand allowSamewayback.
My idea was to go back a route, that means we have waypoints at start
wp from
wp to
with same way back on we have
wp from
wp via1 (the old 'to')
wp to (same as from)
if allowSamewayback=1 then it adds no-go areas
No, the nogo point is added only for roundtrip.
My idea was to go back a route
Sorry, that's not what I meant.
What I mean is an option that in normal routing can avoid using the same roads. For example in above image, it does not u-turn but continues forward and returns through a different road.
@afischerdev What is a waypoint with radius but with isNogo false?
If it is not a no-go, what is it?
@devemux86
avoid using the same roads
This is done by using
profile:correctMisplacedViaPoints=1 - switch the check on
profile:correctMisplacedViaPointsDistance=250 - stops going back on around 250 m, =0 don't stop, the limit for go back points is at the moment MAX_STEPS_CHECK = 250
allowSamewayback=1 - Ok, if not like, just don't use.
@devemux86
What is a waypoint with radius but with isNogo false? If it is not a no-go, what is it?
The standard for a waypoint is isNogo=false. Please see the OsmNodeNamed
This class is used for both nogo and not nogo points. And we start with a list of OsmNodeNamed for the waypoint collection.
@afischerdev So the recommendation when generating round trips is the following?
profile:correctMisplacedViaPoints=1
profile:correctMisplacedViaPointsDistance=250
@mcliquid I think I jumped to short with my answer. The profile can help with better route finding for elevation or 'green area'. But in this round trip calculation the random start brings you anywhere. And the profile has no chance to find a proper route when you start e.g. in an East direction and the forest is in the West.
The data for your wishes is available in the routing tiles. But they are only out when a route is calculated. This could mean that routing in all directions is necessary to find an optimum. I don't like that very much. So I hope to find a shorter way.
@devemux86
Yes, same rule as before. But I would use profile:correctMisplacedViaPointsDistance=0 to get out the maximum points.
When we try round trips on islands near the coastline, we could have result with straight lines.
@afischerdev I wonder if we can improve this case? For example, force the route on the roads.
@devemux86 This should bring better results. But it is not yet optimal. I hope with a 'green filter' it will start more in the North.
Last version:
New version
In this version I changed to a new function for finding travelling points. More like a semi circle, with 4 extra points and without nogo in center.
There is also an initial idea for a weighted starting direction for the round trips.
First build four points around the starting point.
Then create a route between these points to get the route segments and description - just first path finding is enough.
And collect some values from the description. Something like this (area direction, start point elevation, counted ways):
Area 90 210.5m ways 685
Area ways <50m 518 75%
Area ways <100m 634 92%
Area ways more 51 7%
Area ways green 294 42%
Area ways river 0 0%
Area 180 210.5m ways 745
Area ways <50m 451 60%
Area ways <100m 708 95%
Area ways more 37 4%
Area ways green 336 45%
Area ways river 0 0%
Area 270 210.5m ways 967
Area ways <50m 546 56%
Area ways <100m 957 98%
Area ways more 10 1%
Area ways green 533 55%
Area ways river 634 65%
Area 360 210.5m ways 751
Area ways <50m 636 84%
Area ways <100m 751 100%
Area ways more 0 0%
Area ways green 369 49%
Area ways river 27 3%
Now play with the results. Looking for the user selected profile parameters, like consider_elevation, consider_forest, consider_river
This has its limits when working with the Azores example, the space becomes very tight.
All this works a little bit against timing. And I see a problem in keeping this data ready for the next routing call and not calling the tests again.
More work is needed, so no source here at the moment. Ideas are welcome.