OSM Map On Garmin/IMG File Format
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.