3. Maps

Navit can use a variety of maps from a number of sources. This includes free and commercial material, that can be read using different map drivers which allow different sets of functionality. The visual design of maps can be adjusted with a layout.

The following matrix shows at-a-glance the features that each supported map type has.














Garmin maps




Marco Polo Grosser Reiseplaner


> 4y

Routeplaner Europa 2007


> 4y

Map + Route


> 4y

3.1. OpenStreetMap

OpenStreetMap <http://www.openstreetmap.org/> is a free editable map of the whole world. It is made by people like you. OpenStreetMap allows you to view, edit and use geographical data in a collaborative way from anywhere on Earth. Maps from OpenStreetMap can be used in Navit.

3.1.1. Quick Start

  • Go to Navit Planet Extractor

  • Zoom in and select the area that you are interested in. Use the ‘Map Controls’ on the right to switch between ‘Navigation’ and ‘Select’ modes. or use

  • preselected areas:

  • Hit “Get Map!”

  • Move the downloaded map to the directory of your choice, and add it to the active the mapset (see [[Configuration]]) in navit.xml with a line similar to the following:

 <map type="binfile" enabled="yes" data="/path/to/your/map/osm_bbox.bin" />

3.1.2. Add OSM map to your mapset

Move the downloaded map to the directory of your choice, and add it to the active mapset (see [[Configuration]]) in navit.xml with a line similar to the following:

 <map type="binfile" enabled="yes" data="/path/to/your/map/my_downloaded_map.bin" />

3.1.3. Topographic Maps

Navit will display elevation/height lines but the required data is not included in most OSM derived maps.

Navit compatible maps with height lines can be created by feeding the output of Phyghtmap <http://wiki.openstreetmap.org/wiki/Phyghtmap> to Navit’s maptool. Alternatively the SRTM data can be downloaded in osm.xml format http://geoweb.hft-stuttgart.de/SRTM/srtm_as_osm/, avoiding the Phygtmap step. The information can be either merged with OSM derived maps or used in a separate layer.

Many Garmin type maps such as http://www.wanderreitkarte.de/garmin_de.php also have the height lines information but routing will not work with them.

3.1.4. Processing OSM Maps yourself

You can create your own Navit binfiles from OSM data very easily using [[maptool]], the conversion program which installs alongside Navit. ‘’maptool’’ can process both OpenStreetMap XML Data files (.osm files) and OpenStreetMap Protobuf Data files (.pbf files) Follow these steps to process your own maps. Download your own OSM data

OSM data can be downloaded from a variety of sources. OpenStreetMap XML Data files are regular textfiles, easily editable in any text editor. OpenStreetMap Protobuf Data files are binary files, which take up less space (so are quicker to download and process) but are not editable.

  • OpenStreetMap XML Data

  • ‘’’OpenStreetMap Protobuf Data’’’ * [http://download.geofabrik.de/osm/ Geofabrik] provides pre-processed OpenStreetMap Protobuf Data files of almost all countries, and all continents. Convert OSM data to Navit binfile

The following examples assume that you have installed Navit system-wide. If this is not the case, you will need to provide an absolute path to the ‘’maptool’’ executable, which is in the navit/maptool folder.

Please also note, that maptool uses country multipolygon relations. So it’s a good idea to include the whole country boundary to your dataset. You can use the josm editor to download the country boundary relation and save it as osm file. Then this file can be concatenated with your sub-country level excerpt. From .osm
cat my_OSM_map.osm | maptool my_Navit_map.bin


maptool -i my_OSM_map.osm my_Navit_map.bin

Or for multiple OSM data files use the <tt>–dedupe-ways</tt> option to avoid duplication of way data if a way occurs multiple times in the OSM maps.

cat my_OSM_map1.osm my_OSM_map2.osm my_OSM_map3.osm | maptool --dedupe-ways my_Navit_map.bin From .bz2
bzcat my_OSM_map.osm.bz2 | maptool my_Navit_map.bin From .pbf
maptool --protobuf -i my_OSM_map.osm.pbf my_Navit_map.bin

3.1.5. Processing the whole Planet

The OpenStreetMap wiki [http://wiki.openstreetmap.org/index.php/Planet.osm Planet.osm] page lists mirrors where Planet.osm can be downloaded. There are also downloads of smaller areas such as the UK and parts of Europe. These smaller excerpts are a lot quicker to download and process.

In case you want the whole planet.osm (24GB in December 2012), it is even possible to process planet.osm. It will take about 7 hours , requires > 1GB of main memory and about 30 GB disk space for result and temp files - planet.bin is currently (as of December 2012) 9.6GB:

bzcat planet.osm.bz2 | maptool -6 my_Navit_map.bin

Please note -6 option (long name –64bit) used above. It should be used always if output bin file grows above 4GB, or generated file will not work at all. Using that option on smaller files slightly increases their size and makes them unreadable by some unzip versions.

3.1.6. Tips

  • To enable a map you have downloaded refer [[OpenStreetMap#Adding_an_OSM_map_to_your_mapset| adding OSM map to navit.xml]]

  • If you don’t see any map data in Navit (assuming your map is properly specified in navit.xml) using the Internal GUI click anywhere on the screen to bring up the menu. Click on “Actions” and then “Town”. Type in the name of a town that should be within your map data. Select your town from the list that appears. This will bring up a sub-menu where you can click “View On Map”. Note that if you have a GPS receiver you can also just wait till you get a satellite lock.

  • To avoid changing navit.xml if you update your maps and the maps have different file names use the wildcard (*.bin) in your navit.xml file. For example:

<map type="binfile" enabled="yes" data="/media/mmc2/maps/*.bin"/>

3.2. Binfile

Navit has its own map format, called binfile format. It’s a binary format, optimized for use with Navit (rendering, search, routing on embedded devices).

3.2.1. Dividing the world into tiles

The map coordinates of binfile are in meters, measured from equator and null meridian, with a merkator projection. The limit of this world is about 20000 km in earch direction from this null point. This doesn’t cover polar regions, but it’s ok for now.

So, the world gives a 40000x40000km rectangle (tile). This rectangle is divided into 4 equally-sized sub-rectangles (tiles) called a,b,c and d counter clockwise …

  • a is top right

  • b top left

  • c bottom right

  • d bottom left

Each of the sub-rectangles (tiles) is then further subdivided, so a rectangle “aa” is top right in “a”

This is continued further up to 14 levels (but the number of levels might be variable). So in the end you get many tiles which are containing objects which are within this tile… And the tiles are also containing references to tiles which are within them.

A Navit binfile is actually a ZIP file; each tile is a member file in a zip file. So to extract an area of this file, you just read the zip file sequentially.

If you extract a small binfile using a zip tool, you will see member files adbdbbbbadcacd, adbdbbbbadcacd, … . Each file contains the data for one tile.

3.2.2. Projection

The coordinates are projected using a modified “Google” (i.e. EPSG900913) projection. Navit assumes an earth radius of 6371000m rather than the WGS84 value of 6378137m. Thus, for navit, the circumference of the earth is (2 x 20015087m).

3.2.3. Tile data format

A tile itself is a dynamic data structure.

As declared in navit/map/binfile/binfile.c, a tile is represented in memory by a struct :

struct tile {
  int *start;           /* Memory address of the whole data structure */
  int *end;             /* Memory address of first memory address not belonging to tile
                         * thus tile->end - tile->start represents the size of the tile
                         * in multiples of 4 Bytes */
  int *pos;             /* current position inside the tile */
  int *pos_coord_start; /* pointer to the first element inside the tile that is a
                         * coordinate. That is the first position after the header of a
                         * tile. The header holds 3 entries each 32bit wide integers.
                         * header[0] holds the size of the whole data-structure.
                         * header[1] holds the type of the item
                         * header[2] holds the size of the coordinates in the tile */
  int *pos_coord;       /* current position inside the coordinates region within the tile */
  int *pos_attr_start;  /* pointer to the first attr //TODO explain attr format// data
                         * structure inside the tile's memory region */
  int *pos_attr;        /* current position inside the attr region */
  int *pos_next;        /* link to the next tile */
  int zipfile_num;

3.2.4. Content

Inside the binfile, each tile file contains a list of items. Each item is stored like this (everything is 4 bytes wide and always aligned):

  int: Length of the item (not including this length field) in integers
  int: Type of the item (from item_def.h)
  int: Length of the coordinate data which follows in integers
    int: pairs of coordinates with consisting of 2 integers each
  } 0..n
    int: length of the attribute (not including this length field) in integers
    int: Type of attribute (from attr_def.h)
      int: Attribute data, depending on attribute type
    } 0..n
  } 0..n

3.2.5. Extracting a specific area

You can calculate the bounding box of the current tile.

Then there are two possibilities:

  • The tile overlaps with the area you are interested in: Then simply copy the whole file data, including its header to the output, and add an entry to the directory which will be written later

  • The tile doesn’t overlap: Then don’t drop that file, but instead write a file with size 0 and the same name to the output (I will explain later why this is needed), and add an entry to the directory

At some point you will have reached the end of the zip files, then you have to write the zip directory and the “end of directory” marker.

This will be very fast (you don’t have to look into the zip files, which would mean decompressing and compressing them again) but has some disadvantages:

  • You will have many empty files in it which are not really necessary. This is needed because the reference to sub-tiles are by number, and not by name (would be slow), and so the position of a tile within the zip file is not allowed to change

  • You get some data you didn’t want to have: this is because a tile which overlaps with your area of course doesn’t contain only data from your wanted area, but from the area where it is located

3.2.6. How an object is placed in a tile

An object is placed inside of a tile using the following approach

  • If the object can fit into one of the 4 top tiles it is placed in that tile

  • The 4 sub-tiles are then checked to see if the object will fit inside of any of the four tiles that are contained inside of the sub-tile. If so, it is moved down a tile. This step is repeated until the object spans 2 or more tiles (or the lowest tile level is reached)

  • If the object can’t fit inside of any of the 4 top sub-tiles it is placed inside of the top-most tile

An object ‘fits’ inside of a tile if the coordinates of the object (min lat, min lon, max lat, max lon) lie inside of the coordinates of the tile (tile_min_lat, tile_min_lon, tile_max_lat, tile_max_lon)

Any object that cross the equator or the poles is placed in the top-most tile because it can not fit inside of any sub-tile.

Some important objects are placed into upper level tiles despite of their length to be easier reachable for routing or display purposes. This is done by specifying maximum tile name length for them in item_order_by_type() function in navit/maptool/misc.c.

BTW, “order” (zoom level) values used to query map and referred in <itemgra> and route_depth are equal to (tile_name_length-4).