Verkeerslichten met voorrang

[emvee]

In Nederland is het gebruikelijk om bij kruisingen met verkeerslichten ook voorrangsborden en markering staat voor het geval dat de verkeerslichten niet werken.

Verkeerslichten gaan boven verkeerstekens die de voorrang regelen.

De vraag is hoe dat te mappen.

Alleen highway=traffic_signals lijkt me prima.

Sommige mappers mappen graag details en dan komt er één of twee keer highway=give_way + road_marking=give_way bij.

Ik dit zie ik als problematisch omdat je in >99% van de tijd geen voorrang hoeft te verlenen. Routeplanners kunnen niet aan de highway=give_way zien dat hij in die geval niet geldt.

• Ik ben benieuwd wat van dit soort voorrang denken
• Er is een ander, beter alternatief, zo ja wat?

[Peter_Elderson]

@emvee

Routeplanners kunnen niet aan de highway=give_way zien dat hij in die geval niet geldt.

Wel als de stoplichten op de weg gemapt zijn, toch? Lichten overheersen de algemene voorrangsregel, lijkt mij wereldwijd gelden, dus alle routers mogen dat overal toepassen.

Ze kunnen niet zien wanneer het groen, rood of niet-werkend is, dus dat hoeven ze niet weer te geven.

Zou trouwens wel een mooie kerst-osm-kaart zijn, een online kaart die alle verkeerslichten live laat zien.

[Tjuro (Mart)]

@emvee

Ik ben benieuwd wat van dit soort voorrang denken

Normaal gesproken niet zo interessant, bij kruispunten die snachts overschakelen naar een oranje knipper licht modus kan het wel handig zijn.

[JeroenvanderGun (dr.ir. Jeroen van der Gun)]

We zouden overridden_by_traffic_signals=yes kunnen toevoegen aan de node met highway=give_way om aan te geven dat er een highway=traffic_signals in de buurt is die indien ingeschakeld de voorrangsregeling overneemt.

Ik heb in de routezoeker van het verkeersmodel dat ik beheer overigens nog niet meegemaakt dat het omschreven probleem daadwerkelijk een probleem was (maar misschien komt dat omdat ik een vrij lage penalties voor highway=give_way hanteer). Er zijn ook theoretische redenen denkbaar waardoor het zou kunnen dat je op een verkeerslicht op een zijweg gemiddeld iets langer moet wachten dan op een verkeerslicht op een voorrangsweg (bijv. groene golven of gewoon langere groentijden wegens hoger verkeersvolume). De grote spreiding in wachttijden bij highway=traffic_signals is m.i. veel uitdagender voor een routeplanner.

[Allroads]

@JeroenvanderGun

We zouden overridden_by_traffic_signals=yes kunnen toevoegen aan de node met highway=give_way om aan te geven dat er een highway=traffic_signals in de buurt is die indien ingeschakeld de voorrangsregeling overneemt.

Dat op zich is ook te berekenen binnen een bepaalde afstand of als het tussen het verkeerslicht en de kruisingsnode ligt, daar hebben we geen extra tag voor nodig. De werking hangt af van het verkeerslicht er voor, dan zou je ook terug kijken naar de tagging van het verkeerslicht, voor de werking van de give_way.

@JeroenvanderGun

De grote spreiding in wachttijden bij highway=traffic_signals is m.i. veel uitdagender voor een routeplanner.

Zo dacht ik daar al eerder over na.

Als het intensiteit gestuurde verkeerslichten zijn dan is het ondoenlijk om aan te geven, wat de werkende tijden zijn. En dus de werking van de haaientanden en de B6.
Als de VRI, die data actueel zouden vrijgeven, maar waarom, kosten en baten. We moeten dingen niet duurder maken, dan het al is.

Ik ben eens s’nachts op pad geweest om te kijken, hoe de lantaarns de verkeerslichten tonen en wat dan te zien is op de voet- en fietspadoversteek. Niet tot een goede conclusie komende.
Bij geel, knipperend, tonende driekleurige lantaarns op de rijbaan, wat dan de twee kleurige voetgangerslichten hebben. Staan ze uit? Zijn ze rood? Hebben, die altijd een drukknop, om te activeren, ook voor fietsers.
Vanwege de werking, regelingen, en voor laten gaan van voetgangers.

Regeling verkeerslichten

Indien nabij een plaats, waar blijkens een verkeersteken op het wegdek voetgangers plegen over te steken, drie- of tweekleurige verkeerslichten zijn aangebracht, moet het voetgangersverkeer worden geregeld door middel van voetgangerslichten.

De vraag is dan, wat is aangebracht? een lantaarn heeft, driekleurige verkeerslichten, de lantaarn van de voetganger heeft dan welke kleur voetgangerslichten?

En zo, rij ik de laatste tijd wel eens rond met dat in mijn achterhoofd, als mijn geel knipperend is, hoe zie ik vanuit de auto, wat de voetgangers hebben. Dat is lastig, hoek voetgangerslichten en zicht er op. Je moet echt stil staan om de cyclus te bekijken.

Aangebracht.
Op de rijbaan rijdend kan je te maken hebben met:

• tonende verkeerslichten, rood/geel/groen.
• knipperende lichten, geel, bij een lantaarn met driekleurige verkeerslichten. Waarbij soms maar een licht knippert van de boven de weg hangende meerdere lantaarns.
• lantaarn met niet tonende verkeerslichten.

Niet aangebracht.

• geen lantaarns

Dit was mede ingegeven bij verkeerslichten, waar ook een zebra ligt.
Om tot een conclusie te komen:
Kort samengevat:
Als bij de rijbaan verkeerslichten “zijn aangebracht” en er ligt een zebra wanneer moet je voetgangers voor laten gaan?
Voor de beantwoording vroeg men om een concrete situaties.
Dit wijd uit. maar het gaat dan om de tijden dat er een geel licht knippert en de werking van de give_way.

[emvee]

@Peter_Elderson

Routeplanners kunnen niet aan de highway=give_way zien dat hij in die geval niet geldt.

Wel als de stoplichten op de weg gemapt zijn, toch?

Op een kaart is dat inderdaad prima te zien maar voor een router is voor/achteruit kijken niet logisch en niet onderdeel van standaard algoritmes. Een barrier=gate zetten we ook op een weg node en niet op een node naast de weg of een gate-weg die de weg kruist zonder node.

Als voor highway=give_way geldt dat er geen voorrang verleent moeten worden de meeste tijd/als de verkeerslichten werken dan hoort die informatie ook thuis op de highway=give_way node.

@JeroenvanderGun

We zouden overridden_by_traffic_signals=yes kunnen toevoegen aan de node

Ja, zoiets klinkt goed; waarschijnlijk goed om het internationaler te trekken voor een definitieve keuze te maken.

Een optie die ik ook zie is om road_marking=give_way te reserveren voor voorrang-objecten die normaal niet gelden en highway=give_way te houden voor voorrang objecten die altijd gelden.

Over het gebruik van dit soort data

Ik heb in het brouter profiel dat ik gebruik staan:

# cost for traffic lights, stop signs and railway crossings
assign trafficlightcost = 150
assign stopcost = 50
assign givewaycost = 25
assign railwaycost = 25

Met “150 meter” krijg je dit bij sommige verkeerslichten:

Maar dat zie ik niet als een probleem maar als hint en ja, soms fiets ik zo.

Met 25 of 2*25 voor het kruispunt hierboven krijg je niet dit soort detours, het kan wel subtielere wijzigen veroorzaken. Maar de data hoort gewoon correct te zijn, zijn er routeplanners die aangeven dat je voorrang moet verlenen?

Wat betreft de grote spreiding bij verkeerslichten: Naar mijn idee is de enige goede oplossing hier een gemiddelde wachttijd te gebruiken.

[Peter_Elderson]

@emvee

Op een kaart is dat inderdaad prima te zien maar voor een router is voor/achteruit kijken niet logisch en niet onderdeel van standaard algoritmes.

Mijn gedachtengang was: om iets met voorrang of andere eigenschappen te doen moet de router de nodes die onderdeel zijn van een kandidaat-wegdeel, zowizo bekijken/verwerken. Dus als er twee voorrangsgerelateerde nodes zijn kan de software best besluiten om er maar eentje mee te tellen. Daarvoor hoeft de router niet voor/achteruit te kijken, het zit in de verwerking/beoordeling van 1 kandidaat-wegdeel. Maar misschien zie ik dat te simpel.

[emvee]

@Peter_Elderson

Mijn gedachtengang was:

Als ik het mag samenvatten ;-)

• Kiezen voor de moeilijkere oplossing (de nodes die onderdeel zijn van een kandidaat-wegdeel) terwijl op de node zelf wel zo handig is
• Kiezen voor het eerste deel van mijn eerdere betoog, en niet het tweede deel van de eerste alinea en de twee alinea

A*-algoritme

Kijk even rond op het wegdeel is geen onderdeel van dit algoritme.

[Allroads]

De ontwikkeling van routering, gebeurd in verschillende fase.

• Het ophalen van de OSM database, ruwe data.
• Het bewerken van deze dataset.
• Het maken van een applicatie.
• Het uitleveren van een dataset voor de applicatie.
• Het maken van een routeringsprofiel, gebaseerd op de applicatiedata.
• Het gebruiken van de routeringsapp.

m.a.w. in het voortraject kunnen er andere methoden worden toegepast om tot een bruikbare dataset te komen. Samenvoegingen, vergelijkingen, verwijdering, herbenoemen, etc. Dit naar eigen inzicht.

De geodata, die wij maken, is meer het aangeven, wat er is, waar het ligt en deels de werking.

[Peter_Elderson]

@emvee

Kijk even rond op het wegdeel is geen onderdeel van dit algoritme.

Dat is een mooi algoritme om de kortste weg in een graaf te vinden. Als jij zegt dat routers dit toepassen geloof ik je gelijk. Maar dit is niet het hele verhaal. Eigenschappen van wegen en knopen worden voor de routering opgehaald, verwerkt en toegepast; het routeringsprofiel staat vol met eigenschappen van wegen. Functies kunnen meerdere knopen en wegdelen vergelijken.

Als je zegt daar moet code voor aangepast/geschreven worden, natuurlijk, en in welk stadium van de totale verwerkingsketen dat moet gebeuren, geen idee. Maar het kan, en het is aan de ontwikkelaars van routers om te kijken of ze het de moeite waard vinden.

[emvee]

@Allroads, @Peter_Elderson: Jullie lijken beide niet overtuigd dat goed is om een extra tag om aan te geven dat highway=give_way niet geldt (tenzij het verkeerslicht niet werkt).

Wat denken jullie van het voorstel om road_marking=give_way te reserveren voor voorrang-objecten die normaal niet gelden en highway=give_way te houden voor voorrang objecten die altijd gelden.

[Allroads]

Met style en preset (oneclick) bezig, nadat ik dit had gemaakt heeft men de wiki road_marking aangepast. (hier moet ik nog mee aan de slag)
En road_marking=give_way er uit geschreven. De vraag is dan kan je zo’n tag weer herintroduceren? Denk het niet en dan ook nog een werking aan geven.

Nu wordt het road_marking=stop_line stroke=.

Mede om de intentie van gebruik van de key road_marking, wordt daar meer het visualiseren aangehaald om te mappen, niet een werking. Wanneer men het over werking heeft dan worden de daarvoor bestemde tags aangehaald. Dan ga je aan een key bij een value een werking geven, die niet past binnen het road_marking systeem. En voor verwarring zorgt.

En zo heb je de B6,
, die men wil mappen en de haaientanden. Beide hebben een highway=giveway werking, en op straat wel eens los van elkaar gebruikt/weergegeven, niet op elke fietspad met haaientanden staat ook een B6.
Ik worstel er mee of je dat onderscheid moet maken. Waar mag je een traffic_sign=NL:B6 opvoeren, waar niet bij met OneClick (OC) De reikwijdte/werking van een verkeersbord B6 op een kruising, bord naast de rijbaan ook werkend op het fietspad?

Dan liever een extra tag, waarbij ik mij afvraag of dat wereldwijd, correct structureel wordt gezet. Zo, niet, dat men het toch op een andere manier moet bewerken. Om te corrigeren voor gebruik.
Als men dat, dan al doet. Waarom dan nog zetten.

Wereldwijde discussie zou goed zijn.

En zo zijn er ook andere zaken, die costs geven waar een traffic_signals voor staat.
Bij een brug en gebruik van barrier=lift_gate en dan costs voor een barrier. Ondanks, access=yes, wat niet inhoud dat je geen extra handeling moet doen. Wat men weer wil opheffen met open=yes (Somehow open).

En zo keek ik al voor de styling naar wiki traffic_signals

Taginfo Nederland
De ene traffic_signals is de andere niet, als het gaat om costs en tijden.

[Peter_Elderson]

Ik tag alleen de give_way op een wegknoop, ongeacht of het met een bord, haaietanden of beide is aangegeven. Bij haaietanden plaats ik hem thv de punten van de haaietanden.

Overigens zet ik geen give_way nodes meer bij de opritten naar rotondes, want bij de OSM-definitie van rotondes is dat inbegrepen. Als er op de weg een oprit is die voorrang heeft, is het verkeersplein geen rotonde in OSM.