Direction tags op verkeersborden

Ik dacht vanavond een makkelijke klus voor mezelf op te zetten door ontbrekende direction=forward / direction=backward aan stop- en voorrangsborden toe te voegen, maar dat bleek niet het geval. Dit wordt namelijk inconsistent getagd. Naast voornamelijk direction=* tags op verkeersborden hebben we ook een aantal give_way:direction, stop:direction en traffic_sign:direction tags.

De specifieke tags worden soms handig gebruikt op nodes met meerdere doelen om aan te geven dat de direction tag alleen relevant is voor het bord en niet voor andere tags op de node, zoals op borden die dubbel getagd zijn met wegmarkeringen, verkeersdrempels of straatlantaarns. Dat vind ik op zich een goede zaak.

Waar ik tegenaan loop is nodes met alleen highway=stop, highway=give_way of traffic_sign=* erop, met een specifieke ...:direction=* tag erbij. Is het een idee om van al die gevallen, in ieder geval waar ze als nodes op wegen staan, gewoonweg direction=forward/backward te maken?

Zelf gebruik ik traffic_sign:direction in plaats van direction met de gedachte dat de direction tag dan (alsnog) voor de richting in graden gebruikt kan worden. Niet dat ik denk dat dit de enige goede methode is maar voor mij was het de beste.

Voor het toevoegen van verkeersborden ivm maxspeed heb ik voor de zone-borden geen direction toegevoegd met het idee dat dat later automatisch kan, voor komborden (traffic_sign=city_limit) gek genoeg heb ik dan wel wel direction gebruikt ipv traffic_sign:direction

Ter overweging.
In Osmose geeft highway=give_way in combinatie met give_way:direction=backward een foutmelding.
Node: 12061285817 | OpenStreetMap en Osmose
Wat op zich wel vreemd is, want het is een bestaande tagging: Key:traffic_sign:direction - OpenStreetMap Wiki

Ik gebruik zelf give_way:direction=forward/backward voor consistentie met het vrij populaire traffic_signals:direction=forward/backward. Het lijkt me wenselijk om het voor highway=give_way/stop/traffic_signals op dezelfde manier te doen, vanwege de vergelijkbare toepassingen van deze nodes.

Het zou goed zijn om helder te krijgen welke stijl van tagging internationaal de voorkeur geniet. Daarbij zouden in ieder geval bovenstaande drie gevallen en liefst ook traffic_sign/city_limit in de discussie betrokken moeten worden.

Als dataconsument ondersteun ‘ik’ overigens beide manieren: ik kijk in al deze gevallen eerst naar XXX:direction en daarna naar direction als XXX:direction ontbreekt.

Het is maar net vanuit welk standpunt je dat bekijkt.
Wat weegt zwaarder het snel een tag kunnen zetten of meer volledig.
Als het al gezet wordt, dan vinden vele het al genoeg highway=give_way en geen direction bij oneway=yes want meerdere tags key=value is teveel werk. ( dat is toch logisch, wat niet op gaat bij tegengesteld fietsverkeer bij oneway)

Of wel meerdere key=value en dan met een : erbij om de give_way:direction te zetten, die : ervaren andere weer als teveel typewerk, lastig bij automatische aanvullen in JOSM bij wat laatst gebruikt.

En zo heeft een ieder zijn voorkeur. Of niet en doet men wat anderen doen of volgens editor.

Met preset bezig kijk je dieper naar de materie.
Tot heden heb ik steeds gewerkt met alleen direction=xxx op zich correct.
En gekeken, wat er nog meer, als je toch bezig bent met one click kan worden gezet, wat men zoal zet. De road_markings is in opkomst, nieuwe tag, dan wil je ze wel in een style zien, zien wat er wordt gezet, daar de preset op aangepast, want je zet het in een keer, one click.

Dus ik vindt het interessant of ik de give_way:direction moet opvoeren. Meer duidelijk.
Nu nog zo gedaan.

Deze situatie klopt niet, want traffic_sign=NL:B6 klopt niet, want die staat daar niet, alleen haaientanden. En zo heb je weer een one click variant. Aangevende ga je ergens over nadenken dan kom je steeds afwijkende situaties tegen.

De twee stylen, pijltje en zichtvlak (donkergrijs) werken niet met give_way:direction, het zichtvlak werkt op een oneway=yes weg wel, daar hoeft geen direction key op te staan. Het geeft aan bij de ontwikkeling van de style, hoe men denkt over het wel of niet zetten van direction bij oneway.
Style is een soort van controle mechanisme, een hint.

Bij road_marking wel de :direction variant opgevoerd. Haaientanden draaien, links/rechts van de roadlijn.

Bij een style moet je wel met beide rekening houden.

Ik heb dan ook de preset variant:
afbeelding

afbeelding

Keuzes.

Ik zou die minder gebruikte give_way:direction laten staan.

Volgens Taginfo heeft wereldwijd 78,18% van highway=give_way een direction=* tag, tegenover slechts 1,39% traffic_sign:forward/backward=* en 0,09% traffic_sign:direction=*. traffic_sign:forward/backward=* wordt oververtegenwoordigd in 4 Europese landen (België, Wit-Rusland, Servië en Duitsland) en wordt in 87,7% van de gevallen gebruikt in combinatie met direction=forward/backward en soms met andere tags voor borden. Van de 1,129 gevallen met traffic_sign:direction=* op highway=give_way zijn er 477 in Nederland.

highway=stop geeft een meer overzichtelijk beeld, met meer (83,74%) combinaties met direction=* en minder (<0,9%) combinaties met alternatieven.

give_way:direction=* en stop:direction=* komen niet voor op de Taginfo lijsten van tags die in combinatie gebruikt worden met highway=give_way/stop, wat betekent dat ze internationaal zo goed als niet in gebruik zijn.

Als voortzetting van dit onderwerp: is het een idee om direction=forward/backward aan te vullen op stop- en voorrangsborden die al een give_way:direction, stop:direction of traffic_sign:direction tag hebben?

Nee.

Het bord, traffic_sign=* staan naast of hangen boven de weg. Eigenlijk is het highway=traffic_sign en verder.

De direction tag bij deze key, geeft aan de kijkrichting van het bord, dat is tegengesteld aan de rijrichting. In graden of windrichting.

Men zet ze ook op een weglijnnode, als ik daar over na denk, is dat een verkeerde keuze, dat is een afgeleide van het werkelijk plaats van het bord, waarbij door andere tags de werking wordt uitgebeeld, eigenlijk hoort de bron vernoemd te worden door source:traffic_sign=NL:* Maar dit suggereerd, dat er op de node een traffic_sign staat, dit is niet zo.

De kijkrichting van de traffic_sign moet dan goed worden aangegeven. Gebeurd dat met forward en backward?

highway=giveway is werkings key, wat veelal gevisualiseerd wordt door en voorrangsicoon. Dat kan op basis van een verkeersbord B6 naast de weg of met of alleen haaientanden.

Zo kennen we bij maxspeed.
source:maxspeed=sign source:maxspeed=markings of een NL: value
maxspeed:type=sign of een NL: value

Het gaat mij om de verwijzing naar de bron.

source:give_way

Er zijn er maar 20 met traffic_sign de andere met traffic_sign:direction=* zijn fout. Want er is geen traffic_sign. En zou de kijkrichting van het bord moeten aangeven.

Dit kan niet.
afbeelding

De werkingsrichting en bord kijkrichting zijn tegengesteld en dat is verwarrend.

Een methode is gewenst bij traffic_sign.

Ik kom er niet helemaal uit met wat je bedoelt. Kun je me voorbeelden geven van hoe volgens jou een highway=stop/give_way met en/of zonder bord aan een paaltje gemapt zouden moeten worden?

wiki highway-give-way

wiki traffic_sign En dan zet je er een B6 naast in de berm met een direction, zet je die B6 (werkelijk bord, traffic_sign) op een node van de way, dan moet de node van de way ook dezelfde richting (direction) krijgen als de node naast de weg. Dat zou logisch zijn. Maar, ja …

To indicate the direction affected by a traffic sign relative to the highway=* way, three different tags are in use. forward means the same direction as the highway=* way and backward the opposite direction.

Oke, maar als we ons nu beperken tot de give_way/stop op de wegen, dan geldt de logica van het plaatje, toch?

1 Like

Dan kun je niet =forward of =backward gebruiken omdat het een losse node is. Als de rijrichting van de way omdraait (omdat iemand verderop deze weg met een andere samenvoegt) klopt de =forward van de B6 naast de weg niet meer.

N.b. Forward en backward zijn altijd geassocieerd met een weg: Key:direction - OpenStreetMap Wiki
" This only applies to features which are tagged on a node that is part of a way. Examples may include directed traffic signs."

1 Like

Dat zijn de gevallen waar ik het over heb. Op de losse nodes zou ik zelf ook geen forward/backward taggen.

1 Like

Op losse nodes met een traffic_sign kun je alleen een direction zetten met een aantal graden erin. Daarmee kun je het plaatje van de traffic_sign mooi uitlijnen, maar is het wel een lastig en tijdrovend proces.
Maar het lijkt mij niet nuttig om losse nodes met traffic_signs te plaatsen. Het wordt al gauw erg vol en druk.
Ik ben niet goed in het maken van screenshots, maar bedenk even de volgende situatie:
Een N-weg, gescheiden rijbanen, en aan beide kanten een parallelfietspad.
Een overstekende weg en fietsoversteken.
Zeer normaal in NL.
Dan moet je al een bos highway=give_way’s plaatsen, op de overstekende weg en de fietsoversteken.
Als dan ook nog eens naast elke give_way ook nog een traffic_sign in de berm moet worden geplaatst, wordt het al gauw helemaal onoverzichtelijk en vol.
En ik zie ook geen praktisch nut voor die dingen in de berm. Hooguit een mooi plaatje.
Een give_way op de weg, kan door routeerders worden gebruikt voor waarschuwingen om voorrang te verlenen.

3 Likes

Ter aanvulling, ik heb voor maxspeed regelmatig een weg gesplitst op de plek waar een 30/60-zone-bord staat en daar dan traffic_sign=NL:A1-[30/60]-ZB toegevoegd, de weg moest toch al gesplitst worden, en dan voelde het toevoegen van dit tag logisch; zelfde verhaal voor traffic_sign=city_limit