Hi I use mkgmap/Garmin a lot for road routing and driving and frequently find cases where 1/ exit roads cause pop-ups telling me to turn to stay on the main road. 2/ an obvious turn is needed to stay on the same road and no pop-up is generated. These were some of problems that --adjust-turn-headings with code in RouteNode.java::tweezeArcs() was designed to solve. I'd like to have a go at reinstating it and tweaking it a bit to see if I can overcome some of the problems mentioned in some of the threads, eg http://gis.19327.n8.nabble.com/Possible-problem-with-adjust-turn-headin gs-td5851790.html http://gis.19327.n8.nabble.com/What-is-the-idea-behind-adjust-turn-head ings-td5851885.html before it was removed in r3649. I'm considering putting the code in imgfmt/app/net/AngleChecker.java Case 2/ can have further complications because OSM doesn't provide information when you have to give way as you turn to stay on the same road. Another pop-up I'd like to see is the minor road you wish to stay on is intersected by a more major road and you have to give way. Does anyone know if there is any way of triggering this? Ticker
Hi Ticker, maybe try first to disable the AngleChecker with --ignore-sharp-angles. Next, I'd try to disable the compacted format in RouteNode, search for useCompactDirs. The original code in tweezeArcs() was written at a time where the encoding of the heading values was completely misunderstood. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 18. September 2020 15:40 An: mkgmap development Betreff: [mkgmap-dev] Resurrect adjust-turn-headings Hi I use mkgmap/Garmin a lot for road routing and driving and frequently find cases where 1/ exit roads cause pop-ups telling me to turn to stay on the main road. 2/ an obvious turn is needed to stay on the same road and no pop-up is generated. These were some of problems that --adjust-turn-headings with code in RouteNode.java::tweezeArcs() was designed to solve. I'd like to have a go at reinstating it and tweaking it a bit to see if I can overcome some of the problems mentioned in some of the threads, eg http://gis.19327.n8.nabble.com/Possible-problem-with-adjust-turn-headings-td... http://gis.19327.n8.nabble.com/What-is-the-idea-behind-adjust-turn-headings-... before it was removed in r3649. I'm considering putting the code in imgfmt/app/net/AngleChecker.java Case 2/ can have further complications because OSM doesn't provide information when you have to give way as you turn to stay on the same road. Another pop-up I'd like to see is the minor road you wish to stay on is intersected by a more major road and you have to give way. Does anyone know if there is any way of triggering this? Ticker
Hi Gerd Examining compactDir logic there seem to be some strange issues, eg o When an start-of-road generates the first arc in a RouteNode, the pairing of arcs for any following mid-section of other road is upset. o It seems strange that the code stops using compact format when the initial headings of two or more roads are in the same 1/16 degree segment. I've some thoughts as to what the format is trying to imply about how it should be used, and if I can get BaseCamp and/or MapSource to show me reasonable turnangles on routes, test this by re-coding it to my assumptions and see what happens. As you suggest, it's a good idea to disable the AngleChecker. However I'm going to try to use compactDir for all RouteNodes and if it works, then go back to looking at my original problems of turn pop-ups. Ticker On Fri, 2020-09-18 at 16:55 +0000, Gerd Petermann wrote:
Hi Ticker,
maybe try first to disable the AngleChecker with --ignore-sharp -angles. Next, I'd try to disable the compacted format in RouteNode, search for useCompactDirs. The original code in tweezeArcs() was written at a time where the encoding of the heading values was completely misunderstood.
Gerd
Hi I've been experimenting with turn angles, compactDirs (4-bit) or not (8 -bit) format, sharp-angle delay and routing pop-ups and have some observations: 1/ BaseCamp, MapSource, eTrex 30x (newish) and eTrex HCx (old) can give different pop-ups for the same map and route. BaseCamp results are similar to the 30x, MapSource to the HCx. The differences I spotted were on Motorways, where BaseCamp/30x give extra pop-ups to "keep right" or "keep left" where the road splits, ie outside lane(s) will become a different road. 2/ The compactDirs format uses 8 bits per pair of distinct arcs giving 16 possible initial headings spanning 22.5 degrees each. The full format uses 8 bits per distinct arc giving 256 headings of ~1.4 degrees each. 3/ Using compactDirs doesn't reduce the size of the img file as the full size needs to be reserved. 4/ Paring the arcs so the same compactDirs entry is used for both directions of the same road makes no difference as to the decision the device might make about generating a turn pop-up while remaining on the same road because another road is more "straight-on" 4/ When using compactDirs, the Garmin logic appears to consider the opposite road (using the 4-bit granularity) to be the continuation and other roads generate a turn pop-up. I'm not sure if "opposite" has to be exactly opposite or just the closest to opposite. 5/ Because of this granularity, a road that changes angle by a fraction of a degree could end up not in opposing sectors, and another road that is up to 22.5 degrees from the first road could be in an opposite sector to part of the first road! 6/ The current algorithm checks if all the arcs from a routing node use distinct 4-bit headings, and, if so, uses the compactDirs format for that node, otherwise it uses the 8-bit format. The combination of 5/ and 6/ can lead to turn pop-ups on what seems like a straight road. 7/ Using the 8-bit format, the Garmin logic to decide on turn pop-ups seems more intelligent. The examples I've tested don't give a pop-up when driving on a road that bends and there is a path almost straight on. 8/ Sharpish turn-angles impose a routing penalty. This has behaviour that is difficult to pin down, but I'll try and summarise in another post. Ticker
Hi Sharp turn-angles impose a route-choosing penalty. For "fastest" routing this is understandable. However these penalties are so high that the algorithm might choose to cross the road in question and then make 2 or 3 opposite turns to finally onto it in the correct direction. For drive-on:left, it is very costly to turn right and the left turns are cheap. For the same sharp turn in the other direction I haven't found any example where it will make the detour. Building the same map with drive-on:right, it all reverses and you get the detour when needing to go left. Somehow these penalties are also applied to "shortest" routing, resulting in something that is definitely not the shortest route. Even more weirdly, examples can be found when, switching to "fastest", the extra costs of the additional turns and journey legs outweigh single turn cost and this results in a shorter distance that the "shortest" routing. Using compactDirs changes the behaviour of all of this. I'm not sure if this is just because it costs the angle as the maximum of the 22.5 degree segments. AngleChecker.fixSharpAngles (enabled by default, disabled by --x-ignore -sharp-angles) attempts to increase angles to lessen this penalty, but there can be conflicting requirements and sometimes it bends main roads to lessen more minor road angles and this can cause turn pop-ups. One of the examples I was working on to try and understand why I was getting a turn instruction to stay on a trunk/dual-carriageway, I tracked down to fixSharpAngles increasing the angle between the main road and the lead-off road, and this was because the lead-off road wasn't marked as one-way. This isn't obvious in OSM unless you zoom right in or inspect the tags, so something to watch out for. Ticker
Hi Gerd I've been looking at turn pop-ups and routing decisions and attach a patch that makes improvements: Move decision about when to use compactDir initialHeadings from RouteNode to AngleChecker. The current code checks if any headings from a RouteNode share the same compactDir/4-bit sector and, if so, revert to the full/8-bit value. Overlaid roads triggered this, also sharp angles that couldn't be widened, probably when many paths converge at a road. AngleChecker::fixSharpAngles was coded on the basis that compactDirs are used and it tested/increased angles based on this 4-bit step, but if these are then represented in 8-bit format, the encode angle could be much (up to 22.5 degrees) less that the code was expecting and result in turning delays in route calculations. Recode fixSharpAngles to work in degrees but choose the thresholds to be good for compactDirs. Test the resultant angles and only use compactDirs if there are no roads in the same or adjacent 4-bit sectors. Not allowing Adjacent is necessary because, in compactDirs format, if there is a path in the opposite sector to the road and the road continuation is the adjacent sector, Garmin gives a "turn to stay on road" pop-up, but with 8-bit headings it doesn't. This is slightly different from the following case because this concerns an angle that doesn't need to be "unsharpened" as it isn't permitted for vehicles to make this turn. When increasing an angle, change the heading of the lower class/speed road in preference to the major road. This helps prevent the "turn to stay on road" type pop-ups when the lead-off road was more straight-on than the main road and one-way tagging possibly missing. Handle simple (<= 2 RouteArcs) RouteNodes as special cases, giving slight efficiency improvements. Add some diagnostics for showing RouteNodes and RouteArcs in an area. Tidy up normalisation of headings. Fix some bugs. Ticker
Hi Ticker, thanks for the patch. I'll have a closer look at the weekend. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 14. Oktober 2020 10:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings Hi Gerd I've been looking at turn pop-ups and routing decisions and attach a patch that makes improvements: Move decision about when to use compactDir initialHeadings from RouteNode to AngleChecker. The current code checks if any headings from a RouteNode share the same compactDir/4-bit sector and, if so, revert to the full/8-bit value. Overlaid roads triggered this, also sharp angles that couldn't be widened, probably when many paths converge at a road. AngleChecker::fixSharpAngles was coded on the basis that compactDirs are used and it tested/increased angles based on this 4-bit step, but if these are then represented in 8-bit format, the encode angle could be much (up to 22.5 degrees) less that the code was expecting and result in turning delays in route calculations. Recode fixSharpAngles to work in degrees but choose the thresholds to be good for compactDirs. Test the resultant angles and only use compactDirs if there are no roads in the same or adjacent 4-bit sectors. Not allowing Adjacent is necessary because, in compactDirs format, if there is a path in the opposite sector to the road and the road continuation is the adjacent sector, Garmin gives a "turn to stay on road" pop-up, but with 8-bit headings it doesn't. This is slightly different from the following case because this concerns an angle that doesn't need to be "unsharpened" as it isn't permitted for vehicles to make this turn. When increasing an angle, change the heading of the lower class/speed road in preference to the major road. This helps prevent the "turn to stay on road" type pop-ups when the lead-off road was more straight-on than the main road and one-way tagging possibly missing. Handle simple (<= 2 RouteArcs) RouteNodes as special cases, giving slight efficiency improvements. Add some diagnostics for showing RouteNodes and RouteArcs in an area. Tidy up normalisation of headings. Fix some bugs. Ticker
Hi Ticker, sorry for the delay. I've started to compare the results of the patched and the original version. I think there might be a problem with --x-ignore-sharp-angles. I assume that patch disables the compact dirs when this undocument option is used? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Mittwoch, 14. Oktober 2020 19:26 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings Hi Ticker, thanks for the patch. I'll have a closer look at the weekend. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 14. Oktober 2020 10:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings Hi Gerd I've been looking at turn pop-ups and routing decisions and attach a patch that makes improvements: Move decision about when to use compactDir initialHeadings from RouteNode to AngleChecker. The current code checks if any headings from a RouteNode share the same compactDir/4-bit sector and, if so, revert to the full/8-bit value. Overlaid roads triggered this, also sharp angles that couldn't be widened, probably when many paths converge at a road. AngleChecker::fixSharpAngles was coded on the basis that compactDirs are used and it tested/increased angles based on this 4-bit step, but if these are then represented in 8-bit format, the encode angle could be much (up to 22.5 degrees) less that the code was expecting and result in turning delays in route calculations. Recode fixSharpAngles to work in degrees but choose the thresholds to be good for compactDirs. Test the resultant angles and only use compactDirs if there are no roads in the same or adjacent 4-bit sectors. Not allowing Adjacent is necessary because, in compactDirs format, if there is a path in the opposite sector to the road and the road continuation is the adjacent sector, Garmin gives a "turn to stay on road" pop-up, but with 8-bit headings it doesn't. This is slightly different from the following case because this concerns an angle that doesn't need to be "unsharpened" as it isn't permitted for vehicles to make this turn. When increasing an angle, change the heading of the lower class/speed road in preference to the major road. This helps prevent the "turn to stay on road" type pop-ups when the lead-off road was more straight-on than the main road and one-way tagging possibly missing. Handle simple (<= 2 RouteArcs) RouteNodes as special cases, giving slight efficiency improvements. Add some diagnostics for showing RouteNodes and RouteArcs in an area. Tidy up normalisation of headings. Fix some bugs. Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Yes, with --x-ignore-sharp-angles, the compactDirs format is disabled. Some of the example problems I looked at behaved much better when not using compactDirs, so it seemed reasonable, to avoid more developer "- -x-" type options, to have it this way. I thought about having another option to control this when "ignore -sharp-angles", with options to force on, force off and auto mode that looks for the cases of 2 roads being in the same sector or where the road continuation isn't in the opposite sector but some other way is. I can do something like this if you think it worthwhile. Ticker On Tue, 2020-10-20 at 08:10 +0000, Gerd Petermann wrote:
Hi Ticker,
sorry for the delay. I've started to compare the results of the patched and the original version. I think there might be a problem with --x-ignore-sharp-angles. I assume that patch disables the compact dirs when this undocument option is used?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Mittwoch, 14. Oktober 2020 19:26 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings
Hi Ticker,
thanks for the patch. I'll have a closer look at the weekend.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 14. Oktober 2020 10:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings
Hi Gerd
I've been looking at turn pop-ups and routing decisions and attach a patch that makes improvements:
Move decision about when to use compactDir initialHeadings from RouteNode to AngleChecker. The current code checks if any headings from a RouteNode share the same compactDir/4-bit sector and, if so, revert to the full/8-bit value. Overlaid roads triggered this, also sharp angles that couldn't be widened, probably when many paths converge at a road.
AngleChecker::fixSharpAngles was coded on the basis that compactDirs are used and it tested/increased angles based on this 4-bit step, but if these are then represented in 8-bit format, the encode angle could be much (up to 22.5 degrees) less that the code was expecting and result in turning delays in route calculations.
Recode fixSharpAngles to work in degrees but choose the thresholds to be good for compactDirs. Test the resultant angles and only use compactDirs if there are no roads in the same or adjacent 4-bit sectors. Not allowing Adjacent is necessary because, in compactDirs format, if there is a path in the opposite sector to the road and the road continuation is the adjacent sector, Garmin gives a "turn to stay on road" pop-up, but with 8-bit headings it doesn't. This is slightly different from the following case because this concerns an angle that doesn't need to be "unsharpened" as it isn't permitted for vehicles to make this turn.
When increasing an angle, change the heading of the lower class/speed road in preference to the major road. This helps prevent the "turn to stay on road" type pop-ups when the lead-off road was more straight-on than the main road and one-way tagging possibly missing.
Handle simple (<= 2 RouteArcs) RouteNodes as special cases, giving slight efficiency improvements.
Add some diagnostics for showing RouteNodes and RouteArcs in an area.
Tidy up normalisation of headings.
Fix some bugs.
Ticker
_______________________________________________ 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
Hi Ticker, my understanding is that original Garmin maps use compact dirs a lot, so I think it is not a good idea to disable them. My problem with the patch is that NodCheck complains a lot more Steve and I are not sure how Garmin calculates the encoded angles, so we are still just guessing. Your approach might well be the best so far. The code in NodCheck has one big problem: It uses the data stored in RGN to calculate the bearings, and that means 24 bit precision. So for nearby nodes the rounding errors are too big and NodCheck uses a fallback algo which selects another point. I guess Garmin also calculates the NOD data with more than 24 bit precision, so they probably also have some kind of angle fixer. How did you test your changes? I think I used fake data that contained two alternative routes. That helped me to find the threshold values for the penalties. I also used real world OSM data to check special cases like roundabouts or *_link roads. Unfortunately it is very difficult to create unit tests for this, and the risk is high that a change improves 10 cases but worsens another 10, esp. with other styles or in other countries. Maybe there is only one way to find out. I commit your patch and we wait for comments here or in the Garmin forum... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 20. Oktober 2020 10:46 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings Hi Gerd Yes, with --x-ignore-sharp-angles, the compactDirs format is disabled. Some of the example problems I looked at behaved much better when not using compactDirs, so it seemed reasonable, to avoid more developer "- -x-" type options, to have it this way. I thought about having another option to control this when "ignore -sharp-angles", with options to force on, force off and auto mode that looks for the cases of 2 roads being in the same sector or where the road continuation isn't in the opposite sector but some other way is. I can do something like this if you think it worthwhile. Ticker On Tue, 2020-10-20 at 08:10 +0000, Gerd Petermann wrote:
Hi Ticker,
sorry for the delay. I've started to compare the results of the patched and the original version. I think there might be a problem with --x-ignore-sharp-angles. I assume that patch disables the compact dirs when this undocument option is used?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Mittwoch, 14. Oktober 2020 19:26 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings
Hi Ticker,
thanks for the patch. I'll have a closer look at the weekend.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 14. Oktober 2020 10:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings
Hi Gerd
I've been looking at turn pop-ups and routing decisions and attach a patch that makes improvements:
Move decision about when to use compactDir initialHeadings from RouteNode to AngleChecker. The current code checks if any headings from a RouteNode share the same compactDir/4-bit sector and, if so, revert to the full/8-bit value. Overlaid roads triggered this, also sharp angles that couldn't be widened, probably when many paths converge at a road.
AngleChecker::fixSharpAngles was coded on the basis that compactDirs are used and it tested/increased angles based on this 4-bit step, but if these are then represented in 8-bit format, the encode angle could be much (up to 22.5 degrees) less that the code was expecting and result in turning delays in route calculations.
Recode fixSharpAngles to work in degrees but choose the thresholds to be good for compactDirs. Test the resultant angles and only use compactDirs if there are no roads in the same or adjacent 4-bit sectors. Not allowing Adjacent is necessary because, in compactDirs format, if there is a path in the opposite sector to the road and the road continuation is the adjacent sector, Garmin gives a "turn to stay on road" pop-up, but with 8-bit headings it doesn't. This is slightly different from the following case because this concerns an angle that doesn't need to be "unsharpened" as it isn't permitted for vehicles to make this turn.
When increasing an angle, change the heading of the lower class/speed road in preference to the major road. This helps prevent the "turn to stay on road" type pop-ups when the lead-off road was more straight-on than the main road and one-way tagging possibly missing.
Handle simple (<= 2 RouteArcs) RouteNodes as special cases, giving slight efficiency improvements.
Add some diagnostics for showing RouteNodes and RouteArcs in an area.
Tidy up normalisation of headings.
Fix some bugs.
Ticker
_______________________________________________ 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
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd With sharp-angle code enabled, most junctions will get compactDirs; just a few less than the existing code. Original gmapsupp.img for my test area was 9801728 and with this change it is 4096 bytes bigger. I looked at some of the NodCheck angle errors and decided that not much could be done as it only has the low-res road points to work with. In mkgmap, the algo using hi-res points gave a good angle in all the cases I looked at, so the code is now really there to deal with real sharp junctions that cause the time penalty and misleading direction pop-ups. I had a list of troublesome junctions and looked at the angles in 8-bit and 4-bit format before & after my changes to see that it was doing as expected. I also looked the leg-time info from MapSource for various routes. Since then I've been using it a lot for car routing and it hasn't done anything that I've disagreed with. It seemed that you had determined that there was no benefit in increasing angles so that there was more than 1 empty sector between vehicle arcs, so I just did the same such that it was also guaranteed to work if the junction went non-compact for some other reason - an angle of 23 degrees, say the arcs were at -11.5 and +11.5, would considered non-sharp in compact format but is sharp in 8-bit format. Ticker On Tue, 2020-10-20 at 09:25 +0000, Gerd Petermann wrote:
Hi Ticker,
my understanding is that original Garmin maps use compact dirs a lot, so I think it is not a good idea to disable them. My problem with the patch is that NodCheck complains a lot more Steve and I are not sure how Garmin calculates the encoded angles, so we are still just guessing. Your approach might well be the best so far. The code in NodCheck has one big problem: It uses the data stored in RGN to calculate the bearings, and that means 24 bit precision. So for nearby nodes the rounding errors are too big and NodCheck uses a fallback algo which selects another point. I guess Garmin also calculates the NOD data with more than 24 bit precision, so they probably also have some kind of angle fixer. How did you test your changes? I think I used fake data that contained two alternative routes. That helped me to find the threshold values for the penalties. I also used real world OSM data to check special cases like roundabouts or *_link roads. Unfortunately it is very difficult to create unit tests for this, and the risk is high that a change improves 10 cases but worsens another 10, esp. with other styles or in other countries.
Maybe there is only one way to find out. I commit your patch and we wait for comments here or in the Garmin forum...
Gerd
Hi Ticker, OK, I believe that you tested it well with the default style? Did you also try a style that adds multiple routable ways for one OSM way? Not sure if Felix still uses this for his maps on https://www.velomap.org/ but in the past this lead to all kinds of special cases that do not appear with the default style. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 20. Oktober 2020 14:30 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings Hi Gerd With sharp-angle code enabled, most junctions will get compactDirs; just a few less than the existing code. Original gmapsupp.img for my test area was 9801728 and with this change it is 4096 bytes bigger. I looked at some of the NodCheck angle errors and decided that not much could be done as it only has the low-res road points to work with. In mkgmap, the algo using hi-res points gave a good angle in all the cases I looked at, so the code is now really there to deal with real sharp junctions that cause the time penalty and misleading direction pop-ups. I had a list of troublesome junctions and looked at the angles in 8-bit and 4-bit format before & after my changes to see that it was doing as expected. I also looked the leg-time info from MapSource for various routes. Since then I've been using it a lot for car routing and it hasn't done anything that I've disagreed with. It seemed that you had determined that there was no benefit in increasing angles so that there was more than 1 empty sector between vehicle arcs, so I just did the same such that it was also guaranteed to work if the junction went non-compact for some other reason - an angle of 23 degrees, say the arcs were at -11.5 and +11.5, would considered non-sharp in compact format but is sharp in 8-bit format. Ticker On Tue, 2020-10-20 at 09:25 +0000, Gerd Petermann wrote:
Hi Ticker,
my understanding is that original Garmin maps use compact dirs a lot, so I think it is not a good idea to disable them. My problem with the patch is that NodCheck complains a lot more Steve and I are not sure how Garmin calculates the encoded angles, so we are still just guessing. Your approach might well be the best so far. The code in NodCheck has one big problem: It uses the data stored in RGN to calculate the bearings, and that means 24 bit precision. So for nearby nodes the rounding errors are too big and NodCheck uses a fallback algo which selects another point. I guess Garmin also calculates the NOD data with more than 24 bit precision, so they probably also have some kind of angle fixer. How did you test your changes? I think I used fake data that contained two alternative routes. That helped me to find the threshold values for the penalties. I also used real world OSM data to check special cases like roundabouts or *_link roads. Unfortunately it is very difficult to create unit tests for this, and the risk is high that a change improves 10 cases but worsens another 10, esp. with other styles or in other countries.
Maybe there is only one way to find out. I commit your patch and we wait for comments here or in the Garmin forum...
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd I kept the existing logic that takes all arcs within one degree and treats them as one (and fixed the extra case where they straddle +-180) so there should be no difference in this aspect. Ticker On Tue, 2020-10-20 at 12:48 +0000, Gerd Petermann wrote:
Hi Ticker,
OK, I believe that you tested it well with the default style? Did you also try a style that adds multiple routable ways for one OSM way? Not sure if Felix still uses this for his maps on https://www.velomap.org/ but in the past this lead to all kinds of special cases that do not appear with the default style.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 20. Oktober 2020 14:30 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings
Hi Gerd
With sharp-angle code enabled, most junctions will get compactDirs; just a few less than the existing code. Original gmapsupp.img for my test area was 9801728 and with this change it is 4096 bytes bigger.
I looked at some of the NodCheck angle errors and decided that not much could be done as it only has the low-res road points to work with.
In mkgmap, the algo using hi-res points gave a good angle in all the cases I looked at, so the code is now really there to deal with real sharp junctions that cause the time penalty and misleading direction pop-ups.
I had a list of troublesome junctions and looked at the angles in 8 -bit and 4-bit format before & after my changes to see that it was doing as expected. I also looked the leg-time info from MapSource for various routes. Since then I've been using it a lot for car routing and it hasn't done anything that I've disagreed with.
It seemed that you had determined that there was no benefit in increasing angles so that there was more than 1 empty sector between vehicle arcs, so I just did the same such that it was also guaranteed to work if the junction went non-compact for some other reason - an angle of 23 degrees, say the arcs were at -11.5 and +11.5, would considered non-sharp in compact format but is sharp in 8-bit format.
Ticker
On Tue, 2020-10-20 at 09:25 +0000, Gerd Petermann wrote:
Hi Ticker,
my understanding is that original Garmin maps use compact dirs a lot, so I think it is not a good idea to disable them. My problem with the patch is that NodCheck complains a lot more Steve and I are not sure how Garmin calculates the encoded angles, so we are still just guessing. Your approach might well be the best so far. The code in NodCheck has one big problem: It uses the data stored in RGN to calculate the bearings, and that means 24 bit precision. So for nearby nodes the rounding errors are too big and NodCheck uses a fallback algo which selects another point. I guess Garmin also calculates the NOD data with more than 24 bit precision, so they probably also have some kind of angle fixer. How did you test your changes? I think I used fake data that contained two alternative routes. That helped me to find the threshold values for the penalties. I also used real world OSM data to check special cases like roundabouts or *_link roads. Unfortunately it is very difficult to create unit tests for this, and the risk is high that a change improves 10 cases but worsens another 10, esp. with other styles or in other countries.
Maybe there is only one way to find out. I commit your patch and we wait for comments here or in the Garmin forum...
Gerd
_______________________________________________ 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
Hi Ticker, OK, let's try it. Some cleanup is needed. I see - hard coded tests like if (isClose(51.182575, -1.388928, 0.002)) - dead code: getImgAngle() is not used Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 20. Oktober 2020 15:21 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings Hi Gerd I kept the existing logic that takes all arcs within one degree and treats them as one (and fixed the extra case where they straddle +-180) so there should be no difference in this aspect. Ticker On Tue, 2020-10-20 at 12:48 +0000, Gerd Petermann wrote:
Hi Ticker,
OK, I believe that you tested it well with the default style? Did you also try a style that adds multiple routable ways for one OSM way? Not sure if Felix still uses this for his maps on https://www.velomap.org/ but in the past this lead to all kinds of special cases that do not appear with the default style.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 20. Oktober 2020 14:30 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings
Hi Gerd
With sharp-angle code enabled, most junctions will get compactDirs; just a few less than the existing code. Original gmapsupp.img for my test area was 9801728 and with this change it is 4096 bytes bigger.
I looked at some of the NodCheck angle errors and decided that not much could be done as it only has the low-res road points to work with.
In mkgmap, the algo using hi-res points gave a good angle in all the cases I looked at, so the code is now really there to deal with real sharp junctions that cause the time penalty and misleading direction pop-ups.
I had a list of troublesome junctions and looked at the angles in 8 -bit and 4-bit format before & after my changes to see that it was doing as expected. I also looked the leg-time info from MapSource for various routes. Since then I've been using it a lot for car routing and it hasn't done anything that I've disagreed with.
It seemed that you had determined that there was no benefit in increasing angles so that there was more than 1 empty sector between vehicle arcs, so I just did the same such that it was also guaranteed to work if the junction went non-compact for some other reason - an angle of 23 degrees, say the arcs were at -11.5 and +11.5, would considered non-sharp in compact format but is sharp in 8-bit format.
Ticker
On Tue, 2020-10-20 at 09:25 +0000, Gerd Petermann wrote:
Hi Ticker,
my understanding is that original Garmin maps use compact dirs a lot, so I think it is not a good idea to disable them. My problem with the patch is that NodCheck complains a lot more Steve and I are not sure how Garmin calculates the encoded angles, so we are still just guessing. Your approach might well be the best so far. The code in NodCheck has one big problem: It uses the data stored in RGN to calculate the bearings, and that means 24 bit precision. So for nearby nodes the rounding errors are too big and NodCheck uses a fallback algo which selects another point. I guess Garmin also calculates the NOD data with more than 24 bit precision, so they probably also have some kind of angle fixer. How did you test your changes? I think I used fake data that contained two alternative routes. That helped me to find the threshold values for the penalties. I also used real world OSM data to check special cases like roundabouts or *_link roads. Unfortunately it is very difficult to create unit tests for this, and the risk is high that a change improves 10 cases but worsens another 10, esp. with other styles or in other countries.
Maybe there is only one way to find out. I commit your patch and we wait for comments here or in the Garmin forum...
Gerd
_______________________________________________ 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
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd I've deleted the dead code and commented out the node/arc investigation code - it isn't "hard coded tests", rather a harness of a useful diagnostic to see what is happening with the routing structures in geographical areas and some examples of how to use it. It was under the control of: uk.me.parabola.imgfmt.app.net.AngleChecker.level=INFO Also clarified some comments about indirect arcs and their headings. Patch attached Ticker On Tue, 2020-10-20 at 13:32 +0000, Gerd Petermann wrote:
Hi Ticker,
OK, let's try it. Some cleanup is needed. I see - hard coded tests like if (isClose(51.182575, -1.388928, 0.002)) - dead code: getImgAngle() is not used
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 20. Oktober 2020 15:21 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings
Hi Gerd
I kept the existing logic that takes all arcs within one degree and treats them as one (and fixed the extra case where they straddle + -180) so there should be no difference in this aspect.
Ticker
On Tue, 2020-10-20 at 12:48 +0000, Gerd Petermann wrote:
Hi Ticker,
OK, I believe that you tested it well with the default style? Did you also try a style that adds multiple routable ways for one OSM way? Not sure if Felix still uses this for his maps on https://www.velomap.org/ but in the past this lead to all kinds of special cases that do not appear with the default style.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 20. Oktober 2020 14:30 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings
Hi Gerd
With sharp-angle code enabled, most junctions will get compactDirs; just a few less than the existing code. Original gmapsupp.img for my test area was 9801728 and with this change it is 4096 bytes bigger.
I looked at some of the NodCheck angle errors and decided that not much could be done as it only has the low-res road points to work with.
In mkgmap, the algo using hi-res points gave a good angle in all the cases I looked at, so the code is now really there to deal with real sharp junctions that cause the time penalty and misleading direction pop-ups.
I had a list of troublesome junctions and looked at the angles in 8 -bit and 4-bit format before & after my changes to see that it was doing as expected. I also looked the leg-time info from MapSource for various routes. Since then I've been using it a lot for car routing and it hasn't done anything that I've disagreed with.
It seemed that you had determined that there was no benefit in increasing angles so that there was more than 1 empty sector between vehicle arcs, so I just did the same such that it was also guaranteed to work if the junction went non-compact for some other reason - an angle of 23 degrees, say the arcs were at -11.5 and +11.5, would considered non-sharp in compact format but is sharp in 8-bit format.
Ticker
On Tue, 2020-10-20 at 09:25 +0000, Gerd Petermann wrote:
Hi Ticker,
my understanding is that original Garmin maps use compact dirs a lot, so I think it is not a good idea to disable them. My problem with the patch is that NodCheck complains a lot more Steve and I are not sure how Garmin calculates the encoded angles, so we are still just guessing. Your approach might well be the best so far. The code in NodCheck has one big problem: It uses the data stored in RGN to calculate the bearings, and that means 24 bit precision. So for nearby nodes the rounding errors are too big and NodCheck uses a fallback algo which selects another point. I guess Garmin also calculates the NOD data with more than 24 bit precision, so they probably also have some kind of angle fixer. How did you test your changes? I think I used fake data that contained two alternative routes. That helped me to find the threshold values for the penalties. I also used real world OSM data to check special cases like roundabouts or *_link roads. Unfortunately it is very difficult to create unit tests for this, and the risk is high that a change improves 10 cases but worsens another 10, esp. with other styles or in other countries.
Maybe there is only one way to find out. I commit your patch and we wait for comments here or in the Garmin forum...
Gerd
_______________________________________________ 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
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
participants (2)
-
Gerd Petermann -
Ticker Berkin