Regional osm2pgsql updated minutely as an alternative to Overpass.

Short version:

Recently, I wrote a script that could help with OSM DB data replication using osm2pgsql by filtering .osc files with a specific .poly. It doesn’t limit to a specific continent or country, it can be used with any custom PBF (e.g. a specific city), so it doesn’t need to use .fr replication, it uses planet.osm.org directly (which also could be changed).

It’s inspired by the trim_osc.py script by Zverik, but rewritten from scratch with tests, because the script unfortunately didn’t work for me (maybe I did something wrong).

It’s not a very typical thing, so I’m not sure if it will be useful for anyone, but if someone would like try to self-host a regional OSM DB with replication, I recommend to at least checking it.

More details in the repo: osm-replication-osc-poly-filter

Longer version:

A few months ago, I was looking for an alternative for public Overpass instances (due to overloaded servers) for my projects.

I read SomeoneElse’s diary about self-hosting Overpass instance. But it seems over-complicated to me. I also read many times that there are random issues with reliability and it’s time-consuming to maintain it (not sure how true it is).

I decided that I want to switch to something else for my projects. Something more low-level with greater control of data and more likely self-hosted to avoid such problems. Instead of OverpassQL. I switched to SQL with a PostGIS DB. There are no a lot of choices here, so I chose osm2pgsql.

Osm2pgsql is quite advanced tool, which I really recommend at least reading about it – it may require some time to learn it, but it’s worth to seeing some features like --output=flex, which allows to defining custom table schemas in Lua scripts with tags/geometry columns which works when importing and appending (replicating) data. It can be adjusted and optimized per project.

… See full entry