Bad routing on eTrex and MapSource
Hi Gerd I've assembled the data to demonstrate a major routing failure. It might be relate to the problems you are investigating but might not. I noticed this problem a while ago and it fails on r4295. eTrex/MapSource: fastest time - it takes a long detour shortest distance - it goes the wrong way and makes a u-turn BaseCamp (r4561): either mode - it goes the wrong way and makes a u-turn BaseCamp behaviour has changed over the last few svn changes. Some versions have worked correctly. In the route details, some of the leg bearings look suspect. Inverting the route gives correct results. Here is a minimal map: http://files.mkgmap.org.uk/download/487/74200072.osm.pbf and the resultant .img I generate: http://files.mkgmap.org.uk/download/486/74200072.img .gpx file with start/end points and MapSource fastest route are attached, also .sh script. I've been testing it with an old default style (from r4295) but it fails in the same way with the current default style Ticker
Hi Ticker, I used the style from r4295 and your options and an unpatched r4561, but my *.img file is a bit different and I see no problems in Basecamp 4.7.1, but I can reproduce the long detour in MapSource. Maybe a difference in the bounds file, but more likely you use a patched version of the style or the binary. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 9. Juli 2020 13:09 An: mkgmap development Betreff: [mkgmap-dev] Bad routing on eTrex and MapSource Hi Gerd I've assembled the data to demonstrate a major routing failure. It might be relate to the problems you are investigating but might not. I noticed this problem a while ago and it fails on r4295. eTrex/MapSource: fastest time - it takes a long detour shortest distance - it goes the wrong way and makes a u-turn BaseCamp (r4561): either mode - it goes the wrong way and makes a u-turn BaseCamp behaviour has changed over the last few svn changes. Some versions have worked correctly. In the route details, some of the leg bearings look suspect. Inverting the route gives correct results. Here is a minimal map: http://files.mkgmap.org.uk/download/487/74200072.osm.pbf and the resultant .img I generate: http://files.mkgmap.org.uk/download/486/74200072.img .gpx file with start/end points and MapSource fastest route are attached, also .sh script. I've been testing it with an old default style (from r4295) but it fails in the same way with the current default style Ticker
Hi Gerd I've just: 1/ checked that was using clean build of r4561 - yes I was 2/ changed back from current default style to r4295 - I've had identical results with both of these 3/ removed options --bounds=.. and --location-autofill 4/ added option --series-name=castleCourt and the behaviour has changed! MapSource gives correct route forward/inverted time & distance BaseCamp gives correct route forward time & distance but for inverted it goes the wrong way and makes a u-turn (but a different wrong way from before) My BaseCamp version is 4.7.2 Ticker On Thu, 2020-07-09 at 13:00 +0000, Gerd Petermann wrote:
Hi Ticker,
I used the style from r4295 and your options and an unpatched r4561, but my *.img file is a bit different and I see no problems in Basecamp 4.7.1, but I can reproduce the long detour in MapSource. Maybe a difference in the bounds file, but more likely you use a patched version of the style or the binary.
Gerd
Hi Ticker, without bounds the program probably doesn't set the drive-on-left flag, so you should set option --drive-on=left to get similar results. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 9. Juli 2020 16:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource Hi Gerd I've just: 1/ checked that was using clean build of r4561 - yes I was 2/ changed back from current default style to r4295 - I've had identical results with both of these 3/ removed options --bounds=.. and --location-autofill 4/ added option --series-name=castleCourt and the behaviour has changed! MapSource gives correct route forward/inverted time & distance BaseCamp gives correct route forward time & distance but for inverted it goes the wrong way and makes a u-turn (but a different wrong way from before) My BaseCamp version is 4.7.2 Ticker On Thu, 2020-07-09 at 13:00 +0000, Gerd Petermann wrote:
Hi Ticker,
I used the style from r4295 and your options and an unpatched r4561, but my *.img file is a bit different and I see no problems in Basecamp 4.7.1, but I can reproduce the long detour in MapSource. Maybe a difference in the bounds file, but more likely you use a patched version of the style or the binary.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Yes, setting drive on left changes the behaviour back to as described at 12:03 (but it don't why) Ticker On Thu, 2020-07-09 at 14:32 +0000, Gerd Petermann wrote:
Hi Ticker,
without bounds the program probably doesn't set the drive-on-left flag, so you should set option --drive-on=left to get similar results.
Gerd
Hi Ticker, I also don't understand the results in MapSource but I could not find anything wrong in the img data. I also didn't see anything wrong in the route directions. What value looks suspicious to you? My current thinking is that you found an error in the Garmin software. I think it overweighs the two right turns (in a drive-on-left country) Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 9. Juli 2020 17:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource Yes, setting drive on left changes the behaviour back to as described at 12:03 (but it don't why) Ticker On Thu, 2020-07-09 at 14:32 +0000, Gerd Petermann wrote:
Hi Ticker,
without bounds the program probably doesn't set the drive-on-left flag, so you should set option --drive-on=left to get similar results.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd There is something very wrong here with the routing here. Apart from this example, I've never experienced the device taking a long detour to avoid right turns. Testing with BaseCamp and shortest distance on MapSource, the route goes the wrong way and makes a u-turn - see attached BaseCamp trace - do you see this behaviour. What could be a similar problem I discovered the other day was a secondary road with a right turn into a alley to a car park. The device and MapSource wanted to turn into the alley, do a u-turn, then turn right out of the alley and continue on the road. BaseCamp took a 5 km detour to avoid going past the alley. I've also attached my modified test script. Ticker On Thu, 2020-07-09 at 15:40 +0000, Gerd Petermann wrote:
Hi Ticker,
I also don't understand the results in MapSource but I could not find anything wrong in the img data. I also didn't see anything wrong in the route directions. What value looks suspicious to you? My current thinking is that you found an error in the Garmin software. I think it overweighs the two right turns (in a drive-on -left country)
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 9. Juli 2020 17:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource
Yes, setting drive on left changes the behaviour back to as described at 12:03 (but it don't why)
Ticker
On Thu, 2020-07-09 at 14:32 +0000, Gerd Petermann wrote:
Hi Ticker,
without bounds the program probably doesn't set the drive-on-left flag, so you should set option --drive-on=left to get similar results.
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, I've updated Basecamp to 4.7.2 now. When I change the car profile to "shortest way" I also see the long detour, so yes, that makes it more likely that mkgmap writes wrong data. Not sure if I tested this wtih 4.7.1 I'll try to find the trigger for this. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 10. Juli 2020 09:08 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource Hi Gerd There is something very wrong here with the routing here. Apart from this example, I've never experienced the device taking a long detour to avoid right turns. Testing with BaseCamp and shortest distance on MapSource, the route goes the wrong way and makes a u-turn - see attached BaseCamp trace - do you see this behaviour. What could be a similar problem I discovered the other day was a secondary road with a right turn into a alley to a car park. The device and MapSource wanted to turn into the alley, do a u-turn, then turn right out of the alley and continue on the road. BaseCamp took a 5 km detour to avoid going past the alley. I've also attached my modified test script. Ticker On Thu, 2020-07-09 at 15:40 +0000, Gerd Petermann wrote:
Hi Ticker,
I also don't understand the results in MapSource but I could not find anything wrong in the img data. I also didn't see anything wrong in the route directions. What value looks suspicious to you? My current thinking is that you found an error in the Garmin software. I think it overweighs the two right turns (in a drive-on -left country)
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 9. Juli 2020 17:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource
Yes, setting drive on left changes the behaviour back to as described at 12:03 (but it don't why)
Ticker
On Thu, 2020-07-09 at 14:32 +0000, Gerd Petermann wrote:
Hi Ticker,
without bounds the program probably doesn't set the drive-on-left flag, so you should set option --drive-on=left to get similar results.
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, it seems to be related to the encoding of the heading / bearing data. I've reduced the test case to a few roads (see attached file) which still show the problem. When I rotate this small set of data a little bit the problem disappears. Will continue later... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 10. Juli 2020 09:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource Hi Ticker, OK, I've updated Basecamp to 4.7.2 now. When I change the car profile to "shortest way" I also see the long detour, so yes, that makes it more likely that mkgmap writes wrong data. Not sure if I tested this wtih 4.7.1 I'll try to find the trigger for this. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 10. Juli 2020 09:08 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource Hi Gerd There is something very wrong here with the routing here. Apart from this example, I've never experienced the device taking a long detour to avoid right turns. Testing with BaseCamp and shortest distance on MapSource, the route goes the wrong way and makes a u-turn - see attached BaseCamp trace - do you see this behaviour. What could be a similar problem I discovered the other day was a secondary road with a right turn into a alley to a car park. The device and MapSource wanted to turn into the alley, do a u-turn, then turn right out of the alley and continue on the road. BaseCamp took a 5 km detour to avoid going past the alley. I've also attached my modified test script. Ticker On Thu, 2020-07-09 at 15:40 +0000, Gerd Petermann wrote:
Hi Ticker,
I also don't understand the results in MapSource but I could not find anything wrong in the img data. I also didn't see anything wrong in the route directions. What value looks suspicious to you? My current thinking is that you found an error in the Garmin software. I think it overweighs the two right turns (in a drive-on -left country)
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 9. Juli 2020 17:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource
Yes, setting drive on left changes the behaviour back to as described at 12:03 (but it don't why)
Ticker
On Thu, 2020-07-09 at 14:32 +0000, Gerd Petermann wrote:
Hi Ticker,
without bounds the program probably doesn't set the drive-on-left flag, so you should set option --drive-on=left to get similar results.
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
Wow - that is a simplification. I was initially confused because both BaseCamp and Mapsource show the old, full map, despite it having been renamed, but show the routes between the 9 nodes in your minimal test map. Ticker On Fri, 2020-07-10 at 11:13 +0000, Gerd Petermann wrote:
Hi Ticker,
it seems to be related to the encoding of the heading / bearing data. I've reduced the test case to a few roads (see attached file) which still show the problem. When I rotate this small set of data a little bit the problem disappears.
Will continue later...
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 10. Juli 2020 09:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource
Hi Ticker,
OK, I've updated Basecamp to 4.7.2 now. When I change the car profile to "shortest way" I also see the long detour, so yes, that makes it more likely that mkgmap writes wrong data. Not sure if I tested this wtih 4.7.1
I'll try to find the trigger for this.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 10. Juli 2020 09:08 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource
Hi Gerd
There is something very wrong here with the routing here.
Apart from this example, I've never experienced the device taking a long detour to avoid right turns. Testing with BaseCamp and shortest distance on MapSource, the route goes the wrong way and makes a u -turn - see attached BaseCamp trace - do you see this behaviour.
What could be a similar problem I discovered the other day was a secondary road with a right turn into a alley to a car park. The device and MapSource wanted to turn into the alley, do a u-turn, then turn right out of the alley and continue on the road. BaseCamp took a 5 km detour to avoid going past the alley.
I've also attached my modified test script.
Ticker
On Thu, 2020-07-09 at 15:40 +0000, Gerd Petermann wrote:
Hi Ticker,
I also don't understand the results in MapSource but I could not find anything wrong in the img data. I also didn't see anything wrong in the route directions. What value looks suspicious to you? My current thinking is that you found an error in the Garmin software. I think it overweighs the two right turns (in a drive-on -left country)
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 9. Juli 2020 17:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource
Yes, setting drive on left changes the behaviour back to as described at 12:03 (but it don't why)
Ticker
On Thu, 2020-07-09 at 14:32 +0000, Gerd Petermann wrote:
Hi Ticker,
without bounds the program probably doesn't set the drive-on-left flag, so you should set option --drive-on=left to get similar results.
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
Hi Ticker, I still have no clue where to change something :( Routing works fine for pedestrian mode and all the shown values like length or directions look correct, so it seems that the encoded values are interpreted as expected. I've also tried things like mirroring all the data on the vertical axis. Results were exactly the same after I also changed drive-on=left to drive-on=right. Problem disappears when the length of the arc between node 712553226 and node 5691769367 is a bit longer, e.g. 33m instead of ~30m so that it is encoded with the next higher byte value. When I change the geometry so that the arc is even shorter it doesn't seem to help. It really looks like Garmin doesn't like to make to left turns within less than ~32 m when shortest route is selected and traffic mode is not pedestrian. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Samstag, 11. Juli 2020 13:20 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource Wow - that is a simplification. I was initially confused because both BaseCamp and Mapsource show the old, full map, despite it having been renamed, but show the routes between the 9 nodes in your minimal test map. Ticker On Fri, 2020-07-10 at 11:13 +0000, Gerd Petermann wrote:
Hi Ticker,
it seems to be related to the encoding of the heading / bearing data. I've reduced the test case to a few roads (see attached file) which still show the problem. When I rotate this small set of data a little bit the problem disappears.
Will continue later...
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 10. Juli 2020 09:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource
Hi Ticker,
OK, I've updated Basecamp to 4.7.2 now. When I change the car profile to "shortest way" I also see the long detour, so yes, that makes it more likely that mkgmap writes wrong data. Not sure if I tested this wtih 4.7.1
I'll try to find the trigger for this.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 10. Juli 2020 09:08 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource
Hi Gerd
There is something very wrong here with the routing here.
Apart from this example, I've never experienced the device taking a long detour to avoid right turns. Testing with BaseCamp and shortest distance on MapSource, the route goes the wrong way and makes a u -turn - see attached BaseCamp trace - do you see this behaviour.
What could be a similar problem I discovered the other day was a secondary road with a right turn into a alley to a car park. The device and MapSource wanted to turn into the alley, do a u-turn, then turn right out of the alley and continue on the road. BaseCamp took a 5 km detour to avoid going past the alley.
I've also attached my modified test script.
Ticker
On Thu, 2020-07-09 at 15:40 +0000, Gerd Petermann wrote:
Hi Ticker,
I also don't understand the results in MapSource but I could not find anything wrong in the img data. I also didn't see anything wrong in the route directions. What value looks suspicious to you? My current thinking is that you found an error in the Garmin software. I think it overweighs the two right turns (in a drive-on -left country)
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 9. Juli 2020 17:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource
Yes, setting drive on left changes the behaviour back to as described at 12:03 (but it don't why)
Ticker
On Thu, 2020-07-09 at 14:32 +0000, Gerd Petermann wrote:
Hi Ticker,
without bounds the program probably doesn't set the drive-on-left flag, so you should set option --drive-on=left to get similar results.
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
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, My findings so far: Attached are small demo files that show the problem with Basecamp routing. With demo.osm Basecamp refuses to route the shortest way in one direction and doesn't in the other when start and tartget are on the same side of road A. It also prefers the detour with "faster time" for one direction, with demo-more-than-32.osm it always takes the shorter way because the distance between the two ways is a bit longer. The problem also disappears when there is a curve on the ~30 m arc (mkgmap writes different NOD data for this) . I still have no idea if this is an error in the data written by mkgmap or if there is a special case in the Basecamp routing algo. While one can argue that a right turn can take long in a drive-on-left country one would expect that this should have no or only a small effect on the calculation of the "shorter distance". OTOH Garmin doesn't claim that it calculates the shortest route, it is only a "Route Preference". Options to use: --route --preserve-element-order --drive-on=left If you use option --drive-on=right the results are reverted, means, you have to also revert the route to see the same results. Maybe those who have an original routable Garmin map can try to find a similar case in their map and report if the routing works or not. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Samstag, 11. Juli 2020 18:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource Hi Ticker, I still have no clue where to change something :( Routing works fine for pedestrian mode and all the shown values like length or directions look correct, so it seems that the encoded values are interpreted as expected. I've also tried things like mirroring all the data on the vertical axis. Results were exactly the same after I also changed drive-on=left to drive-on=right. Problem disappears when the length of the arc between node 712553226 and node 5691769367 is a bit longer, e.g. 33m instead of ~30m so that it is encoded with the next higher byte value. When I change the geometry so that the arc is even shorter it doesn't seem to help. It really looks like Garmin doesn't like to make to left turns within less than ~32 m when shortest route is selected and traffic mode is not pedestrian. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Samstag, 11. Juli 2020 13:20 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource Wow - that is a simplification. I was initially confused because both BaseCamp and Mapsource show the old, full map, despite it having been renamed, but show the routes between the 9 nodes in your minimal test map. Ticker On Fri, 2020-07-10 at 11:13 +0000, Gerd Petermann wrote:
Hi Ticker,
it seems to be related to the encoding of the heading / bearing data. I've reduced the test case to a few roads (see attached file) which still show the problem. When I rotate this small set of data a little bit the problem disappears.
Will continue later...
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 10. Juli 2020 09:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource
Hi Ticker,
OK, I've updated Basecamp to 4.7.2 now. When I change the car profile to "shortest way" I also see the long detour, so yes, that makes it more likely that mkgmap writes wrong data. Not sure if I tested this wtih 4.7.1
I'll try to find the trigger for this.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 10. Juli 2020 09:08 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource
Hi Gerd
There is something very wrong here with the routing here.
Apart from this example, I've never experienced the device taking a long detour to avoid right turns. Testing with BaseCamp and shortest distance on MapSource, the route goes the wrong way and makes a u -turn - see attached BaseCamp trace - do you see this behaviour.
What could be a similar problem I discovered the other day was a secondary road with a right turn into a alley to a car park. The device and MapSource wanted to turn into the alley, do a u-turn, then turn right out of the alley and continue on the road. BaseCamp took a 5 km detour to avoid going past the alley.
I've also attached my modified test script.
Ticker
On Thu, 2020-07-09 at 15:40 +0000, Gerd Petermann wrote:
Hi Ticker,
I also don't understand the results in MapSource but I could not find anything wrong in the img data. I also didn't see anything wrong in the route directions. What value looks suspicious to you? My current thinking is that you found an error in the Garmin software. I think it overweighs the two right turns (in a drive-on -left country)
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 9. Juli 2020 17:12 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource
Yes, setting drive on left changes the behaviour back to as described at 12:03 (but it don't why)
Ticker
On Thu, 2020-07-09 at 14:32 +0000, Gerd Petermann wrote:
Hi Ticker,
without bounds the program probably doesn't set the drive-on-left flag, so you should set option --drive-on=left to get similar results.
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
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 wonder if a combination of the closeness and parallelness of the roads containing the start & end points persuade the Garmin software that it is a dual-carriageway (having failed to notice both are bi -directional) and incorrect data in mkgmap output is being taken as a restriction to stop the joining road being used for an extended u-turn. Later, probably won't be until tomorrow, I'll try assemble the data for my other case where the routing is simply forced off the main road, down an alley, u-turn, back into main road in original direction. I'll also look for a similar configuration of roads elsewhere and test the behaviour on BaseCamp/MapSource Ticker On Sun, 2020-07-12 at 07:59 +0000, Gerd Petermann wrote:
Hi all,
My findings so far:
Attached are small demo files that show the problem with Basecamp routing. With demo.osm Basecamp refuses to route the shortest way in one direction and doesn't in the other when start and tartget are on the same side of road A. It also prefers the detour with "faster time" for one direction, with demo-more-than-32.osm it always takes the shorter way because the distance between the two ways is a bit longer. The problem also disappears when there is a curve on the ~30 m arc (mkgmap writes different NOD data for this) .
I still have no idea if this is an error in the data written by mkgmap or if there is a special case in the Basecamp routing algo. While one can argue that a right turn can take long in a drive-on -left country one would expect that this should have no or only a small effect on the calculation of the "shorter distance". OTOH Garmin doesn't claim that it calculates the shortest route, it is only a "Route Preference".
Options to use: --route --preserve-element-order --drive-on=left If you use option --drive-on=right the results are reverted, means, you have to also revert the route to see the same results.
Maybe those who have an original routable Garmin map can try to find a similar case in their map and report if the routing works or not.
Gerd
Hi Ticker, yes, handling of dual-carriageways might be a reason for this. I might have found a way to circumvent this problem: If I make sure that arc lengths with an encoded value below 7 are increased to 7 the problem disappears. Interesting thing is that Basecamp and Mapsource still show the real values, so obviously the reported values depend on the data in RGN, not that in NOD. I think I already learned that in the past but I forgot about it. Maybe values below 7 have a special meaning, maybe they should be encoded in a different way. Patch needs more testing for unwanted side effects... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Sonntag, 12. Juli 2020 10:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource Hi Gerd I wonder if a combination of the closeness and parallelness of the roads containing the start & end points persuade the Garmin software that it is a dual-carriageway (having failed to notice both are bi -directional) and incorrect data in mkgmap output is being taken as a restriction to stop the joining road being used for an extended u-turn. Later, probably won't be until tomorrow, I'll try assemble the data for my other case where the routing is simply forced off the main road, down an alley, u-turn, back into main road in original direction. I'll also look for a similar configuration of roads elsewhere and test the behaviour on BaseCamp/MapSource Ticker On Sun, 2020-07-12 at 07:59 +0000, Gerd Petermann wrote:
Hi all,
My findings so far:
Attached are small demo files that show the problem with Basecamp routing. With demo.osm Basecamp refuses to route the shortest way in one direction and doesn't in the other when start and tartget are on the same side of road A. It also prefers the detour with "faster time" for one direction, with demo-more-than-32.osm it always takes the shorter way because the distance between the two ways is a bit longer. The problem also disappears when there is a curve on the ~30 m arc (mkgmap writes different NOD data for this) .
I still have no idea if this is an error in the data written by mkgmap or if there is a special case in the Basecamp routing algo. While one can argue that a right turn can take long in a drive-on -left country one would expect that this should have no or only a small effect on the calculation of the "shorter distance". OTOH Garmin doesn't claim that it calculates the shortest route, it is only a "Route Preference".
Options to use: --route --preserve-element-order --drive-on=left If you use option --drive-on=right the results are reverted, means, you have to also revert the route to see the same results.
Maybe those who have an original routable Garmin map can try to find a similar case in their map and report if the routing works or not.
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Haven't had a chance yet to build this and investigate, but forget my other problem; just found this: https://www.openstreetmap.org/relation/7403805 Ticker On Sun, 2020-07-12 at 09:13 +0000, Gerd Petermann wrote:
Hi Ticker,
yes, handling of dual-carriageways might be a reason for this. I might have found a way to circumvent this problem: If I make sure that arc lengths with an encoded value below 7 are increased to 7 the problem disappears. Interesting thing is that Basecamp and Mapsource still show the real values, so obviously the reported values depend on the data in RGN, not that in NOD. I think I already learned that in the past but I forgot about it.
Maybe values below 7 have a special meaning, maybe they should be encoded in a different way. Patch needs more testing for unwanted side effects...
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Sonntag, 12. Juli 2020 10:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource
Hi Gerd
I wonder if a combination of the closeness and parallelness of the roads containing the start & end points persuade the Garmin software that it is a dual-carriageway (having failed to notice both are bi -directional) and incorrect data in mkgmap output is being taken as a restriction to stop the joining road being used for an extended u -turn.
Later, probably won't be until tomorrow, I'll try assemble the data for my other case where the routing is simply forced off the main road, down an alley, u-turn, back into main road in original direction.
I'll also look for a similar configuration of roads elsewhere and test the behaviour on BaseCamp/MapSource
Ticker
On Sun, 2020-07-12 at 07:59 +0000, Gerd Petermann wrote:
Hi all,
My findings so far:
Attached are small demo files that show the problem with Basecamp routing. With demo.osm Basecamp refuses to route the shortest way in one direction and doesn't in the other when start and tartget are on the same side of road A. It also prefers the detour with "faster time" for one direction, with demo-more-than-32.osm it always takes the shorter way because the distance between the two ways is a bit longer. The problem also disappears when there is a curve on the ~30 m arc (mkgmap writes different NOD data for this) .
I still have no idea if this is an error in the data written by mkgmap or if there is a special case in the Basecamp routing algo. While one can argue that a right turn can take long in a drive-on -left country one would expect that this should have no or only a small effect on the calculation of the "shorter distance". OTOH Garmin doesn't claim that it calculates the shortest route, it is only a "Route Preference".
Options to use: --route --preserve-element-order --drive-on=left If you use option --drive-on=right the results are reverted, means, you have to also revert the route to see the same results.
Maybe those who have an original routable Garmin map can try to find a similar case in their map and report if the routing works or not.
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, okay, good to know. BTW: the problem is not the encoded length value, when I change the multiplier in NodHeader to different values it shows that the length is the threshold. Might be 10 feet. The simple patch is probably not the solution, NodCheck complains a lot and the error also doesn't always occur in my "normal" maps. So the length is not the only trigger and I am pretty sure that it would produce unwanted effects in other situations. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Sonntag, 12. Juli 2020 16:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource Hi Gerd Haven't had a chance yet to build this and investigate, but forget my other problem; just found this: https://www.openstreetmap.org/relation/7403805 Ticker On Sun, 2020-07-12 at 09:13 +0000, Gerd Petermann wrote:
Hi Ticker,
yes, handling of dual-carriageways might be a reason for this. I might have found a way to circumvent this problem: If I make sure that arc lengths with an encoded value below 7 are increased to 7 the problem disappears. Interesting thing is that Basecamp and Mapsource still show the real values, so obviously the reported values depend on the data in RGN, not that in NOD. I think I already learned that in the past but I forgot about it.
Maybe values below 7 have a special meaning, maybe they should be encoded in a different way. Patch needs more testing for unwanted side effects...
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Sonntag, 12. Juli 2020 10:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource
Hi Gerd
I wonder if a combination of the closeness and parallelness of the roads containing the start & end points persuade the Garmin software that it is a dual-carriageway (having failed to notice both are bi -directional) and incorrect data in mkgmap output is being taken as a restriction to stop the joining road being used for an extended u -turn.
Later, probably won't be until tomorrow, I'll try assemble the data for my other case where the routing is simply forced off the main road, down an alley, u-turn, back into main road in original direction.
I'll also look for a similar configuration of roads elsewhere and test the behaviour on BaseCamp/MapSource
Ticker
On Sun, 2020-07-12 at 07:59 +0000, Gerd Petermann wrote:
Hi all,
My findings so far:
Attached are small demo files that show the problem with Basecamp routing. With demo.osm Basecamp refuses to route the shortest way in one direction and doesn't in the other when start and tartget are on the same side of road A. It also prefers the detour with "faster time" for one direction, with demo-more-than-32.osm it always takes the shorter way because the distance between the two ways is a bit longer. The problem also disappears when there is a curve on the ~30 m arc (mkgmap writes different NOD data for this) .
I still have no idea if this is an error in the data written by mkgmap or if there is a special case in the Basecamp routing algo. While one can argue that a right turn can take long in a drive-on -left country one would expect that this should have no or only a small effect on the calculation of the "shorter distance". OTOH Garmin doesn't claim that it calculates the shortest route, it is only a "Route Preference".
Options to use: --route --preserve-element-order --drive-on=left If you use option --drive-on=right the results are reverted, means, you have to also revert the route to see the same results.
Maybe those who have an original routable Garmin map can try to find a similar case in their map and report if the routing works or not.
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 Ticker, I think we have to live with this problem. I found the same error with original Garmin demo maps, e.g. "Topo Deutschland" from 2010 tile 16608746.img. MapSource calculates a big detour, Basecamp doesn't. Inverted route is short in both programs: 1. Rheinstraße 0 m 0:00:00 N53.01308 E8.77969 2. Get on Rheinstraße and drive north 0 m 0 m 0:00:00 0:00:00 180° grid N53.01308 E8.77969 3. Turn right onto Neckarstraße 13 m 13 m 0:00:01 0:00:01 17° grid N53.01317 E8.77973 4. Turn right onto Ahrstraße 32 m 19 m 0:00:08 0:00:09 99° grid N53.01315 E8.78001 5. Ahrstraße 44 m 12 m 0:00:13 0:00:22 180° grid N53.01306 E8.78005 I did not find a route restriction or oneway road which would explain this. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Sonntag, 12. Juli 2020 20:32 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource Hi Ticker, okay, good to know. BTW: the problem is not the encoded length value, when I change the multiplier in NodHeader to different values it shows that the length is the threshold. Might be 10 feet. The simple patch is probably not the solution, NodCheck complains a lot and the error also doesn't always occur in my "normal" maps. So the length is not the only trigger and I am pretty sure that it would produce unwanted effects in other situations. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Sonntag, 12. Juli 2020 16:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource Hi Gerd Haven't had a chance yet to build this and investigate, but forget my other problem; just found this: https://www.openstreetmap.org/relation/7403805 Ticker On Sun, 2020-07-12 at 09:13 +0000, Gerd Petermann wrote:
Hi Ticker,
yes, handling of dual-carriageways might be a reason for this. I might have found a way to circumvent this problem: If I make sure that arc lengths with an encoded value below 7 are increased to 7 the problem disappears. Interesting thing is that Basecamp and Mapsource still show the real values, so obviously the reported values depend on the data in RGN, not that in NOD. I think I already learned that in the past but I forgot about it.
Maybe values below 7 have a special meaning, maybe they should be encoded in a different way. Patch needs more testing for unwanted side effects...
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Sonntag, 12. Juli 2020 10:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource
Hi Gerd
I wonder if a combination of the closeness and parallelness of the roads containing the start & end points persuade the Garmin software that it is a dual-carriageway (having failed to notice both are bi -directional) and incorrect data in mkgmap output is being taken as a restriction to stop the joining road being used for an extended u -turn.
Later, probably won't be until tomorrow, I'll try assemble the data for my other case where the routing is simply forced off the main road, down an alley, u-turn, back into main road in original direction.
I'll also look for a similar configuration of roads elsewhere and test the behaviour on BaseCamp/MapSource
Ticker
On Sun, 2020-07-12 at 07:59 +0000, Gerd Petermann wrote:
Hi all,
My findings so far:
Attached are small demo files that show the problem with Basecamp routing. With demo.osm Basecamp refuses to route the shortest way in one direction and doesn't in the other when start and tartget are on the same side of road A. It also prefers the detour with "faster time" for one direction, with demo-more-than-32.osm it always takes the shorter way because the distance between the two ways is a bit longer. The problem also disappears when there is a curve on the ~30 m arc (mkgmap writes different NOD data for this) .
I still have no idea if this is an error in the data written by mkgmap or if there is a special case in the Basecamp routing algo. While one can argue that a right turn can take long in a drive-on -left country one would expect that this should have no or only a small effect on the calculation of the "shorter distance". OTOH Garmin doesn't claim that it calculates the shortest route, it is only a "Route Preference".
Options to use: --route --preserve-element-order --drive-on=left If you use option --drive-on=right the results are reverted, means, you have to also revert the route to see the same results.
Maybe those who have an original routable Garmin map can try to find a similar case in their map and report if the routing works or not.
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
Hi Gerd That's a shame, thanks for all the investigating. This is normally only a problem at the start & end of journeys. Is "no-arcs-first.patch" going to become part of trunk? Ticker On Mon, 2020-07-13 at 05:43 +0000, Gerd Petermann wrote:
Hi Ticker,
I think we have to live with this problem. I found the same error with original Garmin demo maps, e.g. "Topo Deutschland" from 2010 tile 16608746.img. MapSource calculates a big detour, Basecamp doesn't. Inverted route is short in both programs: 1. Rheinstraße 0 m 0:00:00 N53.01308 E8.77969 2. Get on Rheinstraße and drive north 0 m 0 m 0:00:00 0:00:00 180° grid N53.01308 E8.77969 3. Turn right onto Neckarstraße 13 m 13 m 0:00:01 0:00:01 17° grid N53.01317 E8.77973 4. Turn right onto Ahrstraße 32 m 19 m 0:00:08 0:00:09 99° grid N53.01315 E8.78001 5. Ahrstraße 44 m 12 m 0:00:13 0:00:22 180° grid N53.01306 E8.78005
I did not find a route restriction or oneway road which would explain this.
Gerd
Hi Ticker, reg no-arcs-first.patch: It only has an effect when you use --x-no-force-end-nodes-routing-nodes and I am not sure yet about its effects. I have to do more testing of the special case reported by Felix. I've not yet understood how to avoid the special case which crashes NodCheck. A single node without arcs will still produce this crash. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 13. Juli 2020 09:51 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource Hi Gerd That's a shame, thanks for all the investigating. This is normally only a problem at the start & end of journeys. Is "no-arcs-first.patch" going to become part of trunk? Ticker On Mon, 2020-07-13 at 05:43 +0000, Gerd Petermann wrote:
Hi Ticker,
I think we have to live with this problem. I found the same error with original Garmin demo maps, e.g. "Topo Deutschland" from 2010 tile 16608746.img. MapSource calculates a big detour, Basecamp doesn't. Inverted route is short in both programs: 1. Rheinstraße 0 m 0:00:00 N53.01308 E8.77969 2. Get on Rheinstraße and drive north 0 m 0 m 0:00:00 0:00:00 180° grid N53.01308 E8.77969 3. Turn right onto Neckarstraße 13 m 13 m 0:00:01 0:00:01 17° grid N53.01317 E8.77973 4. Turn right onto Ahrstraße 32 m 19 m 0:00:08 0:00:09 99° grid N53.01315 E8.78001 5. Ahrstraße 44 m 12 m 0:00:13 0:00:22 180° grid N53.01306 E8.78005
I did not find a route restriction or oneway road which would explain this.
Gerd
_______________________________________________ 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