For the Dutch deployment it is important that we establish a robust and consistent annotation system for traffic signs. For now I focus specifically on the main signs, not yet on subsigns or supplementary panels. Below is the current structure …
Each traffic sign is assigned a fixed‑length identifier of 38 characters, built from five defined segments.
This structure brings together the logic of RVV, NDW, and VNVF, and ensures the system remains flexible so it can reference these sources reliably.
Segments
Nr
Length
Name
Description
Alignment
1
10
Source
Origin of the data or issuing authority
Left
2
6
RVV Code (Law)
Legal traffic-sign code according to the RVV
Left
3
3
Zone (NDW)
NDW zone or area classification
Left
4
4
Value (NDW black code)
NDW numerical or coded parameter
Right
5
15
VNVF Sign Code
Unique sign identifier following the VNVF standard
Left
6
38
Code
The concatenated full code (segments 1–5)
Purpose of this structure
This approach creates a single, stable reference that can reflect:
the legal classification (RVV),
the operational NDW coding model,
and the detailed VNVF sign definitions.
It also ensures that once the imagery dataset is published, each sign can be traced back to authoritative and technical sources.
At this moment the catalogue includes 188 traffic signs.
NDW/VNVF do not have their own traffic sign codes but use those of the RVV, so #5 can be left out.
ZoneCode/blackCode are fields you probably found in the verkeersborden_actueel_beeld_wgs84.geojson.gz I linked above.
ZoneCode: ZE = Zone-Eind, ZB = Zone-Begin, (ZH=Zone-Herhaling, ZO = Zone-Onbekend)
blackCode is text on a sign.
With that introduction, I would:
Start with the “extended” RVV code, B6, G11, G12a, A1-60, A1-30-ZE, E10-ZB, C2,OB54 see https://verkeersbordenoverzicht.nl/ for a de facto standaard overview. This includes the zone, “blackCode” and possible a lower-plate OB (onderbord)
That is not correct. VNVF uses the extra 0 (voorloopnul) . So A01 instead of A1 and may also add the indicated maxspeed value. In OSM-NL you will find both NL:G07 and NL:G7 since there is not a defined standard in OSM (whats new ).
Very interesting
Hoewel ik OSM niet terug zie in dat document zie ik wel mogelijke synergie voordelen.
De voorgestelde coderingen zoals A1‑60, A1‑30‑ZE, E10‑ZB, C2 laten meteen zien waar het schuurt: E10 heeft twee cijfers, A1 één. Zodra je varianten krijgt zoals A1‑30 en A1‑130, worden de velden automatisch verschillend van lengte. Voor snelheid is het denk ik daarom handig om uit te gaan van minimaal 3 karakters en deze rechts uit de lijnen.
NDW biedt daarnaast recent mogelijkheid om ook de plaatsnaam in de blackcode op te nemen, waardoor de code nóg langer wordt. Het is een keuze om die op te nemen. Het is denk ik minder nuttig om plaatsnamen of waardes van gewichtsbeperking te registeren, voor maximum snelheid zie ik meer toegevoegde waarde. Maar dat is een keuze.
In de VNVF‑logica staan blackcode‑ en zone‑informatie bovendien niet op vaste posities. Ook gebruikt VNVF voorloopnullen (bijv. RVV C2 → VNVF C02). Richtingen van pijlen zijn in het RVV nauwelijks gecodeerd, maar in VNVF wel, waardoor combineren mogelijk is.
Het RVV bevat daarnaast geen codes voor diverse moderne of aanvullende borden, zoals E8Q (parkeren voor deelauto’s), en ook geen bebakening zoals chevronborden, die wél in VNVF zijn opgenomen: Making sure you're not a bot!
Voor het samenstellen van de lijst heb ik gebruikgemaakt van:
Het CROW‑Informatiemodel Verkeerstekens is gebaseerd op IMBOR, maar is niet volledig en volgt niet consequent RVV, NDW en VNVF niet consequent.
https://www.verkeersbordenoverzicht.nl/ is ook geen officiële bron; de definities zijn deels gebaseerd op RVV, VNVF en NDW. Het overzicht is wel uitgebreid en de codering is logisch opgebouwd.
Ja, zo kan je dingen zien maar er ook een andere manier:
A1‑30‑ZB vs A1____ZB_30__A0130zb
Waarom is de variabele lengte wel een probleem voor de code kolom maar niet voor de value kolom? De codes die je op https://www.verkeersbordenoverzicht.nl worden wel door de meeste mensen herkend.
Ik vraag me ook af wat het doel is van de source kolom voor welke gebruikers is die data interessant? Dat volgt een beetje mijn eerdere vraag wat betreft het doel van dit formaat. Wie gaat de data aanleveren en wie het gebruiken?
Het kan dus voorkomen dat een bordcode wordt gebruikt door meerdere instanties met een verschillende betekenis. Je wil dan dat het eenduidig blijft
Daarom is ‘source’ denk ik heel belangrijk om mee te nemen.
Door te werken met een vaste lengte staat de zelfde soort informatie altijd op dezelfde plek.
Het kan uiteraard ook met een scheidingsteken, maar die moet dan nooit gebruikt worden voor andere zaken. Vaste lengte helpt denk ik aan het koppelen aan de NDW verkeersborden data.
In de de annotatie missen we nog voldoende voorbeelden van onderstaande borden om het algoritme alle borden te leren. Als iemand foto’s heeft van deze borden, laat het weten. .
NB: Het is wel van belang dat de afbeelden rechten vrij zijn.
To train a classification model you need that kind of cropped road sign pictures.
The goal is to have at least 100 samples for each type.
In my last training on NL signs there was 10k samples like that with more than 100 types.
For logic I should go with what used is in the field and that is what you can find on https://www.verkeersbordenoverzicht.nl/. Yes, this is not an official source but even CROW is saying that it is de facto standard.
Ook www.verkeersbordenoverzicht.nl gebruiken voorkomt dit probleem, het wordt naar mijn idee niet duidelijker met RVV1990 E08a en VNNF E8-1 o.i.d.
If there is missing training data it would be good to have a list and a place where people can upload photo’s. With a list of missing sign data I could make a script that finds them in the NDW data and make some software so people can input there coordinates and get a list of sign’s that need additional photo’s in their neighborhood.
Hieronder een lijst van locaties waar er volgens de NDW data een RVV bord staat in Amsterdam van de volgende RVV code (‘J31’,‘J32’,‘J33’,‘J34’,‘J35’,‘J36’,‘J39’,‘K14’).
Zie de images hierboven met de plaatjes bij deze codes.
Hiervan missen we nog voldoende trainingen foto’s die dus waarschijnlijk makkelijk te vinden zijn op de Panorama foto’s op data.amsterdam.nl
Ik zie niet hoe ik 123 een url kan maken zodat ik direct op de juiste locatie ben via de website van Amsterdam
Amsterdam pictures are “rotated” to always have the north in the middle of the picture. This is unusual and Panoramax viewer does not work well with this when moving between pictures in the same sequence, meaning you have to turn around from time to time.
road sign detection is using the standard detection model that has not been trained on NL road signs, meaning that some of them will not be detected (this can be improved by training a new model with NL signs in the training dataset which I plan to do quite soon)
road sign classification does not know the 180 types that have been mentionned here, but a subset of 120+
the tag I’ve used is also something temporary, closer to OSM tags (example: NL:A01[30] for a maxspeed=30), this can be changed later
I’ve uploaded some pictures shot in Amsterdam from early 2023, with quite bad weather !!
The instance is not open for uploads, it is really a PoC so far, runnning from my basement. I’ve not added it to the meta-catalog.
I have installed the Android Panoramax app and taken my first photos. I now want to upload these but I am having trouble finding how to do this. Is there some kind of manual or basic instruction?
).
