Na het verzamelen van de data begon de voorbereiding in QGIS. De ongevallenlijst bevatte heel wat velden die voor deze demo niet nodig waren. Die overbodige velden heb ik verwijderd om de dataset overzichtelijker te maken.

Omdat de ongevallen coördinaten bevatten, kunnen ze naar punten op een kaart getransformeerd worden. Eens ingeladen in QGIS, heb ik daarna de ongevallenpunten ruimtelijk gekoppeld aan het wegenregister. Zo kon ik de dataset verrijken met straatnamen.

Ook de gemeentegrenzen en bevolkingsstatistieken moesten op elkaar afgestemd worden. Beide datasets bevatten een veld NISCODE. Door veldnamen en datatypes gelijk te zetten, wordt de latere koppeling eenvoudiger en betrouwbaarder.

Na de voorbereiding heb ik de opgeschoonde en verrijkte data via QGIS geïmporteerd naar een lokale PostgreSQL-databank met PostGIS.

PostGIS maakt van PostgreSQL een ruimtelijke databank. Daardoor kan je geometrieën opslaan, ruimtelijke analyses uitvoeren en data voorbereiden voor gebruik in een webkaart. Voor organisaties betekent dit dat data niet langer vastzit in losse bestanden, maar terechtkomt in een centrale, bevraagbare databank die geschikt is voor API’s, dashboards en automatisering.

Voor ik de databank online zette, testte ik lokaal de query’s die ik later in de Node.js-app zou gebruiken. Denk aan het ophalen van gemeenten en hun grenzen, ongevallenpunten, straatinformatie, totalen per gemeente en gegevens voor grafieken en trends. Hiervoor gebruik ik meestal via de open-source databasetool DBeaver. Ik gebruik het voor aanpassingen/controles op datatypes, joins, aantallen records en SQL-queryresultaten. Deze controle is belangrijk. Een dashboard kan er visueel mooi uitzien, maar als de onderliggende data verkeerd geïnterpreteerd wordt, zijn de inzichten niet betrouwbaar.

Nadat de belangrijkste SQL-query’s lokaal getest waren, begon ik met de ontwikkeling van de Node.js-app. Die applicatie bouwde ik in Visual Studio Code, met Node.js en Express als basis. Het doel was om geen statische kaart te maken, maar een echte webapplicatie waarin de gebruiker een gemeente kan zoeken en daarna automatisch de juiste kaartlagen, KPI’s, tabellen en grafieken te zien krijgt.

De app bestaat grofweg uit twee delen. Aan de backend-kant zorgt Node.js ervoor dat de juiste data uit PostgreSQL/PostGIS wordt opgehaald. Aan de frontend-kant worden die gegevens getoond op een interactieve Leaflet-kaart en in grafieken via Chart.js. De frontend maakt dus niet rechtstreeks verbinding met de databank, maar vraagt data op via zelfgemaakte API-routes.

In Express maakte ik verschillende routes en API-endpoints aan. Zo kan de applicatie bijvoorbeeld een lijst met gemeenten ophalen, de grens van een geselecteerde gemeente tonen, ongevallenpunten binnen die gemeente opvragen en statistieken berekenen voor KPI’s en grafieken.

/api/gemeenten
/api/gemeente/:naam
/api/ongevallen/:gemeente
/api/statistieken/trends/:gemeente

Elke API-route heeft een duidelijke taak. Sommige routes geven GeoJSON terug voor de kaart, andere routes leveren samengevatte cijfers voor de dashboardkaarten of datasets voor grafieken. Daardoor blijft de applicatie overzichtelijker: de database doet het zware rekenwerk met SQL en PostGIS, terwijl Node.js de resultaten netjes doorgeeft aan de frontend.

Over het maken van API’s schreef ik eerder al een apart artikel op mijn blog: API’s maken en ernaar connecteren . In dit dashboard paste ik hetzelfde principe toe: je maakt gestructureerde eindpunten waar je frontend veilig en voorspelbaar data kan ophalen.

Ik moet daar ook eerlijk in zijn: bij het ontwikkelen van deze demo heb ik veel hulp gehad van AI. Zonder AI zou het veel langer geduurd hebben om alle nodige code voor zo’n applicatie volledig uit te schrijven. Data manipuleren, uitzoeken welke gegevens waar zitten, bepalen welke tabellen en velden met elkaar gecombineerd moeten worden, SQL-query’s testen, JavaScript aanpassen, HTML finetunen en de applicatie stap voor stap verbeteren: dat doe ik graag. Maar de volledige Node.js-app helemaal vanaf nul uitschrijven zonder AI? Nee, dan had ik deze demo waarschijnlijk niet op deze manier kunnen maken.

Voor mij toont dit net de kracht van AI in zo’n ontwikkelproces. AI neemt het denkwerk niet volledig over, maar helpt wel om sneller codevoorstellen te maken, fouten op te sporen, routes op te bouwen, API’s te structureren en bestaande code te verbeteren. Daardoor kan je productiever werken en sneller van een idee naar een werkende demo gaan.

Omdat de demo online moest draaien, had de Node.js-app ook online toegang nodig tot de databank. Een lokale PostgreSQL-databank is handig tijdens ontwikkeling, maar niet geschikt voor een publieke online demo.

En aangezien het om een hobbyproject gaat, wou ik ook niet meteen een betalende databankoplossing gebruiken. Ik zocht naar gratis of betaalbare PostgreSQL-services en kwam uiteindelijk uit bij Neon, een online PostgreSQL-platform waarmee je snel een PostgreSQL-databank beschikbaar maakt voor een gehoste webapplicatie. Bij Neon zit je data in een cloudomgeving bij AWS.

Omdat mijn data geometrieën bevat, activeerde ik ook in Neon PostGIS:

CREATE EXTENSION IF NOT EXISTS postgis;

Daarna maakte ik een dump van mijn lokale databank. Op Windows kan dat bijvoorbeeld via PowerShell.

& "C:\Program Files\PostgreSQL\18\bin\pg_dump.exe" `
-h localhost `
-p 5432 `
-U postgres `
-d verkeersongevallen `
-F c `
-f "$env:XXXXX\verkeersongevallen.dump"

Ik zette de lokale dump online in Neon met pg_restore. Voor het importeren gebruikte ik de directe Neon-connection string.

& "C:\Program Files\PostgreSQL\18\bin\pg_restore.exe" `
-v `
-O `
--no-privileges `
--no-tablespaces `
-d "postgresql://neondb_username:WACHTWOORD@ep-xxxx.eu-central-1.aws.neon.tech/neondb?sslmode=require" `
"$env:USERPROFILE\Documents\verkeersongevallen.dump"

De opties -O, --no-privileges en --no-tablespaces vermijden dat lokale gebruikers, rechten of tablespaces letterlijk moeten bestaan in Neon.

Voor de import gebruikte ik de directe host. Voor de Node.js-app zelf is de pooled host nuttig, omdat een webapplicatie vaak veel korte connecties maakt.

Toen de databank online stond, kon de Node.js-app verbinden met Neon via een environment variable (.env).

DATABASE_URL=postgresql://neondb_username:WACHTWOORD@ep-xxxx-pooler.eu-central-1.aws.neon.tech/neondb?sslmode=require

De app gebruikt API-routes om data op te halen voor de kaart, filters, KPI’s en grafieken. De frontend maakt dus geen rechtstreekse verbinding met de databank.

De laatste stap was het online plaatsen van de Node.js-app. Het resultaat is een online dashboard hier op mijn blog waarin gebruikers per gemeente verkeersongevallen kunnen bekijken, filteren en analyseren.