Gosmore PAK file

Building your own PAK file

Alternatively, build your own pak file. Then the "make install" step is not required:

bzcat ...osm.bz2 | ./gosmore rebuild 

This last step takes typically 5 hours for a current planet file on a dual core 64 bit machine with 2GB RAM and requires close to 20GB of harddisk space, but using country extracts is strongly advised.

Auto Pak file

During "make install", the default.pak file will have been placed in your resource directory (usually /usr/share/gosmore). Then you must make sure that the current directory does not contain gosmore.pak. Use the 'Update Map' function to download the relevant bounding box. As you browse the map, the relevant map will be swapped in.

Or manually download them from prebuilt maps, unzip them and rename gosmore.pak to NNNNNNNNNNNNNNNN.pak.

Note that, due to space restrictions, the prebuilt maps may not include buildings.

The Compile and Rebuild Guide


This description will help you understand the Gosmore rebuild process. It may not always be up to date.


For Relation:multipolygon support (amongst other things), Gosmore needs to know which ways are members of which relations. The relation data is at the end of an OSM file, so a first pass (sortRelations) is needed to create a relation table (relations.tbl). Fortunately we can create a table when we split the planet and that table can then be used for each extract. To make it easier, sortRelations will pass it's input to it's output, like tee e.g.

bzcat planet...osm.bz2 | gosmore sortRelations | osmosis ...
bzcat extract1...osm.bz2 | gosmore rebuild
bzcat extract2...osm.bz2 | gosmore rebuild


bzcat extract.osm.bz2 | gosmore sortRelations >/dev/null
bzcat extract.osm.bz2 | gosmore rebuild

The relations table for the complete planet is 1 GB but is very efficiently handled during the rebuild pass.


Instead of / in addition to country or state based extracts, Gosmore now uses 167 overlapping rectangular bounding box (bboxes). Choosing them was quite difficult, but hopefully that will only be necessary once a year. The bboxes are extracted from the planet with bboxSplit, but if you have enough RAM you can also use osmosis.

Adding low-zoom data

For compound searches (street, city) to work across bboxes, we need to include all cities in all pak files.

So national boundaries, large cities and country names are provided in OSM-XML format. It can be added to an extract on-the-fly:

(bzcat extract.osm.bz2 | egrep -v '</osm'
bzcat bounds.osm.bz2 | egrep -v '<?xml|<osm|</osm'
bzcat lowres.osm.bz2
egrep -v '?xml|<osmCha' countries.osm | sed -e 's|/osmChange|/osm|') |
gosmore rebuild

File sizes / Styles

We are trying to keep pak files below the 400MB limit of Windows Mobile. New imports make this difficult because they often set tags of little importance and they don't adhere to and conventions. Some of the filtering is done inside Osm2Gosmore () function.

Files sizes can also be reduced by removing things from the elemstyles file: It associates a style with a number of key:value pairs. A style consists of a line colour, area colour, an icon amongst other things. If no icon is specified, then gosmore will not match nodes to that style. For example, not icon has been specified for highway=footway because many nodes has been tagged this way and it provides no real information. Note that the file is no longer compatible with JOSM's mappaint component.

At the beginning of the elemstyles file entries for each Gosmore option and each command and their icons.


Most icons come from mappaint. The mkicons script will pack them into a single image and create a CSV file specifying the location and size of the icon. These values are then stored in the pak file during rebuild time.