Hi Gerd Thanks for investigating this. As the eTrex routing seems to work (maybe it is more similar to Mapsource than Basecamp) I'll persist with island removal. Looking at display:NetCheck errors, it looks like the RoadDef.netFlags bit: RoadDef: public static final int NET_FLAG_ADDRINFO = 0x10; display: private static final int RD_HAS_STREET_ADDRESS_INFO = 0x10; and/or nodeCountInner isn't getting set correctly when island-removal happens to the road. Ticker On Thu, 2019-11-21 at 10:00 +0000, Gerd Petermann wrote:

Hi Ticker,

I think we have two different problems here. I can reproduce the errors with display tool even with very small input files and it seems that it existed in almost all versions of the NET-no-NOD branch :-( I have no idea why I didn't see it in various tests before. These problems disappear when I change the code so that the first and last node in a road are always routing nodes. (as it was before r4300) Maybe display tool simply expects this and searches for nodes which don't exist? On the other hand I can reproduce the routing problems with Basecamp (4.7.1), but not with MapSource. And the problems in Basecamp do not disappear when I change the code to add the nodes again, they seem to depend on option --check-routing-island-len only. I always thought that Garmin uses the same routing algo in Mapsource and Basecamp, but at least 4.7.1 shows that I am wrong.

So, for now, I'd say that option --check-routing-island-len should not be used :(

Gerd

Hi Ticker, the attached patch for mkgmap makes display tool happy again but it doesn't solve the routing problems in Basecamp. I still try to find a reason for the routing problems, maybe it simply doesn't like roads without NOD info in a routable map, maybe your two tiles are very special... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 21. November 2019 15:42 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes Hi Ticker, I'm still investigating. I think display tool fails when it finds nodes in NOD without any arcs. With the current code this happens e.g. for way 23989284 in 74210002.osm.pbf, a highway way near the tile boundary, with only one node in the tile and no connection to other roads in the tile. I am not yet sure where to fix that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 21. November 2019 14:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes Hi Gerd Thanks for investigating this. As the eTrex routing seems to work (maybe it is more similar to Mapsource than Basecamp) I'll persist with island removal. Looking at display:NetCheck errors, it looks like the RoadDef.netFlags bit: RoadDef: public static final int NET_FLAG_ADDRINFO = 0x10; display: private static final int RD_HAS_STREET_ADDRESS_INFO = 0x10; and/or nodeCountInner isn't getting set correctly when island-removal happens to the road. Ticker On Thu, 2019-11-21 at 10:00 +0000, Gerd Petermann wrote:

Hi Ticker,

I think we have two different problems here. I can reproduce the errors with display tool even with very small input files and it seems that it existed in almost all versions of the NET-no-NOD branch :-( I have no idea why I didn't see it in various tests before. These problems disappear when I change the code so that the first and last node in a road are always routing nodes. (as it was before r4300) Maybe display tool simply expects this and searches for nodes which don't exist? On the other hand I can reproduce the routing problems with Basecamp (4.7.1), but not with MapSource. And the problems in Basecamp do not disappear when I change the code to add the nodes again, they seem to depend on option --check-routing-island-len only. I always thought that Garmin uses the same routing algo in Mapsource and Basecamp, but at least 4.7.1 shows that I am wrong.

So, for now, I'd say that option --check-routing-island-len should not be used :(

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 Gerd That's interesting. What effect does this ordering have on the resultant NET/NOD/RGN ordering and contents? Should the RouteCenters have the same contents? I've been trying to decipher the way these are written and there is a lot of leaving space for later writing once offsets are known, so if some sizes or counts are not what the logic expects, it could cause apparently random problems depending ordering. Looking at the errors at the end of NodCheck:

ERROR: class boundary node:f81c5: not sorted ERROR: node 35bdd: high class boundary node not included in NOD 4 [1,] the first happens with older releases, before the NET-no-NOD merge, but the next is new. NodCheck might just be running off the end of that section of the file, but I was trying to work out group logic was processing road-class for NODs that would be dropped

Ticker On Fri, 2019-11-22 at 10:44 +0000, Gerd Petermann wrote:

Hi Ticker,

some news: I am able to reproduce the routing problems in Basecamp with a rather small input file and the default style. The involved route is very short. The interesting point is this: When I use this command the routing problem appears: --check-routing-island-len=700 --route --gmapi --preserve-element -order ticker-part-mod.osm When I remove the option --preserve-element-order the problem disappears. --check-routing-island-len=700 --route --gmapi ticker-part-mod.osm

The data contains an island which appears as first way in the input file. When I move it before the first relation routing works also with --preserve-element-order, so order seems important. Open question is what needs to be sorted...

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 21. November 2019 19:52 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Ticker,

the attached patch for mkgmap makes display tool happy again but it doesn't solve the routing problems in Basecamp.

I still try to find a reason for the routing problems, maybe it simply doesn't like roads without NOD info in a routable map, maybe your two tiles are very special...

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 21. November 2019 15:42 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Ticker,

I'm still investigating. I think display tool fails when it finds nodes in NOD without any arcs. With the current code this happens e.g. for way 23989284 in 74210002.osm.pbf, a highway way near the tile boundary, with only one node in the tile and no connection to other roads in the tile. I am not yet sure where to fix that.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 21. November 2019 14:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Gerd

Thanks for investigating this. As the eTrex routing seems to work (maybe it is more similar to Mapsource than Basecamp) I'll persist with island removal.

Looking at display:NetCheck errors, it looks like the RoadDef.netFlags bit: RoadDef: public static final int NET_FLAG_ADDRINFO = 0x10; display: private static final int RD_HAS_STREET_ADDRESS_INFO = 0x10; and/or nodeCountInner isn't getting set correctly when island-removal happens to the road.

Ticker

On Thu, 2019-11-21 at 10:00 +0000, Gerd Petermann wrote:

...

Hi Ticker,

I think we have two different problems here. I can reproduce the errors with display tool even with very small input files and it seems that it existed in almost all versions of the NET-no-NOD branch :-( I have no idea why I didn't see it in various tests before. These problems disappear when I change the code so that the first and last node in a road are always routing nodes. (as it was before r4300) Maybe display tool simply expects this and searches for nodes which don't exist? On the other hand I can reproduce the routing problems with Basecamp (4.7.1), but not with MapSource. And the problems in Basecamp do not disappear when I change the code to add the nodes again, they seem to depend on option --check-routing-island-len only. I always thought that Garmin uses the same routing algo in Mapsource and Basecamp, but at least 4.7.1 shows that I am wrong.

So, for now, I'd say that option --check-routing-island-len should not be used :(

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, attached is a patch which improves routing for my small sample with only one island. It also fixes some of the problems reported by display tool by calling the island detection before writing RGN. Still, it doesn't help at all with your test case. I did not see any effect on routing when I changed the order of roads in NET. So, order in RGN is important, but maybe the problem is not the order within one subdiv, maybe it would be better to change the split process so that non-routable roads (those with skipAddToNOD() == true) are in different sub divisions. The sample is here: http://files.mkgmap.org.uk/download/456/ticker-part-mod.zip Maybe you want to play with that, I'll continue tomorrow... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 22. November 2019 12:57 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes Hi Ticker, Reg. order: All files (RGN, NET, NOD) show changes when the order changes. Strange thing is that Basecamp doesn't fail to calculate the route for other vehicles. I also looked at those messages from NodCheck. I think it doesn't handle the case that two boundary nodes appear at the same (Garmin) location. Anyhow, in my reduced data this message is not displayed and still routing fails. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 22. November 2019 12:17 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes Hi Gerd That's interesting. What effect does this ordering have on the resultant NET/NOD/RGN ordering and contents? Should the RouteCenters have the same contents? I've been trying to decipher the way these are written and there is a lot of leaving space for later writing once offsets are known, so if some sizes or counts are not what the logic expects, it could cause apparently random problems depending ordering. Looking at the errors at the end of NodCheck:

ERROR: class boundary node:f81c5: not sorted ERROR: node 35bdd: high class boundary node not included in NOD 4 [1,] the first happens with older releases, before the NET-no-NOD merge, but the next is new. NodCheck might just be running off the end of that section of the file, but I was trying to work out group logic was processing road-class for NODs that would be dropped

Ticker On Fri, 2019-11-22 at 10:44 +0000, Gerd Petermann wrote:

Hi Ticker,

some news: I am able to reproduce the routing problems in Basecamp with a rather small input file and the default style. The involved route is very short. The interesting point is this: When I use this command the routing problem appears: --check-routing-island-len=700 --route --gmapi --preserve-element -order ticker-part-mod.osm When I remove the option --preserve-element-order the problem disappears. --check-routing-island-len=700 --route --gmapi ticker-part-mod.osm

The data contains an island which appears as first way in the input file. When I move it before the first relation routing works also with --preserve-element-order, so order seems important. Open question is what needs to be sorted...

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 21. November 2019 19:52 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Ticker,

the attached patch for mkgmap makes display tool happy again but it doesn't solve the routing problems in Basecamp.

I still try to find a reason for the routing problems, maybe it simply doesn't like roads without NOD info in a routable map, maybe your two tiles are very special...

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 21. November 2019 15:42 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Ticker,

I'm still investigating. I think display tool fails when it finds nodes in NOD without any arcs. With the current code this happens e.g. for way 23989284 in 74210002.osm.pbf, a highway way near the tile boundary, with only one node in the tile and no connection to other roads in the tile. I am not yet sure where to fix that.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 21. November 2019 14:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Gerd

Thanks for investigating this. As the eTrex routing seems to work (maybe it is more similar to Mapsource than Basecamp) I'll persist with island removal.

Looking at display:NetCheck errors, it looks like the RoadDef.netFlags bit: RoadDef: public static final int NET_FLAG_ADDRINFO = 0x10; display: private static final int RD_HAS_STREET_ADDRESS_INFO = 0x10; and/or nodeCountInner isn't getting set correctly when island-removal happens to the road.

Ticker

On Thu, 2019-11-21 at 10:00 +0000, Gerd Petermann wrote:

...

Hi Ticker,

I think we have two different problems here. I can reproduce the errors with display tool even with very small input files and it seems that it existed in almost all versions of the NET-no-NOD branch :-( I have no idea why I didn't see it in various tests before. These problems disappear when I change the code so that the first and last node in a road are always routing nodes. (as it was before r4300) Maybe display tool simply expects this and searches for nodes which don't exist? On the other hand I can reproduce the routing problems with Basecamp (4.7.1), but not with MapSource. And the problems in Basecamp do not disappear when I change the code to add the nodes again, they seem to depend on option --check-routing-island-len only. I always thought that Garmin uses the same routing algo in Mapsource and Basecamp, but at least 4.7.1 shows that I am wrong.

So, for now, I'd say that option --check-routing-island-len should not be used :(

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 also saw routing errors in Mapsource with my sample and the --preserve-element-order activated. I think the Basecamp dialog shows some options which are not really available in non-NT maps, maybe there is a wrong fallback so that motorcycle routing works like pedestrian or maybe bicycle routing. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 22. November 2019 17:48 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes Hi Gerd I'll build this and experiment. Reg. previous email - Basecamp generating routes for MotorCycle is very strange. I tried setting all the attributes of Motorcar to the same as Motorcycle and it made no difference, so the must be some unknown bits in the img that mkgmap isn't getting quite right. Ticker On Fri, 2019-11-22 at 16:41 +0000, Gerd Petermann wrote:

Hi Ticker,

attached is a patch which improves routing for my small sample with only one island. It also fixes some of the problems reported by display tool by calling the island detection before writing RGN. Still, it doesn't help at all with your test case. I did not see any effect on routing when I changed the order of roads in NET. So, order in RGN is important, but maybe the problem is not the order within one subdiv, maybe it would be better to change the split process so that non-routable roads (those with skipAddToNOD() == true) are in different sub divisions.

The sample is here: http://files.mkgmap.org.uk/download/456/ticker-part-mod.zip

Maybe you want to play with that, I'll continue tomorrow...

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 22. November 2019 12:57 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Ticker,

Reg. order: All files (RGN, NET, NOD) show changes when the order changes. Strange thing is that Basecamp doesn't fail to calculate the route for other vehicles.

I also looked at those messages from NodCheck. I think it doesn't handle the case that two boundary nodes appear at the same (Garmin) location. Anyhow, in my reduced data this message is not displayed and still routing fails.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 22. November 2019 12:17 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Gerd

That's interesting. What effect does this ordering have on the resultant NET/NOD/RGN ordering and contents? Should the RouteCenters have the same contents?

I've been trying to decipher the way these are written and there is a lot of leaving space for later writing once offsets are known, so if some sizes or counts are not what the logic expects, it could cause apparently random problems depending ordering.

Looking at the errors at the end of NodCheck:

...

ERROR: class boundary node:f81c5: not sorted ERROR: node 35bdd: high class boundary node not included in NOD 4 [1,] the first happens with older releases, before the NET-no-NOD merge, but the next is new. NodCheck might just be running off the end of that section of the file, but I was trying to work out group logic was processing road-class for NODs that would be dropped

Ticker

On Fri, 2019-11-22 at 10:44 +0000, Gerd Petermann wrote:

...

Hi Ticker,

some news: I am able to reproduce the routing problems in Basecamp with a rather small input file and the default style. The involved route is very short. The interesting point is this: When I use this command the routing problem appears: --check-routing-island-len=700 --route --gmapi --preserve-element -order ticker-part-mod.osm When I remove the option --preserve-element-order the problem disappears. --check-routing-island-len=700 --route --gmapi ticker-part-mod.osm

The data contains an island which appears as first way in the input file. When I move it before the first relation routing works also with --preserve-element-order, so order seems important. Open question is what needs to be sorted...

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 21. November 2019 19:52 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Ticker,

the attached patch for mkgmap makes display tool happy again but it doesn't solve the routing problems in Basecamp.

I still try to find a reason for the routing problems, maybe it simply doesn't like roads without NOD info in a routable map, maybe your two tiles are very special...

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 21. November 2019 15:42 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Ticker,

I'm still investigating. I think display tool fails when it finds nodes in NOD without any arcs. With the current code this happens e.g. for way 23989284 in 74210002.osm.pbf, a highway way near the tile boundary, with only one node in the tile and no connection to other roads in the tile. I am not yet sure where to fix that.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 21. November 2019 14:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Gerd

Thanks for investigating this. As the eTrex routing seems to work (maybe it is more similar to Mapsource than Basecamp) I'll persist with island removal.

Looking at display:NetCheck errors, it looks like the RoadDef.netFlags bit: RoadDef: public static final int NET_FLAG_ADDRINFO = 0x10; display: private static final int RD_HAS_STREET_ADDRESS_INFO = 0x10; and/or nodeCountInner isn't getting set correctly when island -removal happens to the road.

Ticker

On Thu, 2019-11-21 at 10:00 +0000, Gerd Petermann wrote:

...

Hi Ticker,

I think we have two different problems here. I can reproduce the errors with display tool even with very small input files and it seems that it existed in almost all versions of the NET-no-NOD branch :-( I have no idea why I didn't see it in various tests before. These problems disappear when I change the code so that the first and last node in a road are always routing nodes. (as it was before r4300) Maybe display tool simply expects this and searches for nodes which don't exist? On the other hand I can reproduce the routing problems with Basecamp (4.7.1), but not with MapSource. And the problems in Basecamp do not disappear when I change the code to add the nodes again, they seem to depend on option --check-routing-island-len only. I always thought that Garmin uses the same routing algo in Mapsource and Basecamp, but at least 4.7.1 shows that I am wrong.

So, for now, I'd say that option --check-routing-island-len should not be used :(

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 Gerd I was wondering if the problem related to this and was going to try some experiments. eg just changing just type. I think there is some scope in adding 0x50 to it; one of my devices shows these, but with an added direction. But maybe it's being in the road structures that Basecamp does't like. If this is the case it becomes much more complicated and maybe not worth doing; and probably better just to keep the option as it is but document the incompatibility. I still think, given the random nature of the failures, that there is as slightly incorrect structure being generated somewhere, and I've been going through the code looking at positioning, padding for alignments etc. Ticker On Sat, 2019-11-23 at 09:09 +0000, Gerd Petermann wrote:

Hi Ticker,

I looked at some Garmin demo maps and I found no case where a road appeared in NET but not in NOD, so I think it should better not be done. No idea what problem it causes, but the Garmin software is probably not prepared to handle this case and fails to build internal data structure. I think we see a similar effect with the routable types without NET info (e.g. when you use line type 0x16 without road_class or road_speed).

So, I think we should remove the documentation and also the code as it is now. Maybe the island detection could work in a very different way. My current thinking is that it could work like the special tags mkgmap:set_unconnected_type=<type> and mkgmap:set_semi_connected_type=<type> So, instead of adding those special tags to various lines in the style we might use a simple replacement table containing the replacement type (or "none") for each routable type. The table might be a new style file containing something like

# routing island replacement types 0x01: 0x10800 0x02: 0x10801 0x03: 0x10802 .... 0x07: none ...

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 22. November 2019 17:53 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Ticker,

I also saw routing errors in Mapsource with my sample and the - -preserve-element-order activated. I think the Basecamp dialog shows some options which are not really available in non-NT maps, maybe there is a wrong fallback so that motorcycle routing works like pedestrian or maybe bicycle routing.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 22. November 2019 17:48 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Gerd

I'll build this and experiment.

Reg. previous email - Basecamp generating routes for MotorCycle is very strange. I tried setting all the attributes of Motorcar to the same as Motorcycle and it made no difference, so the must be some unknown bits in the img that mkgmap isn't getting quite right.

Ticker

On Fri, 2019-11-22 at 16:41 +0000, Gerd Petermann wrote:

...

Hi Ticker,

attached is a patch which improves routing for my small sample with only one island. It also fixes some of the problems reported by display tool by calling the island detection before writing RGN. Still, it doesn't help at all with your test case. I did not see any effect on routing when I changed the order of roads in NET. So, order in RGN is important, but maybe the problem is not the order within one subdiv, maybe it would be better to change the split process so that non-routable roads (those with skipAddToNOD() == true) are in different sub divisions.

The sample is here: http://files.mkgmap.org.uk/download/456/ticker-part-mod.zip

Maybe you want to play with that, I'll continue tomorrow...

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 22. November 2019 12:57 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Ticker,

Reg. order: All files (RGN, NET, NOD) show changes when the order changes. Strange thing is that Basecamp doesn't fail to calculate the route for other vehicles.

I also looked at those messages from NodCheck. I think it doesn't handle the case that two boundary nodes appear at the same (Garmin) location. Anyhow, in my reduced data this message is not displayed and still routing fails.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 22. November 2019 12:17 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Gerd

That's interesting. What effect does this ordering have on the resultant NET/NOD/RGN ordering and contents? Should the RouteCenters have the same contents?

I've been trying to decipher the way these are written and there is a lot of leaving space for later writing once offsets are known, so if some sizes or counts are not what the logic expects, it could cause apparently random problems depending ordering.

Looking at the errors at the end of NodCheck:

...

ERROR: class boundary node:f81c5: not sorted ERROR: node 35bdd: high class boundary node not included in NOD 4 [1,] the first happens with older releases, before the NET-no-NOD merge, but the next is new. NodCheck might just be running off the end of that section of the file, but I was trying to work out group logic was processing road-class for NODs that would be dropped

Ticker

On Fri, 2019-11-22 at 10:44 +0000, Gerd Petermann wrote:

...

Hi Ticker,

some news: I am able to reproduce the routing problems in Basecamp with a rather small input file and the default style. The involved route is very short. The interesting point is this: When I use this command the routing problem appears: --check-routing-island-len=700 --route --gmapi --preserve-element -order ticker-part-mod.osm When I remove the option --preserve-element-order the problem disappears. --check-routing-island-len=700 --route --gmapi ticker-part -mod.osm

The data contains an island which appears as first way in the input file. When I move it before the first relation routing works also with --preserve-element-order, so order seems important. Open question is what needs to be sorted...

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 21. November 2019 19:52 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Ticker,

the attached patch for mkgmap makes display tool happy again but it doesn't solve the routing problems in Basecamp.

I still try to find a reason for the routing problems, maybe it simply doesn't like roads without NOD info in a routable map, maybe your two tiles are very special...

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 21. November 2019 15:42 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Ticker,

I'm still investigating. I think display tool fails when it finds nodes in NOD without any arcs. With the current code this happens e.g. for way 23989284 in 74210002.osm.pbf, a highway way near the tile boundary, with only one node in the tile and no connection to other roads in the tile. I am not yet sure where to fix that.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 21. November 2019 14:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Gerd

Thanks for investigating this. As the eTrex routing seems to work (maybe it is more similar to Mapsource than Basecamp) I'll persist with island removal.

Looking at display:NetCheck errors, it looks like the RoadDef.netFlags bit: RoadDef: public static final int NET_FLAG_ADDRINFO = 0x10; display: private static final int RD_HAS_STREET_ADDRESS_INFO = 0x10; and/or nodeCountInner isn't getting set correctly when island -removal happens to the road.

Ticker

On Thu, 2019-11-21 at 10:00 +0000, Gerd Petermann wrote:

...

Hi Ticker,

I think we have two different problems here. I can reproduce the errors with display tool even with very small input files and it seems that it existed in almost all versions of the NET-no-NOD branch :-( I have no idea why I didn't see it in various tests before. These problems disappear when I change the code so that the first and last node in a road are always routing nodes. (as it was before r4300) Maybe display tool simply expects this and searches for nodes which don't exist? On the other hand I can reproduce the routing problems with Basecamp (4.7.1), but not with MapSource. And the problems in Basecamp do not disappear when I change the code to add the nodes again, they seem to depend on option --check-routing-island-len only. I always thought that Garmin uses the same routing algo in Mapsource and Basecamp, but at least 4.7.1 shows that I am wrong.

So, for now, I'd say that option --check-routing-island-len should not be used :(

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 Ticker, okay, I was not able to reproduce the problem on my Oregon, and it turned out that the one routing problem in Mapsource was my fault, I asked for a route which was forbidden because of oneway roads. I think that means that nobody should use option --check-routing-island-len=INTEGER when they use BaseCamp or when they publish their maps unless we find a better implementation. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Samstag, 23. November 2019 11:56 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes Hi Ticker, OK, I'll ty to reproduce the routing error on my Oregon. If there is no problem on the device we might keep the option and document that it causes trouble with Mapsource and Basecamp, else I'll remove the code until we know better. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Samstag, 23. November 2019 11:30 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes Hi Gerd I was wondering if the problem related to this and was going to try some experiments. eg just changing just type. I think there is some scope in adding 0x50 to it; one of my devices shows these, but with an added direction. But maybe it's being in the road structures that Basecamp does't like. If this is the case it becomes much more complicated and maybe not worth doing; and probably better just to keep the option as it is but document the incompatibility. I still think, given the random nature of the failures, that there is as slightly incorrect structure being generated somewhere, and I've been going through the code looking at positioning, padding for alignments etc. Ticker On Sat, 2019-11-23 at 09:09 +0000, Gerd Petermann wrote:

Hi Ticker,

I looked at some Garmin demo maps and I found no case where a road appeared in NET but not in NOD, so I think it should better not be done. No idea what problem it causes, but the Garmin software is probably not prepared to handle this case and fails to build internal data structure. I think we see a similar effect with the routable types without NET info (e.g. when you use line type 0x16 without road_class or road_speed).

So, I think we should remove the documentation and also the code as it is now. Maybe the island detection could work in a very different way. My current thinking is that it could work like the special tags mkgmap:set_unconnected_type=<type> and mkgmap:set_semi_connected_type=<type> So, instead of adding those special tags to various lines in the style we might use a simple replacement table containing the replacement type (or "none") for each routable type. The table might be a new style file containing something like

# routing island replacement types 0x01: 0x10800 0x02: 0x10801 0x03: 0x10802 .... 0x07: none ...

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 22. November 2019 17:53 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Ticker,

I also saw routing errors in Mapsource with my sample and the - -preserve-element-order activated. I think the Basecamp dialog shows some options which are not really available in non-NT maps, maybe there is a wrong fallback so that motorcycle routing works like pedestrian or maybe bicycle routing.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 22. November 2019 17:48 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Gerd

I'll build this and experiment.

Reg. previous email - Basecamp generating routes for MotorCycle is very strange. I tried setting all the attributes of Motorcar to the same as Motorcycle and it made no difference, so the must be some unknown bits in the img that mkgmap isn't getting quite right.

Ticker

On Fri, 2019-11-22 at 16:41 +0000, Gerd Petermann wrote:

...

Hi Ticker,

attached is a patch which improves routing for my small sample with only one island. It also fixes some of the problems reported by display tool by calling the island detection before writing RGN. Still, it doesn't help at all with your test case. I did not see any effect on routing when I changed the order of roads in NET. So, order in RGN is important, but maybe the problem is not the order within one subdiv, maybe it would be better to change the split process so that non-routable roads (those with skipAddToNOD() == true) are in different sub divisions.

The sample is here: http://files.mkgmap.org.uk/download/456/ticker-part-mod.zip

Maybe you want to play with that, I'll continue tomorrow...

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 22. November 2019 12:57 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Ticker,

Reg. order: All files (RGN, NET, NOD) show changes when the order changes. Strange thing is that Basecamp doesn't fail to calculate the route for other vehicles.

I also looked at those messages from NodCheck. I think it doesn't handle the case that two boundary nodes appear at the same (Garmin) location. Anyhow, in my reduced data this message is not displayed and still routing fails.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 22. November 2019 12:17 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Gerd

That's interesting. What effect does this ordering have on the resultant NET/NOD/RGN ordering and contents? Should the RouteCenters have the same contents?

I've been trying to decipher the way these are written and there is a lot of leaving space for later writing once offsets are known, so if some sizes or counts are not what the logic expects, it could cause apparently random problems depending ordering.

Looking at the errors at the end of NodCheck:

...

ERROR: class boundary node:f81c5: not sorted ERROR: node 35bdd: high class boundary node not included in NOD 4 [1,] the first happens with older releases, before the NET-no-NOD merge, but the next is new. NodCheck might just be running off the end of that section of the file, but I was trying to work out group logic was processing road-class for NODs that would be dropped

Ticker

On Fri, 2019-11-22 at 10:44 +0000, Gerd Petermann wrote:

...

Hi Ticker,

some news: I am able to reproduce the routing problems in Basecamp with a rather small input file and the default style. The involved route is very short. The interesting point is this: When I use this command the routing problem appears: --check-routing-island-len=700 --route --gmapi --preserve-element -order ticker-part-mod.osm When I remove the option --preserve-element-order the problem disappears. --check-routing-island-len=700 --route --gmapi ticker-part -mod.osm

The data contains an island which appears as first way in the input file. When I move it before the first relation routing works also with --preserve-element-order, so order seems important. Open question is what needs to be sorted...

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 21. November 2019 19:52 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Ticker,

the attached patch for mkgmap makes display tool happy again but it doesn't solve the routing problems in Basecamp.

I still try to find a reason for the routing problems, maybe it simply doesn't like roads without NOD info in a routable map, maybe your two tiles are very special...

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 21. November 2019 15:42 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Ticker,

I'm still investigating. I think display tool fails when it finds nodes in NOD without any arcs. With the current code this happens e.g. for way 23989284 in 74210002.osm.pbf, a highway way near the tile boundary, with only one node in the tile and no connection to other roads in the tile. I am not yet sure where to fix that.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 21. November 2019 14:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Gerd

Thanks for investigating this. As the eTrex routing seems to work (maybe it is more similar to Mapsource than Basecamp) I'll persist with island removal.

Looking at display:NetCheck errors, it looks like the RoadDef.netFlags bit: RoadDef: public static final int NET_FLAG_ADDRINFO = 0x10; display: private static final int RD_HAS_STREET_ADDRESS_INFO = 0x10; and/or nodeCountInner isn't getting set correctly when island -removal happens to the road.

Ticker

On Thu, 2019-11-21 at 10:00 +0000, Gerd Petermann wrote:

...

Hi Ticker,

I think we have two different problems here. I can reproduce the errors with display tool even with very small input files and it seems that it existed in almost all versions of the NET-no-NOD branch :-( I have no idea why I didn't see it in various tests before. These problems disappear when I change the code so that the first and last node in a road are always routing nodes. (as it was before r4300) Maybe display tool simply expects this and searches for nodes which don't exist? On the other hand I can reproduce the routing problems with Basecamp (4.7.1), but not with MapSource. And the problems in Basecamp do not disappear when I change the code to add the nodes again, they seem to depend on option --check-routing-island-len only. I always thought that Garmin uses the same routing algo in Mapsource and Basecamp, but at least 4.7.1 shows that I am wrong.

So, for now, I'd say that option --check-routing-island-len should not be used :(

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

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, the reason for way -1477104 is simple: It is the only island when you use the default style and it appears as first way in the file. With option --preserve-element-order this seems to be a worst case scenario for BaseCamp. My understanding is that BaseCamp builds internal tables for road data and NOD data and that this fails when a road without NOD is processed before one that has NOD. So, my goal was to sort the data so that BC reads all the roads with NOD first. I gave up because I have no idea how exactly BC reads the data. It seems to ignore the order in NET, it seems to read the RGN file and uses the pointers to NET in it. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 26. November 2019 17:31 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes Hi Gerd I've trying various things, like changing the TYP, removing road -speed/class, ... to try and pin down this problem and generally, the behaviour got worse. I experimented a bit with your cut-down area: ticker-part-mod.zip but had problems. Way -1477104 confused me for a while. So I went back to the full tile. I've just updated to trunk latest r4387, removed all my changes and did a clean rebuild, then, with --check-routing-island=-1 tried lots of Motorcar routing in Basecamp and I find areas of my map still misbehave. EG: "so23 0je" > "so23 0ps" straight line to a road a few roads east then straight line back. "so23 0qb" > "so23 9ru" straight line. Generally, all routing fails around this small area, but other areas north and west work fine. The setup and data is identical to before but I've just been using the northern tile (74210002.osm.pbf) I'm just going to try some of these on the Device and pick some other areas with island=-1 on the ticker-part-mod Ticker On Mon, 2019-11-25 at 07:16 +0000, Gerd Petermann wrote:

Hi Ticker,

okay, I was not able to reproduce the problem on my Oregon, and it turned out that the one routing problem in Mapsource was my fault, I asked for a route which was forbidden because of oneway roads. I think that means that nobody should use option --check-routing -island-len=INTEGER when they use BaseCamp or when they publish their maps unless we find a better implementation.

Gerd

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Ticker, draw a +-shaped crossing with two ways and you'll have two ways where the first point is not converted to a node. I did not find any difference when I changed that back to the old behaviour (before the NET-no-NOD merge). See changes in StyledConverter in 4300 around line 1564. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 27. November 2019 13:17 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes Hi Gerd With a map generated without routing-island-removal, there are geographic areas where Basecamp routing fails, but I couldn't find any routing problems in the same areas with my eTrex or GPSMapEdit. I can't to any more today or tomorrow, but later I'll have a go at using the default style and reducing the area. My style adds lots of circular walkways that are often not connected to the main road network but, looking at the code, StyledConverted goes to some trouble to split these in 2 and to start with a routing node. What other cases are there where the routing node won't be the first on the road, which is what seems to be expected by Display and, maybe, Basecamp. one-way to/from nowhere? Ticker On Tue, 2019-11-26 at 16:58 +0000, Gerd Petermann wrote:

Hi Ticker,

the reason for way -1477104 is simple: It is the only island when you use the default style and it appears as first way in the file. With option --preserve-element-order this seems to be a worst case scenario for BaseCamp. My understanding is that BaseCamp builds internal tables for road data and NOD data and that this fails when a road without NOD is processed before one that has NOD. So, my goal was to sort the data so that BC reads all the roads with NOD first. I gave up because I have no idea how exactly BC reads the data. It seems to ignore the order in NET, it seems to read the RGN file and uses the pointers to NET in it.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 26. November 2019 17:31 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes

Hi Gerd

I've trying various things, like changing the TYP, removing road -speed/class, ... to try and pin down this problem and generally, the behaviour got worse.

I experimented a bit with your cut-down area: ticker-part-mod.zip but had problems. Way -1477104 confused me for a while. So I went back to the full tile.

I've just updated to trunk latest r4387, removed all my changes and did a clean rebuild, then, with --check-routing-island=-1 tried lots of Motorcar routing in Basecamp and I find areas of my map still misbehave.

EG: "so23 0je" > "so23 0ps" straight line to a road a few roads east then straight line back. "so23 0qb" > "so23 9ru" straight line.

Generally, all routing fails around this small area, but other areas north and west work fine.

The setup and data is identical to before but I've just been using the northern tile (74210002.osm.pbf)

I'm just going to try some of these on the Device and pick some other areas with island=-1 on the ticker-part-mod

Ticker

On Mon, 2019-11-25 at 07:16 +0000, Gerd Petermann wrote:

...

Hi Ticker,

okay, I was not able to reproduce the problem on my Oregon, and it turned out that the one routing problem in Mapsource was my fault, I asked for a route which was forbidden because of oneway roads. I think that means that nobody should use option --check-routing -island-len=INTEGER when they use BaseCamp or when they publish their maps unless we find a better implementation.

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