Osm tile
osm_tile.c is a stand-alone C program designed to cut the entire OSM planet file into 1x1 degree .osm XML extracts.
Requirements and Distribution
- osm_tile.c is written for GNU C and requires libz and libexpat.
- osm_tile.c is open-source under the MIT/X11 license.
- osm_tile.c is part of the X-Plane scenery tools code base.
osm_tile.c can split the planet on a 32-bit OS.Memory requirement is now about 5 GB.
For more info on how to get the X-Plane scenery tools code base, see here:
http://wiki.x-plane.com/X-Plane_Scenery_Tools_Development
Once you have the source, the src/OneOffs directory has osm_tile.c
Usage
See osm_tile.c for instructions on compilation and usage.
- -t<relation types> - causes osm_tile to throw out all relations except the comma-separated types in -t (e.g. type=boundary, type=multipolygon could be kept with -tmultipolygon,boundary). This can be useful because relations can often have an absolutely huge bounding box, and osm_tile over-cuts to make sure that everything you _might_ need in a tile is included (see below).
- -g<grid> - sets the size in lat/lon degrees of the cut square. For example, it can be useful to cut the world into 10x10 tiles first, then split the 10x10s into 100 tiles each in parallel.
- -b<box> - sets the export bounds. Every tile within the planet. The default is -180,-90,179,89 to export the entire planet.
- -m<max file descriptors> - sets the maximum number of file descriptors to open at one time. osm_tile has to re-pass over the data when it needs to export more tiles than descriptors; this option is provided for operating systems like OS X that can't arbitrarily increase the file descriptor table from shell.
To cut the planet in a reasonable amount of time on a 32-bit machine, we first cut the planet into 10x10 chunks, and then cut each 10x10 into 100 1x1 chunks in parallel. Since osm_tile is dominated by IO time and OS X can't open 64800 file descriptors at once, this is a win compared to doing a single pass.
In theory, it might be faster to cut the 10x10 chunks into 1x1 chunks using another program that is memory-map based for speed.
Heavy Inclusion
osm_tile does not split ways. Rather it attempts to export at least every node, way, and relation necessary to have in each tile:
- Every node, way and relation that might intersect the tile boundaries.
- Every node and way referenced by an included relation and every node referenced by an included way.
This is a lot more data than you might expect for the tile, particular since axis aligned bounding boxes (AABB) are used for culling. The choice to over-export is based on the idea that a later, spatially aware program will be used to do the actual tile "crop" with robust geometric processing.