
New insight into Garmin File Structures
On this page we post our recent findings . It is updated regularly!
Forcing a tile to show higher detail
It is possible to set the detail level of a single tile (img file) , a technique used by Garmin in some of the TOPO maps.
The tile still shares the map's various zoom levels., ie 17,19,20,22,24 but three of them for this tile have been flagged to show greater detail.
The effect is very striking but perhaps not very useful except if you wish to force a particular tile to show more detail.
It also explains why TOPO Germany / France have their detail level set so high , even if you select the 'lower' map option.
At present, such options are not available via mkgmap or cgsmapper.
FIT to GPX/TCX/CSV converter
![]() |
- FIT ConVerter is a new FREE GUI for Windows.
- It converts the latest FIT files including Strava Segments
- Garmin prefers FIT files to GPX has they can contain additional information like hear rate, temperature,cadence etc
- FIT files are more complex and cannot be read as a txt file.
- More then likely , your device contains a FIT file.
- Check out FIT ConVerter>
GPI File Structure
GPI files contain data about the POIs used by sat-navs, such as speed cameras,petrol stations,supermarkets etc.
These are not text files ;information can be extracted to edit your POIS or even create new ones.
Check out more information >
Garmin's GPI file structure
Garmin uses gpi files in their sat navs to add POIS (important points - petrol stations,hotels,speed cameras etc) to their maps.. These are not text files and require a special compiler such as GPSBabel - however, editors tend to leave out crucial data contained in a gpi file.
For more information on its structure and how to create your own gpi editor
Garmin's gpxx:Subclass
When you examine a Garmins gpx file you often get a mysterious number of bytes after <gpxx Subclass> ie
<gpxx:Subclass>0600D88F0C0249D70B00211600001F001F00</gpxx:Subclass>
The first entry refers to the routing type:
Direct routing starts with
<gpxx:Subclass>000000000000FFFFFFFFFFFFFFFFFFFFFFFF
Implying that the first 12 digits (3 bytes) are grouped and refer to the road type.
The same result appears when you try and route a car on a footpath!
Then if its within <gpxx:rpt :
The first 4 digits are now clear: They always refer to Garmin's road type number, ie in this case 0600 which is residential
This implies that the waypoint is on a residential road
<gpxx:Subclass>1400D88F0C0201001D050D24FD00E114338B</gpxx:Subclass>
Routing starts on a railway line 0x1400 !
It implies that the stream of data contains information about the highway itself,
The last 8 digits (2 little-endian bytes) are related
There is some evidence to suggest that the stream contains distance / length and or angle
Why are some of my elements in a TYP file ignored?
I recently had a case when the transparent hotels (0x 2b01) on my device were always replaced by an icon I used previously.
Answer: the icon for 2b01 was taken from another gmapsupp EVENTHOUGH it had been disabled!
How to keep 'Recent Finds' when updating your gmapsupp
When you update a map and click on a 'Recent Find' more than likely you will get the following message:
'This route does not match the available maps. Cannot follow the route precisely. Do you want to recalculate the route?'
There is no point recalculating as it simply will not work!
Solution:
Check Map ID and FID of your gmapsupp on your device and use the same when creating your new map. It does not matter if your 'map descriptions' or 'map names' are different but do make sure your base Map ID is the same and your FID as well. A gmapsupp contains multiple maps, each with a different ID ; these are generally numbered sequentially.
The FID is the same for all maps and therefore is not located in the map section (RGN etc)
Mapuploader 4.89+ contains a tool which checks the Map IDs and FIDs of all gmapsupps on your device.
Why is my gmapsupp not showing on my device?
There is nothing more frustrating then having just created a gmapsupp which shows perfectly in Mapsource or Basecamp but does not appear on your Garmin device.
Answer: two or more gmapsupps on your device share the same Map ID or FID.
![]() |
Mapuploader 4.89+ contains a tool to check a conflict of mapids and fids of gmapsupps on your device. In our example, gmapsupp8932 has an FID of 8932 but shares a Map Id with gmapsupp89758000 - it will therfore not be listed on your device! |
Description of map product affects some devices
My GPS64 ignores certain TYP file contour settings when the description of the gmapsupp contains 'Topo'
I was very puzzled to see some maps on my device showing grey contour lines, completely ignoring the colours and width set by the TYP file. I then narrowed it down to the description of the map embedded in the gmapsupp - what next !
Garmin devices not showing Chinese/Japanese characters
This has not been reported before, but many new Garmin devices ignore Chinese/Japanese characters embedded in a TYP file
As a result any search for say a 'Chinese restaurant' (中国餐馆) , where the individual name has not been given, results in a blank space and NOT in 中国餐馆.
Unlike Basecamp/Mapsource,these devices do not respond to codepage 932 & 936
Again,unlike Basecamp ,codepage 65001 only works for languages with codepages 1250 -1258
Garmin Geocache ggz files
These are basically a collection of zipped gpx files which can be unzipped using 7+
Each gpx seems to represent a country.
Basecamp won't accept the resulting gpx files and creates an error; however, with some trickery all caches and hints can be displayed.
POI SUBTYPE NUMBERING
For some Garmin POIS the subtypes /&10 define the sub category
Example: Car Repairs is set to 0x2F03 , Amusement 0x2d08
Main Category | 0x2F03 | 0x2D08 | |
sub category | 0x2F13 | 0x2D18 |
NT Extended POIs
Currently, nothing is documented about these pois:
In its basic form an extended poi , as with non NT ones, has 6 bytes: type number, subtype number, 2 bytes for longitude and latitude.
The second byte (subtype) is used as follows:
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
has LBL pointers | unknown | includes label text | |||||
3 bytes | variable 3+bytes | variable + 3 bytes |
Extra Data bytes
5th bit set
if 5th bit is set then 3 LBL bytes follow long and lat bytes.
6th bit
When 6th bit is set and not 7th bit an extra 3 bytes are added followed by a data stream.; the length of this stream is variable and can contain chunks of the same size + and extra byte. If 7th bit is set then the end has been reached. Chunks are clearly separated and may contain a pointers.
The 3 bytes determine the length of the stream and the structure of its contents, ie 43,33,41 using an understood algo define the stream length as 26 bytes.
As an added complication, extra bytes can be added based on the data that follows these three bytes. ie
82 10 37 can signify a length of 8 or 12 bytes
Various combinations of 3 bytes give the same length,implying that these bytes also provide information about the data stream itself.
7th bit
3 bits are added when 7th bit is set.
Although it mostly contains text , other data can be included as well.
If 7th bit is set and the LBL is not set ,then 2 or 3 bytes are used - ie F1 27 - to provide length & other information about the label.
This does not apply to non NT imgs - where the seventh bit when set follows an entirely different algorithm and all labels are stored in the LBL etc.
This block has a definite length calculated using 2nd (+3rd if even) byte(s) - the algorithm is fully understood.
The first byte seems to be some pointer to its length - if the length <16 (?) we get &f0
The second or 3rd byte (if length >255) signifies the length of the stream - the algorithm is understood.
Extra POIs
CN TYP files contain additional label information essential for the correct display of the icon.
Example: Poi type number 11017 (bus stop) might refer to & display an extra POI, ie Ski Lift
example
type & length | label | data stream | |||||||||||
0e | 87 | 4d | 01 | ee | ff | f0 | 0d | B8 | 1D | 00 | a8 | 5a | 07 |
Type 10E07 with label A and length 0d , ie 3
More on extra pois here
For more information on the IMG structure see our 'Exploring IMG Format' pdf
JCV File Structure
For more information check out JCV File structure
BASECAMP LINE DRAWORDER
You can set the draw orders of lines in Basecamp by tweaking route types in a lines style file and line bitmaps in a TYP file - see more
How to turn a line name into capital letters
Basecamp converts words to capital letters with type 0x24 |
![]() |
Mapinstall & TYP files
Latest version of Mapinstall - 4.0.4 - has some very useful features.
However, you may find maps selected and so called installed on your gps may not appear;it does not necessarily create gmapsupps if the imgs are not created by Garmin.
Individual TYP files are ignored as it seems to presume that non topo imgs all have the save typ file!
A safer way is to use mkgmap or Gmaptool to combine your IMG & TYP file .
Line 0 x 10200 - 102FF
It seems these are reserved for a particular reason rendering them transparent ,even in Basecamp!
'This route does not match the available maps' error solved
This annoying error can occur when the 'search properties' do not tally with the map.
When you search for a place name on your gps it stores the location name & coordinates in 'recent finds' . This means that if you replace your gmapsupps covering the same region, and click on one of your 'recent finds' it may detect a different map. This is confusing as the map may be the same. What could be different are the mapnumbers or FID. So...
Quick solution : make sure your initial 8 digit mapnumber and FID are ALWAYS the same.
MDX file structure
Mdx files tell Mapsource / Basecamp which img files to use.
Download mdx file format
Garmin POI Bug When creating a 60x19 POI and 1/3 of the POI from the RIGHT is transparent then the POI cannot be shown - in fact the whole tile cannot be rendered. This applies to truecolor and non truecolor. If the image is reversed or you place a small dot on the right then it works again! Disappearing POI RangeI 0x2200 - 0x2300 SInce my software update Feb 2014 these do not get rendered on my oregon 600,despite showing up on Basecamp! 0x7400-0x741f are not rendered on Oregon |
![]() |