"Turn restrictions" zijn leuk!

Ik had mij tot nu toe niet zo bezig gehouden met “routing”, maar ben mij de laatste tijd bij het reviewen van kruispunten steeds meer gaan realiseren hoe belangrijk “turn restriction” relaties zijn.

Er zijn heel veel kruispunten, en met name die van belangrijke hoofroutes door een stad met een gescheiden middenberm, waar het voor de routing niet genoeg is om slechts de juiste “lijntjes” met elkaar te verbinden. Het probleem is vooral voorkomen dat er ongewenste routing instructies worden gegeven.

Een klassieke situatie is bijvoorbeeld hier:

https://www.openstreetmap.org/#map=19/52.37148/4.62939

Komend van de Paviljoenslaan rechts, zou je de gedigitaliseerde lijnen en éénrichtingsverkeer volgend, theoretisch op het kruispunt met de Dreef een “u-turn” kunnen maken, en weer dezelfde weg terug de Paviljoenslaan op kunnen rijden. Voor de router is dit in principe een volkomen aanvaarde en doodnormale route.

Dat dit echter tot een kamikaze actie :expressionless: met een onmogelijke nauwe turn midden op een heel druk kruispunt zou leiden, weet de router niet. :frowning:

Enter “turn restriction relations”… Door de juiste turn restrictions toe te voegen, kunnen dit soort kamikaze acties voorkomen worden, en zal de router nooit zo’n idiote actie voorstellen.

Ik heb er in Haarlem inmiddels een redelijk aantal toegevoegd via de iD editor, waar dit heel makkelijk gaat. Merk overigens op dat veel van deze turn restrictions “technisch” nodig zijn, vanwege de manier waarop ons highway netwerk is samengesteld, en lang niet altijd met een ge- of verbodsbord alszodanig aangegeven.

Het is voor mij dus inmiddels een leuk spel geworden om bij elk nieuw kruispunt te bedenken, welke turn-restrictions noodzakelijk zijn om rare routing resultaten te voorkomen. Een soort “kruiswoordpuzzels” (ehm… “kruispuntpuzzels”? ;)), maar dan OpenStreetMap stijl! :wink:

Ik heb overigens inmiddels op een aantal kruispunten kunnen verifiëren dat dit inderdaad tot betere routing resultaten leidt, door op de website begin- en eindpunten voor de Graphopper en OSRM router op tactische plaatsen te droppen voor en na de wijzigingen (oh ja, voor iedereen die dat ook probeert: het kan wel een weekje duren voor OSRM en Graphopper de juiste resultaten weergeven, het lijkt erop dat er slechts een wekelijkse update van de onderliggende database is).

1 Like

Als eerste: Goed bezig!

Als tweede: Ik zou niet zomaar overal een turn restriction op zetten als het er niet expliciet verboden en compleet onpraktisch is, voor het hele land volhangt met turn restrictions die vervolgens niet begrepen worden en dan verkeerd staan (ik heb het eens meegemaakt)

Enkele van de meer notabele turn restrictions die ik toegevoegd heb zijn:

  • Op de wisselbaan van de A9: Ik reed over de Provincialeweg naar het zuiden en moest de A2 naar het zuiden (en dus eerst de A9 naar het westen) hebben, een reis die ik regelmatig andersom doe, maar nu niet meer kon. OSMand stelde voor de A9 naar het oosten te nemen en de wisselbaan en dan op de wisselbaan een U-turn te maken.
  • Kochstraat in Hilversum, een middenberm waar je niet door mag steken vanaf de zijstraat om linksaf te slaan. OSMand stelde dan maar voor om rechtsaf te slaan en na de middenberm een U-turn te maken…

Je hoort het op vele kruispunten te gebruiken, vanwege de bepijling.

Verkeerstekens op het wegdek zijn net zo belangrijk als verkeersborden.

RVV 78

In de Wiki staat een enigzins vergelijkbare waarschuwing voor bloat in de database. Ik denk hier echter anders over. De angst voor een oneindig aantal onbegrepen turn restrictions lijkt mij klein: het aantal benodigde turn restriction relaties in een gemiddelde stad in NL is echt maar relatief beperkt als je het afzet tegen het aantal gebouwen, tuintjes, hekken, bomen etc. Ik durf zelfs te zeggen dat het maar een fractie is.

In termen van database records en database bloat zie ik dus echt geen enkel probleem.

Daartegenover staat een eenduidige en niet ambigue routering dat geen rare suggesties meer kan doen: volgens mij een groot voordeel!

Ook zijn turn restriction relaties relatief snel en makkelijk te begrijpen. Zeker als je het vergelijkt met hoe de newbie tegenover multipolygonen staat. Ook daar zie ik dus niet zo’n probleem.

Als laatste: het zoals in de Wiki voorgestelde om geen turn restriction te mappen die niet expliciet van borden zijn voorzien (“are not signed”), is volgens mij contra-productief

Ik ben hier in Haarlem al vele plaatsen tegengekomen, waar expliciet borden stonden met verplichte rijrichting (alleen rechtdoor), vlak voor een kruispunt waar een éénrichtingsweg uitkwam op de weg met het bord, en je van die kant er niet in mocht rijden. In een dergelijke situatie, moet juist niet een turn restriction worden aangemaakt (althans is het volkomen zinloos voor routering, want die gaat al goed dan), zoals ook de Wiki onderkent:

“There is no need to restrict turning into the wrong way of a one way street. This is taken for granted.”

Zouden we in NL met zijn borden manie dus slaafs de Wiki volgen en alleen borden gaan mappen, dan worden er juist vele zinloze turn restrictions toegevoegd, terwijl de technisch noodzakelijke, maar niet beborde restricties, gemist worden! Daar schiet je vanuit de routering bezien dus niets mee op…

Een doorgetrokken streep, na een kruispunt, waar stroken samen komen. Na…

Key overtaking

RVV76

Toch bekijk ik iedere turnrestrictie die ik tegen kom met enige argwaan.
Noodzakelijk of niet ?

Maar ja, dat wordt veroorzaakt door ervaringen zoals in Heerhugowaard.
Die plaats werd vol gezet met turnrestrictions om te voorkomen dat een auto een fietspad op draait.
Of om te voorkomen dat een auto een doodlopende weg inrijdt, wat uitdrukkelijk niet verboden is !
Of om te voorkomen dat een auto een paar paaltjes omver rijdt.

En dat soort restrictions kunnen gewoon verwijderd worden.

Interessante zaak.

Dit lijkt een beetje analoog aan taggen voor de rendering en nu taggen voor de router.

Ik ben het grotendeels met Leo en IIVQ eens: waar geen explicite turnrestrictie staat deze niet mappen. Wat wettelijk mag, misschien routeringstechnisch niet handig of zelfs gevaarlijk is, kunnen we niet “omdat de routeerder dat fijn vindt” naar willekeur voorzien van een turnrestrictie (of ander verbod “dat ons uitkomt”).

Vergelijkbaar ook met het topic om op- en afritten van een niet wettelijke lagere maximumsnelheid te voorzien omdat de routeerder denkt dat de afrit af en de oprit op sneller is. De routeerder moet gewoon meer strafpunten geven aan een op- en afrit, een kruisende weg, stoplichten en dergelijke. Mappers mogen dat, met alle goede bedoelingen, niet kunstmatig en onjuist forceren.

Dat de wegbeheerder wat steekjes heeft laten vallen door op- of afritten ook niet van de maximumsnelheidsborden doet hier niet ter zake.

En turnrestricties naar doodlopende wegen, paaltjes, fietspaden, eenrichtingswegen zijn natuurlijk onnodig en dus ongewenst.

En tenslotte: de weggebruiker is geen robot (gelukkig) en als bestuurder de situatie ter plekke, die heel wat dynamischer is dan een kaart, blijven beoordelen blijft van onschatbaar belang. Als iemand de veerstoep af in het water rijdt omdat de veerboot net even onderweg was: wie valt dat aan te rekenen? :slight_smile:

Dat zal echter niet lang meer duren, autonoom rijdende auto’s zijn in opmars en die hebben juist wel voordeel van een juist gemapte omgeving (uiteraard is dat ook niet het enige waar ze zich op baseren).

Maar ik ben het volledig eens met de gedachte dat je niet overal waar het niet verboden maar misschien onhandig is turnrestricties moet gaan plaatsen. Op plekken waar je sowieso niet logisch zou afslaan zou ik ze ook niet plaatsen. Wat je bijvoorbeeld ziet in dat eerste voorbeeld https://www.openstreetmap.org/#map=19/52.37148/4.63017 is dat er een turnrestriction no_right_turn gezet wordt op het kruispunt met Dreef en Paviljoenslaan, omdat je bij rechtsafslaan de rechtsafbaan gebruikt. Een dergelijke restrictie is natuurlijk overbodig om te maken omdat je daar niet komt.

Nogmaals: hier in Haarlem komen veel expliciet beborde “turn restrictions” (meestal gebodsbord “Alleen rechtdoor”) juist niet in aanmerking om in OSM in te voeren: ze zijn volstrekt overbodig vanwege eenrichtingsverkeer / oneway tags in OSM. Zo door het centrum fietsend, denk ik dat het wel om 50% van alle “turn restriction” gebodsborden gaat, misschien zelfs wat meer… Ik ben persoonlijk dus zeker geen voorstander van het zich beperken tot alleen expliciet aangegeven turn restricties karteren, dat levert gewoon niets op…

Volledige mee eens, die voer ik ook niet in. “Kruispuntpuzzels” zijn leuk, maar ook ik kan mijn tijd wel beter besteden dan onzinnige restricties in te voeren. Ik doe alleen de (technisch) hoogstnoodzakelijke.

Wat er in Heerhugowaard verder is gebeurd weet ik niet, maar dat staat hier los van.

Je verwart alleen expliciet beborde “turn restrictions” aangeven’ met alle expliciet beborde “turn restrictions” aangeven’. In het tweede geval zou dat afgaande op jouw percentage nog altijd zo’n 50% opleveren en niet niets… In het eerste geval levert het in principe 100% op. Dat eerste geval is wat de Wiki aangeeft en wat de reageerders hier aangeven.

Jij komt echter aandragen dat er situaties zijn zonder expliciete bebording waar toch “turn restrictions” gewenst zijn (en er dus zo bezien geen 100% score is).
Daar zie ik verwarring ontstaan omtrent “ongewenste routing instructies”.
Want wat wil je?

A. Wil je niet-verboden maar volgens jouw inschatting ongewenste of gevaarlijke verkeersbewegingen voorkomen?
B. Wil je verboden maar niet expliciet met bebording aangegeven verkeersbewegingen voorkomen?
C. Wil je technische tekortkomingen van routers oplossen via de OSM-database?
D. Wil je technische beperkingen van routers oplossen via de OSM-database?

Ik lees in reacties vrees voor A. In jouw schrijven zie ik geen bevestiging noch ontkenning.
Ik lees ook vrees voor C, een vorm van ‘taggen voor de router’: als mapper onjuiste routering willen voorkomen waar de router dat zou moeten oplossen.

Graag lees ik het van je maar ik zou denken dat je meer zoiets als B en D bedoelt.
Wat betreft B: zie de reacties van Allroads. Dit is van toepassing op het voorbeeld in je openingspost.
Die verkeersregels kan de router niet kennen. In theorie zou de router het kunnen afleiden indien de turn:lanes-tags allemaal correct zijn toegevoegd.

En dan kom ik bij D: er kunnen situaties zijn waarbij de data in de OSM-database in principe correct en compleet is, waarbij er onjuiste routering optreedt en waarbij het vanwege technische beperkingen niet realistisch is om van routers een oplossing te verwachten.
Hierbij zou ik niet te snel conclusies willen trekken voor of tegen, en bij voorkeur de mening vragen van mensen die ervaring hebben met het schrijven van routeringssoftware.

Nee, het is niet de taak van de OSM-gemeenschap om de output van rendering en routing op orde te brengen.
Ja, het is wel de taak van de OSM-gemeenschap om de OSM-data bruikbaar te maken en te houden.

Ik denk niet dat dit onder “taggen voor de router” valt. Bij “taggen voor de rendering” worden er bewust foutieve of op zijn minst discutabele tags gebruikt, daar is bij het toevoegen van turn restrictions zo als ik doe op deze kruispunten in Haarlem geen sprake van.

Het zou pas “taggen voor de router” worden als ik turn restrictions zou gebruiken om een 800 km lange route naar mijn vakantieadres in Frankrijk geheel van “Alleen rechtdoor” beperkingen te voorzien voor alle honderden kruispunten waar ik overheen moest in een poging om voor de router mijn favoriete touristische route te forceren… :wink:

Volledig met je eens dat de weggebruiker geen robot is, maar misschien vindt ik juist *daarom * het verstandig dat er wel in deze situatie turn restrictions worden toegevoegd. De veiligheid van het verkeer staat of valt met het vermogen van ons als mensen om tijdig op verkeerssituaties te kunnen anticiperen. Alles dat je - al is het maar een fractie van een seconde - afleidt, kan potentieel tot een ongeluk leiden. Een router die een onverwachte instructie geeft om op een groot druk kruispunt “om te keren” waar het redelijkerwijs niet kan, kan precies zo’n aan een ongeluk bijdragende factor zijn, doordat de bestuurder even heel kortstondig in de war raakt en afgeleid is.

Hier in Haarlem heb ik, vlak na een ingrijpende wijziging bij het station waar een weg voor automobilisten werd afgesloten en alleen fietsers nog door mochten, maandenlang automobilisten in verwarring gezien, waarbij er één zelfs doodleuk de fietstunnel inreedt. Als we dat soort toestanden en een potentieel dodelijk ongeluk kunnen voorkomen met wat turn restrictions, dan is dat voor mij persoonlijk een uitgemaakte zaak (overigens: in dit specifieke geval van die fietstunnel in Haarlem spelen turn restrictions juist geen enkele rol, de juist highway=x tags regelen het al af, en ik heb hier dan ook zeer zeker géén turn restrictions aangebracht).

Dank voor de heldere analyse Andries! Maar ik reken mijn werk toch vooral onder D, en niet onder A.

Wat “in principe correct en compleet is”, valt voor een wegenbestand als OSM nauwelijks te bepalen en is grotendeels subjectief, want het hangt van je gebruiksdoel af. Als je alleen maar een kaartje wilt met lijnen waar wegen zijn, hebben we zelf niet eens de volledige highway=x tag nodig met al zijn onderliggende wegtypes, classificeer alles maar als highway=road en voilà we hebben een kaart!

Over techische beperkingen: Ik heb zelf jarenlang professioneel in de GIS (Geografische Informatie Systemen) branche als ontwikkelaar rondgelopen, en weet hoe complex het werken met sommige (wegen)bestanden is. Ik ben zelf altijd een groot voorstander van het in de IT wereld welbekende KISS (Keep It Simple Stupid) principe geweest. Verwachten, zoals in de onderstaande OSM Wiki quote staat, dat alle routing engines maar even de wegen- en verkeerswetten van alle 190+ landen op deze aardbol op een of andere magische wijze via b.v. AI “uit hun hoofd leren”, en daarmee volautomatisch in al die landen de juiste beslissingen zullen nemen, is in mijn ogen een volstrekte utopie…

“Turn restrictions” zijn een KISS oplossing voor de problemen met routing. Ze zijn eenvoudig te implementeren in software, niet moeilijk voor gebruikers om mee te leren werken, en lossen potentiële problemen met routing eenduidig en niet ambigue op. Waarom zouden we ze dan niet willen gebruiken in deze situaties?

Het feit dat een inmiddels groot bedrijf als Mapbox, met zijn honderden van over de hele wereld geplukte talentvolle ontwikkelaars, ook voor turn restrictions hebben gekozen als de enige logische KISS oplossing voor deze problemen (zie b.v. deze blog https://labs.mapbox.com/mapping/adding-turn-restrictions/)), zegt genoeg… Als zij als grote organisatie al geen andere redelijke oplossing zien of realisterischerwijs denken te kunnen implementeren, wie dan wel op deze aardbol???

Quote van de Wiki pagina van turn restrictions:
“Don’t map turn restrictions that are the default for a given jurisdiction and are not signed. It is much better to ensure that routing engines embody the regional rule rather than mapping every occurrence as a turn restriction. This applies particularly to unsigned U-turns in Brazil, where using turn restrictions will require hundreds or thousands of restrictions and micro-segmentation of all roads which in turn make editing data hard.”

Andries: wij hebben überhaupt geen taak als OSM-gemeenschap… OSM is een *vrijwilligersproject * wat voor het grootste deel draait op het principe van “vrijheid/blijheid” waarbij het iedereen is toegestaan om zijn eigen weg te volgen. Hooguit is het prettig / gewenst dat we ons aan bepaalde wel of niet geschreven regels houden. Het maakt je leven als OSMer in ieder geval een stuk makkelijker als je dat doet, want ik denk dat niemand het prettig vindt om continue al zijn wijzigingen gerevert te zien worden. OSM functioneert bij de gratie van kuddegedrag (en ik heb geen mening of dat goed of slecht is, het is wat het is wat mij betreft).

Tot slot: het aantal (technisch) benodigde turn restricties is echt relatief beperkt. Voor zover ik het nu kan zien, heb ik in een middelgrote stad als Haarlem, slechts enkele tientallen turn restricties nodig om de boel af te dekken. Dat is volstrekt te overzien, en staat in geen verhouding tot alle andere enorme efforts van onze NL OSM leden om b.v. alle Nederlandse wandel-, fiets-, bus- en treinroutes in te voeren en bij te houden in OSM. Ik zie dan ook persoonlijk geen enkel bezwaar om deze toe te voegen. Het staat verder natuurlijk iedereen vrij om zijn eigen beslissingen te nemen op dit vlak.

Denk je niet dat wanneer je OSM aanpast om de technische beperkingen van de routers op te lossen (D), aan het taggen bent voor de router?

Nee, zie mijn reacties in de vorige post. Het staat je vrij om een andere mening te hebben, maar ik denk dat ik mijn persoonlijke zienswijze duidelijk genoeg heb gemaakt, ik weet er in ieder geval niets aan toe te voegen.

Je bedoelt dit?

(Met een smiley, maar wat je daarmee bedoelt?)

Nee, dat is niet taggen voor de router, dat is vandalisme.

Taggen voor de router/renderer is het aanbrengen van aanpassingen in OSM die er in werkelijkheid niet zijn, om de beperkingen van de renderer/router te verhelpen.
Taggen voor de router is b.v. een weg die nieuw asfalt krijgt op construction zetten i.p.v. er een conditional access=no op te zetten.

Ik vind het prima dat jij op onoverzichtelijke kruisingen gebruik gaat maken van turn-restricties, maar dat is gewoon taggen voor de router.

Wat is werkelijkheid? Dat is iets hoogst subjectiefs als het gaat om de vertaling van wat wij in de buitenlucht zien liggen naar een data-model. Ik zie het meer als het aanvullen van ontbrekende stukken in het data-model en het geven van hints aan de router.

Dat laatste, geven van hints, doen we eigenlijk al continue. Als jij een tracktype=x or surface=x zet op een wegelement, of een mbt:scale=x, ben je feitelijk ook subjectieve hints aan de router aan het geven, omdat je daarmee vaak wilt zeggen “hier niet komen met dit of dat type vervoersmiddel”. Ook in die gevallen is er vaak in de buitenlucht geen bord te zien die deze “werkelijkheid” wettelijk zou moeten bestendigen. Wijs mij de borden met tracktype of mbt:scale maar aan… ze zijn er niet!

Ik hoor werkelijkheid niemand daarover klagen, terwijl turn restrictions er nauwelijks van te onderscheiden zijn als het gaat om het effect. Iedereen vindt het vanzelfsprekend dat we aangeven dat je een four-wheel drive nodig hebt om een bepaald pad te volgen, maar een onmogelijke u-turn mag niet gezet?..

Weet niet of ik dat zou doen, speelt hier in ieder geval geen rol. En wanneer iets nu als “construction” moet worden beschouwd, is ook best vaag, maar tot zover…

Dat staat je vrij om te vinden, iedereen mag zijn mening hebben over dit.

Ik vind dit persoonlijk een drogargument: een afslagrestrictie is een wettig door borden aangegeven verbod en zo objectief als het maar zijn kan.

Een tracktype is inderdaad min of meer subjectief (zelfs het weer speelt een rol) en zegt dus ook niets over een (wettig) verbod. Als ik met mijn racefiets over een tracktype=5 wil, dan mag dat; of het slim is, is een andere vraag. Maar als ik dat als masochist wil, dan mag dat.

Het aanbrengen van een afslagrestrictie impliceert een verbod dat er in jouw voorbeeld niet is. Onhandig, ongewenst of gevaarlijk mag je niet middels een expliciet verbod afdwingen. Dat is aan de wegbeheerder.

De te volgen stappen zijn: jij meldt aan de wegbeheerder dat naar jouw mening een afslagverbod ontbreekt en vraagt dat de wegbeheerder aan te brengen. Nadat de wegbeheerder dat gedaan heeft (onder de voorwaarde dat die het met jou eens is) kun je de turnrestrictie aanbrengen in OSM.

Ik ben van mening dat als het over duidelijk is dat een bepaalde afslag niet genomen dient te worden, ook als is het misschien niet aangegeven met borden of belijning, dat een turn_restriction geen taggen voor de router is. Je geeft immers de bedoeling van de situatie weer?

Dan kun je ook stellen dat het taggen van de maxspeeds op snelwegen taggen voor de router is, aangezien daar een maximum snelheid van 130 km/uur geldt, met overdag de uitzondering van 100 km/uur (zo is het bebord). Maar we hebben er voor gekozen om het andersom te taggen, omdat er routers zijn die de conditional tags niet goed overnemen.

Kun jij mij een voorbeeld geven waar het wettelijk is toegestaan om af te slaan, maar toch overduidelijk is dat dit niet de bedoeling is (en even in het achterhoofd houden wat Martin gezegd heeft in de laatste alinea van zijn laatste bijdrage).

Hier is wettelijk gezien een U-bocht toegestaan, maar door de krappe draaicirkel onmogelijk: https://www.google.nl/maps/@52.7177724,6.517823,3a,75y,205.04h,73.61t/data=!3m7!1e1!3m5!1svwrvfERXgC9JN6yiQBqS6w!2e0!6s%2F%2Fgeo1.ggpht.com%2Fcbk%3Fpanoid%3DvwrvfERXgC9JN6yiQBqS6w%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D53.255486%26pitch%3D0%26thumbfov%3D100!7i13312!8i6656
Los van het feit dat je dan ook nog verkeer kunt treffen waarbij het verkeerslicht ook op groen staat.
Natuurlijk, men moet zelf inschatten of je ergens in kunt rijden, maar het is toch niet verkeerd door extra info mee te geven dat iets niet de bedoeling is?

Mijn autootje kan die u-bocht echt wel halen hoor.
Overigens is de u-bocht daar wettelijk verboden door de voorsorteervakken met pijlen op het wegdek.
De bestuurder is verplicht die pijlen te volgen en dus links af te slaan.

Maar veel belangrijker is, dat er geen één navigatie is die daar een route neerlegt die de u-bocht in zich heeft.

Zo een u-bocht is voor de bestuurder alleen wenselijk als hij van de oorspronkelijke route afwijkt.
En dan wordt die u-bocht ook nog eens niet opgedragen.
Een zachte vrouwenstem vraagt dan vriendelijk “keer om alstublieft” (daar waar dat mogelijk is).
En dat kan ook door 2x te steken als je de bocht niet haalt.

Ergo, ook op deze locatie is een turn-restriction volkomen overbodig.