Weather Provider API

Waarom is deze Weather Provider API ontwikkeld? Omdat het verkrijgen van benodigde meteorologische kennis de sleutel is tot het beheersen van de gevolgen van wat het weer op ons functioneren kan hebben. Daarom is het erg belangrijk om deze meteorologische informatie makkelijk(er) toegankelijk te houden.

Helaas blijkt toegankelijkheid van nature nogal een probleem. Er is een heleboel informatie beschikbaar en lang niet alles heeft eenzelfde uitvoerformaat. Zelfs een enkel instituut kan vaak meerdere uitvoerformaten hebben, met andere namen, voor dezelfde inhoud. Sommigen zijn direct benaderbaar vanuit een URL, terwijl anderen een complete API met autorisatieregels vereisen. Sommigen gebruiken een gestandaardiseerd GRIB-bestandsformaat, terwijl anderen weer een eigen NetCDF-indeling hanteren. Andere informatie zou zelfs kunnen bestaan uit een CSV-bestand of een tabel op een webpagina.

En áls je dan eenmaal al deze informatie bij elkaar gekregen hebt, zal je waarschijnlijk alsnog alles moeten formatteren en vertalen om uit te komen bij iets wat je kunt gebruiken. Dat is een heleboel tijd en moeite die je nodig hebt, nog voordat je gestart bent.

Het doel van de Weather Provider API is om één enkele vaststaande vorm van toegang te bieden voor een grote hoeveelheid aan datasets, met als output een gestandaardiseerd formaat in het bestandsformaat en het eenhedenstelsel dat je nodig hebt.

Dit betekent minder tijd en minder moeite om de informatie te krijgen die je nodig hebt. Daardoor houd je meer tijd over om bij de resultaten te komen die je wil. En als wij hiervan profiteren, waarom dan niet andere mensen ook?

Zoals de naam al suggereert, is de Weather Provider API een API. Dat wil zeggen dat je niet meer nodig hebt dan een simpel HTTP-verzoek om alle informatie die je van een bron wenst te krijgen in het formaat dat jij wil. Ongeacht aan wat voor programmeertaal of -systeem je  voor een project gebonden bent.

De Weather Provider API heeft een aantal modellen geïmplementeerd. Op dit moment zijn dat de volgende:

• KNMI Historische data per dag / uur
  Aan te roepen met ‘daggegevens’ en ‘uurgegevens’
• KNMI Voorspellende data (14 dagen voorspelling, per 6-uurs blok)
  Aan te roepen met ‘pluim’
• KNMI Voorspellende data (48 uurs voorspelling, per uur)
  Aan te roepen met ‘arome’
• KNMI Actuele weerdata
  Aan te roepen met ‘waarnemingen’
• CDS (Climate Data Store) ERA5 uurgegevens van 1979 tot nu – Single Levels
  Aan te roepen met ‘era5sl’

Voor meer informatie over deze modellen verwijzen we naar het README.md document in het project zelf.

Om de API correct aan te roepen, zijn de volgende parameters van toepassing:

• source_id: De code voor de bron behorende bij het model waar data voor opgevraagd moeten worden. Momenteel is dit ofwel het KNMI (‘knmi’) of het CDS (‘cds’).
• model_id:  De code voor het model waar data voor opgevraagd moeten worden.
  Kijk voor de huidige ondersteunde modellen naar de lijst hierboven.
• begin: Een datum-tijd combinatie, die het begin aangeeft voor de tijdsreeks waarvan je informatie wil opvragen.
• end: Een datum-tijd combinatie die het einde aan geeft voor de tijdsreeks waarvan je informatie wil opvragen.
• lat: EenWGS84 latitudewaarde behorende bij de locatie waar je data voor wil opvragen.
  Dit veld kan ook Rijksdriehoekcoördinaat x-componenten verwerken, vooropgesteld dat het lon-veld ook gevuld is met een Rijksdriehoekcoördinaat y-component.
• lon: EenWGS84 latitudewaarde behorende bij de locatie waar je data voor wilt opvragen.
  Dit veld kan ook Rijksdriehoekcoördinaat y-componenten verwerken, vooropgesteld dat het lat-veld ook gevuld is met een Rijksdriehoekcoördinaat x-component.
• weather_factors: Een optioneel veld, waarmee een lijst kan worden opgegeven met daarin de aspecten van het weer die je wilt opvragen voor het gekozen model. Dit kan gevuld worden met de eigen namen van het betreffende model zelf, mits van toepassing, of de gestandaardiseerde namen van de Weather Provider API. Mocht dit veld leeg worden gelaten, dan zal de Weather Provider API de volle dataset opleveren zoals deze is geïmplementeerd.
• units: Een waarde die aangeeft met wat voor eenhedenstelsel de uitvoer moet worden opgeleverd. ‘si’ (wetenschappelijke notatie), ‘human’ (menselijk leesbare notatie) en ‘original’ (de originele notatie) worden ondersteund.
• response_format: Een waarde die aangeeft welk bestandsformaat te gebruiken voor de uitvoer. Ondersteund worden: NetCDF4, NetCDF3, JSON, JSON dataset en CSV
• accept: Een zelden gebruikt optioneel veld, dat kan worden gevuld met specialistische instellingen die van toepassing kunnen zijn op bepaalde modellen.