What is the idea behind --adjust-turn-headings?
Hi all, I understand that this option should help to produce good driving instructions. Anyhow, I wonder if the result is really better. The two screenshots show the difference at this node: http://www.openstreetmap.org/node/21725099 With --adjust-turn-heading I am told to turn left onto Orchideenstraße when the road is nearly straight because Rosenweg bends right. I'd prefer to see something like "straight on onto Orchideenstraße" instead, but it seems that Garmin doesn't produce this message, so I'd be happier without the additional message, as it forces me to search for a possibility to turn left where I have to move straight on. Before I can fix the additinal problems introduced by the naming of service roads I'd like to understand if this is the intended behaviour. Gerd
On Thu, Aug 06, 2015 at 03:11:23PM +0200, Gerd Petermann wrote:
I understand that this option should help to produce good driving instructions. Anyhow, I wonder if the result is really better.
The two screenshots show the difference at this node: http://www.openstreetmap.org/node/21725099
This node is a 3-way T-shaped crossing, with roughly 90° angles between the 3 roads. If my memory serves me correctly, the motivation behind --adjust-turn-headings was to help in cases where you are entering a Y-shaped crossing from the bottom, and there is a very sharp angle between the branches of the Y. At the extreme, one of the branches is going straight, and the other is at some very small angle. In this case, you might want a direction such as "turn left" or "turn right", if Garmin cannot produce a "keep left" or "keep right" direction. IIRC, without the option, when entering this cycleway ramp from the north: http://www.openstreetmap.org/node/33986539 the Garmin Edge 705 would not give any announcement that I have to turn. With --adjust-turn-headings, it would tell me to turn left. I do not have the device any more, so I cannot test this.
Before I can fix the additinal problems introduced by the naming of service roads I'd like to understand if this is the intended behaviour.
I would say that it is not. If you have a T-crossing with the nodes AC at the end of the horizontal section of the T and the node B at the bottom, and you are going left to right from A to C, the road names or the way how the roads are split to way segments should not matter. It also should not matter if the route A-C is bending slightly. IMO, what should matter is the difference of the angles of the roads. In this case, the angle difference between A-C and A-B is about 90°. If that angle difference were smaller than some threshold (say, 45° or maybe even 30°), then it would make sense to adjust the turn headings. Otherwise the turn directions would be simply noise. Marko
Hi Marko, thanks, I think the 2nd block in the comments for the code suggest something else: // detect the "shallow turn" scenario where at a junction // on some "main" road, the side road leaves the main // road at a very shallow angle and the GPS says "keep // right/left" when it would be better if it said "turn // right/left" // also helps to produce a turn instruction when the main // road bends sharply but the side road keeps close to the // original heading Your example matches the "shallow turn" scenario, I think my example matches the 2nd one. I do not yet understand the effect of the parameter (1/2/3) for the option, I guess I have to trace some more examples... Gerd
Date: Fri, 7 Aug 2015 12:22:25 +0300 From: marko.makela@iki.fi To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] What is the idea behind --adjust-turn-headings?
On Thu, Aug 06, 2015 at 03:11:23PM +0200, Gerd Petermann wrote:
I understand that this option should help to produce good driving instructions. Anyhow, I wonder if the result is really better.
The two screenshots show the difference at this node: http://www.openstreetmap.org/node/21725099
This node is a 3-way T-shaped crossing, with roughly 90° angles between the 3 roads.
If my memory serves me correctly, the motivation behind --adjust-turn-headings was to help in cases where you are entering a Y-shaped crossing from the bottom, and there is a very sharp angle between the branches of the Y. At the extreme, one of the branches is going straight, and the other is at some very small angle. In this case, you might want a direction such as "turn left" or "turn right", if Garmin cannot produce a "keep left" or "keep right" direction.
IIRC, without the option, when entering this cycleway ramp from the north:
http://www.openstreetmap.org/node/33986539
the Garmin Edge 705 would not give any announcement that I have to turn. With --adjust-turn-headings, it would tell me to turn left. I do not have the device any more, so I cannot test this.
Before I can fix the additinal problems introduced by the naming of service roads I'd like to understand if this is the intended behaviour.
I would say that it is not. If you have a T-crossing with the nodes AC at the end of the horizontal section of the T and the node B at the bottom, and you are going left to right from A to C, the road names or the way how the roads are split to way segments should not matter. It also should not matter if the route A-C is bending slightly.
IMO, what should matter is the difference of the angles of the roads. In this case, the angle difference between A-C and A-B is about 90°. If that angle difference were smaller than some threshold (say, 45° or maybe even 30°), then it would make sense to adjust the turn headings. Otherwise the turn directions would be simply noise.
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Fri, Aug 07, 2015 at 12:00:25PM +0200, Gerd Petermann wrote:
// 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)? 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? Marko
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-maj... 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
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-maj...
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
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.976... or here: http://www.openstreetmap.org/search?query=52.973986%2C8.854225#map=18/52.973... 2) Mapping errors (?) like here: http://www.openstreetmap.org/search?query=52.944818%2C8.762379#map=18/52.944... 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@gmail.com To: mkgmap-dev@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@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-maj... 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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@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.976... or here:
http://www.openstreetmap.org/search?query=52.973986%2C8.854225#map=18/52.973...
2) Mapping errors (?) like here:
http://www.openstreetmap.org/search?query=52.944818%2C8.762379#map=18/52.944...
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@gmail.com To: mkgmap-dev@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@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-maj...
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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ 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
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.976... or here:
http://www.openstreetmap.org/search?query=52.973986%2C8.854225#map=18/52.973...
2) Mapping errors (?) like here:
http://www.openstreetmap.org/search?query=52.944818%2C8.762379#map=18/52.944...
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@.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-maj...
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@.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@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/What-is-the-idea-behind-adjust-turn-headings-... Sent from the Mkgmap Development mailing list archive at Nabble.com.
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@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.976...
or here:
http://www.openstreetmap.org/search?query=52.973986%2C8.854225#map=18/52.973...
2) Mapping errors (?) like here:
http://www.openstreetmap.org/search?query=52.944818%2C8.762379#map=18/52.944...
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@.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-maj...
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@.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@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/What-is-the-idea-behind-adjust-turn-headings-... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ 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
Hi Felix,
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).
I'm afraid this could greatly increase time for calculating a route. I have done tests with some commercial data and cGPSmapper. I'm not sure if results are directly compatible with mkgmap, but in my opinion, for routing speed most important is the number of roads (class 4 roads in case of long distance routes). Single road with multiple nodes (junctions) is better than the same nodes arranged as multiple roads. -- Best regards, Andrzej
Yes - in principle this is correct. However for roads with too sharp turns or even worse intersections that are needed to be less sharp - that's not true. Maybe concerning long distance routing yes - but when it comes to does Basecamp/the GPS device choose the better route that is actually faster - better have some divided roads. I did setup some test maps with way A vs way B possible between two points. Way A much shorther but with sharp turns - vs Way B much longer and even having intersections - but not sharp turns. B will be chosen. Some profiles are completely incapable (e.g. automotive profiles in new Basecamp versions) of accepting sharp turns - while some profiles like dirt bike or ATV are actually a bit less dependent there - but still results will be much better without sharp turns. It's actually enough to change a sharp turn into a curve - and it will be much more likely to be routed along... On 10 August 2015 at 11:57, Andrzej Popowski <popej@poczta.onet.pl> wrote:
Hi Felix,
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).
I'm afraid this could greatly increase time for calculating a route. I have done tests with some commercial data and cGPSmapper. I'm not sure if results are directly compatible with mkgmap, but in my opinion, for routing speed most important is the number of roads (class 4 roads in case of long distance routes). Single road with multiple nodes (junctions) is better than the same nodes arranged as multiple roads.
-- Best regards, Andrzej
_______________________________________________ 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
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@gmail.com To: mkgmap-dev@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@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.976... or here: http://www.openstreetmap.org/search?query=52.973986%2C8.854225#map=18/52.973... 2) Mapping errors (?) like here: http://www.openstreetmap.org/search?query=52.944818%2C8.762379#map=18/52.944... 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@gmail.com To: mkgmap-dev@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@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-maj... 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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ 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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (5)
-
Andrzej Popowski -
Felix Hartmann -
Gerd Petermann -
GerdP
-
Marko Mäkelä