Kustviewer in beheer name planpublications.deltares.nl/1209381_008b.pdf · kustviewer, maar ook...

Kustviewer in beheer name plan

Verkennen in beheer name Kustviewer.

Fedor Baart (Deltares),Kees den Heijer (Deltares),Anna van Gils (Deltares),Fredrik Gevers Deynoot (Nelen en Schuurmans)

1209381.008

Deltares, 2015

ii

DeltaresTitelKustviewer in beheer name plan

OpdrachtgeverRijkswaterstaat

Project1209381.008

Kenmerk1209381 -008-ZKS-OOO 1

Pagina's35

TrefwoordenKustviewer

SamenvattingDit document beschrijft hoe de kustviewer in beheer genomen kan worden door Rijkswaterstaat(RWS). De kustviewer bestaat uit drie hoofddelen een database, een server en een client.

De database waarin de opgewerkte kustgevevens staan kan met relatief weinig inspanning (updatevan bouwstenen catalogus en uitbreiding met 1 database type) in beheer genomen worden. Deserver is geprogrammeerd in een programmeertaal python die niet in de bouwsteen catalogus staat.We adviseren om python aan de catalogus toe te voegen om aansluiting te vinden bij de ingenieurs, gis en wetenschappelijke software ontwikkelpraktijk. Het client gedeelte van de kustviewer moetherzien worden omdat de plugin die gebruikt wordt als kaart component binnenkort niet meer werkt.Er is op dit moment geen alternatieve kaartcomponent met vergelijkbare functionaliteit beschikbaar.We adviseren de vervanging van de kaartcomponent halverwege volgend jaar te heroverwegen,wanneer de alternatieven verder doorontwikkeld zijn, en tijdelijk met de desktop versie van GoogleEarth te werken. Gebruikers buiten RWS kunnen met de juiste browser de huidige kustviewer toteind 2015 blijven gebruiken.

Om de applicatie in beheer te nemen moeten een aantal rollen ingevuld worden die de werkwijzevan RWS ondersteunen. Daarnaast kan nu al een aantal verbeteringen worden doorgevoerd (informatie beveiliging, automatisch testen, maken testplan) die de overdracht van beheer makkelijkermaken.

Het is op dit moment nog niet mogelijk om op Landelijke Opslag Lodingen (LOL) aan te sluitenomdat LOL en de beschrijving van het toegangsprotocol niet publiek beschikbaar zijn. De datain de kustviewer voldoet aan de open data eisen, daarom kan de kustviewer publiek beschikbaargemaakt worden, met als doelgroep specialistische gebruikers.

Referenties

Versie Datum Auteur Paraaf Review Paraaf Goedkeuring Paraaf

0.1 2014-12-31 FedorBaart Gemma Raaijma-kers

2015-2-23 Fedor Baart Gerrit Hendriksen ~ Dirk Jan Walstra

iii

Status

Definitief

iv

Inhoudsopgave

1 Inleiding 11.1 Bouwstenen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Huisstijl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Beheer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Gegevens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Bouwstenen 32.1 De database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.1 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Kaart component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 Alternatieven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6 Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.6.1 Arcgis Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6.2 City Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6.3 Cesium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6.4 Mapbox gl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.6.5 OpenLayers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.6.6 f4map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.6.7 Leaflet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.6.8 Adaguc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.6.9 Google maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.6.10 GeoWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.6.11 Arcgis Online 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.7 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.8 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Huisstijl 133.1 Corporate huisstijl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Webrichtlijnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.1 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.2 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.3 Principe universeel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.4 Principe waarneembaar . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.5 Principe bedienbaar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.6 Principe begrijpelijk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.7 Principe robuust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Beheer 194.1 Beheersbaar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.1 Rollen en risico’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.2 Opleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.3 Communicatie eindgebruikers . . . . . . . . . . . . . . . . . . . . . . . 204.1.4 Werkproces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

v

4.2 Testbaar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3 Overdraagbaar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.4 Betaalbaar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 Gegevens 255.1 Aansluiting op toekomstige wijziging in de distributielaag . . . . . . . . . . . . . 25

5.1.1 Beschikbaarheid distributielaag . . . . . . . . . . . . . . . . . . . . . . 255.1.2 Eisen aan distributielaag . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2 Open Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.2.1 Rechten derden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.2.2 Concurrentievervalsing . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2.3 Verwachtingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3 Advies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6 Adviezen 296.1 Scenario’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.1.1 RWS als beheerder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.1.2 Deltares als beheerder . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.1.3 Kustviewer herverdelen . . . . . . . . . . . . . . . . . . . . . . . . . . 316.1.4 Kosten en risico’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.2 Overige adviezen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7 Literatuur 33

vi

Lijst van figuren

2.1 Populariteit programmeertalen (aantal commits) in open source projecten overlaatste 10 jaar (bron: openhub.net) . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.1 Voorbeeld van raai-tijd combinaties . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

vii

Lijst van tabellen

ix

1 Inleiding

De kustviewer is in 2009 ontwikkeld om snel kustdata in kaart te brengen en te visualiseren. Debasis is gelegd in het afstudeerwerk van Thijs Damsma (Damsma et al., 2009)en de promotievan Fedor Baart (Baart, 2013). In 2012 is de viewer ondergebracht in het Lizard platform vanNelen en Schuurmans en samen met RWS verder ontwikkeld (Santinelli et al., 2013). De viewerpast in het streven om het consumeren van data van de Nederlandse kust net zo makkelijk temaken als een filmpje op youtube te bekijken (De Boer et al., 2012)

Deze verkenning beschrijft mogelijke aanpassingen aan de kustviewer. Deze aanpassingen heb-ben als doel het beheer over te dragen naar RWS. De aanpassingen die gedaan kunnen wordenhebben we opgesplitst in de techniek (Hoofdstuk 2), de vorm (Hoofdstuk 3), het beheer proces(Hoofdstuk 4) en de gegevens (Hoofdstuk 5). Hierbij worden de volgende vragen beantwoord:

1.1 BouwstenenAansluiten op de bouwstenen van RWS: Aangeven in hoeverre de huidige kustviewer voldoet aande vereisten uit de zogenaamde bouwstenencatalogus. Tevens aangeven welke mogelijkhedener zijn in het kader van de Project Start Architectuur (PSA) OpenEarth Tools (OET) stack diedoor Centrale Informatievoorziening (CIV) (Flip Dirksen), Deltares (Gerard van der Kolff, GerritHendriksen, Fedor Baart) en en Water, Verkeer en Leefomgeving (WVL) (Ingeborg van Splunder)is opgesteld. Bij dit onderdeel wordt bekeken of de bevindingen ook gelden voor andere Lizardviewers zoals het Delta Portaal. Welke onderdelen passen, en op welke onderdelen wijkt dekustviewer af?

Vanuit RWS is het verzoek gekomen om een kustviewer op te leveren die gegarandeerd com-patibel is met het RWS bouwstenen systeem. Welke aanpassing zijn haalbaar en wat vraagtdit voor inspanning? Hierbij moeten ook de requirements voor 2015 tegen het licht houdenmet betrekking tot Informatie- en Communicatie Technologie (ICT) eisen vanuit de Service LevelAgreement (SLA).

Een kenmerk van de kustviewer is dat deze gebruik maakt van 3 dimensionale animaties in detijd. Deze is gebaseerd op een browser plugin. Vanaf 2015 wordt het gebruik van plugins in hetalgemeen en de plugin die gebruikt wordt voor de kustviewer niet meer ondersteund. Daaromwordt een aantal alternatieven onderzocht.

1.2 HuisstijlAansluiten op de huisstijl van RWS: Plan van aanpak maken voor aanpassen kustviewer. Voorzover mogelijk wordt binnen de beschikbare mandagen al een start gemaakt met het aanpassen.Uitgangspunt is, indien dit efficiënt is, een generiek product te maken dat niet alleen voor dekustviewer, maar ook voor andere Lizard-producten (zoals Delta portaal) en zo mogelijk ookvoor andere viewers (die voor RWS ontwikkeld worden) bruikbaar is. De Richtlijnen voor web-weergave (Corporate dienst) worden gebruikt voor websites die bij RWS onder beheer zijn.

Kustviewer in beheer name plan 1 van 35

1209381-008-ZKS-0001, Definitief, 27 februari 2015

1.3 BeheerAansluiten op de in beheername procedure van RWS: Op basis van de beschikbare checklijstvan RWS wordt in beeld gebracht welke stappen genomen moeten worden om de kustviewergeschikt te maken voor ‘in beheername’ door RWS. Voor zover mogelijk wordt binnen de be-schikbare mandagen al een start gemaakt met de benodigde aanpassingen.

1.4 GegevensAansluiten op toekomstige wijziging in de distributielaag: Er wordt een eerste check uitgevoerd ofde kustviewer rechtstreeks data uit LOL kan inlezen. De gegevens die in de kustviewer wordengebruikt worden geput uit de OpenEarth dataset 1. Dit is een opgewerkte vorm van de RWS da-taset. RWS maakt steeds meer datasets publiek toegankelijk. Een van de datasets die gebruiktwordt is de “Vaklodingen” (diepte metingen). Deze wordt beschikbaar gemaakt onder de naamLOL. Inzichtelijk maken in de verkenning wat er nodig is voor het overstappen op LOL als databron. Tevens speelt de vraag of de kustviewer open mag zijn. Hiervoor wordt de checklist “Opendata” toegepast.

1http://opendap.deltares.nl

2 van 35 Kustviewer in beheer name plan

http://opendap.deltares.nl

2 Bouwstenen

Dit hoofdstuk beschrijft in hoeverre de kustviewer op de bouwstenen van RWS voldoet aan debouwstenencatalogus (Engels et al., 2012). Welke onderdelen passen, en op welke onderdelenwijkt de kustviewer af? Er wordt aangegeven welke mogelijkheden er zijn om de Lizard viewers(Kustviewer, Delta Portaal) aan kunnen sluiten bij de OET stack. Hoe kan de kustviewer wordenaangepast zodat deze compatibel is met het RWS bouwstenen systeem? Welke aanpassingzijn haalbaar en wat vraagt dit voor inspanning? Hierbij moeten ook de requirements voor 2015tegen het licht houden met betrekking tot ICT eisen vanuit de SLA.

De kustviewer bestaat uit drie onderdelen, een database, een server en een client. We be-schrijven van elk van deze onderdelen hoe deze aansluiten op de bouwstenen catalogus. Inonderstaande overzichten zitten schuingedrukte onderdelen zitten in de bouwstenen catalogusversie 2.9.10 van 19 juni 2012.

2.1 De databaseDe database omvat alle opgewerkte kustgegevens. De gegevens zijn opgeslagen in een meerdi-mensionale database omdat kustgegevens doorgaans meerdere dimensies bevatten (tijd, ruimte,raaien, hoeken, lagen, frequenties). Ze laten zich daardoor het beste beschrijven in een data-structuur gebaseerd op arrays. De technische componenten die gebruikt worden zijn :

⋄ THREDDS Data Server (THREDDS), applicatie, OPeNDAP protocol. Multidimensionaledatabase. Geeft toegang tot netCDF files via het internet.

⋄ Tomcat, applicatie server. Draait THREDDS applicatie.

⋄ Apache, webserver. Zorgt voor authenticatie, logging en beveiliging van Tomcat.

⋄ CentOS, besturingssysteem.

2.1.1 EvaluatieDe volgende aanpassingen zijn nodig om de applicatie onder RWS bouwstenen te laten passen.

De THREDDS applicatie zou vervangen kunnen worden door een andere applicatie die hetOPeNDAP protocol ondersteunt. Geen van deze applicaties staat in de bouwstenen catalo-gus. De gegevens kunnen met moeite en met performance verlies in een relationele en rastergebaseerde opslag gepast kunnen worden. Omdat het OPeNDAP protocol inmiddels tot OpenGeospatial Consortium (OGC) standaard is verheven en het een de facto standaard voor modelresultaten en multidimensionale gegevens is geworden is het wenselijker als dit protocol toege-voegd wordt aan de ondersteunde protocollen van de bouwstenen catalogus.

Als applicatie server wordt binnen de bouwstenen catalogus alleen JBOSS aangeboden in com-binatie met java 6 (uit 2006). De applicatie THREDDS is zowel incompatibel met java 6 als metJBOSS.

Support voor Java 6 is door Oracle, de leverancier van Java, beëindigd op februari 2013, het isniet aan te raden Java 6 servers te blijven gebruiken omdat dit onveilig is. Updaten naar Java 7



is niet meer handig omdat support hiervoor ook eindigt per april 2015 1. De meest logische optieis te updaten naar de huidige versie Java 8 (einde updates gepland per maart 2017).

De applicatie THREDDS wordt niet ondersteund voor JBOSS Enterprise Application Platform(EAP), maar alleen voor Tomcat. JBOSS EAP omvat een Tomcat deployer (web container) diegebruikt zou kunnen worden. Hiervoor is waarschijnlijk wel een nieuwere versie van JBOSSEAP nodig dan in de bouwstenen catalogus staat. Dit is niet meer te controleren omdat dedocumentatie van JBOSS AS 5.x inmiddels niet meer online staat. De bouwstenen catalogus zalmoeten worden geupdate naar een Tomcat 7 compatibele versie van JBOSS.

De webserver wordt ondersteund. Deze zal wel moeten worden geconfigureerd voor het aanbie-den van de data via OPeNDAP protocol (ondersteuning grote responses, beveiliging configura-tie). Hiervoor kan Deltares ondersteuning verlenen (2 dagen).

De applicatie draait nu binnen CentOS 6.x. Dit is de vrije versie, zonder ondersteuning en tech-nisch equivalent aan Red Hat 6.x. Red Hat 6.x laatste wordt ondersteund door de bouwstenencatalogus en wordt compleet ondersteund tot 2016. Het testen van deze configuratie vereist eenextra Redhat licentie binnen Deltares (1 dag + ongeveer EUR 2000/jaar voor test en ontwikkel-machine, elka jaar).

Daarnaast moet worden gecontroleerd worden of er geen gebruik wordt gemaakt van pakkettenuit de Extra Packages for Enterprise Linux (EPEL) distributie, die niet in de bouwstenen catalogusstaat (1 Dag). Overnemen van support van pakketten uit de EPEL verschilt per pakket en ismoeilijk in te schatten, dat laten we open. Het opnemen van de CentOS distributie en de EPELpakketten in de catalogus voorkomt deze kosten, maar vereist beheerders met meer kennis enoplossingsvermogen.

2.1.2 Advies

⋄ Thredds, of andere OPeNDAP implementatie: opnemen in bouwstenen catalogus

⋄ Tomcat, Update bouwstenen catalogus naar recente java versie. Update bouwstenen ca-talogus naar recente JBOSS versie.

⋄ Apache, webserver. Configuratie (2 dagen Deltares).

⋄ CentOS, overstappen naar Redhat besturingssysteem (2 dagen Deltares + EUR2000/jaar)

2.2 ServerDe server raadpleegt de database met kustgegevens en geeft grafieken, animaties en indicatorenterug.

De technische componenten die gebruikt worden zijn :

⋄ Lizard kml, de applicatie die grafieken en Keyhole Markup Language (KML) bestandengenereert.

⋄ Python, de programmeertaal

1http://www.oracle.com/technetwork/java/eol-135779.html


http://www.oracle.com/technetwork/java/eol-135779.html


Figuur 2.1: Populariteit programmeertalen (aantal commits) in open source projecten overlaatste 10 jaar (bron: openhub.net)

⋄ Python pakketten, webapplicatie, diverse bibliotheken om te plotten en te rekenen.

⋄ Postgis, database met gebruikers en configuratie van kaartlagen.

⋄ Ubuntu, besturingssysteem.

Geen van de technische componenten die worden gebruikt is beschikbaar in de bouwstenencatalogus. De lizard kml applicatie is gemaakt in python op basis van het WSGI protocol endiverse python bibliotheken. Binnen de bouwstenen catalogus worden alleen de talen java, c#en php ondersteund.

Het herschrijven van lizard-kml in een andere taal zou een optie kunnen zijn. De functionaliteitvan de applicatie is redelijk beperkt waardoor het herschrijven in ieder geval een overzichtelijkeinspanning is. Wel zijn er een aantal praktische bezwaren.

Ten eerste de beschikbare ondersteuning. Java wordt ook ondersteund door Deltares voor serverapplicaties. C# wordt alleen gebruikt voor desktop applicaties door Deltares. De talen wordenniet ondersteund door Nelen en Schuurmans.

Daarnaast de beperkte mogelijkheden van de talen en bijbehorende infrastructuur. De imple-mentatie van de applicatie zal lastig blijken door het ontbreken van multidimensionale arrays incombinatie met slicing (C#, java, php), netCDF support (C#, php) en GIS (php). Python onder-steunt een evolutie van een eerste script naar een webapplicatie, hetgeen bij C# en java nietmogelijk is. Indien dit toch wenselijk is kan een offerte voor het herschrijven van de applicatie ineen van de ondersteunde talen worden opgesteld (opstellen offerte 10 dagen + implementatiekosten), er van uitgaand dat voor de offerte ook een lijst met functionaliteiten wordt opgesteld.

Overwegende dat ingenieurs bij de TUD worden opgeleid om met python te ontwikkelen en bijverschillende ingenieurs- en GIS bureaus python inmiddels de standaard programmeertaal is,adviseren we om python en bijbehorende infrastructuur in de bouwstenen catalogus op te nemen.

In het kader van de zandmotor is python toegevoegd aan de OET stack. We adviseren om dezeconfiguratie te gebruiken om python en het framework te ondersteunen.



Daarnaast wordt gebruik gemaakt van de Postgis database die niet in de bouwstenen staat. Dezestaat op de lijst om toegevoegd te worden. De planning hierover is niet openbaar beschikbaar.

De Ubuntu distributie is een populaire distributie. Deze zou toegevoegd kunnen worden, maardat vergt extra kennis bij de beheerders. Door de OET stack te gebruiken kan van Ubuntuovergestapt worden naar Redhat.

De huidige ontwikkeling in de linux wereld is dat applicaties via containers worden uitgeleverd.Het is verstandiger om tijd te stoppen in het toevoegen van containers aan de bouwstenen catalo-gus. Daarmee kunnen applicaties zoals de kustviewer eenvoudig worden toegevoegd, ongeachtde distributie waar ze op draaien.

2.2.1 AdviesWe adviseren om de applicatie niet te herschrijven maar om de componenten waarop deze isgebouwd toe te voegen aan de catalogus. Waarschijnlijk zal het even duren tot deze bouwstenenzijn toegevoegd aan de catalogus. Tot die tijd adviseren we om dit deel van de applicatie inbeheer te houden bij een externe partij.

⋄ Lizard kml, toevoegen aan OET stack (2 dagen, onderhoud 1 dag per release)

⋄ Python, toevoegen aan OET stack (reeds beschikbaar, onderhoud 0.5 dag per release,open source software, geen licentiekosten)

⋄ Python pakketten, toevoegen aan OET stack (2 dagen per webapplicatie, onderhoud 0.5dag per release, open source software, geen licentiekosten)

⋄ Postgresql/Postgis, toevoegen aan catalogus (actie RWS, open source software, geen li-centiekosten)

⋄ Ubuntu, vervangen door Redhat (actie RWS, open source software, geen licentie kosten)

⋄ Containers, toevoegen aan catalogus (gedetailleerd advies 3 dagen) (actie RWS, opensource software, geen licentiekosten)

2.3 ClientDe client van de kustviewer draait in een browser. De browser ontvangt web pagina’s, javascript,plots en kml bestanden van de webserver en zet deze om in de interface die de gebruiker te zienkrijgt. Als browsers zijn binnen RWS de volgende applicaties beschikbaar Firefox en InternetExplorer (Producten & Diensten Catalogus IRN versie 0.9). De versies zijn niet gespecificeerd.Op dit moment is de Google Earth plugin niet meer beschikbaar via RWS. Hierdoor kan dekustviewer niet meer worden bekeken binnen RWS.

⋄ Webbrowser, visualiseert html, stylesheets en draait javascript code.

⋄ Google Earth Plugin, animeert KML bestanden

De methode van plugins zoals deze nu door de kustviewer wordt gebruikt is door de browserfabrikanten als verouderd bestempeld. Hieronder staan de standpunten van Google, Mozilla en



Microsoft weergegeven. Uit deze standpunten blijkt duidelijk ingebouwde plugins in websites inte toekomst niet meer beschikbaar zullen zijn.

Mozilla:

Plugins are now a legacy technology. They are not available on most mobiledevices. Mozilla encourages website developers to avoid using plugins whereverpossible. If there are plugin features which are not available in the web platform, weencourage developers to post their use cases to mozilla.dev.platform project list, sothat Mozilla can prioritize web platform work to make those use cases possible. 2

Microsoft:

For optimal future proofing and browser compatibility, it’s best to develop your siteentirely without using plug-ins. In some cases, however, it might not be possible for awebsite or web app to work completely without plug-ins. In these instances, there aresome fallback techniques and mitigation strategies you can follow to ensure the bestpossible experience for users of Internet Explorer 10 and other plug-in free browsers.3

Google standpunt:

Google chrome plans to disable all plugins (silverlight, java, google earth) per 1january 2015. 4

Daarnaast is relevant dat Google de Google Earth plugin niet meer ondersteunt per 12 december2015.

Therefore, after careful consideration, we have decided to retire the Google EarthAPI. Per our deprecation policy, the API will be supported until one year from todayand will be turned off on December 12, 2015. 5

Dat betekent dat het huidige client deel van de kustviewer niet meer functioneert per 12 december2015. Microsoft Internet Explorer ondersteunt geen plugins meer vanaf versie 10.0, Chrome nietmeer vanaf de versie die januari 2015 wordt uitgebracht. Wanneer Firefox plugins uitschakeltstaat nog niet vast. Tot 12 december 2015 kan de kustviewer gebruikt worden met Google EarthPlugin in combinatie met firefox, tenzij Firefox eerder besluit plugins uit te schakelen of InternetExplorer kleiner dan versie 10.0.

Het is duidelijk dat het raadzaam is om de in de kustviewer gebruikte kaartcomponent te vervan-gen. Hetzelfde geldt voor andere applicaties die gebaseerd zijn op plugins (alle websites die zijn

2https://developer.mozilla.org/en-US/Add-ons/Plugins

3http://msdn.microsoft.com/en-us/library/ie/hh968248(v=vs.85).aspx

4http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html

5http://googlegeodevelopers.blogspot.com.au/2014/12/announcing-deprecation-of-google-earth.

html


https://developer.mozilla.org/en-US/Add-ons/Plugins

http://msdn.microsoft.com/en-us/library/ie/hh968248(v=vs.85).aspx

http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html

http://googlegeodevelopers.blogspot.com.au/2014/12/announcing-deprecation-of-google-earth.html

http://googlegeodevelopers.blogspot.com.au/2014/12/announcing-deprecation-of-google-earth.html


gebaseerd op flash, silverlight of java applets). In de volgende sectie evalueren we verschillendealternatieven voor de google earth plugin component.

De opvolger van de kaartcomponent zal gebaseerd moeten zijn op diverse technieken die inhtml5 beschikbaar zijn gekomen. In principe is de functionaliteit die een html5 compatibele brow-ser biedt voldoende om een 3d kaartcomponent, inclusief tijd, inclusief animatie, inclusief schaal-baarheid te realiseren.

De volgende onderdelen van html5 kunnen hier bij helpen met erachter de huidige ondersteuningin de diverse browsers. Veel van de functies zijn inmiddels in de meest gebruikte browsersbeschikbaar 6. Internet explorer ligt nog steeds achter, maar Microsoft heeft de intentie omde achterstand in te halen. Om met de nieuwe applicaties te kunnen werken is een recente,moderne browser vereist.

⋄ webgl, 3d weergave (ie11, firefox, chrome, ios)

⋄ webworkers, parallel taken verwerken (ie10, firefox, chrome, ios)

⋄ typed arrays, arrays met getallen (ie11, firefox, chrome, ios)

⋄ smil, tijdschronisatie (firefox, chrome, ios)

⋄ video, animaties (ie10, firefox, chrome, ios)

⋄ canvas blending, visualizatie (firefox, chrome, ios)

2.4 Kaart componentHet doel van dit rapport is om inzichtelijk te maken welke alternatieven er beschikbaar zijn voorde Google Earth Plugin die nu wordt gebruikt in de kustviewer van Rijkswaterstaat.

Om dit te onderzoeken zijn een aantal criteria vastgesteld waaraan een alternatief zou moetenvoldoen. Op basis van deze criteria zijn een aantal alternatieven onderzocht.

Voor het onderzoek naar een alternatief voor de kustviewer van Rijkswaterstaat is er gekekennaar 3 criteria waaraan het alternatief moet voldoen.

Tijd: In de kustviewer moeten datasets kunnen worden geladen met een tijd component. Eentweede belangrijke feature is dat er een begin- en eindtijd moet worden kunnen ingesteld.

3D: De data die in kustviewer wordt getoond is gedeeltelijk in 3D. Deze data moet kunnen wordengetoond in de kustviewer.

kml: De data in de kustviewer wordt op dit moment ingelezen via KML bestanden. Dit is hetenige gestandaardiseerde formaat waarmee zowel styling, linked data, Level of detail (LOD),tijdsintervallen en als relatieve hoogte gegevens kunnen worden gerepresenteerd.

6bron: http://caniuse.com


http://caniuse.com


2.5 AlternatievenDe volgende alternatieven voor de Google Earth Plugin zijn onderzocht.

⋄ arcgis explorer (propriëtair)

⋄ arcgis city Engine (propriëtair)

⋄ arcgis online 3d (propriëtair)

⋄ cesium (open source)

⋄ mapbox-gl (open source)

⋄ openlayers (open source)

⋄ f4map (propriëtair)

⋄ leaflet (open source)

⋄ adaguc (open source)

⋄ google maps (propriëtair)

⋄ GeoWeb (propriëtair)

2.6 ResultatenHieronder worden de resultaten van het onderzoek per alternatief besproken.

2.6.1 Arcgis ExplorerArcgis Explorer heeft op dit moment alleen nog een phone, tablet en desktop versie beschikbaar.De online versie is op 10 December 2013 gestopt 7.

2.6.2 City EngineCity Engine gebruikt een plugin vrije omgeving om een 3D scene te creëren in de browser. Hetis niet open source, en buiten de 30 dagen proefperiode moet ervoor betaald worden. Cityengine ondersteund wel 3D maar alleen op “scene” niveau. Het is niet mogelijk om de hele kustdynamisch in te laden. Het is niet mogelijk om een tijdsanimatie te maken. Van KML wordtslechts een deel van de functionaliteit ondersteund.

2.6.3 CesiumCesium is een open source javascript library voor het creëren van 3D en 2D kaart componentenin een web browser. Cesium maakt gebruik van HyperText Markup Language version 5 (HTML5)en WebGL! (WebGL!) . Cesium heeft een 3D en tijd component. Er is geen voorbeeld be-schikbaar waarin ook een tijd interval geselecteerd kan worden, maar de code laat zien dat ditwaarschijnlijk wel mogelijk is. Cesium kan op dit moment nog niet omgaan met het KML formaat,maar daar wordt op dit moment wel aan gewerkt. In de toekomst zal dit wel mogelijk zijn.

7http://www.esri.com/software/arcgis/explorer-online


http://www.esri.com/software/arcgis/explorer-online


2.6.4 Mapbox glMapbox gl is ook een open source javascript library. Er kunnen wel 3D componenten wordentoegevoegd, maar de kaart zelf is in 2D. Het is mogelijk om een tijd component toe te voegen,maar het is niet mogelijk om een tijd interval te selecteren. Mapbox gl ondersteund alleen eeneigen formaat bestandstype en kan niet overweg met KML files.

2.6.5 OpenLayersOpenlayers is ook een open source javascript library. Deze is ontwikkeld met Cesium (hierbovenbeschreven). Openlayers beschikt niet over over een 3D component en ook de tijd componentwordt niet ondersteund. Het KML bestandsformaat wordt wel ondersteund.

2.6.6 f4mapF4map heeft een 3D HTML5 component, vergelijkbaar met City Engine. De tijd component enKML worden niet ondersteund. Deze component is ontwikkeld voor de toeristen industrie.

2.6.7 LeafletLeaflet is een open source java library gericht op het maken van interactieve mobiel vriendelijkekaarten. Er is een 3D plugin beschikbaar, maar deze werkt via parallax effecten. Dat is vooralgeschikt om een bovenaanzicht een 3d illusie te geven. Tijd en het KML bestandsformaat zijnvia plugins beschikbaar.

2.6.8 AdagucAdaguc is een viewer die gebruikt wordt door het knmi. Deze viewer kan omgaan met een tijdcomponent, maar bevat geen 3D component en kan ook geen KML bestanden inlezen.

2.6.9 Google mapsGoogle maps is de laatste viewer die is onderzocht.Deze viewer heeft een goede 3D component zoals opde afbeelding hieronder te zien is. Google maps kan inde 3D alleen niet over weg met de tijd component enkan ook geen bestanden zoals KML weergeven.

2.6.10 GeoWebGeoWeb is een gezamenlijk product van Esri Nederlanden Grontmij. Deze software bevat geen 3D functionaliteit en is grotendeels gebaseerd op Sil-verlight, waardoor deze software ook grotendeels vervangen moet worden door een moderneralternatief.



2.6.11 Arcgis Online 3DIn December 2014 heeft ESRI nog een opvolger van Arcgis Explorer beschikbaar gemaakt. Ditis een 3D kaart component op basis van HTML5. Tijd lijkt niet ondersteund te worden, alleenstatische kaarten. Er zit wel een 3D terrein model in.

Figuur 2.2

Deze component is in zijn huidige vorm niet bruikbaar.De functionaliteit is beperkt. De interface zoomt knulligin en uit en de overgangen tussen satelliet en luchtfoto’sloopt niet soepel. Het is wel te verwachten dat er, zekerdoor het wegvallen van de Google Earth plugin, doorESRI tijd en geld in gestopt wordt om deze toepassingbruikbaar te maken.

2.7 AdviesEr kan worden geconcludeerd dat er op dit momentgeen alternatief is voor de kustviewer die voldoet aande 3 criteria waarnaar is gekeken. Cesium voldoet hetbest aan de gestelde criteria. Alleen KML bestanden kunnen in deze viewer niet worden gela-den. Op het moment zijn er ontwikkelingen gaande op dit gebied en verwacht wordt dat dit in detoekomst wel mogelijk zal zijn.

Het logische advies zou zijn om af te wachten en de ontwikkeling van in ieder geval Cesium enGoogle Maps te volgen. Omdat de kustviewer op dit moment niet meer werkt binnen RWS enbinnen een jaar nergens meer, adviseren we om de in overgang van de kustviewer tijdelijk tesplitsen. De 3D en tijd, gebaseerde visualizaties kunnen op dit moment niet worden onderge-bracht in een andere component omdat er geen kant en klare component voor beschikbaar is.Daarom adviseren voor dit deel gebruik te maken van Google Earth (Desktop). We realiserenons dat deze niet meer beschikbaar is binnen RWS, maar een alternatief is er niet.

Het uitfaseren van de client componenten die gebruikt worden is typerend voor viewers. Webapplicaties worden doorgaans ontwikkeld op basis van diverse componenten. De uitfasering vandergelijke componenten kan snel gaan. Zo adverteert Microsoft Silverlight vandaag nog metde tekst: “bringing a new level of interactivity wherever the Web works.” terwijl het in InternetExplorer 10 en in Chrome niet meer wordt ondersteund. Esri gaf gebruikers van Arcgis ExplorerOnline 3 maanden om over te stappen 8. De uitfasering van de Google Earth plugin binnen eenjaar is hier een ander voorbeeld van.

Gegeven deze volatiliteit is het raadzaam om te overwegen of het op dit moment opportuun isom het beheer van viewers binnen RWS te trekken. In ieder geval moet men er op bedacht zijndat de halfwaarde tijd van viewers, zeker de technisch complexere viewers, eerder in de orde vanmaanden ligt dan jaren. De huidige ontwikkelsnelheid die nodig is om in te spelen op dergelijkeveranderingen sluit niet aan bij de beheeromgeving van RWS. We raden daarom af om viewerszoals de kustviewer bij RWS in beheer te nemen.

⋄ Creëer een netwerk link waarmee in Google Earth (de desktop versie) de huidige visuali-saties van de kustviewer bekeken kunnen worden (3 dagen).

8http://blogs.esri.com/esri/arcgis/2013/11/22/arcgis-online-update-coming-december-10-2013/


http://blogs.esri.com/esri/arcgis/2013/11/22/arcgis-online-update-coming-december-10-2013/


⋄ Voeg Google Earth (de desktop versie) (als uitzondering, tijdelijk) toe aan de ProductenCatalogus van RWS.

⋄ Plan A: Evalueer halverwege 2015 nog een keer (een subset van) de bovenstaande com-ponenten. Hieruit kan of blijken dat er inmiddels een vervanger beschikbaar is van dekaartcomponent, dan kan deze vervangen worden (10 dagen).

⋄ Plan B: Mocht bovenstaand punt niet haalbaar zijn, neem een deel van de functionaliteitover, met name de functionaliteit die past in andere kaart componenten. Ontwerp eennieuwe presentatie vorm voor de ontbrekende informatie. (totaal 20 dagen)

2.8 ConclusieOm de viewer in beheer te nemen raden we het volgende pad aan.

1 Database in beheer. Dit sluit aan bij de activiteiten op het gebied van de aansluiting vande distributie laag op de OET stack. We stellen voor om de dataset die door de kustviewerwordt gebruikt mee te nemen in de activiteiten op dit thema in 2015 (o.a. KPP B&O kust).

2 Server in beheer. Hiervoor dient eerst de bouwstenen catalogus in overeenstemming ge-bracht te worden met actuele programmeertalen (proces binnen RWS voor 2015).

3 Client in beheer. Hiervoor dient eerst een beheerbare basis te ontstaan voor viewers zoalsde kustviewer. Hierop aansluitend staan hierboven een plan A en B.


3 Huisstijl

3.1 Corporate huisstijlOp dit moment heeft de kustviewer een relatief merkloos voorkomen. De hoofdpagina 1 gebruiktgeen beeldmerken. De url valt onder het lizard domein.

De viewer pagina 2 kent wel een aantal beeldmerken. Op deze pagina zijn het overheidslogoklein, deltares beeldmerk en OpenEarth logo te vinden. Door deze beeldmerken te gebruiken,maar niet de huisstijl sluit de pagina bij geen van de organisaties/producten aan qua huisstijl.

Bij het in beheer nemen van de viewer door Rijkswaterstaat past ook het aanpassen aan dehuisstijl van de overheid. Dat komt er op neer dat de richtlijnen van de rijks huisstijl wordengevolgd 3.

De aanpassingen bestaan uit de volgende onderdelen:

1 Logo en header, makkelijk aanpasbaar (1 dag), herbruikbaar tussen websites

2 Flexibel basisgrid, moeilijker aanpasbaar (3 dagen), niet herbruikbaar tussen websites

3 Online kleuren, makkelijk aanpasbaar (1 dag), herbruikbaar tussen websites

4 Webfonts, makkelijk aanpasbaar (1 dag), herbruikbaar tussen websites

5 Iconen, niet aanpasbaar (hangt af van framework dat gebruik wordt, niet consistent tussenwebsites)

6 Favicon, makkelijk aanpasbaar (0 dagen), herbruikbaar tussen websites

3.2 WebrichtlijnenDe webrichtlijnen gaan over het ontwerpen, bouwen en beheren van websites. Ze zijn gebaseerdop internationale standaarden voor kwaliteit en toegankelijkheid (WCAG). Het volgen van dezeaanbevelingen maakt content bruikbaar en toegankelijker voor meer mensen. Denk bijvoorbeeldaan (kleuren-)blinden, doven, mensen met dyslexie en mensen die de Nederlandse taal mindergoed machtig zijn.

De kustviewer is gestart als een klein onderzoeksproject: met een zeer beperkt budget werd eenproof of concept ontwikkeld. Aangetoond werd dat kustdata op een visueel aantrekkelijke manierkan worden ontsloten in een browser door gebruik te maken van Deltares’ OpenEarth databaseen de Google Earth plug-in. Het voldoen aan de webrichtlijnen had geen speciale aandacht.

De Rijksoverheid heeft zich verplicht de webrichtlijnen toe te passen en te handhaven. Nelen &Schuurmans en Deltares zijn gevraagd om te inventariseren of de Kustviewer aan de webrichtlij-nen kan gaan voldoen en welke inspanningen daarmee gemoeid zijn.

1http://kustviewer.lizard.net

2http://kustviewer.lizard.net/kml/

3http://www.rijkshuisstijl.nl/huisstijldragers/algemene-online-richtlijnen


http://kustviewer.lizard.net

http://kustviewer.lizard.net/kml/

http://www.rijkshuisstijl.nl/huisstijldragers/algemene-online-richtlijnen


Met ingang van 2015 stopt ondersteuning voor Webrichtlijnen versie 1. Het ligt daarom voorde hand om ons te baseren op versie 2. Deze kent verschillende niveaus van conformiteit, dieworden aangeduid met niveau A (laagst), AA, en AAA (hoogst). ‘Voldoen aan de Webrichtlijnen’staat gelijk aan het behalen van niveau AA.

3.2.1 EvaluatieDe norm is opgebouwd uit 5 principes, met onder elk principe een aantal richtlijnen, die op hunbeurt weer verschillende succescriteria hebben.

In dit document is per principe een matrix opgenomen met daarin de bindende richtlijnen, suc-cescriteria en niveaus van conformiteit. Op basis van kennis van de applicatie en steekproeven,is per richtlijn aangeven in welke mate de applicatie gebouwd is conform de betreffende richtlijn.Daar waar nodig is een toelichting of onderbouwing opgenomen.

De score van conformiteit is als volgt:

- voldoet niet (vereist een grote inspanning)

± voldoet enigszins (vereist een kleine inspanning)

+ voldoet wel

NA not applicable (niet van toepassing)

? onbekend

3.2.2 Links

1 http://kustviewer.lizard.net/

2 https://publicwiki.deltares.nl/

3 http://standaarden.overheid.nl

4 http://www.webrichtlijnen.nl

5 http://www.w3.org/WAI/intro/wcag

3.2.3 Principe universeel

Richtlijn U.1 Semantisch: Pas technologieën voor web-content op betekenisvolle wijze toe

Conf.niv.

Score

U.1.1 Semantisch correcte opmaak: A ±U.1.2 Geen afgekeurde en afgeraden eigenschappen: A ±U.1.3 Kopregelhiërarchie: A ±Richtlijn U.2 Gescheiden: Scheid content van presentatieen van gedragU.2.1 Scheiding van content en presentatie: A +U.2.2 Scheiding van content en gedrag: AA ±


http://kustviewer.lizard.net/

https://publicwiki.deltares.nl/

http://standaarden.overheid.nl

http://www.webrichtlijnen.nl

http://www.w3.org/WAI/intro/wcag


Richtlijn U.3 Bouw gelaagd: Borg de beschikbaarheid vanbasiscontent en -functionaliteitU.3.1 Gelaagd bouwen: A -

Richtlijn U.4 Foutmeldingen:U.4.1 Aangepaste foutmeldingen: A +Richtlijn U.5 Formulieren: Maak formulieren optimaalbruikbaarU.5.1 Ondersteuning bij formulieren: A +Richtlijn U.6 Meertaligheid: Maak anderstalige contenteenvoudig bereikbaar

U.6.1 Taalkeuze: A +Het mechanisme is reedsaanwezig, maar nog niet allecontent is vertaald.

Richtlijn U.7 Geneste weergavekaders: Sluit niemand uitbij het aanbieden van content middels geneste weergave-kaders

U.7.1 Alternatief voor geneste weergavekaders: AA NAGeen iframe e.d. wordt ge-bruikt.

Richtlijn U.8 Identificatie van tekens en symbolen: Speci-ficeer karaktercoderingU.8.1 Specificeer UTF-8: A +Richtlijn U.9 Openheid: Veroorzaak geen belemmeringenbij de creatie, publicatie en uitwisseling van content

U.9.1 Gebruik ten minste open specificaties: AA +

Naast HTML, CSS en Ja-vaScript wordt er ook ge-bruik gemaakt van de (open)Google Earth API.

Richtlijn U.10 URI’s: URI’s dienen duidelijk, uniek en duur-zaam te zijnU.10.1 Duidelijke URI’s: AA +U.10.2 Unieke en duurzame URI’s: AAA +U.10.3 Markeer dubbele content: AAA +

3.2.4 Principe waarneembaarRichtlijn 1.1 Tekstalternatieven: Lever tekstalternatievenvoor alle niet-tekstuele content, zodat die veranderd kanworden in andere vormen die mensen nodig hebben, zo-als grote letters, braille, spraak, symbolen of eenvoudigertaal

1.1.1 Niet-tekstuele content: A ± Voor content buiten de plug-in, anders -

Richtlijn 1.2 Op tijd gebaseerde media: Lever alternatie-ven voor op tijd gebaseerde media

1.2.1 Louter-geluid en louter-videobeeld (vooraf opgeno-men):

A -

De huidige simulaties zou-den gezien kunnen wordenals louter-videobeeld con-tent. Momenteel is hiervoorgeen alternatief voorhanden.



1.2.2 Ondertiteling voor doven en slechthorenden (voorafopgenomen):

A NA idem

1.2.3 Audiodescriptie of media-alternatief (vooraf opgeno-men):

A NA idem

1.2.4 Ondertitels voor doven en slechthorenden (live): AA NA idem1.2.5 Audiodescriptie (vooraf opgenomen): AA NA idem1.2.6 Gebarentaal (vooraf opgenomen): AAA NA idem1.2.7 Verlengde audiodescriptie (vooraf opgenomen): AAA NA idem1.2.8 Mediumalternatief (vooraf opgenomen): AAA NA idem1.2.9 Louter-geluid (live): AAA NA idemRichtlijn 1.3 Aanpasbaar: Creëer content die op ver-schillende manieren gepresenteerd kan worden (bijvoor-beeld eenvoudiger lay-out) zonder verlies van informatieof structuur

1.3.1 Info en relaties: A - Gebonden aan Google Earthplug-in

1.3.2 Betekenisvolle volgorde: A ?

1.3.3 Zintuiglijke eigenschappen: A - Gebonden aan Google Earthplug-in

Richtlijn 1.4 Onderscheidbaar: Maak het voor gebruikersgemakkelijker om content te horen en te zien, waaronderscheiding van voorgrond en achtergrond

1.4.1 Gebruik van kleur: A - Gebonden aan Google Earthplug-in

1.4.2 Geluidsbediening: A NA

1.4.3 Contrast (minimum): AA - Gebonden aan Google Earthplug-in

1.4.4 Herschalen van tekst: AA +

1.4.5 Afbeeldingen van tekst: AA NAGetoonde content is uitge-zonderd onder de noemer‘essentieel’

1.4.6 Contrast (versterkt): AAA - Gebonden aan Google Earthplug-in

1.4.7 Weinig of geen achtergrondgeluid: AAA NA1.4.8 Visuele weergave: AAA -

1.4.9 Afbeeldingen van tekst (geen uitzondering): AAA +

3.2.5 Principe bedienbaar

Richtlijn 2.1 Toetsenbordtoegankelijk: Maak alle functio-naliteit beschikbaar vanaf een toetsenbord

2.1.1 Toetsenbord: A ± Zie op de site ook opmerking2

2.1.2 Geen toetsenbordval: A ± Kustviewer is niet goed be-dienbaar met toetsenbord.

2.1.3 Toetsenbord (geen uitzondering): AAA +Richtlijn 2.2 Genoeg tijd: Geef gebruikers genoeg tijd omcontent te lezen en te gebruiken2.2.1 Timing aanpasbaar: A +2.2.2 Pauzeren, stoppen, verbergen: A +



2.2.3 Geen timing: AAA +2.2.4 Onderbrekingen: AAA +

2.2.5 Herauthentisering: AAA NAEr zijn geen transactioneleacties.

Richtlijn 2.3 Toevallen: Ontwerp content niet op een ma-nier waarvan bekend is dat die toevallen veroorzaakt2.3.1 Drie flitsen of beneden drempelwaarde: A +2.3.2 Drie flitsen: AAA +Richtlijn 2.4 Navigeerbaar: Lever manieren om gebruikerste helpen navigeren, content te vinden en te bepalen waarze zijn2.4.1 Blokken omzeilen: A NA2.4.2 Paginatitel: A +2.4.3 Focus volgorde: A +2.4.4 Linkdoel (in context): A +2.4.5 Meerdere manieren: AA NA2.4.6 Koppen en labels: AA +2.4.7 Focus zichtbaar: AA ± Zie Richtlijn 2.12.4.8 Locatie: AAA NA2.4.9 Linkdoel (alleen link): AAA +2.4.10 Paragraafkoppen: AAA NA

3.2.6 Principe begrijpelijk

Richtlijn 3.1 Leesbaar: Maak tekstcontent leesbaar en be-grijpelijk3.1.1 Taal van de pagina: A +3.1.2 Taal van onderdelen: AA +3.1.3 Ongebruikelijke woorden: AAA -

3.1.4 Afkortingen: AAA -

3.1.5 Leesniveau: AAA ±Taalgebruik disclaimer mo-gelijk te hoog niveau; “incasu”, “casu quo”, etc.

3.1.6 Uitspraak: AAA -Richtlijn 3.2 Voorspelbaar: Maak het uiterlijk en de bedie-ning van webpagina’s voorspelbaar3.2.1 Bij focus: A +3.2.2 Bij input: A +3.2.3 Consistente navigatie: AA + NA3.2.4 Consistente identificatie: AA +3.2.5 Verandering op verzoek: AAA +Richtlijn 3.3 Assistentie bij invoer: Help gebruikers om fou-ten te vermijden en ze te verbeteren3.3.1 Fout identificatie: A +3.3.2 Labels of instructies: A +3.3.3 Foutsuggestie: AA +3.3.4 Foutpreventie (wettelijk, financieel, gegevens): AA NA3.3.5 Hulp: AAA -

3.3.6 Foutpreventie (alle): AAA ± AAA-status niet relevant



3.2.7 Principe robuust

Richtlijn 4.1 Compatibel: Maximaliseer compatibiliteit methuidige en toekomstige user agents, met inbegrip vanhulptechnologieën

4.1.1 Parsen: A +De onderliggende KML zouook als content kunnen wor-den beschouwd. Zie ook U1.

4.1.2 Naam, rol, waarde: A NA


4 Beheer

Voor het in beheer nemen van applicaties door RWS worden op verschillende aspecten eisengesteld.

Beheerbaar Kan de applicatie in beheer genomen worden en zijn de risico’s bekend.

Testbaar Kan geverifieerd worden of de applicatie naar behoren werkt.

Overdraagbaar Kan de ontwikkeling van de applicatie aan een andere leverancier worden over-gedragen.

Betaalbaar Zijn de budgetten gealloceerd.

4.1 Beheersbaar

4.1.1 Rollen en risico’sOm rolverdeling tussen leveranciers van data, software, kennis en de gebruikers daarvan vastte stellen is het gebruikelijk om een stakeholderanalyse uit te voeren. Aangezien de populatievan stakeholders bekend en beperkt is (n=4, Deltares (kennis, ontwikkeling), RWS (data leveran-cier, gebruiker), Waterschappen (gebruiker, zonder ondersteuning) Nelen en Schuurmans (N&S)(ontwikkeling, beheer)) raden we aan om deze niet uit te voeren.

Een product risicoanalyse kan bepalen aan welke beschikbaarheidseisen de applicatie moetvoldoen, of er sprake is van aansprakelijkheidskwesties. Alle data is vrij, alle code is open source,daarmee zijn de aansprakelijkheidskwesties onwaarschijnlijk, zie ook de open data sectie. Degegevens en indicatoren worden gebruikt in het primaire proces maar zijn niet tijdskritisch. Derisicos voor beschikbaarheid van de produktieomgeving zijn bekend en beperkt en er zijn anderesystemen afhankelijk van de kustviewer. Daarom zijn er geen speciale beschikbaarheidseisen.We adviseren om de productrisico analyse hiertoe te beperken.

De informatie beveiliging is op dit moment niet bepaald.

⋄ eisen informatiebeveiliging definiëren (d.m.v. afhankelijkheid en kwetsbaarheids analyse)(3 dagen)

4.1.2 OpleidingVoor het beheren van de multidimensionale database en het beheren van de server zijn diversevaardigheden vereist. Het gebruik van de kustviewer zelf vereist geen specifieke opleiding. Dehandleiding van Google Earth volstaat is uit de praktijk gebleken.

Voor het beheer van de database en server kan een matrix met benodigde kennis en vaardig-heden worden opgesteld (2 dagen). De opleiding en instructies voor functioneel, applicatie entechnisch beheer kunnen worden verzorgd waarbij ook de benodigde tooling (vrij beschikbaar,moet dan ook aan de producten en diensten catalogus worden toegevoegd) zal worden meege-nomen (5 dagen voorbereiding + 2 dagen cursus).



4.1.3 Communicatie eindgebruikers

⋄ Bij het overnemen van beheer is het belangrijk dat de nieuwe contact informatie voor ge-bruikers op de site wordt geplaatst (actie RWS bij overname beheer).

⋄ Er zal een periodiek gebruikersoverleg moeten plaatsvinden (actie RWS).

⋄ Er zal een termijn van nazorg worden ingepland waarbij de huidige beheerders beschik-baar zijn voor ondersteuning (2 dagen, N&S)

4.1.4 WerkprocesBij het overnemen van beheer hoort ook een aanpassing van het werkproces.

Binnen RWS, Deltares en N&S zijn systemen beschikbaar om werkproces te faciliteren. Hierbijworden de volgende onderdelen afgedekt. Issue, change, request en problem management isop dit moment in gebruik via het registratie systeem. Er zijn geen issues, changes, requests ofproblemen gerapporteerd. 1

⋄ probleemtypen: bug, verzoek, etc.

⋄ afhandelgroepen: urgentie, verantwoordelijken

Binnen RWS wordt het proces verder nog vormgegeven door een diverse werk procedures. Dezepunten worden doorgaans concreet ingevuld door een Service Level Manager. Voor zover be-kend is er geen service level manager actief om de werkprocessen wat betreft software te co-ördineren. Ook zijn de bijbehorende rollen volgens de Responsible, Accountable, Consulted,and Informed (RACI) matrix niet ingevuld. Voordat een afstemming van deze werkprocessenkan worden ingevuld is het raadzaam om eerst de rolverdeling conform het bij RWS gebruiktewerkproces in te vullen.

⋄ cases voor juiste toewijzing

⋄ template handleiding Helpdesk ingevuld

⋄ CIs opgenomen in CMDB (update van systeem)

⋄ maintenance windows bekend (zie eventueel beheerplan)

⋄ wijzigingsprocedure applicatie

⋄ implementatieplan aanwezig

⋄ productiechange volgens implementatieplan getest op testomgeving

⋄ fallback scenario aanwezig en getest (heen, terug, heen)

⋄ change voor de in produktiename geregistreerd (nummer vermelden)

⋄ impact batch doorlooptijd bekend

1https://github.com/lizardsystem/lizard-kml/issues


https://github.com/lizardsystem/lizard-kml/issues


De autorisatie van gebruikers en beheerders is nu gescheiden naar database, server en appli-catie. Bij het overnemen van het beheer dient ook de gebruikersadministratie overgenomen teworden.

4.2 TestbaarVoor het testbaar maken van de verschillende onderdelen van de applicatie is het van belang datde volgende onderdelen aanwezig zijn.

⋄ master-testplan

⋄ detailtestplan(nen)

⋄ testrapporten/bevindingenrapportages

⋄ stresstest

⋄ loadtest

⋄ review mastertestplan

Er is op dit moment geen testplan en er zijn geen testrapporten aanwezig. Op dit moment zijnunit testen (testen van de functies om data op te vragen) en integratie testen beschikbaar. 2.De testen worden geschreven in lijn met de test documentatie: 3 Er worden geen periodieketestrapporten aangemaakt. Stresstesten en loadtesten worden niet uitgevoerd.

We stellen de volgende activiteiten voor.

⋄ Automatiseren unit testen en integratie en toevoegen systeem testen zodat automatischtestrapporten worden gecreëerd. (3 dagen)

⋄ Invullen document master test plan, inclusief review (5 dagen + review RWS).

4.3 OverdraagbaarHet is van belang dat er programma en componentbeschrijvingen zijn.

⋄ Beschrijving van het programma is in het Engels beschikbaar. 4

⋄ Gebruikte componenten hebben elk een eigen beschrijving. Deze zijn eenvoudig terug tevinden via google en Python Package Index (pypi).

Functionele Beschrijving inclusief functioneel detail ontwerp.

2https://github.com/lizardsystem/lizard-kml/blob/master/lizard_kml/tests.py

3https://docs.djangoproject.com/en/dev/topics/testing/

4https://github.com/lizardsystem/lizard-kml


https://github.com/lizardsystem/lizard-kml/blob/master/lizard_kml/tests.py

https://docs.djangoproject.com/en/dev/topics/testing/

https://github.com/lizardsystem/lizard-kml


⋄ Er is een summiere beschrijving van de functionaliteit beschikbaar op de wiki 5 6 en aan-vullende informatie in twee publicaties 7 8 (0 dagen)

⋄ Het in detail beschrijven van de functionaliteit in een functioneel detail ontwerp (5 dagen).

Voor het gebruik van de database zijn uitgebreide tutorials en cursusmateriaal beschikbaar.

Voor het gebruik van de server en de client zijn geen gebruikershandleidingen beschikbaar. Eengebruikershandleiding beschrijft hoe de gebruiker kan werken met de toepassing.

⋄ Omdat de viewer is gebaseerd op google earth kan voor het grootste deel van de functio-naliteit worden verwezen naar google earth documentatie 9

⋄ Schrijven van documentatie server (2 dagen)

⋄ Schrijven van documentatie client (2 dagen)

Voor het in beheernemen van de database, server en de client zijn lijsten met componentennodig. Deze kunnen worden gebruikt om te controleren of er updates nodig zijn als er softwareverouderd of als er veiligheidsupdates nodig zijn.

⋄ De lijst met vereiste systeem componenten 10 is beschikbaar, evenals de lijst vereistesoftware componenten is ook beschikbaar 11 12 (0 dagen)

⋄ Inpakken van de lijst met componenten in een rpm pakket voor de openearth stack (5dagen).

⋄ In een Word document de lijst met pakketten bijhouden (2 dagen)

Voor het begrijpen van de applicatie door een nieuwe ontwikkelaar is het van belang dat hetdatamodel (logisch en technisch, inclusief relatietypes) beschreven is.

⋄ De definitie van gegevens bronnen 13 binnen de server 14 en de database (zelf beschrij-vend) zijn gedocumenteerd. (0 dagen)

⋄ Word document met beschrijving van gegevenstypes. (3 dagen)

Voor het hergebruiken en aanpassen van de code is het van belang dat er interface beschrij-vingen aanwezig zijn. Omdat het een webapplicatie betreft wordt onder de interface doorgaansde vertaling van uniform resource locator (url)’s naar functies verstaan. De kustviewer biedt eenRepresentational state transfer (REST)-achtige gegevens toegang aan. Hiermee kunnen auto-matisch grafieken voor rapporten worden gegenereerd.

5https://publicwiki.deltares.nl/display/KV/Kustviewer

6https://publicwiki.deltares.nl/display/KPP/Achtergrondinfo+Kustviewer

7http://www.vliz.be/imisdocs/publications/241321.pdf

8http://kennisonline.deltares.nl/product/30408

9https://www.google.com/earth/learn/

10https://github.com/lizardsystem/lizard-kml

11https://github.com/lizardsystem/lizard-kml/blob/master/buildout.cfg

12https://github.com/lizardsystem/lizard-kml/blob/master/setup.py

13https://github.com/lizardsystem/lizard-kml/blob/master/lizard_kml/models.py

14https://github.com/lizardsystem/lizard-kml/blob/master/lizard_kml/jarkus/nc_models.py


https://publicwiki.deltares.nl/display/KV/Kustviewer

https://publicwiki.deltares.nl/display/KPP/Achtergrondinfo+Kustviewer

http://www.vliz.be/imisdocs/publications/241321.pdf

http://kennisonline.deltares.nl/product/30408

https://www.google.com/earth/learn/

https://github.com/lizardsystem/lizard-kml

https://github.com/lizardsystem/lizard-kml/blob/master/buildout.cfg

https://github.com/lizardsystem/lizard-kml/blob/master/setup.py

https://github.com/lizardsystem/lizard-kml/blob/master/lizard_kml/models.py

https://github.com/lizardsystem/lizard-kml/blob/master/lizard_kml/jarkus/nc_models.py


⋄ De definitie van de interface in code 15

⋄ Beschrijving van de rest interface in een word document (3 dagen).

4.4 BetaalbaarVoor het betaalbaar houden dienen afspraken gemaakt worden binnen RWS en tussen RWS enDeltares. Tussen Deltares en RWS zal voor het functioneel beheer en applicatie- en technischbeheer, voor zover deze nog bij Deltares liggen een SLA opgesteld moeten worden. De afdekkingvan risicos en serviceniveaus moeten hierin beschreven en afgedekt worden. Het opstellenvan de SLA kan het beste op een hoger niveau dan een enkele applicatie worden afgestemd.Daarnaast moeten eerst compatibele rollen worden ingevuld zoals hierboven geadviseerd.

Binnen RWS moeten urenregels aangemaakt voor het boeken van uren beheerder, de dienstmoet worden opgenomen in de service catalogus en de extra benodigde beheer capaciteit perjaar (beheerlast) bekend en ingeregeld worden. De verwachte beheerlast kan worden ingeschatop basis van de beheerlast van de afgelopen jaren (ongeveer 40 uur per jaar, TODO checken bijAnkie).

15https://github.com/lizardsystem/lizard-kml/blob/master/lizard_kml/urls.py


https://github.com/lizardsystem/lizard-kml/blob/master/lizard_kml/urls.py

5 Gegevens

Dit hoofdstuk beschrijft zowel de aansluiting op de distributielaag als de checklist open data.

5.1 Aansluiting op toekomstige wijziging in de distributielaagAls toekomstige distributielaag voor de data, die in de kustviewer wordt weergegeven, is LOLvoorzien. In de huidige situatie maakt de kustviewer gebruik van (netCDF) data die op de Ope-nEarth thredds server wordt aangeboden. In deze sectie wordt ingegaan op de beschikbaarheidvan LOL en de eisen die aan deze toekomstige data distributielaag gesteld moeten worden omals volwaardig alternatief van de huidige werkwijze aangemerkt te kunnen worden.

5.1.1 Beschikbaarheid distributielaagBij uitvoeren van deze verkenning is het LOL nog niet beschikbaar. Navraag bij Rijkswaterstaat-CIV leert dat LOL vooralsnog uitsluitend op het intranet van Rijkswaterstaat beschikbaar is. Deaanvraag bij helpdesk water, doorgestuurd naar servicedesk data, naar het toegangsprotocolvan LOL is tot op heden (14 dagen na aanvraag) niet beantwoord. Het is onduidelijk wanneerLOL publiekelijk beschikbaar zal komen.

5.1.2 Eisen aan distributielaagDe snelheid is de belangrijkste maatstaf voor het accepteren van een data distributielaag alsbackend van de kustviewer. Om aan de gebruikseisen van een viewer te beantwoorden moet deopgevraagde data snel weergegeven kunnen worden. Om de snelheid te kunnen testen wordthet aantal geleverde JarKus raai-tijd combinaties per tijdseenheid als maatstaf gekozen. In dehuidige situatie kan de netCDF data zoals deze via internet via de OpenEarth thredds serveropgevraagd wordt tevens in identieke vorm lokaal gecached worden.

0 500 1000 1500 2000 2500 3000Cross shore distance [m]

1972

1985

1999

2013

Measu

rem

ent

tim

e [

y]

Figuur 5.1: Voorbeeld van raai-tijd combinaties

Via het internet kunnen 50 raai-tijd combinaties binnen orde 1 seconde geleverd worden. Vanuitde lokale cache kan dit in ruim 2 milliseconde (500x sneller). Als LOL publiekelijk beschikbaaris, moet het de snelheid van orde 1 seconde minimaal kunnen evenaren om als volwaardigalternatief te kunnen worden aangemerkt. Daarnaast is uiterst wenselijk om een lokale cache inidentieke vorm (t.o.v. de online bron) te kunnen bewaren, aangezien hiermee de kans op fouten



aanzienlijk kan worden verkleind.

5.2 Open DataDe kustviewer is opgezet om alle data van de Nederlandse kust beschikbaar te maken voor eeneen breed publiek.

De kustviewer is op dit moment gesloten. Het gebruik is geënt op een klein aantal professionelegebruikers. De viewer is in de huidige vorm niet geschikt voor breed gebruik door alle eventuelegeïnteresseerden. Tevens kan een deel van de ontsloten informatie verkeerd geïnterpreteerdworden zonder goede toelichting.

Om de kustviewer weer openbaar te maken wordt de juridische check uitgevoerd 1.

Er zijn een aantal gronden waarop data gesloten gehouden kan worden.

⋄ een bedreiging zou kunnen vormen voor de eenheid van de Kroon

⋄ de veiligheid van de Staat zou kunnen schaden

⋄ indien het bedrijfs- en fabricagegegevens betreft die vertrouwelijk aan de overheid zijnmedegedeeld

⋄ indien het bijzondere persoonsgegevens betreft

Wat betreft veiligheid kan gedacht worden aan de gegevens om en nabij de kerncentrales vanPetten en Borssele. Op dit moment zijn de kustgegevens in de nabijheid van de kerncentralesniet anders geclassificeerd.

Er zijn geen restricties op kustinformatie in verband met de veiligheid van de staat.

Van het meedelen van bedrijfs- en fabricage gegevens is soms sprake. Denk bijvoorbeeld aan deaanleg van de maasvlakte en de aanleg van de zandmotor. Door metingen van tijdens de aanlegte verzamelen kan de werkwijze van baggeraars ongewild openbaar gemaakt worden. We gaaner van uit dat gegevens waar dit betrekking op heeft door RWS niet worden doorgeleverd.

De kustgegevens die persoonsgegevens omvatten zijn de ARGUS camera beelden. Deze wor-den nu niet via de kustviewer ontsloten.

5.2.1 Rechten derdenEen van de mogelijke rechten die geclaimed zou kunnen worden door een derde is het eigen-domsrecht. De eigenaar van een database wordt bepaald door de databankenwet. De overheidis de risicodragende investeerder, maar de overheid is in veel gevallen uitgesloten van eigenaar-schap zoals in die wet gedefinieerd. Door substantieel te investeren in een gegevensbron kaneen nieuwe eigenaar ontstaan. Hierdoor is het eigendom niet eenvoudig vast te stellen. Deltaresen andere partijen die aan de kustdata werken zouden door het doen van substantiële investe-ringen (toevoegingen van metadata, correcties, samenvoeging en data opwerkingen) eigendom

1https://data.overheid.nl/handreiking/stap2


https://data.overheid.nl/handreiking/stap2


kunnen claimen. Deltares stelt de opgewerkte gegevens open en zonder beperkingen ter be-schikking. Toch is het raadzaam over het eigendom van data, afgeleide en samengevoegde dataconcrete afspraken te maken. Deze afspraken hoeven echter niet binnen dit project gemaakt teworden maar in lopende raamafspraken.

5.2.2 ConcurrentievervalsingHet verkrijgen van de data van de kustviewer en de bijbehorende kengetallen valt binnen hetprimaire proces van RWS. Voor gegevens die vergelijkbaar zijn aan de gegevens gebruikt inde kustviewer, bijvoorbeeld Actueel Hoogtebestand Nederland versie 2 (AHN2) en de luchtfoto’sdoor het kadaster, is gebleken dat dit soort gegevens open gemaakt kunnen worden, ook al zijner commerciële partijen die vergelijkbare datasets commercieel aanbieden.

5.2.3 VerwachtingenBij de datasets dient duidelijk gemaakt te worden wat het doel, kwaliteit en context van de datais. Deze informatie is niet voor alle datasets compleet. Dergelijke informatie wordt bijgehoudenop de website data.overheid.nl. Op dit moment is het niet mogelijk om dergelijke informa-tie (metadata op catalogus niveau) van afgeleide datasets (zoals de data in de kustviewer) viahet data.overheid.nl portaal beschikbaar te stellen. Deze informatie wordt nu, conform deISO19115 standaard in de Deltares catalogus aangeboden.

5.3 Advies

⋄ De kustviewer gebruikt alleen open data en kan daarom ook open worden aangeboden.

⋄ Voeg doel, context en sterren toe aan de metadata van de data die wordt gebruikt voor dekustviewer.

⋄ Maak concrete afspraken over het eigendom van data, afgeleide data en data productendie door Deltares en andere partners van RWS worden geproduceerd.

⋄ Biedt de mogelijkheid datasets die door derden worden beheerd en voor het primaire pro-ces worden gebruikt toe te voegen aan de data.overheid.nl (actie data.overheid.nl)


data.overheid.nl

data.overheid.nl

data.overheid.nl

data.overheid.nl

6 Adviezen

6.1 Scenario’sUit de vorige hoofdstukken blijkt dat het in beheer nemen een aantal grote aanpassingen ver-eist (ofwel het aanpassen van de diensten catalogus ofwel het herschrijven van de software).Daarnaast bleek dat de technische ontwikkelingen de implementatie keuzes bepalen (browserplugins, zoals Google Earth worden uitgezet door fabrikanten).

Om de doorwerking hiervan wat duidelijker te maken schetsen we drie scenario’s voor het inbeheer nemen van (delen van) de kustviewer.

We maken weer onderscheid tussen het overdragen van de opwerking van data, het serverenvan data, de applicatie en de viewer.

In de onderstaande scenario’s wordt het opwerken van de data, het transformeren van de me-tingen naar indicatoren (vaak met modellen) en de structurering (hergridden, interpolatie, stan-daardisatie, validatie) van metingen niet overgedragen omdat dit kennis vereist die alleen binnenDeltares aanwezig is.

6.1.1 RWS als beheerderHet in beheer nemen van de applicatie door RWS vereist het overnemen van drie taken: hetserveren van de data, de applicatie ontwikkeling en hosting en het beheer van de viewer.

OnderhoudenData opwerken Data opwerken

Figuur 6.1

Dit scenario kent een aantal interes-sante uitdagingen: kennis, project-matig en technisch.

Deze aanpak vereist kennis op ver-schillende tereinen, data manage-ment voor het beheer van de ge-gevensverzamelingen, systeembe-heer, voor het beheer van de grotehoeveelheid computer capaciteit enkennis van de volledige stapel vanontwikkeltools (databases, webap-plicaties, viewers, meerdere pro-grammeertalen).

Projectmatig vereist het een grote agiliteit. Op diverse lagen vinden snelle ontwikkelingen plaats.Het verwerken van nieuwe databronnen (bijvoorbeeld satellieten die 1TB per dag meten) totkengetallen vereist steeds meer gespecialiseerd personeel en een flexibele ICT omgeving.

Een voorbeeld van een technische uitdaging zagen we in in paragraaf 2.4, waar bleek dat hetmaken van een viewer, met dezelfde functionaliteit, met de huidige bouwstenen niet mogelijk is.

Daarnaast nog het gebrek aan aansluiting op de andere bouwstenen. De applicaties die nu



gebruikt worden moeten deels worden aangepast en deels worden herschreven. Theoretisch isalle software die Rijkswaterstaat gebruikt en Deltares ontwikkelt al aangepast aan de bouwstenencatalogus van RWS. In de SLA voor het modelinstrumentarium staat immers:

Alle nieuw te ontwikkelen applicaties dienen te voldoen aan de architectuureisenen de bouwstenencatalogus van de RWS CIV. Deltares dient zich te allen tijde teverzekeren dat de systemen die men voor Rijkswaterstaat ontwikkelt, passen op deTechnisch Doelarchitectuur van Rijkswaterstaat.

In de praktijk worden veel applicaties niet initieel voor Rijkswaterstaat ontwikkeld, maar voor inter-nationale projecten, tijdens promoties, voor waterschappen of in de vrije tijd. De bouwstenen dieworden gebruikt sluiten aan bij wat mensen kennen. De software wordt bijvoorbeeld geschrevenin de talen die ooit aan de universiteit zijn gedoceerd (fortran, matlab en tegenwoordig python).De standaarden die gebruikt worden sluiten meer aan bij de internationale gemeenschap (OGC,CF, Inspire) dan bij de landelijke (Aquo).

Met inachtneming van bovenstaande uitdagingen is het raadzaam, als dit scenario gevolgd wordt,om de onderdelen in ieder geval stapsgewijs over te nemen. Te beginnen bij het serveren vande indicatoren en opgewerkte metingen. Het overnemen van de applicatie kan later. Voor hetovernemen van de viewer is het raadzaam te wachten tot de technieken die gebruikt worden omde kust in 3D en in de tijd in beeld te brengen uitgekristalliseerd zijn.

6.1.2 Deltares als beheerderEen ander scenario is het behouden van de huidige situatie. Dit kan voor zowel de data opwer-king, het serveren van de data als de applicatie.

Het viewer gedeelte moet wel herschreven worden, zie paragraaf 2.4. Dit kan door Deltaresuitgevoerd worden. Dit gebeurt in voorkeur in combinatie met een Nederlands ingenieursbureau,omdat zij deze taak (het hosten van viewers) op zich willen en kunnen nemen. De ontwikkelingvan de kustviewer vereist domein en technische kennis die vooral bij Deltares aanwezig is.


Figuur 6.2

Omdat uit paragraaf 2.4 bleek dathet met de huidige technieken nietmogelijk is om dezelfde functionali-teit aan te bieden moet er een nieuwontwerp gemaakt worden. Te den-ken valt aan het aanbieden van een2D kaart + tijd voor een deel van defunctionaliteit (overzicht suppleties,kustlijnen) en een regionale 3D om-geving voor het andere deel van defunctionaliteit (kust lidar, drone data,profielen).

Een andere optie voor het herontwerpen van de viewer is het uitstellen van het nieuwe ontwerptot de technische mogelijkheden voor het weergeven van 3D ruimtelijke data via het web zijnuitgekristalliseerd.



6.1.3 Kustviewer herverdelenAls derde scenario is het te overwegen om de kustviewer te herverdelen. Sinds de kustviewerinitieel ontwikkeld werd zijn er diverse andere viewer initiatieven gestart.

Hierbij kan zowel gedacht worden aan het herverdelen van de applicatie als de viewer.


Figuur 6.3

Omdat de broncode van de kustvie-wer onder een open licentie (GNUGeneral Public License version 3(GPLv3)) is, is het voor anderen mo-gelijk om de representaties (webpa-gina’s, kaartlagen en grafieken) diedoor de kustviewer worden gebruiktna te bouwen of over te nemen. Hetvereist wel enige domein kennis eneen ontwikkel omgeving die het ma-ken van geavanceerde grafieken op

basis van ruimtelijke tijdsafhankelijke data ondersteund.

Op dit moment zijn er alleen al voor de Nederlandse water toepassingen enkele tientallen viewersin gebruik. Omdat juist het viewer gedeelte moet worden herzien valt het te overwegen om dekust data in de andere viewers onder te brengen.

Hierbij zal wel blijken dat ook van deze andere viewers een groot deel reeds weer verouderd is,zij het door gebruik van uitgefaseerde technieken (Silverlight, Flash) of verouderde componenten(bijvoorbeeld OpenLayers 2).

6.1.4 Kosten en risico’sVan de scenario’s valt alleen voor het Deltares Beheer scenario een duidelijke kosten schattingte geven. Op basis van een kostenschatting van het ontwerp van de huidige viewer schatten wedat het ontwerp van de vervanging van de viewer ongeveer hetzelfde zal kosten, dat wil zeggenin de orde van 100k EUR.

Bij de andere scenario’s komen de kosten terecht bij andere organisaties, bij RWS voor het eerstescenario en bij nog te bepalen partijen voor het herverdeel scenario.

6.2 Overige adviezenVoor een goede aansluiting bij de in de markt ontwikkelde toepassingen en de bouwstenen ca-talogus is het van belang dat de bouwstenen catalogus aansluit bij de werkwijze van de ingeni-eursbureaus en Deltares en bij de opleidingen van de TU’s.

We adviseren om een vertegenwoordiging uit deze organisaties een adviserende rol te geven inhet samenstellen van de bouwsteencatalogus. (actie RWS)


7 Literatuur

Baart, F., 2013. Confidence in Coastal Forecasts. Ph.D. thesis, Technical University of Delft. 1

Boer, G. J. de, F. Baart, A. Bruens, T. Damsma, P. G. van, B. Grasmeijer, K. H. den and M. K.van, 2012. “OpenEarth: using Google Earth as outreach for NCK’s data.” In NCK-days 2012:Crossing borders in coastal research jubilee conference proceedings, pages 97–103. URLhttp://proceedings.utwente.nl/177/. 1

Damsma, T., F. Baart, G. de Boer, M. V. Koningsveld and A. Bruens, 2009. “Visualization ofcoastal data through KML.” In Virtual Globes at AGU. URL http://adsabs.harvard.edu/

abs/2009AGUFMIN43A1131D. 1

Engels, J., J. Drenth, H. Bruijn and T. Gerritsen, 2012. Bouwstenen Catalogus DID IAP GeneriekHard en Software Infra. Tech. Rep. 2.9.10, Rijkswaterstaat, June. 3

Santinelli, G., F. Baart, G. Ramaekers and E.-J. Vos, 2013. “Coastviewer: a tool to enable thevisualization of marine and coastal data.” In International Conference on Marine Data andInformatics. 1


http://proceedings.utwente.nl/177/

http://adsabs.harvard.edu/abs/2009AGUFMIN43A1131D

http://adsabs.harvard.edu/abs/2009AGUFMIN43A1131D

Acroniemen

AHN2 Actueel Hoogtebestand Nederland versie 2

CIV Centrale Informatievoorziening

EAP Enterprise Application Platform

EPEL Extra Packages for Enterprise Linux

ICT Informatie- en Communicatie Technologie

KML Keyhole Markup Language

LOD Level of detail

LOL Landelijke Opslag Lodingen

N&S Nelen en Schuurmans

OET OpenEarth Tools

OGC Open Geospatial Consortium

RACI Responsible, Accountable, Consulted, and Informed

REST Representational state transfer

RWS Rijkswaterstaat

PSA Project Start Architectuur

SLA Service Level Agreement

THREDDS THREDDS Data Server

WVL Water, Verkeer en Leefomgeving

pypi Python Package Index

url uniform resource locator

GPLv3 GNU General Public License version 3

HTML5 HyperText Markup Language version 5


Kustviewer in beheer name planpublications.deltares.nl/1209381_008b.pdf · kustviewer, maar ook...

Documents

Transcript of Kustviewer in beheer name planpublications.deltares.nl/1209381_008b.pdf · kustviewer, maar ook...