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

Thu May 27 13:04:17 BST 2010


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).