Nieuwe databron: Verkeersborden overzicht en locatie

Komende tijd wordt er een nieuwe databron beschikbaar gesteld als open data:

1 like

Interessant, hier trouwens een link naar de API van NDW

Misschien dat iemand anders 't weet, maar hoe verhoudt dit zich ten aanzien van de BGT en het (niet verplichte) object Bord

Hmmm, niet alle images zijn’ vrij’ opvraagbaar voor een aantal moet je een cyclomedia/streetsmart account hebben…

2 likes

Vanochtend heb ik de API bekeken.

Bevragen met een filter, bijvoorbeeld op gemeente, of met een geografische afbakening, is niet mogelijk.

Iedereen moet dus de hele dataset downloaden, van het eerste tot het laatste verkeersbord, in groepjes van maximaal 100 borden, en vervolgens alle niet-relevante borden weer weggooien.

Ook worden diacrieten niet goed vermeld: op de default pagina https://data.ndw.nu/api/rest/static-road-data/traffic-signs/v1/events staat een aantal keren de straatnaam ‘Schoonlo?rstraat’, in plaats van Schoonloërstraat.
Natuurlijk kun je dit vervolgens zelf weer oplossen door te post-processen met NWB, maar dat kan niet echt de bedoeling zijn.

Ik ben een groot voorstander van open data, en ik ben blij dat deze gegevens nu open beschikbaar zijn, maar in de huidige vorm vind ik de data redelijk onbruikbaar.

Misschien kan iemand (PDOK?) deze gegevens oogsten, en vervolgens aanbieden in een bruikbare vorm?

1 like

Zitten alle onderborden er ook in?

Want dat is vaak de laatste meest bepalende factor, wat mag, wat niet.
Zo ook het aangegeven bord, eerder post 2, het onderbord met uitgezonderd fiets en bromfietssymbool.

Jammer dat de data niet direct via PDOK beschikbaar wordt gesteld met een fatsoenlijk bijhoudingsbeleid. Ziet er nu uit als een hobby projectje van een ambtenaar met teveel vrije tijd.

Wat al genoemd is:

  • Sommige afbeeldingen zitten achter een login van Cyclomedia
  • Geen gebiedsaanduiding mee te geven
  • Onduidelijke documentatie
  • Diakrieten gaan fout

Ergens las ik dat ze het voor twee jaar hebben gefinancierd waarna ze kijken of het een blijvertje is. Verder werkt de voorbeeld url niet die ze verstrekken, de datumnotatie klopt niet.

Onderborden zijn volgens mij alleen aangegeven als er tekst op staat, dat wil zeggen dat je een tekstwaarde kan uitlezen. Maar de RVV code van onderborden kom ik niet tegen. Misschien moet je die uit de bijbehorende foto halen?

Is er ergens ook een uitleg hoe je deze borden-data zichtbaar kunt maken in bijvoorbeeld Qgis?

Vandaag heb ik als test de eerste 10.000 verkeersborden maar eens binnengehaald.

De oogst: 10.000 borden in 33 gemeenten (met in de helft van deze gemeenten minder dan 10 borden) door het hele land.
De borden zijn in de RVV-series A, B (geen BB, BE, BT, BW), C, D, E, F, G, H, J, L. In totaal 132 verschillende RVV-codes (plus 477 borden met code onbekend).

Geen onderborden (RVV-serie OB).
De toegezegde teksten uit de onderborden zie ik niet terug in de JSON-download. Ook de woonplaatsen ontbreken. Foutje?
Bij de A-borden geen informatie over de snelheid die op het bord wordt afgebeeld.

Ik beschouw deze open data vooral als een warmmakertje voor het bijbehorende commerciële product, dat veel meer informatie bevat. Al kun je voor meer informatie natuurlijk wel doorklikken naar de streetsmart-foto, als je daar een licentie voor hebt.

2 likes

Het beheer van deze data lijkt me bijzonder geregeld (lezend op Verkeersborden in Nederland vanaf nu digitaal beschikbaar | Nieuwsbericht | Rijksoverheid.nl). Een derde partij inventariseert verkeersborden en dat levert dan relevante data op voor wegbeheerders. Maar: zijn het niet juist deze wegbeheerders die de borden plaatsen en dus (zouden moeten) weten wat er waar staat en hangt? Zijn zij niet de bronhouders?

In reactie op:

Is er ergens ook een uitleg hoe je deze borden-data zichtbaar kunt maken in bijvoorbeeld Qgis?
@ardegberts

Deze data is niet rechtstreeks zichtbaar te maken. Je kunt de informatie van maximaal 100 borden opvragen. Welke borden dat zijn bepaal je door een volgnummer mee te geven voor het eerste bord, de website retourneert dan de volgende 100 borden.
Helaas is het niet mogelijk om op te geven dat je alleen binnen een bepaalde bounding box wil bevragen, of alleen borden met een bepaalde RVV-code, of in een bepaalde gemeente. De 100 borden die je ophaalt kunnen in het hele land staan.
Je kunt alleen maar eerst de 100 borden ophalen, en daarna uitzoeken welke borden voor jou relevant zijn.

Na wat testjes heb ik een FME workspace gemaakt die het volgende doet:

  1. Bepaal het hoogste volgnummer dat al aanwezig is in de gegevensopslag
  2. Vraag, met dit volgnummer als parameter, de informatie op van de volgende 100 borden
  3. Schrijf alle opgehaalde informatie naar de gegevensopslag
  4. Verwijder vervolgens de borden uit de gegevensopslag die niet in mijn interessegebied liggen, BEHALVE het bord met het hoogste nummer (dat heb ik nodig in stap 1, de volgende keer dat ik de workspace uitvoer).

Opmerkingen:

  • In stap 4 wordt ook automatisch het bord verwijderd dat in stap 1 werd gebruikt (als het tenminste niet in mijn interessegebied ligt). Daarom verwijder ik de niet-relevante borden pas na het wegschrijven naar de gegevensopslag.
  • Na afloop van de workspace heb ik dus (maximaal) één bord in mijn gegevensopslag zitten dat niet binnen mijn interessegebied valt.

Omdat ik op dit moment nog geen geometrie heb gemaakt uit de X- en Y-coördinaat, gebruik ik als gegevensopslag een non-spatial Oracle-tabel (dat zou net zo goed in PostGres, of in een GeoPackage-tabel zonder geometrie kunnen zijn; zelfs een Excel-bestand kan voldoende zijn, afhankelijk van je eventuele vervolgstappen). Wanneer je in de workbench wel puntgeometrieën wil maken, kan dat natuurlijk ook.

De workspace heb ik geüpload naar FME Server, waar een automation er voor zorgt dat de workspace elke 10 seconden wordt uitgevoerd.
Voor de zekerheid zet ik de automation handmatig aan nadat ik ben ingelogd, en zet ik de automation aan het einde van mijn werkdag weer handmatig uit. Zo nodig kan ik de automation ook tussentijds stoppen, als we de licentie even voor een andere klus nodig hebben.

Momenteel bekijk ik deze gegevens in QGIS door een virtuele laag aan te maken, die de locatie van het bord bepaalt uit de velden X en Y van mijn tabel.
In QGIS kun je visualiseren met een SVG-symbool. SVG-symbolen van de Nederlandse verkeersborden zijn onder andere te downloaden via Wikipedia: https://nl.wikipedia.org/wiki/Verkeersborden_in_Nederland).
De dataset geeft aan in welke richting (Noord / Oost / Zuid / West) het bord leesbaar is, dat gebruik ik (voorlopig) om het bord te roteren in QGIS. Er zijn ook borden met alleen richting L (links van de weg) of R (rechts van de weg), daar doe ik voorlopig even niets mee.

Op termijn wil ik een betere richting aan de borden geven door het Nationaal Wegenbestand (NWB) te gebruiken. Omdat onze GIS-viewer een lijntje nodig heeft om een symbool te roteren, ben ik van plan om met FME een richtingpunt op 1 meter in de gewenste kijkrichting toe te voegen, parallel aan de dichtstbijzijnde weg in NWB.
Daarbij hou ik wel rekening met het richting-attribuut dat al aan de borden hangt: sommige borden (bijvoorbeeld C4) hebben een aparte behandeling nodig.

Ik heb een python script gemaakt om alle data via de api op te halen en in een .CSV bestand weg te schrijven.

1 like

Script blijft (na ruim 4 uur draaien) hangen op tijdsitp:
2020-08-17T12:50:03.399Z

Dat is het hoogste tijdstip in de dataset, en wordt eindeloos opgevraagd. Ik zal een issue op github aanmaken.

Deze manier van data aanbieden is trouwens verschrikkelijk @ndw :frowning:

1 like

Op zo’n manier aanbieden heeft inderdaad weinig met open data te maken

Gelukt! Ik heb een pull request gedaan met een fix voor het python script.

En ik heb de csv opgeschoond en geconverteerd naar een 291mb GeoPackage met 834k verkeersborden. Wie interesse heeft, laat maar weten.

6 likes

De fix is opgenomen in de originele code. Mooie samenwerking zo. GitHub - Uijtdehaag/Verkeersborden: Harvest de verkeersborden die via Nationale Databank Wegverkeersgegevens (NDW) als open data beschikbaar zijn gesteld.

3 likes

Mooi gedaan heren. Ik heb wel interesse dus laat maar weten hoe ik die geopackage kan krijgen.

Heb hier een gezipte gpkg neergezet (67mb). Ik kan nergens een licentie vinden, dus geen idee of dit mag. Behalve dat er staat “Verzamelde gegevens worden via de Nationale Databank Wegverkeersgegevens (NDW) als open data beschikbaar gesteld, bijvoorbeeld aan leveranciers van informatiediensten en aan wegbeheerders.”

http://terglobo.nl/downloads/traffic_signs_ndw_20200820.zip

En het zijn eigenlijk een soort was/wordt mutaties, dus je zou een download en update script moeten hebben dat een actuele dataset bijhoudt. (Ik voel een verkeersbordactueelbestaand aankomen :D) Maar deze gpkg is leuk om mee te spelen, voor nu.

2 likes

Bedankt . Ik ben een beetje aan het freubelen gegaan en inmiddels als best een leuk kaartje in QGIS kunnen maken. Best interessante dataset voor Openstreemap. Dit om bv toegang (Access) te mappen. Hier een kaartje van wat gemeentes in de provincie Utrecht. Er is ook een WMS van zodat ook JOSM (editor voor openstreetmap) deze data zichtbaar te maken is. Ik heb hier alleen een beperkt aantal C en G borden genomen maar uiteraard is er veel meer mee te doen. Hoe dan ook… voor mij is dit een interessante set met gegevens. Smaakt naar meer.

1 like

Ik heb inmiddels ook een download-programmaatje gemaakt en alles gedownload, afgelopen weekend en heb nu 954.008 unieke entries opgehaald.
Waar ik tegenaan liep, was dat ik een heleboel dubbelen kreeg.
(Nog even los gezien van het feit dat het eerste van je 100 opgehaalde records steeds gelijk is aan de laatste van de vorige ‘batch’, als je als offset steeds de laatste publication_timestamp gebruikt).
Het blijkt dat de ‘offset’ (publication_timestamp) NIET in strikt chronologische volgorde komt.
Dat leverde bij mij ca 20% aan dubbelen op (1.2 miljoen records opgehaald om 954.000 unieken over te houden).
Ik kan nu geen kant en klare URL geven die gelijk 100 records ophaalt waarin dat zichtbaar is want de service lijkt momenteel plat te liggen (ik krijg nu 502 Bad Gateway terug), maar ik heb genoteerd dat de eerste groep dubbelen al na 1290 records optreedt.
Dit kan ik er nog wel aan toevoegen:
Na 2020-07-06 16:52:46.714 volgt 2020-07-06 16:52:40.381.
Een sprongetje terug van zo’n 6 seconden.
Dit verschijnsel trad best vaak op.

Een andere kleine tekortkoming is dat er soms wat rare unicode karakters zitten in de tekst_signs en in de straatnamen. Het eerste voorbeeld daarvan zit al in het 5e record: Schoonlo?rstraat.

Ik hoop dat ze dit soort dingetjes nog verbeteren…

1 like

Zeer veel interesse in de geopakkage van Raymond Nijssen.

Groet Jan Pieter

De link staat hier: Nieuwe databron: Verkeersborden overzicht en locatie - #16 door raymondnijssen - Datasets - Geoforum