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 its input to its output, like tee:
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.