<div dir="ltr"><div><div><div><div><div><div>Well the time penalties are really unbearable if (open) angle is lower 50°.<br><br></div>A strait distance of 1km will be 1 minute on the example road in Basecamp (road-speed=2) while being 4minutes if the way has a 20° angle turn in the middle for the same distance. (actually turn only - intersection would be much worse!).<br></div>At ~40° it is still over 1minute added to the total time. At 90° it shows 1 minute too - so the penalty is minimal...<br><br></div>So really - there would need to be some way for cycling/pedestrian maps to make sure no turn is lower than 50°. If the turn is rounded by 3-4 nodes - and each turn in that round has over 90° angle - the penalty is more or less nonexistent. <br></div><br></div>For intersections the rule is likely - no matter what - if the intersection turn angle is lower 50° Basecamp/devices will freak out and try to route somewhere else.<br><br></div><div>Another possibility would be to decrease the road speed at the turn/intersection by 1 or 2 levels - then have the turn/intersection. At road-speed 0 or 1 it is already much better - and the overall time for the way will decrease! (if you have 10meters in and out of the turn with lower road-speed).<br></div><div><br></div>Too bad additional points are not possible.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 August 2015 at 10:21, 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>
the data flow in the current code makes adding new points or arcs very<br>
difficult,<br>
while changing the value for the heading of an arc is very simple and can be<br>
done<br>
with minimal impact on the size of the NOD file.<br>
Adding new points means adding new routing nodes and arcs, if we have to<br>
that<br>
we should only do it where needed.<br>
The big problem is to decide under what conditions a heading has to be<br>
changed.<br>
I'll think about it again, if I find no solution I'll post a patch that<br>
reports<br>
the places where we have sharp angles. Maybe someone else finds good<br>
criteria<br>
to decide whether a junction needs changes and if so, which arcs' headings<br>
should be changed.<br>
<br>
Gerd<br>
<br>
<br>
Felix Hartmann-2 wrote<br>
<span class="">> Good Morning Gerd,<br>
> Well if there is a any way to "fix" those sharp angles like "Hokenbarg" /<br>
> Zum Grunewald and maybe even Schützenstraße / zum Grunewald by adding a<br>
> super short "highway junction" type of connecting road - that would be<br>
> great for cycling/pedestrian maps.<br>
> Even more as such angles are much more common in the nature compared to<br>
> inside urban areas (and there they are not mapping errors).<br>
><br>
> The first junction is so sharp - that no Garmin device will ever try to<br>
> route over it (except with road-speed 0 or maybe 1) - it would simply<br>
> rather make a big detour around other streets...<br>
><br>
> Felix<br>
><br>
> On 10 August 2015 at 08:19, Gerd Petermann <<br>
<br>
> gpetermann_muenchen@<br>
<br>
> ><br>
</span><div><div class="h5">> wrote:<br>
><br>
>> Hi Felix,<br>
>><br>
>> in fact I wanted to look at this point on the todo list<br>
>> "detect sharp angles at road junctions and either change the heading<br>
>> values or add small arcs"<br>
>> when I found out that adjust-turn-headings isn't doing what I expexted.<br>
>><br>
>> The img format stores the initial heading of an arc leaving a given node<br>
>> as well<br>
>> as the so called final heading. I think the initial heading is used to<br>
>> calculate the<br>
>> time penalty, the final heading is used to find out where the arc takes<br>
>> you.<br>
>> Sharp angles between two nodes don't matter much, they will only increase<br>
>> a value that measures how "curvy" a road is.<br>
>> So, I think that we don't need extra points in the map, we just need<br>
>> other<br>
>><br>
>> I agree that sharp angles cause higher time penalties, so it would be<br>
>> good<br>
>> to<br>
>> avoid them for maps which are only used by cyclists or pedestrians.<br>
>> It also is plausible that the penalty depends on the road-speed.<br>
>><br>
>> I see two cases where we have sharp angles:<br>
>> 1) Two parallel highways connect at a juction, like here:<br>
>><br>
>> <a href="http://www.openstreetmap.org/search?query=52.976941%2C8.842898#map=18/52.97694/8.84290&layers=T" rel="noreferrer" target="_blank">http://www.openstreetmap.org/search?query=52.976941%2C8.842898#map=18/52.97694/8.84290&layers=T</a><br>
>> or here:<br>
>><br>
>> <a href="http://www.openstreetmap.org/search?query=52.973986%2C8.854225#map=18/52.97399/8.85422&layers=T" rel="noreferrer" target="_blank">http://www.openstreetmap.org/search?query=52.973986%2C8.854225#map=18/52.97399/8.85422&layers=T</a><br>
>><br>
>> 2) Mapping errors (?) like here:<br>
>><br>
>> <a href="http://www.openstreetmap.org/search?query=52.944818%2C8.762379#map=18/52.94482/8.76238&layers=T" rel="noreferrer" target="_blank">http://www.openstreetmap.org/search?query=52.944818%2C8.762379#map=18/52.94482/8.76238&layers=T</a><br>
>><br>
>> where the junction of way 26667180 and way 4526346 is mapped with a very<br>
>> sharp angle while<br>
>> Bing shows a different situation.<br>
>><br>
>> I fear it will be difficult to separate these cases by algorihtm, but I<br>
>> think the majority of sharp angles is<br>
>> like the ones in 1) and I don't see a need to fix those.<br>
>><br>
>> Any ideas?<br>
>><br>
>> Gerd<br>
>><br>
</div></div>>> ------------------------------<br>
<span class="">>> Date: Sat, 8 Aug 2015 00:12:57 +0200<br>
>> From:<br>
<br>
> extremecarver@<br>
<br>
</span>>> To:<br>
<br>
> mkgmap-dev@.org<br>
<span class=""><br>
>> Subject: Re: [mkgmap-dev] What is the idea behind --adjust-turn-headings?<br>
>><br>
>> It's not so much about the instruction - but about the time penalties.<br>
>> Try out some super sharp turns - with different road-speed. there will be<br>
>> like 2-3 minutes penalties... No turn should be sharper than 50-60° angle<br>
>> left if possible - else the routing really breaks down...<br>
>><br>
>> Best would be actually to create small artificial roads to make the turn<br>
>> less sharp... (actually 4-5 points are enough - and have most of that<br>
>> turn<br>
>> in the additional mid 2-3 points).<br>
>><br>
>> I think adjust turn headings helps there a bit (for bicycle/foot routing<br>
>> -<br>
>> cause actual streets usually don't have relly sharp turns as cars could<br>
>> not<br>
>> do it - but for trails/pathes really awful turns exist (awful for the<br>
>> Garmin algo)...)<br>
>><br>
>><br>
>> In case of crossings with 5-6 ways - even a small artifical turnaround<br>
>> would be great....<br>
>><br>
>> On 7 August 2015 at 16:40, Gerd Petermann <<br>
<br>
> gpetermann_muenchen@<br>
<br>
</span><div><div class="h5">> > > wrote:<br>
>><br>
>> Hi Marko,<br>
>><br>
>> > >// also helps to produce a turn instruction when the main<br>
>> > >// road bends sharply but the side road keeps close to the<br>
>> > >// original heading<br>
>> ><br>
>> > Oh, that would seem to be applicable for a scenario where you have a<br>
>> > grid of highway=residential, and among them a main road (say,<br>
>> > highway=tertiary) that is going like zig-zag within the grid. Could it<br>
>> > be that Garmin is not issuing a turn instruction in this case, when the<br>
>> > main road consists of a single object (with a sharp turn in it)?<br>
>><br>
>> Do you have an example OSM id?<br>
>><br>
>> ><br>
>> > AFAIR, there was another option for implementing support for<br>
>> > through_route relations, in a case where a main road goes zig-zag<br>
>> > through a village. Is it still present in the code base? Maybe it makes<br>
>> > this case of --adjust-turn-headings redundant?<br>
>><br>
>> The evaluation of through-route relations is still in the code, I guess<br>
>> it<br>
>> still<br>
>> works, but IIRC the tag is only rarely used.<br>
>><br>
>><br>
>> I did a few more tests now (without --housenumbers for now).<br>
>> I think the code for --adjust-turn-heading is somehow wrong, e.g.<br>
>> if the calculated route is<br>
>> entering the junction at node 1828873253<br>
>> <a href="http://www.openstreetmap.org/node/1828873253" rel="noreferrer" target="_blank">http://www.openstreetmap.org/node/1828873253</a><br>
>> from south going right will not not show a "turn right" instruction<br>
>> when --adjust-turn-heading is used, but it does without the option.<br>
>> Consequently, if the route goes straight on to way 171930600,<br>
>> the instruction is "turn left onto Börtelsdamm" with and<br>
>> no instruction without the option.<br>
>><br>
>> It seems that Garmin uses the "Continue on" instruction only on ramps.<br>
>><br>
>> Reg. ramps I found no positive effect with --adjust-turn-heading, I see<br>
>> the<br>
>> same instructions but sometimes the calculated time is increased,<br>
>> probably<br>
>> because the code increases the angle too much.<br>
>> Maybe the option (and the code) is really obsolete since r3116 which<br>
>> introduced<br>
>> the new routines for writing NOD data:<br>
>><br>
>> <a href="http://www.mkgmap.org.uk/news/2014/03/19/announcement-version-r3116-is-a-major-u" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/news/2014/03/19/announcement-version-r3116-is-a-major-u</a><br>
>><br>
>> Up to now I did my tests with real data, I'll try to create some test<br>
>> data<br>
>> to find out<br>
>> if there is still a case where --adjust-turn-heading produces better<br>
>> instructions.<br>
>><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>
>><br>
>><br>
>> --<br>
>> Felix Hartman - Openmtbmap.org & VeloMap.org<br>
>> Floragasse 9/11<br>
>> 1040 Wien<br>
>> Austria - Österreich<br>
>><br>
>> _______________________________________________ mkgmap-dev mailing list<br>
>><br>
<br>
</span>> 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>
>> mkgmap-dev mailing list<br>
>><br>
<br>
</span>> 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>
><br>
><br>
> --<br>
> Felix Hartman - Openmtbmap.org & VeloMap.org<br>
> Floragasse 9/11<br>
> 1040 Wien<br>
> Austria - Österreich<br>
><br>
> _______________________________________________<br>
> mkgmap-dev mailing list<br>
<br>
</span>> 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>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://gis.19327.n5.nabble.com/What-is-the-idea-behind-adjust-turn-headings-tp5851885p5852013.html" rel="noreferrer" target="_blank">http://gis.19327.n5.nabble.com/What-is-the-idea-behind-adjust-turn-headings-tp5851885p5852013.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>