[Tile-serving] New release of osm2pgsql?

Sarah Hoffmann lonvia at denofr.de
Mon Apr 8 06:26:37 UTC 2013

On Sat, Apr 06, 2013 at 05:40:35PM -0600, Kai Krueger wrote:
> 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.

I think now is a good moment. The fixes for the tickets you mention
below have a lot of potential side effects that it would be better
to start tackling them after a new release and have a sufficiently
long testing period.


> 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
> _______________________________________________
> Tile-serving mailing list
> Tile-serving at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tile-serving

More information about the Tile-serving mailing list