Hi all, attached is v3, only small changes: 1) the message "maybe duplicated OSM way " was printed too often 2) with --x-cycle-map, change the headings at junctions with only three different arcs so that angles of 90° or more are created. If I hear no complains I'll commit this patch on monday, probably without the --x-fix-sharp-angles switch. I am still trying to work out in what case the Garmin routing algo prefers a detour, so maybe I find more improvements later. Ciao, Gerd
Well - I guess this will never be without errors - with Patch v3 there is again a little loop - now again at the first place: (only happens with "Shorter Distance" and one of the driving/motorcycle/Dirtbike and so on profiles..). Also on some other places still detours - in general "Shorter Distance" seems to be much more problematic than "faster time". So for sharp turns - ironically - shorter distance chooses the detour to avoid the sharp turn. I'm not really sure patch v3 is better than v2 however. Results are 50/50 better/worse. However the arrival times got a bit slower (even if following exactly the same route). I always tried with --x-cycle-map switch - never without. I'm still not so sure what this option really changes for outcome in the end. So - additional intersection roads would still be king IMHO... (but yes I know - not possible). On 04.09.2015 19:34, Gerd Petermann wrote:
Hi all,
attached is v3, only small changes: 1) the message "maybe duplicated OSM way " was printed too often 2) with --x-cycle-map, change the headings at junctions with only three different arcs so that angles of 90° or more are created.
If I hear no complains I'll commit this patch on monday, probably without the --x-fix-sharp-angles switch.
I am still trying to work out in what case the Garmin routing algo prefers a detour, so maybe I find more improvements later.
Ciao, Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
Hi Felix, okay, I came to similar results with other styles today, so maybe I'll revert the change that makes most angles larger. Reg- --x-cycle-map: Without it only angles < 45° are changed to 45°. With it and v2, angles were changed to 68° when road speed of an arc is >= 3 and 90° when road_speed >= 5. With it and v3, all angles < 90 are changed at junctions with only 3 directions. I think the Garmin algo is not really able to handle multiple arcs with that your style creates, at least it doesn't seem to "look" at all of them, esp. the last part of a route seems always to use the "topmost" road, means, the one that was last added in the style (as long as the selected vehicle is allowed). I think we first have to understand how the Garmin algo works before we can try to manipulate the data for better results. This is time consuming and error prone, so I'll need a few more days to work out facts. Gerd Felix Hartmann-2 wrote
Well - I guess this will never be without errors - with Patch v3 there is again a little loop - now again at the first place:
(only happens with "Shorter Distance" and one of the driving/motorcycle/Dirtbike and so on profiles..).
Also on some other places still detours - in general "Shorter Distance" seems to be much more problematic than "faster time". So for sharp turns - ironically - shorter distance chooses the detour to avoid the sharp turn.
I'm not really sure patch v3 is better than v2 however. Results are 50/50 better/worse. However the arrival times got a bit slower (even if following exactly the same route). I always tried with --x-cycle-map switch - never without. I'm still not so sure what this option really changes for outcome in the end. So - additional intersection roads would still be king IMHO... (but yes I know - not possible).
On 04.09.2015 19:34, Gerd Petermann wrote:
Hi all,
attached is v3, only small changes: 1) the message "maybe duplicated OSM way " was printed too often 2) with --x-cycle-map, change the headings at junctions with only three different arcs so that angles of 90° or more are created.
If I hear no complains I'll commit this patch on monday, probably without the --x-fix-sharp-angles switch.
I am still trying to work out in what case the Garmin routing algo prefers a detour, so maybe I find more improvements later.
Ciao, Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- keep on biking and discovering new trails
Felix openmtbmap.org & www.velomap.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
ajjdjdgb.png (24K) <http://gis.19327.n5.nabble.com/attachment/5854037/0/ajjdjdgb.png>;
-- View this message in context: http://gis.19327.n5.nabble.com/Patch-v3-sharp-angles-tp5853996p5854043.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Yes - I think for the start and end of a route - the algo will choose topmost route only. For inbetween sections however not - there it chooses the best - at least according to my tests a few years ago... There is a max of 6 or 7 roads lying on top of each other - if more it will produce a routing error and not go there at all. And yeah - I also don't know what's best. V2 seemed best to me so far. On 5 September 2015 at 15:09, GerdP <gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
okay, I came to similar results with other styles today, so maybe I'll revert the change that makes most angles larger.
Reg- --x-cycle-map: Without it only angles < 45° are changed to 45°. With it and v2, angles were changed to 68° when road speed of an arc is >= 3 and 90° when road_speed >= 5. With it and v3, all angles < 90 are changed at junctions with only 3 directions.
I think the Garmin algo is not really able to handle multiple arcs with that your style creates, at least it doesn't seem to "look" at all of them, esp. the last part of a route seems always to use the "topmost" road, means, the one that was last added in the style (as long as the selected vehicle is allowed). I think we first have to understand how the Garmin algo works before we can try to manipulate the data for better results. This is time consuming and error prone, so I'll need a few more days to work out facts.
Gerd
Felix Hartmann-2 wrote
Well - I guess this will never be without errors - with Patch v3 there is again a little loop - now again at the first place:
(only happens with "Shorter Distance" and one of the driving/motorcycle/Dirtbike and so on profiles..).
Also on some other places still detours - in general "Shorter Distance" seems to be much more problematic than "faster time". So for sharp turns - ironically - shorter distance chooses the detour to avoid the sharp turn.
I'm not really sure patch v3 is better than v2 however. Results are 50/50 better/worse. However the arrival times got a bit slower (even if following exactly the same route). I always tried with --x-cycle-map switch - never without. I'm still not so sure what this option really changes for outcome in the end. So - additional intersection roads would still be king IMHO... (but yes I know - not possible).
On 04.09.2015 19:34, Gerd Petermann wrote:
Hi all,
attached is v3, only small changes: 1) the message "maybe duplicated OSM way " was printed too often 2) with --x-cycle-map, change the headings at junctions with only three different arcs so that angles of 90° or more are created.
If I hear no complains I'll commit this patch on monday, probably without the --x-fix-sharp-angles switch.
I am still trying to work out in what case the Garmin routing algo prefers a detour, so maybe I find more improvements later.
Ciao, Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- keep on biking and discovering new trails
Felix openmtbmap.org & www.velomap.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
ajjdjdgb.png (24K) <http://gis.19327.n5.nabble.com/attachment/5854037/0/ajjdjdgb.png>
-- View this message in context: http://gis.19327.n5.nabble.com/Patch-v3-sharp-angles-tp5853996p5854043.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich
Hi Felix, I think I found some more rules, but I still need more tests before I can code a new fix. I found at least two errors in the v2 + v3 patch, not sure if they cause harm or if they just prevent good results. One was in the highest speed calculation, the other in the calculation of the needed heading change (some angles were not enlarged, others were enlarged too much) Here is what I learned so far: 1) The time penalty for a turn depends on the angle and the sum of the road speed values of the arcs which are used. (I thought that I have to look at the maximum (or minimum)) 2) the sum of speeds gives a factor which is mulitplied with a value that depends on the angle. The threshold values for the sum of speeds: 0,1 : 0 2,3 : 1 4,5 : 2 ... 12..13: 6 14: 7 2) penalties (for a car) are steps of 60s for angles below 22.5° (0s, 60 s, 120 s, 180s, ...,420s) steps of 12s for angles > 22.5 and below 45 (0s ,12s , ..., 84s) steps of 6s for angles > 45 and below 67.5 (0s, 6s, ...42s) steps of 3s for angles > 67.5 and below 90 (0s, 3s, ..., 21s) 3) The penalty is always completely added to the travel time of the 2nd arc. TODO: - The above values are for a right turn in a drive-on-right area. I still have to check left turns. - I also have to measure the effect on bicycle routing and maybe other vehicles - The effect of multiple arcs. They have an effect on the precision of the stored heading values. Not sure how this changes the results. I guess that Garmin will only use an arc with a high speed when that is long enough so that the higher speed weights out the penalty . A few tests show that it typically prefers the slower roads at the junction with the sharp angle, and "jumps" on the faster road at the next node. If you think that I should also look at other parameters, please let me know. Gerd Date: Sat, 5 Sep 2015 15:17:17 +0200 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v3] sharp angles Yes - I think for the start and end of a route - the algo will choose topmost route only. For inbetween sections however not - there it chooses the best - at least according to my tests a few years ago... There is a max of 6 or 7 roads lying on top of each other - if more it will produce a routing error and not go there at all. And yeah - I also don't know what's best. V2 seemed best to me so far. On 5 September 2015 at 15:09, GerdP <gpetermann_muenchen@hotmail.com> wrote: Hi Felix, okay, I came to similar results with other styles today, so maybe I'll revert the change that makes most angles larger. Reg- --x-cycle-map: Without it only angles < 45° are changed to 45°. With it and v2, angles were changed to 68° when road speed of an arc is >= 3 and 90° when road_speed >= 5. With it and v3, all angles < 90 are changed at junctions with only 3 directions. I think the Garmin algo is not really able to handle multiple arcs with that your style creates, at least it doesn't seem to "look" at all of them, esp. the last part of a route seems always to use the "topmost" road, means, the one that was last added in the style (as long as the selected vehicle is allowed). I think we first have to understand how the Garmin algo works before we can try to manipulate the data for better results. This is time consuming and error prone, so I'll need a few more days to work out facts. Gerd Felix Hartmann-2 wrote
Well - I guess this will never be without errors - with Patch v3 there
is again a little loop - now again at the first place:
(only happens with "Shorter Distance" and one of the
driving/motorcycle/Dirtbike and so on profiles..).
Also on some other places still detours - in general "Shorter Distance"
seems to be much more problematic than "faster time". So for sharp turns
- ironically - shorter distance chooses the detour to avoid the sharp
turn.
I'm not really sure patch v3 is better than v2 however. Results are
50/50 better/worse. However the arrival times got a bit slower (even if
following exactly the same route). I always tried with --x-cycle-map
switch - never without. I'm still not so sure what this option really
changes for outcome in the end.
So - additional intersection roads would still be king IMHO... (but yes
I know - not possible).
On 04.09.2015 19:34, Gerd Petermann wrote:
Hi all,
attached is v3, only small changes:
1) the message "maybe duplicated OSM way " was printed too often
2) with --x-cycle-map, change the headings
at junctions with only three different arcs so that angles of 90° or more
are created.
If I hear no complains I'll commit this patch on monday,
probably without the --x-fix-sharp-angles switch.
I am still trying to work out in what case the Garmin routing algo
prefers a detour, so maybe I find more improvements later.
Ciao,
Gerd
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@.org
--
keep on biking and discovering new trails
Felix
openmtbmap.org & www.velomap.org
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@.org
ajjdjdgb.png (24K)
<http://gis.19327.n5.nabble.com/attachment/5854037/0/ajjdjdgb.png>
-- View this message in context: http://gis.19327.n5.nabble.com/Patch-v3-sharp-angles-tp5853996p5854043.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Oh wow - I never did it so scientific. I just changed angles a bit or changed roadspeed and looked at the effect. One problem is that even if using faster time - time is not everything - at least for longer routes. But so it seems - angles below 22.5° should really be avoided. However I'm not sure if it is really good to change all angles so that they are 45° at least - even in nature I would guess in general a route will not take too many of them. Maybe dropping roadspeed by -1 for angles 22.5-45° if unavoidable would be better than changing the angle? On 7 September 2015 at 08:20, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I think I found some more rules, but I still need more tests before I can code a new fix. I found at least two errors in the v2 + v3 patch, not sure if they cause harm or if they just prevent good results. One was in the highest speed calculation, the other in the calculation of the needed heading change (some angles were not enlarged, others were enlarged too much)
Here is what I learned so far: 1) The time penalty for a turn depends on the angle and the sum of the road speed values of the arcs which are used. (I thought that I have to look at the maximum (or minimum)) 2) the sum of speeds gives a factor which is mulitplied with a value that depends on the angle. The threshold values for the sum of speeds: 0,1 : 0 2,3 : 1 4,5 : 2 ... 12..13: 6 14: 7 2) penalties (for a car) are steps of 60s for angles below 22.5° (0s, 60 s, 120 s, 180s, ...,420s) steps of 12s for angles > 22.5 and below 45 (0s ,12s , ..., 84s) steps of 6s for angles > 45 and below 67.5 (0s, 6s, ...42s) steps of 3s for angles > 67.5 and below 90 (0s, 3s, ..., 21s)
3) The penalty is always completely added to the travel time of the 2nd arc.
TODO: - The above values are for a right turn in a drive-on-right area. I still have to check left turns. - I also have to measure the effect on bicycle routing and maybe other vehicles - The effect of multiple arcs. They have an effect on the precision of the stored heading values. Not sure how this changes the results. I guess that Garmin will only use an arc with a high speed when that is long enough so that the higher speed weights out the penalty . A few tests show that it typically prefers the slower roads at the junction with the sharp angle, and "jumps" on the faster road at the next node.
If you think that I should also look at other parameters, please let me know. Gerd
------------------------------ Date: Sat, 5 Sep 2015 15:17:17 +0200 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v3] sharp angles
Yes - I think for the start and end of a route - the algo will choose topmost route only. For inbetween sections however not - there it chooses the best - at least according to my tests a few years ago... There is a max of 6 or 7 roads lying on top of each other - if more it will produce a routing error and not go there at all.
And yeah - I also don't know what's best. V2 seemed best to me so far.
On 5 September 2015 at 15:09, GerdP <gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
okay, I came to similar results with other styles today, so maybe I'll revert the change that makes most angles larger.
Reg- --x-cycle-map: Without it only angles < 45° are changed to 45°. With it and v2, angles were changed to 68° when road speed of an arc is >= 3 and 90° when road_speed >= 5. With it and v3, all angles < 90 are changed at junctions with only 3 directions.
I think the Garmin algo is not really able to handle multiple arcs with that your style creates, at least it doesn't seem to "look" at all of them, esp. the last part of a route seems always to use the "topmost" road, means, the one that was last added in the style (as long as the selected vehicle is allowed). I think we first have to understand how the Garmin algo works before we can try to manipulate the data for better results. This is time consuming and error prone, so I'll need a few more days to work out facts.
Gerd
Felix Hartmann-2 wrote
Well - I guess this will never be without errors - with Patch v3 there is again a little loop - now again at the first place:
(only happens with "Shorter Distance" and one of the driving/motorcycle/Dirtbike and so on profiles..).
Also on some other places still detours - in general "Shorter Distance" seems to be much more problematic than "faster time". So for sharp turns - ironically - shorter distance chooses the detour to avoid the sharp turn.
I'm not really sure patch v3 is better than v2 however. Results are 50/50 better/worse. However the arrival times got a bit slower (even if following exactly the same route). I always tried with --x-cycle-map switch - never without. I'm still not so sure what this option really changes for outcome in the end. So - additional intersection roads would still be king IMHO... (but yes I know - not possible).
On 04.09.2015 19:34, Gerd Petermann wrote:
Hi all,
attached is v3, only small changes: 1) the message "maybe duplicated OSM way " was printed too often 2) with --x-cycle-map, change the headings at junctions with only three different arcs so that angles of 90° or more are created.
If I hear no complains I'll commit this patch on monday, probably without the --x-fix-sharp-angles switch.
I am still trying to work out in what case the Garmin routing algo prefers a detour, so maybe I find more improvements later.
Ciao, Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- keep on biking and discovering new trails
Felix openmtbmap.org & www.velomap.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
ajjdjdgb.png (24K) <http://gis.19327.n5.nabble.com/attachment/5854037/0/ajjdjdgb.png>
-- View this message in context: http://gis.19327.n5.nabble.com/Patch-v3-sharp-angles-tp5853996p5854043.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich
Oh - and one thing is sure. In Basecamp Dirt-Bike and ATV have the same penalties as driving - but the algo differs quite a lot. For "difficult" long routes - it works much better than driving. Driving seems to have some hidden preference really for long straight highway type of drives... On 7 September 2015 at 09:32, Felix Hartmann <extremecarver@gmail.com> wrote:
Oh wow - I never did it so scientific. I just changed angles a bit or changed roadspeed and looked at the effect. One problem is that even if using faster time - time is not everything - at least for longer routes. But so it seems - angles below 22.5° should really be avoided. However I'm not sure if it is really good to change all angles so that they are 45° at least - even in nature I would guess in general a route will not take too many of them. Maybe dropping roadspeed by -1 for angles 22.5-45° if unavoidable would be better than changing the angle?
On 7 September 2015 at 08:20, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I think I found some more rules, but I still need more tests before I can code a new fix. I found at least two errors in the v2 + v3 patch, not sure if they cause harm or if they just prevent good results. One was in the highest speed calculation, the other in the calculation of the needed heading change (some angles were not enlarged, others were enlarged too much)
Here is what I learned so far: 1) The time penalty for a turn depends on the angle and the sum of the road speed values of the arcs which are used. (I thought that I have to look at the maximum (or minimum)) 2) the sum of speeds gives a factor which is mulitplied with a value that depends on the angle. The threshold values for the sum of speeds: 0,1 : 0 2,3 : 1 4,5 : 2 ... 12..13: 6 14: 7 2) penalties (for a car) are steps of 60s for angles below 22.5° (0s, 60 s, 120 s, 180s, ...,420s) steps of 12s for angles > 22.5 and below 45 (0s ,12s , ..., 84s) steps of 6s for angles > 45 and below 67.5 (0s, 6s, ...42s) steps of 3s for angles > 67.5 and below 90 (0s, 3s, ..., 21s)
3) The penalty is always completely added to the travel time of the 2nd arc.
TODO: - The above values are for a right turn in a drive-on-right area. I still have to check left turns. - I also have to measure the effect on bicycle routing and maybe other vehicles - The effect of multiple arcs. They have an effect on the precision of the stored heading values. Not sure how this changes the results. I guess that Garmin will only use an arc with a high speed when that is long enough so that the higher speed weights out the penalty . A few tests show that it typically prefers the slower roads at the junction with the sharp angle, and "jumps" on the faster road at the next node.
If you think that I should also look at other parameters, please let me know. Gerd
------------------------------ Date: Sat, 5 Sep 2015 15:17:17 +0200 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v3] sharp angles
Yes - I think for the start and end of a route - the algo will choose topmost route only. For inbetween sections however not - there it chooses the best - at least according to my tests a few years ago... There is a max of 6 or 7 roads lying on top of each other - if more it will produce a routing error and not go there at all.
And yeah - I also don't know what's best. V2 seemed best to me so far.
On 5 September 2015 at 15:09, GerdP <gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
okay, I came to similar results with other styles today, so maybe I'll revert the change that makes most angles larger.
Reg- --x-cycle-map: Without it only angles < 45° are changed to 45°. With it and v2, angles were changed to 68° when road speed of an arc is
= 3 and 90° when road_speed >= 5. With it and v3, all angles < 90 are changed at junctions with only 3 directions.
I think the Garmin algo is not really able to handle multiple arcs with that your style creates, at least it doesn't seem to "look" at all of them, esp. the last part of a route seems always to use the "topmost" road, means, the one that was last added in the style (as long as the selected vehicle is allowed). I think we first have to understand how the Garmin algo works before we can try to manipulate the data for better results. This is time consuming and error prone, so I'll need a few more days to work out facts.
Gerd
Felix Hartmann-2 wrote
Well - I guess this will never be without errors - with Patch v3 there is again a little loop - now again at the first place:
(only happens with "Shorter Distance" and one of the driving/motorcycle/Dirtbike and so on profiles..).
Also on some other places still detours - in general "Shorter Distance" seems to be much more problematic than "faster time". So for sharp turns - ironically - shorter distance chooses the detour to avoid the sharp turn.
I'm not really sure patch v3 is better than v2 however. Results are 50/50 better/worse. However the arrival times got a bit slower (even if following exactly the same route). I always tried with --x-cycle-map switch - never without. I'm still not so sure what this option really changes for outcome in the end. So - additional intersection roads would still be king IMHO... (but yes I know - not possible).
On 04.09.2015 19:34, Gerd Petermann wrote:
Hi all,
attached is v3, only small changes: 1) the message "maybe duplicated OSM way " was printed too often 2) with --x-cycle-map, change the headings at junctions with only three different arcs so that angles of 90° or more are created.
If I hear no complains I'll commit this patch on monday, probably without the --x-fix-sharp-angles switch.
I am still trying to work out in what case the Garmin routing algo prefers a detour, so maybe I find more improvements later.
Ciao, Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- keep on biking and discovering new trails
Felix openmtbmap.org & www.velomap.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
ajjdjdgb.png (24K) <http://gis.19327.n5.nabble.com/attachment/5854037/0/ajjdjdgb.png>
-- View this message in context: http://gis.19327.n5.nabble.com/Patch-v3-sharp-angles-tp5853996p5854043.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich
Hi Felix, forgot to mention that I found no prove that the road class has an impact on the penalty, in other words: I found no relation between road class and calculated travel time when the road speed is the same. Maybe this is different for longer routes, my test contains just for arcs with the 2nd and 3rd building the sharp angle. My test scenario doesn't allow to use other roads. Reg. different vehicles: I guess that they have different preferences regarding paved/unpaved roads, maybe also regarding road class. And maybe the penalties differ also. I'm now working out how the left turns differ from right turns. Gerd Date: Mon, 7 Sep 2015 09:33:56 +0200 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v3] sharp angles Oh - and one thing is sure. In Basecamp Dirt-Bike and ATV have the same penalties as driving - but the algo differs quite a lot. For "difficult" long routes - it works much better than driving. Driving seems to have some hidden preference really for long straight highway type of drives... On 7 September 2015 at 09:32, Felix Hartmann <extremecarver@gmail.com> wrote: Oh wow - I never did it so scientific. I just changed angles a bit or changed roadspeed and looked at the effect. One problem is that even if using faster time - time is not everything - at least for longer routes. But so it seems - angles below 22.5° should really be avoided. However I'm not sure if it is really good to change all angles so that they are 45° at least - even in nature I would guess in general a route will not take too many of them. Maybe dropping roadspeed by -1 for angles 22.5-45° if unavoidable would be better than changing the angle? On 7 September 2015 at 08:20, Gerd Petermann <gpetermann_muenchen@hotmail.com> wrote: Hi Felix, I think I found some more rules, but I still need more tests before I can code a new fix. I found at least two errors in the v2 + v3 patch, not sure if they cause harm or if they just prevent good results. One was in the highest speed calculation, the other in the calculation of the needed heading change (some angles were not enlarged, others were enlarged too much) Here is what I learned so far: 1) The time penalty for a turn depends on the angle and the sum of the road speed values of the arcs which are used. (I thought that I have to look at the maximum (or minimum)) 2) the sum of speeds gives a factor which is mulitplied with a value that depends on the angle. The threshold values for the sum of speeds: 0,1 : 0 2,3 : 1 4,5 : 2 ... 12..13: 6 14: 7 2) penalties (for a car) are steps of 60s for angles below 22.5° (0s, 60 s, 120 s, 180s, ...,420s) steps of 12s for angles > 22.5 and below 45 (0s ,12s , ..., 84s) steps of 6s for angles > 45 and below 67.5 (0s, 6s, ...42s) steps of 3s for angles > 67.5 and below 90 (0s, 3s, ..., 21s) 3) The penalty is always completely added to the travel time of the 2nd arc. TODO: - The above values are for a right turn in a drive-on-right area. I still have to check left turns. - I also have to measure the effect on bicycle routing and maybe other vehicles - The effect of multiple arcs. They have an effect on the precision of the stored heading values. Not sure how this changes the results. I guess that Garmin will only use an arc with a high speed when that is long enough so that the higher speed weights out the penalty . A few tests show that it typically prefers the slower roads at the junction with the sharp angle, and "jumps" on the faster road at the next node. If you think that I should also look at other parameters, please let me know. Gerd Date: Sat, 5 Sep 2015 15:17:17 +0200 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v3] sharp angles Yes - I think for the start and end of a route - the algo will choose topmost route only. For inbetween sections however not - there it chooses the best - at least according to my tests a few years ago... There is a max of 6 or 7 roads lying on top of each other - if more it will produce a routing error and not go there at all. And yeah - I also don't know what's best. V2 seemed best to me so far. On 5 September 2015 at 15:09, GerdP <gpetermann_muenchen@hotmail.com> wrote: Hi Felix, okay, I came to similar results with other styles today, so maybe I'll revert the change that makes most angles larger. Reg- --x-cycle-map: Without it only angles < 45° are changed to 45°. With it and v2, angles were changed to 68° when road speed of an arc is >= 3 and 90° when road_speed >= 5. With it and v3, all angles < 90 are changed at junctions with only 3 directions. I think the Garmin algo is not really able to handle multiple arcs with that your style creates, at least it doesn't seem to "look" at all of them, esp. the last part of a route seems always to use the "topmost" road, means, the one that was last added in the style (as long as the selected vehicle is allowed). I think we first have to understand how the Garmin algo works before we can try to manipulate the data for better results. This is time consuming and error prone, so I'll need a few more days to work out facts. Gerd Felix Hartmann-2 wrote
Well - I guess this will never be without errors - with Patch v3 there
is again a little loop - now again at the first place:
(only happens with "Shorter Distance" and one of the
driving/motorcycle/Dirtbike and so on profiles..).
Also on some other places still detours - in general "Shorter Distance"
seems to be much more problematic than "faster time". So for sharp turns
- ironically - shorter distance chooses the detour to avoid the sharp
turn.
I'm not really sure patch v3 is better than v2 however. Results are
50/50 better/worse. However the arrival times got a bit slower (even if
following exactly the same route). I always tried with --x-cycle-map
switch - never without. I'm still not so sure what this option really
changes for outcome in the end.
So - additional intersection roads would still be king IMHO... (but yes
I know - not possible).
On 04.09.2015 19:34, Gerd Petermann wrote:
Hi all,
attached is v3, only small changes:
1) the message "maybe duplicated OSM way " was printed too often
2) with --x-cycle-map, change the headings
at junctions with only three different arcs so that angles of 90° or more
are created.
If I hear no complains I'll commit this patch on monday,
probably without the --x-fix-sharp-angles switch.
I am still trying to work out in what case the Garmin routing algo
prefers a detour, so maybe I find more improvements later.
Ciao,
Gerd
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@.org
--
keep on biking and discovering new trails
Felix
openmtbmap.org & www.velomap.org
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@.org
ajjdjdgb.png (24K)
<http://gis.19327.n5.nabble.com/attachment/5854037/0/ajjdjdgb.png>
-- View this message in context: http://gis.19327.n5.nabble.com/Patch-v3-sharp-angles-tp5853996p5854043.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich -- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Yes - there is no different time penalty based on road class. It's just that motorcar is much more focusing on them than any other mode and I would guess besides the penalties there are some other factors that only start to be considered on longer routes. And most of the difference for vehicles only appear on longer distances - which makes assessing differences really difficult. On 7 September 2015 at 11:20, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
forgot to mention that I found no prove that the road class has an impact on the penalty, in other words: I found no relation between road class and calculated travel time when the road speed is the same. Maybe this is different for longer routes, my test contains just for arcs with the 2nd and 3rd building the sharp angle. My test scenario doesn't allow to use other roads.
Reg. different vehicles: I guess that they have different preferences regarding paved/unpaved roads, maybe also regarding road class. And maybe the penalties differ also.
I'm now working out how the left turns differ from right turns.
Gerd
------------------------------ Date: Mon, 7 Sep 2015 09:33:56 +0200
From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v3] sharp angles
Oh - and one thing is sure. In Basecamp Dirt-Bike and ATV have the same penalties as driving - but the algo differs quite a lot. For "difficult" long routes - it works much better than driving. Driving seems to have some hidden preference really for long straight highway type of drives...
On 7 September 2015 at 09:32, Felix Hartmann <extremecarver@gmail.com> wrote:
Oh wow - I never did it so scientific. I just changed angles a bit or changed roadspeed and looked at the effect. One problem is that even if using faster time - time is not everything - at least for longer routes. But so it seems - angles below 22.5° should really be avoided. However I'm not sure if it is really good to change all angles so that they are 45° at least - even in nature I would guess in general a route will not take too many of them. Maybe dropping roadspeed by -1 for angles 22.5-45° if unavoidable would be better than changing the angle?
On 7 September 2015 at 08:20, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I think I found some more rules, but I still need more tests before I can code a new fix. I found at least two errors in the v2 + v3 patch, not sure if they cause harm or if they just prevent good results. One was in the highest speed calculation, the other in the calculation of the needed heading change (some angles were not enlarged, others were enlarged too much)
Here is what I learned so far: 1) The time penalty for a turn depends on the angle and the sum of the road speed values of the arcs which are used. (I thought that I have to look at the maximum (or minimum)) 2) the sum of speeds gives a factor which is mulitplied with a value that depends on the angle. The threshold values for the sum of speeds: 0,1 : 0 2,3 : 1 4,5 : 2 ... 12..13: 6 14: 7 2) penalties (for a car) are steps of 60s for angles below 22.5° (0s, 60 s, 120 s, 180s, ...,420s) steps of 12s for angles > 22.5 and below 45 (0s ,12s , ..., 84s) steps of 6s for angles > 45 and below 67.5 (0s, 6s, ...42s) steps of 3s for angles > 67.5 and below 90 (0s, 3s, ..., 21s)
3) The penalty is always completely added to the travel time of the 2nd arc.
TODO: - The above values are for a right turn in a drive-on-right area. I still have to check left turns. - I also have to measure the effect on bicycle routing and maybe other vehicles - The effect of multiple arcs. They have an effect on the precision of the stored heading values. Not sure how this changes the results. I guess that Garmin will only use an arc with a high speed when that is long enough so that the higher speed weights out the penalty . A few tests show that it typically prefers the slower roads at the junction with the sharp angle, and "jumps" on the faster road at the next node.
If you think that I should also look at other parameters, please let me know. Gerd
------------------------------ Date: Sat, 5 Sep 2015 15:17:17 +0200 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v3] sharp angles
Yes - I think for the start and end of a route - the algo will choose topmost route only. For inbetween sections however not - there it chooses the best - at least according to my tests a few years ago... There is a max of 6 or 7 roads lying on top of each other - if more it will produce a routing error and not go there at all.
And yeah - I also don't know what's best. V2 seemed best to me so far.
On 5 September 2015 at 15:09, GerdP <gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
okay, I came to similar results with other styles today, so maybe I'll revert the change that makes most angles larger.
Reg- --x-cycle-map: Without it only angles < 45° are changed to 45°. With it and v2, angles were changed to 68° when road speed of an arc is >= 3 and 90° when road_speed >= 5. With it and v3, all angles < 90 are changed at junctions with only 3 directions.
I think the Garmin algo is not really able to handle multiple arcs with that your style creates, at least it doesn't seem to "look" at all of them, esp. the last part of a route seems always to use the "topmost" road, means, the one that was last added in the style (as long as the selected vehicle is allowed). I think we first have to understand how the Garmin algo works before we can try to manipulate the data for better results. This is time consuming and error prone, so I'll need a few more days to work out facts.
Gerd
Felix Hartmann-2 wrote
Well - I guess this will never be without errors - with Patch v3 there is again a little loop - now again at the first place:
(only happens with "Shorter Distance" and one of the driving/motorcycle/Dirtbike and so on profiles..).
Also on some other places still detours - in general "Shorter Distance" seems to be much more problematic than "faster time". So for sharp turns - ironically - shorter distance chooses the detour to avoid the sharp turn.
I'm not really sure patch v3 is better than v2 however. Results are 50/50 better/worse. However the arrival times got a bit slower (even if following exactly the same route). I always tried with --x-cycle-map switch - never without. I'm still not so sure what this option really changes for outcome in the end. So - additional intersection roads would still be king IMHO... (but yes I know - not possible).
On 04.09.2015 19:34, Gerd Petermann wrote:
Hi all,
attached is v3, only small changes: 1) the message "maybe duplicated OSM way " was printed too often 2) with --x-cycle-map, change the headings at junctions with only three different arcs so that angles of 90° or more are created.
If I hear no complains I'll commit this patch on monday, probably without the --x-fix-sharp-angles switch.
I am still trying to work out in what case the Garmin routing algo prefers a detour, so maybe I find more improvements later.
Ciao, Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- keep on biking and discovering new trails
Felix openmtbmap.org & www.velomap.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
ajjdjdgb.png (24K) <http://gis.19327.n5.nabble.com/attachment/5854037/0/ajjdjdgb.png>
-- View this message in context: http://gis.19327.n5.nabble.com/Patch-v3-sharp-angles-tp5853996p5854043.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich
Oh - I could not find out about any preference of avoidances yes/no. I am under the assumption paved/unpaved, toll yes/no and so on are really simply strict yes/no criteria - but otherwise irrelevant. On 7 September 2015 at 11:29, Felix Hartmann <extremecarver@gmail.com> wrote:
Yes - there is no different time penalty based on road class. It's just that motorcar is much more focusing on them than any other mode and I would guess besides the penalties there are some other factors that only start to be considered on longer routes. And most of the difference for vehicles only appear on longer distances - which makes assessing differences really difficult.
On 7 September 2015 at 11:20, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
forgot to mention that I found no prove that the road class has an impact on the penalty, in other words: I found no relation between road class and calculated travel time when the road speed is the same. Maybe this is different for longer routes, my test contains just for arcs with the 2nd and 3rd building the sharp angle. My test scenario doesn't allow to use other roads.
Reg. different vehicles: I guess that they have different preferences regarding paved/unpaved roads, maybe also regarding road class. And maybe the penalties differ also.
I'm now working out how the left turns differ from right turns.
Gerd
------------------------------ Date: Mon, 7 Sep 2015 09:33:56 +0200
From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v3] sharp angles
Oh - and one thing is sure. In Basecamp Dirt-Bike and ATV have the same penalties as driving - but the algo differs quite a lot. For "difficult" long routes - it works much better than driving. Driving seems to have some hidden preference really for long straight highway type of drives...
On 7 September 2015 at 09:32, Felix Hartmann <extremecarver@gmail.com> wrote:
Oh wow - I never did it so scientific. I just changed angles a bit or changed roadspeed and looked at the effect. One problem is that even if using faster time - time is not everything - at least for longer routes. But so it seems - angles below 22.5° should really be avoided. However I'm not sure if it is really good to change all angles so that they are 45° at least - even in nature I would guess in general a route will not take too many of them. Maybe dropping roadspeed by -1 for angles 22.5-45° if unavoidable would be better than changing the angle?
On 7 September 2015 at 08:20, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I think I found some more rules, but I still need more tests before I can code a new fix. I found at least two errors in the v2 + v3 patch, not sure if they cause harm or if they just prevent good results. One was in the highest speed calculation, the other in the calculation of the needed heading change (some angles were not enlarged, others were enlarged too much)
Here is what I learned so far: 1) The time penalty for a turn depends on the angle and the sum of the road speed values of the arcs which are used. (I thought that I have to look at the maximum (or minimum)) 2) the sum of speeds gives a factor which is mulitplied with a value that depends on the angle. The threshold values for the sum of speeds: 0,1 : 0 2,3 : 1 4,5 : 2 ... 12..13: 6 14: 7 2) penalties (for a car) are steps of 60s for angles below 22.5° (0s, 60 s, 120 s, 180s, ...,420s) steps of 12s for angles > 22.5 and below 45 (0s ,12s , ..., 84s) steps of 6s for angles > 45 and below 67.5 (0s, 6s, ...42s) steps of 3s for angles > 67.5 and below 90 (0s, 3s, ..., 21s)
3) The penalty is always completely added to the travel time of the 2nd arc.
TODO: - The above values are for a right turn in a drive-on-right area. I still have to check left turns. - I also have to measure the effect on bicycle routing and maybe other vehicles - The effect of multiple arcs. They have an effect on the precision of the stored heading values. Not sure how this changes the results. I guess that Garmin will only use an arc with a high speed when that is long enough so that the higher speed weights out the penalty . A few tests show that it typically prefers the slower roads at the junction with the sharp angle, and "jumps" on the faster road at the next node.
If you think that I should also look at other parameters, please let me know. Gerd
------------------------------ Date: Sat, 5 Sep 2015 15:17:17 +0200 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v3] sharp angles
Yes - I think for the start and end of a route - the algo will choose topmost route only. For inbetween sections however not - there it chooses the best - at least according to my tests a few years ago... There is a max of 6 or 7 roads lying on top of each other - if more it will produce a routing error and not go there at all.
And yeah - I also don't know what's best. V2 seemed best to me so far.
On 5 September 2015 at 15:09, GerdP <gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
okay, I came to similar results with other styles today, so maybe I'll revert the change that makes most angles larger.
Reg- --x-cycle-map: Without it only angles < 45° are changed to 45°. With it and v2, angles were changed to 68° when road speed of an arc is
= 3 and 90° when road_speed >= 5. With it and v3, all angles < 90 are changed at junctions with only 3 directions.
I think the Garmin algo is not really able to handle multiple arcs with that your style creates, at least it doesn't seem to "look" at all of them, esp. the last part of a route seems always to use the "topmost" road, means, the one that was last added in the style (as long as the selected vehicle is allowed). I think we first have to understand how the Garmin algo works before we can try to manipulate the data for better results. This is time consuming and error prone, so I'll need a few more days to work out facts.
Gerd
Felix Hartmann-2 wrote
Well - I guess this will never be without errors - with Patch v3 there is again a little loop - now again at the first place:
(only happens with "Shorter Distance" and one of the driving/motorcycle/Dirtbike and so on profiles..).
Also on some other places still detours - in general "Shorter Distance" seems to be much more problematic than "faster time". So for sharp turns - ironically - shorter distance chooses the detour to avoid the sharp turn.
I'm not really sure patch v3 is better than v2 however. Results are 50/50 better/worse. However the arrival times got a bit slower (even if following exactly the same route). I always tried with --x-cycle-map switch - never without. I'm still not so sure what this option really changes for outcome in the end. So - additional intersection roads would still be king IMHO... (but yes I know - not possible).
On 04.09.2015 19:34, Gerd Petermann wrote:
Hi all,
attached is v3, only small changes: 1) the message "maybe duplicated OSM way " was printed too often 2) with --x-cycle-map, change the headings at junctions with only three different arcs so that angles of 90° or more are created.
If I hear no complains I'll commit this patch on monday, probably without the --x-fix-sharp-angles switch.
I am still trying to work out in what case the Garmin routing algo prefers a detour, so maybe I find more improvements later.
Ciao, Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- keep on biking and discovering new trails
Felix openmtbmap.org & www.velomap.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
ajjdjdgb.png (24K) <http://gis.19327.n5.nabble.com/attachment/5854037/0/ajjdjdgb.png>
-- View this message in context: http://gis.19327.n5.nabble.com/Patch-v3-sharp-angles-tp5853996p5854043.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich
-- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich
Hi again, here are my findings for a left turn (in a drive-on-right map): 1) a left turn adds penalties to the travel time of one or both arcs 2) the penalty for the first arc is based on the road speed of that arc, it doesn't seem to depend on the angle road speed/penalty: 0-1: 6s 2-3: 12s 4-5: 18s 6-7: 24s 3) The penalty for the 2nd arc is more complex, it depends on road speeds and angle. For a car I found these: for angles below 22.5°: like a right turn for angles >= 22.5 and sum of speeds 0, 1: 1 s for angles >= 22.5 and sum of speeds > 1 : double value of a right turn (!) (Note that the real threshold values for the angles are integers after rounding) So, you see the max. penalty of 24s + 420s=444s for a left turn from a road speed 7 road to another road speed 7 road through a 20° angle. When that angle is changed to be 23°, the penalty is 24s + 2*84s = 192s. It is unlikely that Garmin selects such a route, it will most likely find a detour that is a "faster" way. I'll now try to find out if there is something special with the multiple arcs for one OSM way. Gerd From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Mon, 7 Sep 2015 08:20:45 +0200 Subject: Re: [mkgmap-dev] [Patch v3] sharp angles Hi Felix, I think I found some more rules, but I still need more tests before I can code a new fix. I found at least two errors in the v2 + v3 patch, not sure if they cause harm or if they just prevent good results. One was in the highest speed calculation, the other in the calculation of the needed heading change (some angles were not enlarged, others were enlarged too much) Here is what I learned so far: 1) The time penalty for a turn depends on the angle and the sum of the road speed values of the arcs which are used. (I thought that I have to look at the maximum (or minimum)) 2) the sum of speeds gives a factor which is mulitplied with a value that depends on the angle. The threshold values for the sum of speeds: 0,1 : 0 2,3 : 1 4,5 : 2 ... 12..13: 6 14: 7 2) penalties (for a car) are steps of 60s for angles below 22.5° (0s, 60 s, 120 s, 180s, ...,420s) steps of 12s for angles > 22.5 and below 45 (0s ,12s , ..., 84s) steps of 6s for angles > 45 and below 67.5 (0s, 6s, ...42s) steps of 3s for angles > 67.5 and below 90 (0s, 3s, ..., 21s) 3) The penalty is always completely added to the travel time of the 2nd arc. TODO: - The above values are for a right turn in a drive-on-right area. I still have to check left turns. - I also have to measure the effect on bicycle routing and maybe other vehicles - The effect of multiple arcs. They have an effect on the precision of the stored heading values. Not sure how this changes the results. I guess that Garmin will only use an arc with a high speed when that is long enough so that the higher speed weights out the penalty . A few tests show that it typically prefers the slower roads at the junction with the sharp angle, and "jumps" on the faster road at the next node. If you think that I should also look at other parameters, please let me know. Gerd Date: Sat, 5 Sep 2015 15:17:17 +0200 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v3] sharp angles Yes - I think for the start and end of a route - the algo will choose topmost route only. For inbetween sections however not - there it chooses the best - at least according to my tests a few years ago... There is a max of 6 or 7 roads lying on top of each other - if more it will produce a routing error and not go there at all. And yeah - I also don't know what's best. V2 seemed best to me so far. On 5 September 2015 at 15:09, GerdP <gpetermann_muenchen@hotmail.com> wrote: Hi Felix, okay, I came to similar results with other styles today, so maybe I'll revert the change that makes most angles larger. Reg- --x-cycle-map: Without it only angles < 45° are changed to 45°. With it and v2, angles were changed to 68° when road speed of an arc is >= 3 and 90° when road_speed >= 5. With it and v3, all angles < 90 are changed at junctions with only 3 directions. I think the Garmin algo is not really able to handle multiple arcs with that your style creates, at least it doesn't seem to "look" at all of them, esp. the last part of a route seems always to use the "topmost" road, means, the one that was last added in the style (as long as the selected vehicle is allowed). I think we first have to understand how the Garmin algo works before we can try to manipulate the data for better results. This is time consuming and error prone, so I'll need a few more days to work out facts. Gerd Felix Hartmann-2 wrote
Well - I guess this will never be without errors - with Patch v3 there
is again a little loop - now again at the first place:
(only happens with "Shorter Distance" and one of the
driving/motorcycle/Dirtbike and so on profiles..).
Also on some other places still detours - in general "Shorter Distance"
seems to be much more problematic than "faster time". So for sharp turns
- ironically - shorter distance chooses the detour to avoid the sharp
turn.
I'm not really sure patch v3 is better than v2 however. Results are
50/50 better/worse. However the arrival times got a bit slower (even if
following exactly the same route). I always tried with --x-cycle-map
switch - never without. I'm still not so sure what this option really
changes for outcome in the end.
So - additional intersection roads would still be king IMHO... (but yes
I know - not possible).
On 04.09.2015 19:34, Gerd Petermann wrote:
Hi all,
attached is v3, only small changes:
1) the message "maybe duplicated OSM way " was printed too often
2) with --x-cycle-map, change the headings
at junctions with only three different arcs so that angles of 90° or more
are created.
If I hear no complains I'll commit this patch on monday,
probably without the --x-fix-sharp-angles switch.
I am still trying to work out in what case the Garmin routing algo
prefers a detour, so maybe I find more improvements later.
Ciao,
Gerd
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@.org
--
keep on biking and discovering new trails
Felix
openmtbmap.org & www.velomap.org
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@.org
ajjdjdgb.png (24K)
<http://gis.19327.n5.nabble.com/attachment/5854037/0/ajjdjdgb.png>
-- View this message in context: http://gis.19327.n5.nabble.com/Patch-v3-sharp-angles-tp5853996p5854043.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (3)
-
Felix Hartmann -
Gerd Petermann -
GerdP