[mkgmap-dev] Really Serious bug when not using --route

Sun May 23 19:54:31 BST 2010


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20100523/aee97a1d/attachment.html