<div dir="ltr">On Wed, Jun 19, 2013 at 11:13 AM, Andy Allan <span dir="ltr"><<a href="mailto:gravitystorm@gmail.com" target="_blank">gravitystorm@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 19 June 2013 16:25, Ian Dees <<a href="mailto:ian.dees@gmail.com">ian.dees@gmail.com</a>> wrote:<br>


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

</div></div></div>