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@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@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