[mkgmap-dev] [Patch v3] sharp angles

Mon Sep 7 08:32:24 BST 2015

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 at 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 at gmail.com
> To: mkgmap-dev at 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 at 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 at .org
>
> >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
> > --
> > keep on biking and discovering new trails
> >
> > Felix
> > openmtbmap.org & www.velomap.org
> >
> >
> > _______________________________________________
> > mkgmap-dev mailing list
>
> > mkgmap-dev at .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 at 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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20150907/5cbdd4f2/attachment.html>