NDW verkeersborden geopackage Qgis

In dit draadje van het oude forum gaf Smoothfiets al een mooi voorbeeld van het gebruik van de verkeerborden dataset. Ik ben ook aan de slag gegaan met deze NDW dataset en heb dit in een geopackage bestand gestopt die hier te downloaden is (gezipt). Deze is te gebruiken voor hen die Qgis hebben (of willen proberen).

Het voordeel hiervan is dat je zelf een selectie kunt maken van de borden die jij interessant vindt en uiteraard ben je in Qgis ook helemaal vrij in de opmaak w.o. de grootte van de icoontjes, zoomniveau en labels.


Als je op de icoontjes klikt met de ‘identify features’ tool dan kun je ook de features opvragen. Standaard bevat het label ook de datum waarop het bord voor het laatst gezien is (lastseen) maar dat kun je allemaal naar believen aanpassen maar daar is wel wat basale Qgis kennis voor nodig.

Verder goed te weten dat ik de icoontjes gedraaid heb voor beter gevoel van de richting (N,O,Z,W) .
En verkeersborden icoontjes met een cijfer erin (bv maximum snelheid 50) geeft aan dat dit het type bord is maar de waarde kan in werkelijkheid van alles zijn (dus bv ook 80km/u).

Als je de QuickOSM plugin installeert in Qgis kun je ook heel snel van Qgis naar JOSM springen waarbij meteen on the fly de OSM data in JOSM geladen is. Er handig om te mappen op deze manier. Zie rode vakje in plaatje1.

De instructie om deze geopackage te gebruiken staat hieronder. Hopelijk werkt dit. Feedback is welkom.

Om het in Qgis te gebruiken kun je als volgt doen:

Download het bestand en pack deze uit (unzip)
Open Qgis
Kies Project>open.From geopackage
Klik op de 3 puntjes
geopackage5

Selecteer het geopackage bestand dat je hebt gedownload en uitgepakt en kies het project “verkeersborden”

Klik op OK dan zie je als het goed is ongeveer plaatje1 en ben je klaar.

NB: Je kunt gebruik maken van de laag ‘Alle borden’ maar je kunt ook je eigen laag maken. Dat doe je door rechts te klikken op ‘Alle borden’ en te kiezen voor “duplicate layer”. Die nieuw laag kun je een andere naam geven en vervolgens in die laag aan/uitvinken naar behoefte.

2 Likes

Heel erg mooi dit, zeg! :ok_hand:

Mooi flexibel dat je zelf selecties van borden kan maken afhankelijk van je interesse
En handig die rendering met de rotatie van de borden, die gevoel geeft voor de richting waarin ze gelden (blijft soms puzzelen, blik op een foto blijft soms nodig in complexe situaties)
En ook mooi dat verwijderde borden zijn uitgefilterd, scheelt weer verwarring.

Zeker met de selectie op fietsborden valt eerder op dat de inwinning van het bronbestand wel selectief was: vooral op de plekken die goed / legaal met de auto te bereiken zijn.

Fiets- en voetpadborden die in het veld wel aanwezig zijn op locaties die niet direct naast een rijbaan liggen zie je vaak in het bestand niet terug. Het ontbreken van dergelijke borden in het bestand is dus geen reden om op voorhand te twijfelen aan de juistheid van OSM-data in dergelijke gevallen, wel kan het natuurlijk aanleiding zijn om de situatie nader te bekijken.

Oja, en de onderborden zijn in het bronbestand niet gecodeerd toch?
Er kunnen dus in werkelijkheid uitzonderingen gelden op de borden (zoals “fietsen toegestaan” onder een bord G7-voetpad) die je niet in het bestand terugvindt ?

Van deze geopackage gaan we veel mapplezier beleven!

Dank voor de complimenten. Een toelichting op de borden (en hoe die data tot stand komt) kun je vinden in dit PDF document. Best interessant om te lezen hoe dat werkt. Een aparte kolom voor onderborden heb ik niet gezien maar wel een kolom met de naam “text_signs” (= de tekst van een onderbord.) Geen idee of dat een beetje dekkend is en of daar geen fouten in zitten. Dus onderborden zonder tekst (bv met pijlen naar links en rechts om 2 richtingsfietspad aan te geven) heb ik niet kunnen ontdekken.

Ik zag al wel een G13 maar die stond niet bij een fietspad. Het onderbord gaf aan …" na 125 M rechts". Dat leek beter te kloppen. :wink:

Nog wat zitten browsen en een exemplaar van bord-onderbordcombinatie bekeken die je vaak ziet: C2 met een onderbord "uitgezonderd [fietssymbool] [bromfietssymbool] "

Dat geeft *[ textsigns=uitgezonderd ]
en [image= https://signimages.ipsm.nl/1f3/1f36e8eb-2c35-4519-a629-a5a17aceb1ea.jpg ] met de bijbehorende afbeelding van die bordencombinatie


(maar niet geclassificeerd met de OB4-code die je bijvoorbeeld hier en de OSM-wiki ziet) :

Het grappige is dat die image-url op zich wel uniek lijkt te zijn in de database (als je erop filtert dan wordt alleen dit ene exemplaar getoond dat ik eerder zelf had bekeken.

Maar tegelijk lijkt het ook weer geen specifieke foto van het unieke bord, zoals onderstaand voorbeeld illustreert, waarbij de in het bordenbestand gelinkte foto duidelijk afwijkt van de geplaatste versie.

Ben benieuwd: heeft iemand die link al kunnen tussen de type onderborden en de foto-url’s al kunnen doorgronden ?

Voorbeeld Elspeet (D4) :

In werkelijkheid alleen een symbool op het onderbord, geen text
Geeft geen waarde voor “textsigns” (NULL in Qgis)
Wel onderbord te zien op [ image= https://signimages.ipsm.nl/e68/e6871207-3381-47eb-9815-d76d95ea79e4.jpg ]
e6871207-3381-47eb-9815-d76d95ea79e41

Alleen dat is wel een foto van hetzelfde type onderbord [symbool sedan] als hier is geplaatst, maar geen foto van hetzelfde exemplaar, want het symbool is duidelijk anders vormgegeven, zie :

https://www.mapillary.com/app/?pKey=980995125975309

Scherp gezien hoor. Het lijkt er op dat op hun plaatjes de borden en onderborden aparte plaatjes zijn. Zie dit voorbeeld waarbij de kijkhoek van het bord en onderbord echt anders is. Wellicht herkent men wel de onderborden en worden er dan onderborden bij geplakt die een wat leesbaarder formaat hebben. (=puur speculatie ). Maakt mij ook niet zo veel uit als het maar correct is. Dan is het onderbord wellicht ook wel beter leesbaar dan op de werkelijk genomen foto.

In Qgis kun je met de “DB manager” plugin selecties maken op je data. bij voorbeeld een aparte laag met alleen de borden met een onderbord(=textsigns) erin. Daar is dan een sql statement voor nodig.

select * from Alle_borden where textsigns is not null

Zie hieronder.


1 Like

Thx!
Bij mij gaf de DB manager de huidige geopackage niet aan, alleen een oudere geopackage waar ik wel een verbinding (op afstand) had gemaakt.

Kwam wel tot hetzelfde resultaat qua selectie als in jouw voorbeeldplaatje rond de Arnhemseweg door met een gewoon filter op de laag (Lagenpaneel → rechtermuisknop op laag → “Filteren…”) in te voeren:
"textsigns" IS NOT NULL

Even checkvraagje in verband met de te hanteren workflow als je dit mooie bestand wil gebruiken voor aanvullingen op OSM:

  • Klopt het dat borden met onderborden met daarop alleen symbolen (en dus geen tekst + symbool) met dit filter niet worden gevonden en dat je voor de check of er een dergelijk onderbord is dus altijd het betreffende plaatje in “image=https…” moet bekijken ?

  • en de kompasrichting bij “side” (en de renderrichting) is zo te zien de richting waarin je moet kijken om haaks op (de voorkant) het bord te kijken, dus niet per se de richting waarin het bord werkzaam is (meestal wel, maar bij een onderbord met een pijl kan dat ook 90 graden de andere kant op zijn) ?

  • heeft iemand een idee hoe we deze codering kunnen ontcijferen om onderborden met alleen symbolen toch te kunnen selecteren ?

Onderborden met alleen symbolen zijn op verschillende manieren relevant voor onze tagging:

  • bij fietspadborden (pijlen) voor oneway=yes/no en voor de richting waarin het bord van toepassing is (verlengde van kijkrichting vs haaks daarop)
  • bij verbodsborden (C-serie) zowel voor de richting waarin het werkt (pijl; voorbeeld) en ook voor inperking (alleen vrachtwagensymbool onder C2: geldt dus niet voor andere voertuigen)

Heb voor dat laatste punt even zitten kijken naar het eerste deel van drie karakters ( /xxx/ ) binnen waarden van de urls van hetzelfde bordtype bij “image=” , maar daar zag je binnen dezelfde waarde (xxx) toch andere combinaties van onderborden (bij hetzelfde hoofdbord), gaat mijn pet te boven :wink:
De eerder gelinkte handleiding gaf ook geen uitsluitsel.

Voorbeeldje bij de eerste twee punten:
Deze twee borden zijn na toepassing filter op aanwezigheid van een waarde in “textsigns” niet meer zichtbaar (want “textsigns=null” )

Maar op de plaatjes waarnaar wordt gelinkt in image zijn wel onderborden te zien (met daarop alleen maar symbolen, geen text):

Westelijk bord: https://signimages.ipsm.nl/926/9269671c-863d-42e2-9603-6cbfe12d16c2.jpg
9269671c-863d-42e2-9603-6cbfe12d16c21
Oostelijk bord: https://signimages.ipsm.nl/a8f/a8ffc16c-147f-4582-953d-d5fa9643a5b8.jpg
a8ffc16c-147f-4582-953d-d5fa9643a5b81

En hoewel de plaatjes waarnaar wordt gelinkt in het verkeersbordenbestand van een andere locatie zijn, klopt de inhoud wel met de feitelijke situatie, zoals in deze eigen foto ter plekke:

Ik had bij de uitleg nog kunnen melden dat je een permanente connectie kon maken met de geopackage. Dan had je em wel gezien in DB manager.

In de browser rechts klikken op het woord Geopackage en dan new connection naar het bestand.

Ik denk het inderdaad maar 100% zeker weet ik het niet.

Ik denk het wel maar ook hier weet ik het niet zeker. De side (N,O,Z,W) heb ik gebruikt om het aantal graden te bepalen (rotatie) en vervolgens Qgis het plaatje te laten draaien.

Ik niet maar wellicht een ander. En als niemand het weet dan zou je ook de vraag kunnen stellen aan de bronhouder.

1 Like

Hoi Peewee32,
Ik neem aan dat je de API van deze dataset gebruikt om de borden af te halen. Heb je enig idee hoe vaak die databank bijgewerkt wordt? In Vlaanderen hebben we een dataset dit continu bijgewerkt wordt, en dat betekent dat er iets heel interessants kan: filter enkel de allernieuwste borden. Daar houden we enkel de interessantere borden van over, en die zetten we dan op MapRoulette als microtaakje. Is dat een methode die ook in Nederland zou kunnen werken, denk je?
De code staat hier: GitHub - osmbe/traffic-sign-project: Project to map the effects of traffic signs . Ik heb zelf met een niet-OSM’er de proof of concept gemaakt; Ivan Diaz van TomTom is aan het helpen om er een volautomatisch systeem van te maken.

Hoi Joost. Dank voor het delen van deze info.

Die NDW link is inderdaad de bron van de data. Ik haal daar de hele dataset binnen in csv formaat.

https://data.ndw.nu/api/rest/static-road-data/traffic-signs/v1/current-state?content-type=csv

Daarna import in Postgis en verwijderen van borden die weg zijn (removed). Daarna kan ik een vergelijking maken met OSM en bv dit soort kaartjes maken waar mensen mee aan de slag kunnen (ook een soort maproulette :wink: ).

Ik heb als extraatje de geopackage gemaakt om het ook voor anderen wat makkelijker te maken er mee aan de slag te gaan. Grootste uitdaging daar was alle svg plaatjes van de borden te pakken te krijgen. Daarnaast nog zien op te slaan in de style van Qgis (ipv referentie naar pad waar de svg files staan) maar dat is nu klaar. (zie qml bestand verderop)

Op zich snap ik de wens om nieuwe borden te zien maar in NL is nog zoveel te doen met bestaande borden dat hier volgens mij de meeste winst te behalen is. En nog meer verschillen analyses zou denk ik ook wel werken maar de vraag is ook of we voldoende mappers hebben die dit willen op pakken.
Ik heb eerder kaartjes/WMS gemaakt van zaken die aangepakt kunnen worden. Als je daar kijkt naar nummer 3 (defragmenteren van wegen) dan zien we dat er een kleine 75000 wegen zijn samengevoegd. Dat is best heel veel werk geweest verricht door een handjevol fanatieke mappers. Maar met dit tempo zijn we nog wel flink wat tijd bezig. (maar kudos voor dat handjevol mappers overigens)

Is Belgie al zo compleet gemapt dat oude borden niet meer zo interessant zijn?

Het mooie van zo’n maproulette is wel het competitieve element en dat je ook echt voortgang ziet. Ik ben niet handig genoeg om hier een NL versie van te maken nog even los van het feit dat ik me liever met andere OSM zaken bezig hou. Maar wellicht zijn er anderen die dit op willen pakken.

N.a.v. jouw post ben ik nog wel even verder gaan kijken want voor Qgis gebruikers zijn er mogelijkheden om zelf de verkeersborden data te verversen en eigen selecties te maken. Dat wil ik hieronder even delen.

Eerst de csv downloaden (zie bovenaan deze post) en in inlezen in Qgis.
Vervolgens alle opmaak van de plaatjes regelen door het qml bestand te laden. (of evt de opmaak/style te kopieren van de eerder geopende geopackage)
Zo’n csv werkt echter niet zo snel/lekker als een geopackage. Met de processing toolbox (processing plugin) kun je vrij eenvoudig met de ‘package layers’ daarvan een nieuwe geopackage maken (inclusief opmaak) die erg snel werkt.

En met de Qgis DB manager ( of filter op de laag) kun je vervolgens selecties maken op dat bestand afhankelijk van je wensen. BV filteren op de ‘firstseen’ kolom om recente borden te bekijken of filteren op een specifiek bord of gemeente.

Vergeten te melden maar … nee geen idee. De set die ik vandaag downloade had als datum lastseen 22-12-2022 en de set van 9-12-2022 had 30-11-2022 als datum lastseen. Ik meen gelezen te hebben dat gemeenten ook zelf kunnen muteren dus actualiteit zou per gemeente behoorlijk kunnen verschillen.

Die echte analyse is wel schitterend. Staat de code daarvoor ergens online?

De kwaliteit van de verkeersbordendata is bij ons heel erg wisselvallig. Dus een focus op een specifiek gebied heeft enkel zin als je eerst een analyse doet van hoe goed de kwaliteit is. Die analyse is redelijk lastig en zou je regelmatig opnieuw moeten doen. De kwaliteit is wisselvallig omdat ze eenmalig een massieve operatie hebben gedaan, vergelijkbaar als die bij jullie, en daarna er enkel updates komen als de gemeente daar zin in heeft (zonder enige verplichting of duidelijke voordelen voor de gemeente).

Maar sommige gemeenten doen het wel goed, en we willen hen op een of andere manier een hart onder de riem steken door hun data te analyseren. Die nieuwe borden zijn per definitie van gemeenten die hun best doen. Gewoon die selecteren betekent dat we per definitie up to date blijven met de gemeenten die het werk doen.

Een tweede reden om te focussen op nieuwe borden, is dat er heel regelmatig zaken sterk veranderen: er wordt hier heel veel gespeeld met circulatieplannen om mobiliteitsproblemen aan te pakken. Dat betekent dus vaak nieuwe snelheidsregimes, maar vooral nieuwe knippen of ander éénrichtingsverkeer. Ook hebben we een inhaalbeweging van nieuwe fietsinfrastructuur, heel vaak nieuwe fietsstraten bijvoorbeeld. Dat zijn zaken die je niet zo eenvoudig kunt bijhouden op basis van wat we als mapper toevallig oppikken. De focus op nieuwe borden betekent dat we 99% van de verkeersborden niet meer hoeven te bekijken, en dat we die nieuwe situaties heel snel oppikken. Leuke technische bijkomstigheid is dat we ook niet per sé hoeven te analyseren of dat nieuwe bord misschien toch al zijn effect heeft op OSM, aangezien de kans relatief klein is dat een mapper het al heeft gezien vooraleer het bord in onze queue komt.

De situatie zal bij jullie dus wel enigszins anders zijn, maar op het eerste zicht denk ik dat het misschien ook wel een relevante piste is voor in Nederland? Overigens hoeven jullie denk ik niet veel te doen, behalve dan Ivan en mij adviseren, vooral dan “welke codes van verkeersborden zijn interessant”.

Bedankt. De code staat niet online maar is ook niet nodig want het is een erg simple GIS functie. Als het verkeersbord binnen 15 meter van een fietspad staat dat nog geen ‘traffic_sign’ tag heeft dan laat ik em zien.

Where ST_Intersects(ST_Buffer(h.way,15), vb.geom)

Dank voor je toelichting en je aanbod om ook voor NL e.e.a. te willen regelen. Ik denk alleen niet dat ik de persoon ben die moet gaan zeggen welke borden het handigst zijn om te tonen. Ik wil niet ondankbaar overkomen maar ik heb geen behoefte aan nog meer OSM werk. Ik heb mijn handen al vol aan het bijwerken van die fietspaden en ander analyses. Hopelijk zijn er anderen die willen reageren en je kunnen voorzien van een aantal bordcodes.

De opvraag is nu in de url v2

tevens hoe het verder gaat met de verkeersborden database.
Met als leuke link, verkeersborden map van de NDW

Inmiddels levert NDW al bijna drie jaar verkeersborden, zoals die door het ministerie van IenW zijn ingekocht bij de HR-groep, door als open data.

Sinds december hebben we de database uitgebreid met zwarte codes en met een NDW-identificatie voor elk bord.

Per 26 januari hebben we additioneel een interactieve muteerapplicatie voor verkeersborden beschikbaar gesteld.

6 maart zal de mutatiestroom vanuit de HR groep stoppen, omdat het contract met het ministerie van IenW dan afloopt. Deze nieuwsbrief brengt je op de hoogte van de laatste ontwikkelingen op dit gebied.

Actueel beeld

Het actueel beeld op de NDW open data omgeving wordt inmiddels om de dag geactualiseerd beschikbaar gesteld in plaats van eenmaal per maand.

Het actueel beeld is ook in de open data raadpleegomgeving te bekijken.

Leveringen vanuit de inkoop van het Ministerie van IenW

Het contract van het ministerie van IenW met de HR-groep voor het leveren en jaarlijks updaten van de verkeersborden loopt nog tot begin maart.
Vanaf dat moment komen er geen updates als gevolg van de landelijke jaarlijkse schouwronde meer uit die bron. Voor het updaten van de op deze manier ontstane goede basis is een muteerapplicatie ontwikkeld en gaat nog een bulk import functie ontwikkeld worden.
Het is de keuze van de wegbeheerder via welke route hij het bestand actueel zou kunnen of willen houden.

Mogelijkheden om interactief te muteren

Voor wegbeheerders is het sinds eind januari mogelijk een account aan te vragen bij de servicedesk van NDW om mutaties aan te kunnen brengen. Dit interactieve muteerdeel zal de komende periode verder verfijnd worden, mogelijk met iets meer logicacontroles, picklijstjes van toegestane waarden in plaats van vrij invullen, toevoegen van mutatiemogelijkheden voor velden die nu nog niet gemuteerd kunnen worden een controle op areaal, enzovoorts.

Aanleveren van mutaties in bulk

Het vanuit andere applicaties, bijvoorbeeld beheersystemen, aanleveren van een bestand met mutaties gaan we ook faciliteren. Er worden drie interfaces beschikbaar gesteld in de applicatie, één om zwarte codes in bulk aan te leveren, één om nieuwe borden op te voeren en één om mutaties op al aanwezige borden door te geven