Fietsknooppunt route met openingstijden? Hoe verwerken

Fietsknooppunten die alleen kunnen worden gefietst als het betreffende hek open is. Wat doen we daarmee? Waar taggen we de opening hours op, gewoon op het fietspad zelf? Restricties meegeven in de knooppunt relatie? Andere manier?

Betreft een fietsknooppunt route door het museumpark. Eerst was dit een simpel lusje dwars door het museum (Route 50-31, zie OSM), nu hebben ze er een stuk fietspad aangezet. Het is een mooi nieuw stukje fietspad geworden, die zeker niet mag worden overgeslagen tijdens een fietstochtje. Ik heb een foto gemaakt van de situatie.

In OSM, de marker staat dus op het nieuw stuk fietspad met “openingstijden”.

Je kunt de openings_hours op het hek zetten,
Tot dusver wordt er niets met tijden gedaan in het knooppuntnetwerk, dat is ook erg lastig.
Het is in feite hetzelfde als een knooppuntroute die van een seizoenspont gebruik maakt of over een sunrise-sunset fietspad loopt,. Dat wordt ook niet in de relatie getagd en ook daar moet de gebruiker er zelf naar kijken.

restriction:conditional voor het fietspad zelf gebruiken is mischien nog wel een idee denk ik.
https://wiki.openstreetmap.org/w/index.php?title=Conditional_restrictions&uselang=en

Maar nee, denk eigenlijk ook niet dit in de route relatie gezet hoeft te worden. Mensen die voor een dicht hek testaan komen kunnen vervolgens wel het bordje met de omleiding vinden.

1 Like

@dvdhoven Klinkt logisch. Zie jij kans om in dit stukje de nieuwe fietsknooppunten te integreren? Mij gaat dat niet lukken :wink:

Daar ga ik mee aan de slag.

Het wel een zeer algemeen verschijnsel, dat er restricties zijn voor een route, die -als je er eenmaal voor staat- niet vanzelfsprekend een omleiding hebben. Als reiziger had je dat dus liever tijdens het plannen geweten, dan kan je immers uitzoeken wat de beperking precies is, of je er last van gaat hebben en wat het alternatief is. Misschien simpelweg een Pas op! tag?

Bijvoorbeeld “restriction=yes” zou al helpen, de kaart/planner kan dat met een rood uitroepteken renderen of zo, of met een aparte lijneigenschap. De restrictions zelf zijn dan volledig getagd op het hek of de way waar ze gelden, dat kan de gebruiker dan zelf uitzoeken.

Of specifieker: restriction=ferry, restriction=seasonal, restriction=daylight, restriction=dog, restriction=tidal, ik noem maar wat zaken waar ik met de wandelroutes (inkl knooppuntroutes) dagelijks mee te maken heb en die ik nu niet goed kan meegeven.

Ja, dat is een flink probleem.
Bij de FB hebben we een POI , niet altijd toegankelijk, die we aan wegen kunnen koppelen en die wordt in de routebeschrijving getoond.
Daarnaast spelen er ook nog eens fysieke beperkingen, die je ook graag wilt weten.
Bijv. deze step-over, voor mij is dit een zeer lastige hindernis (lokatie OpenStreetMap in de klompenpadroute Fliertpad):

Als het om een aangegeven omleiding gaat wel. Maar met name bij wandelen is het ontzettend vaak het geval dat er een reguliere beperking is (bijvoorbeeld een zomerveer of alleen bij daglicht, of niet met hond), waarbij geen route-omleiding wordt aangegegeven. Als je dan een alternatief moet zoeken loop je goeie kans om 5 Km om te moeten, wat voor fietsers nog wel gaat, maar bij wandelen echt veel is. Dit speelde ook al bij bergwandelroutes, en paardenroutes zijn ook niet vanzelfsprekend,… ik denk dat een generieke (en makkelijk renderbare) oplossing voor alle routes niet gek zou zijn. Vergelijkbaar met de “niet altijd doorgankelijk” POI van dvdhoven.

Om op jouw voorbeeld terug te komen, als er in een route 100 meter zit waar het verboden is voor een hond, wil je dus op de route zetten “verboden voor honden”, terwijl 90% gewoon toegankelijk voor honden is.
Verder ben ik er op tegen om data dubbel te taggen. Verboden voor honden staat al op de betreffende weg.

Nee, ik wil niet verboden voor honden zetten, want de route is niet verboden, maar een waarschuwing dat deze route een restrictie kent. Als die 100m de route niet onbruikbaar maakt, bijvoorbeeld doordat er ter plekke een omleiding aangegeven staat, dan is de route dus niet onbruikbaar en tag je de waarschuwing niet. Je kan dus niet uit de eigenschappen van de wegen afleiden of de route bruikbaar is. Het is dus niet dubbel taggen van het verbod; het is een ander niveau.

Verder wil ik natuurlijk niet alle routes taggen met alle mogelijke verboden, het gaat om waar nodig en redelijk kunnen aangeven dat een route een beperking kent.
In de praktijk zal een LAW in Frankrijk dit nooit krijgen, want die mappen alles bij elkaar ipv in etappes.
Ook LAW-etappes in NL niet, zoals ze nu gemapt zijn in dagetappes volgens de administratieve indeling van Wandelnet. Maar waar er bv een broedseizoenroute is, zou je het betreffende stuk van de hoofdroute in 1 relatie kunnen stoppen, waarop je de beperkende waarschuwing kan taggen. Zo’n stuk begint dan op het punt waar je als wandelaar de keuze moet maken, wat vaak een ander punt is dan het daadwerkelijke toegangsverbod.

Duidelijk, maar dan nog vind ik dat een hoger liggend systeem (de router) naar het lager liggend systeem (de data in OSM) moet kijken of er al dan niet een restrictie is i.p.v. dit 2x aan te geven. Want ook al geef je alleen maar een waarschuwing in de route relatie, deze is wel afgeleid van een verbod en zorgt zo voor dubbel onderhoud.

Dat is het juist: je kan uit de aanwezigheid van een beperking op een weg of knoop onderweg niet afleiden dat de route niet genomen kan worden.

Ook even uitkijken met vertalen naar wat een router doet: die rijgt wegen aan elkaar op basis van kenmerken van de wegen, vergeleken met de eigenschappen/wensen van de gebruiker (het profiel). Die gebruikt dus geen routerelatie. Ik denk dat je beter kan spreken van een planner, als het om het gebruik van routerelaties gaat.

Bijvoorbeeld, een knooppuntrouteplanner zou helemaal zonder wegen kunnen werken! Als er maar staat welke punten aan elkaar verbonden zijn, kun je van Rotterdam tot Groningen plannen.

Da’s voor mij geen reden om het in een routerelatie te zetten. Dat een router het niet herkent wil niet zeggen dat we het op de routerelatie moeten taggen. Taggen voor de router doen we toch niet?

Je voorbeeld van de knooppuntplanner snap ik niet. Ja je kunt een lijstje maken met nummers waar je langs moet rijden, maar wat wil je daarmee aangeven?

Dat is geen taggen voor de router, want 1. de router kijkt naar de wegen zelf en niet naar de routerelatie, en 2. het is taggen van een gegeven wat op dit moment door geen enkele planner/kaart weergegeven wordt, en als je het wél tagt, renderbaar/bruikbaar wordt voor alle software.

Ik zeg ook niet dat het moet, maar dat het een manier is om het gegeven op het juiste niveau vast te leggen zodat het beschikbaar is waar het nodig is: aan de begin/eindpunten van de routerelatie.

Het ging even over het niveau waarop het gegeven werkt. Een knooppuntplanner hoeft niet naar de wegen zelf te kijken om te kunnen plannen, alleen naar de knooppunten en de relaties ertussen. Wil je dan bepalende kenmerken van de knooppuntverbinding vastleggen, dan zitten die bij voorkeur op de relaties.

In het veld kom ik dit geregeld tegen, dat je gemarkeerde route in het broedseizoen een andere kant opgestuurd wordt, terwijl op dat punt/pad nog geen verbod geldt. De feitelijk verboden weg ligt dan verderop, en dat is precies waar de waarschuwing voor is: deze route in het broedseizoen niet nemen want dan kom je verderop in problemen.

Dan is het helemaal zinloos om het in de relatie te zetten. Als de router al niets doet met een routerelatie, wie gaat er dan wel wat mee doen?

V.w.b. punt 2, maar het is nu toch al beschikbaar? Waarom wordt daar niet naar gekeken?

Edit: typo

Inmiddels liggen de nieuwe fietsroutes op het nieuwe stukje fietspad. Ik ga nog even kijken of ik wat met de " Conditional restrictions" ga doen of dat ik toch meer details zoals barrier=gate ga toevoegen en daarop de “openingstijden” plaatst.

Het zou een mooie meerwaarde zijn als een fiets/wandel routeplanner een lijstje restrictions kan weergeven. Ik had zoiets wel in brouter verwacht, maar helaas.

Bedankt alle voor de inzichten.