Verkeerstekens/-borden: verwijderen "needless" tags vaak onterecht

Ondanks dat in deze discussie (vanaf https://forum.openstreetmap.org/viewtopic.php?pid=670744#p670744 ) is geconcludeerd dat overeenkomst van [een tag met een defaultwaarde volgens deze tabellen ](OSM tags for routing/Access restrictions - OpenStreetMap Wiki )
op zich GEEN reden is om die tag weg te laten en al helemaal niet om bestaande tags te verwijderen.

Toch gaan ook mappers die in deze discussie betrokken waren – en de uitkomst onderschreven hebben- door met het verwijderen van correcte en tags van anderen.

Hiermee gaat informatie uit de database verloren en is ook niet meer te achterhalen welke wegen wel compleet getagd zijn en waar we bij gebrek aan expliciete informatie maar moeten terugvallen op een default-waarde, die misschien wel, maar misschien ook niet correct is voor die specifieke weg.

Als een volgende mapper de ontbrekende - en daarmee onbekende- access tags weer aanvult en een default-verwijderaar ze er weer af haalt kom je in een eindeloze cirkel terecht: dweilen met de kraan open.

Uit persoonlijk contact bleek dat dit verwijderen gebeurt onder het motto “de database opschonen” en terwijl de changeset comments een heel ander beeld geeft van wat er gebeurd is:

Bijvoorbeeld:

**1. ** foot=yes verwijderd van cycleway, https://www.openstreetmap.org/way/62309578/history
terwijl juist het toevoegen ipv verwijderen van een tag een verbetering zou vormen, namelijk segregatd=yes: https://www.mapillary.com/map/im/L5QBtvzl5vV7ZEf2L-sSAg )

**2. **foot=yes & bicycle=yes verwijderd van een highway=residential met een bijzonder toegangsregime (changeset: “change name”) https://www.openstreetmap.org/way/359229286/history

**3. **En een voorbeeld waarbij de praktische schade van dit vandalisme het meest duidelijk wordt: foot=designated & bicycle=designated verwijderd van een highway=path (“staan immers default beide op yes, hoeft dus niet getagd“).
https://www.openstreetmap.org/way/32022530/history (changeset: route small mods; source :survey).

**Het gevolg:
**-de Standard carto (toch een van de belangrijkste datagebruikers) rendert dit pad waar fietsers op mogen als een “Wandelpad of voetpad” (rood) en niet meer als een Fietspad (blauw), terwijl de omliggende paden –waar de tags niet zijn gesloopt nog wel gewoon als fietspad (in de zin van de renderer) worden weergegeven : https://www.openstreetmap.org/#map=17/53.48478/6.16848 (is OpenCycleMap is deze wijziging nog niet verwerkt)
In de Duitse versie is ook te zien dat de renderer dit pad door de verwijdering niet meer herkent als geschikt voor fietsers: https://www.openstreetmap.de/karte.html?zoom=17&lat=53.48485&lon=6.16765&layers=B000TT

Dezelfde mapper die deze tags verwijdert heeft onlangs op https://wiki.openstreetmap.org/wiki/NL:Cycleway
toegevoegd:

Maar ook dat is echt een misvatting:

Ook de fietsrouter die OSM.org zelf aanbiedt ziet dit pad door de verwijdering niet meer als bruikbaar voor fietsers:
https://www.openstreetmap.org/directions?engine=graphhopper_bicycle&route=53.48373%2C6.16363%3B53.48630%2C6.17344#map=16/53.4827/6.1715

En ook deze router niet:
http://brouter.de/brouter-web/#zoom=16&lat=53.48381&lon=6.16661&layer=OpenStreetMap&lonlats=6.16363,53.483768|6.173115,53.487541&nogos=&profile=trekking&alternativeidx=0&format=geojson

Dus het veronderstelde landspecifieke default-systeem wordt helemaal niet (breed) ondersteund.
De algemene tabel uit het voorstel op https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions
overigens ook niet, want ook daarin is bicycle=yes op een path.

Deze tabellen zijn dus GEEN leidraad om tagging weg te laten!

En ook al zou dat wel zo zijn: het voorstel is NIET aangenomen (er is zelfs geen defaut-relation gedefinieerd voor NL, alleen een tabel), maar slechts een proposal en er staat ook nergens dat overeenkomst met een default tag een excuus is om tags weg te laten en al helemaal niet om ze te verwijderen.

Dus alsjeblieft allen: stop met dit zinloze slopen van de database er herstel wat je in dit kader hebt verwijderd!
En laten we alsjeblieft ook andere (en vooral beginnende mappers) niet meer aanzetten tot het weglaten of zelfs verwijderen van deze tags, wat helaas wel gebeurt, zie bijvoorbeeld http://resultmaps.neis-one.org/osm-discussion-comments?uid=99810&commented en http://resultmaps.neis-one.org/osm-discussion-comments?uid=99810

Als je graag iets wil opschonen, pak een van de vele validatoren en leef je uit op de duizenden items die wel echte fouten zijn in onze database. Daarmee verbeter je de database. En ik ben er –ondanks alle false positives- nog geen een tegengekomen die foot=yes op een path ziet als een taggingfout.

Verwijderen van tags schoont de database niet op. Dat is al vaker aangegeven. Voor elke actie,die in OSM wordt uitgevoerd, wordt history aangemaakt. En het is juist de history, die qua grootte enorm toeneemt. Ook al in hardware niet meer zo duur, er moet ruimte voor zijn.
Aantal jaren geleden lieten ze dit op een bijeenkomst van de Fietsersbond ook zien. De history database was vele malen groter dan de actuele database.

Ik hou het kort.
Het toevoegen van foot=yes aan een door anderen getekend highway=path door multimodaal vind ik databasevervuiling. Daar heb ik in een pm op gewezen, maar daar wordt geen antwoord op gegeven en in dit topic wordt selectief munitie aangedragen en worden oude koeien uit de sloot gehaald.

Los van het feit dat historie tot in de eeuwigheid in de database opgeslagen blijft (omdat de terabytes niets meer kosten); het toevoegen van nodeloze tags aan OSM elementen kan andere mappers in verwarring brengen en mogelijk aanzetten tot ook maar extra tags aan te vullen. Mensen die access=yes aan een residential street toevoegen begrijpen het gewoon niet.
Die tag hoort daar niet en kan in mijn ogen gewoon verwijderd worden, ook al blijft de historie in de database staan.

De default access rights zijn niet voor niets verzonnen en dat sommige routeerders daar geen rekening mee houden, moeten we om die reden gaan ‘overtaggen’? Of moeten die routeerders wat slimmer worden (een paar regels extra code slechts)?

Ik blijf erbij dat we specifieke access-tags gebruiken daar waar onduidelijkheid zou kunnen bestaan, in alle redelijkheid, of er bijvoorbeeld tijdsgebonden access-rechten zijn.

Ik noem als voorbeeld een voetpad (g07) met als onderbord “fietsen toegestaan” dat getagd zou kunnen worden als footway/pedestrian en bicycle=yes, hoewel het juridisch gezien gewoon een onverplicht fietspad (G13) is, maar dat verkeersbord wordt slechts door 50-plussers nog herkend.

Als iemand voorstelt om aan alle primary, secundary, tertiary en mototorways motor_vehicle=yes toe te voegen: be my guest!

Vreemd dat de routers problemen hebben als er geen extra tags bijkomen.
Het zou toch gemakkelijk moeten zijn om bv. highway=cycleway te vervangen (tijdens de import) naar highway=path;bicycle=designated;foot=yes voor paden in Nederland.

josm klaagt bij de validatie over overbodige access tags, dus ik kan wel begrijpen ze dan door iemand verwijderd worden.

Bij 3. heeft Multimodaal wel een punt. Vooral aan de kust en in de grensstreek wordt door Duitse medemappers nogal eens op de Duitse manier fietspaden gemapt met highway=path , bicycle=designated. Meestal tag ik het dan toch om naar de een G11, 12a of 13 fietspad.
Wie bicycle=designated verwijdert heeft het niet begrepen.

Verder ben ik wat behoudender in het adviseren om in mijn ogen needles tagging te ontmoedigen. Meer in de trant van baat het niet dan schaadt het niet. Advies: Het is niet nodig, maar het kan ook geen kwaad. Het zijn dan wel hun eigen tags.
Verder hebben we natuurlijk ook nog de tool BTM… die geeft foutmeldingen als er bicycle=yes wordt getagd op een cycleway…
Die tags verwijder ik wel net als cycleway=track op een highway=cycleway.

Volgens mij zijn we het met zijn allen wel eens dat het ALTIJD terugvallen op defaults wanneer mogelijk ongewenst is én het onbeperkt toevoegen/toelaten van tags die geen essentiële informatie geven ongewenst is.

De drie voorbeelden van Multimodaal onderstrepen een belangrijk uitgangspunt: wees voorzichtig en terughoudend met het aanpassen van tagging van een situatie die je niet kent / niet recent zelf hebt gezien. Dat lijkt hier althans aan de hand.

Voorbeeld 1: de tag foot=yes lijkt overbodig maar als je de situatie kent of bekijkt zie je inderdaad dat dit geen standaardgeval is. Het is waarschijnlijk dat die aparte voetgangersstrook de reden is geweest voor een eerdere mapper om foot=yes toe te voegen. In deze situatie lijkt me de aanwezigheid van een tag die iets zegt over voetgangers zeer terecht.

Voorbeeld 2: op basis van de tags die er waren zou je denken ‘er staat vast een verbodsbord voor motorvoertuigen met uitzondering voor bestemmingsverkeer of aanwonenden’ en dan is motor_vehicle=no in principe afdoende. Op GSV zie ik echter een zonebord C1, dus o.a. verboden voor alle voertuigen, met daarop o.a. een uitzondering voor fietsers. Ik weet zo niet of mofa daar ook onder valt (mofa=yes is ook weggehaald).
Hier is zowel de oude als nieuwe tagging niet optimaal. Correcter lijkt me vehicle=destination met bicycle=yes.

Voorbeeld 3: zonder beeldmateriaal weet ik / weten we niet wat de werkelijke situatie is. Vanaf het begin, acht jaar geleden, was het highway=cycleway. Twee jaar geleden is het omgezet naar highway=path, bicycle=designated, foot=designated en segregated=no. Op basis daarvan zou je er een verkeersbord van gedeeld fiets- en voetpad verwachten. Die komen in Nederland niet veel voor en verwacht ik hier niet maar het zou kunnen.
Een andere mogelijkheid is dat het een pad is zonder bebording. In dat geval is highway=path correct maar zouden bicycle=* en foot=* de waarde yes moeten hebben.
Hoe dan ook, het verschil tussen designated en yes zal voor routers weinig verschil maken maar het weghalen van die sleutels blijkt dus wel duidelijk nadelige gevolgen te hebben.

Kortom: aanpassen/verwijderen van tags van een (duidelijk door anderen al eens beoordeelde) weg of pad op basis van onvolledige informatie is zeker geen een goede werkwijze.

Er is binnen softwareontwikkeling vaak een (expliciete dan wel impliciete) afspraak dat je een source file niet aanraakt om alleen cosmetische veranderingen aan te brengen. (Natuurlijk zijn er wel uitzonderingen, maar die worden dan wel binnen het hele team gecoordineerd).

Ik denk dat het goed zou zijn om binnen OSM ook zo’n afspraak te maken: als het nu werkt en er is geen reden om een object aan te raken, ga het dan ook niet opschonen. Als er een categorie van objecten is die opgeschoond moeten worden, dan is een bulk edit nodig. Met alle discussie en consensus die daar bijhoort.

Verder, als je (tijdens het editen van een object) een cosmetische verandering aanbrengt dan is het jouw verantwoordelijkheid dat bestaand gebruik van dat object niet breekt.

Er zit een enorme afstand tussen mappers en de uiteindelijke gebruikers van OSM data. Als mappers luk-raak veranderingen aanbrengen die dingen kapot maken voor gebruikers van OSM, dan hebben na verloop van tijd geen gebruikers meer over.

Geen antwoord op gegeven?
Hieronder het antwoord daarop dat ik je in PM van gister schreef.

Als er iets onbeantwoord is, dan is het mijn vraag hoe het verwijderen van een tag het duidelijker en minder foutgevoelig maakt. Ik ben benieuwd naar je antwoord daarop.

Ik draag 3 verschillende situaties tussen de 3 en 25 dagen oud aan…

Op welke wijze is een path met foot=yes in “verwarrender” voor een datagebruiker dan een path waar de hele access onbekend is?

Ik denk dat iemand die dat doet (ik doe het zelf niet) de Nederlandse wetgeving en de tagging beter begrijpt dan jij.
Het zou ook bijvoorbeeld "permissive"kunnen zijn, , de tag “yes” is dan misschien wel wat je in 99% tegenkomt -en daarmee niet heel informatief- maar je weet in ieder geval dat: (a) de situatie voor die weg expliciet is afgewogen en (b) dat deze weg ook daadwerkelijk voldoet aan wat je zou verwachten

Ze zijn verzonnen voor het kunnen omgaan met ONTBREKENDE data, niet om data te doen verdwijnen zoals jij doet.
Waar zie je staan dat je tags moet weglaten of zelfs verwijderen die voldoen aan de default uit de landspecifieke pagina?

Sommige routeerders?
Zelfs de Standard Carto van OSM en de routerdeer die OSM zelf aanbiedt houdt geen rekening met dit abandoned voorstel.
Je sloopt werk van anderen vanuit een een illusie dat er een onzichtbaar systeem is dat ontbrekende data feilloos aanvult, zelfs als deze eigenlijk meerdere waarden zou kunnen aannemen

En een paar access-tags is “overtaggen”?

Een van de grootste meerwaarden van OSM ten opzichte van andere bronnen is dat het inzicht geeft in de toegankelijkheid van oa paths en tracks. Als je alleen maar wil weten of er een pad ligt en je niet bekommert om de toegang, dan kan je net zo goed/beter een topografische kaart pakken. Dat zal met wandelen toch flink wat tegenvallers geven met gesloten paden, paden waar je alleen tegen betaling in mag of alleen in bepaalde perioden.

En de enige manier om daar duidelijkheid in te krijgen is om ze allemaal te taggen.

Anders kan je als eindgebruiker het verschil niet zien tussen een pad waar de access unknown is (helemaal omdat die tags ook verwijderd worden…) en een pad waarvan daadwerkelijk is gebleken dat deze voldoet aan een default. Helaas leven we niet in land met allemansrecht waar je ervan uit kan gaan dat de access altijd wettelijk geborgd is.

Je gaat toch ook niet maxspeed 130 verwijderen van motorways omdat dat de default is?
Dan weet je toch niet meer of maxspeed op motorways compleet getagd zijn?

En als iemand dan zo goed is om een maxspeed op een snelweg waar die -na verwijdering- ontbreekt aan te vullen na een survey en je verwijdert 'm nogmaals, dan kom je toch in een eindeloze en nutteloze cirkel terecht ?

Daar is een hele simpele oplossing voor: blijf met je handen af van expliciete access-tags
*(*beter gezegd: corrigeer ze als ze inhoudelijk onjuist zijn; vul ze aan; maak ze duidelijker, maar gooi ze niet weg). *

Dat is duidelijker voor alle gebruikers en scheelt een heleboel nutteloos werk, onzekerheid over de access en negatieve energie.

edit: * toegevoegd + “of alleen in bepaalde perioden”

brouter routeert gewoon over dat pad als je er naar vraagt. Het is echt niet dat hij er niet over wil routeren. Daarbij heb je zelfs het trekking profiel gebruikt, dat is wandelen. En niet over een pad wandelen?
Het punt is gewoon het routeprofiel. Er wordt een cost van 5050 aan dat pad gegeven. 5000 komt omdat het een highway=path is zonder verdere informatie wat voor pad het is, en dan krijg je die kostfactor. Als je aan zou geven wat voor soort pad (tracktype, surface), dan kom je al een stuk verder.
Ik heb over paden gelopen waar ik ook liever niet over liep. Hoe meer info je kunt geven, hoe beter een router er een kostfactor aan toe kan kennen. Als er geen verdere tags zijn gaat een router van een default uit en dat is meestal het slechtste. Een pad is voor mij het laagste soort begaanbare weg die ik kan verzinnen. Ik tag bospaadjes met path, en daar wil je liever niet over fietsen.

Ik heb geen idee wat voor soort pad het is, maar als het een schelpenpad is zoals ik ze ken op de Waddeneilanden zou ik hier een tracktype=grade1 van maken, en dan krijg je een heel andere routering. En dat vind ik ook een veel logischere tagging dan bicycle=designated of foot=designated. Dat laatste is meer tagging for the router, als in: “ik vind dat je hierover moet kunnen lopen/fietsen dus dan zeggen we maar dat je dat kunt, zonder verdere logische informatie over het pad”.

Dat is iets anders: als je zelf kiest voor een start- of eind plek op een traject waar je volgens de router met het gekozen vervoermiddel niet mag komen, dan overruled jouw keuze voor die plek de afkeer van de router. Wel zo handig als je daar moet zijn en op dat stukje bereid bent bijvoorbeeld met de fiets aan de hand te lopen, de regels wil overtreden of als je weet dat de data in OSM niet klopt, maar jouw correctie nog niet in de wekelijkse update is verwerkt…

Nee ook niet, trekking wordt hier bedoeld in de onderstaande zin, wat wij “vakantiefietsen” oid zouden noemen.

https://en.oxforddictionaries.com/thesaurus/trek

Zie ook http://www.bikeandtrekkingmagazine.nl/ : dat gaat echt over fietsen, niet over wandelen

Dat zie je ook zonder woordenboek al in het routeringsprofiel (dat prettig expliciet is en zelf te wijzigen), bijvoorbeeld:

En als je dat niet wil geloven: het pad dat zou duidelijk wordt vermeden in dit voorbeeld is een footway (moest wel naar het buureiland om een verbindende footway te vinden):
http://brouter.de/brouter-web/#zoom=17&lat=53.44726&lon=5.70959&layer=OpenStreetMap&lonlats=5.704458,53.446749|5.712134,53.446225&nogos=&profile=trekking&alternativeidx=0&format=geojson

Het wandelprofiel heet hier “hiking”, zie de verschillen in het profiel, bijvoorbeeld:

en dat levert gelijk een duidelijk ander resultaat op:
http://brouter.de/brouter-web/#zoom=17&lat=53.44726&lon=5.70959&layer=OpenStreetMap&lonlats=5.704458,53.446749|5.712134,53.446225&nogos=&profile=hiking-beta&alternativeidx=0&format=geojson

De combinatie van (a) de originele tagging: cycleway (b) de SV-foto’s op de aansluitingen van de omliggende paden: G13 (c) het padtype: schelpenpad en (d) de ervaring met dergelijke paden bij de betreffende beheerder: Staatsbosbeheer doen zeer sterk vermoeden dat het een G13-fietspad is.

Maar Martin is hier onlangs op Schiermonnikoog geweest voordat hij de tags verwijderde
( https://www.openstreetmap.org/changeset/57651991 ; source:survey).

@Martin: wat voor pad heb je hier precies aangetroffen?

Ik ben bevooroordeeld, want ik ben in Amsterdam wegen en fietspaden aan het taggen met smoothness t.b.v. inline skaten, maar ik denk dat hier een smoothness tag zou helpen.

bicycle=yes/designated is een access tag. Wie mag er komen, voor wie is het pad bedoeld. Het geeft niets aan of je er ook wil fietsen.

Zeker in buitenland in de bergen is een pad niets waar je wil fietsen. Ik ben wel in gebieden geweest waar je zelfs met een MTB niet gewoon een willekeurig pad kan fietsen.

Dus het is logisch als een router paden zonder extra tags overslaat.

De als je aan wil geven dat een schelpenpad geschikt is om te fietsen, dan is smoothness=intermediate de meest logische toevoeging.

Als access=yes als meerwaarde wordt beoordeeld, hoe klein ook, dan zullen er mappers zijn die dit grootschalig willen gaan toepassen.
Maar waar leg je de grens? Door diverse imports zit er nog veel meer info in de database die nooit handmatig is gecontroleerd. Moeten we daarin dan geen onderscheid maken? Straatnamen bijvoorbeeld… een extra tag met streetname_checked=yes?

Access=yes is qua info algemeen en zou inderdaad in 99% van de gevallen gelden. Door toevoeging overal zou je dus een minieme onzekerheid wegnemen. Vervolgens vermoed ik dat op zijn minst in 1% van de gevallen er alsnog geen grondige check is gedaan. Misschien heeft iemand uitzonderingen op de algemene toegang gemist. Dus vehicle=yes, foot=yes en horse=yes erbij.
En als het een keer vehicle=no is… heeft iemand dan wel gecheckt op uitzonderingen? Toch maar opsplitsen naar motor_vehicle en bicycle. Of wacht… tot maar opslitsen naar motorcar, motorcycle, goods, hgv, psv, moped en mofa.

Ik weet, dit neigt naar een hellend vlak redenering, maar ik wil hiermee aangeven dat er beter wel een grens wordt getrokken.
Er is zeker een punt waarbij extra informatie een netto negatief effect heeft en juist verwarring en lagere betrouwbaarheid kan opleveren.
Wat mij betreft is die met een willekeurig toevoegen van access=yes al overschreden.
Juist als access=yes weinig is toegepast is de kans veel groter dat de actuele status en waarde hiervan door andere mappers wordt gecontroleerd.

Aldus:

• schijnbaar overbodige tags niet te gemakkelijk weghalen (grondig controleren en eventueel overleg met desbetreffende mapper);
• de waarde van die aanvullende tags met wel realistische meerwaarde beschermen door werkelijk overbodige tags te weren.

Minder streng dan Martin maar strenger dan Multimodaal, zoiets.

Waardeer de humor en het relativisme!

Ik ben niet zo streng in de leer - noem me maar agnost.

Heb echter wel een sterk gevoel voor logica: als ik een bord ‘voetpad’ (G07) zie en de gemeente heeft daaronder een bord ‘verboden fietsers/bromfietsers’ (C15) geplaatst, dan denk ik altijd reflexmatig dat blijkbaar alleen een G07 niet voldoende is en ik dus wel gewoon mag fietsen op andere paden waar alleen een G07 staat. Analoog denk ik dat als foot=yes ontbreekt ik daar blijkbaar niet mag lopen.

Maar het zal wel aan mij liggen…waar een wil is is een weg.

Ik heb het idee dat een grote groep fietsers ‘bordblind’ is. Een strook asfalt die breed genoeg is wordt gewoon gezien als fietspad, wat voor borden er ook staan. Dus dan kan ik me voorstellen dat de wegbeheerder er maar een C15 bij zet.

Nog gekker is dat sommige mappers op paden die overduidelijk een voetpad zijn rustig een bicycle=yes zetten omdat er regelmatig gefietst wordt.

Volledig off-topic natuurlijk, want het is geen mapping topic, maar een verkeesregeltopic, maar inderdaad.

Naast bordblindheid constateer ik ook dat de verschillende gemeente(ambtenaren) in Nederland er een verschrikkelijke puinzooi van maken waar mijn gevoel voor logica een knauw krijgt, gedogen voor de hand gaat liggen en handhaving uiterst moeilijk wordt. Ook een minachting van de verkeersdeelnemer, want deze dient de wet te kennen?
Ik geef, het is bijna weekend, het mag, wat voorbeelden uit eigen waarneming:

• Bij het ene bebouwde-kombord (H01-A) staat geen (terecht) onderbord ‘50’ (A01) bij de andere - voor de zekerheid- wel

• Onder het ene eenrichtingsbord (C02/C03) staat een m.u.v fietsers/bromfieters (meestal een icoon, soms volle tekst!) bij de andere een onderbord met een auto en motor-icoontje

• meestal wordt gecategoriseerd eenrichtingsverkeer aangeduid met C02/C03 met onderbord, soms met bijvoorbeeld C12, want formeel geldt dit bord slechts in een rijrichting maar in 99% van de gevallen effectief in beide richtingen; kan ik als fietser nu wel of niet een auto uit die zijstraat verwachten?[*/]

• een bord C01 met als onderbord “voor mountainbikers die de route volgen”

• een bord op de snelweg ‘130’ (A01-30) na bijvoorbeeld ‘100’ (A01-100) in plaats van A2-100 (want is 130 niet de default max snelheid op de autoweg in NL?)

Maar misschien verdubbelt een onderbord verboden voor fietsers onder een bord voetpad de boete

Prettig weekend - het wordt mooi weer!

Voor het (altijd leuke ) punt van bijzondere borden en bordblindheid heb ik maar een apart draadje gestart, want dat leidt hier wel heel erg af van de eigenlijke discussie die ik veel minder leuk vindt; namelijk over het verwijderen van correcte tags van andere mappers waardoor de database informatie verliest op een van de meest essentiële en waardevolle keys, namelijk access.

Verschillende mensen geven -in verschillende gradaties- aan negatief te staan tegenover de manier waarop dat nu gebeurt, maar op de vragen over jouw niet-afgestemde verwijderingen (die op mij persoonlijk eerder zelotisch-defaultistisch dan agnostisch overkomen) van data de situatie duidelijker maken heb je niet gereageerd.

Ik ben toch heel erg benieuwd naar wat jouw sterke gevoel voor logica zegt op deze reeds gestelde vragen:

En hoewel het misschien wel veel gevraagd is; zou je me alsjeblieft op weg kunnen helpen naar aanleiding van deze opmerking?

Is dit dezelfde Martin Bosje die foot=yes *verwijdert *van de drie gegeven voorbeeldwegen waar je WEL mag lopen?

En is dat weer een andere dan deze, die andere mappers afraadt om een highway=path (zonder foot=*) in te tekenen waarvan je nog niet weet of je er wel mag lopen (wel vermoeden dat het niet mag) ? https://www.openstreetmap.org/changeset/52053215

Ik wil als mapper ook graag voorkomen dat mensen naar een path worden gestuurd waar ze niet mogen komen, en daar zijn er helaas nogal veel van in ons land. Op dit path ontbreekt momenteel alle access-informatie.

Stel:
-ik ga op survey naar deze mooie plek om vast te stellen hoe het nou precies zit met die onbekende/onzekere access
-vervolgens kom ik tot de conclusie dat de correcte tag hier “foot=yes” is
-ik voeg deze bevinding toe aan de OSM-database, zodat het niet alleen voor mij duidelijk is, maar ook voor andere gebruikers

Op basis van welke vorm van logica komt deze Martin Borsje dan tot onderstaande conclusie?

Mis ik misschien iets met parallelle universa, of is mijn denkvermogen te beperkt om deel te kunnen nemen aan Openstreetmap ?

Ook een heel zonnig en eenvoudig weekend allen!

Wees gerust. Ik verwijder geen redundant tags meer.
Ik ben het er niet mee eens, maar accepteer het.

Dat is erg fijn om te horen, Martin, mijn weekend kan niet meer stuk

Zou wel fijn als we tot een werkbaar herstel van verwijderde tags kunnen komen van met name de paden in het derde voorbeeld
(highway is path of track waar access-tags zijn verdwenen)

Dat heeft de meeste negatieve praktische effecten (veel meer dan het verwijderen bij voorbeeld 1 en 2).

Weet iemand hoe je op een praktische manier changesets zou kunnen opzoeken waar zulke tags zijn verwijderd en die terugzetten
(zonder de goede toevoegingen uit diezelfde changesets ongedaan te maken?

Mag ik dan aan jou de *datareductie * opdragen die alleen al met mijn proefproject van import in de Meerpolder is bereikt, juist nadat er heel veel informatie is toegevoegd?

Zie nieuwe situatie boven, oude onder:
http://www.openkaart.net/meerpolder.html

Omvang OSM-XML voor gebied
-Oud: 1558 kb (heel veel redundant aansluitende landuse=grass naast elkaar)
-Nieuw: 941 kb

<tag k="bicycle" v="designated"/> 

=32 bytes

Een datareductie van ongeveer 20.000 x tag “foot=yes”

Wat Martin volgens mij bedoelt is het volgende: als in toenemende mate dubbele bevestiging wordt toegepast dan boet enkele bevestiging aan overtuiging in. Stel dat een gemeente bij 90% van de gelijkwaardige kruisingen borden neerzet met de tekst “rechts heeft voorrang”. Dit kan tot gevolg hebben dat bij de gelijkwaardige kruisingen waar die tekst ontbreekt de weggebruikers gaan twijfelen of rechts daar wel voorrang heeft.

Dit is dan analoog aan het toevoegen van bijv. foot=yes waar highway=path volgens de default al toegankelijk zou zijn voor voetgangers. Door toename van foot=yes op een highway=path kan de datagebruiker ineens gaan twijfelen of een path zonder die extra tag wel toegankelijk is voor voetgangers.

Echter, de default staat dus niet gelijk aan bevestiging en uit de voorbeelden blijkt dat inderdaad routers wel behoefte hebben aan die extra tag foot=yes voor echte bevestiging.

En toch… de tag highway=path is bedoeld voor algemene paden waar in principe lopen en fietsen is toegestaan en ik vind dat routers dit wel moeten kunnen begrijpen. Vervolgens: foot=yes of bicycle=yes prioriteit geven boven paden zonder die tags?
Ik vind het wat dubieus omdat access-tags dan worden gelezen alsof ze iets zeggen over de begaanbaarheid.
Er zijn bijv. graspaden zonder bebording waarbij fietsen dan formeel wel is toegestaan maar in de praktijk niet geschikt of niet aan te raden is. Met bicycle=yes de formele toegang aangeven of het weglaten om het lagere routeringsprioriteit te geven?

Ik ben zelf van plan om geen extra tags aan highway=path te hangen.
En ik ben van mening dat een goed functionerend default-systeem voor veel gevallen de voorkeur geniet boven een enorme rij toegangstags.