1OSM2PGSQL(1)                General Commands Manual               OSM2PGSQL(1)
2
3
4

NAME

6       osm2pgsql - Openstreetmap data to PostgreSQL converter.
7

SYNOPSIS

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

DESCRIPTION

14       This manual page documents briefly the osm2pgsql command.
15
16       osm2pgsql  imports  data  from  OSM  file(s) into a PostgreSQL database
17       suitable for use by the Mapnik renderer or the Nominatim geocoder.
18       OSM  planet  snapshots  can  be  downloaded  from  https://planet.open
19       streetmap.org/. Partial planet files ("extracts") for various countries
20       are available, see https://wiki.openstreetmap.org/wiki/Planet.osm.
21
22       Extracts  in  PBF  (ProtoBufBinary)  format  are  also  available  from
23       https://download.geofabrik.de/osm/.
24
25       When  operating  in  "slim"  mode  (and on a database created in "slim"
26       mode!), osm2pgsql can  also  process  OSM  change  files  (osc  files),
27       thereby bringing an existing database up to date.
28

OPTIONS

30       These  programs  follow  the  usual  GNU command line syntax, with long
31       options starting with two  dashes  (`-').   A  summary  of  options  is
32       included below.
33
34       -a|--append
35              Add  the  OSM  file  into the database without removing existing
36              data.
37
38       -b|--bbox
39              Apply a bounding box filter on the imported data.  Must be spec‐
40              ified     as:     minlon,minlat,maxlon,maxlat     e.g.    --bbox
41              -0.5,51.25,0.5,51.75
42
43       -c|--create
44              Remove existing data from the database. This is the  default  if
45              --append is not specified.
46
47       -d|--database name
48              The name of the PostgreSQL database to connect to.
49
50       -i|--tablespace-index tablespacename
51              Store  all  indices in a separate PostgreSQL tablespace named by
52              this parameter.  This allows one to e.g. store  the  indices  on
53              faster storage like SSDs.
54
55        --tablespace-main-data tablespacename
56              Store the data tables (non slim) in the given tablespace.
57
58        --tablespace-main-index tablespacename
59              Store  the  indices  of  the main tables (non slim) in the given
60              tablespace.
61
62        --tablespace-slim-data tablespacename
63              Store the slim mode tables in the given tablespace.
64
65        --tablespace-slim-index tablespacename
66              Store  the  indices  of  the  slim  mode  tables  in  the  given
67              tablespace.
68
69       -l|--latlong
70              Store data in degrees of latitude & longitude.
71
72       -m|--merc
73              Store data in proper spherical Mercator (the default).
74
75       -E|--proj num
76              Use projection EPSG:num
77
78       -p|--prefix prefix_string
79              Prefix for table names (default: planet_osm).
80
81       -r|--input-reader format
82              Select  format  of  the  input  file. Available choices are auto
83              (default) for autodetecting the format, xml for OSM  XML  format
84              files,  o5m  for  o5m formatted files and pbf for OSM PBF binary
85              format.
86
87       -s|--slim
88              Store temporary data in the database.  Without  this  mode,  all
89              temporary  data  is  stored in RAM and if you do not have enough
90              the import will not  work  successfully.  With  slim  mode,  you
91              should  be able to import the data even on a system with limited
92              RAM, although if you do not have enough RAM to  cache  at  least
93              all  of  the  nodes,  the time to import the data will likely be
94              greatly increased.
95
96         --drop
97              Drop the slim mode tables from the database once the  import  is
98              complete.  This  can greatly reduce the size of the database, as
99              the slim mode  tables  typically  are  the  same  size,  if  not
100              slightly  bigger  than  the  main  tables. It does not, however,
101              reduce the maximum spike of disk usage  during  import.  It  can
102              furthermore  increase the import speed, as no indices need to be
103              created for the slim mode tables, which (depending on  hardware)
104              can  nearly  halve import time. Slim mode tables however have to
105              be persistent if you want to be able to update your database, as
106              these tables are needed for diff processing.
107
108       -S|--style /path/to/style
109              Location  of the osm2pgsql style file. This specifies which tags
110              from the data get imported into database columns and which  tags
111              get dropped. Defaults to /usr/share/osm2pgsql/default.style.
112
113       -C|--cache num
114              Only  for  slim  mode:  Use up to num many MB of RAM for caching
115              nodes. Giving osm2pgsql sufficient cache to store  all  imported
116              nodes  typically greatly increases the speed of the import. Each
117              cached node requires 8 bytes of cache,  plus  about  10%  -  30%
118              overhead. For a current OSM full planet import with its ~ 3 bil‐
119              lion nodes, a good value would be 27000 if you have enough  RAM.
120              If  you  don't  have enough RAM, it is likely beneficial to give
121              osm2pgsql close to the full available amount of RAM. Defaults to
122              800.
123
124         --cache-strategy strategy
125              There  are  a  number  of different modes in which osm2pgsql can
126              organize its node cache in RAM. These are optimized for  differ‐
127              ent  assumptions  of  the data and the hardware resources avail‐
128              able. Currently available strategies are dense, chunked,  sparse
129              and  optimized.  dense  assumes  that  the  node  id numbers are
130              densely packed, i.e. only a few IDs in the range are  missing  /
131              deleted.  For planet extracts this is usually not the case, mak‐
132              ing the cache very  inefficient  and  wasteful  of  RAM.  sparse
133              assumes  node  IDs  in  the data are not densely packed, greatly
134              increasing caching efficiency in these cases.  If node  IDs  are
135              densely  packed,  like  in  the full planet, this strategy has a
136              higher overhead for indexing  the  cache.  optimized  uses  both
137              dense  and  sparse  strategies  for  different  ranges of the ID
138              space. On a block by block basis it tries to determine if it  is
139              more  effective  to  store  the  block of IDs in sparse or dense
140              mode. This is the default and should be typically used.
141
142       -U|--username name
143              Postgresql user name.
144
145       -W|--password
146              Force password prompt.
147
148       -H|--host hostname
149              Database server hostname or socket location.
150
151       -P|--port num
152              Database server port.
153
154       -e|--expire-tiles [min_zoom-]max-zoom
155              Create a tile expiry list.
156
157       -o|--expire-output /path/to/expire.list
158              Output file name for expired tiles list.
159
160       -O|--output
161              Specifies the output back-end or database schema  to  use.  Cur‐
162              rently  osm2pgsql  supports  pgsql, gazetteer and null. pgsql is
163              the default output back-end / schema and is optimized  for  ren‐
164              dering  with  Mapnik.   gazetteer  is  a db schema optimized for
165              geocoding and is used by Nominatim.  null  does  not  write  any
166              output  and is only useful for testing or with --slim for creat‐
167              ing slim tables.
168
169       -x|--extra-attributes
170              Include attributes  for  each  object  in  the  database.   This
171              includes  the  username,  userid,  timestamp and version.  Note:
172              this option also requires additional entries in your style file.
173
174       -k|--hstore
175              Add tags without column to an additional hstore (key/value) col‐
176              umn to PostgreSQL tables.
177
178       -j|--hstore-all
179              Add all tags to an additional hstore (key/value) column in Post‐
180              greSQL tables.
181
182       -z|--hstore-column key_name
183              Add an additional hstore (key/value) column containing all  tags
184              that start with the specified string, eg --hstore-column "name:"
185              will produce an extra hstore column that  contains  all  name:xx
186              tags
187
188         --hstore-match-only
189              Only  keep objects that have a value in one of the columns (nor‐
190              mal action with --hstore is to keep all objects).
191
192         --hstore-add-index
193              Create indices for the hstore columns during import.
194
195       -G|--multi-geometry
196              Normally osm2pgsql splits multi-part  geometries  into  separate
197              database rows per part.  A single OSM id can therefore have sev‐
198              eral  rows.  With  this  option,  PostgreSQL  instead  generates
199              multi-geometry features in the PostgreSQL tables.
200
201       -K|--keep-coastlines
202              Keep  coastline  data  rather than filtering it out.  By default
203              natural=coastline tagged data will be  discarded  based  on  the
204              assumption  that  post-processed  Coastline  Checker shape files
205              will be used.
206
207         --exclude-invalid-polygon
208              OpenStreetMap data is defined in terms of nodes, ways and  rela‐
209              tions  and  not in terms of actual geometric features. Osm2pgsql
210              therefore tries to build postgis geometries  out  of  this  data
211              representation. However not all ways and relations correspond to
212              valid PostGIS geometries (e.g. self intersecting  polygons).  By
213              default  osm2pgsql tries to fix these geometries using buffer(0)
214              around the invalid polygons. With this option, invalid  polygons
215              are  instead simply dropped from the database. Even without this
216              option, all polygons in the database should be valid.
217
218         --unlogged
219              Use postgresql's unlogged tables for storing data. This requires
220              PostgreSQL  9.1 or above. Data written to unlogged tables is not
221              written to PostgreSQL's write-ahead log, which makes  them  con‐
222              siderably  faster  than  ordinary  tables. However, they are not
223              crash-safe: an unlogged table is automatically truncated after a
224              crash or unclean shutdown.
225
226         --number-processes num
227              Specifies  the  number  of  parallel  processes used for certain
228              operations. If disks are fast enough e.g. if you  have  an  SSD,
229              then  this can greatly increase speed of the "going over pending
230              ways" and "going over pending relations" stages on a  multi-core
231              server.
232
233       -I|--disable-parallel-indexing
234              By  default osm2pgsql initiates the index building on all tables
235              in parallel to increase performance. This can  be  disadvantages
236              on slow disks, or if you don't have enough RAM for PostgreSQL to
237              perform up to 7 parallel index building processes (e.g.  because
238              maintenance_work_mem is set high).
239
240         --flat-nodes /path/to/nodes.cache
241              The flat-nodes mode is a separate method to store slim mode node
242              information on disk.  Instead of storing this information in the
243              main  PostgreSQL  database,  this  mode creates its own separate
244              custom database to store the information. As this  custom  data‐
245              base has application level knowledge about the data to store and
246              is not general purpose, it can store the data  much  more  effi‐
247              ciently.  Storing  the  node  information  for  the  full planet
248              requires about 100GB in PostgreSQL, the same data is  stored  in
249              only ~16GB using the flat-nodes mode. This can also increase the
250              speed  of  applying  diff  files.  This  option  activates   the
251              flat-nodes mode and specifies the location of the database file.
252              It is a single large > 16GB file. This mode is only  recommended
253              for  full  planet  imports  as  it  doesn't work well with small
254              imports. The default is disabled.
255
256       -h|--help
257              Help information.
258              Add -v to display supported projections.
259
260       -v|--verbose
261              Verbose output.
262

SUPPORTED PROJECTIONS

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

SEE ALSO

271       proj(1), postgres(1).
272

AUTHOR

274       osm2pgsql was written by Jon Burgess, Artem Pavlenko, and  other  Open‐
275       StreetMap project members.
276
277       This  manual  page was written by Andreas Putzo <andreas@putzo.net> for
278       the Debian project, and amended by OpenStreetMap authors.
279
280
281
282
283
284                               February 5, 2017                   OSM2PGSQL(1)
Impressum