Limit number of edits per user and day

[woodpeck]

It regularly happens that people - usually, but not always new signups - upload hundreds of thousands of objects to OSM before someone notices and tells them to stop. Then we have to delete those hundreds of thousands of objects again. (Case in point from recent past, https://www.openstreetmap.org/user/maxiangying.) This is undesirable:

• it skews statistics ("wow, today was the day with the most edits since OSM started!!!" etc)
• it wastes processing time and bandwidth on the thousands of servers world wide that are configured to consume updates from OSM
• it wastes processing time and bandwidth on our own database server (where objects are first created, then deleted again, and a copy of the object is nonetheless held in history)
• it wastes the time of volunteers who have to remove the edits
• it embarrasses the person who uploaded the data (at least I hope it does)

While editors can, and should, inform their users about potential issues, I think it would also be worth contemplating to have some sort of rate limit on the API. It could be something that users can override but not accidentally - for example, you could be normally limited to X edits per day (exact numbers t.b.d.) and then you could click a button in your user preferences that says "I have read the data import and mechanical edit guidelines and I want to lift the limitation for one week" or so.

[tomhughes]

From a practical point of view you need to define "edit" somehow - the obvious answer is changesets but that can be easily gamed so it will presumably need to be the number of objects added/changed/deleted.

Doing it per day is probably excessively expensive from an implementation standpoint because it requires resetting counters at some point, or keeping say hourly counts and expiring those over a day old. A token bucket type algorithm like the download limit probably makes more sense.

From a personal point of view I dread dealing with the resulting complaints...

[mmd-osm]

Come to think about this, I think the best place would be really to include such a check only when creating new changesets.

Can we reopen openstreetmap/openstreetmap-website#2342 and close this issue, as the changeset creation logic is still on the Rails side in production right now (even though cgimap-0.8.0-dev already supports it).

I think we would need additional configuration database tables to store rule configuration settings anyway, and more importantly a UI for admins to adjust those settings. CGimap can't help with those two topics.