Great idea, let the mapathon moderator vouch for the new members to lift the restrictions. If there are active users who vouch for the vandalism conductor, then lets block all of them.
2 Likes
Also, would it be better for the editor to warn new users when their first changeset is approaching the limit that they will not be able to save all their edits due to the rate limit? (Although this might lead to a rebellious streak in the vandals trying to do as much damage as possible while wiping the line? So I don’t know whether this is a good idea.)
2 Likes
In practice, we write and give instructions at MSF or my community (Missing Maps CZ SK) mapathons so new mappers do not delete and recreate objects. In singular cases, new mappers may delete buildings that are no longer on newer satellite imagery. And we encourage them to correct/adjust existing footprints, when they ask. The projects assigned to the recent mapathons contained no or practically no buildings mapped previously, only 3 projects published contained some and those have been mapped by individual volunteers. Only experienced mappers / validators may do that selectively when they deem it efficient way and no valuable information would get lost, usually checking history and authors in JOSM.
1 Like
Ok, now, after the https://wiki.openstreetmap.org/w/index.php?title=Médecins_Sans_Frontières&type=revision&diff=2624910&oldid=2492619 at least one Organized Editing Activity from MSF is documented on the wiki, so at least we can discuss the topic.
And looking at the #homabay2023 hashtag, and…
this changeset https://www.openstreetmap.org/changeset/144300761 the mapper delete and recreate objects that previously arent even misaligned. The change is so small, but so small, that OSMCha barely chan show both objects at same time
Also, you from MSF seems to not be watching changeset comments on your mappers, and (at least before the Wiki page) was no central place to comment in public about the problem. But let me show here that yes, it’s not an isolated case of people deleting-then-creating objects
The text in the image is the following (so others can use translation):
Discussão
Comentário de woodpeck há 17 dias atrás
Dear user aracho, welcome to OSM. In this changeset you have deleted a lot of buildings, only to re-draw them with a little offset. Large deletions like that can set alarm bells ringing. If you are improving an existing building, try to just move it to the right location rather than deleting and re-creating it. Also, when deleting lots of buildings it is good to specify a reason in the changeset comment (e.g. “removing buildings that were destroyed by flood” or so), so that people know it is not an accident.
PS: this was a just a quick look at #homabay2023. Also, about the “rounding buildings” most cases I’m finding about creation/deletion already are poor mapping, to a point of even the validators delete it later (or is someone new deleting one to create another near)
Edit: added text from the image on the changeset
7 Likes
The API has no concept of reviewed changesets. I believe all that is reasonably available is what is found in changeset metadata and the status of reports against a user. Currently the function uses time since first change, moderator/importer status, and some block information to derive max changes per hour, which is then used to compute max changes and compare with recent changes.
If someone wants to propose new rate limits, they should provide some analysis on how it will impact mapathons and how it will impact vandals. It can’t rely on anything external to the API database.
7 Likes
Yes, this is due to a deeper problem that OSM, as a technology, missing the social aspects of our community. Accounts on this forum have a lot of features supporting the social part. Things like “you are a good contributor when 100 posts of yours get at least 2 upvotes”. The entire concept of not just this specific (random) example, but the entire generic idea of such statistics are missing in the OSM database.
As posted before, the idea is fleshed out more on How about limit new accounts?. So I won’t go into details. I’ve just posted about the fact that the problems we are seeing in mapathons can be solved by accepting that social mapping solves this already. So my hope is that the guys writing the code can be convined that what already works in real life can be reflected in software.
So, in short, adding restrictions like editing limitations is new territory for OSM and I hope people using the forums and people organizing mapathons can chime in into the direction that the limits can take. One set of limits was never going to work, adding the social ladder to it probably will make it work.
7 Likes
Hi, well observed changeset with unecessary deleting and redrawing. I would like to clarify that this changeset did not happen at an MSF mapathon; there was none 13 days ago. In mappers’ individual mapping, we cannot of course assure such a supportive guidance for specific changes. But we can try to tweak the instructions to request that mappers do not delete and redraw the same objects.
Making a significant API change like that would be a much bigger project and involve many more people, across multiple software projects. If you think that is worthwhile, you need to start to propose the API that you want to see, and then figure out the UI for it. Also, while a change to the rate limit could be done fairly quickly, a new API takes longer.
7 Likes
MissingMaps publishes Cumulative Statistics for the period 2015-oct.2023 (see
Statistics ). It reports 50 million buildings created since 2015 in context of these projects, 15 million modified and 700,000 deleted. It also shows a very low retention with only 7.4% of contributors still active after 5 days.
Various studies including my diary PierZen's Diary | OSM Contributors Outlook - The Pulse of OpenStreetMap Contributors | OpenStreetMap shows this pattern of participation to OSM. I compiled OSM Planet Changeset monthly statistics of contribution with a classification of days of participation similar to Pascal Neis. For the period 2010-01 to 2017-08, I estimate that Contributors who last 1-2 days contributed on average 122 objects while contributors with 3-14 days of contribution, edited on average 1, 013 objects (ie. node, way, relation).
In such context, I would like to read arguments that justify to increase the rate over 1,000 objects per hour. It would be interesting also to document contribution of those that have hit the limit in their first days of contribution.
There are some actions from new contributors that should flag Let’s look more closely. Deletions by new contributors, removing names or revising/deleting relations are surely part of this. With editors such as RapiD, there is also the risk that new contributors simply import thousand of buildings without revising with appropriate background image.
Detailed Compilations available on OsmContributorStats-Changesets/Pulse_of_OpenStreetMap_Contributors_2017-10-11 at master · pierzen/OsmContributorStats-Changesets · GitHub.
1 Like
I had a DWG case a while ago where new mappers, contributing to a Govt program, were apparently having a competition amongst their group, to see who could add 10000 random, untagged, nodes the quickest! 
One of them, on their first day of mapping, had ~150k “edits” to their name 
No, this wasn’t HOT or MSF, but it still indicates a problem.
I see two different factors in making a decision whether to accept changes:
-
“whether the user is newbie or regular/advanced” - I understand that getting some global reputation score for user is difficult and require extra caching fields and periodic updates (but would bring best results in the long run). On the other hand simpler detection (i.e. is account created in the past 5 days) should be relatively easy.
-
(only) if the user is determined as newbie, what counts as highly likely problematic activity? (not all changes are the same, e.g. adding tagless nodes should have much less impact then say deleting or changing
nametags)
What I am wondering is how hard it would be to “simply” count some of changes by the user differently, as it seems there are some relatively low-hanging fruits there.
As I understand it (please correct me if wrong), currently limiting works by comparing raw count of added/deleted/changes objects by that user in recent past, e.g. something like this pseudocode (exact numbers are just examples):
reject if count_changes("uid=%uid% and time < now-30min") > 1000
If we are considering increasing the limit of changes (from 1000 in that example to say 3000) to avoid problem with mapathons, how hard would it be to have limit extended so certain things (like deletion/modification of name tags) are counted with some multiplier, in order to re-balance the equation in case of vandalism? e.g. something like:
reject if count_changes('uid=%uid% and time < now-30min') +
10 * count_changes('uid=%uid% and time < now-30min' and
(tag_changed='name' or tag_deleted='name'))
> 3000
1 Like
Absolutely, this is a discussion that started in June this year, nobody is taking it lightly.
The rate-limiting is, just like you pointed out, the low hanging fruit and has been rolled out not very long ago. I’m no programmer but I expect it was not trivial either.
So the reason I commented here is to align the viewpoints across a bigger part of our ecosystem and indicating that the pains we see in this thread are expected to be temporary. We can all join into the design and communication to make the transfer as smooth as possible, what we can not do is ignore the rationale and need for actual limits.
1 Like
I was curious to see how exactly it is implemented now, so for anyone else who also wants to have a look:
The main code (in the form of a database function): https://github.com/openstreetmap/openstreetmap-website/blob/master/lib/database_functions.rb#L2-L57
Settings (specific values, used by the function): https://github.com/openstreetmap/openstreetmap-website/blob/master/config/settings.yml#L67-L73
2 Likes
note that links go to dev repo of specific person, not deployed version (so if something changes it may be not visible here)
1 Like
Ups, was a bit to quick there, fixed!
In today’s mapathon #mmmza11 we have reached limit just once. It was mostly because there were just a few new mappers. It was reached with this changet Changeset: 144803560 | OpenStreetMap You can see first upload try when changeset was created and after 10 minutes of waiting it was possible to upload changes.
5 Likes
For info, the account that reached the limit had these edits:
id | num_changes | created_at
-----------+-------------+---------------------
144768383 | 2 | 2023-12-04 20:06:58
144768391 | 1 | 2023-12-04 20:07:09
144768401 | 3 | 2023-12-04 20:07:28
144768384 | 4 | 2023-12-04 20:06:59
144783569 | 2 | 2023-12-05 09:13:36
144783587 | 1 | 2023-12-05 09:14:18
144783598 | 3 | 2023-12-05 09:14:34
144800157 | 130 | 2023-12-05 17:11:52
144800595 | 65 | 2023-12-05 17:23:53
144801277 | 386 | 2023-12-05 17:44:31
144801622 | 298 | 2023-12-05 17:55:29
144802449 | 565 | 2023-12-05 18:19:38
144802600 | 33 | 2023-12-05 18:24:23
144803022 | 411 | 2023-12-05 18:35:53
144803502 | 518 | 2023-12-05 18:50:48
144803560 | 25 | 2023-12-05 18:52:40
144805432 | 1 | 2023-12-05 20:04:31
144805427 | 3 | 2023-12-05 20:04:21
(18 rows)
I hope they don’t mind me posting that here - to be clear, there’s no suggestion that they’re doing anything wrong; I’m just including it here to help understand the sorts of changes involved. Most of the buildings here are rectangular, not round.
5 Likes
And on a first glance, those changesets look fine to me, e.g. changeset #144803502 added 84 new houses and modified dozen of them in about 15 minutes. So they could easily go over 1000 objects limit in an about a half hour.
So, about 10 seconds per building average, which looks to me like it shouldn’t be blocked for new user (i.e. it does not seem too fast at all, especially for JOSM in which that changeset was done - if they were shown building_tools (which they absolutely should be, if they are instructing them to draw buildings in JOSM!), it is quite expectable that even a OSM newbie can quickly learn to draw quite decent square building in 2 seconds or so (much less 10 seconds!), especially if they are proficient with using a mouse.
11 Likes
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
.
4 Likes
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.
2 Likes