[mkgmap-dev] MDR success and a couple of questions

Tue Oct 6 17:43:51 BST 2009


Alexander Atanasov wrote:
> On Sun, Oct 4, 2009 at 1:58 PM, Steve Ratcliffe <steve at parabola.me.uk> wrote:
>   
>> Hi
>>
>>     
>>> MDR7 - Roads
>>> 1/2 bytes IMG id from MDR1
>>> 3 bytes - unknown, may be a pointer in NOD, it's not a label or NET offset
>>>       
>> This definitely is or can be a pointer to LBL as I have now got working
>> street search based on it being a pointer into LBL.
>>     
>
> I was wrong it is a LBL.  i've got this from 3 different maps and it's
> all labels in LBL.
> Only the first is interesting, others are all 0x800000 flagged:
> garmin_mdr.c:1262:1|mdr7: 376772 391769 7 3
> garmin_mdr.c:337:1|1[0000] IMG:[03D0900D] roadptr: 803BBC
> lbl[28BE]:[^D1] left=0 :02 BC 3B 80 BE 28 00
> garmin_mdr.c:337:1|2[0007] IMG:[03D0900E] roadptr: 6EFE
> lbl[28BE]:[^D1] left=0 :03 FE 6E 00 BE 28 00
> garmin_mdr.c:337:1|3[000E] IMG:[03D0900F] roadptr: 73B4
> lbl[28BE]:[^D1] left=0 :04 B4 73 00 BE 28 00
> garmin_mdr.c:337:1|4[0015] IMG:[03D09010] roadptr: BDE6
> lbl[28BE]:[^D1] left=0 :05 E6 BD 00 BE 28 00
> garmin_mdr.c:337:1|5[001C] IMG:[03D09011] roadptr: 11DB3
> lbl[28BE]:[^D1] left=0 :06 B3 1D 01 BE 28 00
> garmin_mdr.c:337:1|6[0023] IMG:[03D09012] roadptr: 7159
> lbl[28BE]:[^D1] left=0 :07 59 71 00 BE 28 00
> garmin_mdr.c:337:1|7[002A] IMG:[03D09013] roadptr: 8C15
> lbl[28BE]:[^D1] left=0 :08 15 8C 00 BE 28 00
> garmin_mdr.c:337:1|8[0031] IMG:[03D09014] roadptr: 7626
> lbl[28BE]:[^D1] left=0 :09 26 76 00 BE 28 00
>
> Note that 0x800000, looks like a new label flag, not repeated. (^D is
> from the special road codes).
>
> This is from another map.
> garmin_mdr.c:1262:1|mdr7: 536473 52440 8 67
> And yet another, which is very small.
> garmin_mdr.c:1262:1|mdr7: 3267 896 8 67
>
> for the last two there is one more byte at the end which is 01.
> I think this hides in the mdr header, not the section flags, most of
> the flags looks like
> an alignment.(arm cpus?)
> 1.garmin_mdr.c:1233:1|hdr: codepage: 1252 00000001 000E0001
>  this doesn't have extra byte at the end. (new zeland map)
> 2.garmin_mdr.c:1233:1|hdr: codepage: 1252 00000007 00170002
> 3.garmin_mdr.c:1233:1|hdr: codepage: 1251 00000008 00170001
> this two have one or two bytes at the end of records, not only in mdr7.
>
> This one is from a map with mdr17, no mdr15.
> garmin_mdr.c:1233:1|hdr: codepage: 1252 00000007 00170002
> MDR17 is read so so and it contains 7 bit ascii.
>
> The code page i clear, next is 1,7,8 - labels coding?
> 1 and 7 are 7bit ascii
> 8 is 8bits  based on cp1251(cyrillic) is read okay.
>
> 0x0E and 0x17 i think this are like the poi properties in the lbl file,
> and specifiy what's in the records and/or what sections are in the mdr.
> the last 1,2 may be too.
>
> One more thing in the mg v9 map:
> garmin_mdr.c:1248:1|mdr4: 116876308 228 3 0
> garmin_mdr.c:1251:1|max_possible_type=4c(76)
> garmin_mdr.c:1084:1|POI Type
> garmin_mdr.c:337:1|1(0)[0000] type=0x0100 x=2(2) :01 02 00
> [cut]
> garmin_mdr.c:337:1|12(b)[0021] type=0x0D00 x=2(2) :0D 02 00
> garmin_mdr.c:337:1|13(c)[0024] type=0x2800 x=2(2) :28 02 00
> garmin_mdr.c:337:1|14(d)[0027] type=0x2A00 x=0(0) :2A 00 00
> garmin_mdr.c:337:1|15(e)[002A] type=0x2A01 x=0(0) :2A 00 01
> garmin_mdr.c:337:1|16(f)[002D] type=0x2A02 x=0(0) :2A 00 02
> garmin_mdr.c:337:1|17(10)[0030] type=0x2A03 x=0(0) :2A 00 03
>
> 0x2800 is in the MDR4 and looks like correctly sorted.
>
>   
>> But perhaps it can be different things, I previously had it down
>> as a pointer into NET.  This would make sense as net contains the
>> locations of the road.  With a pointer to LBL the software has to
>> perform several lookups to locate the road and its city, region etc.
>>     
>
> I belive than the longer records found in some mdrs, even go further,
> to the point of where to route to. Like
> poi = image, pnt:sdiv, lbl, region, road, node, ...
>   
This is possible, Nuvis can search for POI near to a calculated route. 
Outdoor units like 60CSx or Vista/Legend can't. I'm unsure about 
Oregon/Dakota
maybe this is related.
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20091006/fffcc6f0/attachment.html