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

Deze discussie levert duidelijke tegenstellingen op. Mijn voorkeur gaat uit naar het weglaten van schijnbaar overbodige tags en ik heb er zelf wel eens wat verwijderd. Waarom? In de tijd dat ik nog echt ervaring moest opdoen als mapper heb ik op een bepaald moment de ‘default-methode’ geaccepteerd. Foot=yes op cycleway en path ben ik niet alleen overbodig maar ook ‘lelijk’ en ‘storend’ gaan vinden. Waarom? Waarschijnlijk vanuit de behoefte aan eenduidigheid en overzicht en de methode die ik volgde was naar ik dacht volgens de richtlijnen en consensus.
Ik vermoed dat de meeste mappers een bovengemiddelde behoefte aan zaken als structuur, eenduidigheid, compleetheid, overzicht. Het lastige is dan dat OSM nou juist niet een centraal gereguleerd project is. Gelukkig zijn er o.a. de verkeersregels waar we onze lol mee op kunnen. :wink:

De consensus over de ‘default-methode’ ligt op dit forum onder vuur dus hoe zit dat inhoudelijk met de default?

Ik weet niet in hoeverre routers daadwerkelijk de default-tabellen hanteren maar volgens de Wiki’s betreft het inderdaad een niet aangenomen voorstel. Maar uitgaande van de inhoud van het voorstel dan is de vraag vervolgens: wat was en is het idee achter de default-waarden?

Zoals ik het lees: het ging er om bestaande default-waarden die gelden op een nationaal of regionaal niveau beter gecodeerd beschikbaar te maken voor routers. Ik neem aan dat het dan gaat om default-waarden voortvloeiend uit verkeerswetgeving.

Waarom routers überhaupt default-waarden gebruiken wordt niet genoemd. De reden lijkt mij: om op basis van een incomplete database toch routes te kunnen plannen, in feite op basis van waarschijnlijkheid.
Kijk vooral ook eens naar de betekenis en ethymologie van het woord ‘default’:
https://en.wiktionary.org/wiki/default
‘Default’ is iets anders dan ‘standard’.
Ik zou zeggen, ‘default’ = het ontbreken van een specifieke waarde.

De landafhankelijke defaults maken het aldus mogelijk om een onvermijdelijk ontbreken aan informatie zo goed mogelijk op te vangen. Wereldwijde defaults werken niet want dan zou het veel te algemeen blijven. Nationaal niveau is volstrekt logisch gezien de opbouw van verkeerswetgeving.

Qua theorie zou ik, bij nader inzien, multimodaal wel gelijk kunnen geven met bijvoorbeeld deze opmerking:

HenkL heeft echter wel gelijk als hij stelt:

En dat werkt dan twee kanten op: foot=yes zal in veel gevallen niet voortkomen uit situationeel mappen en andersom zal het ontbreken van foot=yes vaak het gevolg zijn van een bewuste keuze ondanks dat de mapper de zekerheid heeft dat er gelopen mag worden.
In de praktijk heb ik gemerkt dat de extra toevoeging foot=yes inderdaad vaak van beginnende mappers komt en dit is dan voor mij weer het signaal om daar extra te controleren.

Mijn praktische argument voor het weglaten van dergelijke extra tags is het vergroten van de betrouwbaarheid: minder tags = minder kans op foutieve en verouderde gegevens.
Wat betreft routering voor wandelaars: voetgangers mogen vaak ook dwars over grasveldjes en door speeltuintjes lopen, enz. Dit is veel te complex om allemaal expliciet aan te geven.

Wanneer een router of renderer iets met de key lit=* wil doen dan hangt het succes daarvan helemaal af van het uitgebreid gemapt zijn van gevallen met lit=yes. Bij kaarten/routes voor voetgangers gaat het niet om telkens bevestiging van foot=yes maar juist om foot=no wanneer het een keer niet mag.
Alleen dat kleine deel aan uitzonderingsgevallen taggen is veel beter bij te houden voor de mappers en vergroot daarmee de betrouwbaarheid.

Kortom:

  • het verwijderen van ‘extra tags’ (vanwege je persoonlijke voorkeur) is niet echt netjes
  • het toevoegen van ‘extra tags’ (vanwege je persoonlijke voorkeur) is misschien ook niet zo netjes
  • zonder centrale regels of harde richtlijnen zal er een diversiteit aan tagging blijven bestaan

Ik blijft erbij dat lokale default een slecht idee zijn. En dat heeft niets met de wet te maken.

De wet geeft aan wat het eind resultaat moet zijn. Hoe we dat bereiken is onze keuze. En de keuze voor lokale defaults is niet de mijne,

Als je een stylesheet goed bestudeert, zie:

http://www.mkgmap.org.uk/download/mkgmap.html

dan zul je zien dat je bewering niet klopt. Des te meer tags, des te groter de betrouwbaarheid. De kaartenmaker heeft meer filtermogelijkheden. Dit geldt natuurlijk niet voor foot=yes bij een highway=footway, waar jij op doelt. Het probleem is niet zo zeer de indeling en de toepassing, maar het oordeel van de mapper is veelal subjectief. Het resultaat is dat een weg/pad in vele gevallen onjuist wordt gemapt. Als er meerdere tags zijn toegevoegd, kan de kaartenmaker dit probleem ondervangen en toch de juiste weg meegeven. De OSM ‘stikt’ van de foutieve tags, en toch worden de wegen/paden in de meeste gevallen goed weergegeven.

Als de naam OpenStreetMap letterlijk wordt opgevat, en street als default wordt genomen, dan kunnen de ‘default mappers’ alle paden wel gaan verwijderen. Daar zal vast wel een tooltje voor zijn. :slight_smile:

De geschiedenis lijkt zich te herhalen. In Engeland is de RSPCA eerder opgericht dan de RSPCC. De OSM is wel volledig als landuse erop voorkomt, maar de wandelmogelijkheden voor wandelaars zijn onnodig. Onder het mom van wandelaars mogen overal komen, hoeven trottoirs niet te worden gemapt. Wandelknooppunten hoeven niet te worden gemapt. Wandelaars behoren niet tot de doelgroep. Alsof wandelaars melaats zijn. :slight_smile:

Mattheus, je gaat hier wel kort door de bocht. In het huidige tijdsgewricht zou je dat popularisering kunnen noemen :confused:

Natuurlijk behoren wandelaars tot de doelgroep! Dat blijkt ook uit de vele paden in OSM, alsmede ingetekende (thema)wandelroutes, al dan niet gebaseerd op knooppunten.

Volgens mij ontkent niemand dat.

Trottoirs mappen “omdat dat kan” geeft toch geen of nauwelijks extra functionaliteit voor wandelaars?

In het algemeen weet de wandelaar dat wegen in het buitengebied geen trottoir hebben en als er sprake is van een begeleidend pad is dat vaak een gemengd fiets/voetpad en kan apart ingetekend worden omdat dat fysiek gescheiden is van de rijbaan door berm of anderszins. Zo ook weet de wandelaar dat in de stad of het dorp de straten meestal van een trottoir voorzien zijn of, zoals in veel woonwijken en woonerven straat en voetgangersstrook bijna ongemerkt in elkaar overgaan. Ook hier heeft de wandelaar en routeerder geen moeite mee.

Het niet (separaat) intekenen van trottoirs maakt de wandelaar niet lepreus denk ik.

Jij geeft het probleem zelf ook al aan: MEESTAL. Niet elke straat is voorzien van een trottoir.

Stel, ik wil niet omvergereden worden door een automobilist. Ik zoek dus uitsluitend straten op die zijn voorzien van een trottoir in een voor mij onbekende plaats. Hoe kan ik die vinden op de OSM?

Dan kan dat perfect ingetekend worden door aan de highway de tag
sidewalk=left|right|both|no|separate toe te voegen en is er geen enkele noodzaak het trottoir alsnog apart in te tekenen.

… en als aanvulling. Losse parallel footways geeft juist omwegen voor voetgangers. Je moet immers eerst naar een eindnode om een hoofdrijbaan over te steken. Zeker als iemand bedenkt om de hoofdrijbaan ook nog op slot voor voetgangers te zetten. In de praktijk kun je immers gewoon de rijbaan opstappen.
Het is dus juist in het voordeel van voetgangers om die parallelvoetpaden niet te mappen.

De manier die Martin aangeeft lijkt me prima.

Qua tijd loop ik net zo veel als ik fiets per jaar. In mijn woonplaats worden diverse wegen/fietspaden opnieuw geasfalteerd. Ik moest dus een nieuwe dagelijkse fietsroute maken. Als ik een route in Mapsource maak, blijkt dat ik thuis diverse routes (=tracks) kan maken die veelal over fietspaden gaan. Een nieuwe wandelroute kan ik thuis niet maken als die uitsluitend over trottoirs moet gaan. Ik loop altijd met mijn Etrex om het aantal gelopen km’s te meten. Er staat een fietskaart op, dus is het logisch dat de trottoirs er niet op staan, maar een OSM wandelkaart met trottoirs valt nu niet te maken.

Ik had het over weglaten van dergelijke extra tags, dus foot=yes bij footway, cycleway en path. En niet over tags die daadwerkelijk extra/nuttige informatie toevoegen.

Als foutieve tags zijn ingevoerd hoe kan een kaartenmaker dan weten welke fout is op basis van andere tags? Kun je een voorbeeld geven van wat je bedoelt?

:smiley:
Ik hoop dat die opmerking bedoeld is als humor en niet als argument.

Dit is zeker een drogreden want een karikatuur van mijn standpunt. Dat helpt de discussie niet verder.
Omdat wandelaars op veel plaatsen mogen komen is het juist van belang om selectief te zijn in hetgeen je expliciet aangeeft zodat je kwaliteit kunt leveren.
Stefan de Konink heeft er al eens op gewezen dat je concreet kunt bijdragen aan routering voor voetgangers in een stad als je werk maakt van veelgebruikte verbindingen zoals bijv. in het openbaar vervoer (bus- en treinstations). Dus het verbinden van o.a. perrons en bushaltes met het wegennet. Ik heb dat in Leeuwarden gedaan en HenkL heeft het op iets andere wijze in Groningen gedaan.
Dit zijn ook de locaties waar af en toe een trottoir wel echt een nuttige toevoeging kan zijn.

Als eerste zouden statistieken over verkeersongevallen per straat, oversteekplaats en kruispunt mogelijk meer soelaas bieden (tip: blijf in elk geval weg uit het centrum van Drachten!). De wegbeheerder zal normaal gesproken bewust hebben gekozen om trottoirs weg te laten. In een woonstraat zal het meestal een 30 km zone betreffen. Het grootste probleem is een geplande route voor een voetganger langs een drukke ontsluitingsweg zonder trottoirs.

Je kunt aan de slag gaan met sidepath=no voor zulke situaties. Kies een middelgrote stad die je goed kent en je bent mogelijk in een middag al klaar. Dat is veel realistischer dan het intekenen en bijhouden van alle trottoirs of dan het op alle stukjes weg aangeven of en waar er wel of niet een trottoir is.

Er zijn veel meer tagging mogelijkheden dan wegen/paden.

Highway=cycleway:

  1. bicycle=yes
  2. bicycle=designated
  3. bicycle=permissive
  4. bicycle=official

Bovenstaand schema wordt gebruikt door MKGMAP in de standaard default style. Alle 4 mogelijkheden worden gezien als een cycleway en op de kaart gezet als een standaard fietspad. Maar de maker van een gespecialiseerde fietskaart, kan aan de tag bicycle=permissive, of tag bicycle=official zien om wat voor weg/pad het gaat. Ongeacht de tag voor highway=, kan hij een speciaal kleurtje meegeven aan zo’n fietspad.

@Mattheus
Det meest voorkomende en enige situatie die ik zo kan bedenken waar het (uitgaande van consensus) fout gaat met highway=cycleway is waar het, op basis van (gebrek aan) bebording, officieel een algemeen pad betreft. In dat geval kan bicycle=* dit niet rechtzetten.

Of bedoel je foutieve tags in de zin van spel- en typfouten? Dan zou een defecte tag inderdaad kunnen worden opgevangen door een wel goed ingevoerde tag. Ik zie dan weer kans op verwarring als mappers worden aangemoedigd om telkens bicycle=* te gebruiken (vooral ‘permissive’ blijkt een lastige).

Natuurlijk kan dat wel. Nederlandse mappers hebben de term cycleway geassocieerd met een verkeersbord. MKGMAP associeert de term cycleway niet met een verkeersbord. Het is gewoon een pad waarover je kunt fietsen. Alle tags met ‘bicycle=’ betreft wegen/ paden waarover je kunt fietsen. Filter je op highway=*; bicycle=permissive, dan sorteer je de fietsmogelijkheden over voetpaden en privéwegen. Je zou zo’n fietsmogelijkheid een naam kunnen geven als ‘concessie fietspad/fietsweg’.

Filter je op highway=*; bicycle=designated | bicycle=official, dan sorteer je op de officiële fietspaden. Die noem je dan gewoon fietspad.

In deze voorbeelden kan highway=* allerlei soorten highways zijn. Als er fouten in de naam staan veegt MKGMAP die bij elkaar en maakt er highway=unclassified van. Dit is de ‘mop up’ regel.

Bovenstaande is een voorbeeld. De tekstfile bevatten natuurlijk verschillende mogelijkheden om een fietspad te renderen:

  1. highway=cycleway
  2. highway=*; bicycle=designated | bicycle=official

  3. 4 …

MKGMAP is een ouderwets MS DOS programma dat werkt onder de opdrachtprompt. De voorwaarden definieer je in een aantal tekst bestanden.

Ik zou niet weten waarom we MKGMAP als uitgangspunt zouden moeten nemen voor tagging, terwijl cycleway wereldwijd in OSM wordt gebruikt en in Nederland volgens mij goed functioneert. Alleen dat laatste vindt blijkbaar niet iedereen.
Volgens de defaults gebaseerd op de verkeersregels zijn ruiters in Nederland wel toegestaan op highway=path en niet op highway=cycleway. Ruiters worden vaak niet bewust meegenomen in de tagging en met bicycle=* en met een losser gebruik van highway=* is de toegang voor ruiters dan niet meer duidelijk.

Maar goed, ik weet te weinig van hoe de technische en praktische verhoudingen liggen tussen OSM enerzijds en renderers en routers anderzijds. Misschien kan iemand anders hier wat meer over schrijven of ik moet me er wat meer in verdiepen.

Goede vraag (en goede analyse ook eerder in dit draadje oa mbt wat “default” eigenlijk betekent).

Ik weet niet veel van routeren, maar vraag me -even los van de discussie hoe om te gaan met defaultwaarden bij taggen van wegen- bij het lezen van de documentatie wel af:

  • Is dat hele systeem van landspecifieke defaults obv de onderstaande tabel -dat steeds als argument wordt gebruikt voor het weglaten/wissen van tags- eigenlijk uberhaupt wel in werking?

http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions

http://wiki.openstreetmap.org/wiki/Proposed_features/Defaults

https://taginfo.openstreetmap.org/tags/type=defaults
17 stuks wereldwijd, op basis van bovenstaande opsomming voor de helft data van schoolvakanties

http://overpass-turbo.eu/s/sEU
Ook hier geen beeld dat er wereldwijd access-defaults zijn gemaakt, ook niet voor NL

http://brouter.de/brouter-web/
Ik ben geen programmeur, maar ook in de routeergegevens bij “profile” bij in ieder geval deze router zie ik geen verwijzing naar landspecifieke defaults.


edit:typo/opmaak

The mkgmap program takes OpenStreetMap data and generates a map in the Garmin .img file format so that it can be loaded onto compatible GPS units.

http://www.mkgmap.org.uk/

MKGMAP is een programma dat wereldwijd wordt gebruikt om kaarten te maken. Het is een universeel programma dat rekening houdt met de manier van taggen in diverse landen.

Het probleem is dat sommigen cycleway associëren met een officieel fietspad en de wet erbij halen om hun argumenten te ondersteunen. De default style van MKGMAP kent slechts één fietspad. Vanuit de routeerregels van de definitie bestanden van MKGMAP bekeken is een cycleway een ‘shortcut’ voor bicycle=yes, bicycle=designated, etc. Door de Nederlandse koppeling cycleway aan een officieel fietspad maken we gebruik van de shortcut. Het is de gemakkelijkste manier van taggen voor de Nederlandse situatie. Maar daarmee wijken we meteen af van wat gangbaar is in omringende landen.

Als we uitsluitend de default tags gebruiken en de mapper maakt een foute inschatting van de weg, komt die verkeerd op de kaart te staan. Een foute inschatting van een weg komt heel vaak voor. Als je meerdere tags gebruikt, kun je er rekening mee houden in de definitie bestanden.

Het gaat niet om het losse gebruik van highway=*. Een weg/pad heeft verschillende definities. De verschillen in de manier van mappen moet worden opgelost door verschillende definities te gebruiken. Wat wordt gerenderd als een fietspad in Nederland, moet ook in Duitsland worden gerenderd als een fietspad, ook al is de manier van taggen verschillend. Zelf heb ik kaarten gemaakt van Niedersachsen en Schleswijk Holstein en die voldoen prima.

P.S. Alle bekende fietskaarten, OpenFietsMap, Velomap, Radreiskarte om er enkele te noemen worden m.b.v. MKGMAP gemaakt.

Als iedere mapper de wegen op de juiste manier mapt/tagt, kunnen ‘default’ wegen in vele gevallen best voldoen. Het probleem is dat vele mappers niet op de correcte manier mappen/taggen, dus fouten maken.

Een voorbeeld. Op het platteland ergens in Noord Nederland is een weg waar de volgende borden staan: verboden toegang, alleen bestemmingsverkeer, fietsen toegestaan.

De weg was getagd als:

highway=residential
maxspeed=60
bicycle=yes
motor_vehicle=destination

Zelf zou ik enkele van bovenstaande tags anders hebben ingevuld. Als fietser/wandelaar heb ik er geen probleem mee, want de weg komt goed op de kaart te staan omdat er bicycle=yes bij staat. Als de ‘default mappers’ hun gang gaan en bicycle=yes verwijderen, dan komt de weg verkeerd op de kaart te staan.

Ik heb alleen ervaring met mkgmap. Mkgmap heeft landspecifieke defaults. Wat ik een probleem vind is dat die defaults met de hand ingevoerd zijn in het mkgmap ‘style’ formaat. Dus er is geen enkele koppeling tussen wat op de wiki staat en wat mkgmap doet. Hoogstens als het iemand opvalt dat er voor een bepaald land iets niet klopt wordt er iets aangepast.

Dan heb je nog het probleem dat als je zelf iets verandert in the mkgmap style, je weer met de hand dat soort veranderingen toe zou moeten voegen.

Volgens mij is het voornaamste conclusie gelet op de vraagstelling in dit topic:

  • Er zijn geen landspecifieke defaults formeel vastgesteld, ze zijn voor de meeste landen (waaronder NL) ook niet in een OSM-relatie vastgelegd en de constatering dat ook een veelgebruikt instrument MKGMAP geen landspecifieke defaults gebruikt bevestigt dat je -ook los van de overige genoemde argumenten- geen data moet gaan verwijderen alleen maar omdat die overeenkomt met de waarde zoals opgenomen in de wiki van het proposal default

Kan je uitleggen wat het verschil is? En welke kaart?

Voor zover ik weer is ‘bicycle=yes’ al de default (zowel wereldwijd als in Nederland) voor highway=residential. Dus een extra bicycle=yes zou nergens verschil uit moeten maken. Dat zou anders zijn als er een bicycle=designated zou staan.

Las dit na posten van laatste bericht.
Ik deel je bezwaar tegen misbruik van defaults als reden om data weg te gooien, het is wel een handig hulpmiddel bij het ontbreken van data.

Kennelijk gebruikt deze dataverwerker dus wel landspecifieke defaults, maar dat betekent niet dat wij alle data moeten weggooien die door deze specifieke data op een hoop wordt gegooid. Je kan weggegooide data niet meer herleiden als (a) MKG iets anders bedenkt of (b) een andere datagebruiker andere shortcuts wil hanteren

Ik wil bijvoorbeeld kunnen routeren over wegen waarvan in de database is vastgelegd dat er een vorm van toegang is (dus yes, permissive oid) en wegen vermijden die geen acces tag hebben (want dan is de access voor de gebruiker feitelijk onbekend en alleen de mapper weet of hij het zelf ook niet weet of dat hij het heeft weggelaten omdat het overeenkomt met een (welke??) default)