first some context... I have a custom projection, here is the projection string:

<5514> +proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813972222222 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +towgs84=542.5,89.2,456.9,5.517,2.275,5.516,6.96 +units=m +no_defs <>

And I use this projection to import OSM maps into my PostGIS DB. I get my map files at geofabrik.de. I use osm2pgsql for the import.

The way it used to work with osm2pgsql version 0.92.0 (don't know when exactly they changed it) with custom projections was, that you could edit a text file located at /usr/share/proj/epsg and there you'd input the projection string and everything would work.

Now I tried using the same procedure with osm2pgsql 1.5.2 and proj 8.2 (also tried with proj 8.1.1) and it simply doesn't work. If you go ahead and create /usr/share/proj/epsg and input the proj string same way as before and try and run osm2pgsql, you will get the following error:

root@45eed82f97c6:/# osm2pgsql --slim --number-processes 5 --proj 5514 -U gisuser -H <some-db-host> -P <some-port> -d <db-name> -C 30000 <somepath.osm.pbf>

2022-04-06 11:35:31  osm2pgsql version 1.5.2 (1.5.2-2-ga55eacda)
2022-04-06 11:35:31  ERROR: creation of CRS failed: no arguments in initialization list

Even if you just create an empty file at /usr/share/proj/epsg, you will get the same error. I have tried putting in the projection in different formats (WKT2) but to no avail.

The thing is... this SHOULD work according to the PROJ docs (https://proj.org/resource_files.html?highlight=init%20files#init-files), but... it just doesn't.

The way I tested is that I spun up a fresh, clean debian docker, installed osm2pgsql via apt install and then tried the procedure described above. Doesn't work. At some point, proj started storing the projections in sqlite3 proj.db, and I don't know how to edit it to match the projection string I have.

Any ideas? Will be happy for any pointers.

Right now I had to go back to osm2pgsql version 0.92.0 and that still works, but... there has to be a better solution :).

1 Answer 1


Your problem might be caused by updates to the proj library instead of an update to the osm2pgsql software itself.

Update Looking at a system that is still running Proj v6.3, EPSG:5514 is defined by default, as shown below. Perhaps check that this projection is still defined in your setup with the later version of proj. It would be odd that a projection would be removed and it is not marked as deprecated in the proj 6.3.1 database. If it is still there, that might suggest that osm2pgsql is not looking up the projection information the way newer versions of Proj expect.

Specifying EPSG:5514, as you show in your question, works properly with osm2pgsql v1.2.1 (installed via ubuntu package) and Proj 6.3.1 without having to define the projection first. So newer osm2pgsql with older Proj seems fine.

Here is an osm2pgsql issue, closed late 2020, dealing with API changes in Proj >= v7.2.

$ osm2pgsql --version
osm2pgsql version 1.2.1 (64 bit id space)

$ proj --version
Rel. 6.3.1, February 10th, 2020

$ projinfo EPSG:5514
PROJ.4 string:
+proj=krovak +lat_0=49.5 +lon_0=24.8333333333333 +alpha=30.2881397527778 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +towgs84=589,76,480,0,0,0,0 +units=m +no_defs +type=crs

WKT2:2019 string:
PROJCRS["S-JTSK / Krovak East North",
        DATUM["System of the Unified Trigonometrical Cadastral Network",
            ELLIPSOID["Bessel 1841",6377397.155,299.1528128,
    CONVERSION["Krovak East North (Greenwich)",
        METHOD["Krovak (North Orientated)",
        PARAMETER["Latitude of projection centre",49.5,
        PARAMETER["Longitude of origin",24.8333333333333,
        PARAMETER["Co-latitude of cone axis",30.2881397527778,
        PARAMETER["Latitude of pseudo standard parallel",78.5,
        PARAMETER["Scale factor on pseudo standard parallel",0.9999,
        PARAMETER["False easting",0,
        PARAMETER["False northing",0,
        AXIS["easting (X)",east,
        AXIS["northing (Y)",north,
        AREA["Europe - Czechoslovakia"],

Probably a secondary issue: Proj changed how it handles resource files in v7.0 so you might need to adjust how you specify your custom projection, although as written above I don't think you should even need to specify this projection. See Adding custom projection in GDAL 3.

For a Debian system, I think your custom projection information, by default, would go in "${XDG_DATA_HOME}/proj if XDG_DATA_HOME is defined. Else ${HOME}/.local/share/proj" (from https://proj.org/resource_files.html).

  • Hey, thanks for the answer... unfortunately, if you look closely at the proj string I posted and compare it with the proj string of 5514, you will see that it's different. So I basically need to convince PROJ to accept my 5514 proj string instead of the default one. And it has to be 5514, because otherwise PostGIS won't know the projection and mess up in different ways. Also for the different paths... that's an interesting thought, however given that osm2pgsql errors out IMMEDIATELY if I add an empty "epsg" file to /usr/share/proj, I'd say I'm at the correct folder :).
    – Pabos
    Commented Apr 11, 2022 at 16:02
  • Okay, I do see the differences in the projection string. Based on the behaviour you are seeing compared to my experiment with osm2pgsql v1.2.1 and Proj 6.3.1, I suggest you try to do the import using a custom projection on the older version of Proj. If you can get osm2pgsql / Proj to accept a custom projection, then you can define that same custom projection for PostGIS. You should be able to use any available custom projection code: gis.stackexchange.com/questions/316252/…. Note that PostGIS uses the projection definition in its spatial_ref_sys table anyway.
    – hgb
    Commented Apr 11, 2022 at 16:17
  • Yup, thanks, that's how I've solved it thus far... but umm, the question really was "how to do it in the new version", so please understand that I won't accept this as the answer... thank you :)
    – Pabos
    Commented Apr 13, 2022 at 7:12
  • That's fine. I'm running off apt packages so osm2pgsql 1.2.1 is the newest I've got. My guess is that the real fix requires more work by osm2pgsql to deal with the Proj API changes >= 7.2. You might consider opening a new issue or reopening the issue I link to above.
    – hgb
    Commented Apr 13, 2022 at 13:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.