<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="gmail_extra"><br><div class="gmail_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="gmail_quote" style="margin:0 0 0 .8ex;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 class="">> 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 class=""><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="HOEnZb"><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="gmail_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>