1 RGI-189 Sensoren als databronnen aan de geo-informatie infrastructuur WP6: SWE in meteorologische waarnemingssystemen Wiel Wauben, R&D informatie- e...
RGI-189 Sensoren als databronnen aan de geo-informatie infrastructuur WP6: SWE in meteorologische waarnemingssystemen Wiel Wauben, R&D informatie- en waarneeminfrastructuur, KNMI
Doelstelling In de operationele meteorologie wordt gebruik gemaakt van netwerken van sensoren waarvan de gegevens tijdig en continue beschikbaar moeten zijn. Behalve sensor data is ook meta-informatie van cruciaal belang voor de gebruikers omdat de gegevens (inter)nationaal worden uitgewisseld en sensoren, meetopstellingen en bewerkingen van meetgegevens per instituut/land verschillen. In dit werkpakket is nagegaan of Sensor WebEnablement (SWE) geschikt is voor gebruik in de operationele meteorologie. Om bovengenoemde aspecten te kunnen nagaan zal sensorinformatie van enkele bestaande KNMI sensoren voor neerslagmetingen middels SWE beschikbaar worden gemaakt. Tevens zal informatie van andere sensoren van derden worden verwerkt om te kunnen toetsen of de relevante sensor eigenschappen en omgevingscondities beschikbaar zijn zodat de gegevens correct kunnen worden geïnterpreteerd. Aangezien neerslag ruimtelijk en temporeel sterk varieert is aanvullende informatie nuttig, maar de kwaliteit van de data is van essentieel belang. Een belangrijk aspect is daarom ook de mogelijkheid van het monitoren van de kwaliteit/status van de SWE sensor.
Achtergrond In de meteorologie is uitwisseling van meetgegevens cruciaal aangezien het weer zich niet aan landgrenzen houdt. De internationale uitwisseling van meteorologische gegevens wordt gecoördineerd door de Wereld Meteorologische Organisatie (WMO). De uitwisseling geschiedde tot voor kort in alfanumerieke meteorologische codes t.b.v. algemene meteorologie, klimatologie etc. Dit zijn typisch uurlijkse berichten, maar vaak ook 3 of 6 uurlijks en betreft landstations, schepen, platforms, radiosonde profielen en luchtvaartberichten onder auspiciën van de International Civil Aviation Organisation (ICAO). De verschillende alfanumerieke meteorologische codes zijn star, ze gebruiken codetabellen die in WMO documenten zijn beschreven en bevatten nauwelijks meta-informatie (meestal enkel de stations aanduiding en enkele indicatoren voor menselijke of automatische waarnemingen). Momenteel vindt een overgang plaats naar een binair formaat (zgn. BUFR) dat meer flexibel is en meta-informatie toelaat. Naast de meteorologische meetgegevens wordt modeloutput in GRIB formaat verspreid. Op Europees niveau vindt tevens uitwisseling van neerslagradar beelden en windprofiler data in HDF formaat plaats. Daarnaast zijn ook gegevens van meteorologische satellieten, die via een downlink van de satelliet kunnen worden ontvangen, essentieel voor de meteorologie. Uitwisseling van meteorologische onderzoeksgegevens geschiedt tegenwoordig vaak in het NETCDF formaat. De meteorologische berichten en modelverwachtingen worden via het wereldwijde Global Telecommunication System (GTS) uitgewisseld. De ruimtelijke informatie van neerslagradar en windprofiler en satelliet alsmede onderzoeksgegevens worden tegenwoordig vaak toegankelijk gemaakt via internet en webservices.
METNET Bliksem, Neerslagradar, Satelliet
digitaal analoog
RWS
MSS
GTS MET rapporten
KMDS
Internet
AWS
Vliegveld Vliegbasis
FTP server Intranet Applicaties Gebruikers
andere bronnen
Serieel RS 422 Locatie code, SIAM type/formaat
Figuur 1. Een schematisch overzicht van het automatische meteorologische netwerk van het KNMI. Sensorinformatie wordt via een SIAM sensor interface aangeboden aan Noordzee/kust stations van RijksWaterStaat (RWS), Automatische WaarneemStations (AWS), burgervliegvelden en vliegbasis van de Koninklijke Luchtmacht en Marine. De meetgegevens worden ontsloten als meteorologische berichten via de Message Switch (MSS) en via exports van data uit de centrale KMDS database. De blauwe kaders geven de componenten aan waar SWE een rol kan spelen. Merk op dat via SWE “eenvoudig” sensorinformatie van derden kan worden verkregen en dat SWE niet alleen voor het verkrijgen/ontsluiten van data van individuele sensoren kan worden gebruikt maar tevens voor sensornetwerken.
Meteorologische sensoren hebben geen standaard interface. Sensoren maken vaak nog gebruik van een analoge output maar tegenwoordig zijn sensoren meestal serieel/digitaal (RS 485) en in enkele gevallen beschikken ze over een webinterface. Tot nu toe moet veel inspanning worden verricht in hardware en software oplossingen voor de data-acquisitie systemen en verwerking van de waarnemingen. Door het gebrek aan standaard oplossingen heeft het KNMI jaren geleden besloten om een eigen sensor interface te maken die de meetgegevens van sensoren omzet in een vast serieel formaat. Hierdoor kunnen de meetgegevens eenvoudig via een COM poort van een computer worden aangeboden. De KNMI sensor interface (SIAM) heeft zich in de praktijk bewezen, maar er zijn beperkingen zoals, het starre formaat dat enkel geschikt is voor een beperkte set van grootheden, de interface werkt asynchroon en kan niet op afstand actief worden benaderd of ge-upgrade, de meta- informatie is beperkt en niet zelfbeschrijvend, het gebruik van seriële verbindingen is ouderwets en storingsgevoelig, de oplossing is KNMI specifiek dus moet voor/door het KNMI worden ontwikkeld en onderhouden en sluit niet aan bij (inter)nationale standaarden. In dit opzicht kan SWE een rol spelen als mogelijke toekomstige vervanger van de KNMI sensorinterface. Daarnaast kan SWE ook gebruikt worden voor de ontsluiting / acquisitie van sensorinformatie van derden. Ook voor het intern toegankelijk maken van sensorinformatie
kan SWE worden gebruikt. In figuur 1 is een schematisch overzicht gegeven van het meteorologische meetnet en de componenten waar SWE een rol kan vervullen.
Setup Voor de test van de geschiktheid van SWE in de meteorologie zijn een aantal meteorologische parameters Web-Enabled (WE) (zie tabel 1). Voor dat doel zijn 10-minuut meteorologische gegevens uit de centrale KMDS database van het KNMI gebruikt die van belang zijn voor neerslag en verdamping (zie Appendix A). Tabel 1. De web-enabled variabelen en hun KMDS benaming.
Variable dr rg pr pg ta rh qg dd
Description precipitation duration rain gauge precipitation intensity rain gauge precipitation duration PWS precipitation intensity PWS air temperature (1.5m) relative humidity (1.5m) global solar radiation wind direction
ff
wind speed (at 10m height)
Unit sec mm/h sec mm/h °C % W/m² ° w.r.t. true North (90=East etc, direction where wind is coming from) m/s
De gegevens zijn elke 10-minuten beschikbaar met een vertraging van enkele minuten. De gegevens van hh:mm (de tijd in UT) zijn de gemiddelden/sommen van het tijdsinterval eindigend op hh:mm. De gegevens bevatten tevens een kwaliteitvlag. Voor de WE zijn enkel de klassen OK, Warning, Errror gebruikt. Bovengenoemde gegevens zijn beschikbaar voor bijna alle automatische waarneemstations van het KNMI. De gegevens van het KNMI zijn conform de wet op het KNM niet vrij beschikbaar. Voor deze test is daarom enkel gebruik gemaakt van de zgn. WMO essentiële stations, die vrijelijk verstrekt mogen worden, en een vijftal station rondom Gendt, de locatie van het veldexperiment. De gegevens van de WMO essentiële stations en de locaties rondom Gendt zijn vermeld in tabel 2. De data is enkel toegankelijk voor een lijst vaste IP adressen van partners uit het project. Tabel 2. De KNMI stations die beschikbaar zijn gemaakt via SWE.
WMO number 06235 06239 06240 06251 06260 06269 06270 06280 06290 06310 06344 06370 06380 WMO number 06275 06356
WMO essential stations Name Latitude De Kooy 52°55'N F-3 54°51'N Amsterdam/Schiphol 52°18'N Hoorn/Terschelling 53°23'N De Bilt 52°06'N Lelystad 52°27'N Leeuwarden 53°13'N Groningen 53°08'N Twenthe 52°16'N Vlissingen 51°27'N Rotterdam 51°57'N Eindhoven 51°27'N Maastricht 50°55'N stations around Gendt Name Latitude Deelen 52°04'N Herwijnen 51°52'N
De WE is verricht met software die is aangeleverd door IFGI, die als subcontractor van TNO B&O aan dit project deelnam. De software is door IFGI ontwikkeld in het 52North consortium en kon met enkele kleine wijzigingen gebruikt worden. De software is tot nu toe enkel gebruikt in een Windows omgeving. Om geen tijd te verliezen bij het porten naar een Linux omgeving is besloten om de WE uit te voeren op een Windows server. De centrale KMDS database draait in een operationele omgeving. Om eventuele verstoring te voorkomen is de WE software niet direct gekoppeld aan de KMDS database, maar vind er eerst een export van de gegevens plaats naar ASCII bestanden die beschikbaar worden gemaakt op de externe FTP server van het KNMI. Dit sluit aan bij de operationele levering van 10-minuut meetgegevens aan derden, zonder dat toegang tot het interne KNMI netwerk vereist is. De ASCII bestanden op de FTP server worden elke 10-minuten door een zgn. Feeder ingelezen en in de database van de KNMI SWE server gezet. Initieel was het de bedoeling dat de KNMI SWE server buiten het KNMI netwerk zou worden geplaatst zodat het beter toegankelijk voor derden zou zijn en niet tot storingen aan het KNMI netwerk zou kunnen leiden. Tijdens de realisatie bleek echter dat het KNMI netwerkveiligheidsbeleid het niet meer toestaat Windows servers buiten het KNMI netwerk te plaatsen. Uiteindelijk is besloten de SWE server binnen het KNMI netwerk te plaatsen en alleen de 8080 poort die gebruikt wordt door het SWE protocol open te zetten voor een aantal vaste IP adressen van systemen die voor dit project gebruikt worden door partners. Figuur 2 geeft een schets van de SWE setup.
Intern
Extern Windows server
KMDS
FTP server
Feeder
Post gres
SOS
Internet
Tomcat Java
Figuur 2. Een schematisch overzicht van de gebruikte setup voor de webenablement van de KNMI gegevens.
SWE-SOS protocol Middels een TCP/IP http connectie met de SWE server kan de database met sensorgegevens worden geraadpleegd via vragen en antwoorden in XML. Het protocol dat hiervoor gebruikt wordt, is het Sensor Observation Service (SOS). Hierbij wordt gebruik gemaakt van Sensor Model Language (SensorML) en Observations and Measurements (O&M) om respectievelijk meta en sensor data te verstrekken. Als het IP adres en poort van de SWE server bekend is (merk op dat dit ook een individuele sensor zou kunnen zijn die aan het netwerk is aangesloten en het SWE protocol ondersteund) dient eerst een GetCapabilities query te worden verricht die informatie geeft over de SOS service alsmede de globale beschrijving de beschikbare informatie (tijdinterval, geografisch gebied). Tevens
wordt een overzicht van de zgn. sensoren (in dit geval de waarneemstations) en phenomenon (in dit geval de meteorologische grootheden). Met DescribeSensor kan meta data van het station worden opgevraagd. Vervolgens kan bijv. GetObservation worden gebruikt om de gewenste grootheden van enkele stations voor een bepaald tijdsinterval op te vragen. De XML voorbeelden van de queries en replies van bovengeschetste typische handelswijze zijn opgenomen in appendix B. De SWE queries kunnen in de testClient handmatig worden ingevoerd om vervolgens naar de SWE server te kunnen worden verzonden. De capabilities kunnen ook met een “oneliner” worden opgevraagd. De XML vragen en antwoorden van SWE zijn in principe leesbaar, maar niet geschikt voor een evaluatie van SWE door gebruikers. Hiervoor zijn applicaties nodig die gebruikers in staat stellen om op een gebruikersvriendelijke manier met de SWE server te communiceren. In het 52N consortium is een viewer beschikbaar, maar deze werkt niet naar tevredenheid. De KNMI evaluatie heeft daarom niet bij de gebruiker/beheerder plaatsgevonden en is tevens beperkt tot het SOS protocol waarvan in eind 2007 versie 1.0 beschikbaar was. Het dient te worden opgemerkt dat de Sensor Planning Service (SPS), Sensor Alert Service (SAS) en Web Notification Service (WNS) ook relevant zijn voor het KNMI, maar officiële software releases deze services zijn/waren nog niet beschikbaar.
Eisen Uiteraard worden inhoudelijke nauwkeurigheidseisen gesteld aan de waarnemingen ten behoeve van meteorologie (WMO No.6, KNMI Handboek Waarnemingen, ICAO annex 3). Deze nauwkeurigheidseisen komen tot uiting in sensorspecificaties, opstellingseisen en onderhoudstermijnen. Behalve deze inhoudelijke eisen moeten de waarnemingen ook voldoen aan eisen betreffende de tijdigheid, beschikbaarheid en aanwezigheid van metainformatie. Tijdigheid is vooral van belang in toepassingen voor bij de luchtvaart waar onder specifieke omstandigheden de sensorgegevens elke 12 seconden aan de klant geleverd wordt en in mindere mate voor algemene meteorologie waarin het KNMI sensorgegevens elke 10 minuten worden ververst. Ook de beschikbaarheid verschilt per toepassingsgebied. De cruciale sensoren/systeem voor de luchtvaart moeten 99.97% van de tijd beschikbaar zijn, terwijl voor algemene meteorologie een beschikbaarheid van 98% wordt geëist. Merk tevens op dat voor luchtvaart dit enkel geldt voor actuele gegevens aangezien enkel deze van belang zijn voor de luchtvaartoperaties, terwijl voor klimatologie dit ook geldt voor historische gegevens, d.w.z. voor klimatologie is lokale buffering om recovery van gegevens na storingen mogelijk te maken gewenst. Meta-informatie over de sensor en meetopstelling zijn essentieel voor gebruikers. Ook hier is weer een verschil per gebruikersgroep. Voor luchtvaart moet de meting representatief zijn voor de luchthaven of de touchdown positie van de gebruikte baan. De opstellingeisen zijn zodanig dat zo dicht mogelijk bij de vaak verstoorde locatie wordt gemeten en dat sensoren relatief vaak worden verplaatst naar aanleiding van wijzigingen aan de luchthaven. Echter, voor klimatologie moeten de metingen zo min mogelijk verstoord worden door omgevingsfactoren en tevens moet de locatie zoveel mogelijk gehandhaafd blijven om de klimatologische reeksen homogeen te houden. Merk op dat meta-informatie zoals bijv. welke sensor gebruikt wordt, de locatie alsmede de omgeving (bebouwing, begroeiing) veranderen in de tijd.
Evaluatie Hieronder volgt een opsomming van de ervaringen opgedaan het de SWE-SOS, -SensorML en -O&M protocollen alsmede de beschikbare software.
De SWE-SOS applicatie draait op een Windows platform dat door het KNMI niet extern mag worden gebuikt. De server staat daarom binnen het KNMI netwerk, maar poort 8080 is extern toegankelijk gemaakt voor enkele vaste IP adressen van partners in het RGI project. Via dezelfde poort is toegang mogelijk tot TOMCAT waarmee de
configuratie kan worden aangepast. Uiteraard is toegang afgeschermd met een gebruikersnaam/ wachtwoord, maar dit voldoet niet aan de veiligheidseisen van het KNMI. Daarbij komt dat de gegevensuitwisseling niet secure is.
De SWE server heeft sinds de installatie medio augustus 2007 stabiel gedraaid. De SOS applicatie is wel enkele keren herstart en tevens is de server een keer helemaal herstart omdat de SOS applicatie niet meer beschikbaar was of de Feeder niet meer werkte. De reden hiervoor is onduidelijk. Één keer viel het onderuitgaan van de SOS applicatie samen met een test van een applicatie van een partner. De oorzaak was echter niet reproduceerbaar. Soms was ook een grote query afdoende om de SOS applicatie te laten vastlopen. In alle genoemde gevallen was de server “onbeschadigd” en kon de SWE-SOS datastroom worden hersteld via een herstart op afstand. Merk op dat remote toegang tot de SWE server tevens van belang is om desgewenst de configuratie en de software remote te kunnen wijzigen.
Het SWE-SOS protocol hanteert het XML formaat. Gebruikers - en configuratie tools ontbreken waardoor het niet mogelijk was om de eindgebruikers en beheerders een evaluatie uit te voeren. De gebruikers zouden dan XML moeten lezen en configuratieveranderingen vergen nu meestal handmatig aanpassingen van XML bestanden of door de software (java) aan te passen. Eventuele wijzigingen moeten nu dus door applicatiebeheer geschieden en niet zoals gewenst door functioneel beheer. Public domain gebruikers- en configuratie tools zijn noodzakelijk om de gegevens van het SWE-SOS protocol op een gebruikersvriendelijke manier te ontsluiten. Het ontwikkelen van de benodigde tools valt echter buiten de KNMI scope van dit project.
De XML berichten van het SWE-SOS protocol zijn vrij omvangrijk (zie appendix B) zeker in vergelijking met de omvang van de eigenlijke sensorgegevens. Normaal gesproken is dit voor de huidige communicatiemiddelen geen probleem, maar voor low-power opstellingen kan dit toch van belang zijn. Hetzelfde geldt voor actuele datastromen met een hoge tijdsresolutie. Daarbij komt dat er geen SOS query bestaat die automatisch de meest actuele data stuurt. Daarom moet gebruik worden gemaakt van een veronderstelde delay en/of een capabilities request om het tijdstempel van de meest actuele data op te vragen. Dit opvraagmechanisme verhoogt de benodigde lijncapaciteit en vertraagd de beschikbaarheid van de meest actuele data. Mogelijk kan in de toekomst het SAS protocol voor het verkrijgen van de actuele gegevens worden gebruikt.
SOS requests kunnen het systeem vertragen. Dit geldt met name voor data request die te veel gegevens opvragen. Er is geen begrenzing op de hoeveelheid op te vragen gegevens, maar als de hoeveelheid meer is dan de SOS buffergrootte dan geeft het systeem na enige tijd een foutmelding. Ondertussen kunnen andere requests worden geblokkeerd en soms loopt op deze manier de SWE-SOS applicatie vast waardoor een herstart noodzakelijk is.
Aangezien enkel het SWE-SOS protocol beschikbaar was, was het niet mogelijk de functionaliteit betreffende de alarmeringen (events waarbij de sensor automatisch een bericht stuurt) middels SPS en SAS en het configureren van de sensor te toetsen. Hierdoor kon ook geen inzicht worden verkregen in de beschikbaarheid/continuïteit van de sensordata bij gelijktijdig gebruik van deze pull en push protocollen door verschillende gebruikersgroepen.
SensorML staat toe meta-informatie op een flexibele manier op te nemen. Dit kan meestal in de vorm van vrije tekst waardoor het gevaar bestaat dat verschillende gebruikers andere manieren hanteren. Hierdoor wordt het lastig om deze informatie
eenduidig laat staan automatisch te processen. Nadere afstemming tussen de gebruikers is hier van belang. Binnen de meteorologische wereld zijn al enkele aanzetten gemaakt voor standaardisatie op het gebied van meta-informatie gegeven, maar deze zijn met name op het gebied van data sets en niet op sensor niveau. Er zijn wel richtlijnen voor de sensorgegevens en opstellingseisen, maar vaak zijn er verschillen in bijvoorbeeld meet/sample frequentie, middelingintervallen en bewaartijden. Op dit moment kan niet getest worden in hoeverre SPS voor dit doel gebruikt kan worden. Onderhouds- en nauwkeurigheids informatie van metingen is zelden on-line beschikbaar.
SensorML is vooral opgezet voor het beschrijven van en gebruik voor een enkele sensor. In deze evaluatie is hiervan gebruikt gemaakt en enkel de mogelijkheid toegevoegd om de sensoren van een waarneemlocatie op verschillende hoogtes en/of fysieke locaties te kunnen beschrijven. Dit is bijv. van belang om windmetingen met een mast buiten het waarneemveld te kunnen beschrijven. Indien de SWE-SOS gebruikt wordt voor het ontsluiten van meetgegevens van een heel netwerk is veel metainformatie gelijk, waardoor een query veel redundante informatie kan bevatten. Dit komt omdat zowel station- en sensorinformatie in het betreffende XML bestand zijn opgenomen. In de getest baseline versie is bijvoorbeeld de identieke sensorinformatie per station met copy/paste ingevoerd voor elke locatie afzonderlijk. In de toekomst kan dit op de achtergrond op een efficiënte/beheerbare manier worden geregeld.
Er ontbreekt een mechanisme om wijzigingen in de meta-informatie kenbaar te maken. Dit kan noodzakelijk zijn omdat in de loop van de tijd de stations configuratie of de sensor wijzigt, maar ook is het van belang om dynamische meta informatie zoals bijv. de datum waarop het laatste onderhoudsbezoek of inspectie heeft plaatsgevonden en de resultaten daarvan. Daarnaast kan uiteraard ook de omgeving sterk veranderen in de loop van de tijd (en soms per seizoen). Behalve het kenbaar maken van zulke wijzigingen, ontbreekt het ook aan middelen om de historie van meta-informatie vast te leggen. Uiteraard kan een gebruiker de meta-informatie altijd opvragen en kan de historie in het betreffende XML bestand worden opgenomen, maar dat maakt het verkrijgen van de juiste meta-informatie nogal bewerkelijk. Merk op dat met deze functionaliteit betreffende historische meta-informatie het SOS protocol ook geschikt zou zijn voor de opslag en ontsluiting van historische meetgegevens.
Het SOS protocol is enkel gebruikt voor sensor data die puntmetingen bevatten. In de meteorologie wordt steeds vaker gebruikt gemaakt van sensoren die 1D of meerdimensionale gegevens bevatten. Denk hierbij aan backscatterprofielen van een wolkenhoogtemeter, het deeltjesgrootte/valsnelheid spectrum van een disdrometer of de bewolking gemeten met een scannende pyrometer of wolkenhoogtemeter. Het SOS protocol moet in staat zijn met zulke meerdimensionale gegevens om te kunnen gaan om aan toekomstige behoeftes te kunnen voldoen. Op dit moment is SOS enkel voor tijdseries van puntmetingen geschikt.
Aanbevelingen en conclusies Het SWE-SOS protocol is nog maar gedeeltelijk beschikbaar en is nog niet uitontwikkeld. Daarom is het op dit moment niet geschikt om operationeel gebruikt te worden door het KNMI. SWE heeft wel de potentie om in een KNMI behoefte te voorzien betreffende de standaardisatie van toegang tot en ontsluiting van sensor gegevens. Hiervoor moet SWE wel integreerbaar zijn in de netwerken van WMO en voldoen aan de EU-Inspire richtlijn. De industrie moet SWE adopteren zodat de ontwikkelingen een goed draagvlak en breed toepasbaar zijn. Tevens moet worden gezorgd dat het OGC-SWE protocol en de W3C standaard (SOAP, WSDL, UDDI) naar elkaar toegroeien.
Rondom het SWE protocol moeten hulpmiddelen/applicaties worden ontwikkeld zodat gebruikers en beheerders eenvoudig toegang kunnen krijgen tot de sensorgegevens. Hierbij kan gedacht worden aan webapplicaties of plug-ins voor bijvoorbeeld GIS (Geografic Information Systems) waarmee de beheerder/gebruiker eenvoudig sensoren kan ontdekken, bevragen en gebruiken. De tools moeten uiteindelijk de beheerder in staat stellen om nieuwe sensorlocaties te vinden/creëren alsmede variabelen, afgeleide variabelen te maken, metainformatie ingeven/lezen, status van de sensoren te monitoren en alarmen voor status en waarde te laten generen, tonen tijdseries waarnemingen, dezelfde variabele meerdere stations en andere variabelen, geografisch presentatie met loop in de tijd. Dit alles moet continue kunnen draaien maar ook configureerbaar zijn. Binnen het RGI project en 52N wordt gewerkt aan de ontwikkeling van zulke tools, maar deze zijn nog in ontwikkeling, star (i.e. toegespitst op een specifieke toepassing) en incompleet. De software voor deze tools moet net als de SWE software zelf gebaseerd zijn op open source en platform onafhankelijk zijn. Het beheer van de SWE standaarden en de software moet goed geregeld zijn zodat continuïteit is gewaarborgd. Tot nu toe is weinig aandacht besteed aan de stabiliteit en toegankelijkheid tot sensor(gegevens) van de ontwikkelde SWE services. Voor operationele toepassingen moet de NRT beschikbaarheid van sensorgegevens te allen tijde gewaarborgd kunnen worden. Dit houdt bijvoorbeeld ook in dat de operationele push en de pull mechanismen in grote mate onafhankelijk van elkaar moeten zijn zodat ze elkaar niet kunnen beïnvloeden. Stabiliteit moet derhalve al in een zo vroeg mogelijk stadium in de SWE implementatie worden beschouwd. Security is een cruciaal aspect dat nauwelijks aandacht heeft gekregen binnen SWE. Voor operationele toepassingen zijn authenticatie, autorisatie en accounting van belang. Tevens moet worden gerealiseerd dat de SWE sensor niet enkel toegankelijk moet zijn middels SOS and de andere SWE services, maar dat het tevens mogelijk moet zijn om remote de O&M en Sensor ML configuratie alsmede de SOS software zelf en het zo mogelijk ook de sensorconfiguratie en -software te kunnen onderhouden en upgraden. SWE-SOS services zijn op dit moment maar in beperkte mate aanwezig en de services die er zijn, zijn lastig te vinden. Daarom kan op dit moment nog nauwelijks ervaring worden opgedaan met de ontsluiting/uitwisseling van sensorgegevens van derden. Voor de toekomst van SWE is het van belang dat de beschikbare SWE services in de lucht blijven en vindbaar zijn bijv. via geoloketten. Daarbij is tevens van belang dat ervaringen worden opgedaan in meerdere disciplines zodat de benodigde harmonisatie tussen verschillende domeinen kan plaatsvinden. Kortom, SWE is een veelbelovende ontwikkeling, maar het is nog niet operationeel inzetbaar. Ten eerste omdat de volledige SWE suite die noodzakelijk is voor operationele meteorologische toepassingen nog niet beschikbaar is. Daarnaast heeft SWE zich nog niet kunnen bewijzen wat betreft betrouwbaarheid, stabiliteit, portabiliteit, toegankelijkheid, configureerbaarheid en beheerbaarheid en veiligheid. Een ander, niet onbelangrijk aspect, is het energieverbruik gerelateerd aan SWE. Om SWE voor operationele meteorologische en klimatologische geschikt te maken is het noodzakelijk dat de ontwikkeling gestructureerd wordt aangepakt. De ervaring zoals hierboven vermeld dienen afgestemd te worden met alle stakeholders en moeten vertaald worden in requirements specificaties. Het gebruik van use case analyses kan daarbij behulpzaam zijn. De specificatie (voor zowel SWE services als tooling) kan richting geven aan partners met betrekking tot de gewenste ontwikkelingen. Daarnaast dient aandacht te worden besteed aan de informatie management structuur binnen SWE voor zowel de data
als de metadata. Multidisciplinaire harmonisatie is gewenst en aansluiting moet worden gezocht met de internationale afspraken binnen vakgebieden en ontwikkelingen binnen die gebieden (bijvoorbeeld meerdimensionale data, near real-time data en dynamische sensor meta-informatie). Het KNMI is geïnteresseerd in SWE en wil zomogelijk meewerken aan een gestructureerde aanpak van de verdere ontwikkeling ervan. KNMI realiseert zich echter dat veel essentiële punten moeten worden opgelost voordat SWE operationeel kan worden toegepast.
Referenties Geoloketten (http://www.geoloketten.nl/) HDF5, Hierarchical Data Format (http://hdf.ncsa.uiuc.edu/HDF5/index.html) ICAO, International Civil Aviation Organization, Meteorological Service for International Air Navigation, Annex 3, July 2007. INSPIRE, Infrastructure for Spatial Information in the European Community (http://inspire.jrc.ec.europa.eu/) ISO, International Organization for Standardization, Information and documentation - The Dublin Core metadata element set, 15836:2003. ISO, International Organization for Standardization, Geographic information - Metadata, 19115:2003. KNMI, Handboek Waarnemingen (http://www.knmi.nl/samenw/hawa/) NetCDF, Network Common Data Form (http://www.unidata.ucar.edu/software/netcdf/) OGC, Open Geospatial Consortium (http://www.opengeospatial.org/) RGI, Ruimte voor Geo-Informatie (http://www.rgi.nl/) W3C, World Wide Web Consortium (http://www.w3.org/) WMO, A Guide to the Code From FM 92-IX Ext. GRIB, Technical Report No.17, WMO TDNo. 611, May 1994. WMO, Guide to Meteorological Instruments and Methods of Observation, WMO Publication No. 8, Seventh edition, August 2008 (http://www.wmo.int/pages/prog/www/IMOP/publications/CIMO-Guide/CIMO_Guide7th_Edition-2006.html) WMO, Guide to WMO Table-Driven Code Forms: FM 94 BUFR, January 2002 (http://www.wmo.int/pages/prog/www/WMOCodes/Guides/BUFRCREXPreface_en.html) WMO, Manual on Codes, WMO Publication No. 306, 2005. WMO, Manual on the Global Telecommunication System, WMO Publication No. 386, July 2007. (http://www.wmo.int/pages/prog/www/ois/Operational_Information/ManOnGTS.html) WMO, WMO core profile of the ISO metadata standard, CBS-Ext. (06), Version 1.0, November 2006 (UML/XML presentation of the version 1.0: (http://wis.wmo.int/2006/metadata/WMO%20Core%20Metadata%20Profile%20(October%20 2006)/documentation.htm)
Appendix A: KNMI neerslagwaarnemingen Het KNMI verricht op een drietal manieren neerslagwaarnemingen. Ten eerste wordt de neerslag (intensiteit, som en duur) gemeten op 35 Automatische WaarneemStations (AWS) met de elektrische neerslagmeter van het KNMI (zie figuur 3). Deze stations zijn homogeen verspreid over Nederland en behalve neerslag worden diverse andere meteorologische parameters gemeten. De meetgegevens zijn op 10-minuut basis centraal beschikbaar in De Bilt. Voor het gezamenlijke experiment is enkel Herwijnen, het enige AWS in het waterschap Rivierenland, in overweging genomen. Voor het experiment is Herwijnen niet geschikt vanwege de afwezigheid cq. afstand tot bodem- en oppervlaktewater metingen.
Figuur 3. Een overzicht van de waarneemlocaties van het automatische meteorologische netwerk van het KNMI en haar partners KLu, KM en RWS. De inzet toont de meetopstelling van de elektronische neerslagmeter.
Voor klimatologische doeleinden worden door vrijwilligers dagelijkse neerslagsommen bepaald op ongeveer 325 meetlocaties (zie figuur 4). Met dit netwerk worden de locale verschillen van de neerslagsommen in kaart gebracht. De metingen worden verricht met een handregenmeter die dagelijks om 8UT wordt afgelezen waarna de gegevens telefonisch worden doorgegeven aan het KNMI. Er bevinden zich een 15-tal meetlocaties in het waterschap Rivierenland, echter de handmatige waarnemingen lenen zich niet voor automatische/continue dataverstrekking.
Figuur 4. De handregenmeter en een overzicht van de ca. 325 meetlocaties van het vrijwillige neerslagnetwerk.
Tot slot heeft het KNMI beschikking over 2 neerslagradars die elke 5 minuten een beeld geven van de neerslag verdeling over Nederland. De ruimtelijke resolutie van de neerslagbeelden is 2,5x2,5 km (recentelijk ook 1x1 km). Aangezien de neerslagradar ruimtelijke remote sensing gegevens levert, zijn deze buiten dit sensor project gelaten. Voor het gezamenlijke experiment is de keuze gevallen op het meetveld in Gendt. Het was niet mogelijk (enkel tegen hoge kosten) om een KNMI neerslagmeter op deze locatie te plaatsen aangezien voeding- en signaal voorzieningen niet nabij de meetlocatie aanwezig waren. Daarom is besloten gebruik te maken van de sensoren van de firma Eijkelkamp die langdurig op batterijen kunnen functioneren en de meetgegevens draadloos via SMS kunnen verzenden. Naast neerslag zijn ook andere meteorologische grootheden van belang in de waterhuishouding. Dit zijn o.a. de windsnelheid en –richting (voor de verplaatsing van neerslagsystemen) en in combinatie met globale zonnestraling, luchttemperatuur en relatieve luchtvochtigheid tevens voor de verdamping (volgens verdampingsformule van Makkink).
Figuur 5. De neerslagradar van De Bilt en een voorbeeld van een neerslagradarbeeld met 2,5x2,5 km resolutie.
Appendix B: Voorbeelden SWE-SOS protocol De capabilities van een SWE-SOS service kunnen worden opgevraagd met de “one-liner”: http://swe.knmi.nl:8080/52nSOSv2kmds/sos?REQUEST=GetCapabilities&SERVICE=SOS De queries kunnen ook worden ingevoerd via de zogenaamde testClient: http://swe.knmi.nl:8080/52nSOSv2kmds/testClient.html Hieronder zijn als voorbeelden de queries en responses van GetCapabilities, DescripeSensor en GetObservation opgenomen.
