Additional NOD format can be found atQuote:
Originally Posted by Giomen [Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]
Additional NT format (but far from complete) can be found at
[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]
Thanks syzygy.
Yes i already read those documents the other day.
And you are correct on what you are saying.
The imgformat-1.0.pdf document was the most useful. The document is a little incomplete, but we don't need to know/understand where exactly the offset point to. We only need to know where are the offsets to be changed and the amount that need to be sustracted from them to properly point to the data when relocated.
It was relative simple, i need to see some details and i'll upload what i found, later.(i've been busy)
But to resume i will say: THE MATTER IS CLOSED!!!. It is definitely possible to convert pseudo-NT to non-NT without any problem.
I will upload the details and explanation later. But correctly changing the offsets is easy.
The ideal thing would be to do it automatically, but the most important part, that is understanding the issue, is CLOSED.
Decompiling maps is a quite different matter than unlocking maps.Quote:
Originally Posted by kunix [Only registered and activated users can see links. Click Here To Register...]
There are many companies, which own digital data suitable for GPS maps. I think in each country there could be a few such companies. They could have better local data than Navteq. Or they sell data to Navteq. Actually they could sell data to any publisher who releases maps. But there is condition - no leaks including no possibility to decompile their data. Since cgpsmapper gives no protection, there are nearly no alternative commercial maps. We get one City Navigator Europe, one Topo Germany, one Topo France etc. And Garmin control market, they don't sell their tools to competition.
Now is interesting what would happen if someone would release decompiling tools for Garmni NT maps? Would Navteq stop selling data to Garmin?
That would probably be a navigation market disaster for Garmin, right? And a big win for others who didn't have good map data before.Quote:
Originally Posted by Kanopus [Only registered and activated users can see links. Click Here To Register...]
Well, I know that both maps formats can be unlocked. I know that unlocking is "relatively" easy and that free OpenSource tools are available.
What I was talking about is that non-NT maps can be decompiled with easily available 3rd party tools and NT maps cannot. I can be wrong here, as I'm an absolute noob when it comes to maps.
There are Garmin NT maps, non-NT maps and 3-rd version are quasi-NT maps created by cgpsmapper. Quasi-NT maps could be decompiled, but until recently there was no available tools to do it. That kind of tools can make problems for remaining competitors of Garmin.
Yeah, I've forgotten about quasi-NT maps... Thank you.
As I understand, decompilation of CarteBlanche won't make their sales significantly lower, as they're not encrypting their map anyway. Who would buy the map if it can be downloaded for free? :) Most probably most map installations are performed by unofficial dealers, who can surely find it and download it...
But it will make Garmin devices less competitive and some other navigation devices more competitive, due to wider map material available. Thus, everyone who sells Garmins would be hit somehow. Am I right ? :)
Doubt, as Garmin is the official sponsor of the Nokia mapping. :) How would all Lumias have a free world wide licence for the Navteq maps if Garmin don't pay for those maps?Quote:
Now is interesting what would happen if someone would release decompiling tools for Garmni NT maps? Would Navteq stop selling data to Garmin?
I'll try to be as clear as possible.
What we want to do is to convert a garmin *.img map from pseudo-nt to non-nt.
So, i have this "example2_NT.img" map and using GmapTool i "split it" and get its subfile "48580011.GMP"
Inside the gmp as stated in first post, there are all of the 5 regular subfiles TRE, RGN, LBL, NET and NOD, and the info on them is EXACTLY the same as if the file where non-nt.
If we get them we can "re-join" them using GmapTool and get the non-nt version.
What i'll explain here is how to find, extract and modify the header of each subfile inside the gmp.
As i already have the raw data of this example i can compare version pseuso-NT and non-NT made by myself, with this and some imagination i realize what is needed to be done.
Here it is the comparison of each subfile header in the pseudo-nt and non*nt version (obviously you won't have the non-nt version in real life !!)
Spoiler: pic
Spoiler: old pics
I only put the headers as they are the only thing that is changed, the bytes you see in red are the ones that differ. This bytes represents the offset (location) of the data within the GMP file.
As in pseudo-NT the subfiles are re-arranged the offsets need to be changed to continue pointing to the right location where the data is.
The headers are easy recognizable and are easy to extract from the GMP file as they are one after another, where one ends the other begins.
The same is with the "body" of the data of each subfile.
The GMP is structured as
GMP header
TRE header
RGN header
LBL header
NET header
NOD header
TRE body
RGN body
LBL body
NET body
NOD body
Once you have each header, with the info inside them you'll know where to look up to retrieve the "body" in the GMP file.
For example in the TRE header (look at the right image) at x31 (4bytes) it is written where it is the beginning of the TRE "body" data (offset).
x31 4bytes means that the info is from x31 to x34. It needs to be read backwards. You see 24 03 00 00 so it is x00000324, without the meaningless zeros x324.
So the body of the TRE subfile begins at x324.
The other differences are from other offsets that point to other locations inside the TRE subfile inside the GMP
The differences are because the data is re-arranged, to put them back as they need to be you need to subtract the offsets some value as it is written here:
Spoiler: list
Whith this info we are now capable to locate and extract the body of each sufile.
Now you put in the "offset corrected" header and the body and create each subfile.
Now you can "join" all the subfiles using GmapTools (you need to SELECT "SHORT HEADER" option), and you get the non-NT version of the img.
You can open it with GPSmapedit, maptk 3.3.0, cgpsmapper 0085 etc...
There is another possibility as explained in an earlier post, instead of changing the offsets in the header you can leave them as they are, and add zeros between the header and the body to maintain the same absolute position of the body.
The number of bytes zeros needed in between are the same that you subtract in the other option.
For example in the TRE subfile, you can leave the header as it is in the gmp then add 587 bytes of zeros and then append the body data.
Obviously this need to be automated for "lot of map" conversion. But for a few map it can be done.
If anyone is already in the know of C, C+ or any other, it would be easy for him/her, i hope so, because i don't have so much time and i would need to study the relevants commands to manage binary data etc...
EDIT: I attach the files i used if you want to use them
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. Click Here To Register...].
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.
