[OSM-talk] Mapnik tileset coherency issues

[Patrick Weber]

Tom Hughes wrote:
> In message <471711BB.5080302 at ucl.ac.uk>
>         Patrick Weber <p.weber at ucl.ac.uk> wrote:
>
>   
>> Mapnik's tileset gets updated once a week on Wednesday's, is that
>> right? I wondered how long the update of the whole tileset takes, as I
>> can see now on Thursday morning, that depending on the zoom level,
>> changes are included, and when zooming in, they disappear again. Also,
>> between tile boundaries, changes might appear and thus new roads get
>> cut off.
>>     
>
> There is no global update, nor do we ever have a "complete" set of
> tiles on disk so it's impossible to give a time for something that
> doesn't actually happen.
>   
Right, okay so thats where I went wrong. So the database dump happens 
once a week, but rendering is done quasi continously.
>> Could there be a mecanism to render these tiles without committing
>> them immediately to the live tileset, saving them in a cache, and only
>> when all dirty tiles have been rendered, to update the tileset in one
>> go by replacing tiles in the live tileset? Would that solve coherency
>> issues I just explained? Would there be enough space on the server to
>> keep while rendering thus dual copies of "dirty" tiles ?
>>     
>
> I expect it is very rare that the dirty tile queue ever falls to
> zero, and even then it is no guarantee that the map is consistent.
>
> I suspect what you really mean is that you want all existing tiles
> to be marked dirty when the planet is loaded and for them all the
> be rerendered and then deployed? I don't think that is feasible
> unfortunately - we would probably still be rerendering when the 
> next planet was released ;-)
>
> Tom
>   
Well, I guess that would be the ideal solution if we had endless 
processing power. So there isnt a way to make shure that the tiles 
presented are always coherent in representing a snapshot of the state of 
the database in one moment in time?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p.weber.vcf
Type: text/x-vcard
Size: 282 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20071018/72cc426a/attachment.vcf>