-
-
Save Hagellach37/5facfb821df1c1551fef8ee30431778b to your computer and use it in GitHub Desktop.
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?
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.
API maintainer here.
That’s not quite accurate. These blocked uploads would show up as empty changesets, since you need to create a changeset first before uploading any changes. If the latter fails, an empty changeset will be still around.