4 posts were split to a new topic: MapRoulette Critique
We unfortunately know that many even high-changeset-count mappers do not review āsuggestionsā in various existing editors** and add things that the merest glance at the screen would reveal to be fiction (umbrellas as buildings was one of my favourites). Maybe one way that Rapid could gain more support is by proposing to do a better job than iD or JOSM do currently at that?
** For the avoidance of doubt Iāve seen problems like this it has mainly been JOSM and iD users, so this absolutely isnāt an argument against Rapid per se; more a comment that we have an unreviewed data problem*** in OSM that we really ought to address.
*** Particular in areas where relatively new users have been encouraged to sign up and edit en masse. Everyone was a new user once; the challenge is to help them become an engaged and accurate OSM editor, not just someone who clicks a few buttons a few times and then goes away.
5 Likes
Picking up on the theme of what editors are for ā¦ so much to say here on user experience, onboarding, and the role of the website. In broadest terms, the OSM website goal is to facilitate editing and expose mappers to all the ways of working with OSM data. Achieving that, balancing community consensus and user experience, is quite a challenge. This is a great and exciting community conversation, and I hope we can turn it into concrete directions for development. Excellent if the discussion of the editor inclusion policy leads to more concrete plans. But we shouldnāt block policy development on attaining answers to these questions. Also, I donāt think thereās any intention right now to fundamentally change the default interaction, that the default action of clicking the Edit button is to open iD.
On the policy topic of AI generated data, the policy for editors should align with practices and guidelines at work in general for editing OSM data. Using AI generated data as part of the editing process can be valuable, when aligned. We want a policy that can be as general possible.
Of course looking at Rapid is immediate and instructive to shape that policy. I just took a look at what Rapid currently makes available. There are Microsoft Buildings, Facebook Roads, and a good number of public sector datasets via ESRI. The Microsoft Buildings dataset is good for indicating generally where buildings are missing, but the quality of the shapes, and the comprehensiveness of detection, vary very widely; agree with @InsertUserās assessment. The Facebook Roads I find pretty helpful for directly editing. When the detection is not a false positive, the geometries match what was on the ground, and being able to bring that geometry directly into editing is very helpful. Rapid could do a bit more to contextualize them as suggestions, and make sure that editors give a proper assessment before adding them. I also think the default tags could be better ā I had rural roads classified as residential, and think the source tag shouldnāt be on an individual feature, but in the changeset. Those are a few of my ideas. Others have those as well. Iām sure Meta wants to improve the experience of Rapid, thatās why theyāre investing in it.
For any software project, itās admittedly difficult to set direction and make decisions based on so many points of view. I think this connects to why the SDRP was included in the policy draft, so that there is a structural connection to an arbitration mechanism that is community based. In practice, with iD, thatās never been necessary to invoke because iD has been practicing community engagement. However it is implemented, I think community responsiveness is what we want to see in general from any editor.
2 Likes
Given that Rapid has nearly no user base that is expected.
PS: if it isnāt clear (Iām sure Andy knows this, but for anybody else) if you want to make a statement as to behaviour an editor induces or not, it has to be relative to the number of edits actually made with that editor to be meaningful. Otherwise it is simply saying by far the majority of edits are made with iD and JOSM, and naturally most bad edits are made by iD and JOSM.
3 Likes
For what itās worth, many of datasets available in Rapid Assist are ArcGIS datasets for which Esri followed the procedure laid out in the import guidelines (wiki proposal page, imports mailing list announcement, etc.). In a couple cases Iām aware of, these import proposals conflicted with other import proposals from volunteers in the local community, so folks closely watching the wiki had to intervene before edit conflicts arose. Otherwise, there was very little comment from the community on the imports mailing list at the time.
Most if not all of these datasets are conventional GIS building layers at the county level in the U.S., so theyāre pretty straightforward to characterize and review. The more contentious datasets seem to be the broader-scale ones that didnāt go through the same Esri pipeline.
1 Like
Eg. if Rapid would make sure that each node of each buildings derived from AI is in a different position than suggested by AI, the whole thing would be a different story 
Then I could somehow follow your argument, that the editor actually enforces, that the user is verifying the data. Since for sure, AI-suggestion is not perfect.
But if open source is part of the policy and Rapidās AI stuff is closed source, isnāt that simply a non-starter?
The generation of the data is closed source, just as it is with the Linux Foundations Overture Map Foundation and that doesnāt seen to concern anybody either, for example the Humanitarian Overture Team.
4 Likes
A closed source data generation process is not at all a non starter for OSM. As long as data is made available under a compatible license, it can be considered as a source in OSM. Think of any municipal dataset, frequently created using ESRI tools. This should have no impact on the policy under discussion.
Getting way off topic again with the bogeyman stuff, but yes Facebook Roads process is closed source. I have no idea if they have plans to release anything there ever or how much work that would be. Iāll note that Meta has been releasing many AI resources as open source, including a new version of Segment Anything, which could possibly have utility in the map making process.
The Overture Map Foundation data packaging process is closed source. I do find this surprising given how recently they arisen and the aims of Overture. Maybe this will change? For OSM, honestly Iām more interested in ways they could contribute to make new datasets theyāve released easy to evaluate for OSM, and that means their places data. Itās a data set that need close human evaluation, and I could see that as a useful source in Rapid.
On HOT, they wrestled with that decision about how to engage with Overture, just as we have in OSMF. In the end, I guess they saw little downside to having an inside ear to whatās happening and some comms boost. I donāt expect it has much practical importance.
4 Likes
The aims of Overture have been debated elsewhere on this forum. I donāt think it will to us any good to rehash them in this thread.
3 Likes
Rapid had half of JOSMās userbase in 2023. 9,121 unique editors compared to JOSMās 19,636. By number of edits, it was the 3rd most used editor.
Iām not arguing these are huge numbers, but by your calculations where does every editor with lower numbers than this stand?
The 2023 numbers show a large one time influx of new users in February that skewed things see Simon Poole: "@nakaner@sueden.social @djh@chaos.social @mvexel ā¦" - OSM Town | Mapstodon for OpenStreetMap
(as you can see this is anything but news).
Compared to iD essentially all other editors are also runs and it gets worse (fsvo) if you remove double counting of mappers. That we weāre messing around with a key part of our new mapper funnel is my major concern as Iāve already pointed out.
Thatās news to me! Though even aside of that large influx (curious what drove that), itās not an insignificant number of users, and donāt see the point.
Your point about new mapper funnel is really the most interesting to come of the entire policy discussion in my opinion. Tactically, I think we need to approach policy and user experience separately. And in the case of editors, I donāt think thereās any suggestion that we change the default action of the edit button for new users. I wouldnāt think that adding drop down options would change new user behavior much, and even with the current UI, thereās options to add explainer text that would suggest other editors are not the best first stop as a mapper.
Thereās so much else we could do to focus on conversion, and integration of mapping tools in the core experience. Separately from policy, Iād love for us to get creative about it.
1 Like
@eneerhut was protesting that I had pointed out in the context of issues created by specific editor users that Rapid has a low take up (~2% typically).
As Iām assuming that Facebook is asking for inclusion on openstreetmap.org to increase their market share, not lower it, it is relevant to the discussion of the new mapper funnel including messaging around editor usage.
As the numbers I posted showed it isnāt as simple as new mappers click on the edit tab and simply use the ādefaultā editor. Even after iD had been made the default there was roughly two years in which Potlatch still got 10% of signups. Which in itself is quite astonishing given that Flash was already rather dead at that point, I suppose that that could have been driven by browser issues, but weāll never know.
As a thought experiment: can we deal with 10% of all newbies using Rapid instead of iD?
PS: the current Rapid share of new users is ~0.5%
I think the discussion was specifically about putting quantitative numbers on an overly subjective assessment of the numbers. And of course, the entire point of being included here on the edit menu is increased exposure and usage.
In any case, the policy says āThe proposed editor must have been in active public use for a while and demonstrated its usefulness by attracting an active community of mappers.ā. I think itās good that this is not more prescriptive, and provides enough guidance for the OWG when they assess.
Thatās really interesting about Potlatch and new user sign ups. I think itās entirely a good idea to direct 100% of new users to iD, and open up other options for participation after someone has made an edit. My guess is that wouldnāt be a tough implementation. In general we should design the website with progressive exposure to different parts of OSM.
2 Likes
I went looking for a visualization and found this OpenStreetMap statistics site useful. Just sharing here for anyone else whoās interested. The monthly first edit by software graph shows that in a typical month a few dozen to a few hundred users make their first edit via Rapid, except in February 2023 where there was a huge spike.
This spike is so big that itās also visible in the monthly active user percentage graph. This shows that typically a little over 1% of monthly active users make edits with Rapid, but in February 2023 it was 12%.
Note: If youāre wondering why a line for iD is not visible in these screenshots itās because I cropped the plot area to zoom in on the minority editor lines that are hard to see on the full plot.
3 Likes
Mappers were likely using Potlatch 2 despite Flash at that point. For the first couple years, iD still had plenty of usability issues, especially around keyboard navigation, its presets and fields were still quite basic, and its performance was not at the level that mappers had come to expect from Potlatch 2. The problem was measurably worse in some popular browsers like Firefox and especially Internet Explorer. (Bet you didnāt expect to hear that name come up today.)
Rapid in a somewhat different spot these days. Parts of the application have been rewritten to perform significantly better than iD. Otherwise, it retains much of what mappers expect from iD, being a fork of it. On the other hand, some aspects like localization are still rougher around the edges, and lots of community members have formed opinions about Rapid without being regular users.
Apart from that, muscle memory would be a big factor dampening uptake. I think we may still have some very committed Merkaartor users.
1 Like
I was just curious what your thought process was. I take your point on the huge one-off spike distorting the 2023 stats for Rapid. I just find the comment āGiven that Rapid has nearly no user baseā an interesting comment given Rapidās June usage was 1.3% of editors which is where Vespucci was in March, 2018.
But to the heart of your argument, we have no interest in bad data going into OSM. The Rapid GH issues repo is open and we love feedback and ideas on what can be done to improve Rapid and OSM by extension.
I think an underlying tension for the community to navigate is the trade off between making it easier to contribute to OSM and ensuring edits are error free. Both are ideal, but if you optimized for the latter, you might do things like make people go through a 3 month training process before they can edit real data which would result in a far less people editing OSM and thus less data coming into OSM. I think this point is under appreciated when discussing new mappers, no matter which editing tool they use.
I donāt really see this tension @eneerhut. If anything, OSM possibly goes too far to optimize for making it easy to contribute. Anyone can sign up and start editing, immediately. There have been some limitations recently placed on new editors due to really difficult issues with vandalism, but those were very intentional and selective. I know I suggested that new users start off on iD and make one edit before trying all the other available tools, but I wouldnāt ever think that should be based off a required training program or such.
Where I think we have a lot of work to do is more systematically support new mappers as they edit. Perhaps thatās your point ā making it easier for people to get involved in all aspects of OSM.
1 Like
Yeah thatās exactly what I was getting at. Itās an exciting opportunity and something that all editors can do better at.
I was addressing a theme I have seen for a while of iD or Rapid being criticized for making it too easy for new mappers to come in and edit. You want to onboard them without scaring them away. Thatās where the tension can arise. Do you force them to map in a sandbox for months? Do you restrict what kind of edits they can make? Do you limit their access to open datasets to ensure they canāt add 100 buildings too quickly? Some of things might be good, but you donāt want a scenario where the number of people contributing drops because of too many guardrails.
1 Like