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.
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.)
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?
sidewalk=none verwijderd van paden (geen wegen) waar al foot=no op stond
sidewalk=none op highway=cycleway + foot=yes veranderd in segregated=no waar nog geen segregated=* tag bestond.
Voor elke bewerking heb ik steekproeven gedaan om errors en vreemde tags te vinden om die vervolgens te herstellen en om eigen fouten te voorkomen alvorens ik aan het omtaggen begon.
Er bestaan nu nog sidewalk=none tags op ruim 900 paden, waaronder:
highway=bridleway
highway=cycleway
highway=path
highway=pedestrian
highway=track
Hierover zou ik graag wat advies willen. Halen we alle sidewalk=* op deze paden weg onder het mom van irrelevante data of kunnen we er nog wat mee?
Bij een cycleway is sidewalk=* vrij gangbaar in Nederland, dus die zullen mappers zelf moeten nakijken. Als je in stedelijk gebied een stuk hebt waar het fietspad deels wel en deels niet een stoep ernaast heeft dan is het wel consistent (en duidelijk voor andere mappers) om een deel sidewalk=left/right en sidewalk=no te hebben. Je geeft met de sidewalk=no namelijk ook aan dat je die way hebt beoordeeld op de aanwezigheid van een stoep, en net als met oneway=no kan die erop wijzen dat je hier als mapper even op moet letten.
Ik zou dus niet sidewalk=none verwijderen van cycleway en er alleen segregated=no voor terugzetten. (Buiten de bebouwde kom is dat wel gangbaarder natuurlijk.)
