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

Tue Aug 11 07:24:54 BST 2015

Hi Felix,

I was referring to a different junction (Ristedter Hauptstraße / Scheunenbrink) but
I see that this small area seems to contain some good test cases :-)

Up to now I found one additional problem when looking for candidate junctions :
Before modifying angles (or adding new ways) the algo has to find out if the 
OSM data already contains that alternative way and if that way allows the wanted
traffic. I guess that check can be done by looking at the lengths of the two arcs and
the existence of an arc between the destination nodes of the two arcs.

If you agree, I'd first like to finish the discussion about the existing code for 
--adjust-turn-headings. I think the code and the option should be removed,
I think the current code is often changing data to the worse, and it is just good
luck when it fixes one of the "sharp angle" problems, it might as well create
one.

Gerd

Date: Mon, 10 Aug 2015 09:04:47 +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?

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 <gpetermann_muenchen at hotmail.com> 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 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

_______________________________________________

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/20150811/e1f5a36b/attachment.html>