Use OpenStreetMap to create your own Garmin device

Full of Style

Both Mkgmap and Maperitive have a set of rules that defines how a device displays point and line objects. These rules describe particular details line by line in the same way that the software processes them. If the tool uses a rule, it will process the next object. The entire ensemble of rules is divided up among several files and is referred to as the style.

The styles used in Mkgmap are very special and also different from those in Maperitive. They consist of at least four files in a directory where specialized information is kept. Often there are more of these files. You can select names for the files as desired. Alternatively, Mkgmap accepts compressed directories or all of the information in a single file.

One file by the name of version is a must have. This file describes the version of the description language for the style rather than the version of the style itself. Currently, there are only versions 0 and 1. An empty space should follow the line with the version number.

The optional file info contains information about the style as <key>=<value> . You can indicate multiple line values between the two curved brackets. Possible keywords include version (style version), summary (short description of the style), and description (detailed description of the style).

You can provide options in the options file similar to those in the command line (see Table 2). However, the software will only pay attention to options that refer to the style, such as levels , overview-levels , and extra-used-tags . The latter entry makes it possible to indicate additional tags that you would like to use in the style. Most of the time this will not be required.

The points file contains rules that the software uses to display point objects. Normally these include POIs. They will not appear on the map without the points file. You can enter the corresponding objects as follows:

<key>=<value> [
  <character number> resolution <resolution>]

The combination of key and value indicates the POI that you want to have displayed. The < character number> refers to the internal number of the character you would like to use. <Resolution> refers to the resolution at which it will appear. This is illustrated by the following example:

amenity=
  hospital [0x3002 resolution 14]

The points file normally ends with a clause, which provides that the software will have an icon or text for each object displayed (Listing 1). The inc/address file contains clauses as shown in Listing 2. These clauses make sure that all of the elements appear with the names they have been given. However, this can lead to numerous additional entries in some areas.

[...]
<finalize>
# The finalizer section is executed for each element when a rule with an element type matches
name=* { name ,${name}' }
include ,inc/address';

[...]
mkgmap:phone!=* & phone=* { set mkgmap:phone='${phone}' }
mkgmap:phone!=* & contact:phone=* { add
mkgmap:phone='${contact:phone}' }
mkgmap:is_in!=* & is_in=* { set mkgmap:is_in='${is_in}' }

Similarly, lines defines the display for ways, and polygons defines the display for surfaces. The relations file provides relations for borders, routes, and other things. You will find examples of these file types in the sources [7], documentation [8], and style manual [9] for Mkgmap. Additional examples for style files that have some interesting features can be found on Github under the keyword "mkgmap." You will find a truly interesting version of an OSM map online [10] together with accompanying text that explains how to create the map [11].

Some options such as name-tag-list="name:mkgmap,name:de,int_name,name:en,name" no longer work in the options file of Mkgmap's current version. Instead they only work on the command line. When called, Mkgmap comments on the modified behavior of default options. The online information about about various options [12] is very good, although not entirely current.

Mkgmap style rules follow a predetermined pattern. They consist of two to three parts, which you divide with empty spaces or line breaks. The simplest tests consist of equal or relational operators. There is just a small number of operators that can be used for the tests (see Table 4).

You can connect several tests together with an ampersand (& ). A vertical bar (| ) indicates the logical "or." Tags containing empty spaces are expressed with single or double quotation marks. Functions used to influence the appearance of objects are put between curvy brackets. You can separate the statements using a semicolon (; ). The number of statements is restricted in size. Table 5 shows the most important statements.

Garmin devices have a built-in set of icons for marking POIs and ways. A special version of OSM maps, which has been created by the user Computerteddy [13], makes many features available for older navigational devices. For newer devices, you can define additional icons via a so-called TYP file [14]. For some time now, Mkgmap has been able to automatically create these files from special source texts. As soon as you indicate an appropriate TXT file to create an image file when you are calling the program, Mkgmap will also translate this:

$ mkgmap [...] map.osm <TYP-File>.TXT [...]

The call automatically creates the file <TYP-File>.TYP . If you copy it together with the image files to the navigational device's Garmin/ folder, then the device will use the new icons.

Mkgmap is able to quickly test some of the style features (--check-styles ). Before trying this out, you should first determine via --list-styles which styles the application can find. You can select the desired style using --style-file=<Stil> . If no selection is made, the program will test all of the styles found. Ideally, both commands report on Number of MapFailedExceptions: 0 and Number of ExitExceptions: 0 .

After implementing an OSM file with Mkgmap, you should use QLandkarte to test the file that has just been created, even if only in a limited way. This program does not load the image files directly. Instead, it takes a detour consisting of a TDB file. Mkgmap also creates this file when requested. For example, tdbfile=yes activates this process from the options file. Otherwise you should use the following command:

$ mkgmap --tdbfile gmapsupp.img

Two options support the accurate representation of borders and coastlines. You can get exact information about borders [15] via --bounds=bounds.zip , and about coastlines [16] via --precom-sea=sea.zip . You can mount both options on the command line when you create the image files.

Creating Maps

The process of getting the best raw data will depend in part on your requirements and the available possibilities. In most cases, the prepared Geofabrik [17] raw data will suffice. You can load these either as an XML file with the extension .osm or as a compressed version, normally in the PBF format [18].

Depending on the region, these files can be hundreds of megabytes to several gigabytes in size. You should divide the files in such a way that parts of structures that belong together persist (Listing 3, Line 1). The result will be a file by the name of template.args for which you should specify a family-id and map name (Listing 4). You should use this file later when calling Mkgmap in order to set important default settings.

01 $ java -Xmx1024m -jar splitter.jar --output=pbf --output-dir=splitter --max-nodes=1400000 --mapid=10010001 --poly-file=germany.poly europe.osm.pbf
02 $ java -Xmx2048M -jar mkgmap --name-tag-list="name:de,name,int_name" --tdbfile --style-file=<Style-Datei> --remove-short-arcs --route --net -c template.args *.pbf *.osm *.TYP

# This file can be given to mkgmap using the -c option
# Please edit it first to add a description of each map.
#
# You can set the family id for the map
family-id: 7777
product-id: 1
# Following is a list of map tiles. Add a suitable description
# for each one.
mapname: 63240001
# description: OSM Map
input-file: 63240001.osm.pbf
[...]

Afterwards you should use Mkgmap to compile the divided PBF and OSM files as shown above. If you have source texts for a text file (*.TXT ), then you should add these to the list of the files that have been entered. The family and product IDs need to match with one another so that the Garmin device recognizes the text files as belonging to the maps. This requires that you indicate the data in the --family-ID=<Number> option when compiling the source texts for the TYP files and map.

When creating maps from OSM files that have been split, you will find that the template.args file already exists. You should incorporate this file together with -c template.args into the command line (Listing 3, Line 2).