Welcome guest, is this your first visit? Click the "Create Account" button now to join.
Page 4 of 15 FirstFirst ... 2345614 ... LastLast
Results 31 to 40 of 141
  1. #31
    Navigation software Moderator

    kunix's Avatar
    Join Date
    Sep 2011
    Location
    Belarus
    Posts
    1,038
    Rep Power
    601

    Default

    testlelelala
    I really don't think that it's a good idea to change offsets of subfile data.
    If you search for "pointer" keyword inside imgformat-1.0.pdf, you would find that it's not uncommon for data from one subfile to point (i.e. to contain the offset) to data from some other subfile. For example, some TRE data could point to data inside RGN, NET could point to NOD and to NET itself.
    Therefore, if you move subfiles, you change all the offsets and all the links mentioned above are destroyed.

  2.    Advertissements


  3. #32
    Member
    Join Date
    Aug 2013
    Location
    A
    Posts
    25
    Rep Power
    61

    Default

    Quote Originally Posted by kunix View Post
    testlelelala
    I really don't think that it's a good idea to change offsets of subfile data.
    If you search for "pointer" keyword inside imgformat-1.0.pdf, you would find that it's not uncommon for data from one subfile to point (i.e. to contain the offset) to data from some other subfile. For example, some TRE data could point to data inside RGN, NET could point to NOD and to NET itself.
    Therefore, if you move subfiles, you change all the offsets and all the links mentioned above are destroyed.
    Yes i read that, and have some thoughts about it in that moment.
    But changing the offsets of the subfiles already is working perfect!!.
    Keep in mind that i already know what it must/should be as i have maps compiled by myself in where i have both, pseudo-NT and non-NT.
    I knew before hand that there where differences between pseudo-NT and non-NT map compilation of the same data. Then i realize that this differences where the offsets, this is confirmed as subtracting the same value, change the offsets from pseudo-nt to the ones in the non-NT version, in a way that the pseudo-nt header now became exactly the same as the non-nt header.
    None of the headers i revised had an offset that pointed out of the corresponding data of that header subfile.
    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. ].

    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.
    The regular non-nt img is structured as:
    some things
    TRE subfile
    some zeros
    RGN subfile
    some zeros
    LBL subfile
    some zeros
    NET subfile
    some zeros
    NOD subfile

    In case this occur, it would need to be revised. But i bet that this won't in case of pseudo-nt.
    But just to know that the pseudo-nt has exactly the same data that the non-NT counterpart and that the only thing to change is apparently the offsets, makes it easier to analyse in the future cases as the one you are referring.
    Last edited by testlelelala; 12th August 2013 at 03:03.

  4. #33
    Member
    Join Date
    Aug 2013
    Location
    A
    Posts
    25
    Rep Power
    61

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

  5. #34
    Navigation software Moderator

    kunix's Avatar
    Join Date
    Sep 2011
    Location
    Belarus
    Posts
    1,038
    Rep Power
    601

    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.

  6. #35
    Member
    Join Date
    Aug 2013
    Location
    A
    Posts
    25
    Rep Power
    61

    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.

  7. #36
    Navigation software Moderator

    kunix's Avatar
    Join Date
    Sep 2011
    Location
    Belarus
    Posts
    1,038
    Rep Power
    601

    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:
    [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.

  8. #37
    Navigation software Moderator

    kunix's Avatar
    Join Date
    Sep 2011
    Location
    Belarus
    Posts
    1,038
    Rep Power
    601

    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.

  9. #38
    Member
    Join Date
    Aug 2013
    Location
    A
    Posts
    25
    Rep Power
    61

    Default

    Quote Originally Posted by kunix View Post
    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.
    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.

  10. #39
    Member
    Join Date
    Aug 2013
    Location
    A
    Posts
    25
    Rep Power
    61

    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.

  11. #40
    Navigation software Moderator

    kunix's Avatar
    Join Date
    Sep 2011
    Location
    Belarus
    Posts
    1,038
    Rep Power
    601

    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.

 

 
Page 4 of 15 FirstFirst ... 2345614 ... LastLast

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
  •  
This website uses cookies
We use cookies to store session information to facilitate remembering your login information, to allow you to save website preferences, to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.