Zaczero
Rejecting edits at the null island (0,0)
What about rejecting edits where a node, or a way's node, has coordinates 0, 0 (null island)? It must always be a bug in the editor.
Corresponding ticket at openstreetmap-website: 5279
It must always be a bug in the editor.
This is a reasonable argument and I am in approval of the idea :+1:. This would give app developers a chance to spot the mistake than to continuously upload broken data. I don't think there is a legitimate reason for making such edits. Perhaps just whitelist moderators from this restriction.
Furthermore, the same restriction could be applied to uploading GPS traces and making notes.
Thank you for the quick reply! I also agree with @SomeoneElseOSM from the other ticket; blatantly wrong edits are still useful as poor man's user flags.
So the edit attempt could leave a trace. Even something as simple as reason + date could help mods identify the user's intention (say, a newbie playing around vs a missed sanity check) and help QA tools report the most recent violations.
I don't think these edits are user errors. Null islands typically originate from software bugs. Even intentionally, it would be difficult to create an object at precisely 0.0000000, 0.0000000 coordinates. I can't imagine this scenario affecting more than one or two people at most. Setting up reporting for it seems like unnecessary work. Thoughts?
How would you edit this node: https://www.openstreetmap.org/node/3815077900
I can see two possible solutions:
- Scrap the idea altogether
- Move the node to 0.0000001, 0.0000000: won't matter practically, only sentimentally
I am personally 50/50 on this.
This OsmCha filter lists the monthly changesets within -0.1,-0.1,0.1,0.1 (changeset size bound set to 1 * bbox). There are quite a few user mistakes in there. Also, most of the buoy's history is deletions + reverts. But I just wanted to bring the idea on the table and I'd rather not have the feature than move an object to wrong coordinates.
A new day and a new idea: we could apply the restriction for changesets containing 2 or more null island elements. This won't prevent legitimate edits, and will still detect majority of software related issues.
A new day and a new idea: we could apply the restriction for changesets containing 2 or more null island elements. This won't prevent legitimate edits, and will still detect majority of software related issues.
I am going to slightly bump this discussion. After all this time, I think the notion of blocking "suspicious edits" is a good idea, and would integrate well with the future anti-vandalism detection mechanism. We could start implementing it with a simple rule based system, initially preventing edits containing several objects at the null island. Given the existing arguments, this won't interfere with legitimate use and still detect some software bugs.