1208589-000
drs. G.H. van der Kolff dr.ir. G.J. de Boer drs. ing G. Hendriksen ing. J.F. Keppel
Opdrachtgever RWS Water Verkeer en Leefomgeving Project 1208589-000 Pagina's 21 Trefwoorden
Datamanagement,OpenEarth,Informatiehuis Marien,benthos data Samenvatting
De Digitale Delta Use Case Mariene Monitoring (DD-UC-MM) sluit aan bij het eerder uitgevoerde project 1207084:Pilot datamanagement mariene projecten en het (nog lopende)
vervolg hierop 1208604:Beheer mariene projectdata.
De SPA-opdracht voor de Digitale Delta Use Case Mariene Monitoring komt van Informatie Huis Marien en betreft het verder ontwikkelen van een op OpenEarth gebaseerde methode voor beheer en herbruikbaar maken van mariene projectdata.Dit project is uitgevoerd samen met IMARES, terwijl het in een bredere setting wordt uitgevoerd i.s.m.Rijkswaterstaat Water Verkeer en Leefomgeving en Centrale Informatievoorziening (RWS-WVL en -CIV), IMARES en 3TU.
Deltares heeft de noodzakelijke software bij IMARES geïnstalleerd en geconfigureerd. Vanuit IBM (als trekker van het koepelproject Digitale Delta)is er geen actieve bijdrage geweest met betrekking tot de hierboven genoemde punten. Er zijn geen uitspraken geweest over de Deltares software stack, noch heeft een "keuring" van de bruikbaarheid daarvan plaatsgevonden. Referenties Zaaknummer 31086670/Hofman ·an.2014 Versie Datum Status definitief
Inhoud
1 Introductie 3
2 Ontsluiten van IMARES data 5
3 Verslag van uitgevoerde werkzaamheden 13
3.1 Ordenen data en metadata 13
3.2 Standaardisatie 13
3.3 Mappingstabel en tool 13
3.4 Installatie server 14
3.5 Test 15
3.6 Toelichting kenmerken gemeenschappelijke database 16
3.7 Protocol mariene data 16
1 Introductie
Het Informatiehuis Marien (IHM) is een gemeenschappelijk initiatief van de ministeries van Infrastructuur en Milieu (IenM) en Economische Zaken (EZ), met het ministerie van Defensie als lid van de klankbordgroep en leverancier van data, kennis en advies. IHM heeft tot doel alle mariene informatie en onderzoeksgegevens over de Noordzee op één plek toegankelijk te maken voor belangstellenden, overheden en professionals. Hiermee wordt die informatie beter toegankelijk en is deze steeds opnieuw te gebruiken.
IHM participeert in het project de Digitale Delta, waarin Rijkswaterstaat, IBM,
Hoogheemraadschap Delfland, TU Delft en Deltares samen onderzoeken hoe met behulp van betere informatiedeling en slim hergebruik van ICT toepassingen het waterbeheer in Nederland verbeterd kan worden. De Digitale Delta kent een open aanpak: de watersector kan in Use Cases participeren, hun producten en diensten in een proeftuin demonstreren en via een klankbordgroep meedenken over het programma. IHM is trekker van de Use Case Mariene Monitoring. In de Use Case wil IHM zich een beeld vormen van de mogelijke toegevoegde waarde van de Digitale Delta ten opzichte van alternatieve aanpakken, waaronder de OpenEarth software stack die Deltares propageert.
Eind 2012 heeft RWS aan Deltares opdracht verleend voor het onderzoeken van korte en lange termijn oplossingen voor het hergebruik van mariene projectgegevens. De uitgevoerde pilot toonde aan dat OpenEarth technieken succesvol kunnen worden geïntegreerd in de RWS data architectuur. Door het toepassen van een zogenaamde software stack konden de data van het project PMR-NCV bereikbaar worden gemaakt via de data-distributielaag van WaterDataNet. Het eindrapport van de pilot geeft een uitvoerige beschrijving van het systeem dat gebruikers toegang verschaft tot de laatste versie van data, terwijl de data bij verschillende bronhouders kan blijven. Het systeem is gebaseerd op open source componenten en omvat procedures die de verbinding met de data-distributielaag van RWS verzorgen. Hiermee worden op projectbasis verzamelde gegevens op gestandaardiseerde wijze ontsloten. De pilot verschafte tegelijkertijd inzicht in nationale en internationale ontwikkelingen op het gebied van datamanagement.
Tenslotte gaf deze pilot een uitleg van de zogenaamde *aaS standaarden (“… as a Service”) voor beheer van gedistribueerde ICT systemen, op basis waarvan scenario’s voor beheer kunnen worden gegenereerd.
Voor geslaagde data uitwisseling is het belangrijk dat de partijen het eens zijn over de gebruikte technieken, semantische afspraken en organisatorische afspraken. Om dit te faciliteren heeft IHM het Protocol mariene data opgesteld samen met betrokken partijen. Dit protocol vormt een van de kaders van de huidige opdracht. De OpenEarth software stack is een oplossing die voldoet aan dit protocol. Sommige onderdelen van de stack zijn al productiewaardig, terwijl andere onderdelen nog in ontwikkeling zijn. In deze fase is er niet veel focus geweest op metadata-zoekcatalogi, vooral omdat partijen hier zelf al oplossingen voor hebben, zoals de RWS data-distributielaag. Hier levert de OpenEarth software stack alleen aan.
Het huidige project moet door het ontsluiten van (benthos) data van IMARES leiden tot inzicht in hoeverre de door Deltares ontwikkelde OpenEarth stack ook voor IMARES bruikbaar is en voordelen biedt ten opzichte van bijv. de Digitale Delta om mariene gegevens op uniforme wijze te ontsluiten.
Digitale Delta Use Case Mariene Monitoring 17 januari 2014, definitief
4 van 21
Voor IHM vormt het project een onderdeel van haar inspanning om benthos data uit verschillende bronnen op uniforme wijze te ontsluiten. Het betreft naast de benthos data van IMARES, tevens de RWS Ecolims data en RWS benthos data die in spreadsheets zijn opgeslagen. Gebruikers moeten in staat zijn deze data te zien en te downloaden.
In een bredere context is Deltares voor Rijkswaterstaat bezig de OpenEarth software stack ook bij 3TU te installeren voor het beheer van de Zandmotor data. Daarnaast heeft RWS aan Deltares opdracht verleend om te kijken in hoeverre de stack ook door RWS zelf gehost kan worden, met als case de data van MEP-Duinen. IMARES is dus (naast Deltares, 3TU en RWS-CIV) de vierde locatie waar met de stack gewerkt wordt.
2 Ontsluiten van IMARES data
Zoals aangegeven in de inleiding moet het huidige project, door het ontsluiten van (benthos) data van IMARES, leiden tot inzicht in hoeverre de door Deltares ontwikkelde OpenEarth stack ook voor IMARES bruikbaar is. In het speelveld van mariene data zijn er echter vele alternatieve oplossingen om mariene gegevens op uniforme wijze te ontsluiten. Soms verschillen de gebruikte standaarden, terwijl in andere gevallen dezelfde standaarden gebruikt worden maar in alternatieve technische oplossingen. Sommige standaarden zijn al jaren gangbaar zonder dat deze door een gemachtigde instantie als standaard zijn bestempeld: de zogenaamde de facto standaarden. Er zijn ook standaarden die door gemachtigde instanties als zodanig zijn aangemerkt. Dit zijn zogenaamde de jure standaarden. Idealiter vallen de jure en de facto standaarden samen. Sommige klassieke de facto standaarden voldoen niet aan de minimum eisen voor een de jure standaard, terwijl sommige de jure standaarden geen gebruikersgroep kennen en dus geen de facto standaard zijn. Op Europees niveau wordt hierop gestuurd door domeinen zelf hun eigen standaarden te laten inbrengen voor detail niveau. Het is de uitdaging in het speelveld mariene data om de jure standaarden en de facto standaarden naar elkaar te laten convergeren.
Digitale Delta Use Case Mariene Monitoring 17 januari 2014, definitief
6 van 21
OpenEarth schrijft geen eigen standaard voor, maar probeert convergentie te verkrijgen door met een mix van bestaande standaarden te werken. Dit kan door de jure standaarden technisch te implementeren, maar ook door te lobbyen om de facto standaarden een de jure status te geven. Het uitgangspunt is echter altijd een set die op korte termijn praktisch werkt, en op langere termijn naar convergentie moet evolueren. Datamanagement moet namelijk zowel op korte termijn betrouwbaar ingezet kunnen worden in projecten met een concrete opdracht en een deadline, zoals PMR-NCV, maar ook op lange termijn koppelbaar zijn naar de relevante netwerken. Vanwege de pragmatische aard van OpenEarth zullen we hier de relevante biologische de jure en de facto standaarden bespreken, om die maximaal te kunnen herbruiken. Dit vergt enig jargon, waarbij Figuur 1 verbanden aangeeft.
• IMARES (partij A; linksonder in figuur) heeft haar eigen “in-house” opslagmodel voor data, en kan data van daar aan externe partijen uitleveren. Momenteel levert IMARES al data aan aan EZ (partij B; linksboven in figuur) waarvoor een ons onbekende de facto standaard voor syntax en semantiek wordt gehanteerd.
• a: Daarnaast heeft IMARES (overigens net als RWS, Deltares en Defensie (Dienst der Hydrografie)) zitting in het Nationaal Oceanografisch Data Committee (NODC) waar netCDF of het Europese Ocean Data View (ODV) file formaat met SeaDataNet (SDN) semantiek gehanteerd wordt. ODV-SDN is uitontwikkeld voor fysisch-chemische data. Biologische data wordt op Europees niveau momenteel uitgewisseld door middel van de WoRMS semantische standaard via database (SQL-) syntax (zie ook d.). Het Europese deel van WoRMS is de mariene subset van de INSPIRE PESI database (die alle soorten omvat). WoRMS is ook de mariene subset voor het wereldwijde GBIF (Global Biodiversity Information Facility). Deze standaard is al af en dus een de facto standaard, en is daarom gekozen als basis voor opslag en uitwisseling in PMR-NCV. De betrouwbaarheid van de implementatie heeft ertoe geleid dat deze standaard in de OpenEarth stack is opgenomen, en nu ook voor Building with Nature en de Zandmotor partners wordt voorgeschreven. In het EU project EMODNet-biology wordt momenteel gewerkt aan het geschikt maken van ODV-SDN voor biologische data.
• b (donkerblauw vlak in figuur): Voor het huidige project zijn de in IHM deelnemende partijen van belang: de uitlevering aan EZ en uitlevering aan Rijkswaterstaat, volgens de data-distributielaag (DDL) die momenteel in ontwikkeling is. Rijkswaterstaat vereist dat alle data volgens de Aquo semantische standaard wordt aangeleverd. Dit is een Nederlandse “Pas toe of leg uit”1de jure standaard beheerd door IHW. Deze standaard is al gemeengoed voor zoete wateren (EU KRW rapportages), en is in de groei voor zoute wateren. IHM heeft deze standaard in haar Protocol mariene data geadopteerd. Deze standaard is nog jong, sinds 2008. Men is vrij in de syntax standaard (xml, csv en ook netcdf is mogelijk).
• c: De OpenEarth stack wordt apart genoemd als technische implementatie, maar het is geen aparte standaard (conform het doel van OpenEarth om bestaande de jure en de facto standaarden te laten convergeren, met iets bruikbaars op korte termijn). Voor PMR-NCV en BwN is gekozen om de uitontwikkelde WoRMS semantiek met een relationele database (SQL) als uitgangspunt te nemen. Dit is vervolgens op verzoek van RWS uitgebreid met een mapping van WoRMS naar WFS-Aquo. Door deelname van IMARES aan deze interdisciplinaire projecten (PMR-NCV, BwN) en sindsdien ook Zandmotor, is uitlevering naar de OpenEarth stack inmiddels vereist voor relevante datasets van IMARES. PMR-NCV en Zandmotor kunnen met de OpenEarth stack achteraf aan RWS aanleveren, dat WFS-Aquo als standaard hanteert.
1
• d: IMARES en Deltares participeren samen in het EU project EMODnet, waarin afgesproken is om gezamenlijke data uit te leveren naar de pan-Europese EMODnet biology database. Dat kan via de WoRMS syntax, maar ook via de in ontwikkeling zijnde uitbreiding van de ODV-SDN syntax in datzelfde project (zie a). Voor SDN uitlevering (a) zou de OpenEarth stack met een SDN mapping uitgebreid moeten worden, terwijl voor (d) OpenEarth meteen kan leveren.
• Tenslotte moet genoemd worden dat de IOW (Intelligent Operations Water) software van IBM een oplossing kan zijn om mariene data op te slaan en te ontsluiten. Syntax en semantiek zijn ons onbekend.
Er zijn dus vele wegen die naar Rome leiden, waarvan sommige al gebaande paden zijn, terwijl anderen nog aangelegd moeten worden. In dit project is getracht met een minimum aan inspanning op korte termijn een maximum aan uitwisseling te bereiken.
Voor het huidige project is ervoor gekozen initieel de infrastructuur (stack) te gebruiken die door Deltares is ontwikkeld in het kader van de ‘Pilot datamanagement mariene projecten’, en deze naar behoefte aan te passen. De stack kent momenteel de meeste gebaande paden (analogie: de meeste plug-n-play “printerdrivers”), en kan dus het snelst wat werkends opleveren. De filosofie achter de OpenEarth stack is namelijk dat deze evolueert door ontwikkelingen te incorporeren die noodzakelijk blijken als de stack op een nieuwe plek wordt geïnstalleerd. De centrale versie van de OpenEarth SaaS (software as a Service) stack accumuleert aldus de noodzakelijke technische aanpassingen die voor verschillende PaaS (Platform as a Service) ondergronden vereist zijn (bijvoorbeeld andere Linux versies). Daarnaast neemt de OpenEarth stack ontwikkelingen in zich op die nodig blijken om het geheel blijvend te laten convergeren. Tenslotte wordt de stack aangepast als ontwikkelingen nodig blijken t.b.v. afnemers van data, zoals IHM.
In feite is de software stack slechts een “pijpleiding” waar data doorheen kunnen. De Deltares OpenEarth stack omvat de volgende elementen (zie Figuur 2):
Subversion repository. De repository is de centrale opslagplaats waar de ruwe gegevens en wijzigingen daarin onder versiebeheer worden bijgehouden.
PostgreSQL database. De ETL-procedures (Extract, Transform, Load) om de data uit de repository in de PostgreSQL database te krijgen zijn de verantwoordelijkheid van de toeleverende partijen. De ETL-procedures moeten tot op hoge graad geautomatiseerd zijn om de PostgreSQL te updaten bij bepaalde releases (geteste versie) van de data. Deze procedures worden bij voorkeur in dezelfde voornoemde Subversion repository opgeslagen.
PostGIS extensie is bedoeld om met geospatiële datatypes te werken. (Voor Oracle is hiervoor Oracle Spatial beschikbaar).
GeoServer: deze laag zorgt door middel van een servicelaag op o.a. databases dat de data naar buiten beschikbaar komt via OGC services (Open Geospatial Consortium) en zo in bijvoorbeeld webviewers of desktop GIS-applicaties gebruikt kan worden zonder dat de gebruiker kennis heeft van de data. Deze laag biedt de WFS syntax en Aquo semantiek aan zoals afgesproken in het Protocol mariene data.
GeoNetwork: Deze service dient als discovery (vindbaarheid) catalogus voor de onderliggende data. Via de catalogus kan een extern proces, hetzij een viewer of een andere catalogus-server, eenvoudig een antwoord vinden op de volgende vragen; WAT is gemeten, WAAR is gemeten en WANNEER is gemeten. Als deze vragen eenmaal beantwoord zijn, kan gericht data opgevraagd worden. De data zelf wordt niet via de catalogus geleverd. De catalogus levert alleen informatie over wat voor data aanwezig is en waar deze data te vinden is. Dit laatste zal gebeuren door middel van URL-links, die kunnen verwijzen naar WFS-, WMS- en
Digitale Delta Use Case Mariene Monitoring 17 januari 2014, definitief
8 van 21
OPeNDAP services of naar andere databronnen. De GeoNetwork catalogus ondersteunt het OGC CSW (Catalog Services for the Web) protocol. Dit protocol maakt het mogelijk om de informatie binnen een catalogus te harvesten. Zo zou elke procesketen een catalogus kunnen aanbieden en zou deze gekoppeld kunnen worden aan een projectoverstijgende catalogus van Rijkswaterstaat. Voor de duidelijkheid; met het harvesten blijft de data zelf bij de bronhouder, alleen de metadata wordt onder gebracht in een of meerdere CSWs. Omdat binnen een dataset niet alle data voor iedereen vrij beschikbaar is, biedt GeoNetwork de mogelijkheid om functionaliteit en data af te schermen met behulp van gebruikers authenticatie. Op deze manier blijft de bronhouder in controle over de mate van openheid van de data.
Figuur 2 De Deltares OpenEarth stack is een data distributieketen, die (onderin) begint bij een repository, waar de ruwe data (versies) binnenkomen, en vervolgens via standaardisatie (in een database) en opwerking leidt tot producten die bekeken en via een catalogus gevonden kunnen worden (bovenin de stack). Merk op dat in de stack twee parallelle sporen te onderscheiden zijn: links via PostgreSQL het spoor voor puntdata; rechts via netCDF het spoor voor rasterdata. In het huidige project ligt de focus op puntdata
SubVersion, GIT version control: THREDDS OGC netCDF + OPeNDAP PostgreSQL ISO SQL OGC CF Conventions OGC PostGIS GeoServer Geonetworks CSW ncWMS, ADAGUC
OGC WxS & KML servlets
geospatial semantics servlets
De componenten van de stack en andere van de stack deel uitmakende software zijn in dit project geïnstalleerd op een zgn. virtuele Linux server die IMARES bij Wageningen UR ICT heeft afgenomen. De server is voor de ‘buitenwereld’ slechts onder restricties toegankelijk. Deze opzet komt voort uit het IMARES beleid dat data in productiedatabases niet rechtstreeks toegankelijk zijn voor derden. IMARES zal dus een zogenoemde cache aanbieden aan de buitenwereld.
Figuur 1 liet zien dat er voor IMARES in principe twee hoofdroutes beschikbaar zijn om hun ecologische puntdata te ontsluiten: direct een mapping vanuit hun in-house database naar een doeldatabase, of een offline mapping op database niveau van de in-house database naar een database met een gedeeld datamodel, waarvoor al mappings naar de doeldatabases bestaan. Figuur 3 presenteert de selectie van onderdelen uit Figuur 1 die voor het huidige project relevant zijn.
Figuur 3 Ontsluiting van IMARES data via de Deltares software stack
In de voorgaande pilot, die Deltares voor RWS heeft uitgevoerd, stond RWS voor dezelfde keuze: ofwel een rechtstreekse mapping vanuit de interne database (DONAR) naar de WFS-Aquo standaard van de DDL, ofwel een relevante selectie van DONAR op database niveau repliceren naar een Aquo-compliant datamodel, waarna deze cache database via de Deltares software stack op de DDL wordt aangesloten.
IMARES heeft voor dit project een soortgelijke keuze als Rijkswaterstaat gemaakt, met dezelfde randvoorwaarde dat niet hun hele interne database gemapt hoeft te worden; een deel van de data blijft alleen intern beschikbaar (zie ook Figuur 4, ontleend aan de (concept)-offerte van IMARES).
Digitale Delta Use Case Mariene Monitoring 17 januari 2014, definitief
10 van 21
Figuur 4 Ontsluiting via de groene pijlen van de IMARES data, figuur IMARES
Aansluiting eerdere pilot RWS DDL
In de eerdere pilot voor RWS zijn de doeldatabases weergegeven in het schema van de systeem architectuur HWS 2011-2013 (zie Figuur 5). De uit te werken scenario’s zijn toen aangeduid als “4” of “6”. Scenario “4” staat voor een goed gedefinieerde, intern beheerste standaard met een navenant beheerst geldigheidsgebied: Aquo, alleen in Nederland toegepast. Scenario “6” staat voor een in beweging zijnde internationale standaard met een navenant groot geldigheidsgebied (heel Europa, of zelfs wereld). Vanwege de beheersbaarheid van het pilot project is toen gekozen voor “4”, met een open oog naar “6”. Voor dit project is, na overleg met IMARES, in feite een identiek pad bewandeld. Er is een “4” geïmplementeerd door IMARES data via dezelfde WFS-Aquo standaard te ontsluiten.
Figuur 5 Verschillende scenario’s om de Deltares software stack aan te sluiten op de HWS systeemarchitectuur van Rijkswaterstaat. Zowel in de pilot als in het huidige project is gekozen voor scenario “4”
3 Verslag van uitgevoerde werkzaamheden
In de volgende paragrafen worden de uitgevoerde werkzaamheden, zoals die zijn geoffreerd, kort beschreven.
. Ondersteun IMARES op haar verzoek bij het op orde brengen van data en metadata . Doe in overleg met IMARES beperkte inspanning om standaardisatie verder te brengen . Werk met IMARES indien nodig aan mappingstabel en tool
. Ondersteun bij de installatie van de WFS/WMS dataserver en WebDAV metadata server . Test op het internet (dus van buiten) dat de data zijn te zien en op te vragen
. Stel vast op welke terreinen het protocol mariene data helpt en waar het moet worden aangescherpt
In de oorspronkelijke aanbieding was er ook een verband gelegd tussen de door IBM voorgestelde enterprise service bus techniek en de Deltares OpenEarth software stack. De onderlinge vergelijking van deze verschillende oplossingen is door het opsplitsen van het project in een aantal separate deelprojecten, in het huidige project niet aan de orde gekomen.
3.1 Ordenen data en metadata
Naar aanleiding van de werksessie mapping is besloten dat het gaat om het leveren van de webservices volgens het op deze werksessie opgestelde pakket van eisen. Die eisen zijn een aantal verplichte metadata velden en een aantal velden zoals in Aquo gedefinieerd. IMARES draagt er zorg voor dat de webservices de inhoud krijgen van de in de werksessie afgesproken velden. Zie verder § 3.3.
De afgesproken velden gaan op meer detail in dan wat Deltares in de pilot mariene projecten heeft opgeleverd. Deltares zal haar dataservices upgraden naar hetzelfde metadata niveau in het project.
3.2 Standaardisatie
IMARES bleek intern al grotendeels WoRMS te hanteren voor benthos. Bij het kopiëren (repliceren) van de open subset van haar interne database, maakt IMARES de mapping naar WoRMS compleet. IMARES gebruikt niet het PMR-NCV datamodel, maar een eigen datamodel. IMARES kan hierdoor niet de Aquo mapping van het PMR-NCV datamodel hergebruiken, maar maakt een eigen mapping. Deze investering wordt kleiner geschat dan de investering om naar het PMR-NCV datamodel te mappen. De uiteindelijke datalevering is identiek, dus voor de gebruikers is het om het even.
3.3 Mappingstabel en tool
Op vrijdag 6 december 2013 is met personen van Ecosys, RWS, IMARES, MARIS, IHM, IHW en Deltares een werksessie gehouden om afspraken te maken over de te vullen velden ten behoeve van metadata en velden ten behoeve van uitwisseling. Daarbij is sterk geleund op het Uitwisselmodel Aquo (UM-Aquo). Tijdens deze sessie is afgesproken dat eenieder data beschikbaar stelt via een zogenaamde CSW service. Dit staat voor Catalogus Service voor het Web, een standaard voor het beschikbaar stellen van een catalogus met beschrijvende informatie van geospatiële data, services en aanverwante bronnen via Internet (over HTTP). Aanbieders van geospatiële data kunnen hun metadata aan een catalogus aanbieden, conform het gebruikte informatiemodel. Het is dan voor applicaties mogelijk om snel naar geospatiële data en services te zoeken. De gebruiker van de data kan op basis van de metadata de geschiktheid en kwaliteit van data(-producten) beoordelen en vergelijken. De CSW-service voldoet aan de eisen van het Nederlands profiel op ISO19115-2. Geonovum
Digitale Delta Use Case Mariene Monitoring 17 januari 2014, definitief
14 van 21
levert uitputtende beschrijvingen van dit dialect op het internationale ISO19115-2 metadataprofiel.
Voor de inhoud van de webservices is vooral gekeken naar de semantiek. Welke velden in welke specifieke services. UM-Aquo is opgebouwd volgens het Wat, Waar en Hoe principe, respectievelijk ook wel locatie, meting en monster genoemd.
Afgesproken is dat dit aan de ontvangende kant ondubbelzinnig en volgens Aquo standaarden ingelezen moet kunnen worden. Dit betekent dat aan de leverende kant vanuit het gehanteerde datamodel “iets” gedaan moet worden om dit te realiseren. Dan zijn er diverse mogelijkheden, deze zijn vanuit de leverende kant:
- Datamodel handhaven en mappen naar Aquo
- Datamodel herzien en zonder mappen leveren aan Aquo
Met betrekking tot de taken die voor IMARES uitgevoerd worden/zijn is voor de eerste optie gekozen. Het huidige datamodel (en dus de werkwijze) blijven ongewijzigd waardoor via een mapping aanlevering volgens UM-Aquo gerealiseerd kan worden. Dat is een snelle actie die volledig geautomatiseerd kan worden.
Per organisatie en mogelijk per project kan worden overwogen om een specifiek voor een bepaald doeleinde ontworpen datamodel te maken, of een bestaand datamodel incl. geïmplementeerde mappings te hergebruiken. Echter de uitleverende partij dient volgens de afspraken een UM-Aquo comforme webservice aan te bieden.
3.4 Installatie server
Medio november 2013 heeft IMARES een server beschikbaar gesteld voor installatie van de software stack componenten. De server (scomp1184.wur.nl) is voorzien van het RedHat Enterprise Linux Server Operating System.
Deltares heeft ter plekke geassisteerd bij de installatie en configuratie van de software stack componenten. Van ‘onder naar boven’ zijn geïnstalleerd (Figuur 2):
- PostgreSQL database
- PostGIS extensie op PostgreSQL
- Apache Tomcat Webservice container voor het draaien van GeoServer en GeoNetwork, beide Java implementaties
- GeoServer voor WxS services op de database - GeoNetwork voor catalogus (CSW)
De GeoNetwork installatie is zo geconfigureerd dat deze voor opslag van de metadata catalogus gegevens ook de PostgreSQL database benut i.p.v. de embedded, in-memory H2 database die na installatie van GeoNetwork bij verstek wordt toegepast.
Naar goede gewoonte staat de server scomp1184.wur.nl in een Demilitarized Zone (DMZ) die naar de buitenwereld (www) enkel verkeer over poort 80 (http) toestaat. Om de services (GeoServer en GeoNetwork) die onder Apache Tomcat (poort 8080) draaien, bereikbaar te maken is een proxy opgezet met het open source product Squid dat Deltares ook in gebruik heeft.
3.5 Test
Als test van de werking van de stack is de PostgreSQL database bij IMARES gevuld met een export van de PMR-database die bij Deltares staat. De aldus gerealiseerde en initieel gevulde IMARES’ Spatiële Data Infrastructuur (SDI), bestaande uit de GeoServer installatie en de onderliggende PostgreSQL/PostGIS database, is vanuit een webbrowser bereikbaar. Op het moment van schrijven zijn er 2 lagen beschikbaar:
http://scomp1184.wur.nl/geoserver/pmr/wms?service=WMS&version=1.1.0&request= GetMap&layers=pmr:v_observations&styles=&bbox=3.0,51.4,6.541666667,53.7&widt h=512&height=332&srs=EPSG:4326&format=application/openlayers http://scomp1184.wur.nl/geoserver/pmr/wms?service=WMS&version=1.1.0&request= GetMap&layers=pmr:v_locations&styles=&bbox=3.0,51.4,6.541666667,53.7&width=5 12&height=332&srs=EPSG:4326&format=application/openlayers
Figuur 6 Eenvoudige WMS preview van een van de datalagen (pmr:observations) via IMARES’ SDI
Met behulp van het GetCapabilities request zijn de data lagen die via GeoServer worden aangeboden op te vragen (resultaat in XML-formaat):
http://scomp1184.wur.nl/geoserver/pmr/wms?service=WMS&version=1.1.0&request=GetCap abilities
Digitale Delta Use Case Mariene Monitoring 17 januari 2014, definitief
16 van 21
Hoewel de GeoNetwork CSW installatie in deze fase van het project nog niet strikt noodzakelijk was, is deze catalogus al wel beschikbaar (maar nog niet gevuld). Zie:
http://scomp1184.wur.nl/geonetwork/
Figuur 7 Lege maar functionele CSW, zichtbaar via een webbrowser
Voor uitleg over gebruik van de hier genoemde URLs wordt verwezen naar Appendix B3 “Bevraging via een internet Browser” van Deltares rapport “Pilot datamanagement mariene projecten”.
3.6 Toelichting kenmerken gemeenschappelijke database
Besloten is geen gemeenschappelijk datamodel te ontwikkelen; IMARES houdt zijn eigen datamodel, omdat dat beter is afgestemd op de interne vragen.
Dit betekent wel dat IMARES zelf een ETL van de interne database naar de extern benaderbare database moet verzorgen om van daaruit via de Deltares OpenEarth stack data te serveren naar de gebruiker d.m.v. een Aquo compliant WFS.
Een potentieel knelpunt in deze opzet is dat de repository functie uit de stack niet wordt overgenomen, maar wordt vervangen door de originele IMARES database. Kwaliteitscontrole en versiebeheer zijn hierdoor minder traceerbaar en transparant.
3.7 Protocol mariene data
Het Protocol verschaft duidelijkheid over rollen, taken en verantwoordelijkheden. De uitkomst van de werksessie is een noodzakelijke aanvulling op het bestaande document, onder meer ten aanzien van de minimaal aan te leveren velden ten behoeve van een correcte en complete uitwisseling. Speciale aandacht zou nog gegeven kunnen worden aan de catalogus. Het protocol biedt momenteel onvoldoende inzicht in wat er geïmplementeerd moet worden om aan het protocol te voldoen. Een verwijzing naar de validatiefuncties van NGR (Nationaal Georegister) zou al een goede aanvulling zijn.
Het Protocol mariene data heeft hiermee aangeven een belangrijk trede te zijn in het laten convergeren van partijen en standaarden in het veld van de mariene data. Met het inpassen van de noodzakelijke aanvullingen volgend uit de werksessie zal het protocol de volgende trede zijn in het convergentieproces. Het is zaak voor de toekomst om de juiste balans te vinden in het vastleggen van afspraken voor de nabije toekomst enerzijds, en het meegroeien in het convergentieproces op langere termijn anderzijds. Er zal moeten blijken wat een goede update frequentie is, jaarlijks, twee-jaarlijks? De organisatie achter het protocol, een aantal partijen die samen (i.p.v. top-down) de piketpaaltjes uitzetten en er samen aan werken om die op korte termijn te implementeren, is een vruchtbare aanpak gebleken.
4 Conclusies en aanbevelingen
In deze pilot is met een relatief bescheiden budget en in relatief korte tijd een aantal grote stappen gezet. De hands-on-aanpak van dit project enerzijds in combinatie met breed overleg anderzijds is ons inziens de succesfactor. Na 1 kick-off meeting van een halve dag zijn de experts meteen hands-on aan de slag gegaan zonder eerst alles uitentreuren in detail te willen plannen. Het projectbudget is direct omgezet in werkende technologie, in plaats van alleen een ontwerp op papier. De combinatie van specialisten op gebied van mariene biologie (taxonomie), database experts, webservice experts en voldoende brede projectleiders hebben hiertoe geleid. Deze zogenaamde agile aanpak wordt in de software wereld steeds vaker gehanteerd: in kleine iteratieve stapjes doorwerken, met evaluatie en bijsturen na iedere stap. Zo’n stap wordt vaak een sprint genoemd, en duurt niet langer dan een maand. Zo beschouwd is dit hele project in feite een sprint geweest in jargon van de agile software ontwikkeling. Dit project vraagt daarom nu een gedegen evaluatie, resulterend in het formuleren van een volgende sprint. Voor het evalueren is een aantal richtingsverkenningen mogelijk.
Een openstaand punt is om de door Deltares en IMARES opgeleverde web ontsluiting grondig te testen wat betreft aansluiting op een catalogus. Een centrale catalogus zoals die van IHM of de RWS DDL zou de beide databases helemaal leeg moeten vragen om te beoordelen of de data en mapping compleet zijn, en of de web ontsluiting een goede performance heeft. IMARES en Deltares zouden ook elkaars services kunnen bevragen alsof het hun eigen services zijn. Ook zouden hier ‘sparring’ partners buiten het veld van mariene data gezocht kunnen worden om zaken mee te testen, zoals NGR en 3TU Datacenter en VLIZ.
Het draagvlak voor de gezamenlijke aanpak kan verder vergroot worden door het aantal deelnemende partijen uit te breiden met bijvoorbeeld de PMR of Zandmotor partners.
Zowel in de vorige pilot als in het huidige project is aangestuurd op aansluiting van de Deltares OpenEarth software stack op de RWS datadistributielaag (DDL). Er dreigt echter vertraging op te treden in de realisatie van de DDL, waardoor het niet zeker is dat het ministerie van IenM tijdig invulling kan geven aan haar beleid om per 1 januari 2015 haar data open beschikbaar te stellen. De Deltares stack is door het gebruik van WFS evenwel flexibel genoeg om rechtstreeks te leveren aan een portal zoals bijvoorbeeld het IHM voor ogen heeft.
De resultaten van het huidige project zullen worden benut in het project Datamanagement mariene monitoring (1208604) dat RWS aan Deltares gegund heeft. De uitbreiding op de metadata zullen worden geïmplementeerd in de OpenEarth stack. Ze zullen zodoende doorwerken bij de Deltares en 3TU servers, en ook in de beoogde installatie bij RWS CIV. Het opknippen van de Use Case Mariene Monitoring in een aantal kleine deelprojecten heeft als nadeel dat het overzicht voor de deelnemende partijen vermindert. Zo is de inbreng van IBM (hoe beoordeelt een professioneel ICT-bedrijf de OpenEarth aanpak?) voor de deelnemende partijen geheel buiten beeld gebleven.
De aanpassingscyclus van het Protocol mariene data verdient nadere aandacht. Een eerste slag is om de aanpassingen uit de workshop te incorporeren en in de volgende versie van het Protocol te publiceren.
