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

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.

Het negatieve gevolg is dat alle gebruikers van de data rekening moeten houden met twee tags die hetzelfde betekenen. Dat is een niet-ideale situatie die heel gemakkelijk te verhelpen is. Dat objecten dan voor het laatst “vandaag” gewijzigd zijn lijkt me geen reden om met zulke situaties te blijven zitten. Er zijn genoeg andere manieren om aandachtsgebieden in OSM te vinden.

Frederik Ramm zei ook al in een recente discussies dat dergelijke edits helemaal niet uitgevoerd moeten worden, omdat dan de dichtheid van foutmeldingen (zoals in Osmose) in sommige gebieden afneemt, waardoor ze minder snel als aandachtsgebied gevonden worden. Dat vind ik al helemaal een slecht en ongeldig argument, want minder foutmeldingen is juist alleen maar positief en betekent dat mappers zich efficiënter op de resterende foutmeldingen kunnen focussen.

Wat mij betreft moeten we het bijhouden van onze data stimuleren, uiteraard met draagvlak en documentatie als de basis.

if("no"||"none") { }

Alleen als je het wereldwijd oplost. Zolang daar geen draagvlak voor is heeft in Nederland alleen weinig zin. Maar tools die nu iets met de data doen moeten er toch al rekening mee houden (temeer omdat het in 2017 nog zo was dat ‘none’ de juiste waarde was omdat ‘no’ niet voortkwam uit de oorspronkelijke proposal), dus je lost het alleen op voor iemand die in de toekomst om een of andere reden:

  • niet de wiki raadpleegt voor de bestaande waarden,

  • niet naar de waarden kijkt die in gebruik zijn (via bijvoorbeeld Taginfo),

  • en niet in staat is om in code twee waarden aan elkaar gelijk te stellen.

Dan verricht je wel een hoop werk voor zo’n fictief iemand! Het negatieve gevolg dat je schetst bestaat dan feitelijk toch niet?

Andere mappers zien dat soms anders. De omtagoplossing die je voorstelt levert dus mogelijk meer ergernis op (terecht of onterecht) voor een heel beperkte winst.

Ik snap je insteek wel, want het voelt fijner als de data ‘schoon’ is, maar de OSM database is gigantisch; het is nooit af, net, of compleet (en dat is prima). Gerichte data-onderhoudsacties die zich richten op echt foute waarden (spelfouten, fout toegepaste tags zoals footway=right, etc.) leveren veel meer winst op.

Edit: (Het zou anders zijn als het om een paar honderd tags ging, maar sidewalk=none is 418765 keer gebruikt.)

In onder andere de VS en Polen wordt sidewalk=none nu actief uitgefaseerd. Zie bijvoorbeeld https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/retag_sidewalk=none_in_Poland.

Over het lot van ongebruikelijke highway=* + sidewalk=none combinaties, zoals highway=path, wordt nog gesproken.

Mijn suggestie is dat we nog even de kat uit de boom kijken om te zien hoe internationale mappers hiermee omgaan en welke hindernissen zij tegenkomen, zodat wij hiervan kunnen leren voordat we ook in Nederland op grote schaal overstappen van sidewalk=none naar =no.

Een groot deel van de sidewalk=none tags kwam trouwens van StreetComplete. Ondertussen is StreetComplete overgestapt naar het taggen van sidewalk=no wanneer gebruikers aangeven dat langs een weg geen stoep is.

Het uitfaseren van sidewalk=none is nu in volle gang. Kijk maar eens naar deze vergelijking.
Volgens mij zijn de Amerikanen nu halverwege, dus de grafiek zal binnenkort nog een groot stuk verschuiven.

Vind iedereen het goed om dit in Nederland ook te doen?