Just for reference Support android intent uri for JOSM style remote control by simonpoole · Pull Request #1478 · openstreetmap/openstreetmap-website · GitHub old and url handling has changed a bit in the mean time on Android.
But the core issues remain URI schema to use, iOS support, error handling (one aspect of which would be offering to install an app).
In any case I consider the question of mobile to be a diversion from the actual topic which is including RapiD.
I doubt it: publish preview version on talk mailing list/forum/etc, enough mappers try it out, becomes eligible
+1, both are serious concerns that should be resolved
if policy is effectively about Rapid then it makes sense to focus on Rapid-specific issues rather than try to handle unlikely and theoretical appearance of new desktop editor while ignoring issues specific to actually relevant editor.
@Firefishy Given that one of major Rapid-iD differences is its usage as import tool: have you consulted LWG and DWG on this topic? Both seem relevant for topic of imports and in large part effectively bypassing https://wiki.openstreetmap.org/wiki/Import/Guidelines
Are you suggesting added LWG + DWG check to the policy?
It seems like a good idea to me to require green light from them.
It would add even more workload for them, but this will be really rare event and preventing potential problems seems a good idea here.
There’s a border line case to be made for full editing mobile apps that maintaining the classical “zoom to a location - edit that location” workflow makes sense (barely).
I don’t see that for the vast majority of speciality apps, which typically will want to edit a specific object and they can already do that by catching the corresponding URLs (there’s a whole discussion to had around that see Feature request: catch openstreetmap.org node and other links · Issue #844 · MarcusWolschon/osmeditor4android · GitHub for example).
That works only when user installed app already, right?
So potential new mappers would end opening Google Maps.
I’d think that this policy is general enough and flexible enough to cover both, but agree that asking the other working groups to review makes sense if there are concerns. If the issue is over data imports, I feel like discussions about RapiD’s data import mechanisms are well covered by the following item in the proposed policy, while being flexible enough to handle other cases.
I also remain confused - I understand that people are concerned about further approving of something they may disagree with, but the horses are out of the stable, so to speak. In my area, a large volume of the edits that add content come from RapiD already. If people are concerned, I think the discussion should be broader. Otherwise, I personally think this policy looks good and covers the important elements - namely OSM data quality and licensing. While I think RapiD would conform to it, if it doesn’t, then I think the policy already would limit inclusion based on established rules. Calling out RapiD explicitly makes this policy less useful, IMO, even if there are no other editors on deck on desktop.
I think @westnordost is referring to the fact that Rapid has already been rewritten to be more performant than iD. Some mappers have been choosing Rapid over iD when mapping in dense areas, even without ever touching the features related to external sources.
They’ve also introduced a 3D building preview and other features that haven’t worked their way back to mainline iD.
I think any kind of external app/software should be treated similar like it’s done with jOSM.
My point was more related to web-based editors, like Relatify (wiki). I see no reason, that such an editor is not allowed, just because its targeting a special part of OSM. For me, listing such kind of special editors is more beneficial than listing 10 editors doing the same thing.
Might be, that the term “general purpose” is targeting something else, if so it seems that term need to be explained better.
Does this suppose to mean, the editor must offer English and better should offer more languages? I’m asking because I think English should be a must have, but it’s not clearly required.
An editor available e.g., in Mandarin and Cantonese only would fulfill above requirement. But is this somehow useful for the OSM?
That is “already the case” aka any app that implements the required subset of the JOSM RC API can already be started that way on at least Linux and Windows (I kind of assume it works on macOS too, but can’t check). The only thing slightly confusing is the menu label…
The situation with mobile is slightly more complicated, but there is no reason that the same/similar thing can’t be done there (as my prototype showed).
To call it an editor inclusion policy and then have a criterion that says only desktop editors can be considered makes it sound like mobile editors have no chance of ever being included. If this isn’t what the policy is about, then may I suggest calling it the “Desktop Editor Inclusion Policy”? That would make it clear that mobile editors are out of the scope of the policy.
OK OK, I should have written
In any case I consider the question of mobile and other editors to be a diversion from the actual topic which is including RapiD.
I think the opposite is the case. There are web-based editors and they need a dedicated link to be reachable from OSM-website and the policy is about which requirements such kind of editor have to fulfill.
All Android and iOS apps as well as editors running as dedicated software on Windows, Linux, macOS should share one entry “external Editor”. That link might change depending on which OS you are currently using, if this is required du to OS limitations. It would be up to the user to take care of the rest. Like if I want to address jOSM, I have to start jOSM first.
It wasn’t explicitly said in the policy but currently I don’t think third party sites are under consideration, just apps that can be deployed as vendor assets from the rails app. Adding links to 3rd party sites would have to have a quite a long list of additional considerations because of the associated risks.
By permissive, do you mean a non-copyleft license such as BSD, MIT or Apache as described in this article?
JOSM for example is released on a GPL license, which is not permissive. Why make a rejection criteria for copyleft licenses?
It might be, that there are currently no such editors under consideration. But the policy is about all editors. If it’s meant to be only targeting some of the editors or even just a specific one, this should be made clear. 
IMO we should make more clear the scope the editor should have.
Without context I would have interpreted “desktop GUI map editor” as only native desktop applications (for example: JOSM yes, iD no).
Based on your comment I understand that also web apps are included. I guess “desktop” meant all apps designed for usage from desktop. If so, I think we should replace
The proposed editor must be a general purpose desktop GUI map editor aimed at a broad audience of (potential) mappers.
with something like
The proposed editor must be a general purpose GUI map editor aimed at a broad audience of (potential) mappers. The editor can be native or web-based and must be usable from desktop.
.
But if this is the case, I agree with the comments above about the fact that it would be ideal to allow the inclusion also of mobile editor: IMHO the addition of a quick link to a mobile editor is long overdue, given that the majority of people browses from mobile we are missing an enormous amount of potential editors by not having it.
Another aspect that has been quickly cited but should also be included is the linkability. It should be clear which of the available linking methods are supported:
geo: URI schemahttp: URLs to the web versionhttp: URLs to the app through Android app links or equivalent systemsIt would be ideal to support all methods above, but while in theory the first 4 are pretty easy to implement on our side, I imagine that the last one would require quite some more work to implement. Because of this I think it’s better to allow new editors only with the first methods. That section could look like this:
The proposed editor must be a general purpose GUI map editor aimed at a broad audience of (potential) mappers. The editor can be native or web-based and must be reachable through an HTTP URL or a custom URI.
(proposal)
Additionally, it is recommended that translations and their improvements be updated on a monthly basis to avoid mislabeling due to incorrect translations.
Regarding the OpenStreetMap iD editor, the latest release available
at OpenStreetMap ID Tagging Schema was on 2023 August 16.
Consequently, the production version of the iD editor does not include the most recent translations and their fixes.
This is particularly important for non-English speaking communities to ensure that errors stemming from translation mistakes are addressed as soon as possible.
Specifically, there is an error in the Hungarian translation that leads to incorrect tagging, which has been corrected for some time now.