[mkgmap-dev] What is the idea behind --adjust-turn-headings?

Mon Aug 10 09:21:03 BST 2015

Hi Felix,

the data flow in the current code makes adding new points or arcs very
difficult,
while changing the value for the heading of an arc is very simple and can be
done
with minimal impact on the size of the NOD file.
Adding new points means adding new routing nodes and arcs, if we have to
that
we should only do it where needed.
The big problem is to decide under what conditions a heading has to be
changed.
I'll think about it again, if I find no solution I'll post a patch that
reports
the places where we have sharp angles. Maybe someone else finds good
criteria
to decide whether a junction needs changes and if so, which arcs' headings 
should be changed.

Gerd

Felix Hartmann-2 wrote
> Good Morning Gerd,
> Well if there is a any way to "fix" those sharp angles like "Hokenbarg" /
> Zum Grunewald and maybe even Schützenstraße / zum Grunewald by adding a
> super short "highway junction" type of connecting road - that would be
> great for cycling/pedestrian maps.
> Even more as such angles are much more common in the nature compared to
> inside urban areas (and there they are not mapping errors).
> 
> The first junction is so sharp - that no Garmin device will ever try to
> route over it (except with road-speed 0 or maybe 1) - it would simply
> rather make a big detour around other streets...
> 
> Felix
> 
> On 10 August 2015 at 08:19, Gerd Petermann &lt;

> gpetermann_muenchen@

> &gt;
> wrote:
> 
>> Hi Felix,
>>
>> in fact I wanted to look at this point on the todo list
>> "detect sharp angles at road junctions and either change the heading
>> values or add small arcs"
>> when I found out that adjust-turn-headings isn't doing what I expexted.
>>
>> The img format stores the initial heading of an arc leaving a given node
>> as well
>> as the so called final heading. I think the initial heading is used to
>> calculate the
>> time penalty, the final heading is used to find out where the arc takes
>> you.
>> Sharp angles between two nodes don't matter much, they will only increase
>> a value that measures how "curvy" a road is.
>> So, I think that we don't need extra points in the map, we just need
>> other
>>
>> I agree that sharp angles cause higher time penalties, so it would be
>> good
>> to
>> avoid them for maps which are only used by cyclists or pedestrians.
>> It also is plausible that the penalty depends on the road-speed.
>>
>> I see two cases where we have sharp angles:
>> 1) Two parallel highways connect at a juction, like here:
>>
>> http://www.openstreetmap.org/search?query=52.976941%2C8.842898#map=18/52.97694/8.84290&layers=T
>> or here:
>>
>> http://www.openstreetmap.org/search?query=52.973986%2C8.854225#map=18/52.97399/8.85422&layers=T
>>
>> 2) Mapping errors (?) like here:
>>
>> http://www.openstreetmap.org/search?query=52.944818%2C8.762379#map=18/52.94482/8.76238&layers=T
>>
>> where the junction of way 26667180 and way 4526346 is mapped with a very
>> sharp angle while
>> Bing shows a different situation.
>>
>> I fear it will be difficult to separate these cases by algorihtm, but I
>> think the majority of sharp angles is
>> like the ones in 1) and I don't see a need to fix those.
>>
>> Any ideas?
>>
>> Gerd
>>
>> ------------------------------
>> Date: Sat, 8 Aug 2015 00:12:57 +0200
>> From: 

> extremecarver@

>> To: 

> mkgmap-dev at .org

>> Subject: Re: [mkgmap-dev] What is the idea behind --adjust-turn-headings?
>>
>> It's not so much about the instruction - but about the time penalties.
>> Try out some super sharp turns - with different road-speed. there will be
>> like 2-3 minutes penalties... No turn should be sharper than 50-60° angle
>> left if possible - else the routing really breaks down...
>>
>> Best would be actually to create small artificial roads to make the turn
>> less sharp... (actually 4-5 points are enough - and have most of that
>> turn
>> in the additional mid 2-3 points).
>>
>> I think adjust turn headings helps there a bit (for bicycle/foot routing
>> -
>> cause actual streets usually don't have relly sharp turns as cars could
>> not
>> do it - but for trails/pathes really awful turns exist (awful for the
>> Garmin algo)...)
>>
>>
>> In case of crossings with 5-6 ways - even a small artifical turnaround
>> would be great....
>>
>> On 7 August 2015 at 16:40, Gerd Petermann &lt;

> gpetermann_muenchen@

> &gt; > wrote:
>>
>> Hi Marko,
>>
>> > >// also helps to produce a turn instruction when the main
>> > >// road bends sharply but the side road keeps close to the
>> > >// original heading
>> >
>> > Oh, that would seem to be applicable for a scenario where you have a
>> > grid of highway=residential, and among them a main road (say,
>> > highway=tertiary) that is going like zig-zag within the grid. Could it
>> > be that Garmin is not issuing a turn instruction in this case, when the
>>  > main road consists of a single object (with a sharp turn in it)?
>>
>> Do you have an example OSM id?
>>
>> >
>> > AFAIR, there was another option for implementing support for
>> > through_route relations, in a case where a main road goes zig-zag
>> > through a village. Is it still present in the code base? Maybe it makes
>> > this case of --adjust-turn-headings redundant?
>>
>> The evaluation of through-route relations is still in the code, I guess
>> it
>> still
>> works, but IIRC the tag is only rarely used.
>>
>>
>> I did a few more tests now (without --housenumbers for now).
>> I think the code for --adjust-turn-heading is somehow wrong, e.g.
>> if the calculated route is
>> entering the junction at node 1828873253
>> http://www.openstreetmap.org/node/1828873253
>> from south going right will not not show a "turn right" instruction
>> when --adjust-turn-heading is used, but it does without the option.
>> Consequently, if the route goes straight on to way 171930600,
>> the instruction is "turn left onto Börtelsdamm" with and
>>  no instruction without the option.
>>
>> It seems that Garmin uses the "Continue on" instruction only on ramps.
>>
>> Reg. ramps I found no positive effect with --adjust-turn-heading, I see
>> the
>> same instructions but sometimes the calculated time is increased,
>> probably
>> because the code increases the angle too much.
>> Maybe the option (and the code) is really obsolete since r3116 which
>> introduced
>> the new routines for writing NOD data:
>>
>> http://www.mkgmap.org.uk/news/2014/03/19/announcement-version-r3116-is-a-major-u
>>
>> Up to now I did my tests with real data, I'll try to create some test
>> data
>> to find out
>> if there is still a case where --adjust-turn-heading produces better
>> instructions.
>>
>> Gerd
>>
>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> 

> mkgmap-dev at .org

>> 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 .org

>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> 

> mkgmap-dev at .org

>> 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 .org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

--
View this message in context: http://gis.19327.n5.nabble.com/What-is-the-idea-behind-adjust-turn-headings-tp5851885p5852013.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.