[OSM-dev] Expiring Tiled OSM Data

Ian Dees ian.dees at gmail.com
Wed Jun 19 19:58:29 UTC 2013


On Wed, Jun 19, 2013 at 11:13 AM, Andy Allan <gravitystorm at gmail.com> wrote:

> On 19 June 2013 16:25, Ian Dees <ian.dees at gmail.com> wrote:
>
> > The last bit of work before I can call it complete is to correctly expire
> > tiles based on the minutely diffs. The naive and incorrect approach
> would be
> > to expire based on node changes. This ignores changes to way and relation
> > tags, for example.
>
> > Any thoughts on how to do this correctly and efficiently?
>
> I think the correct way is, for each tile, to store the list of nodes,
> ways and relations returned within that tile. For example, the map
> call walks up the tree from nodes -> ways, but then also back down the
> three from ways -> nodes in order to complete the way. So if a
> minutely diff marks an entity as expired, I can't see any other way to
> determine which tiles that request is mentioned in, beyond re-creating
> every tile from scratch, or doing some complex graph walking. Even for
> a simple node tag change, that node could appear in any (or all)
> tiles, and doing an exhaustive search of all the ways and relations
> that mention it, and relation members in turn, to find every possible
> bounding box seems the wrong way.
>
> So basically, when generating a tile, store an entity -> tile lookup
> table too. When regenerating a tile, flush the entity -> tile store
> for that tile and repopulate.


So we're talking potentially several billion (entity type)+(entity id) ->
[(tile x)+(tile y), ...] rows in a database of some sort along with the
forward and reverse indexes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20130619/bbb38b71/attachment.html>


More information about the dev mailing list