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/[email protected]>
_______________________________________________
Tile-serving mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tile-serving
