Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit number of edits per user and day #207

woodpeck opened this issue Aug 6, 2019 · 1 comment


Copy link

commented Aug 6, 2019

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, 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.


This comment has been minimized.

Copy link

commented Aug 6, 2019

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.