I've been running a script which consumes minutely diffs from Planet.osm. It's been operating without issue for a number of months. But, this past week it has failed twice for an issue where an element was deleted which was still being referenced by a
relation. The first failure happened on April 7th, when relation 2261308 was deleted even though it was still a member of relation 2261314. The second failure happened on April 12th, where relations 4424718, 4424720, and 4424721 were deleted even though they
were still members of relation 4424722.
Since I've only first run into this issue in the past week, I was wondering if there is a bug that was recently introduced which is allowing these elements to be deleted even though they are still referenced by a relation. Or, are relation references to
deleted elements a normal scenario which my script should be capable of handling?
On 17/04/2020 08:10, Marc Labrecque wrote:
> Since I've only first run into this issue in the past week, I was
> wondering if there is a bug that was recently introduced which is
> allowing these elements to be deleted even though they are still
> referenced by a relation.
This bug has been around for almost a year now, and occurred under very
special circumstances only:
- A user wants to remove the last member of a child relation
- This child relation is part of a 3-level nested relation
In the case of the second example mentioned, the grandparent corresponds
to the National Expressways of South Korea (relation 6818098), which
includes route_master relation 4424722 (parent), which in turn
references relations 4424718, 4424720, and 4424721 as children.
- iD deletes both child and parent relations, but for some reason didn't
adjust the grandparent->parent dependency. This is being addressed in
another GitHub issue.
In the API request, only child and parent relations were to be deleted
using the if-unused="true" flag. This flag is set by some editors like
iD, Potlatch, and GoMap!! to suppress error messages for already deleted
objects. IIRC it has been introduced as a convenience feature for
Potlatch back in the days.
- CGImap deleted the child, although it was still required by the
grandparent->parent dependency. This only happened in case the API was
called with if-unused="true".
An updated CGImap 0.8.2 release including a fix for this issue has been
Thanks again for providing a thorough analysis of the issue.