OSM Map On Magellan/Format/imi archive
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 |