osm2pgsql Man page

OSM2PGSQL(1) General Commands Manual OSM2PGSQL(1)


osm2pgsql – Openstreetmap data to PostgreSQL converter.


osm2pgsql [options] planet.osm
osm2pgsql [options] planet.osm.{gz,bz2,pbf}
osm2pgsql [options] file1.osm file2.osm file3.osm


This manual page documents briefly the osm2pgsql command.

osm2pgsql imports data from OSM file(s) into a PostgreSQL database
suitable for use by the Mapnik renderer or the Nominatim geocoder.
OSM planet snapshots can be downloaded from http://planet.open‐
streetmap.org/. Partial planet files (“extracts”) for various countries
are available, see http://wiki.openstreetmap.org/wiki/Planet.osm.

Extracts in PBF (ProtoBufBinary) format are also available from

When operating in “slim” mode (and on a database created in “slim”
mode!), osm2pgsql can also process OSM change files (osc files),
thereby bringing an existing database up to date.


These programs follow the usual GNU command line syntax, with long
options starting with two dashes (`-‘). A summary of options is
included below.

Add the OSM file into the database without removing existing

Apply a bounding box filter on the imported data. Must be spec‐
ified as: minlon,minlat,maxlon,maxlat e.g. –bbox

Remove existing data from the database. This is the default if
–append is not specified.

-d|–database name
The name of the PostgreSQL database to connect to (default:

-i|–tablespace-index tablespacename
Store all indices in a separate PostgreSQL tablespace named by
this parameter. This allows one to e.g. store the indices on
faster storage like SSDs.

–tablespace-main-data tablespacename
Store the data tables (non slim) in the given tablespace.

–tablespace-main-index tablespacename
Store the indices of the main tables (non slim) in the given

–tablespace-slim-data tablespacename
Store the slim mode tables in the given tablespace.

–tablespace-slim-index tablespacename
Store the indices of the slim mode tables in the given

Store data in degrees of latitude & longitude.

Store data in proper spherical Mercator (the default).

-E|–proj num
Use projection EPSG:num

Repair bad UTF-8 input data (present in planet dumps prior to
August 2007). Adds about 10% overhead.

-p|–prefix prefix_string
Prefix for table names (default: planet_osm).

-r|–input-reader format
Select input format reader. Available choices are libxml2
(default) for OSM XML format files, o5m for o5m formatted file
and pbf for OSM PBF binary format (may not be available on all

Store temporary data in the database. Without this mode, all
temporary data is stored in RAM and if you do not have enough
the import will not work successfully. With slim mode, you
should be able to import the data even on a system with limited
RAM, although if you do not have enough RAM to cache at least
all of the nodes, the time to import the data will likely be
greatly increased.

Drop the slim mode tables from the database once the import is
complete. This can greatly reduce the size of the database, as
the slim mode tables typically are the same size, if not
slightly bigger than the main tables. It does not, however,
reduce the maximum spike of disk usage during import. It can
furthermore increase the import speed, as no indices need to be
created for the slim mode tables, which (depending on hardware)
can nearly halve import time. Slim mode tables however have to
be persistent if you want to be able to update your database, as
these tables are needed for diff processing.

-S|–style /path/to/style
Location of the osm2pgsql style file. This specifies which tags
from the data get imported into database columns and which tags
get dropped. Defaults to /usr/share/osm2pgsql/default.style.

-C|–cache num
Only for slim mode: Use up to num many MB of RAM for caching
nodes. Giving osm2pgsql sufficient cache to store all imported
nodes typically greatly increases the speed of the import. Each
cached node requires 8 bytes of cache, plus about 10% – 30%
overhead. For a current OSM full planet import with its ~ 3 bil‐
lion nodes, a good value would be 27000 if you have enough RAM.
If you don’t have enough RAM, it is likely beneficial to give
osm2pgsql close to the full available amount of RAM. Defaults to

–cache-strategy strategy
There are a number of different modes in which osm2pgsql can
organize its node cache in RAM. These are optimized for differ‐
ent assumptions of the data and the hardware resources avail‐
able. Currently available strategies are dense, chunked, sparse
and optimized. dense assumes that the node id numbers are
densely packed, i.e. only a few IDs in the range are missing /
deleted. For planet extracts this is usually not the case, mak‐
ing the cache very inefficient and wasteful of RAM. sparse
assumes node IDs in the data are not densely packed, greatly
increasing caching efficiency in these cases. If node IDs are
densely packed, like in the full planet, this strategy has a
higher overhead for indexing the cache. optimized uses both
dense and sparse strategies for different ranges of the ID
space. On a block by block basis it tries to determine if it is
more effective to store the block of IDs in sparse or dense
mode. This is the default and should be typically used.

-U|–username name
Postgresql user name.

Force password prompt.

-H|–host hostname
Database server hostname or socket location.

-P|–port num
Database server port.

-e|–expire-tiles [min_zoom-]max-zoom
Create a tile expiry list.

-o|–expire-output /path/to/expire.list
Output file name for expired tiles list.

Specifies the output back-end or database schema to use. Cur‐
rently osm2pgsql supports pgsql, gazetteer and null. pgsql is
the default output back-end / schema and is optimized for ren‐
dering with Mapnik. gazetteer is a db schema optimized for
geocoding and is used by Nominatim. null does not write any
output and is only useful for testing.

Include attributes for each object in the database. This
includes the username, userid, timestamp and version. Note:
this option also requires additional entries in your style file.

Add tags without column to an additional hstore (key/value) col‐
umn to PostgreSQL tables.

Add all tags to an additional hstore (key/value) column in Post‐
greSQL tables.

-z|–hstore-column key_name
Add an additional hstore (key/value) column containing all tags
that start with the specified string, eg –hstore-column “name:”
will produce an extra hstore column that contains all name:xx

Only keep objects that have a value in one of the columns (nor‐
mal action with –hstore is to keep all objects).

Create indices for the hstore columns during import.

Normally osm2pgsql splits multi-part geometries into separate
database rows per part. A single OSM id can therefore have sev‐
eral rows. With this option, PostgreSQL instead generates
multi-geometry features in the PostgreSQL tables.

Keep coastline data rather than filtering it out. By default
natural=coastline tagged data will be discarded based on the
assumption that post-processed Coastline Checker shape files
will be used.

OpenStreetMap data is defined in terms of nodes, ways and rela‐
tions and not in terms of actual geometric features. Osm2pgsql
therefore tries to build postgis geometries out of this data
representation. However not all ways and relations correspond to
valid postgis geometries (e.g. self intersecting polygons). By
default osm2pgsql tries to automatically fix these geometries
using ST_Buffer(0) around the invalid polygons. With this
option, invalid polygons are instead simply dropped from the

Use postgresql’s unlogged tables for storing data. This requires
PostgreSQL 9.1 or above. Data written to unlogged tables is not
written to PostgreSQL’s write-ahead log, which makes them con‐
siderably faster than ordinary tables. However, they are not
crash-safe: an unlogged table is automatically truncated after a
crash or unclean shutdown.

–number-processes num
Specifies the number of parallel processes used for certain
operations. If disks are fast enough e.g. if you have an SSD,
then this can greatly increase speed of the “going over pending
ways” and “going over pending relations” stages on a multi-core

By default osm2pgsql initiates the index building on all tables
in parallel to increase performance. This can be disadvantages
on slow disks, or if you don’t have enough RAM for PostgreSQL to
perform up to 7 parallel index building processes (e.g. because
maintenance_work_mem is set high).

–flat-nodes /path/to/nodes.cache
The flat-nodes mode is a separate method to store slim mode node
information on disk. Instead of storing this information in the
main PostgreSQL database, this mode creates its own separate
custom database to store the information. As this custom data‐
base has application level knowledge about the data to store and
is not general purpose, it can store the data much more effi‐
ciently. Storing the node information for the full planet
requires about 100GB in PostgreSQL, the same data is stored in
only ~16GB using the flat-nodes mode. This can also increase the
speed of applying diff files. This option activates the
flat-nodes mode and specifies the location of the database file.
It is a single large > 16GB file. This mode is only recommended
for full planet imports as it doesn’t work well with small
extracts. The default is disabled.

Help information.
Add -v to display supported projections.

Verbose output.

Latlong (-l) SRS: 4326 (none)
Spherical Mercator (-m) SRS:900913 +proj=merc +a=6378137 +b=6378137
+lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null
+no_defs +over
EPSG-defined (-E) SRS: +init=epsg:(as given in parameter)


proj, postgres(1).


osm2pgsql was written by Jon Burgess, Artem Pavlenko, and other Open‐
StreetMap project members.

This manual page was written by Andreas Putzo for
the Debian project, and amended by OpenStreetMap authors.

April 06, 2013 OSM2PGSQL(1)

Ils en parlent aussi

How to import OpenStreetMap data into PostgreSQL – skipperkongen
Osmosis, Osm2postgresql & Osm2pgsql – OpenStreetMap-Daten …