Many routeplanners for cyclists use this path in their tracks. But this path is not accessible for bicycles, only for pedestrians. Is there a way to make this more clear, so the routeplanners work more properly?
Deze note viel me op. Hij is anoniem gepost, en is vrij specific. @Leo_Slager heeft daar de situatie iets aangepast.
Nu zie ik hier dezelfde note. Wederom anoniem. @Geim had hem bekeken, en die zag wat mij ook al opviel bij beide situaties; het gaat om voetpaden (footway) waarover ‘many routeplanners’ voor fietsers dus blijkbaar routeren. Dat lijkt me vreemd, want een routeplanner voor fietsen zou daar dan een fietser een behoorlijk stuk laten afstappen. Dat is mogelijk (en soms wenselijk), maar niet als omrijden misschien twee keer zo lang is. Daar maak je geen fietser immers blij mee („Stap hier maar even af en loop 300m, in plaats van 600m te fietsen over fietspaden.”)
Wat zit hier achter?
Dit lijken bijna geen echte gebruikersnotes, maar eerder door een algoritme gevonden situaties waar mappers dan op geattendeerd worden. Alleen valt er niet zo veel te fixen. Als dit notes op basis van een algoritme zijn, dan zie ik de auteur liever een keer het probleem hier uitleggen in plaats van anoniem (!) notes te spammen.
Komen deze notes vaker voor, of zijn het echt gewoon twee lokale opmerkingen?
Dan zal het toch een lokale gebruiker zijn die in het natte herfstweer ergens tussen Boazum en Wirdum een route plande over wegen/paden met niet bijster veel verkeer.
Het is vooral die ‘Many routeplanners for cyclists’ die het zo’n rare opmerking maakt. Geen van de drie op openstreetmap.org zelf doen het namelijk. Dan ben ik wel benieuwd welke dan wel.
Bij mij routeert OSRM fietsers wel over dit pad op openstreetmap.org. Dat lijkt te maken te hebben met surface=concrete. GraphHopper routeert fietsers zo te zien over highway=footway, surface=paved.
Alle fiets routers zouden over een voetpad moeten routeren maar dan wel met een flinke penalty, als fietser ben je voetganger als je de fiets aan de hand mee neemt.
OsmAnd gaat bij Boazum ook fout, bij Wytgaard niet, maar dat kan ook aan de lengte van de shortcut liggen.
Hier komt de harige discussie uit Tag:bicycle=dismount - OpenStreetMap Wiki weer naar boven. Hier mist een tag die zegt ‘je kán hier waarschijnlijk niet eens met een fiets komen, zelfs als je die aan de hand meeneemt’, in de lijn van wheelchair=no.
Met alleen het aanpassen van surface en bicycle=no op de veeroosters mist er toch iets aan data. Bij zowel Boazum als Wytgaard zijn de bruggetjes fysiek te smal, maar of routers rekening houden met width op een bridge=*? Daarnaast zit er ook nog wel verschil tussen surface=grass waar je door een zompig Fries weiland loopt en surface=grass bij een pittoresk dorpje in gortdroog Andalusia.
Dit zou al aan moeten geven dat je daar niet snel met een fiets overheen komt (niet tijdens normaal gebruik; je kan wel een lichte mountain bike over je schouder dragen wellicht, maar dat is niet nuttig voor het meeste gebruik), maar het is niet direct mogelijk om te zeggen ‘dit is een smal bruggetje met aan één kant een leuning en aan de andere kant niets’.
Missen we dan toch een bicycle_dismount=no, of moeten routers iets met width=* en bridge=*? Er zullen ook smalle bruggetjes zijn waar je wel overheen kan met de fiets namelijk…
Mee eens, fiets aan de hand meenemen is hier niet echt een optie. Zelfs met een fiets op je schouder is de alternatieve route logischer.
De route via de bruggetjes van het kruispunt (plaats, cyan pijl) naar de aansluiting van De Trochsnijing is 117 meter, de route via het fietspad 387 meter.
387/117 = 3.3.
15/4 = 3.7
Dus puur op afstand zou OSRM via het fietspad moeten gaan, waarschijnlijk heeft OSRM nog extra penalties voor de aansluiting van het fietspad met De Trochsnijing, zou goed zijn om zeker te weten.
Zie bicycle.lua hierboven, OSRM heeft ondersteuning voor width maar die staat “uit”:
-- Exclude narrow ways, in particular to route with cargo bike
width = nil, -- Cargo bike could 0.5 width, in meters
Ik denk dat er voor een goede inschatting van de fysieke toegankelijkheid meer nodig is dan alleen width: in het bruggetje op de foto zou een gemiddelde fietser met een lichte fiets misschien nog wel kunnen passeren als er geen reling was, maar met die reling erbij moet je jezelf in zo’n bocht werpen dat het wel een hele erge balanceeract wordt (ik praat uit ervaring ).
Een ervaren veldrijder zou er dan misschien weer minder moeite mee hebben.
Een samenvattende tag in de trant van bicycle:practical=zou denk ik wel handig kunnen zijn. Wordt wat meer subjectief, maar wel betekenisvolle data voor wat we proberen over te brengen. Belangrijk dus om de waarden goed te documenteren, beetje zoals de smoothness-schaal
Dat denk ik wel. Denk ook dat het goed is om onderscheid te maken tussen bruggetjes / wegen waar je praktisch gezien niet goed kan lopen met een fiets (met verschillen tussen personen en de fietsen die zich bij zich hebben) en plekken waar je niet mag lopen met de fiets, want die zijn er ook .
Op openbare wegen waar de toegang alleen met RVV-borden mag worden beperkt zal je dat niet snel tegenkomen (kan niet met onderbord onder een G7), maar op opengestelde eigen wegen kan de eigenaar het meevoeren van de fiets wel verbieden op grond van zijn eigendomsrecht / art 461-bepalingen
Ja, maar daar hoef je geen rekening mee te houden in een standaard fietsnavigatiemodel. Je hebt het dan over minder dan 5% van de fietsers immers. Navigatieprofielen die dat wel willen kunnen dan inderdaad met de fysieke maten gaan werken, zoals width op een brug. Sowieso is fietsen hier al niet toegestaan; enkel afstappen en de fiets meenemen. De navigatietools stellen deze route voor in een context van afstappen en lopen met de fiets.
Ja, er zijn genoeg wandelpaden over boerengrond waar je echt alleen als wandelaar welkom bent. Ook daar past een ‘fiets meenemen = nee doe maar niet’ goed.
Subjectief is hier prima. Dat geldt namelijk ook voor wheelchair=no. Anders zet je jezelf vast met allemaal uitzonderingen, terwijl het soms gewoon volstaat om met boerenverstand te zeggen ‘nee, dat gaat gewoon niet; dat zie je toch zo?’.
Er zouden twee keys nodig zijn dan, want fietsen en lopen met de fiets zou ik niet onder één tag scharen:
Dat profiel past gewoon de loopsnelheid toe voor afstappaden. Dat is waarschijnlijk veel te voordelig in veel gevallen, omdat afstappen an sich al een vertragende handeling is, en je met een fiets aan de hand lopend veel meer energie verbruikt dan gewoon lopend. Het zou een bug kunnen zijn in dat profiel.
Alleen zulke profielen tweaken lijkt me alleen niet genoeg, gezien bovenstaande. Soms is het niet haalbaar om een fiets mee te nemen voor het merendeel van de gebruikers.
Los van de discussie over nieuwe tags die interessant zijn voor de toekomst:
Binnen de bestaande tags ben ik benieuwd of zoiets al praktische uitkomst zou kunnen bieden:
Het hele ontwerp van de smalle brug vormt al een fysieke barrière om daar met een fiets overheen te gaan:
door de reling kan je niet de fiets rechtop op het achterwiel voor je uit duwen: dan raakt de fiets de reling
de fiets rechts van je boven het water dragen is lastig, want door de reling kan je niet goed tegenhellen naar links om in balans te blijven (en hand langs de reling schuiven geeft kans op splinters
En de brug bevat daarbovenop nog een extra barrière in de breedte, vlak voor het eind: zonder fiets stap je daar omheen, met fiets wordt het heel lastig
Dat lijkt me genoeg ground truth voor een node met iets in de trant van:
Alleen is de intentie van deze bruggetjes niet zo zeer het weren van fietsers. Een fietshekje voorkomt immers niet het meenemen van een fiets; de bocht haal je vaak wel, alleen niet fietsend. (Ah nee, dat is al gedekt door de aanvullende bicycle=*-tag.) Het kan wel, maar het rekt de tag wel iets op.
Naar intenties blijft het natuurlijk altijd gissen. Bij de extra barrière op het eind van het bruggetje zou het in het ene geval bedoeld kunnen zijn om vee binnen te houden, en bij het andere om fietsers buiten te houden.
Voor de barrier-tags geldt vooral de praktische uitwerking die de constructie heeft, en dat is hier dat toegang met fietsen aan de hand duidelijk praktisch wordt beperkt / belemmerd.
Het grappige is dus dat voor dat fysiek redelijkerwijs niet mogelijk de betekenis van bicycle=no al sinds mensenheugenis is opgerekt:
niet (alleen) een juridisch verbod (zoals bij bicycle=no op een highway=*, maar ook een praktische belemmering, specifiek wanneer het is toegepast op een node met de tag barrier=cycle_barrier
(zie bijvoorbeeld ook de versie van de wiki uit 2010, waar deze ruime interpretatie van bicycle=no op dergelijke nodes ook al in zat)
Misschien niet de meest pure en onderling consistente toepassing van een tag, maar wat mij betreft helder genoeg en langdurig gedocumenteerd en praktisch werkbaar.
).
