B1 Voorrangsweg, hoe taggen?

60px-Nederlands_verkeersbord_B1.svg B1
Hier is de weg tot op de rotonde getagd met priority_road=designated.

De vraag is dan is dit correct.

Waar hoort de knip te staan?

Haaientanden met een B6 Nederlands_verkeersbord_B6.svg highwway=give_way, deze tag zetten we op de plek waar haaientanden staan, een node van de way. Daar mogen we niet knippen. Want node highway=give_way mag geen begin- of eindnode van een way zijn.

300px-Give_way_on_roundabout

Omdat we daar niet mogen knippen tot waar moet dan priority_road=designated lopen.

De vraag is dan waar houd wettelijk gezien de voorrangsweg op?

  • Bij de haaientanden? Hier mogen we niet knippen, dat is dan lastig.
  • Bij de B6 verkeersbord "Verleen voorrang aan bestuurders op de kruisende weg "
  • Op de rotonde, node gezamelijke wegen.

Bij een kruising komen voorrangswegen bij elkaar.
Tot waar loopt de voorrangsweg?
Hier is een deel naast de vluchtheuvel niet getagd, wat niet klopt.
Als je dat wel tot op de kruising tagt.
Met de tag priority_road=designated geef je aan dat je voorrang kan krijgen, een routingcost mogelijkheid.
Maar die highway=giveway is getagd, mag je daarna nog wel priority_road=designated taggen?

Er zijn niet zoveel B2 60px-Nederlands_verkeersbord_B2.svg

  • priority_road=no: The road is not a priority road.
    If the priority road has just ended, you can use the following more specific value:
  • priority_road=end: Traffic entering the way at the start passes an end of priority road sign Vienna Convention road sign B4-V1.svg.

Waar zetten we die?
Bij het bord dat kan hier ook beter.
*=end er zijn geen *=no in Nederland.
afbeelding

Tevens kunnen we gelijk parking meenemen in een preset.
Preset gebruik is daar het meest geschikt voor. Dan moet je wel weten wat je doet.
Parkeren op een B1

De bestuurder mag zijn voertuig niet parkeren: buiten de bebouwde kom op de rijbaan van een voorrangsweg. RVV Art.24. Tag: parking:lane=no_parking. Buiten de bebouwde kom wordt dit bord geplaatst op enige afstand na zijwegen van de voorrangsweg. Binnen de bebouwde kom wordt dit bord geplaatst direct voor zijwegen van de voorrangsweg.

Deze tag schijnt nu verouderd te zijn. (deprecated) was een stuk korter als de nieuwe vorm van Streetparking

Deprecated. Use: parking:side:restriction=no_parking
side = both, forward, backward.
de rijbaan zou dan ook nog moeten worden toegevoegd, is lane voldoende of moet dat on_street zijn.
Als value:
lane Parking position lane.png100x55 Parking on the street (which could be easily converted to a travel lane).
Maar het moet in de key om no_parking aan te geven.
parking:lane:side:type is verouderd
Die mogelijkheid zie ik niet terug in de beschrijving van Streetparking
Dan moet het ook in een de goede volgorde:
parking:lane:both:restriction=no_parking kan niet, want parking:lane is deprecated.
Heb het gevoel dat het nieuwe systeem nog niet goed doordacht is.

Daar ben ik nog niet uit.

Waarom niet? Kan zijn dat ik eroverheen kijk maar ik zie het niet op de tagpagina.

1 Like

Dit is inderdaad gewoon toegestaan. Je moet er alleen voor zorgen dat de node geen kruispunt is, want dan is niet duidelijk welke richting er voorrang moet verlenen.

Als er niet meer dan twee ways aan de node zijn verbonden, is er niks aan de hand. (Bij tweerichtingsverkeer kun je direction=forward/backward of give_way:direction=forward/backward toevoegen, net als bij verkeerslichten.)

Zo heb ik het altijd begrepen.
Omdat bij tweerichtingsverkeer de direction moet worden toegepast.

Als deze twee ways een verschillende tekenrichting hebben kan het niet, de forward backward verwijst naar de tekenrichting van de weg. Twee beginpunten bij elkaar dan weet je niet welke kant de node op werkt.

En daarom heb ik altijd begrepen dat er gekozen is, dat het geen begin- eindnode mag zijn.
Om hier geen probleem te krijgen. Dat men er niet over nadenkt.

Beide ways moeten inderdaad dezelfde tekenrichting hebben. (Dat gaat vanzelf goed als je eerst de way tekent en hem daarna splitst.)

Ik zou zeggen dat de voorrangsweg ophoudt op de rotonde. En dat als je afslaat je dan op de voorrangsweg komt.

Aangezien wij wegen representeren als lijnen en die in tegenstelling tot de wegdelen geen breedte hebben. Komt er een extra virtuele lijn tussen de daadwerkelijke positie van de giveway wat het einde van het wegdeel representeert.

Je zou dan kunnen concluderen dat met deze lijn abstractie het stuk direct na het afsplitsen al telt voor de zijweg van de rotonde. Ook als dit stuk zich in werkelijkheid nog op het asfalt van de rotonde bevindt.

Dat lijkt me een mooi puntje voor de validators/checkers/challenges/QA-tools.
Is dat punt hiermee opgelost, @Allroads ?

Punt van een knip. Dat is een mogelijkheid. Om daar zo van uit te gaan en de veronderstelde regel, geen begin- eindnode los te laten.

Daarmee zeg je dat de B6/haaientand niet de B1 opheft.

Op het punt waar haaientand ligt of B6 staat.

Niet helemaal wat ik bedoel is dat de B6/haaientand het einde is van de voorrangsweg.

Eigenlijk zit de giveway op de kruising met de rotonde, en eindigt daar de weg met een haaientand. Alleen hebben we ervoor gekozen om nodes op de daadwerkelijke positie te plaatsen.

Hoewel het stuk na de B6/haaientand zich fysiek op de rotonde bevindt is de lijn representatie naar mijn mening nog steeds onderdeel van de voorrangsweg.

Hier staat alles nog niet goed.


Dit is buiten de bebouwdekom, dan zetten we de voorrangsborden B1 na het kruispunt.
Binnen de bebouwde kom zetten we de B1 voor de kruising.

Hier staat een B2 na de kruising en er voor.
Bedoeling, blijkbaar om aan te geven dat de brug geen voorrangsweg is.
Bij B2 stopt dan de werking waar het bord staat?

B2 Er wordt dan in OSM aangegeven dat je priority_road=end moet gebruiken om het verkeersbord aan te geven.

Dit heeft gevolgen voor het juist zetten van =no_parking.

Parkeren, het kruisingsvlak van een kruising, rotonde is ook een kruising, heeft dus ook een kruisingsvlak, daar mag men niet parkeren en binnen 5 meter vanaf het kruisingsvlak. ( dit ook volgens gerechtelijke uitspraken bij een T splitsing)

Vandaar het nader bekijken tot waar gelden de regels, en hoe te taggen volgens OSM.

Test: Wanneer ik de tekenrichting van een way verander in JOSM krijg ik gelijk deze melding. De richting is naar het noorden een uitgaande weg, verandering naar het zuiden.
afbeelding Na klik gelijk de melding.

Apply selected changes is correct, de werkingsrichting van de B1 moet in dezelfde richting werkzaam blijven.

Nu knip ik de way op de node met B6 verkeersbord. En upload deze naar JOSM.
Download het gebied in JOSM.
Het kleine stuk (rood), daar pas ik de tekenrichting aan.
Krijg gelijk een melding.


Neem aan. Ik ben het er mee eens, apply selected chainges.
Dan veranderd de B6 werkingsrichting, wat niet correct is.
Nu upload ik deze data naar OSM.
Dan komen er geen validatie resultaten en staat het verkeerd.
tekenrichting twee richtingen, B6 werking in de verkeerde richting.
Zie pijl bij B6, nu tegengesteld (forward).

Nu alles weer terug gezet tot oude situatie.

Node, node attribuut op een begin- eindnode, en tekenrichting way verandering. Effect op forward/backward tag.
Een makkelijk te maken fout, vooral als de node uit het zichtveld ligt, en men denkt zal wel correct zijn, dus apply.
Dit in JOSM
Bovenstaande als voorbeeld voor

Hoe is dit geregeld in ID?

Duidelijk.

De reden voor plaatsing is niet alleen een optische reden, maar meer een logische/praktische reden, op de kruisingsnode, is het met OSM tags niet aan te geven, wie voorrang moet verlenen aan welke way. Wellicht met een relatie (onpraktisch). Het is in de routering een kleine, mits gebruikt, costfactor voor de berekening tijd, snelste afstand. Daarom is het een logisch keuze, dat op de way te doen, op de optische locatie, want daar onderga je de costfactor, misschien wel de best reden. En hoort het helemaal niet op de kruisingsnode.

Omgekeerd, omdat we toch over voorrang hebben, hoort er op de rotonde D1 Nederlands_verkeersbord_D1.svg, op basis van verkeersborden en regels ook een vorm van priority te staan. Daar is dan enige vorm van costrouteringsvoordeel. Bij een rotonde op zich hebben we veelal te maken met een lagere gebruikssnelheid, zo ook het afslaan, als dit meegenomen wordt in een berekeningsfactor.
(Te verwerken in een preset)

Ik heb daar nog geen duidelijke mening over. Dacht meer stoppend bij de haaientand. Ik begrijp je onderbouwing.
Vandaar mijn topicstart, omdat ik deze vraagstelling nog niet eerder ben tegenkomen.

Wat denken andere, hoe zou het moeten in OSM?

In NL, omdat we geen principiële voorrang voor verkeer op de rotonde hebben, mappen we een rotonde alleen als junction=roundabout als er op alle aanvoerende rijbanen fysiek een geef-voorrang staat. Zodoende kan de router erop rekenen dat junction=roundabout voorrang heeft, zelfs als OSM er geen give_way node heeft staan. MI geldt dat ook als de aanvoerende weg een voorrangsweg is.

Als de rotonde niet overal expliciet voorrang heeft, is het voor ons nog steeds een rotonde, maar voor OSM is het een junction=circular, waarbij de router, als er geen give_way node is, voorrang van rechts moet veronderstellen.

1 Like

De router berekening route, kijkt niet op de inkomende zijweg of er een give_way staat.
Dus men verondersteld dan “rechts heeft voorrang”, wat dan niet zo is, een OSM constatering.
Om dit duidelijk te maken in de route wegberekening, zal een tag moeten staan, op de te volgen route, de rotonde, rechts heeft geen voorrang, priority crossing
Vandaar, als alle toekomende wegen op een rotonde, een give_way hebben, OSM constatering, zou je op de rotonde enig vorm van priority kunnen zetten. Zelfs op delen van de rotonde tot aan de kruisingspunt.

Waarom haal ik dit ook aan, bij het doortaggen tot aan de kruisingsnode van de inkomende weg (Tjuro methode,haaientand - kruisingsnode). De router berekening kijkt ook niet naar de inkomende weg priority_road=designated. Aan dat stuk wayintekening haaientand - kruisingsnode, is het niet aan af te leiden, als dit wel meegenomen zou worden door een routerberekening, dan zou de inkomende priority_road, ook op basis daarvan voorrang hebben, wat niet zo is, want immers er staat een B6 inkomend.

Het gaat dan om wel of niet priority aangeven.

Als alle toekomende wegen een give_way hebben, taggen we de wegen op de rotonde met junction=roundabout, en OSM zegt dan dat ze voorrang hebben.

Als niet alle toekomende wegen give_way hebben, taggen we de rotondedelen met junction=circular, en hebben wegen van rechts voorrang, tenzij op de een of andere manier is aangegeven dat rechts géén voorrang heeft of dat dat stuk rotonde in dit geval toch voorrang heeft.

Als de give_way node voor de router niet meetelt, moet de prioriteit ofwel als niet-priority op het inkomende wegdeel (kan de router dat dan wél zien?) of als priority op het rotondedeel worden getagd.

Is dat wat je bedoelt?

The tag junction=roundabout is used only on road intersections where traffic on the roundabout has right of way

Daarmee geef je nog niet de priority aan. Alleen de keuze voor junction=roundabout. Een afgeleide key/value combinatie.
In de basis krijgt van rechts voorrang. Rijdend op een met priority aangegeven wegdeel, dan heeft van rechts geen voorrang.

? Als geldt “A roundabout is a generally circular (self-intersecting) road junction where the traffic on the roundabout has always right of way.”, dan geef je met junction=roundabout toch per definitie de priority aan?

1 Like

Dat is de wikipedia definitie.
Post eerder, dat is de OSM defenitie, wanneer junction=roundabout toe te passen.