Hello,
as mentioned last week I would like to start a more proper release
process for a tile rendering stack (osm2pgsql, mod_tile, renderd) of OSM.
With Osm2pgsql currently reasonably stable and no larger development
ongoing, I wanted to start with that and therefore asked if anyone knows
of any
issues that would prevent currently tagging a stable release of osm2pgsql.
Since then only 1 issue cropped up, which should now be fixed thanks to
Sarah. ( PBF files were not correctly read on a 32 bit system due to a
32 bit / 64 bit issue of node ids )
So unless there is any objections, I will tag the current snapshot (
064e2267afff0706e3c208664fdcb45243ed982e ) as a "release" and mark it as
version 0.82.0 later today.
Kai
On 04/08/2013 12:26 AM, Sarah Hoffmann wrote:
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.
Sarah
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
[email protected]
http://lists.openstreetmap.org/listinfo/tile-serving
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev
