I propose to migrate sidewalk=none to sidewalk=no with an automated edit that I would perform.
It is a very minor improvement, but still removes one piece of annoyance for new data consumers and for anyone looking at raw tags.
Yes, it is a tiny change and nothing groundbreaking and having synonyms is not even in top 10 of annoyances for data consumers.
But such change is an improvement and easy to do.
The only cost is making edit itself which will cause objects to be edited.
Note that this change will not break any data consumers as it changes to a far more popular alternative.
It is far preferable to do it with automatic bot edit over doing it as a validator rule in editors or doing it manually as it is pointless to spend human effort or attention on such drudgey of changing several thousands tags manually, one at time.
In my experience objects with such tag are not useful identifications of bad tagging deserving human attention.
If anyone is interested in such useful detectors where human attention would be useful, let me know (with preferences for area and/or topic and/or editing type and other similar preferences if any).
Edit proposed here would be global and recurring, retagging also future occurrences of such tagging.
Note, I already performed such edit for limited geographic area where there was agreement from local community.
When I eradicated sidewalk=none from Greater London (not as an automated edit - weâve got very good aerial imagery), I found very few cases where sidewalk=none was a tagging error and couldnât be replaced with sidewalk=no.
To be clear, I am not claiming that there is 0% bad data ratio. Only that it is not high enough to be a decent detector and that I have endless parade of much better detectors of bad data, more than what can be processed by mappers.
So of sidewalk=none are going to be wrong. But retagging them, according to my tests, does not hide useful signal and human attention can be much more usefully spend on other things.
I fully support this proposed edit. Thank you for working on this!
While we (TCAT and PWG) strongly prefer the âsidednessâ sidewalk tagging (sidewalk:<side>=*) schema, I am familiar enough with editing these tags to know that, unfortunately, sidewalk=no|none does not always mean that sidewalk:both=no is accurate - they are best reviewed individually. This proposed edit maintains that these are searchable for targeted improvements without introducing any bad data that wasnât already wrong or out of date.
What is Streetcomplete filling out on this quest these days⊠sidewalk=no none yes, does it qualify if only at left or right with the proper sidewalk:side=*?
Personally, if at all make it sidewalk:both=no to promote future edit tagging with the approved proper schema should a sidewalk get added to a way as lane or separate.
No. If then intention was to actually improve the quality of OSM data then it would make sense to look at these oddities rather than just replacing âfairly common valueâ with âeven more common value that means the same thingâ.
With a data consumer hat on I already look at both values and will need to continue to look at both values, because someone will surely start adding sidewalk=none again, because it is a more natural English form of words.
A previous attempt to tidy the landmark key lasted a week, and that change makes far more sense than this - the old page was pretty muddled, and the old usage of landmark basically meant âseamarkâ(!). (tagging list thread). I expect none to reappear as a value pretty soon (months, not years) after any automated edit.
Where I am a linear roads have two, and saying that âthere is no sidewalkâ is exactly the same as âthere is no sidewalk on the left AND there is no sidewalk on the rightâ. Currently this âis there a sidewalk logicâ has expanded from âis there a value that is not no or noneâ to the current 40-line monstrosity.
probably no, but such objects will be skipped in the edit (or more specifically only ones with valid highway values will be retagged, and not even all valid highway values)
you will be happy to hear that such suspicious objects will be in fact NOT retagged (like they were not retagged in Poland where I run such edit)
So youâre not investigating and fixing the actual problems; just changing some other tags (both with the same obvious meaning) instead
There are some things in OSM that had genuine values, like, er, building=yesdiarrhea - it absolutely does make sense to set those to something sensible. The âlong tailâ of the building type list has lots of semicolons in it, the vast majority a testament to someone who doesnât really understand how multipolygons work - search for âroofâ and youâll find mostly relations where someoneâs merged a filling station roof and shop together without understanding the impact. Whatâs needed in each of those cases is a conversation with each of those mappers explaining whatâs happened, and what might be a better approach.
(Iâve fixed a few and have tried to engage a few of the previous mappers)
It is possible to search for reappearances of tags that have been removed from the database with an Overpass query and I have regularly checked for several ones that can be fixed remotely to do so. Unfortunately my lightning talk at State of the Map Europe 2023 when I talked about this wasnÊŒt recorded.
aliases with exactly the same meaning are a tiny and minor problem - but still a problem and easily fixable one
I can easily list 50 and probably could list 256, maybe 1000 more important problems in OSM, but each of them is also proportionally harder to fix for me. Otherwise I would switch to doing something else.
To be more exact, for some I am actually doing something - but benefit/effort ratio of doing more work there is comparable to doing this one, in my estimate, for me, as far as I know. Someone else may for example be in much better position to fix broken Bing in JOSM than me - and doing it would be tremendously useful. But I do not have contact in Microsoft, so my ability to contribute there are much smaller. I could, I guess, try to ask someone else to look into this.
(this should not be a reason to flatten and bulldoze and retag stuff just because it is maybe an alias, but in this case I think that it is quite clear that meaning is 100% the same)
And for more manual investigations - I am also doing this, for example recently I am fixing amenity=fixme directly or contacting mappers when situation is unclear to clean this debris caused by curious Every Door behaviour
The opposite would make more sense to me, but I would still argue that such a change is irrelevant. There is nothing simpler for applications then processing a second value with the same meaning, not more complex then value == "no" || "none".
I agrre with @Mateusz_Konieczny. The fact that other problems are bigger is not an argument against fixing small problems. You found something in the data that is currently complexer than it could (and should) be and you are proposing simplification for that. Please execute that mass-edit.
Everyone who knows bigger problems and has solutions for them can go for that. But that shouldnât stop anyone from giving attention to the minor problems.
values, like, er, 