Hi Stephan, meanwhile I've asked Steve Hill (author which is mentioned in the source file header) for help. His explanation in brief:
The expired-tiles list which is written by osm2pgsql does not contain any redundant information. This is intended that way because he wanted to save memory: the quad-tree in the algorithm should not grow too much. For this reason there are two groups of tiles excluded from the list: 1. Next lower zoom levels For example, if a tile at zoom level 18 is considered as dirty, you will need to render the related tile at level 17 too. The list will only contain the level-18 tile. 2. Next higher zoom levels If four neighboring tiles at zoom level 18 are dirty and they fit into a single level-17 tile, only the level-17 tile is marked as dirty, the four level-18 tiles are not. Of course I can understand the need to save memory while the expired-tiles list is created but in my opinion this list should be written as a complete list of expired tiles... Markus -------- Original-Nachricht -------- > Datum: Wed, 10 Aug 2011 08:19:34 +0200 > Von: Stephan Knauss <[email protected]> > An: [email protected] > Betreff: Re: [OSM-dev] osm2pgsql, zoom range for -e option? > Hi Markus, > > On 09.08.2011 19:53, [email protected] wrote: > > OK, I fixed the bug. - If it really was a bug and not intended > behaviour. > > I'm still not sure... > > > > My patch (I added just 2 lines): > > diff -C 5 -p expire-tiles_old.c expire-tiles.c > > --- 139,151 ---- > > + if(this_zoom>=min_zoom) > > + fprintf(outfile, "%i/%i/%i\n", this_zoom, x, y); > > + > > I would also expect the lowzoom tiles being expired. Having a quick look > at the source I don'T understand both. What do you try to fix with this > patch? > > If the tile is dirty, I guess it would match one of the tree->complete > conditions. > > What is the flow? It looks like it is recursing by increasing the zoom > level. So it would have started at the low-zooms already. Why did it not > output anything in this situation? > > Is the _mark_tile() working as expected? Do you have data to reproduce > the problem? > > Stephan > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/dev _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
