Implement "if-unused" osmChange API feature for outside BBOX nodes

[anonymous]

API 0.6 has been extended to support a "if-unused" delete node attribute on osmChange diff uploads.

Introduced here: ​http://git.openstreetmap.org/rails.git/commitdiff/2d937f94d55c0b8f94b024f579a78271d85fbe9a

It would make sense to start using this for nodes which are deleted, instead of prompting user when they attempt to delete a node outside known BBOX.

[anonymous]

Potlatch 2 now implements: ​http://trac.openstreetmap.org/changeset/24776

[framm]

It is probably not good to use this for *all* nodes that are deleted because this means that editing conflicts go unnoticed. And it is probably not good either to drop the "you are deleting stuff outside the downloaded area" message either because doing so is usually not a good thing - some things might rely on what you're deleting without actually using it, e.g. you delete a road for which someone else has made a corridor through a forest just outside your downloaded area - so you want to delete the road and let the corridor remain? etc.

[pnorman]

framm: We had talked a couple of weeks ago, do you have any further thoughts on this? I think it makes sense to do if-unused for all nodes outside the downloaded area

[skyper]

We have to be careful as framm already mentioned. Though I am sometimes annoyed about the stupid conflicts when just deleting nodes outside area which are no end nodes of any way.

Did not really understand what "if-unused" is really doing but if it checks for tags, membership, end node of way and not part of more than one remaining way, it would be save to use. Seems something similar was implemented.

We only need to take care of new objects.
Still a major task and I would prefer to get the defects about conflict detection fixed first.

[Don-vip]

Replying to skyper:

Did not really understand what "if-unused" is really doing

There is ​some documentation.

[skyper]

Replying to Don-vip:

Replying to skyper:

Did not really understand what "if-unused" is really doing

There is ​some documentation.

Thanks but if this method does not check for tags on the deleted nodes which is dangerous and overall it seems to be not very useful as conflict management should already handle any edge cases and the rest should be deletable anyway.

What I was looking for was a method which simply deletes the crossing node of two ways once one is deleted plus manages cases with more than two ways by keeping the node both without any new conflicts. Sure the four checks previously mentioned are needed.

[skyper]

Ok, we could benefit of less conflicts but leaving quite some unneeded nodes within the data. The problem is that "update data" only checks objects within download area and will not find these conflicts. You either have to manually download the area or you might get a lot of upload interruptions. I did not check if "update modified" checks delete nodes but I guess not.

[pnorman]

The user deleting already knows if there are tags on the deleted nodes, they just don't know if they are referenced by another object. if-unused is equivalent to automatically resolving in favour of keeping.

[blackboxlogic@…]

This feature would still be nice to have! (he says, talking into the void)