logo separator

[mkgmap-dev] What's the maximum size of global index MDR size?

From Gerd Petermann GPetermann_muenchen at hotmail.com on Sat Dec 11 10:06:49 GMT 2021

Hi all,

does anybody know the actual limits?
The structure of the MDR file encodes offsets with 4 bytes. 
We can assume those are interpreted as unsigned integers, so 0xffffffff (2^32 ~ 4G) 
would be the highest possible offset, the section length is also encoded with 4 bytes, 
so maybe we can even write a correct MDR that is close to 8G if the last section is the largest.
The MDR sub file for the PC is stored in the *_mdr.img file which also contains the SRT sub file. 
As far as I know the *.img file can grow > 4G, so I hope that our routines to write large *.img files are OK.

As of now, the --gmapi option doesn't work with an MDR sub file > 2G, the corresponding folder will contain a *.MDR file with 0 bytes.
The display tool programs also fail to analyse such a file.

I see that both mkgmap and MapSource can handle an *_mdr.img written 
by mkgmap file that is > 2G as long as the MDR sub file itself is < 2G.
Current mkgmap fails with different errors when an offset in the MDR 
sub file gets > 2G. I started to fix those errors but MapSource crashes 
with such an index file.
My problem: I don't know if it crashes because mkgmap still does something 
wrong or because MapSource interprets the offset field as a signed int 
(as mkgmap does so far in some places). With signed int the 
values > 2G are interpreted as negative values and that cannot work.

Is it possible to have an MDR sub file > 2G in an *.img file? 
If yes I may invest more time to find out what is wrong in mkgmap.
If no, we may skip the writing of sections 
(e.g. Mdr 21 (streets sorted by region) or Mdr 22 (streets sorted by country)
or maybe even Mdr 15 (the string table).

Has anybody an idea how the string compression of Mdr15 section might work?

Gerd


More information about the mkgmap-dev mailing list