[Tile-serving] New release of osm2pgsql?

[Kai Krueger]

Hello everyone,

as just mentioned in a previous email, I would like to try and establish 
a process of stable releases for the tile-rendering tool chain.

I would suggest to kick of the process with osm2pgsql. As far as I am 
aware it is currently fairly stable at the moment so it seems like a 
good time to tag one of the snapshots as a new stable release.

Most of the current open issues / tickets seem to be more feature 
requests than bug reports.

Perhaps the biggest issues I am currently aware of are

trac ticket #4525: Polygons not rendering after removing them from 
relation. If a closed way was part of a multi-ploygon relation, that 
would render in its own right as a polygon, then this polygon will not 
be present in the rendering tables of the database after removing the 
multi-polygon. The diff import process deletes the polygon associated 
with the relation, but does not reprocess the individual ways to see if 
they should now create geometry objects in the database that were 
previously removed to prevent duplicates with the multi-polygon 
geometries. This bug is triggered occasionally in "real world" 
situations and has caused issues on the main osm.org map (and presumably 
on other maps using diff importing with osm2pgsql). There is a patch 
attached to the ticket, but as it might have substantial effects on diff 
processing speed, it hasn't yet been committed.

trac ticket #4553: The number of lines and polygons imported into a 
database differ depending on using the latlon projection or the web 
Mercator projection. I don't know under what conditions this happens, or 
if it has any practical implications. Potentially it is an issue with 
how long ways get split and how the ways to polygon algorithm works 
trying to put together multiple ways into a polygon.  This has however 
prevented the automated test suit for osm2pgsql to complete correctly

The way splitting algorithm in osm2pgsql, that is supposed to prevent 
overly long lines to be introduced into the db, which can cause 
inefficiencies in the mapnik rendering process, only splits on osm 
nodes. Therefore, if the distance between two nodes is extremely long 
(e.g. because a node that is part of a way was accidentally moved to 
0/0), there will still be very long ways in the db. This has in the past 
caused the rendering process on osm.org to occasionally  more or less 
stall as many z18 suddenly took nearly two orders of magnitudes longer 
to render, bogging down the rendering queue. Matt Amos has a patch to 
fix this issue, but it isn't yet applied.


Does anyone know of other issues that should prevent the tagging of a 
release or need to be done before hand? Should the above bugs be fixed 
before hand? Or are they sufficiently minor that they don't really have 
an impact on a stable build? I would suggest to ignore #4525 for this 
release, as it is sufficiently long standing that it doesn't matter if 
it is delayed for some more. Also the fix could have potentially rather 
significant slow downs.

Could git snapshot bb40fff69e be a release candidate?

Kai


[1] https://trac.openstreetmap.org/ticket/4525
[2] https://trac.openstreetmap.org/ticket/4553