[Tile-serving] [openstreetmap/osm2pgsql] Feature request: deletion of relation members (#1325)

[Kevin B Kenny]

> Use the 2-stage processing. The `flex-config/route-relations.lua` example config does this.

Can you walk me through how this happens? I'm not seeing it - and I'm fairly convinced that the example script - which I based my own processing on - has the exact same problem. Have you tested it with the following scenario?

Start with a database has already been loaded with a route R and a member way W. There will be one row in 'routes' describing the relation R. The 'highways' table will have a row for way W. In that row, `rel_ids` and `rel_refs` describe its membership in relation R. All is OK so far.

Now, apply an update that removes member way W from relation R and replaces it with member V. (Assume that no change has happened to either member; the route is simply following a different way.)

(a) Stage 1 `process_way` sees neither W nor V because neither way has changed.

(b) Stage 1 `process_relation` is called for the old relation.  It adds a row to `routes` corresponding to the deleted relation, duplicating (harmlessly) the row that's already there. It also records in `w2r` that W is a member of R.

(c) `process_relation_members` is called, and schedules way W for reprocessing.

(d) The old relation is deleted, and the redundant row in `routes` is removed. (I don't know when this happens relative to (c), but it's happening correctly, so no trouble here.)

(e) Stage 1 `process_relation` is called for the new relation. It adds a row to `routes` corresponding to the new version of the relation. It records in `w2r` that V is a member of R.

(f) `process_relation_members` is called, and schedules way V for reprocessing.

(g) Stage 2 `process_way` is called for way W. It creates an entry in `highways` corresponding to W's _former_ membership in relation R. This entry is _in addition to_ the entry in `highways` that was previously there, which has not been deleted, because way W is unchanged from its previous version. There are now two rows in `highways` both showing that W is a member of R. Both are wrong.

(h) Stage 2 `process_way` is called for way V. It creates an entry in `highways` corresponding to V's membership in relation R.  This is the only correct row among the three rows in `highways`.


The minimal fix, as I see it, would be:

(1) Add the `delete` flag that I requested, so that `process_relation` can check it, and _not_ add deleted memberships to `w2r`. That gets rid of the bad row in `highways` that was caused by inserting the member of a deleted relation in (g).
I work around this bad row by cleaning it up using a referential integrity constraint `ON DELETE CASCADE`.

(2) Allow `process_way` to create entries in a relation table, and make `highways` a relation table, so that the magical deletion would actually clean up the residual entries in `highways` that haven't been cleaned up because nothing has touched the ways.  (Right now, you can't insert into a relation table from 1anywhere but `process_relation`, which makes this cleanup impossible.) I don't have a 100% solution for this problem.  For the case of a _modified_ relation, I can work around it by detecting that `process_relation` has been called a second time for the same relation, and cleaning up `w2r` before putting in the new members. For the case of a deleted relation, I cannot do this, and so stage 2 `process_way` simply recreates the rows that the `ON DELETE CASCADE` deleted.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/osm2pgsql/issues/1325#issuecomment-729088059
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tile-serving/attachments/20201117/ff950e8e/attachment.htm>