OpenStreetMap logo OpenStreetMap

In order for OpenStreetMap to thrive, we need to attract and retain new mappers. To be welcoming to newcomers, we should avoid high barriers to starting mapping and instead support contributions that can be made with limited time, context, and experience. StreetComplete is a great example of this approach: by asking simple, well-scoped questions, it enables contributors to improve data quality in small, incremental steps. An effort-inclusive tagging philosophy builds on this idea by encouraging tagging schemas where each additional piece of information can be added independently and still be useful on its own. For example, amenity=bench is still a bench regardless if mapper knew about backrest=* and armrest=*.

I am writing this because I have encountered cases where newcomers are advised to follow practices that I consider unnecessarily demanding for basic contributions. A particularly stark example appears in the context of CCTV and ALPR mapping, where a sub-community recommends mappers to take high-resolution photographs, research manufacturers and exact models at home, and consult product datasheets for adding a single camera to OSM. While such detailed work can be valuable, it not only risks discouraging participation, but also makes incorrect data harder to detect if mapper misidentifies the model.

Advanced mapping techniques such as per-lane destination tagging or 3D mapping are entirely appropriate in contexts where that level of detail is the goal. The problem arises when tagging schemas or community conventions require large changes or trolltag-esque top-level tag replacement in order to express additional information. A common example is waste baskets that support sorting: in order to describe what kind of waste is collected, some tagging convention implies to replace amenity=waste_basket with amenity=recycling, rather than incrementally enrich the existing object. Tagging practices like this make small improvements harder and counter an effort-inclusive, iterative approach to improving OSM data.

Discussion

Comment from pussreboots on 17 January 2026 at 00:30

Unfortunately Street Complete is only on Android. So we’ve already alienated a large portion of potential mappers if Street Complete is supposed to be the entry point to OSM.

Comment from SimonPoole on 17 January 2026 at 11:45

Some wild assumptions here it seems, facts are:

  • Apple has ~20% of the global phone market, the other 80% are essentially all Android phones. Now while you can argue that iPhones are more common in affluent parts of society that are more likely to map, that doesn’t turn things upside down. BTW Go Map!! has had quest support for a long time.
  • SC is the starting point for ~5% of new mappers, about half of what starts OSM with Organic Maps/Comaps. From a mapper retention pov, long term it is no better than iD (which is what most mappers start with). Historically it has been worse however that would need some new numbers to see if that is still the case. What is true is that very short term SC users edit a bit more, a possibly reason for this is that iD users as a tendency want to specifically fix something and then stop when that task has been done, SC users on the other hand are likely to at least play a couple of quests before they decide that it is something they like or not.
  • As a rule OSM lives from incremental improvement and that has always been the case, while there might be some communities that require every addition to be perfectly complete, I have yet to come across one, in any case that doesn’t depend on the tool you are using.

Comment from pussreboots on 17 January 2026 at 17:26

In the U.S. (and I know we’re currently a fascist hell hole) the usage is 58%. There are also HUGE areas — even urban areas — of the US map that aren’t mapped. Having Map Complete available on iOS might make that easier.

Nice way to be all welcoming and inclusive in your rude reply.

Comment from SimonPoole on 17 January 2026 at 17:40

MapComplete is a web app and available on iOS (and arguably a better choice than SC when ‘nothing’ has been mapped).

Comment from fghj753 on 17 January 2026 at 20:59

StreetComplete was listed as well-known example, MapComplete could serve as sample as well, I’ve never used GoMap nor CoMap to form an opinion on them. Point i tried to make was irrelevant to specific editor, but highlight those applications positively as they focus on features/presets where map data can be improved in small steps.

As a rule OSM lives from incremental improvement and that has always been the case

After giving the topic more thought, I wholly agree with Simon here. I couldn’t really come up with clear counter-examples of problematic tagging conventions or presets. My personal grievance concerns the recycling:* tags because even adding a single yes-tag from the namespace impliesno values for all other imaginable tags, but as far as tagging convention is concerned, it actually has really solid structure.

Maybe the initial idea could be rephrased as “Partial data has to be better than no data” and instead of blaming tagging, it should have highlighted that useful data can be contributed with any level of effort - from just a few taps on a phone to global tagging cleanup campaign.

Comment from Minh Nguyen on 19 January 2026 at 04:17

StreetComplete’s maintainers have done a good job of reminding us to adhere to the Unix philosophy (every key does one job well). Everyone wants a StreetComplete quest for their pet tagging scheme, so there’s a good incentive to follow that principle these days. This benefits other preset-centric editors too.

The problems you’re noticing are probably concentrated in older tagging schemes that first arose when most mappers were managing raw tags manually, so brevity was more important than modularity. The community is slowly evolving those tagging schemes as the need arises. The most prominent example of that is probably crossing=*.

The surveillance tagging scheme is pretty old too, but I’m surprised to see it come up as an example of monolithic tagging. For the longest time, we’ve just mapped man_made=surveillance and a few other keys for those who bother. Simple tagging is still possible if you’re using a mainstream editor. If you’re using something like DeFlock, then by all means they can get down in the weeds, just like the specialized editors for street parking, bus routes, and trees. That’s kind of the point of keeping those editors separate.

Comment from steveman1123 on 23 January 2026 at 01:51

Another major issue I come across is that the data is simply not present to improve in the first place. One way I’d really love to see this (and a host of other issues including OSM awareness, data quality, and user agency) be addressed is with streamers on Twitch (et al).
Someone who’s got a better setup than I do could easily start a stream and map viewer requested areas. You’d drum up awareness by having someone map (and potentially get paid for it!), show others how the process is done, available editors, why they should care, and encourage others to get on the platform

While I agree StreetComplete is a decent starting point for newbs, I think we should also look to other avenues that may be more passive, a la twitch streams and youtube tutorials to give people ideas of how to actually do what they want to (describe parts of the ID editor, how to set up JOSM, change goals on StreetComplete or MapRoulette, etc) in easily digestible formats so they aren’t apprehensive about making changes to something that’s visible globally

I think we also need to add a reason why people should care about adding detailed data (like whether a bench has a backrest). Right now the only tool I know of that can make use of that kind of info is the Overpass QL, which is awesome, but not exactly user friendly. I’d love to see some kind of tool that a 4 year old could get the answer to “where’s the nearest ice cream shop that’s close to a toy store” - those kinds of answers would give people reasons to contribute

Log in to leave a comment