[Tile-serving] [osm2pgsql-dev/osm2pgsql] Difference-based expire (Issue #2454)

[Jochen Topf]

joto left a comment (osm2pgsql-dev/osm2pgsql#2454)

> I'm thinking about this from the perspective of water, where you have a geometry for the area and another for a label point if named. A member node movement might result in no changes for the point and only a change in part of the polygon.

If you have several geometry columns they must be handled separately. So we do the expire calculations based on the geometries for each geometry column by itself. (But the expire configuration is per table, not per column, so this has to be kept in mind. Now that I am thinking about this, this might have been the wrong thing to do, we probably should have tied the expire configuration to the column.)

> Should we look at columns? If a member node change can avoid expiring because the geometry and tags are the same that means a tag change that doesn't result in any DB column changes is also safe to not expire by the same logic.

That's a larger subject which I want to keep out of this issue to keep the next step manageable. Currently we only get the geometry from the old, soon to be deleted, row from the database and use that for expire. We could also get the rest of the data and do clever processing deciding whether we actually need to delete that row and then insert the same row again, but that's more complicated and needs some separate discussion, see issue #2406.

> I'm also not sure how this affects two-stage processing....

You can always decide to have diff-expire or not based on your use case. I am seeing diff-expire as an optimization that's "off" by default. If you are sure that diff-expire is fine with your use-case and you are seeing performance problems, then you can enable it, otherwise just ignore it. So we are pushing this decision to the user/writer of the Lua-config.

We do have to think about what diff-expire actually does in two-stage processing so that we can document it and, possibly, avoid situations where it doesn't work as the users expects. I see at least one problem: In normal processing diff-expire should only trigger on changes in child-objects of the object in question, so a change in a node will trigger processing of the way and if the way itself did not change we can do diff-expire for the way, because we are sure only the geometry changed and not the tags. But for two-stage processing the second stage processes *the ways* (based on changes in relations), so we don't know whether tags changed (or tags where handed down from the relations) and we have to do full expire. So I think we have to completely disable diff-expire for two-stage processing. We can only do that better if we also look at the tags etc., see above.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/osm2pgsql-dev/osm2pgsql/issues/2454#issuecomment-3876197282
You are receiving this because you are subscribed to this thread.

Message ID: <osm2pgsql-dev/osm2pgsql/issues/2454/3876197282 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tile-serving/attachments/20260210/4844c563/attachment.htm>