logo separator

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

From Felix Hartmann extremecarver at gmail.com on Fri Aug 7 23:12:57 BST 2015

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


More information about the mkgmap-dev mailing list