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

Mon Aug 10 10:03:51 BST 2015

Well the time penalties are really unbearable if (open) angle is lower 50°.

A strait distance of 1km will be 1 minute on the example road in Basecamp
(road-speed=2) while being 4minutes if the way has a 20° angle turn in the
middle for the same distance. (actually turn only - intersection would be
much worse!).
At ~40° it is still over 1minute added to the total time. At 90° it shows 1
minute too - so the penalty is minimal...

So really - there would need to be some way for cycling/pedestrian maps to
make sure no turn is lower than 50°. If the turn is rounded by 3-4 nodes -
and each turn in that round has over 90° angle - the penalty is more or
less nonexistent.

For intersections the rule is likely - no matter what - if the intersection
turn angle is lower 50° Basecamp/devices will freak out and try to route
somewhere else.

Another possibility would be to decrease the road speed at the
turn/intersection by 1 or 2 levels - then have the turn/intersection. At
road-speed 0 or 1 it is already much better - and the overall time for the
way will decrease! (if you have 10meters in and out of the turn with lower
road-speed).

Too bad additional points are not possible.

On 10 August 2015 at 10:21, GerdP <gpetermann_muenchen at hotmail.com> wrote:

> Hi Felix,
>
> the data flow in the current code makes adding new points or arcs very
> difficult,
> while changing the value for the heading of an arc is very simple and can
> be
> done
> with minimal impact on the size of the NOD file.
> Adding new points means adding new routing nodes and arcs, if we have to
> that
> we should only do it where needed.
> The big problem is to decide under what conditions a heading has to be
> changed.
> I'll think about it again, if I find no solution I'll post a patch that
> reports
> the places where we have sharp angles. Maybe someone else finds good
> criteria
> to decide whether a junction needs changes and if so, which arcs' headings
> should be changed.
>
> Gerd
>
>
> Felix Hartmann-2 wrote
> > 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@
>
> > >
> > 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@
>
> >> To:
>
> > mkgmap-dev at .org
>
> >> 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@
>
> > > > 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 .org
>
> >> 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 .org
>
> >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >>
> >> _______________________________________________
> >> mkgmap-dev mailing list
> >>
>
> > mkgmap-dev at .org
>
> >> 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 .org
>
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/What-is-the-idea-behind-adjust-turn-headings-tp5851885p5852013.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> 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/28bd308e/attachment-0001.html>