We are using 0.86, and per @Pnorman:
<pnorman> I suggest you update to 0.88.1, earlier versions have an off-by-one error which can result in invalid geometries as updates occur and some nodes are in cache and others are in storage, and an invalid geometry can potentially cause an exception in ST_PointOnSurface which you use a lot with vector tile generation
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Upgrade osm2pgsql to 0.90.0 | operations/puppet | production | +61 -20 | |
| explicitely set input reader format in osm2pgsql | operations/puppet | production | +37 -11 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • JGirault | T132971 Implement Kartographer customization to match Wikivoyage existing map | |||
| Declined | Yurik | T137364 Migrate {{geo}} Wikivoyage template to <maplink> (with an icon) | |||
| Resolved | TheDJ | T137656 Migrate WV Template:PoiMap2detail to new maplink | |||
| Resolved | Yurik | T134086 Allow map tags to get geodata from Kartotherian | |||
| Resolved | Yurik | T138192 Implement Graph support of the OSM geo service | |||
| Resolved | Yurik | T134084 Provide osm mapdata service | |||
| Resolved | Yurik | T134085 Implement quick shape retrieval from Postgres based on WikidataID | |||
| Resolved | Gehel | T112423 Update osm2pgsql to 0.90+ |
A fresh import offers some advantages
If you use the existing database, the pending removal migration at https://github.com/openstreetmap/osm2pgsql/blob/master/docs/migrations.md needs to be applied. The z_order changes should also be applied, but this is not essential.
To expand on the invalid geometries, an invalid geometry may cause ST_PointOnSurface to error and stop the query for the layer for the entire tile. Not all invalid geometries will cause this error, and the geometry errors introduced by tend to fall into this class.
0.88.1 is recommended anyways, as it needs a smaller database, using in-memory pending, which also cuts down on disk accesses. As well, deduplication (https://github.com/openstreetmap/osm2pgsql/commit/ed16e9e5bc68f97589b2899eac7c1123b9c40d64) can cut down on disk accesses in updates, potentially significantly for longer update intervals.
This is becoming a bit more pressing now, as we try to expand into alternative OSM db schemas (like being able to query for a geometry based on wikidata ID). @Pnorman, should we persue v0.90.x instead?
Adding a column doesn't require an osm2pgsql upgrade, but without lua transforms you'll have to do all normalization of that column in SQL.
I'm not sure how much normalization you need for Wikidata ID
@Pnorman, we probably don't need as much normalization for WikidataID, but we definitly want to move away from the original default schema and more into the clear-tables direction and other similar efforts, and for that Lua would be needed. My question was mostly if we should pursue 0.88 or 0.90.
If you're going to use the multi backend, 0.90.0 is recommended. If you're using the pgsql backend with Lua transforms, 0.86 and later support that.
Because Debian testing and stable-bpo have moved to 0.90.0, I'd go for that.
For what is worth, I support the jump to 0.90.0 as well, given it is in jessie-backports.
Change 287600 had a related patch set uploaded (by Gehel):
WIP - Upgrade osm2pgsql to 0.90.0
Test in progress on new maps servers. Upgrade was manually applied on the server to validate before pushing this to puppet.
Change 293475 had a related patch set uploaded (by Gehel):
explicitely set input reader format in osm2pgsql