OSM Map On Magellan/Format/imi archive

Contents

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.