Osm2pgsql Release

Today Sarah released the new osm2pgsql version 1.3.0 (release notes). After working on this for more than half a year now it is great to see the new version out there.

The main new feature in this release is the new “flex” output. I have written about that before. Osm2pgql has several output modules for different database formats. This new output module allows the user to define in detail which database tables should be created with which columns and which OSM data should end up in which table. This is done by writing Lua scripts which gives a lot of flexibility to the user and makes osm2pgsql usable for many more use cases than before. We have provided several example config files with extensive comments to help you use this new power. (The Lua scripts are not compatible to the Lua scripts used in the old pgsql output, we needed to change the API to allow for the greater flexibility.)

We have also spent many hours fiddling with the build scripts and refactoring the internals of osm2pgsql. A lot of code was cleaned up, modernized, made more robust, and sometimes removed. The dependency management, the part of the code which tracks which changes in the OSM data trigger which changes in the outputs, was totally reorganized making in much cleaner and removing the last remnants of code written to support “old style” multipolygons which were deprecated years ago.

This allowed us to add a new feature (only available in the flex output): Using two-stage processing it is now possible to get information from relations to their members, allowing, for instance, to render tags from bicycle route relations on their member ways. I am excited to see how users will use this feature to improve their maps.

Most of the development work in this release was done by me. This was only possible due to the support by Thunderforest and Geofabrik, both heavy users of osm2pgsql who each payed for part of this work. Thanks!

There is a lot of stuff that didn’t make it into this release. At some point you have to stop and do the release, even if it is tempting to “just” get this tiny improvement in and this other one, and that one over there. But I plan to keep working on this and there is always a next release…

The flex backend is currently still marked as experimental, because it is new and we want to collect feedback from the community before finalizing the API. But it already works well. Give it a try!