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

Mon Aug 10 08:04:47 BST 2015

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20150810/c8f891ec/attachment-0001.html>