BTW, clicking on building and pressing “O” doesn’t work in my JOSM (it will complain about Please select exactly two or three nodes...). And even if it worked, circular building would be at wrong place and in wrong size, which is not much (if any) improvement.
So deleting and recreating is faster and less effort (click for details)
In order to fix it correctly, easiest way in JOSM using O for correctly converting “fake” square building to correct circular one is (as far as I know):
click on one node of original square building
press delete
click on second node
press delete
click on third node
drag and drop it on one part of the circle
click on fourth node
drag and drop it on second part of the circle
press ‘O’
compare that with default JOSM remove-and-readd:
select building(s) (click or drag bbox for multiple) (only once)
press delete (only once)
press ‘a’ (only once)
click on one part of the circle
click on second part of the circle
press ‘O’
or even shorter (with building_tools):
select building(s) (click or drag bbox for multiple) (only once)
press delete (only once)
press ‘alt-z’ for building_tools circular mode (only once)
press ‘b’ (only once)
click on one part of the circle and drag to another
(which is significantly less work, and that work is easier and less error prone due to less mouse movements – especially as first two bullets can be consolidated by drag-a-square-and-delete-multiple-buildings if there is more then one wrong building)
But that is getting off-topic: I was just trying to note why many users do delete-and-recreate instead of modifying existing objects, and so why such behaviour should be taken into account for vandalism countermeasures as it IMHO isn’t going away.
Could a workaround for upcoming mapathons be to let the participants just map the buildings as nodes (possibly adding diameter=* for circular buildings)? While it won’t show up as nicely on most maps, it would be enough to allow workers on the ground to find where there are buildings. It would also be easy to as a next step do a search for these buildings (mapped just as a node and in a changeset with some hashtag as you presumably already use), allowing (humanitarian) mappers with enough edits to not be hit by rate-limits to make them into areas (this is of course not an ideal solution, so should just be seen as a workaround).
I just had a look at How about limit new accounts? (only followed it very shallowly previously) and interestingly I got no search results for either “missing maps”, “mapathon”, “hot” or “humanitarian”. Unless your use case was mentioned somewhere else in the discussion (or I just didn’t use the right search terms) it seems like this use case (mapathons for new mappers) wasn’t considered. If this is the case I think you (the humanitarian mapping organizations) should consider that missing out on a discussion that affects your work so gravely is a pretty big red warning sign that you have some work to do on your cooperation with the larger OSM community. As a community, we of course want to consider everyone’s thoughts, but you can’t count on someone else bringing your thoughts to the table. How frequent are members/representatives of the humanitarian organizations on this forum?
I think three issues are being discussed here, and that it would make sense to try to separate them:
Finding a work-around that allows working with the existing rate limits
Finding another rate-limit or alternative (procedure/organizational)
Implementing another rate limit or alternative (technical)
I feel like 1. is ultimately up to you (the humanitarian mapping organizations) to solve, but you’ve received some good tips here already.
Provided that some consensus can be reached on 2., is there someone from “the humanitarian side” who could implement it in openstreetmap-website (for example someone working on the HOT Tasking Manager)? Alternatively, would there be funding available to find someone else (possibly one of the ordinary maintainers) to implement it? If no to both these questions I think you’ll have to be prepared for a solution to take time to be implemented (unless one of the ordinary maintainers feels like this is a priority, but as volunteers that would be completely up to them of course). Likewise, I think any requests to increase the overall rate limit (or other solutions that would risk letting more bad faith edits in again) should be accompanied by an offer from someone to volunteer to join the DWG to help them handle the possible increase in vandalism.
I think all the suggestions for 2. that have been brought forward so far have some merit, though I think we should be careful about solutions that are along the lines of “just handle mapathon participants separately”; both because it might risk weakening the “no one is more important/has more decision power than anyone else”-aspect and because it might risk increasing the workload of the DWG (if they have to manually handle these exceptions).
I’ll throw a variant of the suggestion by @DavidKarlas (and similar by others) into the ring:
Taking some inspiration from the StackExchange point system (hey, maybe we should have something similar in more ways than this?); any mapper can “vouch” for other users. Vouches remove (or increase) the rate limit of the users vouched for during some specified time period (normally the duration of the mapathon). A mapper can only “vouch” for N users at a time, where N is based on their changeset count/years of experience/something else (since, usually, a more experienced mapper should be able to help more newcomers at once). The power to vouch for another user can be taken away (for example if the DWG finds a lot of bad edits from users vouched for by some user, or even reasons to ban users vouched for). A possible extension could be that “vouches” are only valid for changesets with some specific hashtag or within a specific area, and that they might require a link to the wiki page for the mapathon in question.
I think following the OEG and writing proper documentation on the wiki should be a base requirement before any kind of rate limit exemptions can be implemented.
As there are somewhat frequent complaints about the data quality it might also make sense to update each activity page once post-event validation/cleanup has been done, noting who was responsible for it and what was done (which QA tools where used etc.).
With Changeset: 144564707 | OpenStreetMap I get warnings about overlapping buildings. I do not get any for Changeset: 144106801 | OpenStreetMap. Building with an almost square angle seems to need a download area (bug?) and is only an informational (other) warning and , yes, the minimal and the maximal angles are configurable in advanced preferences (validator.RightAngleBuilding),
The shortcut O works for me but it does not add any nodes, i.e. rather useless with a way with less than five nodes.
As already mentioned, please, use “Replace geometry” from utilsplugin2 if you want to replace a geometry. Simply draw a new, accurate way, select the new way and the old one to replace and press Ctrl+Shift+G.
It would block anyone trying to map forest/lake/road/multiple buildings as their initial edits, what seems undesirable to me
Adding 6 square buildings is already: 6 * 4 = 24 nodes, 6 new ways - for 30 map changes in total. And it is a reasonable edit in the first day of mapping.
I would go with limit like 1000 changes per day for new accounts, later upgraded up to 50000 per day with bot-flagged accounts having no limit. Which should already put some limits on vandal scripts without harming true users.
But even 1000 changes per day would likely cause problems for say people attending workshops about OSM mapping.
(emphasis added)
Though it clearly underestimated scale of even initial edits some attempt to make.
I am pretty sure that I also mentioned HOT editing elsewhere (many new users adding very large volume of buildings) as the most likely false positive and that it would not be false positive in case of very low quality data at large volume. But not sure is it on github or some volatile location.
We did not miss out on a discussion but when I saw there were 267 comments I felt it would not be effective adding one. And wanted to coordinate with Missing Maps partners this week, if this new measure affects them as much as MSF.
As for a page for Organized Editing for each single mapathon, this is the first time I hear about it. There are about 100 MSF mapathons a year. I find that very time-demanding and unrealistic. Do you mean to ask their organizers to create an entry for each? They already often create an eventbrite or tickettailor registration, register the mapathons on the missing maps website, on our internal support request system, sometimes on Osmcal…that makes it a lot for a 1hr-3hr event. And I don’t see hoe that would help prevent the rate limit fot uploading data.
As for 1, has any workable workaround really been proposed? We do not have a way to map buildings as points in iD or JOSM, and I think many community members would disagree to that.
It might have been effective, or it might have been ignored. But I’d argue that it’s a lot better to make a point and have it be ignored than deciding not to participate in the discussion and then complaining once all is said and done (and implemented). If nothing else the case you’re making with this thread would be a lot stronger (note: not saying it is not strong) if your opinions had been voiced earlier.
Just having separate pages each, or the Organized Editing Guidelines as a whole?
While it’s possible to debate the definition of “activity”, the OEG do point at these sample activities, one of which is a mapathon. So to me it’s pretty clear that each mapathon should count as a separate activity, and should therefore have a separate page.
Except osmcal none of those others are really relevant for the larger OSM community. There was another discussion recently that touched on this issue as well; it’s annoying for someone wanting to find out what a hashtag such as #hotosm-project-14894 actually means since you have to find which system that information is stored in (HOT-TM in this case), find the project there etc. While I also don’t think that the wiki is ideal for this, that is currently the only central place to store such information in a way that makes it available to the community at large. So again, having to handle a lot of systems isn’t really the problem of the OSM community, but for your organization to handle (personally, I’d solve that by automating; creating an event in one place (like your internal system) automatically creates it in all other relevant places).
In the case of wiki pages, I assume that they’d look pretty much identical for all your mapathons (or at least one of a small number of variants). Mediawiki has quite good support templates, even without any other automation you could probably set it up so that creating an event page takes less than a minute.
And if this hasn’t convinced you; it’s really bad form to choose to ignore a guideline that the community has agreed on, regardless of your reason. The right thing to do is follow the guidelines while trying to get it changed (again, I also agree that the wiki isn’t really a perfect place for this kind of information, it’s just the least bad right now). Start a thread voicing your opinions on the guidelines and how you’d like them changed, see what the community response is and work with the larger OSM community to come to a solution that hopefully works for all parties involved.
At least in iD it’s perfectly possible (though slightly annoying since you have to specify the tag manually), I’d expect it to be similar in JOSM. And though I’m sure there’ll be people who disagree with that, the wiki page for buildings actually explicitly allows this! (and I’m sure most who would disagree would be alright with this if you make it part of your process to “upgrade” them to areas later on)
I must concede that the impression I got previously (there being several workarounds proposed) seems to have been wrong. Though some parts that you might want to consider at least making sure that the edits made are as small as possible (for example, really making sure that objects are reused where appropriate rather than deleted and re-created, this would also help with data quality).
Also, I believe it’s possible to “save changes for later” in JOSM, so that they can be uploaded within the current rate limit. Again not a perfect solution, only a workaround (since increases the risk of conflicts, has a risk that mappers forget to upload their changesets later, and doesn’t work for iD), but could get you through your upcoming mapathons while a more permanent solution is discussed and implemented.
The Tasking manager project is the central point. The Mapathons Organisers propose to their participants one or many TM-projects to participate. While it m ight be quite difficult to assure we can contact mapathon organisers in general, we already have infos about the Tasking manager project.
I did already propose years ago to have a better workflow between tools such as the Tasking manager (plus quality tools) and editors such as iD and JOSM. See for example the JOSM Remote Control.
The OSM Changeset 96988403 shows tags passed to the iD editor through API communications. The tag host=HOT Tasking Manager links directily to the tasking manager project. Such link could indicate which individual #task and if edit or validation task.
OSM contributors that revise mapping can easily link to the TM-project. Since these metadas are added to the Planet Changeset file, this gives the possibility to analyse such data to find any patterns.
It would also be great if mapathons organizers and HOT-MissingMaps partners would accept to collaborate more closely with us.
The metadata tags could be restructured as :
comment tag : for usual mapping context comments
hahshtags : to group all hashtags
host : https://tasks.hotosm.org/projects/14894/notask#[map|validate] which would link to the #task area and document if mapping or validation step
imagery : imargey used
source: it would also be usefull to differentiate imagey and other sources (JOSM do not propose the imagery tag)
Your use case is not taking tagging into account (the ones that do not render on editor or OSM-carto), which becomes very clear on Organized Editing on areas previously mapped by local mappers (e.g. survey included).
One example of this happening is this one https://www.openstreetmap.org/changeset/142196646. The comment here is in Portuguese, but the delete-then-create in this case was in two different changesets, and not only was not reused elements, but previous tagging building=house (by local mapper, with knowledge) was replaced by a building=yes (by armchair mappers).
(By the way: this kind of problem is far harder to detect than when is in the same changeset.)
So, no, even if is faster, the idea of delete objects (in special by people NOT in the same organized editing) to create new ones is not acceptable. Because to really allow this, at minimum, the guides for new mappers would need to explain what the other tags means.
At the risk of sounding like a broken record,
I want to point out that the initial idea posted on that thread was specifically to tie in the limits to social cohesiveness. More rights & more uploads were suggested (by me) to be allowed when changesets were reviewed. Which would be a trivial thing to do in a mappathon since that by its nature is social.
So the original social idea would still be something I’d push for, it would help a lot by turning new and potentially scamny accounts into recognized mapping accounts that can have much more upload (change) capacity.
Hope this can be taken into account by the foundation and the developer(s).
Ok then ignore JOSM first, because this topic may mainly affect iD users. You assume the size needs to be adjusted. How often is that the case? It’s likely close enough for the example above. How precise are you expecting them to get here?
Even if so, RapiD has long been considering to add scaling by dragging. It’s not an inherent argument favoring delete to redraw. Reimplement scaling · Issue #912 · facebook/Rapid · GitHub
Missing tags as mentioned by others is the other half of the problem I forgot to mention. That supports using “replace geometry” in JOSM.
There’s also the less common case of some users redrawing to ironically a lower quality in general outside HOT, when they can move or do minor adjustments of the part needed, if not “replace geometry”. Deleting should not be encouraged as the 1st solution to turn to immediately, especially for new users with risk of other subpar edits at the same time. If JOSM is taught, the best practices should be presented together.
For your experience, you are either selecting wrongly, or have a non-standard setup. [O] is already the default. It’s technically “align in circle” only. For a smoother shape, you could select the best 3 points to generate a new circle (default is [Shift]+[O]) , then again use “replace geometry” as the solution. That’s something JOSM may further improve, but is still not an inherent flaw. Aside from dragging with Buildings Tools, that same function you used with [O] can generate a circle with a selected line as the diameter,
In iD, a very simple way to adjust the size of many things (definitely circles {e.g.roundabouts}, squares / rectangles {car parks} & irregular shapes {buildings}) is to click on the existing, then click shft + +/- on your computer keyboard.
This will expand or shrink the size of that feature, while keeping it’s shape & proportions intact.
Sure. I give JOSM example as it is what I use and can explain best, but the problem is similar in iD - it does not know where the building should be and in what size/shape. It needs human to tell it that, and it takes extra time and effort. (and by the time we get AI to be good enough to do that stuff automatically without requiring extra effort from humans; we won’t need those pesky fallible human editors anyways in OSM, and could modify rules to ban all human mappers instead )
Ummm, in more or less about 100% of the cases where it needs changing? If how it is mapped is good enough in mapper opinion, then it obviously does not need any work fixing it (either by moving nodes, or by deleting and recreating), so hopefully most people won’t waste their time to “fix” things which they find perfectly OK as they are?
But again, you miss my point. It is not that technical measures to preserve object history do not exist. It is that they invariably are more complicated and require more time and effort for (to average newbie user!!) no visible difference in result at all. Yes, I know how to replace geometry/keep history, and I know why it is a good idea. You don’t need to convince me. You instead need to either:
find a foolproof way to perfectly convince millions of newbies to do more work for same-looking result (without any loss in morale) with about 100% success rate, or
make your peace with likely outcome that it won’t happen, and that non-insignificant number of people will continue to use delete+readd instead of more complex and time consuming alternatives, no matter how hard you try to reach and convince them. Sure, you should still try to educate them (which is completely separate topic to this one), but you also should better take into account the fact that such things will continue to happen – in order to design usable anti-vandalism yet pro-newbies limits.
My point is that former seams quite unlikely, so the latter is what needs to be handled. IOW, the question that needs to be solved (for this thread!) is not“how ideal world should look like”, but instead “how to handle the world as it actually is, in order to get least bad results (i.e. least false positives)”.
(just to preemptively clarify: that “you” / “your” in text above is not personal and not intended to be about any person in particular, but generally speaking referring to anyone willing to involved in the anti-vandalism brainstorming effort in this and similar threads)
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.
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.)
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.
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)
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.
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.
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.
)
