Opvolg: Uitgevoerd. Ik heb er toch zo’n 4 uur over gedaan! Dat is wel met aantekeningen maken erbij, en nazoeken van nog wat vraagpunten. Maar ik betwijfel of ik het onder de 2 uur krijg, zeker als er wat bizonderheden zijn. Want deze was wel behoorlijk standaard en symmetrisch, én hij was in de oude stijl al goed gemapt en getagd.
PS Stel dat we hier een projekt van maken, dan zou ik zeggen laat elke rotonde nacontroleren door een andere mapper. Er zitten zoveel dingetjes in dat er al heel gauw iets over het hoofd gezien wordt.
Misschien Turbo rotonde “opperhoofden” aanstellen ?
Als voorstel wil ik Peter_Elderson & Tjuro voorstellen, voordeel daarvan is dat als er nog nieuwe info ontstaat door bijvoorbeeld net andere ontwerpen van Turbo rotondes dit meteen meegenomen kan worden in de OSM wiki beschrijvingen.
Wat ik trouwens nog als nadeel bedacht van parallelle ways intekenen: navigatiesoftware zal altijd een van de twee kiezen (ook wanneer beide mogelijk zijn). Het liefst wil je natuurlijk dat er duidelijk aangegeven wordt dat beide banen naar dezelfde plek leiden. Dat zie je uiteindelijk waarschijnlijk wel ter plekke. Maar toch…
Erger nog, twee van de drie autorouters op osm.org slaan op een turbo hier vlak bij de speciale bypass voor rechtdoor over, en laten je over de rotonde rijden. Wat kan en mag maar niet de bedoeling is. Misschien omdat dat geen zijdelingse manoeuvre vereist?
Verder zijn er twee rotondes vlak achter elkaar, als ik rechtdoor over 2 rotondes wil hebben alle drie de routers een verschillende kombinatie van banen die ze kiezen.
Een navigatie die beide mogelijkheden wil renderen heeft daarvoor voldoende info denk ik. Hij hoeft niet een keuze te geven voor een van de twee rechtdoren, hij mag er 1 voorstellen. Als ik de andere neem dan hij voorstelt wil ik wel dat hij snel herberekent.
Ik heb inmiddels de wiki wat uitgebreid, kan zeker nog beter.
Dat is hetzelfde bij alle gesplitste baandelen, je wilt juist dat er één gekozen wordt, aangezien dat het optimale pad is. Maar optimaal is natuurlijk wel net hoe je dat instelt. Geef je een penalty voor junction=roundabout? En een scherpe of minder scherpe bocht? Etc.
Ik heb het vermoeden dat een toevoeging in de wiki als 'This type of roundabout is primarily deployed in The Netherlands" niet zou misstaan. Ook zou ik een cross in the junction=roundabout wiki naar de turbo wiki plaatsen, mocht dat nog niet gedaan zijn. Plaatjes van goede, reeds goed doormapte Carto voorbeelden zou een pre zijn “to get the idea” voor buitenlandse bezoekers.
Hoe zit het eigenlijk met kluif (turbo) rotondes. Doen we dan alle delen met junction=roundabout. Of alleen de rotonde delen?
Is een kluif rotonde één entiteit of zijn het twee entiteiten die aan elkaar gekoppeld zijn?
Als ik autorij kan ik zo’n hondebotrotonde niet als één rotonde zien, en ik verwacht voorsorteerbanen navigatiaanwijzingen ook per apart rondje.
Dus ik zou de tussenstukken niet als junction=roundabout taggen, maar als oneway=yes.
Of de tussenstukken een naam of ref moeten krijgen weet ik niet, en het higwaytype zou ik per rond-deel bepalen.
junction=roundabout impliceert al give_way en oneway. Met de geïmpliceerde houden alle drie de routers rekening, heb ik gezien. Het zou raar zijn als ze met de voorrang geen rekening houden, omdat de voorrang de junction als roundabout definieert.
Maar ik ga dat nog even apart testen!
OPVOLG: Beide turborotondes hebben expliciete give_way-knopen op de voorsorteerbanen, vlak voor de rotonde, waar de haaietanden staan. Dus dat is niet de enige verklaring!
Valhalla is de enige die de bypass pakt, OSRM en Graphhopper routeren via de rotonde. De bypass vergt een voertuigbeweging naar de bypassbaan, op het punt waar die ontstaat.
Valhalla pakt vervolgens op de tweede rotonde de buitenbaan, wat zonder baanwissel vanzelf gaat.
Graphhopper pakt op beide rotondes de binnenbaan, wat geheel zonder manoeuvres gaat.
OSRM pakt op de eerste rotonde de binnenbaan, maar op de tweede de buitenbaan, en daarvoor moet je wisselen naar een bereden baan.
In mijn ogen doet alleen Valhalla het helemaal goed: eerst de bypass, vervolgens in je baan blijven. OSRM raadt een onnodige baanwissel aan, dat vind ik fout.
Als ik deze rotonde pak (geen turbo, maar gaat om de bypass) OpenStreetMap dan routeren ze ook niet allemaal over de bypass richting Drachten. Bypass is gemapt als trunk_link, terwijl de rest (inclusief rotonde) gemapt is als trunk. Andersom zou mij logischer voorkomen, bypass als trunk en de rotonde als trunk_link
Bypass (dus volledig los van rotonde) lijkt mij een link-weg. De rotonde zelf absoluut niet. De rotonde in Drachten is dus correct gemapt, eventueel kan een rijbaanscheiding bij de opritten van de rotonde worden toegevoegd.
Je hebt een bypass die de (langzamere) rotonde om eventueel af te slaan vermijdt, maar die noemen we een link en de rotonde een trunk? Ik mis daar de logica. Als het een 2-baans rotonde was geweest hadden we er wel een trunk van gemaakt.
