[OSM-dev] [PATCH] osm2pgsql tile expiry
Steve Hill
steve at nexusuk.org
Sun Feb 8 14:04:58 GMT 2009
On Sun, 8 Feb 2009, Jon Burgess wrote:
> I have just started running the diff import on the OSM tile server. The
> diff imports are a little slower than I'd ideally like but seem to be
> working.
I've got some significant database performance problems on my system in
general to be honest - I think I'm going to have to spend some time
tuning the DB. My server seems to be unable to keep up with the OSM
updates during the day (it gradually falls behind during the day and then
catches up again overnight: http://openpistemap.org/updategraph ). The
database server seems to be totally I/O bound most of the time.
One query that stands out as very slow is a waterways query generated by
Mapnik at low zooms:
LOG: duration: 19252.079 ms execute <unnamed>: select asbinary(way) as
geom,"landuse","natural","waterway" from (select * from planet_osm_line where
waterway IS NOT NULL or landuse='reservoir' or landuse='water' or
"natural"='lake' or "natural"='water' order by z_order) as water where way &&
setSRID('BOX3D(1066449.418634779 5997554.987368068,1105585.17711679
6036690.745850078)'::box3d,900913)
But as for the performance problems during updates, I haven't pinned down
any specific query that is causing problems, I think it's just being slow
at looking up any record in the DB.
> your
> osm2pgsql solution looks like it handles edge cases where a line crosses
> a tile with no nodes inside the tile.
That was the primary reason for integrating it into osm2pgsql - we're
already calculating all the PostGIS objects here, so it seemed the logical
place to also calculate dirty tiles.
The edge case it can't really handle very well is where Mapnik renders
something (e.g. text) some distance away from the object. At the moment,
the code expires any tiles that are 0.5 tile-widths away from the object
in order to try and reduce this problem. But when using the generated
tile list to expire tiles in lower zoom levels you haven't got as much
data available so you either have to just expire 1 tile and accept that
stuff might get cut off at the edge, or expire all the surrounding tiles
as well.
One option may be to have osm2pgsql calculate dirty tiles for *all* zoom
levels rather than just the maximum, but that's going to make the list
very big.
> I might be tempted to add a metatile flag too. Since mod_tile only cares
> about rendering 8x8 grids of tiles this can dramatically reduce the
> number of tiles that we actually need to track.
Is this not just a case of reducing the zoom level you ask osm2pgsql to
expire for? e.g. if your maximum zoom level is 17 (giving a map 131027
tiles wide), asking for zoom level 14 should give you meta-tiles instead
(the map would be 16384 meta-tiles wide since a zoom level 14 tile
contains an 8x8 array of zoom 17 tiles).
> I don't see anything wrong with you adding this into SVN. Thanks for the
> new code.
Cool. I'll make some of the suggested tweaks to the code and commit it
later today.
- Steve
xmpp:steve at nexusuk.org sip:steve at nexusuk.org http://www.nexusuk.org/
Servatis a periculum, servatis a maleficum - Whisper, Evanescence
More information about the dev
mailing list