digitale delta use case mariene monitoringpublications.deltares.nl/1208589_000.pdf · gebruikte...

Digitale Delta Use CaseMariene Monitoring

Digitale Delta Use Case MarieneMonitoring

1208589-000

© Deltares, 2014, B

drs. G.H. van der Kolffdr.ir. G.J. de Boerdrs. ing G. Hendriksening. J.F. Keppel

DeltaresTitelDigitale Delta Use Case Mariene Monitoring

OpdrachtgeverRWSWater Verkeer enLeefomgeving

Project1208589-000

Pagina's21

TrefwoordenDatamanagement, OpenEarth, Informatiehuis Marien, benthos data

SamenvattingDe Digitale Delta Use Case Mariene Monitoring (DD-UC-MM) sluit aan bij het eerderuitgevoerde 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 InformatieHuis Marien en betreft het verder ontwikkelen van een op OpenEarth gebaseerde methodevoor beheer en herbruikbaar maken van mariene projectdata. Dit project is uitgevoerd samenmet IMARES, terwijl het in een bredere setting wordt uitgevoerd i.s.m. Rijkswaterstaat WaterVerkeer en Leefomgeving en Centrale Informatievoorziening (RWS-WVL en -CIV), IMARESen 3TU.Deltares heeft de noodzakelijke software bij IMARES geïnstalleerd en geconfigureerd. VanuitIBM (als trekker van het koepelproject Digitale Delta) is er geen actieve bijdrage geweest metbetrekking tot de hierboven genoemde punten. Er zijn geen uitspraken geweest over deDeltares software stack, noch heeft een "keuring" van de bruikbaarheid daarvanplaatsgevonden.

ReferentiesZaaknummer 31086670/Hofman

·an.2014Versie Datum

Statusdefinitief

Digitale Delta Use Case Mariene Monitoring

17 januari 2014, definitief

Digitale Delta Use Case Mariene Monitoring i

Inhoud

1 Introductie 3

2 Ontsluiten van IMARES data 5

3 Verslag van uitgevoerde werkzaamheden 133.1 Ordenen data en metadata 133.2 Standaardisatie 133.3 Mappingstabel en tool 133.4 Installatie server 143.5 Test 153.6 Toelichting kenmerken gemeenschappelijke database 163.7 Protocol mariene data 16

4 Conclusies en aanbevelingen 19


Digitale Delta Use Case Mariene Monitoring 1 van 21



1 Introductie

Het Informatiehuis Marien (IHM) is een gemeenschappelijk initiatief van de ministeries vanInfrastructuur en Milieu (IenM) en Economische Zaken (EZ), met het ministerie van Defensieals lid van de klankbordgroep en leverancier van data, kennis en advies. IHM heeft tot doelalle mariene informatie en onderzoeksgegevens over de Noordzee op één plek toegankelijkte maken voor belangstellenden, overheden en professionals. Hiermee wordt die informatiebeter 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 behulpvan betere informatiedeling en slim hergebruik van ICT toepassingen het waterbeheer inNederland verbeterd kan worden. De Digitale Delta kent een open aanpak: de watersectorkan in Use Cases participeren, hun producten en diensten in een proeftuin demonstreren envia een klankbordgroep meedenken over het programma. IHM is trekker van de Use CaseMariene Monitoring. In de Use Case wil IHM zich een beeld vormen van de mogelijketoegevoegde 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 langetermijn oplossingen voor het hergebruik van mariene projectgegevens. De uitgevoerde pilot toondeaan 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-NCVbereikbaar worden gemaakt via de data-distributielaag van WaterDataNet. Het eindrapport van depilot geeft een uitvoerige beschrijving van het systeem dat gebruikers toegang verschaft tot delaatste versie van data, terwijl de data bij verschillende bronhouders kan blijven. Het systeem isgebaseerd op open source componenten en omvat procedures die de verbinding met de data-distributielaag van RWS verzorgen. Hiermee worden op projectbasis verzamelde gegevens opgestandaardiseerde wijze ontsloten. De pilot verschafte tegelijkertijd inzicht in nationale eninternationale ontwikkelingen op het gebied van datamanagement.Tenslotte gaf deze pilot een uitleg van de zogenaamde *aaS standaarden (“… as a Service”) voorbeheer van gedistribueerde ICT systemen, op basis waarvan scenario’s voor beheer kunnenworden gegenereerd.

Voor geslaagde data uitwisseling is het belangrijk dat de partijen het eens zijn over degebruikte technieken, semantische afspraken en organisatorische afspraken. Om dit tefaciliteren heeft IHM het Protocol mariene data opgesteld samen met betrokken partijen. Ditprotocol vormt een van de kaders van de huidige opdracht. De OpenEarth software stack iseen oplossing die voldoet aan dit protocol. Sommige onderdelen van de stack zijn alproductiewaardig, terwijl andere onderdelen nog in ontwikkeling zijn. In deze fase is er nietveel focus geweest op metadata-zoekcatalogi, vooral omdat partijen hier zelf al oplossingenvoor hebben, zoals de RWS data-distributielaag. Hier levert de OpenEarth software stackalleen aan.

Het huidige project moet door het ontsluiten van (benthos) data van IMARES leiden tot inzichtin hoeverre de door Deltares ontwikkelde OpenEarth stack ook voor IMARES bruikbaar is envoordelen biedt ten opzichte van bijv. de Digitale Delta om mariene gegevens op uniformewijze te ontsluiten.



4 van 21

Voor IHM vormt het project een onderdeel van haar inspanning om benthos data uitverschillende bronnen op uniforme wijze te ontsluiten. Het betreft naast de benthos data vanIMARES, tevens de RWS Ecolims data en RWS benthos data die in spreadsheets zijnopgeslagen. Gebruikers moeten in staat zijn deze data te zien en te downloaden.

In een bredere context is Deltares voor Rijkswaterstaat bezig de OpenEarth software stackook bij 3TU te installeren voor het beheer van de Zandmotor data. Daarnaast heeft RWS aanDeltares opdracht verleend om te kijken in hoeverre de stack ook door RWS zelf gehost kanworden, met als case de data van MEP-Duinen. IMARES is dus (naast Deltares, 3TU enRWS-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 OpenEarthstack ook voor IMARES bruikbaar is. In het speelveld van mariene data zijn er echter velealternatieve oplossingen om mariene gegevens op uniforme wijze te ontsluiten. Somsverschillen de gebruikte standaarden, terwijl in andere gevallen dezelfde standaardengebruikt worden maar in alternatieve technische oplossingen. Sommige standaarden zijn aljaren gangbaar zonder dat deze door een gemachtigde instantie als standaard zijnbestempeld: de zogenaamde de facto standaarden. Er zijn ook standaarden die doorgemachtigde instanties als zodanig zijn aangemerkt. Dit zijn zogenaamde de jurestandaarden. Idealiter vallen de jure en de facto standaarden samen. Sommige klassieke defacto standaarden voldoen niet aan de minimum eisen voor een de jure standaard, terwijlsommige de jure standaarden geen gebruikersgroep kennen en dus geen de facto standaardzijn. Op Europees niveau wordt hierop gestuurd door domeinen zelf hun eigen standaardente laten inbrengen voor detail niveau. Het is de uitdaging in het speelveld mariene data om dejure standaarden en de facto standaarden naar elkaar te laten convergeren.

Figuur 1 Wegen om IMARES data te ontsluiten, figuur IMARES



6 van 21

OpenEarth schrijft geen eigen standaard voor, maar probeert convergentie te verkrijgen doormet een mix van bestaande standaarden te werken. Dit kan door de jure standaardentechnisch te implementeren, maar ook door te lobbyen om de facto standaarden een de jurestatus 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 namelijkzowel op korte termijn betrouwbaar ingezet kunnen worden in projecten met een concreteopdracht en een deadline, zoals PMR-NCV, maar ook op lange termijn koppelbaar zijn naarde relevante netwerken. Vanwege de pragmatische aard van OpenEarth zullen we hier derelevante biologische de jure en de facto standaarden bespreken, om die maximaal tekunnen herbruiken. Dit vergt enig jargon, waarbij Figuur 1 verbanden aangeeft.

• IMARES (partij A; linksonder in figuur) heeft haar eigen “in-house” opslagmodel voordata, en kan data van daar aan externe partijen uitleveren. Momenteel levert IMARES aldata aan aan EZ (partij B; linksboven in figuur) waarvoor een ons onbekende de factostandaard voor syntax en semantiek wordt gehanteerd.

• a: Daarnaast heeft IMARES (overigens net als RWS, Deltares en Defensie (Dienst derHydrografie)) zitting in het Nationaal Oceanografisch Data Committee (NODC) waarnetCDF 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 deWoRMS semantische standaard via database (SQL-) syntax (zie ook d.). Het Europesedeel van WoRMS is de mariene subset van de INSPIRE PESI database (die allesoorten omvat). WoRMS is ook de mariene subset voor het wereldwijde GBIF (GlobalBiodiversity 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. Debetrouwbaarheid van de implementatie heeft ertoe geleid dat deze standaard in deOpenEarth stack is opgenomen, en nu ook voor Building with Nature en de Zandmotorpartners wordt voorgeschreven. In het EU project EMODNet-biology wordt momenteelgewerkt aan het geschikt maken van ODV-SDN voor biologische data.

• b (donkerblauw vlak in figuur): Voor het huidige project zijn de in IHM deelnemendepartijen van belang: de uitlevering aan EZ en uitlevering aan Rijkswaterstaat, volgensde data-distributielaag (DDL) die momenteel in ontwikkeling is. Rijkswaterstaat vereistdat alle data volgens de Aquo semantische standaard wordt aangeleverd. Dit is eenNederlandse “Pas toe of leg uit”1 de jure standaard beheerd door IHW. Deze standaardis al gemeengoed voor zoete wateren (EU KRW rapportages), en is in de groei voorzoute 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 enook netcdf is mogelijk).

• c: De OpenEarth stack wordt apart genoemd als technische implementatie, maar het isgeen aparte standaard (conform het doel van OpenEarth om bestaande de jure en defacto standaarden te laten convergeren, met iets bruikbaars op korte termijn). VoorPMR-NCV en BwN is gekozen om de uitontwikkelde WoRMS semantiek met eenrelationele database (SQL) als uitgangspunt te nemen. Dit is vervolgens op verzoek vanRWS uitgebreid met een mapping van WoRMS naar WFS-Aquo. Door deelname vanIMARES aan deze interdisciplinaire projecten (PMR-NCV, BwN) en sindsdien ookZandmotor, is uitlevering naar de OpenEarth stack inmiddels vereist voor relevantedatasets van IMARES. PMR-NCV en Zandmotor kunnen met de OpenEarth stackachteraf aan RWS aanleveren, dat WFS-Aquo als standaard hanteert.

1 https://lijsten.forumstandaardisatie.nl/open-standaard/aquo-standaard



• d: IMARES en Deltares participeren samen in het EU project EMODnet, waarinafgesproken is om gezamenlijke data uit te leveren naar de pan-Europese EMODnetbiology database. Dat kan via de WoRMS syntax, maar ook via de in ontwikkeling zijndeuitbreiding 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, terwijlvoor (d) OpenEarth meteen kan leveren.

• Tenslotte moet genoemd worden dat de IOW (Intelligent Operations Water) softwarevan IBM een oplossing kan zijn om mariene data op te slaan en te ontsluiten. Syntax ensemantiek 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 minimumaan inspanning op korte termijn een maximum aan uitwisseling te bereiken.

Voor het huidige project is ervoor gekozen initieel de infrastructuur (stack) te gebruiken diedoor Deltares is ontwikkeld in het kader van de ‘Pilot datamanagement mariene projecten’, endeze 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 werkendsopleveren. De filosofie achter de OpenEarth stack is namelijk dat deze evolueert doorontwikkelingen te incorporeren die noodzakelijk blijken als de stack op een nieuwe plek wordtgeïnstalleerd. De centrale versie van de OpenEarth SaaS (software as a Service) stackaccumuleert 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 hetgeheel blijvend te laten convergeren. Tenslotte wordt de stack aangepast als ontwikkelingennodig blijken t.b.v. afnemers van data, zoals IHM.

In feite is de software stack slechts een “pijpleiding” waar data doorheen kunnen. DeDeltares OpenEarth stack omvat de volgende elementen (zie Figuur 2):

Subversion repository. De repository is de centrale opslagplaats waar de ruwegegevens en wijzigingen daarin onder versiebeheer worden bijgehouden.PostgreSQL database. De ETL-procedures (Extract, Transform, Load) om de datauit de repository in de PostgreSQL database te krijgen zijn deverantwoordelijkheid van de toeleverende partijen. De ETL-procedures moeten totop hoge graad geautomatiseerd zijn om de PostgreSQL te updaten bij bepaaldereleases (geteste versie) van de data. Deze procedures worden bij voorkeur indezelfde voornoemde Subversion repository opgeslagen.PostGIS extensie is bedoeld om met geospatiële datatypes te werken. (VoorOracle is hiervoor Oracle Spatial beschikbaar).GeoServer: deze laag zorgt door middel van een servicelaag op o.a. databasesdat de data naar buiten beschikbaar komt via OGC services (Open GeospatialConsortium) en zo in bijvoorbeeld webviewers of desktop GIS-applicaties gebruiktkan worden zonder dat de gebruiker kennis heeft van de data. Deze laag biedt deWFS syntax en Aquo semantiek aan zoals afgesproken in het Protocol marienedata.GeoNetwork: Deze service dient als discovery (vindbaarheid) catalogus voor deonderliggende data. Via de catalogus kan een extern proces, hetzij een viewer ofeen andere catalogus-server, eenvoudig een antwoord vinden op de volgendevragen; WAT is gemeten, WAAR is gemeten en WANNEER is gemeten. Als dezevragen eenmaal beantwoord zijn, kan gericht data opgevraagd worden. De datazelf wordt niet via de catalogus geleverd. De catalogus levert alleen informatieover wat voor data aanwezig is en waar deze data te vinden is. Dit laatste zalgebeuren door middel van URL-links, die kunnen verwijzen naar WFS-, WMS- en



8 van 21

OPeNDAP services of naar andere databronnen. De GeoNetwork catalogusondersteunt het OGC CSW (Catalog Services for the Web) protocol. Dit protocolmaakt het mogelijk om de informatie binnen een catalogus te harvesten. Zo zouelke procesketen een catalogus kunnen aanbieden en zou deze gekoppeldkunnen worden aan een projectoverstijgende catalogus van Rijkswaterstaat. Voorde duidelijkheid; met het harvesten blijft de data zelf bij de bronhouder, alleen demetadata wordt onder gebracht in een of meerdere CSWs. Omdat binnen eendataset niet alle data voor iedereen vrij beschikbaar is, biedt GeoNetwork demogelijkheid om functionaliteit en data af te schermen met behulp van gebruikersauthenticatie. Op deze manier blijft de bronhouder in controle over de mate vanopenheid van de data.

Figuur 2 De Deltares OpenEarth stack is een data distributieketen, die (onderin) begint bij eenrepository, waar de ruwe data (versies) binnenkomen, en vervolgens via standaardisatie (ineen database) en opwerking leidt tot producten die bekeken en via een catalogus gevondenkunnen worden (bovenin de stack). Merk op dat in de stack twee parallelle sporen teonderscheiden zijn: links via PostgreSQL het spoor voor puntdata; rechts via netCDF het spoorvoor rasterdata. In het huidige project ligt de focus op puntdata

SubVersion, GIT version control:

THREDDSOGC netCDF+ OPeNDAP

PostgreSQLISO SQL

OGC CFConventionsOGC PostGIS

GeoServer

Geonetworks CSW

ncWMS, ADAGUC

OGC WxS & KML servlets

geospatial semantics

servlets

ETL



De componenten van de stack en andere van de stack deel uitmakende software zijn in ditproject geïnstalleerd op een zgn. virtuele Linux server die IMARES bij Wageningen UR ICTheeft afgenomen. De server is voor de ‘buitenwereld’ slechts onder restricties toegankelijk.Deze opzet komt voort uit het IMARES beleid dat data in productiedatabases nietrechtstreeks toegankelijk zijn voor derden. IMARES zal dus een zogenoemde cacheaanbieden aan de buitenwereld.

Figuur 1 liet zien dat er voor IMARES in principe twee hoofdroutes beschikbaar zijn om hunecologische puntdata te ontsluiten: direct een mapping vanuit hun in-house database naareen doeldatabase, of een offline mapping op database niveau van de in-house database naareen database met een gedeeld datamodel, waarvoor al mappings naar de doeldatabasesbestaan. Figuur 3 presenteert de selectie van onderdelen uit Figuur 1 die voor het huidigeproject 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 dezelfdekeuze: 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 niveaurepliceren naar een Aquo-compliant datamodel, waarna deze cache database via de Deltaressoftware stack op de DDL wordt aangesloten.

IMARES heeft voor dit project een soortgelijke keuze als Rijkswaterstaat gemaakt, metdezelfde randvoorwaarde dat niet hun hele interne database gemapt hoeft te worden; eendeel van de data blijft alleen intern beschikbaar (zie ook Figuur 4, ontleend aan de (concept)-offerte van IMARES).



10 van 21

Figuur 4 Ontsluiting via de groene pijlen van de IMARES data, figuur IMARES

Aansluiting eerdere pilot RWS DDLIn de eerdere pilot voor RWS zijn de doeldatabases weergegeven in het schema van desysteem architectuur HWS 2011-2013 (zie Figuur 5). De uit te werken scenario’s zijn toenaangeduid als “4” of “6”. Scenario “4” staat voor een goed gedefinieerde, intern beheerstestandaard met een navenant beheerst geldigheidsgebied: Aquo, alleen in Nederlandtoegepast. Scenario “6” staat voor een in beweging zijnde internationale standaard met eennavenant groot geldigheidsgebied (heel Europa, of zelfs wereld). Vanwege debeheersbaarheid 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 HWSsysteemarchitectuur van Rijkswaterstaat. Zowel in de pilot als in het huidige project is gekozenvoor 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 IBMvoorgestelde enterprise service bus techniek en de Deltares OpenEarth software stack. Deonderlinge vergelijking van deze verschillende oplossingen is door het opsplitsen van het projectin een aantal separate deelprojecten, in het huidige project niet aan de orde gekomen.

3.1 Ordenen data en metadataNaar aanleiding van de werksessie mapping is besloten dat het gaat om het leveren van dewebservices volgens het op deze werksessie opgestelde pakket van eisen. Die eisen zijn eenaantal verplichte metadata velden en een aantal velden zoals in Aquo gedefinieerd. IMARESdraagt er zorg voor dat de webservices de inhoud krijgen van de in de werksessieafgesproken velden. Zie verder § 3.3.De afgesproken velden gaan op meer detail in dan wat Deltares in de pilot mariene projectenheeft opgeleverd. Deltares zal haar dataservices upgraden naar hetzelfde metadata niveau inhet project.

3.2 StandaardisatieIMARES 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 naarWoRMS compleet. IMARES gebruikt niet het PMR-NCV datamodel, maar een eigendatamodel. IMARES kan hierdoor niet de Aquo mapping van het PMR-NCV datamodelhergebruiken, maar maakt een eigen mapping. Deze investering wordt kleiner geschat dande investering om naar het PMR-NCV datamodel te mappen. De uiteindelijke datalevering isidentiek, dus voor de gebruikers is het om het even.

3.3 Mappingstabel en toolOp vrijdag 6 december 2013 is met personen van Ecosys, RWS, IMARES, MARIS, IHM, IHWen Deltares een werksessie gehouden om afspraken te maken over de te vullen velden tenbehoeve van metadata en velden ten behoeve van uitwisseling. Daarbij is sterk geleund ophet Uitwisselmodel Aquo (UM-Aquo). Tijdens deze sessie is afgesproken dat eenieder databeschikbaar stelt via een zogenaamde CSW service. Dit staat voor Catalogus Service voorhet Web, een standaard voor het beschikbaar stellen van een catalogus met beschrijvendeinformatie 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 naargeospatiële data en services te zoeken. De gebruiker van de data kan op basis van demetadata de geschiktheid en kwaliteit van data(-producten) beoordelen en vergelijken. DeCSW-service voldoet aan de eisen van het Nederlands profiel op ISO19115-2. Geonovum



14 van 21

levert uitputtende beschrijvingen van dit dialect op het internationale ISO19115-2metadataprofiel.

Voor de inhoud van de webservices is vooral gekeken naar de semantiek. Welke velden inwelke 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 Aquostandaarden ingelezen moet kunnen worden. Dit betekent dat aan de leverende kant vanuithet gehanteerde datamodel “iets” gedaan moet worden om dit te realiseren. Dan zijn erdiverse 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 optiegekozen. Het huidige datamodel (en dus de werkwijze) blijven ongewijzigd waardoor via eenmapping aanlevering volgens UM-Aquo gerealiseerd kan worden. Dat is een snelle actie dievolledig geautomatiseerd kan worden.

Per organisatie en mogelijk per project kan worden overwogen om een specifiek voor eenbepaald doeleinde ontworpen datamodel te maken, of een bestaand datamodel incl.geïmplementeerde mappings te hergebruiken. Echter de uitleverende partij dient volgens deafspraken een UM-Aquo comforme webservice aan te bieden.

3.4 Installatie serverMedio november 2013 heeft IMARES een server beschikbaar gesteld voor installatie van desoftware stack componenten. De server (scomp1184.wur.nl) is voorzien van het RedHatEnterprise Linux Server Operating System.Deltares heeft ter plekke geassisteerd bij de installatie en configuratie van de software stackcomponenten. 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 demetadata catalogus gegevens ook de PostgreSQL database benut i.p.v. deembedded, in-memory H2 database die na installatie van GeoNetwork bij verstekwordt toegepast.

Naar goede gewoonte staat de server scomp1184.wur.nl in een Demilitarized Zone (DMZ) dienaar de buitenwereld (www) enkel verkeer over poort 80 (http) toestaat. Om de services(GeoServer en GeoNetwork) die onder Apache Tomcat (poort 8080) draaien, bereikbaar temaken is een proxy opgezet met het open source product Squid dat Deltares ook in gebruikheeft.



3.5 TestAls test van de werking van de stack is de PostgreSQL database bij IMARES gevuld met eenexport van de PMR-database die bij Deltares staat. De aldus gerealiseerde en initieel gevuldeIMARES’ Spatiële Data Infrastructuur (SDI), bestaande uit de GeoServer installatie en deonderliggende PostgreSQL/PostGIS database, is vanuit een webbrowser bereikbaar. Op hetmoment 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&width=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=512&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 wordenaangeboden op te vragen (resultaat in XML-formaat):

http://scomp1184.wur.nl/geoserver/pmr/wms?service=WMS&version=1.1.0&request=GetCapabilities



16 van 21

Hoewel de GeoNetwork CSW installatie in deze fase van het project nog niet striktnoodzakelijk 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 marieneprojecten”.

3.6 Toelichting kenmerken gemeenschappelijke databaseBesloten is geen gemeenschappelijk datamodel te ontwikkelen; IMARES houdt zijn eigendatamodel, omdat dat beter is afgestemd op de interne vragen.Dit betekent wel dat IMARES zelf een ETL van de interne database naar de externbenaderbare database moet verzorgen om van daaruit via de Deltares OpenEarth stack datate 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 wordtovergenomen, maar wordt vervangen door de originele IMARES database. Kwaliteitscontroleen versiebeheer zijn hierdoor minder traceerbaar en transparant.

3.7 Protocol mariene dataHet Protocol verschaft duidelijkheid over rollen, taken en verantwoordelijkheden. De uitkomstvan de werksessie is een noodzakelijke aanvulling op het bestaande document, onder meerten aanzien van de minimaal aan te leveren velden ten behoeve van een correcte encomplete uitwisseling. Speciale aandacht zou nog gegeven kunnen worden aan de catalogus.Het protocol biedt momenteel onvoldoende inzicht in wat er geïmplementeerd moet wordenom aan het protocol te voldoen. Een verwijzing naar de validatiefuncties van NGR (NationaalGeoregister) zou al een goede aanvulling zijn.



Het Protocol mariene data heeft hiermee aangeven een belangrijk trede te zijn in het latenconvergeren van partijen en standaarden in het veld van de mariene data. Met het inpassenvan de noodzakelijke aanvullingen volgend uit de werksessie zal het protocol de volgendetrede zijn in het convergentieproces. Het is zaak voor de toekomst om de juiste balans tevinden in het vastleggen van afspraken voor de nabije toekomst enerzijds, en het meegroeienin het convergentieproces op langere termijn anderzijds. Er zal moeten blijken wat een goedeupdate frequentie is, jaarlijks, twee-jaarlijks? De organisatie achter het protocol, een aantalpartijen die samen (i.p.v. top-down) de piketpaaltjes uitzetten en er samen aan werken om dieop 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 grotestappen gezet. De hands-on-aanpak van dit project enerzijds in combinatie met breed overleganderzijds is ons inziens de succesfactor. Na 1 kick-off meeting van een halve dag zijn deexperts meteen hands-on aan de slag gegaan zonder eerst alles uitentreuren in detail tewillen plannen. Het projectbudget is direct omgezet in werkende technologie, in plaats vanalleen een ontwerp op papier. De combinatie van specialisten op gebied van mariene biologie(taxonomie), database experts, webservice experts en voldoende brede projectleidershebben hiertoe geleid. Deze zogenaamde agile aanpak wordt in de software wereld steedsvaker gehanteerd: in kleine iteratieve stapjes doorwerken, met evaluatie en bijsturen naiedere 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 softwareontwikkeling. Dit project vraagt daarom nu een gedegen evaluatie, resulterend in hetformuleren van een volgende sprint. Voor het evalueren is een aantal richtingsverkenningenmogelijk.

Een openstaand punt is om de door Deltares en IMARES opgeleverde web ontsluitinggrondig te testen wat betreft aansluiting op een catalogus. Een centrale catalogus zoals dievan IHM of de RWS DDL zou de beide databases helemaal leeg moeten vragen om tebeoordelen of de data en mapping compleet zijn, en of de web ontsluiting een goedeperformance heeft. IMARES en Deltares zouden ook elkaars services kunnen bevragen alsofhet hun eigen services zijn. Ook zouden hier ‘sparring’ partners buiten het veld van marienedata gezocht kunnen worden om zaken mee te testen, zoals NGR en 3TU Datacenter enVLIZ.Het draagvlak voor de gezamenlijke aanpak kan verder vergroot worden door het aantaldeelnemende 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 deDeltares OpenEarth software stack op de RWS datadistributielaag (DDL). Er dreigt echtervertraging op te treden in de realisatie van de DDL, waardoor het niet zeker is dat hetministerie van IenM tijdig invulling kan geven aan haar beleid om per 1 januari 2015 haar dataopen beschikbaar te stellen. De Deltares stack is door het gebruik van WFS evenwel flexibelgenoeg om rechtstreeks te leveren aan een portal zoals bijvoorbeeld het IHM voor ogenheeft.De resultaten van het huidige project zullen worden benut in het project Datamanagementmariene monitoring (1208604) dat RWS aan Deltares gegund heeft. De uitbreiding op demetadata zullen worden geïmplementeerd in de OpenEarth stack. Ze zullen zodoendedoorwerken 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 heeftals nadeel dat het overzicht voor de deelnemende partijen vermindert. Zo is de inbreng vanIBM (hoe beoordeelt een professioneel ICT-bedrijf de OpenEarth aanpak?) voor dedeelnemende partijen geheel buiten beeld gebleven.De aanpassingscyclus van het Protocol mariene data verdient nadere aandacht. Een eersteslag is om de aanpassingen uit de workshop te incorporeren en in de volgende versie van hetProtocol te publiceren.

digitale delta use case mariene monitoringpublications.deltares.nl/1208589_000.pdf · gebruikte...

Documents