Helaas kan ik op het ogenblik de methode waar Teus naar refereert (mijn presentatie in Amersfoort en het verslag in het LV2 voortgangsrapport van januari 2023) niet meer werkend krijgen. Het aflezen van de samenmeten.rivm website ging met een vb.net console applicatie ( te openen in Visual Studio 2019 - software die de ontwikkelaar had, maar ik niet).
Het systeem werkte met een toegang tot een bepaalde versie van de samenmeten.rivm website - en ik vermoed dat die website een upgrade heeft gehad met een nieuw versie nummer. Deze toegang is daarmee - althans voor mij - gesloten. Als iemand in deze software wil duiken - geef maar een seintje.
Blijft de vraag hoeveel missing data de RIVM API oplevert. Enerzijds zal de computing capaciteit bij RIVM zijn toegenomen, anderzijds is ook het aantal meetstations toegenomen. In elk geval zal de interne kalibratie van RIVM stations om 2 uur 's nachts blijven bestaan, met uitval van de metingen op dat tijdstip op bepaalde dagen tot gevolg. Heel hinderlijk dat dan zowel de gekalibreerde als de ongekalibreerde data uitvallen. Als alleen de gekalibreerde data niet aanwezig zijn is met een interpolatie van de kalibratie funktie de waarde van een missing data point nog wel te achterhalen. Anders moeten we een nieuwe list verzinnen.
Frans Kets
Interpolatie van missende gekalibreerde waardes met kalibratie factor van vorige meting met kalibratie gegevens.
Vooral in het jaar 2022 missen er nogal een aantal gekalibreerde PM2.5 waardes.
Wanneer er geen gekalibreerde waarde is, maar wel een niet-gekalibreerde waarde, wordt de gekalibreerde waarde geïnterpoleerd met de vorige kalibratie-factor.
De RIVM API (het is in wezen een soort website query ge-ent op OCG Things ‘standaard’, een soort van familie van website query interfaces) is wat traag maar werkt best. Ik merkte dat de low-cost meetstations benaming in Things vrij structureel van aard is: XYZ_naam. Waarbij XYZ een soort verwijzing is naar type station, bijv OHN voor een Ohnics station. Station XYZ heeft een ‘vast’ aantal sensoren die gegevens uploaden in een periode, soms uit periode in het ver verleden. Wil je gegevens tav een regio bijv gemeente Groningen (met > 100 stations met ieder meer dan 4 sensoren) analyseren betekent dit een langdurige en frequent acces (meer dan 100X4) op de Things website van Samen Meten met mogelijk maar een succes van enkele 10-tallen website accessen. Vraag: is er duidelijkheid waar XYZ voor staat zodat bijv stations met Palmesbuisjes uitslagen uitgesloten kunnen worden?
De Things query maakt gebruik van selectie criteria in bijv Things (stations, ed) en apart Observations. Dat betekent bijv minimaal 2 queries. Vraag weet iemand hoe dit in een qeury te combineren? Dit halveert de acces wacht tijd bijv.
Vraag: meetwaarden worden opgestuurd met een timestamp. Wordt dat in de onderliggende database ook verwerkt zodat gemiste meetdata aangevuld kan worden? Cq bijv aangevulde meetwaarden die naar Sensors.community zijn opgestuurd ook via de lijn community-RIVM in de database belanden?
Samen Meten Tools
Geïnspireerd door Zuinige Rijder zijn Samen Meten RIVM toolset en het data analyse werk met Python (Pandas, statistiek modules, plot modules, etc. etc) heb ik een Python (V3.8+) basis module: het ophalen van gegevens (meta informaties low-cost stations, zg sensor observaties van een station over een periode via RIVM Samen Meten Things API (een website query interface), extra gegevens zoals locatie adres, omzetten van gemeentenaam naar gemeente code mbv Open Street Map, Open Data Soft, etc. geschreven. De module is voorzien van ca 50% aan documentatie en kan stand alone aangeroepen worden om inzicht te krijgen wat een routine zoal doet en hoe hij aangeroepen kan worden.
De meta informatie wordt in een Python dict (simpel naar json of CSV om te zetten) samengevat. De observaties worden naar een Pandas dataframe geschreven. Een goede basis om daarna data analyse mee te doen. Of gegevens op te slaan in een database of CSV bestand.
Omdat website queries nogal wat tijd kost (soms 15-30 seconden) en het aantal queries groot kan zijn, bijv een request voor alle Luftdaten meetstations in een regio met 4-6 sensoren en beschikbare meetgegevens in een bepaalde periode, is voorzien om dat parallel (multithreading) te laten uitvoeren. Dit geeft een factor 2-5 versnelling.
De module is momenteel in alpha test fase. Opmerkingen, verbeteringen en aanvullingen zijn welkom (!), vooral tav gewenste functionaliteit. De module geeft overigens een aardig inzicht hoe de Things query interface werkt. Cq geeft antwoord hoe bepaalde gegevens (lees: verouderde metingen) uitgesloten kunnen worden. Of misschien wel iets verbeterd kan worden.
