[Tile-serving] New release of osm2pgsql?

[Kai Krueger]

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