I would assume, the default will remains iD, though every user can change his default.
I disagree with this. Discourse can do collapsible sections.
And TBH it wasnât that much scrolling anyway by the standards of this forum.
3 Likes
Thanks for posting the data. I found it interesting and wasnât burdened by the hardship of a bit of scrolling. Glad I was still able to see the content despite the post being deleted.
1 Like
Fair enough, though it wasnât placed into a collapsible section. Simon is human, like the rest of us. And the graph (visually) spoke âa thousand words,â though, please donât quote me thatâs an exact number.
Every day, we are people who speak to one another with respect and the belief that all others are earnest in their presentation of their best. Iâll say Thank You once again to all here who do present their best. (And Simon is an outstanding, top-notch example of âoneâs best,â another âawesomeâ in our midst).
Much of what we do here and now, it seems to me, is smooth over potential future misunderstandings. Thatâs good communication. How we steer our pipeline from new user to more-likely-to-be-engaged mapper, thatâs deep, but effective as we manage it. So, good for us.
Can I interest you in a discussion about abandoned railways?
6 Likes
Every time someone brings up that topic I will remove more long-gone railways from OSM.
1 Like
Thank you for the detailed response; I wasnât expecting the data to be that handy. I agree that Potlatch usage in the latter years is mainly the story of Flashâs demise. Itâs too bad Shumway didnât progress beyond being able to load Potlatch 2âs splash screen, though I hold out some hope for Ruffle. The usage rate shortly after iD replaced Potlatch 2 as the default is more interesting. It gives a very rough sense of how much impact weâre likely to see from the outset from a new editor admitted under the proposed policy. From the looks of it, the impact would be nontrivial but still not overwhelming.
The relative quality of each editor would matter too. In the early days, iD still had many basic usability gaps compared to Potlatch 2 or even Potlatch 1, such as keyboard navigation. Even though I quickly switched to iD as my primary editor, I appreciated having continued access to Potlatch for years. On the other side of the data pipeline, I think having built-in access to multiple renderers and multiple routing engines has been very healthy for community discussions around tagging and other mapping practices, and for those software projectsâ developers. It keeps us all honest. We kind of have that with the choice between iD and JOSM, but it isnât the same because, ya know, not everyone has access to a three-button mouse all the time.
Weâre here because the OWG apparently wanted to lay out ground rules instead of curating the menu by fiat (also known as developer discretion). Both approaches have merit, and both are fraught. The proposal is clearly modeled on the featured tile layer policy. A prospective tile layerâs developer can think they satisfy the letter of the law but still get held up by all sorts of concerns they never anticipated. When that happens, it reflects poorly on our project, as though we donât really know what we want (but whatever we want, itâs not that).
For better or worse, this kind of âvoluntaryâ happens all the time in the real world:
Honestly Iâm surprised this is the source of unease. Such a close reading of the SDRPâs mandate would call attention to the fact that the panelists are still serving out their original terms of office, which were originally meant to be much shorter but which have been extended. We arenât exactly worn out from our burgeoning docket, but thatâs something the board would probably need to affirm its support for if the panel takes on a greater role.
2 Likes
Is this Featured Tile Layer policy a draft or actually in use ?
This seems to be the main issue. OpenStreetMap is such a huge ecosystem with tons of softwareâboth open-source and commercialâand plenty of success stories. But when someone new visits openstreetmap.org, they only see the âstandardâ editor, map, and a few other styles including some unmaintained ones like OpenTopoMap.
A lot of OSM end-users donât even know where their application data comes from or what OpenStreetMap is all about.
It makes sense that the community wants to show off these great tools, but the process for featuring them seems pretty complicated and slow. Whether itâs politics or fear of competition, it sometimes feels like OpenStreetMap isnât as open as it should be.
Maybe we should start by figuring out what the community really wants ?
1 Like
when I started mapping, PL wasnât a good option for my context because the internet connection was so slow and buggy that I drew features again which were already present but not yet loaded, and had to wait after every panning of the screen. I would assume that this could still be a problem today with iD on slow connections (although it is 2024 and slow connections are probably getting rarer, here for many people itâs 1GB now). Should we give a hint that for slow connections editors with an explicit data download action may be preferable?
I think mappers will figure that out pretty fast by themselves after theyâve spent several minutes waiting for a download to finish a couple of times.
That said, welcoming new users and giving them practical information in a bite-sized package is something we should be doing better, but which seems out of scope for the osm.org editor inclusion policy.
Yes, Ruffle is looking very promising. A cursory look at its compatibility chart suggests that the main missing APIs that would affect Potlatch are around the classes that pull down data from external URLs - things like LoaderInfo, Loader and URLLoader. Given the pace of development Iâm sure these will be addressed before too long.
(Thereâs also the possibility that Harmanâs AIR development might eventually get WebAssembly output.)
2 Likes
Thought Iâd help the discussion and the feedback collation process and provide a high level summary of relevant points and input.
- SDRP: Most active portion of the discussion. Is it appropriate to require, when SDRP indicates that it is opt-in and not a dependency for OSMF decisions (funding explicity)? Can the OSMF mandate in case of making decision on editor inclusion? If yes, would an update to SDRP be required?
- General Audience / Purpose: question on what âgeneral purposeâ means. Could this be editors focused on a special purpose, but still appropriate for a âgeneral audienceâ?
- Privacy Policy requirement: How does this align with the OSM website privacy policy?
- Intl: Minor wording suggestion: make it âEnglish and other langaugesâ.
- Clarify (para 2) that the criteria are the minimum to be accepted, and that the OSMF board still has the ultimate decision whether to accept or reject.
- Question on whether map data must solely be made to the OSM database, and that those changes must be made under the OSM licence and Contributor Terms. Or if possible for data to also be shared with another service (like OHM)?
- Suggestion that editors can not facilitate imports
2 Likes
I would frame this point a bit differently.
The bulk of this concern I suspect derives specifically from the Microsoft building footprints dataset which is easily available in Rapid. That dataset has been the subject of a number of controversies and DWG revert actions. Because of this, when people hear âRapidâ, many immediately think âlow quality1 building import,â and are often unaware of all the other performance and usability features that the editor has accumulated over the years.
I would also point out that JOSM also âfacilitates importsâ because itâs essentially a map editing power tool that can do things that arenât really possible in a web editor.
So I would rather say something like:
- Concern that new editors do not inappropriately lower barriers to importing. Such barriers are necessary to ensure community review and limit importing to users with higher technical proficiency.
1Whether or not the MS building footprint dataset is "low quality" or "good enough" is a matter of considerable debate and varies by location and quality of the imagery used to generate it.
9 Likes
âcan notâ is a bit hard. Itâs rather the editor should not increase the load to the DWG (and other quality-care-takers) by allowing âlow-qualityâ data to be imported easily.
Maybe incorporate as well the last point into that section.
At least it would fit to âthere might be further criteriaââŠ
2 Likes
Or even âEnglish and other languagesâ! 
As well as Microsoft buildings, there are datasets from Facbookâs AI detection.
Which brings us to a question: What if Facebook/Meta made a version of Rapid without the âAdd data from AIâ features? What would that look like? Personally I would find that much less objectionable.
As IIRC was pointed out at the beginning of this discussion, the problem is not with the technical ability to support the use of 3rd party data, it is that the data sets presented are not under community control in any meaningful fashion, but nonetheless by power of being presented in an officially sanctioned editor are assumed to be âgood to useâ*.
MS buildings is just one example for which a mapper using the data should be aware of is not just the quality caveats but that they are creating a long term legal dependency for the whole project on Microsoft.
But, re-iterating this yet another time, the real question is, is this supposed to be a convenience function for mappers that are already using an editor that isnât listed and doesnât support JOSM RC, or if not, how do we present the multiple options with associated messaging to new contributors? And related, how much control do we want to give away over the new contributor funnel?
* ah yes the another annoying thing is that it uses a proprietary protocol to do so.
1 Like
Isnât the question of âwhat happens when the edit button on osm.org is clickedâ different from 'the wiki is hard to find and it is even harder to find up to date information on the wealth of tools in the OSM ecosystem"?
The former is about on boarding new mappers, and to a lesser degree existing mapper convenience, and that is really the only reason there is even a drop down in the first place. If it was my call I would go as far as removing that except if the mapper in question has configured a default editor other than iD.
In the end we want to funnel new mappers to the editor with the best conversion rate (to engaged mappers) and that is hands down clearly iD.
2 Likes
I really donât understand the actual concern about the Microsoft footprint dataset or Facebook roads as an import, the Rapid editor only provide a hint, the mapper still need to review it with imagery and manually approve it. I have seen plenty of controversial building additions done on iD based on mis-aligned/outdated imagery (maproulette/hackaton). I have used Rapid and the hints provides in general a much higher quality than many changesets out there.
1 Like
The rate of dodgy building additions from new mappers is limited by the speed of tracing building. Even so I am still cleaning up 2017 traces that look more like a low poly game of asteroids than the underlying buildings. If the mappers stick around they usually get better, because it is a skill and they are practicing.
Import of dubious AI traces can occur at a far higher rate and donât have the opportunity to improve with practice. The only way to improve them is with skills new users havenât developed because they havenât used the actual edit tools just the âlooks like a building to meâ button.
My experience of using MapWithAI is that it is very rare to get a building that is OK as is and itâs often better to just run through the area with either the Building Tools or Mapathoner plugins to get a base and then improve with extrude than it is to adapt the AI buildings to something that actually resembles the shape of the building.
Are the traces from AI better than first time users without validation? Maybe. Are they better than a user that has been told to draw, square, tweak, and re-square? Probably not, and that latter option is usually one changeset comment (or warning message) away.
2 Likes