/*
Find all turbo roundabouts in Nederland currently mapped as 2-lane roundabouts
*/
[out:json][timeout:250];{{geocodeArea:Netherlands}}->.searchArea;
way
[junction=roundabout][lanes=2][“change:lanes”=“no|no”][roundabout!~turbo]
[roundabout!~turbo_lookalike]
[roundabout!~construction]
[roundabout!~proposed]
(area.searchArea);
(._;>;);
out meta;
Als ik een nepturbo tegenkom (bijvoorbeeld met alleen krijtstrepen ipv physieke scheiding, of met alleen een paar bypassbanen) dan tag ik het hele rondje met roundabout=turbo_lookalike, verder doe ik niks. Dan valt hij uit de query weg.
Zelfde voor roundabout=construction en roundabout=proposed. Die hebben meestal al iets met construction of proposed erin, maar zo vond ik het handiger.
Welke ga jij doen? Brabant en Limburg hebben er ook nog een stapeltje.
Ik denk dat je highway!~construction en highway!~construction nodig hebt om rotondes in aanleg en geplande rotondes eruit te filteren. Een rotonde in aanleg is bijvoorbeeld getagd met highway=construction en junction=roundabout, niet met roundabout=construction.
Ik heb ze zelf zo getagd. Op deze manier kan ik ze later ook makkelijker terugvinden; bij sommige lijken vooral de luchtfoto’s achter te lopen dus die wil ik een tijdje blijven checken. Maar het was zowizo voor tijdelijk gebruik bedoeld, alleen die turbo_lookalike (de el cheapo versie van de turbo) wou ik er wel in houden.
Belangrijker: omdat de routers zo achterlopen ben ik gestopt met checken. Maar dat wil ik wel degelijk gaan doen, alle turborotondes checken op routering, van alles naar alles via de rotonde. Daar wil ik ook een tijdelijk kenmerk (check:date?) en een query voor gebruiken, alleen dan niet op elk afzonderlijk stukje highway op een turborotonde. Ideeën?
Er bestaat zeker geen rotonderouteringschecker?
Ten eerste, de routing is niet getest. Ik wil niet afwachten tot gebruikers tegen eventuele foutjes aanlopen, en ik wil de 3 voorbeeldrouters vragen om zo mogelijk wat aanpassingen te doen.
Ten tweede: de instructie.
Wij vinden het natuurlijk heel apart dat het een turborotonde is die in Nederland is uitgevonden, maar in de basis is het voor OSM een meerbaansrotonde met fysieke baanscheiding die daarom met aparte ways gemapt kan worden.
Dus de hele vraag of iets wel een turborotonde is, en welk type en zo, dat maakt in OSM helemaal niet uit. Ook nepturbo’s die gedeeltelijk fysieke baanscheiding hebben kan je met aparte ways taggen voor het deel waar de scheiding ligt.
Dus misschien is het voor de internationale gemeenschap handig om het zo te presenteren, ipv als iets typisch Nederlands.
Ten derde, ik heb veel zaken genegeerd, zoals destinations, speed limits, refs, en heel veel mofa-meldingen e.d. Ik denk dat ik daardoor misschien ook wel fouten heb veroorzaakt. Dus daar wil ik nog aan werken, dat ik in ieder geval begrijp wat ik gedaan heb en de fouten op kan lossen. Tips daarbij zijn altijd welkom!
Ik ben nog aan het denken, in dit geval over de voorrang. Ik heb dit net in de internationale draad geplaatst, maar had dat beter hier kunnen doen denk ik:
Het gaat om de korte connectiestukjes tussen de buitenring en de binnenring. Die zijn junction=roundabout, wat betekent dat ze eenrichting zijn maar ook dat ze voorrang hebben. En dat is in feite niet zo: voor de voorrang zijn het nog inkomende banen die voorrang moeten geven.
Toch?
Als dat zo is dan zouden we misschien toch die stukjes niet als junction=roundabout maar alleen als oneway=yes moeten taggen. Voor de rendering en de standaard routering maakt het niet uit, alleen als de navigatie iets met voorrang gaat doen (bv tonen op een banenlayoutplaatje van de rotonde) dan zou het wel helemaal juist moeten zijn).
Jawel, dat is zo gedefinieerd in OSM. Het is hun schuld niet dat NL die regel heeft laten vervallen… wij eisen nu dat alle inkomende wegen borden/haaietanden moeten hebben, dan taggen we het roundabout, en dan zou de regel junction=roundabout geeft voorrang, moeten kloppen.
Juridisch geldt dat verbindingsstukje nog als het oprijden van de rotonde, denk ik, dus de praktijksituatie klopt wel. Maar een router weet dat volgens mij niet, die kijkt naar de tags op de ways.
je gaat van een niet voorrangs stuk(geen junction=roundabout) naar een wel junction=roundabout stuk, op dat moment moet je voorrang verlenen aan al het verkeer. Daarna zit je op de rotonde. als we de tussen stukjes niet taggen met roundabout dan zijn er twee voorrangs momenten en dat is niet zo.
Hm… dat is de situatie op de weg, er is één voorrangsmoment omdat het één weg is. Maar voor turbo’s tekenen we twee ways, dus de router ziet twee kruispunten en twee dwars inkomende verkeersstromen naar het invoegende voertuig. Hoe moet de router nu weten dat de tweede de voorrang van de eerste moet overnemen?
Voor de router is het alleen handig te weten waar hij voorrang moet verlenen en dat is bij een highway=give_way node en (net geleerd) bij de overgang van een normale weg naar een junction=roundabout.
Maar dat komt overeen met de situatie. De binnenste ring heeft geen voorrang op het tussen stuk. Er is geen voorrangs moment bij het tussen stuk want dat is daarvoor dan (hopelijk) al gebeurd.
ja maar dat gebeurt daarvoor niet meer op het tussen stuk. Als je eenmaal op het tussen stuk staat kan je niet meer voorang verlenen, dan ben je al op de rotonde.
Ja, dat klopt als de router alleen maar aan de bestuurder vertelt waar het voorrangsbord staat of waar de voorrang ingaat. En de router kan een penalty geven voor de weg waarop de give_way node staat of de weg ineens junction=roundabout krijgt. Dan wordt het redelijk overbodig om het tussenstukje ook nog een penalty te geven.
Ik zit in mjn hoofd met de gedachte dat de router iets met het kruispunt (de intersection van de ways) doet, en dat is eigenlijk helemaal niet zo. Hij ziet niet of er een auto aankomt op de binnenring om vervolgens te bepalen wie er eerst mag en dan NOODSTOP!!! te roepen.
Ik heb een issue geopend voor OSRM ondersteuning.
Het lijkt mij niet handig om drie ontwikkel-issues tegelijk te openen voor alle drie de routers op osm.org, dus ik heb willekeurig degene genomen met de letters van osm in de naam.
De andere komen ook, als we meer antwoorden hebben over wat er kan.
Voor de geïnteresseerden, vermocht je weer een waarschuwing in JOSM tegenkomen dat er een tegengestelde richting conflict is, dan is het hoogstwaarschijnlijk dat de oneway of way in tegenovergestelde richting is gemapt (met de klok mee) terwijl met de junction=roundabout er aangenomen wordt dat de routing antiklokwijs is. Gister weer een tegen gekomen waar de junction tag ontbrak en de rotonde met de klok mee getekend was. Na toevoeging gaf de validator een waarschuwing. De (Mijn) werkwijze nu is te verifiëren dat de weg pijltjes goed staan, desnoods R drukken om te reversen en dan pas the junction tag toevoegen.
Je kunt erop wachten tot iemand een rotonde bedenkt die een Turborotonde combineert met een Fietsrotonde. Als je die laatste nog niet bent tegengekomen kijk dan bijvoorbeeld naar de Luchtfoto Actueel Ortho HR aan de oostkant van de Campenhoefdreef in Tilburg.
Turbo’s hebben het voordeel dat de naderende autochauffeur net als bij gewone rotondes weet dat hij (vooral) naar links moet kijken want daar komt het verkeer vandaan. Bij een Fietsrotonde mag je niet vergeten dat er ook fietsers van rechts kunnen komen.
Dat faat wel eens mis. Dus wil Tilburg naar verluidt meer van die dingen aanleggen zodat men eraan went.
