NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

Nee! Dat staat er niet meer zag ik vandaag toen ik terugkwam uit Hedel.

Zie hier:

Het bord “Fietsstraat, auto te gast” kom ik tegen met 2 coderingen:

Hier is het L1002
http://www.verkeersbordenoverzicht.nl/#L

maar hier:
https://www.informatiebord.nl/oefenen/verkeersborden-overzicht/

en ook bij CROW:
http://kennisbank.crow.nl/KennisModule (je moet hier even zoeken en mogelijk heb je helemaal geen toegang. Ik kan erbij vanwege de Fietsersbond)

staat het bord als L51 bekend.

Wie moeten we geloven?

Bij het zoeken op https://zoek.officielebekendmakingen.nl op L51 vind ik 14 verkeersbesluiten en bij L1002 zijn dat er 8. Dus zoveel borden staan er niet eens in Nederland, dan toch?
Lijkt er maar net van af te hangen welke leverancier de gemeente heeft…

Mapillary heeft in JOSM een preset voor verkeersborden.

Hierbij gebruiken ze geen voorloopnul !!

De discussie voor keuze voorloopnul is nog niet afgerond.

Hierbij gaat Mapillary voorbij aan de Nederlandse discussie.

Wat nu?

Welke preset bedoel je Allroads?
Bedoel je deze?
Deze layer vind ik zeer goed.

Die bedoel ik niet.

Ik denk dat ik ook op het verkeerd been sta, vanwege dat ik de kleur van het icoon associeerde met Mapillary.

https://github.com/yopaseopor/traffic_signs_preset_JOSM
Het gaat dus om deze preset. NL.zip

traffic_sign_NL. had ik als knop in mijn bovenste taakbalk gezet. Het groene mapillary kleurtje.

Dus ik dacht.
Dat komt met de installatie van Mapillary mee. Presets keuze.
Maar kan net zo goed met JOSM nieuwe versies meekomen. Ik weet het niet.

Bord C1

traffic_sign:forward=NL:C1 dus niet met voorloopnul C01

Hoe dan bij, zulke bordenstrings traffic_sign=NL:A01-30-ZB, moet dat A1 zijn?
Daar in de zipfile ook geen A01.

access=no
side=right
traffic_sign:forward=NL:C1

access=no, en voetgangers dan? Presets moeten wel kloppen. Nederland

We hebben in het verleden de discussie gehad met op een node forward en backward. Ekris situatie.
Het wordt hier dus toegepast, maar hoe als het op een knooppunt van wegen ligt met verschillend richting way.

Ook wordt nu de keuze gegeven of het bord links of rechts van de weg staat. Direction?
Alles vanuit de op de lijn tagging gedachte.

Wanneer zulke presets wereldwijd worden geintroduceerd, zet dat de toon.

Is er overleg geweest met de Nederlandse community?

Als ze gezocht hadden, dan waren ze vast bij dit topic uitgekomen.

Sander H mappaintstyle gebruikt voorloop nul.
Moet dan nu omgebouwd worden?

Is de keuze nu opgelegd door iemand om zonder voorloopnul te gaan werken?

https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging

Ook hoe een tweede bord te taggen is al bepaald?

Welke kant van weg het bord staat?

Wat als de richting van de weg verandert?

Niks over direction van het bord.

Wat vinden jullie?

Ik heb een vraag over het gebruik van ‘direction’ tag bij een verkeersbord als node.

Op https://wiki.openstreetmap.org/wiki/Key:traffic_sign staat:
“You can use the direction=* tag to describe the facing orientation of the sign by using an angle or cardinal direction.”

Dus als ik naar het westen rij en een verkeersbord tegenkom, dan kijkt dat bord naar het oosten, en tag ik ‘direction=E’

Nu was ik met de josm css style van Sander H aan het spelen. En dan lijken de verkeersborden precies verkeerd om gerendered te worden.

Hier is een eerste poging om twee borden of een onderbord te renderen:
http://stereo.hq.phicoh.net/~philip/josm-css-nl-traffic-signs/Styles_Traffic_signs-style.mapcss

Je kunt voor direction beter forward en backward gebruiken.
Dat doe ik bijv. ook bij verkeerslichten: traffic_signals:direction=forward
forward en backward gaan dan ten opzichte van de richting van de weg
Op deze manier wordt in routes forward/backward ook gebruikt
En ook bij destination wordt forward/backward op deze manier gebruikt.

node alleenstaand, direction geef ik een getal in graden aan, dat komt het beste overeen. Op een gegeven moment krijg je daar handigheid in.

Soms is een verkeersbord op een highway=street_lamp gemonteerd, dan zou je eigenlijk traffic_sign:direction moeten nemen. Want het zegt niks over de straatlantaarn. http://overpass-turbo.eu/s/yKh
Heb ik ook fout gedaan en zit er over te denken om al mijn tags in 1 keer te verbeteren.

Dit is eigenlijk het forumtopic dat gaat over visualisatie verkeersborden in JOSM style, kunnen we over style daar beter verder gaan.

Ja, dat lijkt me inderdaad handiger.

Maar mijn vraag is, als je naar het westen rijdt en ja passeert een bord, geef je dan voor dat bord direction=270 (want dat is west) of juist 90 omdat het bord naar het oosten kijkt?

Maar goed, ik denk dat ik maar traffic_sign:direction=forward ga gebruiken. Dat lijkt me eenvoudiger.

Ik had het over losse node naast de weg. Bovenstaand.

Op een node in de way, dan gebruik ik direction=forward of backward, deze node mag niet de begin en eind-node zijn!!
Net zoals dat gebruikt wordt bij give_way, stop en traffic lights. Net zoals Dick omschreef. of met *:direction=

Op de way dan traffic_sign:forward=NL:** of traffic_sign:backward=NL:**, dit wordt nog niet gerendeerd met Josm style, bij C borden op een klein stukje weg, werkt vaak van 1 kant na elke kruising moet bord herhaald worden, je komt het ook tegen dat van de andere kant een ander regime geldt.

Bij fiestpaden komt het op de hele weg G11 G12a G13 dan vaak met oneway=yes.

Er zijn dus een paar methoden om te taggen met hun access tags erbij.
way methode en node in way methode voor routering.
Een keuze is niet gemaakt. Zal ook wel landafhankelijk zijn vanwege de regels/wetten.
Bij de meeste C borden mag er van de ander kant af gedraaid worden.
Dat is uit dit topic bij navraag naar voren gekomen

Belangrijke verkeersborden zet ik zelf wel naast de weg neer op losse node.
Vooral ook bij zone borden. Dan krijg je beter overzicht of alle ingangen ingedekt zijn.
Bij een natuurgebied zet ik ook de bordjes er in als access_sign ( in ontwikkeling) bordjes met direction.
Dan zie je ook of alle ingangen een bordje hebben, de zone klopt.

Een tag op een way is handig om toekomstige mappers duidelijk te maken wat de situatie is. Mijn ervaring is dat je soms toch niet goed kijkt. En dan is het handig als er een traffic_sign tag is. Bijv. als je bicycle=no omzet in bicycle=use_sidepath. Als je even niet goed kijkt dan zie je een verbodsbord over het hoofd. Als dan op de way een traffic_sign tag staat, dan is dat een reden om ter plekke nog eens goed rond te kijken.

Voordeel van nodes met traffic_sign is dat je ze goed op de kaart kan zetten. Dat maakt het visueel eenvoudig te controleren of het klopt.

Als de plaatsing van een bord niet heel veel uitmaakt dan is een node in een weg waarschijnlijk handig omdat je dan eenduidig forward en backward als richting kan gebruiken.

Als een bord bevestigd is aan een lantarenpaal die je ook wil mappen dan is een traffic_sign:direction met een richting waarschijnlijk de juiste aanpak.

Verkeersbord code

Waar ik tegenaan liep was hoe het verkeersbord te taggen wat aangeeft dat de voorrangsweg een bocht maakt en daar één of twee kruisende wegen zijn. https://www.informatiebord.nl/oefenen/verkeersborden-overzicht/299/ob711-verloop-voorrangsweg-voor-kruispunt geeft OB711, en op https://www.verkeersbordenoverzicht.nl/#B is dat OB701-1, en dat spoort niet.
(Overigens zijn er meer verschillen: OB15, OB17(links/rechts), OB25, OB66, OB612/613, en vast nog meer.)
Onze wiki https://wiki.openstreetmap.org/wiki/NL:Overzicht_Nederlandse_Verkeersborden#OB:_Onderborden_bij_verkeersborden geeft hierover geen informatie.
https://nl.wikipedia.org/wiki/Verkeersborden_in_Nederland is ook (nog) niet compleet
Bij wie of waar is de correcte codering voor de (die) onderborden te vinden?
edit: link gecorrigeerd

Een lastige.

De overheid omschrijft het mogelijk gebruik van onderborden, maar publiceert geen codes.

Codes ontstaan in de loop van de jaren, veelvuldig gebruik, consensus bij overkoepelende organisaties.
Zo is CROW, een van de organisaties, die overlegd en adviseert.

Maar als burger kunnen wij daar niet zo bij.

En elk borden verkopend bedrijf, heeft zijn eigen artikel codes. Veelal lopen ze in de pas, meestal met voorloopnul, ook aan de wettelijke omschrijving schort het wel eens.

Misschien kan @marczoutendijk duidelijkheid geven over OB15 16 17 en al die andere.

Een verkeersbord hangt aan een paal of hangt boven de weg.

Nu taggen we het verkeersbord, traffic_sign=* (eventueel met forward backward) ook op de weg way, wat niet klopt, want daar staat het verkeersbord niet.
Het eerstegraads afgeleide, de verkeersbord code taggen op een way is eigenlijk een source tagging.
Om het juist te doen zouden we dan source:traffic_sign:forward=* of source:traffic_sign:backward kunnen gaan taggen?

Wat denken jullie?

Doen we het fout?

Zelf vindt ik wel belangrijk om de code op een way of middennode van een way te taggen, om de tweedegraads afgeleide, de access tags, later te kunnen controleren.
Als wetgeving verandert, zaken te kunnen veranderen.

Voor Nederland zijn dat vooral fietspaden, bijna 40% van de hele wereld. G11 G12a G13 Zie taginfo way

Heb ik het juist dat:

  1. De codes zelf niet door renderers (en renderende routers/navigaties) gebruikt worden?
    (dan zouden ze per land een overeenkomende codedatabase per land moeten bijhouden en bij het renderen daar het juiste plaatje uitplukken)

  2. De codes zelf niet voor navigatie/routeren gebruikt worden?
    (dan zouden de “tomtoms” de betekenis van de codes voor het verkeer per land precies moeten kennen)

Dus dat het eigenlijk alleen een tag/controlehulpmiddel is?
Om bruikbaar te zijn voor navigatie moeten alle betekenisvolle verkeerstekens dan ingevoerd worden en heel betrouwbaar zijn. Niks is zo vervelend en gevaarlijk als verkeerde aanwijzingen van je navigatiesysteem.

Moeten verkeerstekens bij ingewikkelde kruispunten dan ook per baan/rijstrook getagd worden?

Maar ook de missende aanwijzingen.

Dat is nu het probleem, de Nederlandse tagger doet het nu ook niet altijd juist, omdat ze de vertaling van verkeersbord en onderbord, niet kunnen naslaan.

Of de routeerders een eigen database hebben, maar wij zelf moeten het ook hebben.
Als is het maar om een goede presets te maken, bij fietspaden kies je voor G13 en de juiste tags komen er op.
Vroeger moest ik behoorlijk nadenken of een tagger met bepaalde tagcombinatie nu een G13 of G11 bedoelde.
Als iemand het fout had gedaan was het bijna niet te zien, te doorgronden met al die tags op een way en al de knippen in de weg.

Lane, dat ligt er aan of een verkeersbord/tekens voor een lane geldt.
Rijd je op een rijstrook met een pijl, dan mag je na die pijl, niet meer van strook verwisselen.

  1. Vele niet, andere willen weten waar het bord staat, voor 3d visualisatie. (extra tagging side etc.)
  2. Vele niet, omdat programma’s nog niet zo ver zijn.

De echte Tomtom zal wel zo’n databestand hebben neem ik aan.
Ze zullen niet elke individuele werknemer een vertaling laten maken van het verkeersbord, zoals wij dat eigenlijk doen.
Wil je kwaliteit, dan is dit de weg.

Eigenlijk zou je nu elke bordencombinatie, 1 keer uitgezocht, uitgewerkt en opgeschreven moeten worden in OSM tags.
Hier is best nog wel een slag te slaan.
Presets geven meer kwaliteit en uniformiteit.

En zo kom je nog niet volledige tags tegen.
De discussie over motorcar.
Het fietssymbool op onderborden, voor wie geldt dat?
Maar ook alle andere genoemde voertuigen op de verkeersborden.