OpenStreetMap
2021 editor usage stats - some interesting parts
Posted by Mateusz Konieczny on 6 January 2022 in English.https://wiki.openstreetmap.org/wiki/Editor_usage_stats has some interesting parts for 2021
- iD use continues to increase by percent (both edited objects and distinct users)
- iD by number of distinct users dropped from all-time-height in 2021
- end of lockdowns? OSM slowing down? 2018 to 2019 also dropped, this year JOSM edit volume went from 996 million to 905 million edits
- JOSM still used for over 50% of all contributed edits by objects
- StreetComplete is the second most popular editor (by number of distinct users), usage almost doubled
- StreetComplete is still almost not noticeable by edited object volume - 0.8%
- but last year it was 0.3%, it tripled to 12 million edits
- failed import and its revert is the second most popular editor, by count of edited objects
- 1.5% of all edits in 2021
- https://forum.openstreetmap.org/viewtopic.php?pid=760818#p760818 is an example of what was imported
- new editors: Organic Maps
- ok, “new” as it is MAPS.ME fork
- and that failed Finland forest import
- MAPS.ME continues to die, also as an OSM editor
Discussion
Comment from TrevorPumpkin on 6 January 2022 at 04:45
Street Complete is a great way for beginners/casual users to contribute, and a good reason to explore your local area.
I hope it continues to grow.
Comment from G1asshouse on 9 January 2022 at 13:43
“StreetComplete is still almost not noticeable by edited object volume” Oh, I notice it. My area has lost work because of a bug. It dumps “legitimate” tagging bloat. It simplifies complicated situations which masks places that haven’t actually been accurately mapped. Sadly, it has gone the way of ID in both data mutilation and in cult-like defense. Such a shame, too. It is a fantastic idea that has long ago ballooned into a data bloat and quality destruction tool. Some time ago, I recall seeing push back on a feature request to add a “backrest” quest for benches. I can’t think of how that quest could go wrong but I appreciated seeing the defense of the database’s quality and accuracy. I miss those days.
That’s enough of the negative. Thank you for putting this together. Just the other day I was looking for each editor’s usage percentage. So, you’ve answered a question I had. I am surprised that StreetComplete does not look to have stolen any users form ID or JOSM. I am also surprised that OsmAnd (my favorite navigation app) is a source of more edits than Vespucci. Vespucci is a solid app and deserves far more love.
Comment from Mateusz Konieczny on 9 January 2022 at 14:29
Can you be more specific? There were some known data-damaging bugs but affected versions were blocked and all affected data was repaired.
Also here, can you be more specific? I am not sure is it complaining about deleting tags or about adding tags.
For which types of answers?
Is it case of mappers answering incorrectly?
Comment from Mateusz Konieczny on 9 January 2022 at 14:31
OsmAnd has more users. Vespucci mappers has about 15 times more edits (by volume of edited objects which in this case should be comparable).
Comment from G1asshouse on 11 January 2022 at 13:05
Some examples of “legitimate” bloat tags. I understand that these are subjective. ) “opening_hours:signed=” appears to have been created by you as a placeholder key and it only benefits Street Complete. Flags on data that are used for quality of life improvements in the app should be solved in the app. Regardless of my opinion, I am not going to fight over this. That’s 17,000 tags of SC using OSM’s database to store it’s data flags. *) “crossing:island=no” is a value that can assumed to be “no” instead of needing to apply it to every known crossing in OSM. I believe, I saw a post which says SC limits what types of streets it will place this tag on. I’m sure that helps but why is it placed at all? 353,000 (70%) unnecessary tags. The same thing applies to other tags like “tactile_paving=no”. Again, I don’t care enough to fight over it. check_date / survey:date / last_checked / etc. are all bloat tags. At best, they belong in “note” but I (and many others) don’t feel that the tags/note belongs in the database at all. It’s 1.4 million unnecessary tags.
“all affected data was repaired” I believe you folks made a solid attempt. Regardless, I have fixed and continue to fix some of these SC errors. As you know, SC v28.0 had an error with crossing/kerb tags. If it was a larger problem I would not know. I only noticed that it would remove all tags on barrier=kerb / tactile_paving=* nodes. I just noticed this error from SC v38.2. Changeset 115319560 (SC v38.1) added tactile_paving=yes to crossing node on 2021-Dec-23 [Node: 4291702901]. Nodes at each end of the footway=crossing have had tactile_paving=yes since 2017-Feb-26 [Way: 436979377] [Node: 4694343209] [Node: 4707439042]. Therefore, we now have double tagging and the crossing node should not have had the tactile_paving=* tag added. Not a huge deal but it can be frustrating. I have come across other issues from time to time but the crossing/kerb tags being deleted was the worst one that affected me. I would include more variety in errors but I can’t recall which nodes or ways had the other issues. Normally, the issues are minor so either I fix it or I ignore it and move on.
“mappers answering incorrectly” that can always be a frustration but we all make mistakes. I have seen folks, that have been mapping since 2008, make simple errors. I don’t blame SC for that type of issue.
“complicated situations” surface=* - Long ways that cross different surfaces (example: asphalt → paving stones → asphalt). It will get tagged with “asphalt” leaving the middle segment tagged wrong. I know that SC can do some edits like splitting a way. roof:shape=* on non-flat roofs. Roof shapes are often complicated and tagging a simple building outline results in a simple roof shape. Often, what should happen is a complicated building needs to be redrawn with building:part=* and each building:part=* gets the appropriate roof:shape=* tag. I’m sure there are plenty of better examples but my statement is more about the general idea that StreetComplete has expanded to include tags that are more complicated to add than they appear to be at first.
I just get frustrated with these issues from time to time but these are small problems. I love the idea of StreetComplete. I enjoy the look and feel of StreetComplete. I’m ok with the function of StreetComplete. I hate how well-meaning fans of the app keep pushing it to do more and to do everything. StreetComplete filled a great need. A very easy to use program that is error proof in adding tags. That is my opinion.
Mateusz Konieczny, I want to say, I appreciate how you handle criticism. I know you work on the wiki pages. It looks like on 2021-Feb-07 Victor.yarema incorrectly added “crossing=” node only tags as appropriate way tags (ID also has this error). I see “crossing=traffic_signals” and “crossing=marked”, “crossing_ref=zebra” added to the first two examples. Node: highway=crossing + crossing= Way: highway=footway/path/* + footway/*=crossing https://wiki.openstreetmap.org/w/index.php?title=Tag:footway%3Dcrossing&oldid=2106935
Comment from Mateusz Konieczny on 12 January 2022 at 17:00
@Adamant1 Yes! In fact processing all changesets ever made is relatively easy.
One of my current project is making analysis like this - to show lifetime of many users at all in a graphical form. I am curious who is using SC - new people? New people who become more involved - or stay on SC forever? People mapping already?
Not sure when I will do this but I can link some code processing this data if anyone wants.
Comment from Mateusz Konieczny on 16 January 2022 at 13:26
@G1asshouse Thanks for answering! I will see what can be improved.
I will answer to the entire comment, but I will do it bit by bit because it is a bit overwhelming.
Do you have any idea is it caused by mapper not caring about data quality? Or by someone unaware that splitting is even available?
Or maybe it was happening before splitting tool become available?
Either of this things would require a different action: either making split more prominent in the interface, or educate people that it exists, or maybe introduce even a special message shown to people who made many edits without using split tool. Links to changesets would be welcome - I can try contacting this mappers and asking them what went wrong.
roof:shape was recently disabled by default (partially for that reason, partially due to poor effort/effect ratio).
Maybe limiting to people interested in roof mapping was enough? Let me know if that step was insufficient.
I would rather say that everything is more complicated than expected. In other words reality is unexpectedly complex.
Comment from Mateusz Konieczny on 16 January 2022 at 13:56
I admit that I started using it when I was mapping with SC and from start planned to use it in SC, but I wanted something like this earlier - to skip places not bothering with signing opening hours.
In my defense I can say that I consulted it with tagging mailing list - if there would be some consensus that it is a bad idea I would drop that idea.
Though I agree that it is subjective, close/borderline case and I can see why someone may be against this tag.
I guess that sidewalk=no, cycleway:both=no, noname=yes, lit=no also belong here.
Here I guess that it depends on whether and when someone considers as acceptable to record “this place was surveyed to check for XYZ and it was not found”.
Either way thanks for sharing this position! I am not rushing to delete all quests that use this tagging, but it is useful to know what is making people unhappy.
Hmm. Can you link some affected objects? It is not on the list of banned versions ( https://westnordost.de/streetcomplete/banned_versions.txt ) so if there was data damage it could be missed. See
Yes, this is kind of duplication - but it is more of a tagging schema issue than SC-specific issue (at least in my opinion).
If you see it again, and it is not working as intended - please make report at https://github.com/streetcomplete/StreetComplete/issues/new/choose
I do not remember this being reported.
And crossing ques has no “does not exist” option that would delete it, only leaving notes. As it is too complex to handle by SC.
No idea what is going on, if anyone spots this happening - please report it as a bug.
(maybe it is not a bug, but it sounds like a bug to me)
Thanks, this is nice to hear! Hopefully I have not changed your opinion by this answers.
Comment from Hungerburg on 16 January 2022 at 22:36
StreetComplete is a very valuable tool to enter immediate observations on the ground. Still, please do no oversimplify use cases:
Tagging a residential road sidewalk=no gives valuable information, while on a motorway it is redundant. cycleway:both=no a bit less so, because a cycleway is not so common as a sidewalk. Such issues are best handled on the SC tracker. Some heuristics may need some polish.
SC needs to grow user base a lot, if it was to replace work done on the desktop. Please think twice before gamification - something that applies to desktop editors just the same - ticking off validator suggestions blindly should not give users Bonus points.
Comment from Mateusz Konieczny on 17 January 2022 at 07:56
It is definitely not intended or planned future.
It is intended to be used especially for tasks requiring survey on the ground and updating many objects, likely it will never be great in mapping buildings, landuse, road geometries, waterway geometries.
It is also intended to give people ability to contribute with low effort.
It is intended to supplement JOSM, not to replace it.