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

Communities Nederland (Netherlands)
161

Zoals bekend heb ik al op verschillende manieren de traffic_sign key toegepast. Dat is voor mij geen reden om niet ook de gebruikelijke (bv access) tags toe te passen. Echter, het staat een mapper vrij te mappen wat ie wil hoewel het wel verstandig is dat te doen met instemming van de community. Als er iemand is die alle verkeersborden als losse punt naast de weg wil taggen en verder niets dan is daar volgens mij niet veel mis mee maar ik zal wel proberen de implicaties ook te taggen.

Als ik de traffic_sign Wiki lees zijn er vele mogelijkheden en persoonlijk ben ik nog een beetje zoekende wat we het best kunnen doen. Ook ik neig er naar om deze op de weg te plaatsten zodat er iets aan te geven is over de geldigheidsrichting maar dan is nog steeds de vraag hoe. Ik heb het idee dat we in deze NL verkeersborden wiki uit moeten breiden met per bord aan te geven of het in principe een bord is voor een punt/knoop/node of voor een way/wegvlak. Ik denk dat een aantal (nee niet alle :wink: ) C borden punten zouden moeten zijn tenzij aan beide einden van een weg zo’n C bord staat. Dan zou het denk ik ook op de weg getagd kunnen worden en ik denk dat dit wel handig is al heb je dan wel weer 2 methodes die voor het zelfde bord gebruikt kunnen worden. Dat maakt het weer wat onduidelijk. Lastig.

En dan is er verder nog de vraag of een bord en de implicatie daarvan in principe op het zelfde element (way of node) getagd moeten worden of niet. Als de meeste C borden die maar aan 1 kant van de weg staan dan getagd moeten worden op de node (of een klein stukje daar vandaan op de weg) en de implicatie met een turn restrictie dan wordt ik daar nog even niet echt blij van maar zie ook niet hoe dat beter kan.

Ook is het wel fijn als we in NL consensus krijgen over hoe we de value willen toepassen. Alle borden op een paal in 1 value en de onderborden gescheiden met een komma? Of toch iets a la de Finse methode? Ik neig naar de eerste methode.

Ook over de naamgeving van de borden moeten we een ei leggen. C1 wordt zowel als C1 als als C01 aangeduidt. Zie bv hier: . Met alleen een RVV codering komen we er niet. Een maximum snelheidsbord van 50km/h is een A1 maar dan weet je nog niet welke snelheid dat is. Dan is een A0150 een ondubbelzinnige notatie. Uiteraard kunnen we ook nog een A1[50] oid verzinnen maar daar ben ik geen voorstander van omdat dit zo te zien geen gebruikelijke notatie is in NL. Ik stel dan ook voor om de fabrieksnummer/modelnummer notatie te hanteren. Dat maakt het ook veel eenvoudiger voor de overpass queries en het mapcss voor JOSM.

Welke discussie doel je hier op?

162

Ik heb een reactie van de Gemeente Rotterdam.

Over het laatste puntje heb ik nog gevraagd HOE dat beschikbaar gesteld gaat worden. Net als de verkeersborden?

163

https://lists.openstreetmap.org/pipermail/tagging/2014-February/016400.html
(De antwoorden daar gaan iets verder dan de vraag die je stelde over fictieve eenrichtingsbarriëren; ik neem aan dat je hier t.z.t. de discussie verder zet, maar ik wilde een ander aspect aan de orde stellen)

164

Ok helder. Ja zoals in mijn vorige post aangegeven weet ik ook nog niet wat de beste manier is van taggen van verkeersborden en hun implicaties. In een mailwisseling met Ilpo heb ik net ook aangegeven dat we misschien moeten proberen een soort hierarchie af te spreken voor verkeersborden (en nog even niet de implicaties) . Iets in de trend van:

1 Als het op de way kan (ondubbelzinnig) dan kiezen we dat. (bv de A1 borden met Maxspeed, of C borden die aan alle uiteinden van een weg helderheid bieden)
2 Zo niet maar het kan wel op een node, dan kiezen we die (bv. een aantal C-borden)
3 Als dat ook niet lukt dan misschien maar alleen een bord als los staande node mappen (bv dit voorbeeld van Ilpo een OB502 als je op een T-splitsing af rijdt en het bord staat op het eind waar de wegen samenkomen.)

Het is maar een idee hoor dus schieten wordt op prijs gesteld :wink:

165

En nog een reactie van Rotterdam. Die zijn lekker bezig met open data. TOP.

166

Ik ben ook nog even aan het zoeken geslagen naar een uniforme manier van aangeven welk bord wat is. Dat valt niet mee. Ik ben nu al diverse notaties tegen gekomen voor de borden. Hier een aantal varianten . 1 Erdi , 2 TSNED, 3 POL, 4 CROW .

Ik heb maar een mail naar de VNFV gestuurd in de hoop dat die iets van helderheid kunnen bieden.

167

Ik zou CROW gebruiken. Lijkt me een prima referentiepunt. Die lijst is toch ook nog van NEN en VNFV?* Meer normalisatie dan dit krijgen we nergens. De websites en catalogi van een van de fabrikanten zou ik juist niet volgen, want er is kans op coderingsverschillen tussen fabrikanten (en ik dacht dat de leden van VNFV er toch op die lijst overgingen**).

Kolom “Fabrieksnummer/modelnummer” bij CROW is zeker een optie.

Een extra “0” bij bord C01 enz. lijkt me prima. Het verandert niets aan de betekenis of herkenbaarheid van de borden. En het heeft (zoals je citeert van Rotterdam) ook voordelen.

Variabelen zoals snelheid enz. verwerken in een referentiecode zoals traffic_sign=A0130zb heeft voordelen (want ondubbelzinnig).

Het betekent wel dat sommige dingen anders wordt getagd op een weg dan in de tag traffic_sign=. Het wordt ook een systeem alleen voor Nederland (want andere landen hebben andere referentiecodes om naar de borden te refereren), dus uitbreiden naar andere taggingsvormen zal niet mogelijk zijn.

Edit: Onderborden: hier. Dus, bijvoorbeeld: OB52 “Uitgezonderd fietsers”.

168

Plaatjes van ook niet RVV borden, CROW heeft ze niet beschikbaar. Ze werken zelf met lage kwaliteit plaatjes.
PNG en SVG plaatjes vanwege transparantie en niet rechthoekig.

169

Ik geloof dat we de gebruikelijke tagging niet moeten vervangen met traffic_sign= (om redenen die ik hierboven al noemde), maar het aanvullend te doen.

Daarom zou ik traffic_sign= plaatsen op een knoop vlakbij de werkelijke locatie en loskoppelen van pogingen om het routeerbaar te maken. Of los, naast de weg, of als knoop in de weg/het pad.

Eigenlijk net als met tourism=information;information=board enz.

De keuze varianten zijn dan niet nodig.

170

Allroads, de plaatjes van de niet RVV borden kan ik misschien toch nog wel losweken, je hoort nog. Dat zijn er redelijk veel tegenwoordig, er worden er nogal wat bijgemaakt, het proces is geDTP’d en daarmee voor veel mensen een optie.

171

Helemaal mee eens. Het was ook niet mijn bedoeling dat voor te stellen hoor. Ik vind de implicaties belangrijker dan de borden maar de borden zijn veelal de oorzaak ervan. Daarom zou het mooi zijn als we in OSM ondubbelzinnig kunnen zien welk bord waar van toepassing is. Ook voor bv controle doeleinden of het mappen van de implicaties.

Gezien de reacties op tagging (al gaat dat meer over de implicaties op een node dan over de traffic_sign tag) vraag ik mij dus af wat wijsheid is. Is het zinvol om bv een traffic_sign:forward=NL:C6 te mappen op een node die onderdeel uitmaakt van de weg en tegelijkertijd de implicatie als een restrictie (met 2 wegen en een andere node) te mappen. Iets zegt me dat dit in tegenspraak is maar… misschien ben ik wel op zoek naar iets dat niet kan. Zie als voorbeeld de Ekris zoals deze nu in OSM staat.

De rode weg is 1 van de wegen die onderdeel uitmaakt van de restriction (restriction:motorcar=no_entry). Het verkeersbord is een losse node op deze weg (traffic_sign:backward=NL:C6) vlak bij de node van de restriction. Op zich ondubbelzinnig maar is het verstandig om die traffic_sign:backward=NL:C6 op de node te mappen. Het geeft wel aan voor welke richting die geldt en dat vind ik relevante informatie. Als we het bord helemaal als losse node naast de weg mappen dan zit je volgens mij met de vraag hoe we aan gaan geven voor welke weg en richting deze geldt. Bij de Ekris is wel helder voor welke weg dat is maar zeker bij punten waar veel wegen bij elkaar liggen zal dat een uitdaging worden.

Even hardop denkend zouden we misschien nog het volgende kunnen doen aangenomen dat een restriction relatie hoe dan ook nodig is.

1 Zet de traffic_sign tag weer terug op de node die onderdeel uitmaakt van de restrictie. De traffic_sign heeft dan geen forward/backward meer nodig omdat de restrictie al aangeeft over welke richting het gaat.
2 Geeft de restrictie relatie een extra tag : traffic_sign=NL:C6 (naast de restriction:motorcar=no_entry en type=restriction)

Zomaar een paar ideeen.

172

Op de tagginglist verscheen een item over speed cameras. Al lezende kwam ik op de wiki hoe men deze tagged en zag parallelen met verkeersborden die in 1 richting geldig zijn. Op deze wiki example 3b staat uitgelegd hoe dat werkt. Daar staan ook een paar filmpjes. Hier de JOSM variant. Kort samengevat:

Men plaatst een losse node naast de weg daar waar de camera staat. Op de weg worden een stukje ervoor en een stukje erna 2 losse nodes geplaatst. Al deze 3 nodes zitten in een relatie (ook to en from) zodat bekend is wat de richting van de camera is. Een voordeel van deze methode is dat de weg helemaal niet opgeknipt wordt en de camera ook in OSM exact staat waar ie in werkelijkheid staat.

Is dit een insteek die voor dit type verkeersborden te gebruiken is? Wat vinden jullie?

173

Ingewikkeld.
En je moet dan twee keer (of meer) relaties gaan invoeren: tenminste een keer voor de weg (turn restriction) en nog een keer voor het bord zelf.

Ik ben niet bang voor relaties (in OSM, :slight_smile: ) maar turn restrictions invoeren is al geen lol.

Ik zie me zelf het niet doen en betwijfel ook of de editors het gaan invoeren (misschien m.u.v. JOSM).

174

Ja.
Ik denk dat er iets met turn restriction nodig is.
en dan traffic_sign=NL: op de node en het aan de renderer overlaten waar het geplaatst moet worden.

(Daar is ook het e.e.a. over te zeggen, maar voordeel is: eenvoud.
Eenvoudiger dan dit kunnen we het niet maken.)

175

Bij nader inzien stel ik toch voor om in het voorbeeld van de Ekris de traffic_sign maar als aparte node naast de weg te mappen en in de turnrestriction relatie op te nemen als een location_hint. . De aparte traffic_sign node heeft dan ook geen forward/backward. Op die manier hebben we alle nodes en ways die iets met die restrictie te maken hebben ook opgenomen in de relatie. Daarnaast staat het verkeersbord keurig naast de weg waar ie in werkelijkheid ook staat zodat zelfs zonder de relatie in ogenschouw te nemen iemand wel kan vermoeden vanuit welke richting je daar met de auto niet in mag rijden. Wat vinden we hiervan?

176

Wat nu in mijn ogen primair is dat we het bord taggen, als eerste taggen. traffic_ sign=NLXX

Hier draait alles om, is nodig voor

  1. om op andere nodes ways relaties te taggen, de access te taggen.
  2. bordenschema door routeerders te gaan gebruiken (toekoemst)

Stel ook voor om in http://wiki.openstreetmap.org/wiki/Overzicht_Nederlandse_Verkeersborden#C:_Geslotenverklaring
De traffic_sign=NLXX als eerste vermelden misschien wel twee kolommen maken primair tag /secundaire tag.
Want als je het bord weet kan je eenvoudiger alle borden lokaliseren, en in een keer de secundaire tags toevoegen
op losse node
node van een way/way (lastig is backward and forward)
binnen een relatie
Denk aan de C borden met zeer lange tagstrings (meerdere tags).
We moeten routeringspartijen de mogelijkheid geven om nieuwe routeringsmethodieken te kunnen ontwikkelen. Crossmethodieken.
Daar hebben we zelf baat bij.

In principe vindt ik voorloopnul een slechte zaak, de it wereld moet aan de mens aan passen en niet andersom.
Maar, ja, bij de overheid wordt al met deze structuurfout gewerkt, omdat pc-progjes, de logica dan niet meer snappen. Schijnt nogal diep te zitten. Dus voorloopnul!

De vraag is of we zelf [50] [100m] moeten gaan gebruiken. Dit is wel een gebruikelijke wijze van notatie binnen OSM. [waarde op het bord] hierachter zb van zonebord
Taggers zullen toch veel het overzicht verkeersborden schema gebruiken. Dus om strikt CROW aan te houden is niet noodzakelijk.
We mogen daar onze eigen draai aan geven. Schept wel verduidelijking, ook internationaal gezien. En je kan je eigen bord maken met [15].
Ik denk dat ik toch deze keuze zou maken.

Van/naar is een richting.
Dit in een relatie, geeft de node naast de weg ook een richting.
Hierbij zou het bord (icoon) ook in de goede richting gedraaid kunnen worden. (toekomst)
Dan liever het bord niet apart voorzien van een direction=*.

We zijn dan af van forward/backward.
Vooral bij copy uit schema paste to node of way, bij selectie vele situaties, en vele borden in het geheel, zou dit problemen geven. Omdat je elke keer weer hebt, motorcar:backward=no of was het nu forward, te veel if and as.
Nu kan het afgeleid worden van way of de richting tussen twee nodes.
Van/naar geeft de mogelijkheid te taggen zonder de tekenrichting van de weg te kennen.
Dus relaties is toch de oplossing.

Ik zit nog wel even met de traffic_sign notatie
Meerdere borden op een punt.

traffic_sign=NL:XX(voorkant paal);NL:XX(achterkant paal)
en dan het gevolg
traffic_sign:2=;
etc.

Maar hoe je nu hoofdbord en onderbord met elkaar linked
traffic_sign=NL:XX(hoofdbord);NL:XX(onderbord);NL:XX(onderbord)
volgende borden combinatie
traffic_sign:2=NL:XX(hoofdbord);NL:XX(onderbord);NL:XX(onderbord)

en hoe dan met het achterkant bord op dezelfde paal
In combinatie met relaties voor de richting.

location_hint hier wordt wat anders bedoelt
het invoegen van from to “location_hint”, is nog best lastig te veel type werk “sign”

Een relatie hoeft op zich geen keys values te hebben.

177

Mee eens. Laten we nu eerst maar een kijken hoe we een verkeersbord als losse node willen mappen in NL.

Ik denk dat we misschien wel 3 kolommen moeten hebben. RVV (indien van toepassing) bv A1, Fabrikantennotatie bv A0130, OSM notatie bv NL:A01[30] of misschien toch A0130. Meer daarover stukje verderop.

Ik krijg steeds meer het idee dat die backward/forward op een node die onderdeel is van een way geen goed plan is

Ok. Ik heb de borden die ik het ingevoerd inmiddels voorzien van een voorloopnul. Ik denk (gezien Rotterdam) dat dit straks ook wel eens de notatie kan worden die in de BGT gebruikt gaat worden.

Ja… goed punt. Gezien het internationale karater van OSM zou je bv voor een 50km bord NL:A01[50] kunnen gebruiken. Waarschijnlijk heeft de way dan ook al een maxpeed=50 dus of het veel toevoegt? Alternatief is m.i. de NL:A0150. Tja lastig. Ik heb net het bordenwijzer besteld. Eens kijken of daar nog wat logica uit te halen is.

Ja… misschien wel de beste keuze.

Maar niet ieder verkeersbord zal onderdeel zijn van een relatie (gelukkig) en dan is het soms wel handig dat je weet voor welke richting het bedoeld is. Voor veel situaties zal het duidelijk zijn omdat borden veelal rechts van de weg geplaatst worden (maar zeker niet altijd). Ik vermoed wel dat er heel veel uitzonderingen op deze regel zijn en hoe gaan we dat dan mappen?

Ja zolang het in een relatie zit dan wel maar wat zouden we bv bij de Ekris willen taggen als aan beide uiteinden een C06 zou staan. Alleen de losse nodes naast de weg en geen traffic_sign op de way (maar bv alleen de implicatie motorcar=no) ?

Dit is de Finse methode. Bij de “gewone” wiki wil dit niet zeggen dat de ene kant de voor- en de andere de achterkant is. Daar kunnen wel 5 borden achter elkaar in de value staan.

Volgens de gewone Wiki moeten hoofd en onderborden met een comma (,) gescheiden worden en hoofdborden met een puntkomma (;).

Wat bedoel je hiermee? Bedoel je te zeggen dat een losse node (als traffic_sign) niet als location_hint gebruikt zou moeten worden in een turn restriction?

Ik denk inmiddels dat het toch niet verstandig is om een traffic_sign op te nemen als tag van de relatie (als we tenminste de losse traffic_sign node op kunnen nemen als location_hint)

178

Nog even een toevoeging. Die zb slaat op Zone Begin. Zo is er ook nog een ze (zone eind) een een zh van zone herhaling.

Ilpo heeft al een nieuwe versie gemaakt met voorloopnul en ook nog een backward/forward. Deze kun je hier downloaden. Let er wel op dat de plaatjes (mapnaam= img) ook een andere is geworden.

179

“A hint to a renderer as to where might be a good place to position a symbol indicating the restriction”
location_hint

locatie_ hint is het aangeven aan de render, als die een icoon wil plaatsen waar naast de weg jij bij voorkeur het icoon geplaatst wil hebben, zo lees ik dat.
Dat is eigenlijk een node zonder key/value, en in de relatie mee genomen, als role location_hint.
Een woord moet de inhoud dekken, hint is wenk tip toespeling.
Maar wij doen het anders we zetten een vaste node, en maken daar een verkeersbordnode van, die wel of niet een onderdeel van de relatie wordt. Met key value verkeersbord traffic_sign=NL:XX
Ik vroeg me dan af of een introductie van de role "sign"of zoiets beter is, dan weet een routerender mogelijk dat hij naar een bord value moet kijken, in combinatie met verkeersborden schema, de access (toekomst).

Ik heb dan al meerdere turn-restrictions gezet, en josm plaatste dan de algemene bordjes op eigen initiatief van de turn-restriction plug in bij het viapunt, en soms stonden die niet logisch.
Geen location_hint gebruikt.

Ik heb ook wat moeite mee om de term turnrestrictions te gebruiken, om voor de verkeersborden a la C te gebruiken.
ook omdat anderzijds, verwijst het al naar de plugin.

In het verkeersbordenoverzicht zou ik graag de mogelijkheid hebben (snel tag om daar al de node met NL bord tags te kopieren) voor in Josm met ctrl C plakken van een node.
En ook een plek om de access tags als geheel passende bij bord met shift ctrl C te plakken op de reeds aanwezig node way relatie.
Misschien een eigen josm plugin voor NLborden. want dit is toch de editor met diepgang.

We zullen toch de accesstringtags nog hebben:
Op de way moeten zetten ( voor de eerste vorm van routering, meest gebruikte methodiek)
Op node in way ( nog niet gebruikte methode) dan is ook behoefte aan richting backward forward)
Op de relatie bij from/to methode (routerender heeft dit nog niet opgepakt, toekomst)
Maar schijnbaar zijn ze er bekend mee, traffic_camera, dan zou implementeren toch dichter bij liggen dan we nu mogelijk verwachten.

Het ; en , had ik even over het hoofd gezien.
Maar hoe met ; en , dan de borden zichtbaar maken al la finse voorbeeld.
Met zo’n hele string van mogelijk twee hoofdborden en vijf onderborden. Is wel wat lastiger taggen, en begrijpen.
Ik heb het nog even zo ingevoerd (finse methode : 2 :3 ) bij enkele verkeersborden nodes.
En dan access op de weg.

C6 op Ekris, beide kanten, op zich aan beide kanten dezelfde methode is voldoende. (Dus niet over de hele weg.)
Denk dat dat nog het beste is.
Borden worden gezet op openbare wegen, borden uit de wegenlegger, verplichting na openbare zijweg het bord te herhalen indien nodig.

Maar ik ken ook zijwegen die niet in de openbare wegenlegger staan, zoek nog even naar een praktisch voorbeeld.
Niet alleen voor C6 kan ook voor foot bicycle motorcycle mofa moped zijn

Schematisch voorbeeld

A====================B====================C weg wegenlegger
|
| weg “niet” in wegenlegger, kan ook een track of path zijn over langgoed, eigen wegen, andere eigendoms terreinen. Verhard/onverhard.
|
|
D=NL:CXX=========== O==E =================NL:CXX===F weg wegenlegger
| |
| |
| | je kan ook zo’n weg kruisen

Rijden vanaf A-B-E-F
en zo kan je uitkomen op zo’n weg aan twee zijde een bord.
We willen niet alleen routering over alleen openbare wegenlegger wegen, maar ook over alle wegen/paden recreatief routering.
Dus de vraag moet op zo’n weg, over de hele weg access=no, denk het niet, je wilt ook dat stukje van E naar O routeren.
Eenmaal een andere keuze gemaakt is het slecht terug draaien.

180

Laten we dan “turn” weg. Ze heten op de wiki ook gewoon “Restrictions”.
http://wiki.openstreetmap.org/wiki/Relation:restriction