MDR success and a couple of questions
Hi I've managed to construct a working MDR file with all of 2 POIs in it. This is with sections 1 (with empty subsections), 4, 9, 10, 11, 15. That appears to be the minimum number of sections to get anything to work. Interestingly, MDR 15 doesn't appear to be used much. It supplies auto-completion results when typing in the search boxes, but the actual search results show the actual labels of the points. So 4 and 9 are required but I don't completely understand them, so does anyone know or speculate what the second byte in MDR 4 is? The wiki says 'kind of index', suggesting that it tells you which sections use that POI type. If that is what is meant then what is the mapping? Secondly any ideas on MDR 9? The first record always appears to be 01 01 00 00, and that is enough to make searching work in my simple example, but beyond that I have no idea. ..Steve
Steve Ratcliffe wrote:
Hi
I've managed to construct a working MDR file with all of 2 POIs in it.
Congratulations! Nice work.
Secondly any ideas on MDR 9? The first record always appears to be 01 01 00 00, and that is enough to make searching work in my simple example, but beyond that I have no idea.
On my NT map, MDR9 only contains a single 4-byte element, containing just 01 01 00 00 just as you describe. So evidently that's an accepted Garmin way of rendering a minimum MDR9. The wiki claims (in a recent edit) that the number of elements in MDR9 is the same as the number in MDR10 but that's clearly not the case here. In breaking news(!) I find that MDR10 (in an NT map) can be a list of cities (settlements actually) rather than a list of POIs in the general sense of the word. Steve.
On 22/09/09 16:31, Steve Hosgood wrote:
On my NT map, MDR9 only contains a single 4-byte element, containing just 01 01 00 00 just as you describe. So evidently that's an accepted
OK Thanks, that is encouraging. I shall just plough on, hoping that is all we need in 9 for now. Cheers, ..Steve
Steve Ratcliffe wrote:
On 22/09/09 16:31, Steve Hosgood wrote:
On my NT map, MDR9 only contains a single 4-byte element, containing just 01 01 00 00 just as you describe. So evidently that's an accepted
OK Thanks, that is encouraging. I shall just plough on, hoping that is all we need in 9 for now.
This would seem to agree with the current comments on the wiki about MDR9 - that the contents (in this case) would be a set of records in the form <single byte integer><three byte integer>, and in this case both of the integers are '1'. This would agree with evidence elsewhere that seems to show Garmin's indexing usually starts from one. I'll issue a wild guess here that MDR9 is a sort-of "chapter list" for MDR10/11, splitting the POI list into a number of categories. Steve - next time you're playing in this area, could you try putting in about 10 POIs into MDR10/11 and adding a second record to MDR9 with the value 0x02, 0x04, 0x00, 0x00 please? Then look to see if the POI search facility has somehow split into two sections. I'd expect 3 items in one section and 7 in the other if there were 10 items total. It could be that the <three byte integer> is an absolute byte offset, not an index into the POI list, but I consider this rather unlikely. Steve
I'll issue a wild guess here that MDR9 is a sort-of "chapter list" for MDR10/11, splitting the POI list into a number of categories.
You may care to glance at the mkgmap POI index code, it could possibly provide some help. We have been able to generate the POI index for some time but it hasn't proven to be useful - i'm hoping that with the MDR in place, the POI index will become relevant. Cheers, Mark
On Wed, Sep 23, 2009 at 10:19:19AM +0100, Mark Burton wrote:
I'll issue a wild guess here that MDR9 is a sort-of "chapter list" for MDR10/11, splitting the POI list into a number of categories.
You may care to glance at the mkgmap POI index code, it could possibly provide some help. We have been able to generate the POI index for some time but it hasn't proven to be useful - i'm hoping that with the MDR in place, the POI index will become relevant.
Excuse me, what is this POI index used for? I guess that it must be something else than the submenus of Where To?/Find Places, because that has worked on my Edge 705 as long as I remember. Do some units implement POI and address search differently? Even street name search works on my Edge 705 with pretty much default mkgmap options (--gmapsupp --route). Marko
Hi Marko,
Excuse me, what is this POI index used for? I guess that it must be something else than the submenus of Where To?/Find Places, because that has worked on my Edge 705 as long as I remember. Do some units implement POI and address search differently? Even street name search works on my Edge 705 with pretty much default mkgmap options (--gmapsupp --route).
Perhaps it's related to POI finding in mapsource which doesn't work at this time? Mark
Hi Mark, On Wed, Sep 23, 2009 at 10:37:10AM +0100, Mark Burton wrote:
Hi Marko,
Excuse me, what is this POI index used for? I guess that it must be something else than the submenus of Where To?/Find Places, because that has worked on my Edge 705 as long as I remember. Do some units implement POI and address search differently? Even street name search works on my Edge 705 with pretty much default mkgmap options (--gmapsupp --route).
Perhaps it's related to POI finding in mapsource which doesn't work at this time?
Sorry, I will go back to my cave, which hasn't seen the light of Windows. :-) Marko
Hi Marko,
Sorry, I will go back to my cave, which hasn't seen the light of Windows. :-)
No need to be sorry. I only use mapsource as part of my mkgmap development (XP on VMWare on Linux, of course). Personally, I don't care much if the mapsource find stuff doesn't work but having implemented the POI index months ago, it would be nice if it was actually useful for something! Cheers, Mark
Hi, On Tue, Sep 22, 2009 at 6:31 PM, Steve Hosgood <steve@tallyho.bc.nu> wrote:
Steve Ratcliffe wrote:
Hi
I've managed to construct a working MDR file with all of 2 POIs in it.
Congratulations! Nice work.
Secondly any ideas on MDR 9? The first record always appears to be 01 01 00 00, and that is enough to make searching work in my simple example, but beyond that I have no idea.
On my NT map, MDR9 only contains a single 4-byte element, containing just 01 01 00 00 just as you describe. So evidently that's an accepted Garmin way of rendering a minimum MDR9. The wiki claims (in a recent edit) that the number of elements in MDR9 is the same as the number in MDR10 but that's clearly not the case here.
In breaking news(!) I find that MDR10 (in an NT map) can be a list of cities (settlements actually) rather than a list of POIs in the general sense of the word.
Yes, if there is no MDR4, MDR9 contains just one record and MDR10 contains only cities but no POIs. MDR10 and MDR11 counts are equal, not MDR9 and MDR10. Also if there is MDR4 city types are repeated as subtype in MDR9. -- have fun, alex
Hi Steve, thats really good news ! I tried to embed your dummy mdr file into my map unfortunately my Nuvi was not impressed. It is still asking for a state but at least it didn't crash. In one of your posts you mentioned that the "find" button gets enabled. Did you test it with MS or on your garmin device ? Did you just used the img with the dummy mdr file ? Unfortunately I was not able to spend much time looking into MDR during the last months. So I have to dig into this again. According to my documents the nuvi at least requires the following MDR Records: 1, 5, 11, 24 (country List ?), 25 (City Ref List), 29 (Country List ?) I found this out by removing section by section from the mdr header of a working file. I forgot if this file was MS generated or by cGPSmapper. Then I tried to put this records in one of my files but Nuvi didn't liked it much. Berni.
I've managed to construct a working MDR file with all of 2 POIs in it.
This is with sections 1 (with empty subsections), 4, 9, 10, 11, 15. That appears to be the minimum number of sections to get anything to work.
Interestingly, MDR 15 doesn't appear to be used much. It supplies auto-completion results when typing in the search boxes, but the actual search results show the actual labels of the points.
So 4 and 9 are required but I don't completely understand them, so does anyone know or speculate what the second byte in MDR 4 is? The wiki says 'kind of index', suggesting that it tells you which sections use that POI type. If that is what is meant then what is the mapping?
Secondly any ideas on MDR 9? The first record always appears to be 01 01 00 00, and that is enough to make searching work in my simple example, but beyond that I have no idea.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 22/09/09 21:35, Bernhard Heibler wrote:
thats really good news ! I tried to embed your dummy mdr file into my map unfortunately my Nuvi was not impressed. It is still asking for a state but at least it didn't crash.
Ah yes, I should have been clear, it will only work in mapsource as far as I know. Also I expect that the section 1 subsection data is used by ms to create the on-device version, so I doubt that will work either (though I've not tried, so feel free to check).
Unfortunately I was not able to spend much time looking into MDR during the last months. So I have to dig into this again. According to my documents the nuvi at least requires the following MDR Records:
1, 5, 11, 24 (country List ?), 25 (City Ref List), 29 (Country List ?)
Did you also reduce the header length? The sections 24,25 and 29 may only be required in files with the larger header. ..Steve
Hi! This is going to be a long post. MDR1 - Images List. 4 bytes image id, 4 bytes detailed map id, like in the tdb MDR4 1 byte type, 1 byte unknown, 1 byte subtype garmin_mdr.c:1020:1|POI Type garmin_mdr.c:337:1|1(0)[0000] type=0x0300 x=4(4) :03 04 00 garmin_mdr.c:337:1|2(1)[0003] type=0x0400 x=4(4) :04 04 00 garmin_mdr.c:337:1|3(2)[0006] type=0x0700 x=3(3) :07 03 00 garmin_mdr.c:337:1|4(3)[0009] type=0x0800 x=3(3) :08 03 00 garmin_mdr.c:337:1|5(4)[000C] type=0x0A00 x=2(2) :0A 02 00 garmin_mdr.c:337:1|6(5)[000F] type=0x0B00 x=2(2) :0B 02 00 ------------------------------------------------------------------------------ garmin_mdr.c:337:1|7(6)[0012] type=0x2A00 x=1(1) :2A 01 00 garmin_mdr.c:337:1|8(7)[0015] type=0x2A03 x=1(1) :2A 01 03 garmin_mdr.c:337:1|9(8)[0018] type=0x2A04 x=1(1) :2A 01 04 garmin_mdr.c:337:1|10(9)[001B] type=0x2A05 x=1(1) :2A 01 05 garmin_mdr.c:337:1|11(a)[001E] type=0x2A07 x=1(1) :2A 01 07 garmin_mdr.c:337:1|12(b)[0021] type=0x2A09 x=1(1) :2A 01 09 garmin_mdr.c:337:1|13(c)[0024] type=0x2A0A x=1(1) :2A 01 0A garmin_mdr.c:337:1|14(d)[0027] type=0x2A0B x=1(1) :2A 01 0B garmin_mdr.c:337:1|15(e)[002A] type=0x2A0C x=1(1) :2A 01 0C garmin_mdr.c:337:1|16(f)[002D] type=0x2A0D x=0(0) :2A 00 0D garmin_mdr.c:337:1|17(10)[0030] type=0x2A0E x=0(0) :2A 00 0E garmin_mdr.c:337:1|18(11)[0033] type=0x2A12 x=0(0) :2A 00 12 --------------------------------------------------------------------------------- garmin_mdr.c:337:1|19(12)[0036] type=0x2B00 x=1(1) :2B 01 00 garmin_mdr.c:337:1|20(13)[0039] type=0x2B01 x=1(1) :2B 01 01 garmin_mdr.c:337:1|21(14)[003C] type=0x2B03 x=0(0) :2B 00 03 garmin_mdr.c:337:1|22(15)[003F] type=0x2B04 x=0(0) :2B 00 04 --------------------------------------------------------------------------------- garmin_mdr.c:337:1|23(16)[0042] type=0x2C00 x=0(0) :2C 00 00 garmin_mdr.c:337:1|24(17)[0045] type=0x2C01 x=0(0) :2C 00 01 garmin_mdr.c:337:1|25(18)[0048] type=0x2C02 x=0(0) :2C 00 02 the --- lines are where the type changes, this is used later in MDR9 MDR6 - Cities 1/2 bytes IMG id from MDR1 1/2 bytes (city index) not sure about this, 1 or 2 bytes is from the first bit in the flags(after record size in header) 3 bytes label offset in the image, here 0x800000 is set if the point is indexed 2 bytes region id in MDR13 3 bytes label offset in MDR15 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 3 bytes label offset in MDR15 MDR9 - Poi Category index 1 bytes - unknown 2/3 bytes - poi index in MDR11 garmin_mdr.c:1202:1|o9: 643317 44 4 0 garmin_mdr.c:977:1|POI Index1 garmin_mdr.c:337:1|1[0000] i=1 o=1(1) idx:50094 [163C66:ABLANITSA] :01 01 00 00 garmin_mdr.c:337:1|2[0004] i=2 o=1389(5001) idx:5189 [A38:117] :02 89 13 00 garmin_mdr.c:337:1|3[0008] i=3 o=16B3(5811) idx:50090 [163C30:A LA FIESTA (PARK HOTEL)] :03 B3 16 00 garmin_mdr.c:337:1|4[000C] i=4 o=1944(6468) idx:3 [9A1:1] :04 44 19 00 garmin_mdr.c:337:1|5[0010] i=5 o=1C10(7184) idx:30739 [E85:4] :05 10 1C 00 garmin_mdr.c:337:1|6[0014] i=6 o=1DA5(7589) idx:2 [1512D:"PIKADILI PARK"] :06 A5 1D 00 garmin_mdr.c:337:1|7[0018] i=7 o=1FD2(8146) idx:15 [9A1:1] :07 D2 1F 00 garmin_mdr.c:337:1|8[001C] i=8 o=11CFA(72954) idx:26 [9A1:1] :08 FA 1C 01 garmin_mdr.c:337:1|9[0020] i=11 o=11FB8(73656) idx:1 [15129:???] :0B B8 1F 01 garmin_mdr.c:337:1|10[0024] i=12 o=12C79(76921) idx:65336 [3034:BLATO] :0C 79 2C 01 garmin_mdr.c:337:1|11[0028] i=13 o=12CAF(76975) idx:50432 [1644FE:ARKATA] :0D AF 2C 01 garmin_mdr.c:1003:1|Done 11 len:44 rs:4 The unknown byte is sequential as you see above.
From MDR4 where the type changes(just type, no the subtype) it coresponds to a record here. So you have a type from here you find where point with that type start in MDR10.
MDR10 - POIs indexed by type 1 bytes - subtype 2/3 bytes - POI index in MDR11 - index have 0x8000 or 0x800000 flag-> if the point is indexed or not MDR11 - POIs sorted 1/2 bytes - IMG id from MDR1 1 byte - point index in the image 2 bytes - subdiv index in the image 3 bytes - label offset in the img, 0x800000 flagged, index or no index point(not sure) 2 bytes - region index 0x8000 flagged - may be city or region 3 bytes - label offset in MDR15 MDR13 - Region 1/2 bytes - IMG id from MDR1 2 bytes - region id 2 bytes - country id from MDR14 3 btyes - label offset in MDR15 MDR14 - Country 1/2 bytes - IMG id from MDR1 2 bytes - Country ID 3 bytes - label offset in MDR15 MDR15 - Labels 0 terminated strings referenced from other sections if flags is not 0, it's compressed/encoded If header is more than 286 i've seen this: MDR24 1/2 bytes - IMG id from MDR1 2 bytes - region id same as in MDR13 2 bytes - country id same as in MDR14 3 bytes - label offset in MDR15 MDR29 1/2 bytes - IMG id from MDR1 2 bytes - region id same as in MDR13 3 bytes - label offset in MDR15 3 bytes - unknown yet. -- have fun, alex
Hi Alex
The unknown byte is sequential as you see above.
From MDR4 where the type changes(just type, no the subtype) it coresponds to a record here. So you have a type from here you find where point with that type start in MDR10.
At first I didn't see how this could work with my example files, but I now think you are correct with one small difference in that type 0x28 is out of place: first byte: type 1: all city types and perhaps all indexed points 2: 2a 3: 2b ... etc 7: 2f 8: 30 9: 28 So group 9 is out of order. Also what about points that have a type > 0x30? File that have such points do not any entries in mdr 4 for them. Perhaps you just can't search for them?
MDR10 - POIs indexed by type 1 bytes - subtype Ha - I realised today it was subtype and not type, but I see you said it first.
2/3 bytes - POI index in MDR11 - index have 0x8000 or 0x800000 flag-> if the point is indexed or not
I think this flag is actually to say if the name is new or not. If the flag is not set, then the name of the POI is the same as the name of the previous poi. Thanks I think I will be able to write mdr9 tommorow and hopefully everything will stop being a city! Regards, ..Steve
Hi, Steve! On Wed, Sep 30, 2009 at 2:18 AM, Steve Ratcliffe <steve@parabola.me.uk> wrote:
Hi Alex
The unknown byte is sequential as you see above.
From MDR4 where the type changes(just type, no the subtype) it coresponds to a record here. So you have a type from here you find where point with that type start in MDR10.
At first I didn't see how this could work with my example files, but I now think you are correct with one small difference in that type 0x28 is out of place:
first byte: type 1: all city types and perhaps all indexed points 2: 2a 3: 2b ... etc 7: 2f 8: 30 9: 28
28(regions) and 21(exits) may be are different, i don't have map that contains them in mdr4. (this types that are within ranges may be are types like the cities 1 byte, < 0xff and 1 byte options, like region idx, in the exits it's exit flags) Also its known that some types appear in more than one category, the unknown byte may be related. For the regions there is a section, so no need to be in the POIs. For the exits probably there is a section too, like in the LBL file. (exits appear realy rare in the free maps)
So group 9 is out of order. Also what about points that have a type > 0x30? File that have such points do not any entries in mdr 4 for them. Perhaps you just can't search for them?
in one of the maps i tested with there are 64XX,65XX,66XX types at the end of mdr4, so types greater than 0x30 should be possible. garmin_mdr.c:337:1|76(4b)[00E1] type=0x3008 x=0(0) :30 00 08 garmin_mdr.c:337:1|77(4c)[00E4] type=0x6400 x=0(0) :64 00 00 garmin_mdr.c:337:1|78(4d)[00E7] type=0x6401 x=1(1) :64 01 01 garmin_mdr.c:337:1|79(4e)[00EA] type=0x6402 x=0(0) :64 00 02 garmin_mdr.c:337:1|80(4f)[00ED] type=0x6403 x=0(0) :64 00 03 garmin_mdr.c:337:1|81(50)[00F0] type=0x6404 x=1(1) :64 01 04 garmin_mdr.c:337:1|82(51)[00F3] type=0x6405 x=0(0) :64 00 05 garmin_mdr.c:337:1|83(52)[00F6] type=0x6406 x=1(1) :64 01 06 garmin_mdr.c:337:1|84(53)[00F9] type=0x6407 x=0(0) :64 00 07 garmin_mdr.c:337:1|85(54)[00FC] type=0x6408 x=1(1) :64 01 08 garmin_mdr.c:337:1|86(55)[00FF] type=0x640A x=1(1) :64 01 0A garmin_mdr.c:337:1|87(56)[0102] type=0x640B x=0(0) :64 00 0B garmin_mdr.c:337:1|88(57)[0105] type=0x640C x=0(0) :64 00 0C garmin_mdr.c:337:1|89(58)[0108] type=0x640D x=0(0) :64 00 0D garmin_mdr.c:337:1|90(59)[010B] type=0x640E x=0(0) :64 00 0E garmin_mdr.c:337:1|91(5a)[010E] type=0x640F x=1(1) :64 01 0F garmin_mdr.c:337:1|92(5b)[0111] type=0x6410 x=1(1) :64 01 10 garmin_mdr.c:337:1|93(5c)[0114] type=0x6411 x=0(0) :64 00 11 garmin_mdr.c:337:1|94(5d)[0117] type=0x6412 x=0(0) :64 00 12 garmin_mdr.c:337:1|95(5e)[011A] type=0x6413 x=0(0) :64 00 13 garmin_mdr.c:337:1|96(5f)[011D] type=0x6414 x=1(1) :64 01 14 garmin_mdr.c:337:1|97(60)[0120] type=0x6415 x=0(0) :64 00 15 garmin_mdr.c:337:1|98(61)[0123] type=0x6508 x=0(0) :65 00 08 garmin_mdr.c:337:1|99(62)[0126] type=0x650B x=0(0) :65 00 0B garmin_mdr.c:337:1|100(63)[0129] type=0x650D x=1(1) :65 01 0D garmin_mdr.c:337:1|101(64)[012C] type=0x6511 x=0(0) :65 00 11 garmin_mdr.c:337:1|102(65)[012F] type=0x6604 x=0(0) :66 00 04 garmin_mdr.c:337:1|103(66)[0132] type=0x660A x=1(1) :66 01 0A garmin_mdr.c:337:1|104(67)[0135] type=0x6614 x=0(0) :66 00 14 garmin_mdr.c:337:1|105(68)[0138] type=0x6616 x=0(0) :66 00 16 in mdr9: garmin_mdr.c:337:1|9[0020] i=11 o=11FB8(73656) idx:1 [15129:???] :0B B8 1F 01 garmin_mdr.c:337:1|10[0024] i=12 o=12C79(76921) idx:65336 [3034:BLATO] :0C 79 2C 01 garmin_mdr.c:337:1|11[0028] i=13 o=12CAF(76975) idx:50432 [1644FE:ARKATA] :0D AF 2C 01
MDR10 - POIs indexed by type 1 bytes - subtype Ha - I realised today it was subtype and not type, but I see you said it first.
2/3 bytes - POI index in MDR11 - index have 0x8000 or 0x800000 flag-> if the point is indexed or not
I think this flag is actually to say if the name is new or not. If the flag is not set, then the name of the POI is the same as the name of the previous poi.
Thanks I think I will be able to write mdr9 tommorow and hopefully everything will stop being a city!
Good luck! -- have fun, alex
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. 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. If anyone can confirm pointer to something other than LBL could you let me know what the flags following the MDR 7 start, size and record size fields in the header are please. ..Steve
On Sun, Oct 4, 2009 at 1:58 PM, Steve Ratcliffe <steve@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, ... -- have fun, alex
Alexander Atanasov wrote:
On Sun, Oct 4, 2009 at 1:58 PM, Steve Ratcliffe <steve@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.
Hi, A bit of mdr > 15 or on the device format. Looks like it's the same except references to mdr15 are stripped in the sections < 15. They are moved in mdr17 in each section there. MDR17 format is like this: Section: read one byte and check first bits, section lenght is encoded there. if (b&1) -> len=b>>1 if (b&2) -> read one more and strip first two bits from the first byte if (b&4) -> read two more and strip first three bits from the first byte if (b&8) -> ... read three more This coding is used a lot in the nt maps. (Next in the nt maps there is 80 00 flag, skip this if found. only in the first section) read 1 byte index len read 1 byte text len find first set bit in index len which give the lenght of the index, like this if first bit, len is 1, if second bit 2, etc, strip this bits to get unknown1. mask text len with 0x0f and add 1 to get how much is the lenght of the text, label prefix 0xf0 mask gives unknown2. Start to read text len + index len bytes and get the results, until you read section lenght bytes. Repeat for the next section. this should give you several sections in mdr17 that correspond to the street, city, street,poi sections. (streets in my maps are present two times - one for mdr7, one for mdr21,22,23? ) garmin_mdr.c:1381:1|mdr17: 1362452 101163 0 garmin_mdr.c:350:1|header dlen:42EF/17135 u1=323/803 i1=08/8(sect=9) i2=03/3 tlen=4 ilen=2 slen=3 :64 17 02 23 03 2F garmin_mdr.c:476:1|0005:STR:[/ 57] idx:01/1 garmin_mdr.c:476:1|000B:STR:[/15] idx:02/2 garmin_mdr.c:476:1|0011:STR:[/21] idx:03/3 ... [ cut] garmin_mdr.c:489:1|Section done:2855 garmin_mdr.c:350:1|header dlen:00F7/247 u1=323/803 i1=04/4(sect=5) i2=01/1 tlen=2 ilen=1 slen=2 :D6 03 09 01 41 48 garmin_mdr.c:476:1|42F3:STR:[AH] idx:4D01/19713 garmin_mdr.c:476:1|42F6:STR:[AS] idx:4D02/19714 garmin_mdr.c:476:1|42F9:STR:[AY] idx:4D03/19715 garmin_mdr.c:476:1|42FC:STR:[BA] idx:4D04/19716 and so on. The question here is how to map this section to the corresponding mdrXX. I think it's with i1 in the log(or what left when you get the index lenght) The index is an index into the section, when it's not sequential, the prefix of the street,city,poi is repeated. For example: garmin_mdr.c:476:1|0072:STR:[ГЕНЕ] idx:19/25 garmin_mdr.c:476:1|0077:STR:[ГЕОР] idx:1A/26 garmin_mdr.c:476:1|007C:STR:[ГРАФ] idx:1D/29 garmin_mdr.c:350:1|26[00C8] IMG:[12345678] roadptr: 80202C lbl[0146]:[ГЕОРГ ВАШИНГТОН] left=1 :01 2C 20 80 46 01 00 01 garmin_mdr.c:350:1|27[00D0] IMG:[12345678] roadptr: 801E24 lbl[0156]:[ГЕОРГИ БЕНКОВСКИ] left=1 :01 24 1E 80 56 01 00 01 garmin_mdr.c:350:1|28[00D8] IMG:[12345678] roadptr: 8021F5 lbl[0167]:[ГЕОРГИ С. РАКОВСКИ] left=1 :01 F5 21 80 67 01 00 01 You see that the 'ГЕОР' prefix is same for 26, 27, 28 indexes in MDR7. idx 29 is with different prefix. MDR18 is mistery yet. contains fixed size records. may be it is sorting. MDR20 - contains pois sorted by something. may be by name. 2/3 bytes records, POI idx in mdr11 if flagged with 0x8000/0x800000 it's a new name, otherwise the previous is repeated. MDR21,22,23 are streets sorted in different ways, format is the same as MDR7 without the label. Still one byte at the end is unclear. MDR24 - regions garmin_mdr.c:350:1|1[0000] img:12345678 rid:1 cid:1 imglbl:[800087] left:0 :01 01 00 01 00 87 00 80 1/2 img id, 2 region id, 2 country id, 3 label in the img file MDR25 and MDR30 have only one record, i guess its country testing with small maps. MDR28 - city sorted contains 1/2 bytes city record index in mdr5. MDR29 - regions again, needs more work. No time to get to the details, but that should help to get started with them. -- have fun, alex
I've managed to construct a working MDR file with all of 2 POIs in it.
Really cool. I hope you have more succes with it. While looking at the mdr files a question arose. What has the filename of the mdr to be? I.e. what has to be in front of the *.mdr? Does the number has a meaning? Regards, Johann
On 23/09/09 21:19, Johann Gail wrote:
While looking at the mdr files a question arose. What has the filename of the mdr to be? I.e. what has to be in front of the *.mdr? Does the number has a meaning?
Not as far as I know. I believe it is just like the overview map and can have any ascii characters in it. I called mine test and that was OK. ..Steve
participants (8)
-
Alexander Atanasov -
Bernhard Heibler -
Felix Hartmann -
Johann Gail -
Mark Burton -
Marko Mäkelä -
Steve Hosgood -
Steve Ratcliffe