Overbodig foot=yes en sidewalk=none (door Potlatch?)

Het viel me op dat een gebruiker foot=yes en sidewalk=none gebruikte in combinatie met highway=footway, en dat in een natuurgebied. Ik heb hem hierop gewezen en wel reactie gekregen maar het werd niet gecorrigeerd. Dat heb ik dan zelf gedaan. Nu zie ik dat dezelfde gebruiker in een ander natuurgebied dit opnieuw doet. Hij gebruikt Potlatch 2.5.
Ik gebruik die editor niet maar heb een vermoeden dat de overbodige tags het gevolg zijn van het aanklikken van symbolen in Potlatch. Kan iemand dit bevestigen of ontkennen?

Ik heb gekeken naar de internationale cijfers van het gebruik van deze tags in een aantal overbodige combinaties (Taginfo):

Sidewalk=none: 268.076
Sidewalk=none i.c.m. foot=yes: 55.998 (20,9%)
Sidewalk=none i.c.m. highway=footway: 6.893 (2,6%)
Sidewalk=none i.c.m. highway=path: 4.360 (1,6%)
Sidewalk=none i.c.m. foot=designated: 3.060 (1,1%)
Sidewalk=none i.c.m. segregated=no: 2.444 (0,9%)

Foot=yes: 2.615.131
Foot=yes i.c.m. highway=footway: 522.319 (20%)
Foot=yes i.c.m. highway=path: 470.766 (18%)

Foot=designated: 659.275
Foot=designated i.c.m. highway=path 347.278 (52,7%)
Foot=designated i.c.m. highway=footway 111.459 (16,9%)

De cijfers overlappen elkaar voor een deel. Het is wel duidelijk dat er een flinke hoeveelheid overbodige tag-combinaties in omloop is.

Met Overpass Turbo heb ik nog even rondgekeken in het noorden van het land. In ieder geval één gebruiker heeft met JOSM ook diezelfde overbodige tag-combinaties gemaakt. Wel zijn er meerdere gebruikers van Potlatch die dit op hun naam hebben. Die ene gebruiker springt er wel uit, ook omdat die zich vooral met paden lijkt bezig te houden.
Heeft iemand suggesties hoe dit te stoppen (behalve deze gebruiker erop te wijzen zoals ik heb gedaan)?

Overigens is tegenwoordig sidewalk=no preferred ipv none. http://wiki.openstreetmap.org/wiki/Key:sidewalk

Er lopen nu meerdere discussies om sidewalk=none uit te faseren ten gunste van sidewalk=no. Is dit iets wat wij in Nederland willen steunen? Persoonlijk ben ik voor het consistent maken van onze data en het verwijderen van synonymen.

Momenteel is in Nederland sidewalk=none zo’n 5.000 keer gebruikt tegenover 24.000 maal sidewalk=no: https://taginfo.geofabrik.de/europe/netherlands/keys/sidewalk#values

Links naar andere discussies:
Wiki
JOSM
JOSM
StreetComplete
en een discussie in Discord, maar waar die begonnen is kan ik niet zo snel terugvinden.

Deprecaten van sidewalk=none is prima (maar ook niet echt belangrijk). Als je die discussie leest kun je mijn irritatie wel merken over het ‘doen zonder documentatie’; dat komt omdat de documentatie van sidewalk=* nu letterlijk stelt dat none en no exact gelijk zijn, en beiden prima.

Als je code bijdraagt aan de tools die wij gebruiken baseer je je onder andere op de actuele documentatie. Dat dan ondertussen allerlei patches worden voorbereid die hem effectief deprecaten zonder discussie op de Tagging-ML of de wiki is dan raar; je verwacht dan ten minste een voetnootje op de wiki. Dit ergert mij specifiek omdat ik net met de validatorcode voor footway=/sidewalk= in JOSM bezig was.

In 2017 zei de documentatie nog dat ‘no’ een niet-goedgekeurd synoniem voor ‘none’ was, dus dit loopt sowieso raar qua ontwikkeling.

Ik vind het prima om de Wiki documentatie aan te passen om sidewalk=none als vervangbaar aan te duiden. Zal ik dat doen?

Markeer hem dan als deprecated; daarmee zeg je dat de tag ooit correct was, maar nu niet meer gebruikt moet worden om wegen te taggen. Deprecated betekent ook dat data consumers de waarde mogelijk nog wel moeten erkennen.

Ga je gang. Het kan zijn dat je wat tegenreacties te horen krijgt, maar dan mogen die dat uitvechten met degenen die nu in ID en JOSM ‘none’ als fout aanmerken.

Gedaan: https://wiki.openstreetmap.org/w/index.php?title=Key:sidewalk&diff=2191684&oldid=2185418

Uitgebreider commentaar kan altijd nog worden toegevoegd.

Heeft iemand een suggestie om de sidewalk=no/none in Nederland consistent te maken? Mijn persoonlijke voorkeur gaat uit naar alle 5.000 =none in in één keer aanpassen, maar wellicht zijn er andere ideeën.

Hoeveel van die sidewalks zijn er onterecht? sidewalk=yes/no langs highway=path en highway=footway is gewoon fout, langs een highway=track is op z’n minst twijfelachtig.
Zie: http://overpass-turbo.eu/s/1aFX

Volgens mij bestaat dit niet (in Nederland), want ik blijf errors en lege resultaten krijgen met deze en vergelijkbare queries. Dat lijkt me een goed teken.

Ik zou het gewoon zo laten. Data consumers moeten toch nog jaren lang no en none hetzelfde behandelen (en dat is triviaal). Het is dus geen ongeldige waarde, enkel een verouderde die je nu niet meer moet gebruiken (maar wel mee om moet gaan als je iets met die data doet). Het zijn er wereldwijd ook zo veel dat een geautomatiseerde opschoonactie enorm is zonder duidelijk voordeel. Als iemand een gebiedje update dan kom je er vanzelf langs.

Lijkt me eerder dat je query niet goed werkt, of dat de server overbelast is of dat je een te groot gebied kiest.
Hier een paar uit mijn query:
https://www.openstreetmap.org/way/397705506 (sidewalk=none op een pad)
https://www.openstreetmap.org/way/385406527 (sidewalk=yes op een sidewalk)

Prima.

Wat wel gek is is dat onder Possible tagging mistakes nog steeds Can be replaced with sidewalk=none voor komt.

Edit: Ik zie dat dit later is bijgewerkt.

Is het inmiddels duidelijk of dit komt door Potlatch?

Het is goed als “verboden combinaties” in Josm bekend zijn, dan komen ze ook met verloop van tijd in Osmose en heb je een extra mogelijkheid om de gebruiker er op te wijzen.

Als je ergens aan het opschonen slaat kan je altijd even in dat gebied de sidewalks op no ipv none zetten.

Met dit beleid zullen we altijd met hopen oude data blijven zitten. We hebben nu zoveel data in OSM dat deze aanpak simpelweg niet meer volstaat. Mijn voorkeur gaat uit naar het gestructureerd aanpakken van inconsistente data.

Veel mensen zullen niet begrijpen waarom je “no” zou gebruiken en in dit soort situaties nog steeds “none” gebruiken. Dat lijkt mij persoonlijk ook meer terecht aangezien het geen booleaanse parameter is. De benaming “oude data” is daarom incorrect.

Wat mij betreft gaat het niet om welke waarde logischer is, het gaat erom wat de afspraak is (en … als je die lang genoeg gebruikt ga je het vanzelf logisch vinden)

Ik hecht meer waarde aan data consistentie. Wat mij op valt is dat na een beslissing het erg lang duurt voordat alle data bijgewerkt is.

Klopt, maar om dit op te lossen zou je eigenlijk wereldwijd in één klap alle none door no moeten vervangen. Dat gaat tegen het huidige beleid in. Niet omdat die vervanging kwalijk is, maar omdat je daarmee de datum van laatste bewerking van heel veel entiteiten ook naar ‘vandaag’ zet. Daar zullen om verschillende redenen mappers bezwaar tegen hebben, bijvoorbeeld omdat ze de datum van laatste bewerking meenemen als zoekparameter of attribuut voor zoekopdrachten of data-analyses (bijvoorbeeld: „welke regio’s worden vaker bijgewerkt?”).

Met deprecation in software is er altijd een overgangsperiode waarin de gedeprecate waarde of methode nog een tijd lang geldig blijft. Dat is bij een project van deze omvang normaal. Probeer je er niet aan te storen; deze waarde heeft bijna geen negatieve gevolgen in tegenstelling tot veel andere verouderde waarden.