Dat is altijd een dilemma, maar om ondersteuning te krijgen zit er niets anders op dan de tag te gebruiken; de documentatie en acceptatie ervan lijken in orde. Gelukkig lijkt restriction:conditional al breder in gebruik.
Als iemand een betere waarde voor de maximumlengte weet, of een andere beperking die daar zinnig is, houdt ik me aanbevolen. Ik zet die conditional er eerst maar zo in.
Waarom ben je niet met lanes:width verder gegaan?
Ik heb de situatie nog niet aangepast; width:lanes komt op de kruisende wegen. Die informatie alleen zou ook al kunnen helpen, maar zegt in theorie niets over de draaicirkel.
Eens, ik kan nergens iets vinden over maximale draaicirkel, maximale lengte zou dan een oplossing zijn.
verder vind ik implicit = yes een keurig oplossing om aan te geven dat er geen daadwerkelijk verbod is op basis van een bord, maar dat de situatie ter plekke het niet toelaat.
praktisch, zal men daar overheen rijden. binnenbocht draaicirkel en buitenbocht verschil.
Dat kan weer belemmerend zijn voor het recht doorgaande verkeer.
Oversteek:
Is de strook breed genoeg voor een vrachtwagen?
Waar rekent men mee. link
Vrachtwagen: spoorbreedte, 2.15 breedte: 2,55 (wettelijk maximum; voor
conditioneerde voertuigen 2,60)
Ik vroeg mij af, de auto, de draaicirkel …
De navigatie voor de auto is wellicht bij gebruik data het meest problematisch. Ondanks dat er width:lanes op staat.
Ingelum bereiken OSM graphhopper, dit wil je niet.
De baan van een auto, buitenwiel/binnenwiel, overhang “het vegen”. Nu staat er geen bollard op hoek verkeerseiland.
plaatje van link
bron afbeeldingen: ASVV 1996 (Aanbevelingen voor verkeersvoorzieningen binnen de bebouwde kom)
De hoek van het verkeerseiland, is dat het middelpunt van de draaicirkel? de straal zou dan zijn de breedte van de weg (max) tussen de kerbs, R=4.50 (overgang, 2 lanes, elk dan 2.25) R=4.00 (rijbaan, prov. weg)
Het binnenwiel mag niet over middelpunt cirkel (hoek verkeerseiland) heen komen.
only_straight_on @ (radius >4.00)
Hoe bepaal je max R= ?
Of moet je D= nemen ?
Hierbij ga je uit van de waarde van de situatie.
wiki turning_radius abandoned, het gaat even om de bepaling en de discussie page, argumenten.
Past het afslaan, baan voertuig, binnen de baan van het wegontwerp.
breedte, spoorbreedte, draaicirkel, wielbasis, overhang.
Lastig.
Ik heb het eerst zo opgelost: https://www.openstreetmap.org/changeset/125692920
Hier is geen mooie oplossing, want:
Geen beperkingen: navigatie voor vrachtwagens is ruk en onuitvoerbaar.
Beperkingen voor iedereen: komt niet overeen met verkeerssituatie, de wegbeheerder heeft er bewust geen fietspad van gemaakt.
Beperkingen op basis van lengte: arbitrair, wordt wellicht alleen door geavanceerde routers opgepikt, maar wel redelijke weergave van werkelijkheid
Beperkingen op basis van radius: arbitrair en zeldzaam; lijkt niet in gebruik in conditionals.
De beste oplossing is het aanpassen van de verkeerssituatie.
Wegbeheerders lijken niet altijd oog te hebben voor de gevolgen van een verkeerssituatie op de algoritmen van navigatiesoftware. Vroeger was een situatie als deze alleen bekend onder bewoners van het gebied; de rest reed er dan zonder nadenken langs, want je volgde de hoofdroutes op de kaart. Nu zal het meestal ook wel goed gaan, maar iemand die van Ingelum naar Menaam rijdt en niet lokaal bekend is? Dat moet wel haast over de ventwegen gaan met een stukje over de primary en dus een van deze rare afslagen.
Bij de rechtse oversteek mist dan nog data.
Goede conclusie.
Aangepast, dank je.
Wat zou de veiligheidsregio in liveop voor route nemen naar deze locaties? links en rechts van de autoweg.
Vanuit de kazerne Leeuwarden, route
Dat is dan wel een reden om zaken aan te passen.
Goede use case voor LiveOp. Goed voorbeeld ook van een verkeerssituatie waar de veiligheidsregio het beste iets kan zeggen over (hier grotere voertuigen van) hulpdiensten.
Inderdaad. en zoals Jeroen schrijft heeft navigatiesoftware de wereld verandert. In Nederland gaat het meestal goed en dit geval lijkt me een uitzondering. In Londen bijv. is sinds er navigatiesoftware is meer autoverkeer door woonwijken gaan rijden en dan krijg je als tegenbeweging zoiets als Low Traffic Neighbourhoods.
Graphhopper doet trouwens op de heenweg vreemd, waarom niet als brouter?
De andere kant op neemt Graphhopper driekwart van de rotonde…
Nog even verder gespeeld met routeplanners maar voor autoverkeer is de dit echt wel een logische route, stom dat een wegbeheerder zich er dan zo “makkelijk” van af maakt. Als fietser hoef je hier eigenlijk nooit te komen en met brouter in ieder geval kom ik er ook eigenlijk niet over.
Ik heb de maxspeed voor parallelwegen naar Ingelum en Bitgummole 60 km/h gemaakt. Dat is gebaseerd op zone A1 borden als je Ingelum en Bitgummole uit rijdt, ook hier is de wegbheerder bij de rotonde een steek laten vallen maar maxspeed:forward heb ik er niet van gemaakt.
Dat scheelt ook al in de navigatie trouwens.
Het pijnlijke is dat wij dat in Nederland al bijna standaard hebben, terwijl daar verstokte autorijders alle smoesjes die hier al lang van tafel geveegd zijn van stal halen om dat soort initiatieven te stoppen — kansloos op termijn gelukkig; wanneer een buurt om is wil men niet meer terug. We lopen ver voor op dat gebied.
Ook de giveway taggen? kan men gebruiken als kostenfactor.
Was er ooit een west afslag gepland?
Dit omdat aan die zijde de kerb niet door loopt.
En daar nu alles verhard is met grass_paver. Toch de bedoeling om er overheen te rijden.
Tussen enkele paaltjes mist ook een ketting.
(is het dan nu een afslag, krom gedacht)
Daar een volledige west afslag maken en bij de 3 oversteken een afslag restrictie uitvoeren.
Wat zijn dan de nadelen?
Ze stonden er wel voor 2015.
Ik vroeg me af of ze nog ergens anders stonden. (vroeger)
In de oude situatie hoef je eigenlijk geen zone 60 neer te zetten, wegens de doorgaande verplichting, gaat dan weer verder in een zone 60.
Op basis van de google streetview link van @Allroads nog eens wat rondgekeken maar welke logica hier is gevolgd is mij een raadsel. De oversteek van de Ingelumerdyk naar de Tsjerkeleane was ook een draak maar daar mocht je alleen recht oversteken.
Ik had ervoor gekozen gewoon deze verbinding te laten vervallen en de oversteek van de Menamerdyk en de Bitgumerdyk in stand te houden, niet deze vreemde parallelwegen.
Eventueel had men de kruising van de Ingelumerdyk en de N398, dat nu een ongelijkvloerse kruising is, is ook een rotonde kunnen maken zodat autoverkeer uit Ingelum redelijks rechtstreeks en een stuk veiliger op het autosnelwegnetwerk had kunnen komen.
Dat is wel een leuke stelling die wat verder gaat dan OSM. Moet een wegbeheerder rekening houden met navigatiesoftware, of moet de software zorgen voor een oplossing? Of is de gebruiker uiteindelijk degene die verantwoordelijk is voor zijn rij-gedrag.
Zo mag ik als fietser strikt genomen rondjes op de rotonde rijden ( is geen autoweg meer ). Maar zelfs als mijn navigatie dat zegt zou ik dat ter plekke wel uit mijn hoofd laten.
Zo kom ik wel vaker situaties tegen waar de navigatie misschien de ‘wettelijke’ route kiest, maar ik als gebruiker ter plekke een andere beslissing neem.
+1
Wat is er mis met het basis principe van OSM “Map What Is” ?
Survey buiten en verwerk dat, maar ga geen ideale situatie weergeven (creeren), maak dan je eigen wereld elders.
traffic_sign:direction=forward
Geeft niet de werkingsrichting aan van de give_way, wiki, daar gebruikt men direction=*
Zover ik weet is er niets gemapt wat er niet is.
Wat betreft traffic_sign:direction=forward, ja, traffic_sign:direction, net zoals traffic_signals:direction.
Voorrang verlenen (NL:B6) en Stop (NL:B7) zijn naar mijn idee verkeersborden dus vandaar maar ik zie nu dat het niet echt gemeengoed is.
Het volgende gaat dacht ik ook op “dont tag voor de renderer”, toch ?
Waarom maken we ons dan zorgen over de router ? Gaat daar niet hetzlefde principe voor ?
Plons, maar de router zei rechts af 
Blijft gezond verstand over zoals Noordfiets al verklaarde.
Als je deze verkeerssituatie bekijkt zie je dat we niets taggen wat niet daadwerkelijk (of in ieder geval bij benadering) het geval is.
Taggen voor de router zou zijn van deze kruisingen maar een cycleway te maken zodat ze niet routeren voor auto’s en de navigatie gewoon de hoofdwegen met fatsoenlijke kruisingen gebruikt.
Wat hier gedaan is, is de router potentieel genoeg informatie geven om de beste route te kunnen berekenen met weging van de beperkende factoren. Dat is nadrukkelijk een doel van de OSM data. Dit is dus een vraagstuk over hoe we in een aparte uitzonderingssituatie als deze de data beter kunnen maken zodat diverse data consumers er ook iets aan hebben.