Really Serious bug when not using --route
There is a serious bug that breaks routable maps when --route is NOT given. This bug will in future break routing on most GPS devices and is already inflicting Mapsource 6.16.1 and Basecamp 3. This means that also if you compile maps that are not routable, you have to pass the --route parameter. Else the GPS / Mapsource looks into an empty NOD table and may crash. This will happen as soon as you mix routable maps with the non routable mkgmap created maps. The problem is that Mapsource and the GPS search for 63440000.NOD data (63440000 as an example placeholder for the mapname). "Falagar", a developer at Garmin said to release a fix for this bug in Mapsource 6.16.2 however mentioned that this fix will not be carried on to GPS devices and will still mean a deterioration of overall routing. I'm not sure what the exact problem for this is (I just tried even very old mkgmap versions like 858 and also there the problem arises) but currently this means that --route should be the compulsory for all map creation, also not routable ones. If you have old maps (eg transparent contourline maps) that are troublesome to rebuilt, then opening with gpsmapedit, saving as mp and recompiling passing --route parameter is enough to solve the problem. I think that until the bug is found, mkgmap should adopt --route as standard, because it may happen that if users put an mkgmap created without --route onto their GPS besides other routable maps, these maps might impact autorouting for the other routable maps (except if "deactivated" on the GPS).
On 23.05.2010 18:24, Felix Hartmann wrote:
There is a serious bug that breaks routable maps when --route is NOT given. This bug will in future break routing on most GPS devices and is already inflicting Mapsource 6.16.1 and Basecamp 3. This means that also if you compile maps that are not routable, you have to pass the --route parameter. Else the GPS / Mapsource looks into an empty NOD table and may crash. This will happen as soon as you mix routable maps with the non routable mkgmap created maps.
The problem is that Mapsource and the GPS search for 63440000.NOD data (63440000 as an example placeholder for the mapname). "Falagar", a developer at Garmin said to release a fix for this bug in Mapsource 6.16.2 however mentioned that this fix will not be carried on to GPS devices and will still mean a deterioration of overall routing.
I'm not sure what the exact problem for this is (I just tried even very old mkgmap versions like 858 and also there the problem arises) but currently this means that --route should be the compulsory for all map creation, also not routable ones. If you have old maps (eg transparent contourline maps) that are troublesome to rebuilt, then opening with gpsmapedit, saving as mp and recompiling passing --route parameter is enough to solve the problem.
I think that until the bug is found, mkgmap should adopt --route as standard, because it may happen that if users put an mkgmap created without --route onto their GPS besides other routable maps, these maps might impact autorouting for the other routable maps (except if "deactivated" on the GPS). Just as an update. I got the following answer from Falagar, concerning creating all maps with --route parameter:
/Naja, das ist halt nur ein Trick. Am besten waere es, die NOD-Flag zu entfernen, aber ich weiss nicht, ob ihr wisst, wo die ist. Ich weiss es leider auch nicht. Es koennte evtl. ein wenig langsamer sein, wenn MS & Geraet die Routinginformationen erst oeffnen muessen, bevor wir feststellen, dass da keine Info drin ist. Aber ich denke, das sollte erst einmal funktionieren. / Translation. This is only a trick. Best would be to completly remove the NOD-Flag, but I don't know whether you know where it is. Actually, I don't know it either. Eventually it could be a little bit slower if Mapsource & GPS first has to open the routing information, until it notices that there is no info inside. But I think this would do if for a beginning. So either someone finds the NOD flag (gmaptool also knows nothing about it, removing NOD data with gmaptool does not clear the NOD flag, ) and it will be deactivated when --route is not given, or we pass --route as mandatory, as we obviously miss something in the implementation. I will give some really old versions a go to see if they did it correctly and the bug got introduced with the advent of routing in mkgmap, and send a message if they worked correctly. If not then we probably set this flag since the beginning (but until recently this was no problem).
On 23.05.2010 20:22, Felix Hartmann wrote:
On 23.05.2010 18:24, Felix Hartmann wrote:
There is a serious bug that breaks routable maps when --route is NOT given. This bug will in future break routing on most GPS devices and is already inflicting Mapsource 6.16.1 and Basecamp 3. This means that also if you compile maps that are not routable, you have to pass the --route parameter. Else the GPS / Mapsource looks into an empty NOD table and may crash. This will happen as soon as you mix routable maps with the non routable mkgmap created maps.
The problem is that Mapsource and the GPS search for 63440000.NOD data (63440000 as an example placeholder for the mapname). "Falagar", a developer at Garmin said to release a fix for this bug in Mapsource 6.16.2 however mentioned that this fix will not be carried on to GPS devices and will still mean a deterioration of overall routing.
I'm not sure what the exact problem for this is (I just tried even very old mkgmap versions like 858 and also there the problem arises) but currently this means that --route should be the compulsory for all map creation, also not routable ones. If you have old maps (eg transparent contourline maps) that are troublesome to rebuilt, then opening with gpsmapedit, saving as mp and recompiling passing --route parameter is enough to solve the problem.
I think that until the bug is found, mkgmap should adopt --route as standard, because it may happen that if users put an mkgmap created without --route onto their GPS besides other routable maps, these maps might impact autorouting for the other routable maps (except if "deactivated" on the GPS). Just as an update. I got the following answer from Falagar, concerning creating all maps with --route parameter:
/Naja, das ist halt nur ein Trick. Am besten waere es, die NOD-Flag zu entfernen, aber ich weiss nicht, ob ihr wisst, wo die ist. Ich weiss es leider auch nicht. Es koennte evtl. ein wenig langsamer sein, wenn MS & Geraet die Routinginformationen erst oeffnen muessen, bevor wir feststellen, dass da keine Info drin ist. Aber ich denke, das sollte erst einmal funktionieren. /
Translation. This is only a trick. Best would be to completly remove the NOD-Flag, but I don't know whether you know where it is. Actually, I don't know it either. Eventually it could be a little bit slower if Mapsource & GPS first has to open the routing information, until it notices that there is no info inside. But I think this would do if for a beginning.
So either someone finds the NOD flag (gmaptool also knows nothing about it, removing NOD data with gmaptool does not clear the NOD flag, ) and it will be deactivated when --route is not given, or we pass --route as mandatory, as we obviously miss something in the implementation. I will give some really old versions a go to see if they did it correctly and the bug got introduced with the advent of routing in mkgmap, and send a message if they worked correctly. If not then we probably set this flag since the beginning (but until recently this was no problem).
Okay, there is probably no need to search for the revision that introduced this bug. I went as far back as rev 500, and there the NOD flag is already set, which was before we got started with autorouting. Hence I assume we don't know about its existence, and it has been wrong from the start.
On 5/23/2010 2:54 PM, Felix Hartmann wrote:
There is a serious bug that breaks routable maps when --route is NOT given. This bug will in future break routing on most GPS devices and is already inflicting Mapsource 6.16.1 and Basecamp 3. This means that also if you compile maps that are not routable, you have to pass the --route parameter. Else the GPS / Mapsource looks into an empty NOD table and may crash. This will happen as soon as you mix routable maps with the non routable mkgmap created maps.
Felix,
If I understand correctly this will happen in the future? Where do you get Mapsource 6.16.1? Can you install it concurrently with another version of Mapsource? Thanks, N.
Hi
Okay, there is probably no need to search for the revision that introduced this bug. I went as far back as rev 500, and there the NOD flag is already set, which was before we got started with autorouting. Hence I assume we don't know about its existence, and it has been wrong from the start.
Yes we probably don't know about it. I can't remember having to set any of the unknown things differently when going to routing. It could be in the TDB file as that has more unknowns in it, but that is not transferred to the device - although it could affect what is sent to the device, so still less likely. ..Steve
Maybe it's this bit in the TDB-Header (HeaderBlock.java): os.write(1); // map is routable At least it looks strange that this bit is set regardless of the --route option, and there are similar flags related to DEM info in this block as well ... Best wishes Christian Felix Hartmann schrieb:
On 23.05.2010 18:24, Felix Hartmann wrote:
There is a serious bug that breaks routable maps when --route is NOT given. This bug will in future break routing on most GPS devices and is already inflicting Mapsource 6.16.1 and Basecamp 3. This means that also if you compile maps that are not routable, you have to pass the --route parameter. Else the GPS / Mapsource looks into an empty NOD table and may crash. This will happen as soon as you mix routable maps with the non routable mkgmap created maps.
The problem is that Mapsource and the GPS search for 63440000.NOD data (63440000 as an example placeholder for the mapname). "Falagar", a developer at Garmin said to release a fix for this bug in Mapsource 6.16.2 however mentioned that this fix will not be carried on to GPS devices and will still mean a deterioration of overall routing.
I'm not sure what the exact problem for this is (I just tried even very old mkgmap versions like 858 and also there the problem arises) but currently this means that --route should be the compulsory for all map creation, also not routable ones. If you have old maps (eg transparent contourline maps) that are troublesome to rebuilt, then opening with gpsmapedit, saving as mp and recompiling passing --route parameter is enough to solve the problem.
I think that until the bug is found, mkgmap should adopt --route as standard, because it may happen that if users put an mkgmap created without --route onto their GPS besides other routable maps, these maps might impact autorouting for the other routable maps (except if "deactivated" on the GPS). Just as an update. I got the following answer from Falagar, concerning creating all maps with --route parameter:
/Naja, das ist halt nur ein Trick. Am besten waere es, die NOD-Flag zu entfernen, aber ich weiss nicht, ob ihr wisst, wo die ist. Ich weiss es leider auch nicht. Es koennte evtl. ein wenig langsamer sein, wenn MS & Geraet die Routinginformationen erst oeffnen muessen, bevor wir feststellen, dass da keine Info drin ist. Aber ich denke, das sollte erst einmal funktionieren. /
Translation. This is only a trick. Best would be to completly remove the NOD-Flag, but I don't know whether you know where it is. Actually, I don't know it either. Eventually it could be a little bit slower if Mapsource & GPS first has to open the routing information, until it notices that there is no info inside. But I think this would do if for a beginning.
So either someone finds the NOD flag (gmaptool also knows nothing about it, removing NOD data with gmaptool does not clear the NOD flag, ) and it will be deactivated when --route is not given, or we pass --route as mandatory, as we obviously miss something in the implementation. I will give some really old versions a go to see if they did it correctly and the bug got introduced with the advent of routing in mkgmap, and send a message if they worked correctly. If not then we probably set this flag since the beginning (but until recently this was no problem). ------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 24.05.2010 18:01, Christian Gawron wrote:
Maybe it's this bit in the TDB-Header (HeaderBlock.java): os.write(1); // map is routable
At least it looks strange that this bit is set regardless of the --route option, and there are similar flags related to DEM info in this block as well ...
Best wishes Christian
You mean setting os.write(0); // map is nonroutable should fix it?? I'll give it a go and try it out. It's definitely better unsetting it than inserting an empty NOD table (which is however much much better than having an index point to it, and then the NOD table not found at all, and seriously affecting other maps).
Felix Hartmann schrieb:
On 23.05.2010 18:24, Felix Hartmann wrote:
There is a serious bug that breaks routable maps when --route is NOT given. This bug will in future break routing on most GPS devices and is already inflicting Mapsource 6.16.1 and Basecamp 3. This means that also if you compile maps that are not routable, you have to pass the --route parameter. Else the GPS / Mapsource looks into an empty NOD table and may crash. This will happen as soon as you mix routable maps with the non routable mkgmap created maps.
The problem is that Mapsource and the GPS search for 63440000.NOD data (63440000 as an example placeholder for the mapname). "Falagar", a developer at Garmin said to release a fix for this bug in Mapsource 6.16.2 however mentioned that this fix will not be carried on to GPS devices and will still mean a deterioration of overall routing.
I'm not sure what the exact problem for this is (I just tried even very old mkgmap versions like 858 and also there the problem arises) but currently this means that --route should be the compulsory for all map creation, also not routable ones. If you have old maps (eg transparent contourline maps) that are troublesome to rebuilt, then opening with gpsmapedit, saving as mp and recompiling passing --route parameter is enough to solve the problem.
I think that until the bug is found, mkgmap should adopt --route as standard, because it may happen that if users put an mkgmap created without --route onto their GPS besides other routable maps, these maps might impact autorouting for the other routable maps (except if "deactivated" on the GPS). Just as an update. I got the following answer from Falagar, concerning creating all maps with --route parameter:
/Naja, das ist halt nur ein Trick. Am besten waere es, die NOD-Flag zu entfernen, aber ich weiss nicht, ob ihr wisst, wo die ist. Ich weiss es leider auch nicht. Es koennte evtl. ein wenig langsamer sein, wenn MS & Geraet die Routinginformationen erst oeffnen muessen, bevor wir feststellen, dass da keine Info drin ist. Aber ich denke, das sollte erst einmal funktionieren. /
Translation. This is only a trick. Best would be to completly remove the NOD-Flag, but I don't know whether you know where it is. Actually, I don't know it either. Eventually it could be a little bit slower if Mapsource & GPS first has to open the routing information, until it notices that there is no info inside. But I think this would do if for a beginning.
So either someone finds the NOD flag (gmaptool also knows nothing about it, removing NOD data with gmaptool does not clear the NOD flag, ) and it will be deactivated when --route is not given, or we pass --route as mandatory, as we obviously miss something in the implementation. I will give some really old versions a go to see if they did it correctly and the bug got introduced with the advent of routing in mkgmap, and send a message if they worked correctly. If not then we probably set this flag since the beginning (but until recently this was no problem). ------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 24.05.2010 18:01, Christian Gawron wrote:
Maybe it's this bit in the TDB-Header (HeaderBlock.java): os.write(1); // map is routable
At least it looks strange that this bit is set regardless of the --route option, and there are similar flags related to DEM info in this block as well ...
Best wishes Christian
Just got to test it. Good try but ain't work. Still crashing Mapsource/Basecamp. Only solution I think is to make --route default and compulsory for the moment. Else people will create maps that havoc other maps without realising.
Felix Hartmann wrote:
Only solution I think is to make --route default and compulsory for the moment. Else people will create maps that havoc other maps without realising.
I strongly advice against this. The problem has been around a very long time and nobody noticed, so I don't think it is that critical. The workaround is simple: Do not use the latest version of MS/BC until the problem is fixed. On the other hand, routable maps seem to be much larger than non-routable maps. If you change the behaviour of mkgamp there you can break things by enlarging the maps so they do not fit into the memory they used previously. If the map is tailored to fit an 1GB SD card, it will no longer. There are older devices that have a limited amount of built-in memory and you might make maps unusable that now are fitting into the devices. In short: I think a compulsory change would break more than it helps right now. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Really-Serious-bug-when-not-using-route-tp50... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 25.05.2010 11:58, NopMap wrote:
Felix Hartmann wrote:
Only solution I think is to make --route default and compulsory for the moment. Else people will create maps that havoc other maps without realising.
I strongly advice against this. The problem has been around a very long time and nobody noticed, so I don't think it is that critical. The workaround is simple: Do not use the latest version of MS/BC until the problem is fixed.
On the other hand, routable maps seem to be much larger than non-routable maps. If you change the behaviour of mkgamp there you can break things by enlarging the maps so they do not fit into the memory they used previously. If the map is tailored to fit an 1GB SD card, it will no longer. There are older devices that have a limited amount of built-in memory and you might make maps unusable that now are fitting into the devices.
In short: I think a compulsory change would break more than it helps right now.
bye Nop
Routable maps are in no way bigger than non routable maps (if there is no routable information inside, of course if you use the same style that is routable and compile it without --route it gets smaller, if you remove all road_class and road_speed from style, there is virtually no size difference). Lazyness shouldn't break stuff. And continuing with this problem is no option, as the newest Oregon Firmware and all future Firmwares for other devices will crash too.
Felix Hartmann wrote:
Routable maps are in no way bigger than non routable maps (if there is no routable information inside, of course if you use the same style that is routable and compile it without --route it gets smaller, if you remove all road_class and road_speed from style, there is virtually no size difference).
This is not what I have observed. Using a style that does not have any route info, accidentially activating --route caused it to grow significantly. Maybe there is a different explanation, but until the reason is clear, I must assume that a compulsory --route would cause the same. Felix Hartmann wrote:
Lazyness shouldn't break stuff. And continuing with this problem is no option, as the newest Oregon Firmware and all future Firmwares for other devices will crash too.
So if you're bulding for an Oregon and if you use the latest updates, you need to specify --route. This is no reason to force the owners of all other devices to do this, too. Especially if you break the building of maps for older devices this way. A sensible solution would be to either fix the problem for good by removing those flags or introduce a new parameter/default behaviour that just creates an empty version of the required block with less side effects than a global --route. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Really-Serious-bug-when-not-using-route-tp50... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 25.05.2010 14:28, NopMap wrote:
Felix Hartmann wrote:
Routable maps are in no way bigger than non routable maps (if there is no routable information inside, of course if you use the same style that is routable and compile it without --route it gets smaller, if you remove all road_class and road_speed from style, there is virtually no size difference).
This is not what I have observed. Using a style that does not have any route info, accidentially activating --route caused it to grow significantly. Maybe there is a different explanation, but until the reason is clear, I must assume that a compulsory --route would cause the same.
Felix Hartmann wrote:
Lazyness shouldn't break stuff. And continuing with this problem is no option, as the newest Oregon Firmware and all future Firmwares for other devices will crash too.
So if you're bulding for an Oregon and if you use the latest updates, you need to specify --route.
This is no reason to force the owners of all other devices to do this, too. Especially if you break the building of maps for older devices this way.
A sensible solution would be to either fix the problem for good by removing those flags or introduce a new parameter/default behaviour that just creates an empty version of the required block with less side effects than a global --route.
bye Nop
I just rechecked your claims about --route increasing map size. I built austria from geofabrik using the default style but having deleted any occurence of road_class and road_speed once without --route and once with --route. --route made the each map exactly 2 bit bigger. So using --route and a non routable style, will exactly do what you ask for. So unless we find the real problem, a quick fix would be to have mkgmap just dropping road_class and road_speed when --route is not given, but otherwise behave exactly as if --route were given. If you really want to decrease map size, there are good methods, like reducing levels (e.g use only 23,21,19 and skip 24 alltogether as 23 is usually still much better than the quality of data inside osm), using --reduce-point-density=10 and --reduce-point-density-polygon=20 (patch exists), using --merge-lines (maybe called similary), and dropping lines/polygons with less than x points by resolution (patch exists). Oh, and best work on an overview map for low resolutions inside mapsource, on GPS there is the basemap anyhow for theese resolutions).
Only solution I think is to make --route default and compulsory for the moment. Else people will create maps that havoc other maps without realising.
I strongly advice against this. The problem has been around a very long time and nobody noticed, so I don't think it is that critical. The workaround is simple: Do not use the latest version of MS/BC until the problem is fixed.
On the other hand, routable maps seem to be much larger than non-routable maps. If you change the behaviour of mkgamp there you can break things by enlarging the maps so they do not fit into the memory they used previously. If the map is tailored to fit an 1GB SD card, it will no longer. There are older devices that have a limited amount of built-in memory and you might make maps unusable that now are fitting into the devices.
In short: I think a compulsory change would break more than it helps right now.
Felix, I appreciate your detailed work in investigate this bug, which will concern mkgamp in the future. But at the moment it is not known, where this NOD-Bit resides, so we can not do a clean solution. As you have shown with your detailed work, there is a simple workaround. If you want universal non-routable maps, then delete the routing specific entries from the style file and set the --route option. Therefore it *IS* an option, to be able for each user to fulfill their own needs. There is no need to make this mandatory. Ok, I admit it is a little confusing at the moment to need to set the --route option to generate a working nonroutable map for the future version of MS, but I think it is only a matter of time, until mkgmap handles the flag correctly. If in future the problem will become a bigger one, for sure someone wil look for a solution. At the moment there is simply no urgent need.
On 27.05.2010 13:00, Johann Gail wrote:
Only solution I think is to make --route default and compulsory for the moment. Else people will create maps that havoc other maps without realising.
I strongly advice against this. The problem has been around a very long time and nobody noticed, so I don't think it is that critical. The workaround is simple: Do not use the latest version of MS/BC until the problem is fixed.
On the other hand, routable maps seem to be much larger than non-routable maps. If you change the behaviour of mkgamp there you can break things by enlarging the maps so they do not fit into the memory they used previously. If the map is tailored to fit an 1GB SD card, it will no longer. There are older devices that have a limited amount of built-in memory and you might make maps unusable that now are fitting into the devices.
In short: I think a compulsory change would break more than it helps right now.
Felix, I appreciate your detailed work in investigate this bug, which will concern mkgamp in the future. But at the moment it is not known, where this NOD-Bit resides, so we can not do a clean solution.
As you have shown with your detailed work, there is a simple workaround. If you want universal non-routable maps, then delete the routing specific entries from the style file and set the --route option. Therefore it *IS* an option, to be able for each user to fulfill their own needs. There is no need to make this mandatory.
Ok, I admit it is a little confusing at the moment to need to set the --route option to generate a working nonroutable map for the future version of MS, but I think it is only a matter of time, until mkgmap handles the flag correctly. If in future the problem will become a bigger one, for sure someone wil look for a solution. At the moment there is simply no urgent need.
I wouldn't say it is not urgent. I got reports from Oregon 3.80 Firmware users, that they already have problems with autorouting if they have "nonroutable" mkgmap created maps on their GPS. The biggest problem is, people will think the routable map is at fault, while the nonroutable cause all the trouble. The least to do would be to change mkgmap behaviour to write an empty NOD index if --route is NOT given (so people don't have to fiddle with their styles). I had a testunit based on newer firmware and it wouldn't even start anymore until I removed the SD-Card after having calculated a route that caused the GPS to crash. And 6.16.1 is not a future version of Mapsource, but since 3 weeks the current stable version. Basecamp is affected since 3.0.2 (~5 weeks old) already. And we can't expect people to have a parallel installation of older Mapsource/Basecamp (while in practice without this bug, 6.16 and Basecamp 3 feature autorouting that works at least twice better in comparison with older versions).
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
already inflicting Mapsource 6.16.1 and Basecamp 3.
OK so I upgraded to 6.16.1, had to upgrade twice to get there.
This means that also if you compile maps that are not routable, you have to pass the --route parameter. Else the GPS / Mapsource looks into an empty NOD table and may crash. This will happen as soon as you mix routable maps with the non routable mkgmap created maps.
Now how exactly do I reproduce the problem? I've not been able to. If the flag is in TRE, then my first guess would be within the 3 bytes from 0x43. We don't know exactly what they are for, but some of the bits at least affect routing (see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/001473.html) Please try the attached patch. ..Steve
On 26.05.2010 23:40, Steve Ratcliffe wrote:
already inflicting Mapsource 6.16.1 and Basecamp 3.
OK so I upgraded to 6.16.1, had to upgrade twice to get there.
This means that also if you compile maps that are not routable, you have to pass the --route parameter. Else the GPS / Mapsource looks into an empty NOD table and may crash. This will happen as soon as you mix routable maps with the non routable mkgmap created maps.
Now how exactly do I reproduce the problem? I've not been able to.
You need to combine two different maps of the same area (so most often one being contourlines) into the same mapset (meaning same tdb/overview image/mdr/....). Then whenever you route to an object that is inside the nonroutable map (i.e. the contourlines), Mapsource will not calculate the route but stop with: -- Basecamp 3 will even outright get into a loop you can only escape by closing it via task-manager (don't ask me what happens if you use it via WINE) If you want, here is a beta map that you could install that shows the behaviour (install from d:/garmin/0mtb/mtbaustria1/ as the location is hardcoded inside the bat and the path is set for x64 windows, or exchange it with texteditor to your liking, or simply register the maps with Mapsettoolkit or by hand): run both install* .bat files, one will install without contourlines (correct routing), and one with broken routen (*srtm*). http://openmtbmap.x-nation.de/maps/beta/mtbaustria.7z.zip and here a route that will show the error: http://openmtbmap.x-nation.de/maps/beta/Broken_route.zip Sometimes it does not happen, but usually it does, it seems to depend how much other information that is routable is nearby. As to what I am told by Garmin, all future Firmwares will show the same behaviour, even worse, just having an activated mkgmap created map created without --route is then may be enough to crash the GPS. If you rebuild the 7*.img files (the contourlines) with --route, than the problem is worked around. (to rebuilt just open the *.img with gpsmapedit, save as MP, and recompile with mkgmap).
If the flag is in TRE, then my first guess would be within the 3 bytes from 0x43. We don't know exactly what they are for, but some of the bits at least affect routing (see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/001473.html)
Please try the attached patch.
..Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
You need to combine two different maps of the same area (so most often one being contourlines) into the same mapset (meaning same tdb/overview image/mdr/....).
OK I have finally reproduced it with your map. It seems that in fact you have two different map sets with different family/tdb/etc. When I switch to the non-routable one and attempt to draw a route it tries to calculate a route and usually fails. I'll try to create a smaller example so I can investigate. ..Steve
On 28.05.2010 00:21, Steve Ratcliffe wrote:
You need to combine two different maps of the same area (so most often one being contourlines) into the same mapset (meaning same tdb/overview image/mdr/....).
OK I have finally reproduced it with your map.
It seems that in fact you have two different map sets with different family/tdb/etc.
No it's originally two different maps, but they are joined into the same mapset so they become one map. So if joined, they have the same family/tdb/etc. (on the GPS the error occurs also if they are really two different maps, the chance that the error occurs is less likely, as it can only happen on tile boundaries I think, but there it does happen and it does crash the GPS (in worst case if maps installed to internal memory and you can't power on the GPS anymore this means sending the GPS by post to Garmin to delete the offending map)
When I switch to the non-routable one and attempt to draw a route it tries to calculate a route and usually fails.
I'll try to create a smaller example so I can investigate.
Go for it, but I don't think it'll be easy to solve.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 27/05/2010 23:43, Steve Ratcliffe wrote:
No it's originally two different maps, but they are joined into the same mapset so they become one map. So if joined, they have the same
How are they joined?
OK never mind I see how. The srtm set includes the other one and is not separate.
On 28.05.2010 00:43, Steve Ratcliffe wrote:
No it's originally two different maps, but they are joined into the same mapset so they become one map. So if joined, they have the same
How are they joined?
using mkgmap parsing all img files to create new tdb/overview map, etc..., gmt.exe to adapt FID/PID in typfile. Same happens when joining with gmt/cgpsmapper however.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
If the flag is in TRE, then my first guess would be within
the 3 bytes from 0x43. We don't know exactly what they are for, but some of the bits at least affect routing (see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/001473.html)
Please try the attached patch.
The first 3 TRE values have nothing to do with it (maybe the fourth, but I still have not understood where it is set). If you have: writer.putInt(0x130201); then 17 is setting the autorouting priority. 02 sets the draw priority (overrules DP if set inside tdb), and 01 is unkown to me but does not affect routing. Setting the fourth via gmaptool breaks the routing for routable maps, but Mapsource/GPS still search for the NOD flag. In my opinion the NOD flag is not configured at all inside mkgmap, else the Garmin dev wouldn't tell that we might not no about it's existence at all.
On 27.05.2010 00:28, Felix Hartmann wrote:
If the flag is in TRE, then my first guess would be within
the 3 bytes from 0x43. We don't know exactly what they are for, but some of the bits at least affect routing (see: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/001473.html)
Please try the attached patch.
The first 3 TRE values have nothing to do with it (maybe the fourth, but I still have not understood where it is set).
If you have: writer.putInt(0x130201); then 17 is setting the autorouting priority. Ups, sorry, just wrote it wrongly. 13 (what I ment with 17), is setting the distance for recalculation when off road. The lower the earlier the GPS will recalculate. It is useful for cycling/hiking as recalculation is happening later the slower you go (maybe because this is interpreted as bad gps reception??).
02 sets the draw priority (overrules DP if set inside tdb), and 01 is unkown to me but does not affect routing. Setting the fourth via gmaptool breaks the routing for routable maps even though it should be there for setting maps tranparent/opaque is some obscure way different from the general transparent/opaque flag , but Mapsource/GPS still search for the NOD flag. In my opinion the NOD flag is not configured at all inside mkgmap, else the Garmin dev wouldn't tell that we might not no about it's existence at all.
I am more or less certain that the TRE values have nothing to do with it. There must be another value where the NOD flag is stored.
Setting the fourth via gmaptool breaks the routing for routable maps even though it should be there for setting maps tranparent/opaque is some obscure way different from the general transparent/opaque flag
Could this be the exactly the NOD flag? If modifying this flag breaks routing then this IS a strong hint for influencing routing. Could it be that in this byte one bit is the flag for the presence (or absence) of the NOD table? If this bit is set/cleared then it tells the device that there is no NOD table and therefore no routing is possible.
On 27.05.2010 13:12, Johann Gail wrote:
Setting the fourth via gmaptool breaks the routing for routable maps even though it should be there for setting maps tranparent/opaque is some obscure way different from the general transparent/opaque flag
Could this be the exactly the NOD flag? If modifying this flag breaks routing then this IS a strong hint for influencing routing. Could it be that in this byte one bit is the flag for the presence (or absence) of the NOD table? If this bit is set/cleared then it tells the device that there is no NOD table and therefore no routing is possible.
Well I don't know how to clear it. Setting it to 0 doesn't help. It seems to only matter whether it is even or uneven. Setting it even breaks routing, while all uneven values work. Therefore I'm more or less sure, this is not the NOD flag. Also this byte is set for non routable garmin maps to even and uneven values, so no, I don't think this has anything to do with it.
Felix Hartmann schrieb:
On 27.05.2010 13:12, Johann Gail wrote:
Setting the fourth via gmaptool breaks the routing for routable maps even though it should be there for setting maps tranparent/opaque is some obscure way different from the general transparent/opaque flag
Could this be the exactly the NOD flag? If modifying this flag breaks routing then this IS a strong hint for influencing routing. Could it be that in this byte one bit is the flag for the presence (or absence) of the NOD table? If this bit is set/cleared then it tells the device that there is no NOD table and therefore no routing is possible.
Well I don't know how to clear it. Setting it to 0 doesn't help. It seems to only matter whether it is even or uneven. This is exactly what I meant by clearing the bit. With uneven values it is not set, i.e. cleared. Setting it even breaks routing, while all uneven values work. Therefore I'm more or less sure, this is not the NOD flag.
Could you tell please, what happens with broken routing? Does it mean, there is no routing at all, or happens wrong routing?
Also this byte is set for non routable garmin maps to even and uneven values, so no, I don't think this has anything to do with it.
This is the point which confuses me at the moment. This bit does influence routing in some way. But you say that there are nonroutable maps with this bit set/unset. So what could the meaning of this bit be?
On 27.05.2010 13:34, Johann Gail wrote:
Felix Hartmann schrieb:
On 27.05.2010 13:12, Johann Gail wrote:
Setting the fourth via gmaptool breaks the routing for routable maps even though it should be there for setting maps tranparent/opaque is some obscure way different from the general transparent/opaque flag
Could this be the exactly the NOD flag? If modifying this flag breaks routing then this IS a strong hint for influencing routing. Could it be that in this byte one bit is the flag for the presence (or absence) of the NOD table? If this bit is set/cleared then it tells the device that there is no NOD table and therefore no routing is possible.
Well I don't know how to clear it. Setting it to 0 doesn't help. It seems to only matter whether it is even or uneven. This is exactly what I meant by clearing the bit. With uneven values it is not set, i.e. cleared. Setting it even breaks routing, while all uneven values work. Therefore I'm more or less sure, this is not the NOD flag. Could you tell please, what happens with broken routing? Does it mean, there is no routing at all, or happens wrong routing?
Well you can click around in the map with the route tool, and it just draws straight lines. The problem arises if there is a routable and a nonroutable map inside the same mapset in mapsource or same gmapsupp.img on GPS. Then it all goes wrong and crashes GPS, or causes MPL error on Mapsource.
Also this byte is set for non routable garmin maps to even and uneven values, so no, I don't think this has anything to do with it.
This is the point which confuses me at the moment. This bit does influence routing in some way. But you say that there are nonroutable maps with this bit set/unset. So what could the meaning of this bit be?
Noone really knows. Mkgmap sets it even. Garmin maps are actually allways uneven. I speculated that the 0 (unset) here breaks intertile routing, but I have no clue what mkgmap is doing here and where to set it. Here are all values that I know (I don't have all these maps, but often only a few demo tiles that were downloadable form Garmin servers). mkgmap default: -1 - 3 - 17 - 0 ----- MPC created ---- Topo Austria v1 - nonroutable - 1 - 4 - 23 - 3 Topo Austria v2 - routable; - 1 - 4 - 23 - 1 Topo Transalpin - routable; - 1 - 4 - 23 - 1 Topo Germany v2 non routable, - 1 - 4 - 23 - 13 Topo Germany 2010 routable, 1 - 4 - 10 - 13 Topo Swiss v2 routable, 1 - 4 - 23 - 9 ----- ??? created ---- City Navigator 2009 classic routable, 1- 3 - 17 - 9 City Navigator 2010.20 NT, routable (from Nuvi), 1 - 3 - 17 - 13 (this seems to be the standard for all Garmin NT maps). ----- cgpsmapper created ---- Onroute Fietskaart routable, 1 - 3 - 17 - 5 Topo Adria 2.20, 1 - 4 - 23 - 5 I think cgpsmapper defaults to -5, and sets - 3 - 17 for maps with autorouting primed at cyclist/motorists, and - 3 -17 for pedestrian topos. Note, I wrote in another thread that I don't like mkgmap setting it to 0, but setting it uneven makes routing to direct line routing (so breaks routing). And I could'nt understand the explanations on howto change it from 0 to something else. If I change mkgmap created maps to eg -1 -3 -17 -1 (or any other uneven fourth TRE value, than it means direct line routing only).
This is the point which confuses me at the moment. This bit does influence routing in some way. But you say that there are nonroutable maps with this bit set/unset. So what could the meaning of this bit be?
Noone really knows. Mkgmap sets it even. Garmin maps are actually allways uneven. I speculated that the 0 (unset) here breaks intertile routing, but I have no clue what mkgmap is doing here and where to set it.
In the TREHeader.java (like in the patch from steve) add a one more byte in first position. If I understand it correctly, this will set the ominous fourth byte to 01. (Not tested). - writer.putInt(0x110301); + writer.putInt(0x01110301);
[...] mkgmap default: -1 - 3 - 17 - 0
This are exactly the values from the line above, in decimal coding. (The values in mkgmap are in hexadecimal coding.)
In the TREHeader.java (like in the patch from steve) add a one more byte in first position. If I understand it correctly, this will set the ominous fourth byte to 01. (Not tested).
In fact the 4th byte that appears in the gmaptool dialog is actually what mkgmap calls poiDisplayFlags and occurs earlier in the .img file. ..Steve
Hi, On Thu, May 27, 2010 at 11:44 PM, Steve Ratcliffe <steve@parabola.me.uk> wrote:
In the TREHeader.java (like in the patch from steve) add a one more byte in first position. If I understand it correctly, this will set the ominous fourth byte to 01. (Not tested).
In fact the 4th byte that appears in the gmaptool dialog is actually what mkgmap calls poiDisplayFlags and occurs earlier in the .img file.
The first bit in poiDisplayFlags have to do something with the basemaps. In all detailed maps it's set. The maps i found that it's not set are worldwide base maps - gmapbmap.img(s) For the route recalculation, it's not clear which of the two bites changed the recalculation - first rule of re -> always change only one thing . -- have fun, alex
On 28.05.2010 12:18, Alexander Atanasov wrote:
Hi,
On Thu, May 27, 2010 at 11:44 PM, Steve Ratcliffe<steve@parabola.me.uk> wrote:
In the TREHeader.java (like in the patch from steve) add a one more byte in first position. If I understand it correctly, this will set the ominous fourth byte to 01. (Not tested).
In fact the 4th byte that appears in the gmaptool dialog is actually what mkgmap calls poiDisplayFlags and occurs earlier in the .img file.
The first bit in poiDisplayFlags have to do something with the basemaps. In all detailed maps it's set. The maps i found that it's not set are worldwide base maps - gmapbmap.img(s)
For the route recalculation, it's not clear which of the two bites changed the recalculation - first rule of re -> always change only one thing .
Can someone write a patch to allow setting the poiDisplayFlag? Cause mkgmap maps are usually no basemaps....
The first bit in poiDisplayFlags have to do something with the basemaps. In all detailed maps it's set. The maps i found that it's not set are worldwide base maps - gmapbmap.img(s)
For the route recalculation, it's not clear which of the two bites changed the recalculation - first rule of re -> always change only one thing .
Can someone write a patch to allow setting the poiDisplayFlag? Cause mkgmap maps are usually no basemaps....
Ok, the following patch intruduces a new option "--detailed-map" which sets this flag. Patch compiles, but is otherwise completely untested. I don't expect it to help much, but feel free to try out.
On 31.05.2010 16:08, Johann Gail wrote:
The first bit in poiDisplayFlags have to do something with the basemaps. In all detailed maps it's set. The maps i found that it's not set are worldwide base maps - gmapbmap.img(s)
For the route recalculation, it's not clear which of the two bites changed the recalculation - first rule of re -> always change only one thing .
Can someone write a patch to allow setting the poiDisplayFlag? Cause mkgmap maps are usually no basemaps....
Ok, the following patch intruduces a new option "--detailed-map" which sets this flag. Patch compiles, but is otherwise completely untested. I don't expect it to help much, but feel free to try out.
Well I can't see what it does with gmaptool. Maps are still 1 3 17 12 according to gmaptool and setting 1 3 17 13 breaks autorouting. I am pretty sure that if the requisites don't break autorouting when 1 3 17 13 is set, that then the 3 tile problem would be solved too. For Garmin maps, setting 1 3 17 12 like mkgmap does changes nothing, routing still works as expected. So if on Garmin maps one can change it to any value, it should not break when doing the same thing on mkgmap created maps.
I've now got a small example that shows the problem. No luck so far in finding the flag, if indeed it is just a flag. ..Steve
I've now got a small example that shows the problem.
No luck so far in finding the flag, if indeed it is just a flag.
A possible way to find the flag: With MapSource (at least with 6.13) it is possible to include or exclude the routing data when transferring to the device. If you transfer the same data twice, one time with, the ther time without the routing data, then it contains the routing section or not. If there IS a flag concerning this, then it should differ between these two images. Regards, Johann
Hi
A possible way to find the flag: With MapSource (at least with 6.13) it is possible to include or exclude the routing data when transferring to the device. If you transfer the same data twice, one time with, the ther time without the routing data,
A great idea! Unfortunately my results are that all the sub-files are unaltered and bit for bit identical in the two cases. All the changes in the header appear to be consistent with the changes required for the fact that the files are different sizes and one does not contain NOD. I've had no luck with finding anything. I've tried unsetting all the flags that we don't know the meaning of, so it seems that it might not be a simple flag that we always set but shouldn't. Perhaps mixing routable and non-routeable maps with the same family id just doesn't work? Has anyone seen a working example? ..Steve
On 31.05.2010 15:05, Steve Ratcliffe wrote:
Hi
A possible way to find the flag: With MapSource (at least with 6.13) it is possible to include or exclude the routing data when transferring to the device. If you transfer the same data twice, one time with, the ther time without the routing data,
A great idea!
Unfortunately my results are that all the sub-files are unaltered and bit for bit identical in the two cases.
All the changes in the header appear to be consistent with the changes required for the fact that the files are different sizes and one does not contain NOD.
I've had no luck with finding anything. I've tried unsetting all the flags that we don't know the meaning of, so it seems that it might not be a simple flag that we always set but shouldn't.
Perhaps mixing routable and non-routeable maps with the same family id just doesn't work? Has anyone seen a working example?
Yes I mixed the Garmin Topo Austria v1 (non routable) with mkgmap routable maps, and the errors did not occur. The flag is properly really well hidden. I think mkgmap should simply default to always write the NOD index file, also if --route is not given. That's not the best solution, but better than breaking down new GPS (and all Oregon/Dakota/Colorado have now beta Firmware that is probably prone to crash with non routable mkgmap created maps).
..Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
A possible way to find the flag: With MapSource (at least with 6.13) it is possible to include or exclude the routing data when transferring to the device. If you transfer the same data twice, one time with, the ther time without the routing data,
A great idea!
Unfortunately my results are that all the sub-files are unaltered and bit for bit identical in the two cases.
All the changes in the header appear to be consistent with the changes required for the fact that the files are different sizes and one does not contain NOD.
Ok, so there IS NO NOD flag. I really haven't expected this result, but seems the case here.
I've had no luck with finding anything. I've tried unsetting all the flags that we don't know the meaning of, so it seems that it might not be a simple flag that we always set but shouldn't.
Two things come to my mind. 1. Could it be a matter of draw priority? Maybe the routable map needs a higher drawing priority to be in front? In the other case routing will be tried on the non-routable map and fail. 2. Could it have to do something with the detailed map/basemap flag? To write a patch for this bit should not be that complicated, but iirc setting this bit breaks routing. Regards, Johann
On 31.05.2010 15:56, Johann Gail wrote:
A possible way to find the flag: With MapSource (at least with 6.13) it is possible to include or exclude the routing data when transferring to the device. If you transfer the same data twice, one time with, the ther time without the routing data,
A great idea!
Unfortunately my results are that all the sub-files are unaltered and bit for bit identical in the two cases.
All the changes in the header appear to be consistent with the changes required for the fact that the files are different sizes and one does not contain NOD.
Ok, so there IS NO NOD flag. I really haven't expected this result, but seems the case here.
I've had no luck with finding anything. I've tried unsetting all the flags that we don't know the meaning of, so it seems that it might not be a simple flag that we always set but shouldn't.
Two things come to my mind. 1. Could it be a matter of draw priority? Maybe the routable map needs a higher drawing priority to be in front? In the other case routing will be tried on the non-routable map and fail.
No I played around with that already. Has no influence.
2. Could it have to do something with the detailed map/basemap flag? To write a patch for this bit should not be that complicated, but iirc setting this bit breaks routing.
Well you're provided patch did not break routing for me. I will try out later if it solves the problem when --route is not given, though not having noticed any differences when using the patch for normal autoroutable maps, I doubt it solves the problem.
Regards, Johann
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (7)
-
Alexander Atanasov -
Christian Gawron -
Felix Hartmann -
Johann Gail -
Nakor -
NopMap -
Steve Ratcliffe