verharde/onverharde fietspaden

Winkelier: “Wilt u verder nog iets?”
Klant: “Nee, een brood en een croissant”.

Hoe simpeler een script des te minder (kansen op) fouten, beter leesbaar, beter onderhoudbaar en sneller:

  • access=no & (bicycle=yes | bicycle=designated | bicycle=official | bicycle=permissive) {delete access}

  • (access=no | access=private) & bicycle!=* & bicycleroute!=yes & cycleway!=* & mtb!=yes {set bicycle=no; set motorcar=no; set motorcycle=no}

  • highway=unclassified & (access=no|access=private|access=destination) & bicycle=* & bicycle!=no & mkgmap:unpaved!=1 {add no_car=yes}

Fouten die gemaakt worden tijdens mappen zijn deels ook terug te voeren op dit soort communicatiefoutjes. Het is niet echt “fout”, maar de volgende mapper moet goed opletten wat er staat. Zeker als er veel tags staan, met [access=no] bovenaan (alfabetische volgorde).

Het eerste voorbeeld dat ik hier vlakbij zie:

  • access=no (er staat “immers” een [barrier=bus_trap])
  • bicycle=yes
  • highway=service
  • psv=yes
    Je mag er niet lopen! Maar het is 100% voetpad met een noodzakelijke doorgang voor psv. En je mag er ook fietsen.
    Meer correct zou zijn (IMO):
  • highway=service
  • motor_vehicle=no
  • psv=yes
  • service=driveway
    (Al vraag ik me wel af of de aanwezigheid van een bus_trap een unclassified of residential verandert in service).

Het volgende voorbeeld heeft wel [foot=yes] toegevoegd, maar vergeet ook weer [moped=yes]. Want een [barrier=bus_trap] heeft niet tot doel brommers tegen te houden.

Maar je hebt gelijk: volgens de WIKI mag het. Al suggereert “consider” wel dat je het slechts moet overwegen in het geval je inderdaad “Nee, een brood” wilt kopen. Maar of het “best practice” is? Ik betwijfel het.
Ik zie wel een verschil met [access=private]. Hierbij vind ik (…) [foot=yes/permissive] niet strijdig. Het blijft immers private, maar ik mag er wandelen.
Maar “no” + “yes”… ik begrijp het gewoon niet (of ik wil het niet begrijpen).

Weer even terug On Topic.

Het begon met [surface=fine_gravel].
Omdat ik had gemerkt dat we veel te veel prima, prachtige fietspaden aan het vermijden waren. Ten onrechte.
Sindsdien ook ontdekt dat er maar weinig onverhard in Nederland is dat wij niet kunnen fietsen. Tenzij je het opzoekt (MTB-routes). Maar wij kennen geen Sattelweg (zelfs lopen met de fiets is daar een uitdaging) en de surface=gravel=keien wegen langs de Oostzee weet ik hier ook niet te vinden.
Het enige probleem zijn echte zandpaden. Dat fietst gewoon niet, maar zijn dan soms wel weer te mooi om niet te lopen. Die nemen we op de koop toe.
Dus sindsdien routeer ik met onverhard vermijden = no en carpool lanes vermijden = no (want anders pakt de route nog steeds geen halfverhard).

En nu praten we over het dichtzetten van het fietsen op wandelpaden.
Maar met bovengenoemde instellingen stuurt Basecamp en Etrex 30 ons gewoon over [bicycle=no] heen. Recent tussen de auto’s over een rotonde omdat het fietspad een behoorlijke omweg maakt. MapSource routeert hier wel goed.

Dus [bicycle=no/permissive] is niet de meest effectieve discussie?

Garmin neemt OSM tegenwoordig ook serieus. Moeten we niet gaan klagen dat de routering van Basecamp/GPS voortdurend moeizamer lijkt te gaan verlopen? Al dan niet in combinatie met OSM?

Ook het dwingen van een route over onverhard heen (met onverhard vermijden aan) gaat steeds moeizamer.
Vroeger zette je een of twee viapunten juist óp de onverharde weg en klaar. Nu lijkt het dat je de viapunten zo kort mogelijk vóór en ná de onverharde weg moet zetten en dan hopen dat de route inderdaad onverhard volgt.
Zet je het viapunt óp de onverharde weg dat springt de route in vogelvlucht (rechte lijn) naar dat punt. (Is al eerder gemeld met een voorbeeld in België).
Ik heb ook situaties gezien waar dit probleem (viapunt op de onverharde weg) vermeden wordt door het viapunt op een kruising met de onverharde weg te zetten. Moet er wel een kruising aanwezig zijn op die weg.