OSM Map On Garmin/IMG File Format

From OpenStreetMap Wiki
Jump to navigation Jump to search

OSM Map On Garmin

A reverse-engineering of Garmin's IMG file format

The IMG file contains all the info needed to render a map on a Garmin GPS unit, and may support autorouting information for those GPS units that offer navigation (i.e in-car GPS routers and some types of devices intended for hikers).

The .img file is basically a hard-disk image (complete with partition table) containing a filesystem which itself contains subfiles that provide the functionality for the Garmin GPS unit. The filesystem seems to be 'flat': that is, it doesn't directly support the concept of subdirectories, however the .GMP subfiles do provide a kind-of subdirectory structure. See below for more on that.

Here is source code for a simple Linux/Unix command-line program to take an .IMG file and to create a directory of files corresponding to its contents. It would be simple to modify this to run on DOS/Windows... help yourselves!

The IMG Header

Byte Offset Length (bytes) Description
0x00 1 If non-zero, every byte of the entire .img file is to be XORed with this value
0x01 7 ??? All zeroes
0x08 1 Map's version major
0x09 1 Map's version minor
0x0A 1 Map's month
0x0B 1 Map's year
0x0C 2 ??? All zeroes
0x0E 1 Mapsource flag, 1 - file created by Mapsource, 0 - Garmin map visible in Basecamp and Homeport
0x0F 1 Checksum, sum of all bytes modulo 256 should be 0
0x10 7 Signature: DSKIMG 0x00 or DSDIMG 0x00 for demo map
... See [1]
0x40 1 Physical block number of FAT header

The Filestore

A simple 'flat' filestore based on File Allocation Tables (FATs) though there is no serious resemblance between the format of a FAT used here and the more (in)famous FAT used in Microsoft's DOS and early Windows filestores.

The File Allocation Table starts with a header at the physical block number as defined in the IMG file header at address 0x040. The first FAT is found in the next physical block after this FAT header. The size of a physical block is always 0x200 (= 512 bytes). Thus, if the physical block number is 2 then the FAT header is at 2 * 0x200 = 0x400, hence, the next physical block is at 0x600 which contains the first FAT.

Example:

00000600   01 30 30 30 31 30 30 30 30 52 47 4E 45 E8 2B 00   .00010000RGNE.+. (first entry)
00000800   01 30 30 30 31 30 30 30 30 52 47 4E 00 00 00 00   .00010000RGN.... (second entry)
(...)
00007400   01 30 30 30 31 30 30 30 30 4E 4F 44 00 00 00 00   .00010000NOD.... (last entry)
00007600   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ (end of FAT)

The Subfiles

Each subfile has its own page, but as a quick reference the known subfiles are:

The TRE Subfile

Information of this subfile can be found here.

The NOD Subfile

This contains the routing information, unused by those GPS units that don't offer routing. Fill in here ..

The MDR Subfile

This contains the searchable address table used for finding routing destinations. See here for details.

The SRT Subfile

This is a fairly short file, containing a lookup table that categorises the characters in the map's codepage, and defines their collating sequence. Details are here ..

The GMP Subfile

This appears to represent a subtile of the larger area covered by the .IMG file. Its filename is of the form IXXXXXXX.GMP (where the 'X' characters are uppercase hexadecimal digits). Inside the .GMP file is a copyright message and the contents of a .TRE file, an .RGN file, an .LBL file, a .NET file and a .NOD file corresponding to that subtile. See here for details.

The DEM Subfile

The DEM (Digital Elevation Model) subfile contains elevation data used by Mapsource (shading, height profiles of routes) and Basecamp (3D view, height profiles of routes). Unfortunately, it seems that not much information is available right now. GMapTool can create "empty" DEM files and can also be used to extract DEM subfiles from IMG files with DEM information. See here for some preliminary results.

Links