Handling of Dependent Objects

[lonvia]

( copied over from #1663)

We should think about ways of doing attribute-based "expire" and re-processing. One option would be to add some kind of hash to each database entry. That hash must be calculated in the Lua config based on the tags used in an object. And osm2pgsql would keep track of those hashes and make sure objects with the same hash are re-processed whenever an object with that hash changes.

[pnorman]

I'm reading the linked issues of #1663 and #2204 (reply in thread) and I'm not sure if an easier way to handle relation geometry generation is in scope. I want to be able to insert a geometry from a relation member when in the process_relation callback, e.g. to insert a point from the first node member in the members list.

[joto]

@pnorman I agree that that's something we need, but I am not sure this is related to this particular issue.

[pnorman]

I'm not sure either - what I posted is a case of dependent objects, but this issue might only be about object invalidation. The linked issues also add a bit of confusion.

Processing of dependent objects currently only works through OSM object dependencies: when a node changes, all ways and relations containing the node are reprocessed, same for ways. This can be at the same time, invalidate too many objects (changing the tags on a node might have no influence on the way) or too few (you might want to invalidate near-by nodes). The dependency handling also works the same for all tables: it is the input object that gets recomputed for all tables.

osm2pgsql needs a more flexible mechanism to handle dependent updates. Ideally the mechanism also allows to express transitive relationships: a change in OpenStreetMap triggers changes in table A, which in turn triggers updates in table B.