Here is a list of users which have paticipated yesterday. Somebody can count averages per hour. (These were not new mappers, but at least we get some data about how fast limit can be reached with mostly good data)
openstreetmap.org/user/L Sochorova/history
openstreetmap.org/user/Pavol Žigo/history
openstreetmap.org/user/MatusD/history
openstreetmap.org/user/MaKr0/history
openstreetmap.org/user/Branisla_0/history
openstreetmap.org/user/matty351/history
openstreetmap.org/user/Pinzo/history
openstreetmap.org/user/kristiand22/history
openstreetmap.org/user/ErikHadida/history
openstreetmap.org/user/Filip Nadžady/history
openstreetmap.org/user/mkropuch/history
openstreetmap.org/user/Kristián Bačik/history
openstreetmap.org/user/abil3311/history
openstreetmap.org/user/infiniteatomic/history
openstreetmap.org/user/abil3311/history
openstreetmap.org/user/alfonzalfonz/history
openstreetmap.org/user/michalkova/history
openstreetmap.org/user/TheElevatedOne/history
openstreetmap.org/user/psondreicka/history
openstreetmap.org/user/VlNecesany/history
openstreetmap.org/user/Krysa9/history
.
More and more I see the need to introduce the functionality of account moderation. I myself also run Mapatons in Poland. Mostly for people who are professionally involved in mapmaking. It should be possible to increase the limit for accounts, either by a moderator or for people who belong to a group such as MM or Local Chapter. Extending the functionality of OSM.org accounts with such features should have happened a long time ago.
In principle, I agree with Cristoffs, although in our case we can speak of mapathon participants belonging to a local chapter of Missing Maps only in Czechia, Slovakia and the UK, and to OSM sometimes in case our GIS officers organize a mapathon locally, in Zimbabwe, for example. In some other countries, we organize them regularly, like every 2 or 3 months, yet there is no self-identified community. So that would be limiting for MSF mapathon participants, to have to belong to a defined group to have a more reasonable limit, in about 17 other remaining countries, 65% of our mapathons.
Deviating from the topic (Sory) 
We could think about organizing mapathons under the aegis of MM also in Poland. Get back to me on PM, we will talk.
That is an interesting suggestion to count more ‘grave’ changes, like deleting buildings or changing tags, with a multiplier! I would support that.
In order to help people think about the sort of edits we’re seeing on the other side of the coin, here’s a set of changesets that I’ve just reverted:
id | num_changes | created_at
-----------+-------------+---------------------
143552401 | 7 | 2023-11-02 23:28:08
144221297 | 2 | 2023-11-19 19:52:56
144879446 | 523 | 2023-12-07 20:14:48
144879477 | 10000 | 2023-12-07 20:15:37
144879565 | 10000 | 2023-12-07 20:19:34
144879570 | 609 | 2023-12-07 20:19:47
144879580 | 3438 | 2023-12-07 20:20:05
144879619 | 10000 | 2023-12-07 20:21:24
144879621 | 4823 | 2023-12-07 20:21:33
144879632 | 1900 | 2023-12-07 20:22:17
144879677 | 7289 | 2023-12-07 20:24:12
144879700 | 2593 | 2023-12-07 20:25:11
144879719 | 7289 | 2023-12-07 20:25:52
144879746 | 437 | 2023-12-07 20:26:41
144879759 | 779 | 2023-12-07 20:27:07
144879783 | 10000 | 2023-12-07 20:27:55
144879824 | 10000 | 2023-12-07 20:29:28
144879831 | 10000 | 2023-12-07 20:29:35
144879834 | 8356 | 2023-12-07 20:29:43
144879905 | 1249 | 2023-12-07 20:32:23
144880015 | 224 | 2023-12-07 20:37:07
144880085 | 224 | 2023-12-07 20:40:28
144880311 | 16 | 2023-12-07 20:49:46
144880419 | 199 | 2023-12-07 20:54:32
144880657 | 0 | 2023-12-07 21:03:15
(25 rows)
I wonder if the entire contribution of the local mapathon could be stored in a kind of ‘staged repository’ before ultimately being committed to the main OSM database.
It could function similarly to a Git repository:
- Pull data from the main OSM database (for a specific area) and create a local repository.
- Push all contributions from the mapathon to that local repository.
- After undergoing reviews by the mapathon manager, this local repository will be pushed to the main OSM database.
Optional : Create a local OSM Carto renderer for the repository containing edits from the local mapathon.
Corollary : This will create numerous ‘OSM local forks’ in a specific local area. I don’t know whether this is a good thing or not.
The technical challenge here is how to make the core OSM infrastructure more mobile, allowing anyone to initiate their local “OSM server” and begin serving the read-write API for local mapathon contributors.
Proxy accounts merging contribution from multiple users are in general really bad idea.
I’m also doubtful of that idea (both because it has a high risk of “fragmenting” the community and because it would be a gigantic technical undertaking, which, since I still haven’t gotten a response on if there would be developers from the humanitarian communities who’d be able to help implement any changes, I doubt anyone is willing to do).
However, something similar can be done with our tools today; it’s possible to download change files from both iD and JOSM. Those could then either be uploaded later by the mapper (though with the risk that this gets forgotten) or by someone with higher rate limits (though would get the wrong attribution, similar issue as Mateusz mentioned).
It would also be possible to build a “queue” service, where anyone can login and upload a change file, and the service would then periodically retry to upload it, this would be similar to your intermediary/staging area idea. Shouldn’t be too hard technically, but would need some safeguards against usage by bad-faith actors (otherwise they’d just end up queueing a lot of vandalism changes).
yes, and was done before, effects were really poor
Years ago I remember hearing about an attempted decentralised OSM DB, Portable OSM, but I think nothing came of that.
As far I know it was used quite a bit, but it has obvious downsides that make its approach not applicable for anything that has to remotely scale (which is the same for many of the proposals made here).
This is exactly what was on my mind. Thanks for pointing it out.
It is not, for two reasons. The API is tag-agnostic, by design, and secondly, that information isn’t available from the changeset table. The rate limit function needs to be queried many times, so I don’t see going to the full history tables as practical.
I’m not really following the pseudo-code, but this doesn’t really make much sense as tags aren’t deleted or changed in the API. A new version is uploaded with a complete set of tags.
Hi, I just wanted to share that I have written a new section on MSF OSM wiki page on Assuring Data Quality, where I describe the measure we take. You can check here: Médecins Sans Frontières - OpenStreetMap Wiki
The limit was a minor or no issue at our last December mapathons last week, because the mapathons with corporate partners were too short to do enough mapping for anyone to reach it, and the Greece and Brazil mapathons were too small (no one reached it). At our Swiss Geneva mapathon on 13 Dec, there was one person who reached the limit, user name MoYuTu99, and Czech Olomouc mapathon on 13 Dec, also one.
Hi @pnorman @Mateusz_Konieczny @kaartjesman @Kovoschiz @Matija_Nalis and all contributing to this thread who may be interested, here is a scientific analysis from @Hagellach37 published on the HeiGIT blog about Missing Maps new users and how they would be affected by different rate limits. We are curious about your thoughts.
I am skeptical about the analysis. At the end it identifies that about 32k/58kchangesets were made in Ukraine. To a reasonable approximation, all the high volume edits from new users in Ukraine during this time were vandalism. Most of the ones in Russia and Belarus would be too, but I didn’t consider those. Many of the users were not blocked as they were deleted. This makes the users which were blocked metric meaningless as due to the nature of the most common vandalism, vandals would not show up under this metric. It would have been better to look at users that were blocked or deleted their account, and then check what this metric was missing.
Because it’s missing this, it makes the user counts not very useful. The percentage of changesets that are vandalism goes up as you go from 1000 to 5000, but it also starts missing a bunch of the vandalism. This makes me curious about the changesets that fall between 1000 and 5000.
Publishing a list of changesets would be useful, as it would allow users to do an analysis of the interesting part.
Overall, the analysis confirms that over 50% of blocked edits are likely vandalism and as the rate limit increases that percentage goes higher.
I also followed
Get in touch with us via ohsome@heigit.org if you have further questions about our analysis and its results.
and wrote to them
EDIT: got reply - they made minor tweak to text and mentioned that they want to look into deleted but not blocked accounts and gave them futher info about deleted vandal acounts
Thanks for doing that legwork!
I am under the impression that the option of finding an local optimal for limits is not all that useful as the situation is a transitory one. Not in a government sense where any transitory situation tends to become permanent 
No, instead this is simply hard work that needs to be done and has been acknowledged by devs and the foundation.
I stand by this older post where the longer term vision is to recognize that lone mappers can have much lower limits than mappers doing it in a team with a social element to it. Because the limits are not just about actual intentional vandalism, they are just as much about well intended but maybe harmful changes.
Lets aim to make new people actually seek out and work with experienced ones if they want to get full access.
The older post:
Hey @pnorman @Mateusz_Konieczny ,
we have updated the blog post and analysis which now includes also changes from account which were deleted. You will find the changes marked in red in the post.
I think to some extend this should answer your open questions.