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

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?

Die laatste link stopt midden 2018, op https://taginfo.openstreetmap.org/keys/sidewalk#values kan je vinden dat none op dit moment 248058 keer gebruikt is tegen no 613884 keer, iets van 2.5 maal meer. De grafiek voor sidewalk=none laat een scherp daling zien in de afgelopen weken.

In Nederland gaat het om 5197 maal none tegen 24762 keer no.

Ik heb er geen bezwaar tegen als voor Nederland none no wordt gemaakt.

Ik heb nu enkele dingen gedaan:

  • een lading errors gefixt
  • sidewalk=* tags van voetpaden afgehaald
  • sidewalk=none op autowegen in =no veranderd
  • 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?

Relevante wijzigingensets tot zover:
112416929, 112419180, 112420651, 112421086, 112422997

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.)

ik heb nu de laatste ~900 sidewalk=none naar =no omgezet. De kwaliteitscontrole had ik dus al eerder gedaan.

Relevante wijzigingensets:

Fijn dat het opgelost is wat mij betreft. Inmiddels is taginfo ook bijgewerkt.

:slight_smile: