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

Mon Aug 10 07:19:05 BST 2015

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 at gmail.com
To: mkgmap-dev at lists.mkgmap.org.uk
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 <gpetermann_muenchen at hotmail.com> 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 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20150810/ed5d3f01/attachment.html>