OSM Map On Magellan/Format/imi archive

From OpenStreetMap Wiki
< OSM Map On Magellan‎ | Format(Redirected from IMI)
Jump to navigation Jump to search

File Archive

The Magellan map file is an archive file consisting of a table of contents and the body containing the files but is not a compressed archive. The following description uses an imi-file as an example. Both sections end with a 'magic' word "MAGELLAN" and a checksum. All files within the archive, as well as the imi-file have the same ENDIAN encoding. The old format (eg Meridian) was BIG_ENDIAN encoded and the new format (since the Triton Series) is LITTLE_ENDIAN encoded. So the following numbers are all encoded with least significant byte first because the imi-format is a new format. Following conventions will be used:

name bytes bits
byte 1 8
short 2 16
int 4 32
long 8 64

Table of Contents

The TOC starts with the number of files contained in the archive.

Header
Bytes 0 - 7 0 1 2 3 4 5 6 7
Number of Files (int) Number of Files (int)

Followed by one or more TOC entries

TOC Entry
Bytes 8 - 31 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Name of File (ASCII) 0 (byte) Name Extension of File (ASCII) 0 (int) Offset of the file from beginning of archive (int) length of file (int)

The next TOC entry would fill bytes 32-56 and so on and so forth. The toc is ending with a checksum and the "magic" word 'MAGELLAN'. Lets assume this archive contains only one file than it would be continued this way:

TOC End
Bytes 32-41 0 1 2 3 4 5 6 7 8 9
Checksum1 (byte) Checksum2 (byte) 0x4d (byte) 0x41 (byte) 0x47 (byte) 0x45 (byte) 0x4c (byte) 0x4c (byte) 0x41 (byte) 0x4e (byte)

The total length of the TOC is

Length(TOC) = 40 + NumberOfFiles * 24

The remaining 22 bytes are filled up with 0.

NOTE: Some maps available at the Internet does not contain a "TOC end" 32 bytes sequence. NOTE: "VantagePoint" may ignore an absence of "TOC end" sequence.

Body

Starting with the first byte after the TOC the body containing the file data follows. There is no byte alignment (?) or checksum in the body. Lets assume the archive has only a single text file, with the text "Hello World" within. Then the body would look like this:


Body
Bytes 64 - 74 0 1 2 3 4 5 6 7 8 9 10
0x48 (byte) 0x65 (byte) 0x6c (byte) 0x6c (byte) 0x6f (byte) 0x20 (byte) 0x57 (byte) 0x6f (byte) 0x72 (byte) 0x6c (byte) 0x64 (byte)

NOTE: If the length of a file inside the archive is expressed by an odd number, then one byte containing zero (hex 00) will be inserted after that file. So, a next file will start from even offset.

For example (info from old map of France from maps4me.net):

TOSMFR0613.imi
File number File name File offset (dec) File offset (hex) File length (dec) File length (hex)
234 00lay9.lay 388698106 FA 0F 2B 17 1885130 CA C3 1C 00
235 00map.ini 390583236 C4 D3 47 17 12539 FB 30 00 00
236 00poi.cfg 390595776 C0 04 48 17 1786 FA 06 00 00

As you see, file number 234 starts from offset 388698106 and its length is 1885130. So, the offset of the next (235) file will be 388698106+1885130=390583236. Next (235) file starts from offset 390583236 and its length is 12539. But 12539 is an odd number. So, next (236) file offset will be 390583236+12539+1=390595776.


Also the body has a checksum and a magic:

Body End
Bytes 75 - 85 0 1 2 3 4 5 6 7 8 9 10
0x4d (byte) 0x41 (byte) 0x47 (byte) 0x45 (byte) 0x4c (byte) 0x4c (byte) 0x41 (byte) 0x4e (byte) 0 (byte) optional when body is not word aligned Checksum1 (byte) Checksum2 (byte)

Checksum

The checksum always has two bytes. It is built by xor operation. The first byte of the checksum xors all bytes on odd positions and the second on even positions. The checksum can also be built by understanding the data as a stream of shorts, its just a question of implementation.

The first checksum in the TOC is build over the first NumberOfFiles * 24 + 8 bytes of data. The second checksum is build over the complete file starting at byte 0.

For example, the checksum could be calculated as follows. Read the bytes two at a time as shorts. To start off the first short is XOR'd with zero (which will return the same value as the short). Progressively the XOR'd result is then XOR'd with each short until the end. The first byte of the XOR'd result becomes the checksum for odd bytes and second byte of the XOR'd result becomes the checksum for even bytes.

NOTE: "VantagePoint" may ignore wrong file checksum.

NOTE: "VantagePoint" can understand a short "file end" sequence, where there are only an optional "zero" byte for word alignment and two bytes of file checksum.

NOTE: Some maps from maps4me.net contain strange long "file end" sequence

0x20 0x4d 0x41 0x47 0x45 0x4c 0x4c 0x41 0x4e 0x00 (always) Checksum1 Checksum2  

Example

Here is an example of an archive containing a single file named test.txt with the content 'Hello World':

0x01 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x74 0x65 0x73 0x74 0x00 0x00 0x00 0x00
0x00 0x74 0x78 0x74 0x00 0x00 0x00 0x00 0x40 0x00 0x00 0x00 0x0B 0x00 0x00 0x00
0x34 0x11 0x4D 0x41 0x47 0x45 0x4C 0x4C 0x41 0x4E 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x48 0x65 0x6C 0x6C 0x6F 0x20 0x57 0x6F 0x72 0x6C 0x64 0x4D 0x41 0x47 0x45 0x4C
0x4C 0x41 0x4E 0x00 0x0B 0x2B