You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Deleting a feature can destroy much work. Therefore, iD should be quite protective here. We should not enable the delete operation while the feature is not fully visible. Instead of delete we might add a zoom feature operation to the radial menu in this case.
In case of complex features (many nodes or members) iD should be even more protective. The delete button should just add a delete request field on top of the fields section, where the user has to add a reason. This should add a tag like delete_request=reason.
In case such a tag was constantly in the object history for some time (e.g. a week) an immediate delete should be possible. Such delete requests tags should be monitored in a QA tool.
The text was updated successfully, but these errors were encountered:
We should not enable the delete operation while the feature is not fully visible
I agree with this part.
All the other stuff you mentioned about checking for the complexity of the feature or asking users to supply a reason for deletion sounds like it would make iD too complex and unfriendly, or depends on other people building OSM tools that don't exist yet.
All the other stuff you mentioned about checking for the complexity of the feature or asking users to supply a reason for deletion sounds like it would make iD too complex and unfriendly, or depends on other people building OSM tools that don't exist yet.
We don't need any new OSM tools, just a link to Overpass Turbo or TagInfo does the job of monitoring the delete requests.
When deleting significant work, having to write a reason and waiting a few days doesn't seem to be unfriendly, especially because it is indicating that the user's own contributions are also protected.
In regions with an active community the wait time would likely be much shorter, because a JOSM user would just delete it, provided a good reason was given.
Disallowing to delete, as you have proposed for large features, seems to be much more unfriendly.
Just offering a single click delete for significant work might appear as disrespect to user contributions.
I don't think this would be complex, at least not for the user, maybe a little more in view of programming.
Deleting a feature can destroy much work. Therefore, iD should be quite protective here. We should not enable the delete operation while the feature is not fully visible. Instead of delete we might add a zoom feature operation to the radial menu in this case.
In case of complex features (many nodes or members) iD should be even more protective. The delete button should just add a delete request field on top of the fields section, where the user has to add a reason. This should add a tag like delete_request=reason.
In case such a tag was constantly in the object history for some time (e.g. a week) an immediate delete should be possible. Such delete requests tags should be monitored in a QA tool.
The text was updated successfully, but these errors were encountered: