-
-
Save Hagellach37/5facfb821df1c1551fef8ee30431778b to your computer and use it in GitHub Desktop.
I would focus on empty changesets which have been created during the first 7 days of mapping activity only. The clock starts ticking when the first changeset is created, regardless if it's empty or not. The data for all empty changesets is probably a bit too noisy, but I haven't checked this in detail.
I agree that there might be a number of reasons why a changeset could be empty. Some people might face issues with their internet connection, and then retry a few seconds later. Depending on the editor app used and on settings, such a retry attempt might create an empty changeset.
You'd probably have to fine tune an analysis based on the existing data. One hypothetical scenario could be: if someone on their first mapping days creates an empty changeset, and then 30 seconds another changeset with 500 changes, I'd discard the first changeset as a potential rate limiting victim, since it's rather unlikely to do 500 changes in just 30 seconds.
Hey @mmd-osm ,
thanks for reaching out here and providing your feedback. I will make sure to update this in the blog post.
Still, I find it difficult to identify those changesets which are currently blocked by the OSM API. Would you suggest a way how this could be done? I guess one could look at all empty changesets, but probably there are numerous other reasons why an empty changeset is uploaded?