Welcome guest, is this your first visit? Click the "Create Account" button now to join.
Page 4 of 14 FirstFirst ... 23456 ... LastLast
Results 31 to 40 of 133
  1. #31
    Member
    Join Date
    Aug 2013
    Location
    A
    Posts
    24
    Rep Power
    68

    Default

    I test with this maps:
    [Only registered and activated users can see links. ]
    using "add zeros" method to compensate the changes in offset (it is faster to do as i have to do it manually)
    I only convert on tile, not all of them, and it worked!!
    When converting from pseudo-nt to non-nt i got a "non-nt locked map", as the maps seems to be locked.
    Then i used [Only registered and activated users can see links. ] to unlock it and...
    I Can open it with gpsmapedit, cgpsmapper etc...

  2.    Advertissements


  3. #32
    Navigation software Moderator kunix's Avatar
    Join Date
    Sep 2011
    Location
    Belarus
    Posts
    908
    Rep Power
    438

    Default

    Quote Originally Posted by testlelelala View Post
    I think that the info in imgformat-1.0.pdf is not complete/ok , take a look at [Only registered and activated users can see links. ].
    Thank you for this nice doc! After looking at it briefly I've started suspecting that "pointers" are offsets relative to subsections of subfiles (aka LBL1 is a subsection of LBL), and therefore your method is fine.

    Quote Originally Posted by testlelelala View Post
    Either way, in case some of the offsets do really point to a position in another subfile, this could be detected, just taking into account that if some offset in a header is greater than the end of the corresponding subfile, the subtract value will change including now the header size of the others subfiles that are between or something else.
    Well, I wasn't talking only about headers, I was talking about some data referring other data through specifying the offset. You can't fix that without deep IMG format knowledge.
    But your doc and the fact that you can convert CarteBlanche convince me that your way is just fine.

    Also, I've discovered another way:
    1) Unpack the pseudo-NT IMG with GMapTool
    2) For every YYYYYYYY.GMP
    2.1) for every XXX subfile inside YYYYYYYY.GMP
    2.1.1) save a copy of YYYYYYYY.GMP as YYYYYYYY.XXX
    2.1.2) replace the GMP header with XXX header in YYYYYYYY.XXX
    3) Pack the map with GMapTool

    This method has a disadvantage: the map size increases 6-7 times.
    But it also allowed me to open CarteBlanche with mapedit. And also all maps converted this way (I've tested NT and pseudo-NT) work fine on Garmin devices.

    It seems to me that both NT and non-NT maps can be stored using GMP and not using GMP (I've checked, see above).
    So, maybe GMP is not relevant to NT at all? Maybe NT is just another way of storing/encoding individual subfiles?

    Can you try your method of "offset subtracting" on NT maps? And then use those maps on Garmin devices?
    Last edited by kunix; 12th August 2013 at 08:46 AM.

  4. #33
    Member
    Join Date
    Aug 2013
    Location
    A
    Posts
    24
    Rep Power
    68

    Default

    Thanks, i like your method, in a way is similar to "add zeros" method, preserving absolute offsets of the data, but your method is even faster, i like it!!
    Obviously, for proper conversion, it is needed to do the whole "subtract" offsets thing and you get a proper non-nt img with a proper size.
    But with your method you get a quick way to obtain the the non-nt img and then the *.mp (polish format map). Even if the img is oversized, the .mp data is not, so is perfect for that.
    And that is ultimately what we want it for. The oversized img is not needed anyway as the original "nt whatever" is already available if we don't want the data.

    Quote Originally Posted by kunix View Post
    2.1.2) replace the GMP header with XXX header in YYYYYYYY.XXX
    To be clear, i would add that the XXX header need to be "overwritten" to whatever is at the beginning, and NOT inserted if you "insert" you move the data and loose the original absolute offset position, and it won't work.

    Definitely, "add zeros method" is deprecated in favor of yours.
    Quote Originally Posted by kunix View Post
    Well, I wasn't talking only about headers, I was talking about some data referring other data through specifying the offset. You can't fix that without deep IMG format knowledge.
    But your doc and the fact that you can convert CarteBlanche convince me that your way is just fine.
    There was NO differences in the "body" of the sufiles, comparing pseudo-nt to non-nt (not even a byte). The only differences where in the headers, so no need to correct anything in the data itself.

    Quote Originally Posted by kunix View Post
    And also all maps converted this way (I've tested NT and pseudo-NT) worked fine on Garmin devices.
    You say here NT (real NT?), what do you mean, you say you could open it on Garmin devices, but Could you open NT(real) converted maps in Gpsmapedit?

    Could you point me to a link to a real NT map?(better if it is a small size download!)
    Last edited by testlelelala; 12th August 2013 at 09:15 AM.

  5. #34
    Navigation software Moderator kunix's Avatar
    Join Date
    Sep 2011
    Location
    Belarus
    Posts
    908
    Rep Power
    438

    Default

    Quote Originally Posted by testlelelala View Post
    There was NO differences in the "body" of the sufiles, comparing pseudo-nt to non-nt (not even a byte). The only differences where in the headers.
    I remember that. But don't you think it's true only because your map is too small and you don't test all the available data formats? It would be nice to compare this way something like CNE, huh ?

    Quote Originally Posted by testlelelala View Post
    You say here NT (real NT?), what do you mean, you say you could open it on Garmin devices, but Could you open NT(real) converted maps in Gpsmapedit?
    Of course, I've tried it! I could open a real NT map after my "conversion". But, mapedit opened it waay too quickly and didn't draw anything at all, though, it did save something to .mp file. The produced .mp file mainly consists of "[POI]" sections. Nothing interesting...
    In the map statistics mapedit shows the following:
    Spoiler: pic
    [Only registered and activated users can see links. ]

    So you see it can't decode addresses, polylines, polygons, roads...

    Quote Originally Posted by testlelelala View Post
    Could you point me to a link to a real NT map?(better if it is a small size download!)
    I used some maps that I could find on my PC. I don't have any working links... Also I can't download/upload anything large right now, as I have a very bad internet connection right now.
    But I do believe that almost any map you can find here is NT. pseudo-NT and non-NT maps are quite rare. If want to to be absolutely sure, download City Navigator XXX NT
    Last edited by kunix; 12th August 2013 at 10:15 AM.

  6. #35
    Navigation software Moderator kunix's Avatar
    Join Date
    Sep 2011
    Location
    Belarus
    Posts
    908
    Rep Power
    438

    Default

    Quote Originally Posted by testlelelala View Post
    To be clear, i would add that the XXX header need to be "overwritten" to whatever is at the beginning, and NOT inserted if you "insert" you move the data and loose the original absolute offset position, and it won't work.
    Yes, of course. I was doing it by
    1) calculating the maximum header size that definitely doesn't overlap the subfile bodies (=max(offset_of_header[i] + header_size[i]))
    2) copying the calculated amount of bytes starting from header XXX to offset 0.
    Of course, we could do something more subtle like calculating the exact size of header XXX in each case. But it would require knowledge of IMG format much deeper than I have. I'm an absolute IMG-noob, as I said.

  7. #36
    Member
    Join Date
    Aug 2013
    Location
    A
    Posts
    24
    Rep Power
    68

    Default

    The header size is located in the first two bytes of each header.
    Example: When you found "GARMIN RGN" before that you see two bytes 7D 00 it means x7D which after conversion to decimal is 125 bytes.
    Analog with LBL (xEC-->236 bytes), NET(x64-->100 bytes) and NOD(x3F-->3 bytes)
    The only one "odd" is the TRE header that is larger that what you see in the first two bytes, because it could change with copyright info, nevertheless this extra info is not necessary, you could only grab the size that you get from the first two bytes.

  8. #37
    Member
    Join Date
    Aug 2013
    Location
    A
    Posts
    24
    Rep Power
    68

    Default

    Quote Originally Posted by Giomen View Post
    What about it?

    Other than that, I have done some research on the deviation of China map
    coordinates. Though there is no concrete result, you can follow it in this
    article
    [Only registered and activated users can see links. ]
    My ultimate goal is to change the coordinates in place, i.e. change individual
    bytes without recompiling the map. The cmdc tool is to generate the deviation
    table. The gimgfixcmd tool fixes the deviation of a map.

    ...

    The reverse engineering of the unlocking algorithm and the GMP section (aka the NT format by Garmin) are my work.

    It is really work!
    Quote Originally Posted by Giomen View Post
    I do not write what it is saucer with blue border! But source code is very useful things sometime. We had big provocative discussion about non-NT and NT format on russian forum. Do the bible by John Mechalas have another analogue?

    Quote Originally Posted by catymag View Post
    It could be nice to hear
    [Only registered and activated users can see links. ]
    opinion about this matter
    I also need that Wu Yongheng explain us what he means. I didn't understand what he said.
    From what i see, gimgtools doesn't help us.
    In [Only registered and activated users can see links. ]
    He says:
    "...Credits:
    Most of the reverse engineering on IMG format was done by other pepole (listed
    below). I just read their docs and code. The reverse engineering of the
    unlocking algorithm and the GMP section (aka the NT format by Garmin) are my
    work...."

    But i don't see where in his utilities he reverse engineered the pdeuso-NT format, or even more, where, he reverse engineered the NT format as he is claiming.
    It would be nice he accomplished that, it would be nice Wu Yongheng explain us.

  9. #38
    Navigation software Moderator kunix's Avatar
    Join Date
    Sep 2011
    Location
    Belarus
    Posts
    908
    Rep Power
    438

    Default

    Quote Originally Posted by testlelelala View Post
    The header size is located in the first two bytes of each header.
    Example: When you found "GARMIN RGN" before that you see two bytes 7D 00 it means x7D which after conversion to decimal is 125 bytes.
    Analog with LBL (xEC-->236 bytes), NET(x64-->100 bytes) and NOD(x3F-->3 bytes)
    The only one "odd" is the TRE header that is larger that what you see in the first two bytes, because it could change with copyright info, nevertheless this extra info is not necessary, you could only grab the size that you get from the first two bytes.
    I'm afraid it's not true. I've seen a map with GMP subfiles having some data (not copyright) beyond the standard header size for almost all headers (except 2, don't remember which ones), but before the next header. This map was an NT one, actually.

    Quote Originally Posted by testlelelala View Post
    But i don't see where in his utilities he reverse engineered the pdeuso-NT format, or even more, where, he reverse engineered the NT format as he is claiming.
    It would be nice he accomplished that, it would be nice Wu Yongheng explain us.
    See, for example, gimglib.c line 153, it parses GMP headers below.
    Also function create_patch at gimgunlock.c line 95 should be able to handle NT map data.
    Last edited by kunix; 22nd August 2013 at 06:31 AM.

  10. #39
    Member
    Join Date
    Aug 2013
    Location
    A
    Posts
    24
    Rep Power
    68

    Default

    Quote Originally Posted by kunix View Post
    I remember that. But don't you think it's true only because your map is too small and you don't test all the available data formats? It would be nice to compare this way something like CNE, huh ?
    The example i uploaded here in the thread is just that, an example. I compared and analyzed bigger and complex maps (non-nt and pseudo-nt) and came to some conclusions, this conclusions came from this complex maps and not from the "example" map, the example map is the one i selected to upload here to share, i thought this was obvious.
    Obviously this conclusions could be wrong, if you found one counter-example please provide it here so we can analyse it.

    Quote Originally Posted by kunix View Post
    I'm afraid it's not true. I've seen a map with GMP subfiles having some data (not copyright) beyond the standard header size for almost all headers (except 2, don't remember which ones), but before the next header. This map was an NT one, actually.
    Definitely i'm talking about non-nt and pseudo-nt maps, which are the ones treated in this thread (NT maps are different!!!).
    And YES the first two bytes in the header give you the size of the header. I'm not the only one saying this, see [Only registered and activated users can see links. ] and seacrh for "Header Length" string.
    Also, there is not a "standard header size", you get the size from the first two bytes, it could change between different maps.

    Regarding this i downloaded the Malsingmaps which are NT.(in this case this is the only one i analysed, no diversity here besides the several individual maps included)
    What i found is that TRE, LBL and NET headers have a length as it is given in the first two bytes of each header, as in the non-NT/pseudo-nt maps.
    On the contrary RGN and NOD headers don't. Further analysis make me to believe that the extra data for example in the RGN header, is in fact not part of the RGN header and is another header of x4a length (74 bytes) (info given in the first two bytes of this extra data). This extra header point to some "dictionary" data.
    If you download Malsingmaps you will see what i mean.
    It is difficult to explain here in a short comment, and it is useless to do so as i don't have any other relevant info.
    The extra data in the NOD header doesn't seem to be another header.
    From what i saw to convert from NT maps to non-NT maps it would take definitely more work and i think ¡'m not capable of doing this.

    Quote Originally Posted by kunix View Post
    See, for example, gimglib.c line 153, it parses GMP headers below.
    Also function create_patch at gimgunlock.c line 95 should be able to handle NT map data.
    If you explain how can i use it to convert from NT to non-nt, or at least pseudo-nt to non-nt it would be great, i just don't see how you can accomplish this with this utilities.
    Last edited by testlelelala; 22nd August 2013 at 05:42 PM.

  11. #40
    Navigation software Moderator kunix's Avatar
    Join Date
    Sep 2011
    Location
    Belarus
    Posts
    908
    Rep Power
    438

    Default

    Quote Originally Posted by testlelelala View Post
    If you explain how can i use it to convert from NT to non-nt, or at least pseudo-nt to non-nt it would be great, i just don't see how you can accomplish this with this utilities.
    I can't explain that, of course. And you can't accomplish that with bare gimgtools, obviously.

 

 

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •