The new rate limiting prevents participants to Missing Maps mapathons from saving buildings

Alas no, that doesn’t really pin it down:

changesets=> select count(*) from osm_changeset where created_at > '2023-11-16 00:00:00' and created_at < '2023-11-16 23:59:59' and tags -> 'comment' like '%msf%'; 
(1 row)

I have long experience collaborating for humanitarian mapping and did coordinate the major OSM Disaster Response before the arrival of Missing Maps. I also wrote often about data quality problems related to Tasking Manager related coordinated mapping projects.

You all want to strictly discuss about rate limits. Looking at the history of HOT/Missing Maps projects mapping escalation via tasking manager and mapathons vs quality problems plus the dificulty for the community to have a good discussion with these humanitarian partners, I personally think that it is important to again discuss about better monitoring of such projects and the quality of edits even more with the arrival of AI related data imports.

For those not familiar with previous discussions, below are a few links :

Below is an Overpass query over Homa Bay where 1,319 buildings loaded, 1,286 with source=microsoft/BuildingFootprints.
Overpass Query- Buildings from nov.15 - Homa Bay Kenya

See for example the changeset 144106801 where 940 buildings are imported. Do you want to remove the rate limit to import more rapidly such type of data ? No reference in the Changeset about the imagery used to compare the import and fix quality problems, and no reference to the tasking manager or any coordinated project.

<changeset id="144106801" created_at="2023-11-16T18:05:34Z" closed_at="2023-11-16T18:05:40Z" open="false" user="obraynt456" uid="12114869" min_lat="-0.5306056" min_lon="34.4503570" max_lat="-0.5230729" max_lon="34.4618476" comments_count="0" changes_count="5114">
<tag k="comment" v="buildings in homa bay town"/>
<tag k="created_by" v="JOSM/1.5 (18822 en)"/>
<tag k="mapwithai" v="939"/>
<tag k="mapwithai:options" v="version=816;maxadd=999;url_ids=facebook_mapwithai"/>

Comparing the building data added to OSM with Esri or Bing, makes me think that no effort was made to correct / align buildings with standared imageries. If we speedup such AI detected buildings imports, we will surely not assure quality.

It is not enough for our humanitarian partners to say that these projects are important for their project and often admit that they worry more about the number of buildings in an area then about mapping quality.


Or at least a quick solution to the immediate problem. That might involve tweaking the limits, but it might also involve, say, marking the accounts of mapathon participants as exempt from the limit in an unbureaucratic fashion. (I think we already have such a solution for import accounts.)

I’m fully in favor of better organized editing practices as well, but that should be a separate conversation. Our humanitarian partners deserve a timely solution to their pressing issue as a first step.


I just looked at the changeset of one of the mentioned maphatons. And sorting by changeset with most deletions, this is the top one.

Note that some objects are deleted then recreated, instead of just reuse (which would allow stay easier under the limits)


Hi, we have also an osm wiki page here: Médecins Sans Frontières - OpenStreetMap Wiki
When back from SotM Africa I will see how to improve this.


Are these mapathons meeting in person or online? If in person itʼd be a good idea to have an experienced OSM contributor looking over shoulders and give them the authority to ease limits if necessary.

We have started these discussions from the start of the Missing Maps project back in 2014-2015. We accomplished a lot for the Nepal 2015 Earthquake response but a lot of frustration was expressed by experience mappers about mapping quality and validation.

If you look at the link above for the Nord Kivu Ebola outbreak in 2018, mapathons organized by partners impacted with bad quality of tracing. In the context of a major emergency, we did have to erase all buildings for Butembo and restart the mapping

Looking more closely at Changeset 144106801, it seems that this was a contribution from a local contributor using AI generated data .

Missing Maps TM-Project-15737 from Nov.14 was in the eastern part of Homa bay and this Overpass Query covers the area from Nov.14. (22,772 buildings from nov.14).

I have to say that Data quality has improved from a few years ago. But still some mappers that trace non-orthogonal buildings or misalligned them comparatively to base imagery. Validation function from JOSM returns for these buildings :

  • section of a way repeated twice - 5 buildings
  • area not closed - 5 ways
  • duplicate - 1 way
  • similar name - 40 (name=edificio)
  • no zone style for a multipolygon (1 building traced with 2 ways grouped in a relation)

Part of this extraction, there are 66 buildings that overlap. There are also many non-orthogonal buildings. But note that using the JOSM validation function, it did not report these non-orthogonal buildings The Changeset session144564707mapped three days ago shows such quality mapping problems. Have the JOSM rules been modified and not catching overlaps and non-orthogonal buildings anymore ? Or do I need to specific parameters in JOSM ? JOSM Preferences - Data validator panel - all options are already checked.

OSMCha for Changeset 144564707

1 Like

This doesn’t describe this specific organised edit. The OEG page needed would contain a bunch of information needed to investigate what was being done and if tweaks to the limits are necessary.


Tested by creating a new OSM account and mapping buildings in Somalia until I hit the limit. I mapped 52 buildings in iD before the limit was hit. This is one of the changesets that went through before the block came in. You can see here all of the buildings that comprise this limit exceeding activity (in iD against black for clarity):

The same in JOSM against Bing imagery (buildings in teal):

And the block:

2023-12-02 08_24_06-Window

I chose an area with circular buildings to demonstrate how the limit can be reached quickly when features require more nodes. But please note that this is not exceptional in humanitarian/development, lots of areas that MSF focuses on include plenty of circular buildings.


Hey, I have added the info about this mapping project to the page. I hope this is sufficient? As said above, I will work to improve our documentation in general the upcoming days.


It occurs to me that circular buildings wouldn’t be the problem they are if we were using Jochen Topf’s API redesign. Is there a way we could simulate some of that in the limits?

1 Like

Note that there is an open issue for iD about reducing the number of nodes used for small circles. Currently these huts which are about 9 square metres get 19 nodes in iD and 8 in JOSM.

Would implementing something closer to the JOSM algorithm raise the point where rate limiting comes in for this kind of edit?


The test changeset above has 44 ways in it and 836 nodes, so yes (the linked example way is circular and has 20 nodes).

8 nodes are too coarse an approximation for a circle, as 45° angles are not small enough for a heuristic to safely assume that they are supposed to represent a curve.

I don’t think the response to overly strict API limits should be to decrease mapping quality. In any case, it would only allow about twice as many buildings to be mapped before you’d run into the limit anyway.


For the avoidance of doubt, the “cicular” item I linked above didn’t look like a perfect circle on the imagery - 6 or so nodes could have actually been more accurate here.

(obvious above Sam was demonstrating “what happens if you draw circles” - I’m not criticising the use of circles in that example!)

1 Like

Yes, good catch, but how to detect that case? While reusing the existing nodes and ways is indeed preferable from “technical neatness” point of view, it often comes at a heavy price of lower edit quality and significantly less efficiency

(i.e. it is significantly simpler to add 3 nodes and press O in JOSM to create perfect circular buildings, then to drag all nodes of existing building to that place and press O, or even worse manually add new ones. Even more so for rectangular ones, it is waaay easier to just delete “junk” buildings and make many perfectly parallel buildings with right angles using building_tools JOSM plugin, then trying to correct them manually one by one)

So whatever is triggering the limits should be made smarter, as IMHO deleting wrong building and creating correct one should ideally not be counted differently than modifying geometry of existing buildings.

One idea that I have not see mentioned yet, might be special treatment of tagless nodes, as well as ways tagged only with building=* (i.e. ignoring them from count). That is because I assume most of the limits are triggered by creating/deleting/modifying buildings (which would not seem like the common case being abused by vandals to me, and yet is very prominent in beginner mappings)

Also, perhaps when changeset is rejected due to said limits its .osc should be saved for later analyses. That would help both with addressing false positives, as well updating the rules for better vandal catching (such as validating or refuting my assumption about buildings above).


Good observation. Can’t speak to that particular changeset, but we usually tell mappers to move and adjust existing buildings.

They are in a format that organizers choose, some online some hybrid and some in person. Whem in person there are trainers and assistants, the kind of support that you mentioned.

1 Like

I think you need the mapathoner plugin in order to flag overlapping and non-orthogonal buildings.


Usually I would always mention how JOSM has “replace geometry”, but the editing procedures you raised are not exactly the problems screenshotted from the changeset there? You can circularize existing buildings as easily in iD as JOSM by selecting them then pressing [O] . It even works on multiple buildings.