Zelf een regenradar bouwen met open data van het KNMI en het Kadaster

Buienradar.nl en Regenmelding.nl doen hun werk prima. Toch wilde ik weten of het zelf kon: de radarbeelden van het KNMI over de kaart van het Kadaster, in mijn eigen huisstijl, draaiend op mijn eigen UGREEN NAS. Het antwoord is ja, het is gelukt.

Het doel was tweeledig: een eigen regenradar bouwen, en onderweg meer leren over het bouwen van API’s. En dat samen met AI, in mijn geval Claude en ChatGPT. Belangrijk daarbij is om eerst samen te bepalen welke techniek de juiste is. Voor deze regenradar werd dat HTML en PHP.

Waarom zelf bouwen

Er zijn genoeg regenradars. Alleen wil ik meestal maar één ding weten: gaat het hier het komende uur regenen? Daar heb ik geen cookiemuur, geen reclamebanners en geen app voor nodig die mijn locatie doorgeeft aan partijen waar ik nooit om gevraagd heb.

En eerlijk is eerlijk: het KNMI en het Kadaster zetten hun gegevens gratis online, en dan wil ik wel weten hoe ver je daarmee komt. Ik wilde ook iets extra’s toevoegen: een lichte en donkere modus, en als je toch naar een neerslagradar kijkt, meteen ook de weersverwachting voor de komende vijf dagen. Die komt eveneens uit de data van het KNMI.

Twee bronnen, allebei open

Het KNMI levert de buien

De radarbeelden komen uit de dataset radar_forecast_2.0, laag precipitation_nowcast. Dat is geen kale bestandsdownload maar een WMS-service: je vraagt een plaatje op voor een tijdstip en een gebied, en je krijgt een PNG terug met transparante achtergrond.

Mijn radar haalt er 31 op: een half uur terug en twee uur vooruit, in stappen van vijf minuten. Vooruitkijken kan omdat het KNMI niet alleen meet maar ook rekent, een zogeheten nowcast. Voor het anonieme eindpunt heb je geen sleutel nodig.

Het Kadaster levert de kaart

De achtergrondkaart is de BRT-Achtergrondkaart van het Kadaster, geleverd via PDOK. Die bestaat in meerdere smaken, en daar maak ik dankbaar gebruik van:

1. In de donkere modus de grijze variant, in de browser omgekeerd naar donker.
2. In de lichte modus de standaardvariant met kleur.
3. De plaatsnamen als losse laag bóvenop de radar, zodat Nijmegen leesbaar blijft ook als er een bui overheen trekt.

Het samenvoegen

Alles komt bij elkaar in Leaflet, een kaartbibliotheek van 40 kilobyte. Het werk zit in de volgorde van de lagen:

kaart.createPane('ondergrond').style.zIndex = 190;  // Kadasterkaart
// het radarbeeld komt hier tussenin, op de standaardhoogte
kaart.createPane('labels').style.zIndex = 450;      // plaatsnamen bovenop

De browser praat niet rechtstreeks met het KNMI. Daar zit een klein PHP-bestandje tussen dat het verzoek zelf opbouwt en het antwoord even bewaart. Dat scheelt verkeer, en het voorkomt dat mijn NAS, waar de website draait, een open doorgeefluik wordt en zo overbelast zou kunnen raken.

Waarom het niet meteen werkte

De eerste versie liet keurig een lege kaart zien. Geen buien. De diagnose gaf drie keer hetzelfde antwoord: HTTP 403, verboden toegang.

Valkuil twee: de WMS-standaard laat toe dat je time=* opvraagt om alle tijdstippen in één keer te krijgen. De koppeling van het KNMI antwoordt daarop sinds kort met een foutmelding. Je moet een expliciet bereik meegeven, van tijd A tot tijd B.

Valkuil drie was wel de leukste. De grafiek onderin bleef vlak, ook als er een flinke bui over de geplaatste speld trok. Het KNMI geeft de waarde namelijk niet altijd in millimeters per uur, maar soms als hoeveelheid per tijdstap van vijf minuten. Dat is nogal een verschil, en dan lijkt een hoosbui ineens op motregen.

Drie schermen, drie indelingen

Een radar op een desktop en een radar in je hand zijn niet dezelfde toepassing. Op de bank wil je details, buiten wil je één blik.

1. Desktop: de kaart schermvullend, met zwevende panelen eroverheen. De vijfdaagse verwachting, de tijdbalk met de neerslaggrafiek, de knoppen. Alles wat er is.
2. Tablet: dezelfde indeling, maar de panelen schuiven mee en de tijdbalk kun je wegklappen zodat de kaart nog groter wordt.
3. Smartphone: alleen wat telt. De radar, een knop voor dag- of nachtmodus, de tijd van het beeld, en play en pauze. Het weerpaneel en de tijdbalk zijn weg. Mijn logo staat klein linksonder.

Die telefoonweergave kostte de meeste moeite. Op mijn iPhone bleef er onderin een lelijke band staan. Cache legen hielp niet, opnieuw installeren hielp niet, en vier pogingen tot een oplossing hielpen ook niet. De oorzaak, uiteindelijk gemeten in plaats van beredeneerd: op iOS wordt een element met position: fixed afgeknipt op het zichtbare deel van het scherm en kan het dus niet achter de browserbalk doorlopen. Gewone inhoud in de documentstroom kan dat wel. Dat was het.

Vloeiend laten lopen

De radar levert één beeld per vijf minuten. Speel je die achter elkaar af, dan springt de regen met horten en stoten over het scherm. Laat je de beelden in elkaar overvloeien, dan lost de ene bui op terwijl de andere verschijnt. Ook niet mooi, want je ziet even twee buien half doorzichtig naast elkaar.

Hoe laat je regen bewegen als je maar twaalf beelden per uur hebt?

Het antwoord heet advectiecorrectie, en de weer-apps doen het ook. Je meet per paar beelden welke kant de buien op schuiven en hoe hard, en je schuift ze tijdens de overgang mee. Dat meten gaat via de omtrek van de buien: tel per kolom en per rij hoeveel regen er staat, en zoek de verschuiving waarbij die profielen het best op elkaar liggen. Alle 31 beelden zijn zo binnen een oogwenk doorgerekend, en de regen beweegt in plaats van op te lossen.

De grafiek die naar de kaart kijkt

De balkjes onderin geven de neerslag op de plek van je speld, en die hingen eerst volledig aan die ene losse meting. Ging die mis, dan stond er ‘droog de komende twee uur’ terwijl je op dezelfde pagina een paarse vlek over je huis zag trekken.

Nu leest de pagina de kleur van het radarbeeld af op de plek van de speld, voor alle 31 beelden. Hoe donkerder de kleur, hoe hoger de balk. De grafiek kan dus niet meer tegenspreken wat je ziet. Ga je met de muis over een balk, dan springt de kaart naar dat tijdstip en verschijnt de verwachte hoeveelheid in een ballonnetje.

En dat samen met een AI

Het hele project heb ik gebouwd in gesprek met Claude. Dat ging opvallend goed bij het uitzoeken van het gedrag van de KNMI-service, bij het schrijven van geautomatiseerde tests, en bij het becommentariëren van de code in gewoon Nederlands.

Het ging minder goed zolang er gerédeneerd werd in plaats van geméten. Die zwarte band op mijn iPhone kreeg vier keer een oplossing die klonk alsof hij klopte. Pas toen ik vroeg of hij het écht wilde nakijken, kwam er een testpagina die de werkelijke afmetingen op het scherm uitlas. Toen was het binnen tien minuten opgelost.

Dat is denk ik de bruikbaarste les uit dit project. Vraag om bewijs, niet om een oplossing. En accepteer het als het antwoord ‘dat heb ik niet kunnen testen’ is, want dat is nuttiger dan steeds opnieuw ervaren dat het toch niet is opgelost. Maak ook gebruik van de Chrome-extensie van bijvoorbeeld Claude, zodat die zelf kan ‘zien’ en testen wat er misgaat.

Zelf iets bouwen met deze gegevens?

Beide bronnen zijn gratis en openbaar. Voor het KNMI maak je een account aan op het Data Platform, voor PDOK heb je niets nodig. Vermeld wel netjes je bron: het KNMI vraagt CC BY 4.0, en de kaart is van het Kadaster. De buurlanden worden trouwens niet weergegeven, want die data heeft het Kadaster niet.

De radar zelf vind je op geutjes.com/radar. Hij is te installeren als app op je smartphone of tablet, hij werkt in donkere en lichte modus, en er zit geen enkele tracker in. Precies zoals ik hem wilde hebben.

Bronnen