Welke defaults worden door welke routers / profielen gebruikt?

Naar aanleiding van [https://forum.openstreetmap.org/viewtopic.php?pid=728213#p728213](de discussie over het verwijderen van tags die overeenkomen met een bepaalde bepaalde gekozen defaultwaarde )(met name de defaults genoemd in deze wiki van een abandoned proposal ) wilde ik eens beter in beeld krijgen hoe verschillende routers nu omgaan met defaults.

Nu zou dat op zich geen invloed moeten hebben op hoe we taggen:
-het zijn defaults voor routing, niet voor tagging
-we taggen net zo min voor router als voor de renderer, we moeten gewoon streven om correcte en zo duidelijk en volledig mogelijke data in de database te zetten, zodat elke dataverwerker (renderer, router, gis-analyse) daar op zijn eigen manier mee om kan gaan. Defaults zijn een handig en noodzakelijk instrument bij ontbrekende data.

Maar uit stijgende verbazing over het rotsvaste geloof van sommige mappers in een eenduidig, universeel, landspecifiek default-systeem, dat zelfs van onzekerheden (onbekende data) zekerheden weet te maken, toch maar eens onderstaande aanzet gemaakt.

Aanvullingen zijn natuurlijk welkom.

Mijn beeld op basis van onderstaande :

*Natuurlijk gebruiken routers defaults, en dat is maar goed ook, want vaak ontbreekt allerlei data
Met de lastige gevallen (zoals fiets op path; foot op cycleway) gaan routers en profielen anders om
De landspecifieke defaults uit de wiki lijken weinig gebruikt te worden, veel routers wijken daar van af
Los van in absolute zin wel/niet routeren over een bepaald wegtype, is de aanwezigheid van met de wiki-routing-defaults (zoals bicycle=yes op highway=path) ook van invloed op de costfactor die wordt gehanteerd, en daarmee op het resultaat
Iedere datagebruiker kan zelf de omgang met defaults zo tweaken zoals voor zijn doel (en dataset) gepast is. In een land met Allemansrecht zal je dat anders doen dan in een land vol met art. 461 WvS bordjes zoals Nederland

**Voorbeelden **

MKG-MAP (algemeen programma om Garmin-kaarten te maken vanuit OSM data)
Hier worden eerst OSM categorieën voor oa highway en access samengevoegd en vervolgens omgezet in categorieën voor Garmin-kaarten. Elke gebruiker van MKG-map kan deze instellingen aanpassen naar wens.

*Landspecifieke defaults
Er staan maar 3 landspecifieke defaults opgenomen in de standaardinstellingen van MKG (!), terwijl er op https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions 23 staan, en het aantal landen in de wereld natuurlijk nog veel groter is. Een snelle blik leert dat van de 23 opgenomen landen er veel meer dan 3 afwijken van de bovenste “default-default” tabel.

https://github.com/openstreetmap/mkgmap/blob/master/resources/styles/default/inc/access_country


# Spain (ESP)
highway=trunk & mkgmap:country=ESP { add bicycle=yes; add foot=yes }
highway=bridleway & mkgmap:country=ESP { add bicycle=yes; add foot=yes }


Meest opvallende is dat de default die MKG voor Spain gebruikt niet overeenkomt met die in de OSM-wiki voor Spain : MKG staat bij gebrek aan tags bicycle & foot WEL toe op brideways, de osm-wiki NIET.

Ik weet niet welke waarde het meest logisch is voor Spanje, maar gelet op de verschillende onjuistheden in de NL-wiki zou de waarde van MKG best wel eens beter kunnen zijn dan die van de OSM-Wiki

Verder staat er alleen nog maar:

# The Netherlands (NLD)
highway=trunk & mkgmap:country=NLD { add bicycle=no; add foot=no }
highway=cycleway & mkgmap:country=NLD { add foot=yes }
highway=bridleway & mkgmap:country=NLD { add foot=yes }

# Belgium (BEL)
highway=trunk & mkgmap:country=BEL { add bicycle=no; add foot=no }
highway=cycleway & mkgmap:country=BEL { add foot=yes }
highway=bridleway & mkgmap:country=BEL { add foot=yes }

Voor NL komt de conclusie voor bridleway niet overeen met de feitelijke juridische situatie: op een ruiterpad (RVV G9) mag je niet lopen. In de wiki staat dat nogal vaag, onduidelijk of MKG uit een andere bron heeft geput, of dat ze door de vage tekst in de wiki op het verkeerde been zijn gezet

Sowieso geeft de NL-default niet de geldende juridische default aan: deze is in NL namelijk permissive en niet yes; een weg is obv de Wegenwet pas openbaar als dat bewezen is; de bewijslast ligt bij de gene die zich op openbaarheid beroept en niet andersom. Maar ja, dit is dan ook een default voor routers (die zich om zulke details vaak niet zullen bekreunen, itt andere gebruikers)

Ook de erg bijzondere (en juridisch niet correcte) uitzondering in de NL-wiki tov de algemene default voor moped/mofa op path (yes ipv no) zie je hier niet terug, maar misschien negeert MKG deze categorieën gewoon helemaal, net als horse.

*algemene defaults (niet landgebonden)

De huidige standaardinstellingen van MKG volgen de default-default-osm-wiki grotendeels, maar ook niet helemaal:
volgens OSM-wiki zou Horse by default WEL op een path mogen, maar dat zie je hier niet terug (paarden lijken helemaal niet te bestaan na de dataconversie, want op een bridleway mag niemand komen…)

https://github.com/openstreetmap/mkgmap/blob/master/resources/styles/default/inc/access


38 highway=path  { add foot=yes; add bicycle=yes; add access=no } 
39 highway=bridleway { add access=no }

Verder ontbreekt in de default osm-wiki highway=track geheel…

Belangrijker in de context van de discussie over tagging, is dat de gehanteerde standaardinstellingen defaults bepaald niet bevroren zijn in de tijd:

In een van de verschillende wijzigingsoverzichten (die niet samengingen met een wijziging in de OSM-wiki) is bijvoorbeeld al te zien dat:

de standaard-MKG-default voor bicycle op path al eens is gewijzigd van YES naar NO (en 2013 weer van NO naar YES…) ;
104 - highway=path {add access = no; add bicycle = yes; add foot = yes} […]113 + highway=footway|highway=path|highway=steps {add access = no; add foot = yes} […]De standaard-MKG-default voor bridleway het verleden ook is gewijzigd: was in bovenstaand overzicht nog YES voor zowel bicycle als foot (is nu NO)

highway=bridleway {add access = no; add bicycle = yes; add foot = yes} [...]

Ik denk (en hoop) niet dat er toen mappers tags in de database zijn gaan omtaggen omdat opeens andere waarden volgens ‘hun’ router default – en daarmee “needless” zouden zijn?

*samenvoeging van OSM-highwaysoorten ook obv access-tags:

De dataconversie voor access en highway-types vind nu op twee plekken plaats (leek eerder geheel op onderstaande plek te gebeuren)

mkgmap/resources/styles/default/lines

highway=path & snowplowing!=no & (bicycle=designated | bicycle=permissive | bicycle=official)
{set highway=cycleway; set bicycle=yes}

Afhankelijk van de aanwezigheid van bicycle=* wordt een path kennelijk al dan niet omgezet in een cycleway

OFM (specifieke variant binnen MKG-MAP)

In OFM lijkt eea weer net even anders te gaan dan in de standaardinstellingen van MKG:

http://mijndev.openstreetmap.nl/%7Eligfietser/openfietsmap/Scripts/Styles/lines

highway=path & foot=designated & bicycle!=yes { set highway=footway }

Hier lijkt dus de **afwezigheid **(!) van bicycle=yes ervoor te zorgen dat een path wordt omgezet naar een footway.
(@Ligfietser: corrigeer me ajb als ik het verkeerd interpreteer)

Dat is dan wat je krijgt als je bicycle=yes verwijdert van een path *“omdat het default is” *
Hierdoor zal bicycle over dit path niet / minder snel wordt gerouteerd.

Hier zomaar een voorbeeld van een dergelijk pad (nu nog met foot=yes) waaraan veel forumleden al hebben gewerkt
Ik kan het bord op Mapillary niet lezen, maar paden zonder G13, maar met een art 461 gebiedsbord in de trant van “voetpad, fietsen toegestaan" is die tagging natuurlijk heel goed denkbaar. Zulke borden zullen er zeker zijn, is het niet hier, dan wel elders.

Tot zover wat ik kon opmaken uit MKG (hoewl ik wel zelf webkaarten maak, ben ik geen programmeur; ik doorgrond niet alles en moet me nog steeds een keer ertoe gaan zetten om zelf kaarten voor Garmin te gaan maken, dus constructief commentaar is welkom.

In ieder geval lijkt al wel duidelijk dat er GEEN volledige, eenduidige, en harde koppeling is tussen OSM-wiki en veel gebruikte dataproducten zoals routeerbare kaarten voor Garmin-apparaten.

En dat lijkt me ook maar goed ook, want voor elk doel en dataset kan een andere default het meest nuttig zijn.

Later meer over het soortgelijke beeld dat te zien is bij online routeerders (waarbij voor mij vooral de resultaten zichtbaar zijn en niet alles onder de motorkap).

Hier is een redelijk recent (18-04-2018) plaatje van het voorbeeldpad:

En hier het bord, niet die van het pad, maar een identiek exemplaar van een ander pad: