Proposal - Editor Inclusion Policy

I mentioned this earlier, but here again. You don’t want to be supporting random links to off site services because you don’t control them and misuse is guaranteed, not to mention the support load when something doesn’t work. We already support geo: URIs via the share tab, you probably don’t want to do that via the edit button, because as has already been pointed out, this will start google maps on mobile devices per default.

What is OK is:

  • web apps that can be distributed from the OSM website (as iD is currently and potentially RapiD could be), that gives us control over any changes in behaviour. Imagine for example that RapiD would start submitting changes to google in parallel, if we just link to the Facebook site we might not even know that that is happening.
  • apps that the contributor has installed themselves and is responsible for the behaviour, this covers everything started via JOSM RC (or other similar mechanisms if they were developed).

As to the missing out on massive numbers of mappers because they browse on mobile*, what about a far simpler solution then anything that has been proposed here: have the edit button (would have to be visible in the mobile layout which it isn’t currently) open a page with information about editing and potential solutions on mobile (the downside of that is that the OSMF will have to deal with all the related Fanboism).

* I’m not convinced that that is actually a thing.


This would be nice for making the editors more discoverable to newcomers. However, for regulars, it’d still be awkward without some kind of button that takes you to a particular coordinate in the editor. There are probably many Go Map!! users who browse the map using something other than Go Map!!, as this editor is a bit too heavyweight for browsing. If they use the OSM website rather than a second dedicated application such as Organic Maps, then they’ll end up having to copy-paste the URL hash or do something similarly tedious to navigate to the same location in the editor. Maybe for these users, it would be enough to implement some link that only shows to logged-in users, perhaps tied to the user’s editor preference.


Because general map applications will be unable to make sense of an edit link, which may only have an OSM ID, it sounds like we need a different URI schema. Reading the geo rfc all it can do is points in 2d, 3d, and with uncertainty, in different CRSes, so we do need something else.


The if is the bit that needs to be quantified, as I said I’m not totally convinced that that is a workflow that is really common enough to be worth supporting.

We already have that (see Controlling Vespucci from other apps - Vespucci if you don’t want to advertise for JOSM, then rename the schema, but otherwise, this exists and works).

1 Like

This seems a little weak. A privacy policy that says “We record any, and all, PII and we can sell it to whoever we want” would meet the requirement to publish “how PII is handled” :rofl:

How about adding: “… and that Privacy Policy must be broadly similar in spirit to progressive privacy laws like the GDPR” ?


…and then the decision-makers can choose to allow or disallow that editor based on their privacy policy.


If the above are true, than I wonder if we aren’t all wasting our time. Do we expect the Rapid devs to want this?

This appears to be the case:

Draft Ops policy for adding editor to Edit Button Dropdown · Issue #877 · openstreetmap/operations · GitHub

Hello- Ben Clark commenting here on behalf of the Rapid team at Meta to confirm our support for the inclusion of Rapid Editor on We have been waiting for the community to develop consensus about the inclusion criteria, but we are confident we can meet both the hard and soft criteria as they are proposed currently.


I think niche editors are totally fine, as long as they meet the other requirements.

So an editor first needs to gain popularity to be included, but they need to be included to gain popularity in the first place. That doesn’t really work unless we force people to make a lot of publicity for their editor. And how many upvotes would be sufficient? Or do we send out a OSMF-wide survey every now and then to get maximum community consensus?

I think this idea should be reformulated.

Maybe a testing period where only a few mappers / OSM admins can use the new editor to evaluate it, and then a green light from them to open it up to the whole community ?

If that means we drop support for editors when maintenance stops, even while current versions are stable and well-liked, I think we risk losing valuable editors in the long term.

Why? It just has to work properly, right? Why do we care about uniqueness?

This may be off-topic, but would it work to show a “edit in this or that mobile app” button on mobile devices?

Other than that, maybe we could say “the editor should be freely (gratis) available to all mappers” (or something along those lines). We probably wouldn’t want to have paid premium (versions of) editors, or editors that are exclusively available to a group of (corporate?) mappers.

That should then probably be mentioned explicitly in the inclusion policy.


Also, can’t we make inclusion in the drop-down list an opt-in feature? So people can go to the settings on, select Rapid or any other (approved) editor and have it added to their list that way. And then only JOSM and iD remain the standard editors that are shown by default.


I think there should be some degree of curation, otherwise we’ll end up with a long list that’ll be confusing & overwhelming to newbies?


Fair point. For the same reason niche editors should probably be excluded as well. But maybe the opt-in idea could work?

At least: to avoid situation where anyone can fork iD/JOSM/etc, make minor changes and request inclusion


The question is really do they actually support including the editor as vendor assets (and not simply a link to a Facebook controlled site)?

And I would note that the elephant in the room, aka control over 3rd party sources provided in the editor, still hasn’t been addressed. To short cut the unavoidable whataboutism: the imagery layers provided in iD via the editor-layer-index undergo fairly rigorous vetting by both the maintainers and the community at large, definitely enough that the residual risks are small enough to provide the data as an official OSMF service.


The thing is that pressing “Edit” on the website is mainly something that, outside of actual iD users, beginners use (I literally use it once per year on January 1st for actual mapping).

You can’t just have a list of recommended editing apps without providing the potential 1st time on the site person some kind of decision making support and the longer the list and the more specialized the app the more difficult that is going to be (it doesn’t even really work with the 2 (two) entries we have currently). And the added dimension of mobile platform compatibility is not going to make anything easier.


As someone who rarely touches iD and maps mainly with JOSM, I use it quite frequently when I look at and happen to find something that I want to edit with JOSM. The remote control is a most helpful tool. It would be nice to see this functionality being extended to other editors, like Vespucci on Android (if that’s feasible, I’m not a tech wizard). So IMO this policy would have implications beyond just Rapid.

1 Like

Yes, we are happy to provide the Rapid code in whatever format @TomH and @Firefishy wants it in. Vendored assets are fine.