<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hi Felix,<br><br>I think I found some more rules, but I still need more tests<br>before I can code a new fix.<br>I found at least two errors in the v2 + v3 patch, not sure <br>if they cause harm or if they just prevent good results.<br>One was in the highest speed calculation, the other in the calculation <br>of the needed heading change (some angles were not enlarged, others<br>were enlarged too much)<br><br>Here is what I learned so far:<br>1) The time penalty for a turn depends on the angle and the sum of the <br>road speed values of the arcs which are used.<br>(I thought that I have to look at the maximum (or minimum))<br>2) the sum of speeds gives a factor which is mulitplied with a value that depends<br>on the angle. The threshold values for the sum of speeds:<br>0,1 : 0<br>2,3 : 1<br>4,5 : 2 <br>...<br>12..13: 6<br>14: 7<br>2) penalties (for a car) are <br>steps of 60s for angles below 22.5° (0s, 60 s, 120 s, 180s, ...,420s)<br>steps of 12s for angles > 22.5 and below 45 (0s ,12s , ..., 84s)<br>steps of 6s for angles > 45 and below 67.5 (0s, 6s, ...42s)<br>steps of 3s for angles > 67.5 and below 90 (0s, 3s, ..., 21s)<br><br>3) The penalty is always completely added to the travel time of the 2nd arc.<br><br>TODO:<br>- The above values are for a right turn in a drive-on-right area. I still have to <br>check left turns.<br>- I also have to measure the effect on bicycle routing and maybe other vehicles<br>- The effect of multiple arcs. They have an effect on the precision of the stored<br>heading values. Not sure how this changes the results.<br>I guess that Garmin will only use an arc with a high speed when<br>that is long enough so that the higher speed weights out the penalty .<br>A few tests show that it typically prefers the slower roads at the junction<br>with the sharp angle, and "jumps" on the faster road at the next node. <br><br>If you think that I should also look at other parameters, please let me know.<br>Gerd<br><br><div><hr id="stopSpelling">Date: Sat, 5 Sep 2015 15:17:17 +0200<br>From: extremecarver@gmail.com<br>To: mkgmap-dev@lists.mkgmap.org.uk<br>Subject: Re: [mkgmap-dev] [Patch v3] sharp angles<br><br><div dir="ltr"><div><div>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...<br></div>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.<br><br></div>And yeah - I also don't know what's best. V2 seemed best to me so far. <br></div><div class="ecxgmail_extra"><br><div class="ecxgmail_quote">On 5 September 2015 at 15:09, GerdP <span dir="ltr"><<a href="mailto:gpetermann_muenchen@hotmail.com" target="_blank">gpetermann_muenchen@hotmail.com</a>></span> wrote:<br><blockquote class="ecxgmail_quote" style="border-left:1px #ccc solid;padding-left:1ex;">Hi Felix,<br>
<br>
okay, I came to similar results with other styles today, so<br>
maybe I'll revert the change that makes most angles larger.<br>
<br>
Reg- --x-cycle-map:<br>
Without it only angles < 45° are changed to 45°.<br>
With it and v2, angles were changed to 68° when road speed of an arc is >= 3<br>
and 90° when road_speed >= 5.<br>
With it and v3, all angles < 90 are changed at junctions with only 3<br>
directions.<br>
<br>
I think the Garmin algo is not really able to handle multiple arcs with<br>
that your style creates, at least it doesn't seem to "look" at all of them,<br>
esp. the last part of a route seems always to use the "topmost" road,<br>
means, the one that was last added in the style (as long as the selected<br>
vehicle is allowed).<br>
I think we first have to understand how the Garmin algo works before<br>
we can try to manipulate the data for better results.<br>
This is time consuming and error prone, so I'll need a few more days to<br>
work out facts.<br>
<br>
Gerd<br>
<br>
<br>
Felix Hartmann-2 wrote<br>
<span>> Well - I guess this will never be without errors - with Patch v3 there<br>
> is again a little loop - now again at the first place:<br>
><br>
><br>
</span><div><div class="h5">> (only happens with "Shorter Distance" and one of the<br>
> driving/motorcycle/Dirtbike and so on profiles..).<br>
><br>
> Also on some other places still detours - in general "Shorter Distance"<br>
> seems to be much more problematic than "faster time". So for sharp turns<br>
> - ironically - shorter distance chooses the detour to avoid the sharp<br>
> turn.<br>
><br>
><br>
> I'm not really sure patch v3 is better than v2 however. Results are<br>
> 50/50 better/worse. However the arrival times got a bit slower (even if<br>
> following exactly the same route). I always tried with --x-cycle-map<br>
> switch - never without. I'm still not so sure what this option really<br>
> changes for outcome in the end.<br>
> So - additional intersection roads would still be king IMHO... (but yes<br>
> I know - not possible).<br>
><br>
><br>
><br>
> On 04.09.2015 19:34, Gerd Petermann wrote:<br>
>> Hi all,<br>
>><br>
>> attached is v3, only small changes:<br>
>> 1) the message "maybe duplicated OSM way " was printed too often<br>
>> 2) with --x-cycle-map, change the headings<br>
>> at junctions with only three different arcs so that angles of 90° or more<br>
>> are created.<br>
>><br>
>> If I hear no complains I'll commit this patch on monday,<br>
>> probably without the --x-fix-sharp-angles switch.<br>
>><br>
>> I am still trying to work out in what case the Garmin routing algo<br>
>> prefers a detour, so maybe I find more improvements later.<br>
>><br>
>> Ciao,<br>
>> Gerd<br>
>><br>
>><br>
>> _______________________________________________<br>
>> mkgmap-dev mailing list<br>
>><br>
<br>
</div></div>> mkgmap-dev@.org<br>
<span><br>
>> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
><br>
> --<br>
> keep on biking and discovering new trails<br>
><br>
> Felix<br>
> <a href="http://openmtbmap.org" rel="noreferrer" target="_blank">openmtbmap.org</a> & <a href="http://www.velomap.org" rel="noreferrer" target="_blank">www.velomap.org</a><br>
><br>
><br>
</span>> _______________________________________________<br>
> mkgmap-dev mailing list<br>
<br>
> mkgmap-dev@.org<br>
<br>
> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
><br>
> ajjdjdgb.png (24K)<br>
> <<a href="http://gis.19327.n5.nabble.com/attachment/5854037/0/ajjdjdgb.png" rel="noreferrer" target="_blank">http://gis.19327.n5.nabble.com/attachment/5854037/0/ajjdjdgb.png</a>><br>
<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://gis.19327.n5.nabble.com/Patch-v3-sharp-angles-tp5853996p5854043.html" rel="noreferrer" target="_blank">http://gis.19327.n5.nabble.com/Patch-v3-sharp-angles-tp5853996p5854043.html</a><br>
Sent from the Mkgmap Development mailing list archive at Nabble.com.<br>
<div class="ecxHOEnZb"><div class="h5">_______________________________________________<br>
mkgmap-dev mailing list<br>
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a><br>
<a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a></div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="ecxgmail_signature"><div dir="ltr"><div><div><div>Felix Hartman - Openmtbmap.org & VeloMap.org<br></div>Floragasse 9/11<br></div>1040 Wien<br></div>Austria - Österreich</div></div>
</div>
<br>_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</div> </div></body>
</html>