Praktisch gezien zou je dat misschien deels aan de kant van de router kunnen oplossen door de gebruikers invloed te geven op de mate waarin / tegen welke kosten de router probeert om precies bij de pointer van het opgegeven eindpunt te komen (alternatieven voorstellen: eindigen verder van eind-pointer met lagere kosten op de ways in de route of dichter bij de pointer met hogere kosten in de ways op de route).
Anderzijds zouden wij als mapper routers wellicht kunnen helpen om meer locaties-specifieke afwegingen te maken door op parallele ways in OSM (die verkeerskundig tot dezelfde weg behoren) tags op aan te geven in hoeverre situaties doorsteekbaar zijn.
hop= : indicates wether an able bodied person can legally and reasonably cross over to a parrallel way in OSM that is legally part of the same road (such as from a highway=cycleway to a parralel carriageway or path). Cyclists may have to dismount.*
Natuurlijk voor liefhebbers te verfijnen met onderscheid naar vervoerswijze (wel voor voetgangers, niet voor fietsen of rolstoelgebruikers), specificatie van lengte en hoogte van de hop…
weet iemand of zoiets ergens al in gebruik / ontwikkeling is, we zouden toch niet de enigen moeten zijn die hier tegenaan lopen?
Mooi dat de discussie weer goed word opgepakt. Vanuit de wijk vereniging is er nu de behoefte om de toegankelijkheid van voetpaden in kaart te brengen. Ik werk nu aan een methode om de breedte van de voetpaden te bepalen. Ik zal deze methode delen en ook een stuk voorbeeld data.
Deze plaat toont gebouwen in rood en de voetpaden in roze. Om het een beetje verwarrend te maken zijn de wegen en de tuinen allebei wit, maar je begrijpt wel hoe het zit. Over het roze voetpad loopt een looplijn, eigenlijk is dit een “centerline” het midden van het beloopbare deel. Hiermee kunnen we nu de breedte van het voetpad bepalen. De TU-Delft heeft deze methodiek al eens gebruikt voor hun COVID social distancing dashboard zie de demo. Ik heb de door hen gebruikte methode bekeken en aangepast. Als leuk detail zie je op de hoek een boom staan en daaromheen twee routes. De ene is te smal voor een rolstoel de andere kan er krap omheen.
Hoe het een en ander gaat passen in OSM weet ik nog niet. Ik denk dat we allereerst de data gaan verzamelen en buiten OSM houden. Dan hebben we een beter beeld:
Welke situaties doen zich voor
Hoe vaak komen deze voor
Vervolgens kunnen we op basis van die inzichten kijken hoe verder te gaan.
In het kader van ‘hoe wel en hoe niet’ kom ik nog eens terug op de situatie in Surhuisterveen. Het is positief dat MapMan420 actie heeft ondernomen en meteen de intekening van trottoirs heeft aangepast.
De hier gekozen oplossing met boogjes om de parkeervakken lijkt me echter ook niet gewenst.
Met deze manier van werken en het gebruik van sidewalk-tags op de weg is de Groningerstraat over een werkelijke afstand van 340 meter opgeknipt in liefst 28 delen, dat is gemiddeld 12 meter per wegdeel. Nog een geluk dat daar geen bus-, fiets- of wandelroute loopt…
Dit illustreert volgens mij heel mooi dat het gebruik van sidewalk tags op de rijbaan-way ipv een aparte way voor een fysiek gescheiden -maar naastliggend- trottoir uiteindelijk een doodlopende weg is waarmee we onszelf steeds verder in de nesten werken.
Het regelmatig gepropageerde criterium “het mag geen aparte way zijn als het trottoir direct langs de rijbaan ligt, maar wel als er nog iets anders tussen ligt” is een houtje-touwtje oplossing voor een slechte keuze aan het begin, namelijk de gemakzuchtige keuze -die ik ook regelmatig heb gemaakt- om een feature (het trottoir) geen eigen OSM-element geven, maar alleen een tag op een ander element.
Ik vind het dan ook jammer dat de vaak inconsistente en nogal zwaar aangezette kritiek hier op de eerder door Mapman420 als aparte ways ingetekende paden ertoe heeft geleid dat hij veel van die paden heeft weggehaald. Veel beter was geweest als er constructieve adviezen waren gekomen hoe de specifieke problemen bij oversteken waren op te lossen.
Laten we allen vooral kritisch kijken naar de uitwerking van de soms wat vastgeroeste adviezen/(voor-)oordelen die vanuit dit forum regelmatig worden gegeven (met als triest dieptepunt: correcte data van anderen die zonder overleg wordt verwijderd, zoals hier aangehaald), in plaats van die kritiek te richten op een goedbedoelende nieuwe mapper die netjes werkt en zich volgens mij ook behoorlijk goed heeft ingelezen.
