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)
Deltares
TitelKustviewer in beheer name plan
Opdrachtgever Rijkswaterstaat Project 1209381.008 Kenmerk 1209381 -008- ZKS-OOO 1 Pagina's 35 Trefwoorden Kustviewer Samenvatting
Dit 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 (update van bouwstenen catalogus en uitbreiding met 1 database type) in beheer genomen worden. De server 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 dei ngenieurs-, gis en wetenschappelijke software ontwikkelpraktijk. Het client gedeelte van de kustviewer moet herzien 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 Google Earth te werken. Gebruikers buiten RWS kunnen met de juiste browser de huidige kustviewer tot eind 2015 blijven gebruiken.
Om de applicatie in beheer te nemen moeten een aantal rollen ingevuld worden die de werkwijze van RWS ondersteunen. Daarnaast kan nu al een aantal verbeteringen worden doorgevoerd (in-formatie beveiliging, automatisch testen, maken testplan) die de overdracht van beheer makkelijker maken.
Het is op dit moment nog niet mogelijk om op Landelijke Opslag Lodingen (LOL) aan te sluiten omdat LOL en de beschrijving van het toegangsprotocol niet publiek beschikbaar zijn. De data in de kustviewer voldoet aan de open data eisen, daarom kan de kustviewer publiek beschikbaar gemaakt worden, met als doelgroep specialistische gebruikers.
Referenties
Versie Datum Auteur Paraaf Review Paraaf Goedkeuring Paraaf
0.1 2014-12-31 Fedor Baart Gemma Raaijma
-kers
2015-2-23 Fedor Baart Gerrit Hendriksen ~ Dirk Jan Walstra
Inhoudsopgave
1 Inleiding 1 1.1 Bouwstenen . . . 1 1.2 Huisstijl . . . 1 1.3 Beheer . . . 2 1.4 Gegevens . . . 2 2 Bouwstenen 3 2.1 De database . . . 3 2.1.1 Evaluatie . . . 3 2.1.2 Advies . . . 4 2.2 Server . . . 4 2.2.1 Advies . . . 6 2.3 Client . . . 6 2.4 Kaart component . . . 8 2.5 Alternatieven . . . 9 2.6 Resultaten . . . 9 2.6.1 Arcgis Explorer . . . 9 2.6.2 City Engine . . . 9 2.6.3 Cesium . . . 9 2.6.4 Mapbox gl . . . 10 2.6.5 OpenLayers . . . 10 2.6.6 f4map . . . 10 2.6.7 Leaflet . . . 10 2.6.8 Adaguc . . . 10 2.6.9 Google maps . . . 10 2.6.10 GeoWeb . . . 10 2.6.11 Arcgis Online 3D . . . 11 2.7 Advies . . . 11 2.8 Conclusie . . . 12 3 Huisstijl 13 3.1 Corporate huisstijl . . . 13 3.2 Webrichtlijnen . . . 13 3.2.1 Evaluatie . . . 14 3.2.2 Links . . . 14 3.2.3 Principe universeel . . . 14 3.2.4 Principe waarneembaar . . . 15 3.2.5 Principe bedienbaar . . . 16 3.2.6 Principe begrijpelijk . . . 17 3.2.7 Principe robuust . . . 18 4 Beheer 19 4.1 Beheersbaar . . . 19 4.1.1 Rollen en risico’s . . . 19 4.1.2 Opleiding . . . 19 4.1.3 Communicatie eindgebruikers . . . 20 4.1.4 Werkproces . . . 204.3 Overdraagbaar . . . 21
4.4 Betaalbaar . . . 23
5 Gegevens 25 5.1 Aansluiting op toekomstige wijziging in de distributielaag . . . 25
5.1.1 Beschikbaarheid distributielaag . . . 25
5.1.2 Eisen aan distributielaag . . . 25
5.2 Open Data . . . 26 5.2.1 Rechten derden . . . 26 5.2.2 Concurrentievervalsing . . . 27 5.2.3 Verwachtingen . . . 27 5.3 Advies . . . 27 6 Adviezen 29 6.1 Scenario’s . . . 29 6.1.1 RWS als beheerder . . . 29
6.1.2 Deltares als beheerder . . . 30
6.1.3 Kustviewer herverdelen . . . 31
6.1.4 Kosten en risico’s . . . 31
6.2 Overige adviezen . . . 31
Lijst van figuren
2.1 Populariteit programmeertalen (aantal commits) in open source projecten over
laatste 10 jaar (bron: openhub.net) . . . 5
2.2 . . . 11
5.1 Voorbeeld van raai-tijd combinaties . . . 25
6.1 . . . 29
6.2 . . . 30
1
Inleiding
De kustviewer is in 2009 ontwikkeld om snel kustdata in kaart te brengen en te visualiseren. De basis is gelegd in het afstudeerwerk van Thijs Damsma (Damsma et al., 2009)en de promotie van Fedor Baart (Baart, 2013). In 2012 is de viewer ondergebracht in het Lizard platform van Nelen en Schuurmans en samen met RWS verder ontwikkeld (Santinelli et al.,2013). De viewer past in het streven om het consumeren van data van de Nederlandse kust net zo makkelijk te maken 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 worden hebben 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 Bouwstenen
Aansluiten op de bouwstenen van RWS: Aangeven in hoeverre de huidige kustviewer voldoet aan de vereisten uit de zogenaamde bouwstenencatalogus. Tevens aangeven welke mogelijkheden er zijn in het kader van de Project Start Architectuur (PSA) OpenEarth Tools (OET) stack die door Centrale Informatievoorziening (CIV) (Flip Dirksen), Deltares (Gerard van der Kolff, Gerrit Hendriksen, 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 Lizard viewers zoals het Delta Portaal. Welke onderdelen passen, en op welke onderdelen wijkt de kustviewer 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 vraagt dit voor inspanning? Hierbij moeten ook de requirements voor 2015 tegen het licht houden met betrekking tot Informatie- en Communicatie Technologie (ICT) eisen vanuit de Service Level Agreement (SLA).
Een kenmerk van de kustviewer is dat deze gebruik maakt van 3 dimensionale animaties in de tijd. Deze is gebaseerd op een browser plugin. Vanaf 2015 wordt het gebruik van plugins in het algemeen en de plugin die gebruikt wordt voor de kustviewer niet meer ondersteund. Daarom wordt een aantal alternatieven onderzocht.
1.2 Huisstijl
Aansluiten op de huisstijl van RWS: Plan van aanpak maken voor aanpassen kustviewer. Voor zover 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 de kustviewer, maar ook voor andere Lizard-producten (zoals Delta portaal) en zo mogelijk ook voor 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.
1.3 Beheer
Aansluiten op de in beheername procedure van RWS: Op basis van de beschikbare checklijst van RWS wordt in beeld gebracht welke stappen genomen moeten worden om de kustviewer geschikt 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 Gegevens
Aansluiten op toekomstige wijziging in de distributielaag: Er wordt een eerste check uitgevoerd of de kustviewer rechtstreeks data uit LOL kan inlezen. De gegevens die in de kustviewer worden gebruikt worden geput uit de OpenEarth dataset1. Dit is een opgewerkte vorm van de RWS da-taset. RWS maakt steeds meer datasets publiek toegankelijk. Een van de datasets die gebruikt wordt is de “Vaklodingen” (diepte metingen). Deze wordt beschikbaar gemaakt onder de naam LOL. Inzichtelijk maken in de verkenning wat er nodig is voor het overstappen op LOL als data bron. Tevens speelt de vraag of de kustviewer open mag zijn. Hiervoor wordt de checklist “Open data” toegepast.
2
Bouwstenen
Dit hoofdstuk beschrijft in hoeverre de kustviewer op de bouwstenen van RWS voldoet aan de bouwstenencatalogus (Engels et al.,2012). Welke onderdelen passen, en op welke onderdelen wijkt 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 worden aangepast zodat deze compatibel is met het RWS bouwstenen systeem? Welke aanpassing zijn haalbaar en wat vraagt dit voor inspanning? Hierbij moeten ook de requirements voor 2015 tegen 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. In onderstaande overzichten zitten schuingedrukte onderdelen zitten in de bouwstenen catalogus versie 2.9.10 van 19 juni 2012.
2.1 De database
De 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. Multidimensionale database. 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 Evaluatie
De 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 het OPeNDAP 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 raster gebaseerde opslag gepast kunnen worden. Omdat het OPeNDAP protocol inmiddels tot Open Geospatial Consortium (OGC) standaard is verheven en het een de facto standaard voor model resultaten 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 met JBOSS.
Support voor Java 6 is door Oracle, de leverancier van Java, beëindigd op februari 2013, het is niet 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 20151. De meest logische optie is 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) die gebruikt zou kunnen worden. Hiervoor is waarschijnlijk wel een nieuwere versie van JBOSS EAP nodig dan in de bouwstenen catalogus staat. Dit is niet meer te controleren omdat de documentatie van JBOSS AS 5.x inmiddels niet meer online staat. De bouwstenen catalogus zal moeten 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 bouwstenen catalogus en wordt compleet ondersteund tot 2016. Het testen van deze configuratie vereist een extra 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 pakketten uit de Extra Packages for Enterprise Linux (EPEL) distributie, die niet in de bouwstenen catalogus staat (1 Dag). Overnemen van support van pakketten uit de EPEL verschilt per pakket en is moeilijk in te schatten, dat laten we open. Het opnemen van de CentOS distributie en de EPEL pakketten in de catalogus voorkomt deze kosten, maar vereist beheerders met meer kennis en oplossingsvermogen.
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 Server
De server raadpleegt de database met kustgegevens en geeft grafieken, animaties en indicatoren terug.
De technische componenten die gebruikt worden zijn :
⋄ Lizard kml, de applicatie die grafieken en Keyhole Markup Language (KML) bestanden genereert.
⋄ Python, de programmeertaal
1209381-008-ZKS-0001, Definitief, 27 februari 2015
Figuur 2.1: Populariteit programmeertalen (aantal commits) in open source projecten over laatste 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 bouwstenen catalogus. De lizard kml applicatie is gemaakt in python op basis van het WSGI protocol en diverse 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 functionaliteit van de applicatie is redelijk beperkt waardoor het herschrijven in ieder geval een overzichtelijke inspanning is. Wel zijn er een aantal praktische bezwaren.
Ten eerste de beschikbare ondersteuning. Java wordt ook ondersteund door Deltares voor server applicaties. C# wordt alleen gebruikt voor desktop applicaties door Deltares. De talen worden niet 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 in combinatie 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 niet mogelijk is. Indien dit toch wenselijk is kan een offerte voor het herschrijven van de applicatie in een van de ondersteunde talen worden opgesteld (opstellen offerte 10 dagen + implementatie kosten), 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 bij verschillende 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 deze configuratie te gebruiken om python en het framework te ondersteunen.
Daarnaast wordt gebruik gemaakt van de Postgis database die niet in de bouwstenen staat. Deze staat 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, maar dat vergt extra kennis bij de beheerders. Door de OET stack te gebruiken kan van Ubuntu overgestapt 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, ongeacht de distributie waar ze op draaien.
2.2.1 Advies
We adviseren om de applicatie niet te herschrijven maar om de componenten waarop deze is gebouwd toe te voegen aan de catalogus. Waarschijnlijk zal het even duren tot deze bouwstenen zijn toegevoegd aan de catalogus. Tot die tijd adviseren we om dit deel van de applicatie in beheer 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.5 dag 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, open source software, geen licentiekosten)
2.3 Client
De 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 zien krijgt. Als browsers zijn binnen RWS de volgende applicaties beschikbaar Firefox en Internet Explorer (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 de kustviewer 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 browser fabrikanten als verouderd bestempeld. Hieronder staan de standpunten van Google, Mozilla en
1209381-008-ZKS-0001, Definitief, 27 februari 2015
Microsoft weergegeven. Uit deze standpunten blijkt duidelijk ingebouwde plugins in websites in te toekomst niet meer beschikbaar zullen zijn.
Mozilla:
Plugins are now a legacy technology. They are not available on most mobile devices. Mozilla encourages website developers to avoid using plugins wherever possible. If there are plugin features which are not available in the web platform, we encourage developers to post their use cases to mozilla.dev.platform project list, so that 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 site entirely without using plug-ins. In some cases, however, it might not be possible for a website or web app to work completely without plug-ins. In these instances, there are some fallback techniques and mitigation strategies you can follow to ensure the best possible 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 1 january 2015. 4
Daarnaast is relevant dat Google de Google Earth plugin niet meer ondersteunt per 12 december 2015.
Therefore, after careful consideration, we have decided to retire the Google Earth API. Per our deprecation policy, the API will be supported until one year from today and will be turned off on December 12, 2015.5
Dat betekent dat het huidige client deel van de kustviewer niet meer functioneert per 12 december 2015. Microsoft Internet Explorer ondersteunt geen plugins meer vanaf versie 10.0, Chrome niet meer vanaf de versie die januari 2015 wordt uitgebracht. Wanneer Firefox plugins uitschakelt staat nog niet vast. Tot 12 december 2015 kan de kustviewer gebruikt worden met Google Earth Plugin in combinatie met firefox, tenzij Firefox eerder besluit plugins uit te schakelen of Internet Explorer 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 3 http://msdn.microsoft.com/en-us/library/ie/hh968248(v=vs.85).aspx 4http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html 5 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 verschillende alternatieven voor de google earth plugin component.
De opvolger van de kaartcomponent zal gebaseerd moeten zijn op diverse technieken die in html5 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 ondersteuning in de diverse browsers. Veel van de functies zijn inmiddels in de meest gebruikte browsers beschikbaar 6. Internet explorer ligt nog steeds achter, maar Microsoft heeft de intentie om de 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 component
Het doel van dit rapport is om inzichtelijk te maken welke alternatieven er beschikbaar zijn voor de 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 moeten voldoen. Op basis van deze criteria zijn een aantal alternatieven onderzocht.
Voor het onderzoek naar een alternatief voor de kustviewer van Rijkswaterstaat is er gekeken naar 3 criteria waaraan het alternatief moet voldoen.
Tijd: In de kustviewer moeten datasets kunnen worden geladen met een tijd component. Een tweede 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 worden getoond in de kustviewer.
kml: De data in de kustviewer wordt op dit moment ingelezen via KML bestanden. Dit is het enige gestandaardiseerde formaat waarmee zowel styling, linked data, Level of detail (LOD), tijdsintervallen en als relatieve hoogte gegevens kunnen worden gerepresenteerd.
6
1209381-008-ZKS-0001, Definitief, 27 februari 2015
2.5 Alternatieven
De 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 Resultaten
Hieronder worden de resultaten van het onderzoek per alternatief besproken.
2.6.1 Arcgis Explorer
Arcgis Explorer heeft op dit moment alleen nog een phone, tablet en desktop versie beschikbaar. De online versie is op 10 December 2013 gestopt7.
2.6.2 City Engine
City Engine gebruikt een plugin vrije omgeving om een 3D scene te creëren in de browser. Het is niet open source, en buiten de 30 dagen proefperiode moet ervoor betaald worden. City engine ondersteund wel 3D maar alleen op “scene” niveau. Het is niet mogelijk om de hele kust dynamisch in te laden. Het is niet mogelijk om een tijdsanimatie te maken. Van KML wordt slechts een deel van de functionaliteit ondersteund.
2.6.3 Cesium
Cesium is een open source javascript library voor het creëren van 3D en 2D kaart componenten in 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 dit waarschijnlijk 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.
7
2.6.4 Mapbox gl
Mapbox gl is ook een open source javascript library. Er kunnen wel 3D componenten worden toegevoegd, 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 een eigen formaat bestandstype en kan niet overweg met KML files.
2.6.5 OpenLayers
Openlayers is ook een open source javascript library. Deze is ontwikkeld met Cesium (hierboven beschreven). Openlayers beschikt niet over over een 3D component en ook de tijd component wordt niet ondersteund. Het KML bestandsformaat wordt wel ondersteund.
2.6.6 f4map
F4map heeft een 3D HTML5 component, vergelijkbaar met City Engine. De tijd component en KML worden niet ondersteund. Deze component is ontwikkeld voor de toeristen industrie.
2.6.7 Leaflet
Leaflet is een open source java library gericht op het maken van interactieve mobiel vriendelijke kaarten. Er is een 3D plugin beschikbaar, maar deze werkt via parallax effecten. Dat is vooral geschikt om een bovenaanzicht een 3d illusie te geven. Tijd en het KML bestandsformaat zijn via plugins beschikbaar.
2.6.8 Adaguc
Adaguc is een viewer die gebruikt wordt door het knmi. Deze viewer kan omgaan met een tijd component, maar bevat geen 3D component en kan ook geen KML bestanden inlezen.
2.6.9 Google maps
Google maps is de laatste viewer die is onderzocht. Deze viewer heeft een goede 3D component zoals op de afbeelding hieronder te zien is. Google maps kan in de 3D alleen niet over weg met de tijd component en kan ook geen bestanden zoals KML weergeven.
2.6.10 GeoWeb
GeoWeb is een gezamenlijk product van Esri Nederland
en Grontmij. Deze software bevat geen 3D functionaliteit en is grotendeels gebaseerd op Sil-verlight, waardoor deze software ook grotendeels vervangen moet worden door een moderner alternatief.
1209381-008-ZKS-0001, Definitief, 27 februari 2015
2.6.11 Arcgis Online 3D
In December 2014 heeft ESRI nog een opvolger van Arcgis Explorer beschikbaar gemaakt. Dit is een 3D kaart component op basis van HTML5. Tijd lijkt niet ondersteund te worden, alleen statische 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 knullig in en uit en de overgangen tussen satelliet en luchtfoto’s loopt niet soepel. Het is wel te verwachten dat er, zeker door het wegvallen van de Google Earth plugin, door ESRI tijd en geld in gestopt wordt om deze toepassing bruikbaar te maken.
2.7 Advies
Er kan worden geconcludeerd dat er op dit moment geen alternatief is voor de kustviewer die voldoet aan de 3 criteria waarnaar is gekeken. Cesium voldoet het
best 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 de toekomst wel mogelijk zal zijn.
Het logische advies zou zijn om af te wachten en de ontwikkeling van in ieder geval Cesium en Google Maps te volgen. Omdat de kustviewer op dit moment niet meer werkt binnen RWS en binnen een jaar nergens meer, adviseren we om de in overgang van de kustviewer tijdelijk te splitsen. 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 realiseren ons 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. Web applicaties worden doorgaans ontwikkeld op basis van diverse componenten. De uitfasering van dergelijke componenten kan snel gaan. Zo adverteert Microsoft Silverlight vandaag nog met de tekst: “bringing a new level of interactivity wherever the Web works.” terwijl het in Internet Explorer 10 en in Chrome niet meer wordt ondersteund. Esri gaf gebruikers van Arcgis Explorer Online 3 maanden om over te stappen8. De uitfasering van de Google Earth plugin binnen een jaar is hier een ander voorbeeld van.
Gegeven deze volatiliteit is het raadzaam om te overwegen of het op dit moment opportuun is om het beheer van viewers binnen RWS te trekken. In ieder geval moet men er op bedacht zijn dat de halfwaarde tijd van viewers, zeker de technisch complexere viewers, eerder in de orde van maanden ligt dan jaren. De huidige ontwikkelsnelheid die nodig is om in te spelen op dergelijke veranderingen sluit niet aan bij de beheeromgeving van RWS. We raden daarom af om viewers zoals 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).
⋄ Voeg Google Earth (de desktop versie) (als uitzondering, tijdelijk) toe aan de Producten Catalogus 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 de kaartcomponent, dan kan deze vervangen worden (10 dagen).
⋄ Plan B: Mocht bovenstaand punt niet haalbaar zijn, neem een deel van de functionaliteit over, met name de functionaliteit die past in andere kaart componenten. Ontwerp een nieuwe presentatie vorm voor de ontbrekende informatie. (totaal 20 dagen)
2.8 Conclusie
Om 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 van de distributie laag op de OET stack. We stellen voor om de dataset die door de kustviewer wordt 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 zoals de kustviewer. Hierop aansluitend staan hierboven een plan A en B.
3
Huisstijl
3.1 Corporate huisstijl
Op dit moment heeft de kustviewer een relatief merkloos voorkomen. De hoofdpagina1gebruikt geen beeldmerken. De url valt onder het lizard domein.
De viewer pagina2 kent wel een aantal beeldmerken. Op deze pagina zijn het overheidslogo klein, 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 de huisstijl van de overheid. Dat komt er op neer dat de richtlijnen van de rijks huisstijl worden gevolgd3.
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 tussen websites)
6 Favicon, makkelijk aanpasbaar (0 dagen), herbruikbaar tussen websites
3.2 Webrichtlijnen
De webrichtlijnen gaan over het ontwerpen, bouwen en beheren van websites. Ze zijn gebaseerd op internationale standaarden voor kwaliteit en toegankelijkheid (WCAG). Het volgen van deze aanbevelingen maakt content bruikbaar en toegankelijker voor meer mensen. Denk bijvoorbeeld aan (kleuren-)blinden, doven, mensen met dyslexie en mensen die de Nederlandse taal minder goed machtig zijn.
De kustviewer is gestart als een klein onderzoeksproject: met een zeer beperkt budget werd een proof of concept ontwikkeld. Aangetoond werd dat kustdata op een visueel aantrekkelijke manier kan worden ontsloten in een browser door gebruik te maken van Deltares’ OpenEarth database en 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
2
http://kustviewer.lizard.net/kml/
Met ingang van 2015 stopt ondersteuning voor Webrichtlijnen versie 1. Het ligt daarom voor de hand om ons te baseren op versie 2. Deze kent verschillende niveaus van conformiteit, die worden aangeduid met niveau A (laagst), AA, en AAA (hoogst). ‘Voldoen aan de Webrichtlijnen’ staat gelijk aan het behalen van niveau AA.
3.2.1 Evaluatie
De norm is opgebouwd uit 5 principes, met onder elk principe een aantal richtlijnen, die op hun beurt 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 presentatie en van gedrag
U.2.1 Scheiding van content en presentatie: A +
1209381-008-ZKS-0001, Definitief, 27 februari 2015
Richtlijn U.3 Bouw gelaagd: Borg de beschikbaarheid van basiscontent en -functionaliteit
U.3.1 Gelaagd bouwen: A
-Richtlijn U.4 Foutmeldingen:
U.4.1 Aangepaste foutmeldingen: A +
Richtlijn U.5 Formulieren: Maak formulieren optimaal bruikbaar
U.5.1 Ondersteuning bij formulieren: A +
Richtlijn U.6 Meertaligheid: Maak anderstalige content eenvoudig bereikbaar
U.6.1 Taalkeuze: A +
Het mechanisme is reeds aanwezig, maar nog niet alle content is vertaald.
Richtlijn U.7 Geneste weergavekaders: Sluit niemand uit bij het aanbieden van content middels geneste weergave-kaders
U.7.1 Alternatief voor geneste weergavekaders: AA NA Geen iframe e.d. wordt ge-bruikt.
Richtlijn U.8 Identificatie van tekens en symbolen: Speci-ficeer karaktercodering
U.8.1 Specificeer UTF-8: A +
Richtlijn U.9 Openheid: Veroorzaak geen belemmeringen bij 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 zijn
U.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 waarneembaar
Richtlijn 1.1 Tekstalternatieven: Lever tekstalternatieven voor alle niet-tekstuele content, zodat die veranderd kan worden in andere vormen die mensen nodig hebben, zo-als grote letters, braille, spraak, symbolen of eenvoudiger taal
1.1.1 Niet-tekstuele content: A ± Voor content buiten de
plugin, 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 worzou-den als louter-videobeeld con-tent. Momenteel is hiervoor geen alternatief voorhanden.
1.2.2 Ondertiteling voor doven en slechthorenden (vooraf
opgenomen): 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 idem
1.2.5 Audiodescriptie (vooraf opgenomen): AA NA idem
1.2.6 Gebarentaal (vooraf opgenomen): AAA NA idem
1.2.7 Verlengde audiodescriptie (vooraf opgenomen): AAA NA idem 1.2.8 Mediumalternatief (vooraf opgenomen): AAA NA idem
1.2.9 Louter-geluid (live): AAA NA idem
Richtlijn 1.3 Aanpasbaar: Creëer content die op ver-schillende manieren gepresenteerd kan worden (bijvoor-beeld eenvoudiger lay-out) zonder verlies van informatie of structuur
1.3.1 Info en relaties: A - Gebonden aan Google Earth
plug-in
1.3.2 Betekenisvolle volgorde: A ?
1.3.3 Zintuiglijke eigenschappen: A - Gebonden aan Google Earth
plug-in Richtlijn 1.4 Onderscheidbaar: Maak het voor gebruikers
gemakkelijker om content te horen en te zien, waaronder scheiding van voorgrond en achtergrond
1.4.1 Gebruik van kleur: A - Gebonden aan Google Earth
plug-in
1.4.2 Geluidsbediening: A NA
1.4.3 Contrast (minimum): AA - Gebonden aan Google Earth
plug-in
1.4.4 Herschalen van tekst: AA +
1.4.5 Afbeeldingen van tekst: AA NA
Getoonde content is uitge-zonderd onder de noemer ‘essentieel’
1.4.6 Contrast (versterkt): AAA - Gebonden aan Google Earth
plug-in
1.4.7 Weinig of geen achtergrondgeluid: AAA NA
1.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 opmerking
2
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 om content te lezen en te gebruiken
2.2.1 Timing aanpasbaar: A +
1209381-008-ZKS-0001, Definitief, 27 februari 2015
2.2.3 Geen timing: AAA +
2.2.4 Onderbrekingen: AAA +
2.2.5 Herauthentisering: AAA NA Er zijn geen transactionele
acties. Richtlijn 2.3 Toevallen: Ontwerp content niet op een
ma-nier waarvan bekend is dat die toevallen veroorzaakt
2.3.1 Drie flitsen of beneden drempelwaarde: A +
2.3.2 Drie flitsen: AAA +
Richtlijn 2.4 Navigeerbaar: Lever manieren om gebruikers te helpen navigeren, content te vinden en te bepalen waar ze zijn
2.4.1 Blokken omzeilen: A NA
2.4.2 Paginatitel: A +
2.4.3 Focus volgorde: A +
2.4.4 Linkdoel (in context): A +
2.4.5 Meerdere manieren: AA NA
2.4.6 Koppen en labels: AA +
2.4.7 Focus zichtbaar: AA ± Zie Richtlijn 2.1
2.4.8 Locatie: AAA NA
2.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-grijpelijk
3.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; “in casu”, “casu quo”, etc.
3.1.6 Uitspraak: AAA
-Richtlijn 3.2 Voorspelbaar: Maak het uiterlijk en de bedie-ning van webpagina’s voorspelbaar
3.2.1 Bij focus: A +
3.2.2 Bij input: A +
3.2.3 Consistente navigatie: AA + NA
3.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 verbeteren
3.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 NA
3.3.5 Hulp: AAA
3.2.7 Principe robuust
Richtlijn 4.1 Compatibel: Maximaliseer compatibiliteit met huidige en toekomstige user agents, met inbegrip van hulptechnologieën
4.1.1 Parsen: A +
De onderliggende KML zou ook als content kunnen wor-den beschouwd. Zie ook U1.
4
Beheer
Voor het in beheer nemen van applicaties door RWS worden op verschillende aspecten eisen gesteld.
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’s
Om rolverdeling tussen leveranciers van data, software, kennis en de gebruikers daarvan vast te stellen is het gebruikelijk om een stakeholderanalyse uit te voeren. Aangezien de populatie van 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 moet voldoen, 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. De gegevens en indicatoren worden gebruikt in het primaire proces maar zijn niet tijdskritisch. De risicos voor beschikbaarheid van de produktieomgeving zijn bekend en beperkt en er zijn andere systemen 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 Opleiding
Voor het beheren van de multidimensionale database en het beheren van de server zijn diverse vaardigheden vereist. Het gebruik van de kustviewer zelf vereist geen specifieke opleiding. De handleiding 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 en technisch 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 Werkproces
Bij het overnemen van beheer hoort ook een aanpassing van het werkproces.
Binnen RWS, Deltares en N&S zijn systemen beschikbaar om werkproces te faciliteren. Hierbij worden de volgende onderdelen afgedekt. Issue, change, request en problem management is op dit moment in gebruik via het registratie systeem. Er zijn geen issues, changes, requests of problemen gerapporteerd.1
⋄ probleemtypen: bug, verzoek, etc.
⋄ afhandelgroepen: urgentie, verantwoordelijken
Binnen RWS wordt het proces verder nog vormgegeven door een diverse werk procedures. Deze punten 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 werkprocessen kan worden ingevuld is het raadzaam om eerst de rolverdeling conform het bij RWS gebruikte werkproces 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 1
1209381-008-ZKS-0001, Definitief, 27 februari 2015
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 te worden.
4.2 Testbaar
Voor het testbaar maken van de verschillende onderdelen van de applicatie is het van belang dat de 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 zijn unit 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 periodieke testrapporten aangemaakt. Stresstesten en loadtesten worden niet uitgevoerd.
We stellen de volgende activiteiten voor.
⋄ Automatiseren unit testen en integratie en toevoegen systeem testen zodat automatisch testrapporten worden gecreëerd. (3 dagen)
⋄ Invullen document master test plan, inclusief review (5 dagen + review RWS).
4.3 Overdraagbaar
Het 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 te vinden 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
3
https://docs.djangoproject.com/en/dev/topics/testing/
⋄ Er is een summiere beschrijving van de functionaliteit beschikbaar op de wiki5 6en aan-vullende informatie in twee publicaties7 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. Een gebruikershandleiding 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 documentatie9
⋄ 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 componenten nodig. Deze kunnen worden gebruikt om te controleren of er updates nodig zijn als er software verouderd of als er veiligheidsupdates nodig zijn.
⋄ De lijst met vereiste systeem componenten 10 is beschikbaar, evenals de lijst vereiste software componenten is ook beschikbaar11 12(0 dagen)
⋄ Inpakken van de lijst met componenten in een rpm pakket voor de openearth stack (5 dagen).
⋄ 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 het datamodel (logisch en technisch, inclusief relatietypes) beschreven is.
⋄ De definitie van gegevens bronnen13 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 doorgaans de vertaling van uniform resource locator (url)’s naar functies verstaan. De kustviewer biedt een Representational state transfer (REST)-achtige gegevens toegang aan. Hiermee kunnen auto-matisch grafieken voor rapporten worden gegenereerd.
5 https://publicwiki.deltares.nl/display/KV/Kustviewer 6https://publicwiki.deltares.nl/display/KPP/Achtergrondinfo+Kustviewer 7 http://www.vliz.be/imisdocs/publications/241321.pdf 8http://kennisonline.deltares.nl/product/30408 9 https://www.google.com/earth/learn/ 10https://github.com/lizardsystem/lizard-kml 11 https://github.com/lizardsystem/lizard-kml/blob/master/buildout.cfg 12https://github.com/lizardsystem/lizard-kml/blob/master/setup.py 13 https://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
1209381-008-ZKS-0001, Definitief, 27 februari 2015
⋄ De definitie van de interface in code15
⋄ Beschrijving van de rest interface in een word document (3 dagen).
4.4 Betaalbaar
Voor het betaalbaar houden dienen afspraken gemaakt worden binnen RWS en tussen RWS en Deltares. Tussen Deltares en RWS zal voor het functioneel beheer en applicatie- en technisch beheer, voor zover deze nog bij Deltares liggen een SLA opgesteld moeten worden. De afdekking van risicos en serviceniveaus moeten hierin beschreven en afgedekt worden. Het opstellen van 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 dienst moet worden opgenomen in de service catalogus en de extra benodigde beheer capaciteit per jaar (beheerlast) bekend en ingeregeld worden. De verwachte beheerlast kan worden ingeschat op basis van de beheerlast van de afgelopen jaren (ongeveer 40 uur per jaar, TODO checken bij Ankie).
5
Gegevens
Dit hoofdstuk beschrijft zowel de aansluiting op de distributielaag als de checklist open data.
5.1 Aansluiting op toekomstige wijziging in de distributielaag
Als toekomstige distributielaag voor de data, die in de kustviewer wordt weergegeven, is LOL voorzien. 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 beschikbaarheid van LOL en de eisen die aan deze toekomstige data distributielaag gesteld moeten worden om als volwaardig alternatief van de huidige werkwijze aangemerkt te kunnen worden.
5.1.1 Beschikbaarheid distributielaag
Bij 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. De aanvraag bij helpdesk water, doorgestuurd naar servicedesk data, naar het toegangsprotocol van LOL is tot op heden (14 dagen na aanvraag) niet beantwoord. Het is onduidelijk wanneer LOL publiekelijk beschikbaar zal komen.
5.1.2 Eisen aan distributielaag
De snelheid is de belangrijkste maatstaf voor het accepteren van een data distributielaag als backend van de kustviewer. Om aan de gebruikseisen van een viewer te beantwoorden moet de opgevraagde data snel weergegeven kunnen worden. Om de snelheid te kunnen testen wordt het aantal geleverde JarKus raai-tijd combinaties per tijdseenheid als maatstaf gekozen. In de huidige situatie kan de netCDF data zoals deze via internet via de OpenEarth thredds server opgevraagd wordt tevens in identieke vorm lokaal gecached worden.
0
500
1000
1500
2000
2500
3000
Cross shore distance [m]
1972
1985
1999
2013
Measurement time [y]
Figuur 5.1: Voorbeeld van raai-tijd combinaties
Via het internet kunnen 50 raai-tijd combinaties binnen orde 1 seconde geleverd worden. Vanuit de lokale cache kan dit in ruim 2 milliseconde (500x sneller). Als LOL publiekelijk beschikbaar is, moet het de snelheid van orde 1 seconde minimaal kunnen evenaren om als volwaardig alternatief te kunnen worden aangemerkt. Daarnaast is uiterst wenselijk om een lokale cache in identieke vorm (t.o.v. de online bron) te kunnen bewaren, aangezien hiermee de kans op fouten
aanzienlijk kan worden verkleind.
5.2 Open Data
De kustviewer is opgezet om alle data van de Nederlandse kust beschikbaar te maken voor een een breed publiek.
De kustviewer is op dit moment gesloten. Het gebruik is geënt op een klein aantal professionele gebruikers. De viewer is in de huidige vorm niet geschikt voor breed gebruik door alle eventuele geïnteresseerden. Tevens kan een deel van de ontsloten informatie verkeerd geïnterpreteerd worden zonder goede toelichting.
Om de kustviewer weer openbaar te maken wordt de juridische check uitgevoerd1. 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 zijn medegedeeld
⋄ indien het bijzondere persoonsgegevens betreft
Wat betreft veiligheid kan gedacht worden aan de gegevens om en nabij de kerncentrales van Petten en Borssele. Op dit moment zijn de kustgegevens in de nabijheid van de kerncentrales niet 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 de aanleg van de maasvlakte en de aanleg van de zandmotor. Door metingen van tijdens de aanleg te verzamelen kan de werkwijze van baggeraars ongewild openbaar gemaakt worden. We gaan er 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 derden
Een 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 overheid is 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 kan een nieuwe eigenaar ontstaan. Hierdoor is het eigendom niet eenvoudig vast te stellen. Deltares en 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
1209381-008-ZKS-0001, Definitief, 27 februari 2015
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 data concrete afspraken te maken. Deze afspraken hoeven echter niet binnen dit project gemaakt te worden maar in lopende raamafspraken.
5.2.2 Concurrentievervalsing
Het verkrijgen van de data van de kustviewer en de bijbehorende kengetallen valt binnen het primaire proces van RWS. Voor gegevens die vergelijkbaar zijn aan de gegevens gebruikt in de kustviewer, bijvoorbeeld Actueel Hoogtebestand Nederland versie 2 (AHN2) en de luchtfoto’s door het kadaster, is gebleken dat dit soort gegevens open gemaakt kunnen worden, ook al zijn er commerciële partijen die vergelijkbare datasets commercieel aanbieden.
5.2.3 Verwachtingen
Bij de datasets dient duidelijk gemaakt te worden wat het doel, kwaliteit en context van de data is. Deze informatie is niet voor alle datasets compleet. Dergelijke informatie wordt bijgehouden op de websitedata.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) via hetdata.overheid.nl portaal beschikbaar te stellen. Deze informatie wordt nu, conform de ISO19115 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 de kustviewer.
⋄ Maak concrete afspraken over het eigendom van data, afgeleide data en data producten die 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 dedata.overheid.nl(actiedata.overheid.nl)
6
Adviezen
6.1 Scenario’s
Uit 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 (browser plugins, zoals Google Earth worden uitgezet door fabrikanten).
Om de doorwerking hiervan wat duidelijker te maken schetsen we drie scenario’s voor het in beheer nemen van (delen van) de kustviewer.
We maken weer onderscheid tussen het overdragen van de opwerking van data, het serveren van 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 binnen Deltares aanwezig is.
6.1.1 RWS als beheerder
Het in beheer nemen van de applicatie door RWS vereist het overnemen van drie taken: het serveren van de data, de applicatie ontwikkeling en hosting en het beheer van de viewer.
Onderhouden
Data 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 manament voor het beheer van de ge-gevensverzamelingen, systeembe-heer, voor het beheer van de grote hoeveelheid computer capaciteit en kennis van de volledige stapel van ontwikkeltools (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) tot kengetallen 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 het maken 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 is alle software die Rijkswaterstaat gebruikt en Deltares ontwikkelt al aangepast aan de bouwstenen catalogus van RWS. In de SLA voor het modelinstrumentarium staat immers:
Alle nieuw te ontwikkelen applicaties dienen te voldoen aan de architectuureisen en de bouwstenencatalogus van de RWS CIV. Deltares dient zich te allen tijde te verzekeren dat de systemen die men voor Rijkswaterstaat ontwikkelt, passen op de Technisch 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 die worden gebruikt sluiten aan bij wat mensen kennen. De software wordt bijvoorbeeld geschreven in 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 van de indicatoren en opgewerkte metingen. Het overnemen van de applicatie kan later. Voor het overnemen van de viewer is het raadzaam te wachten tot de technieken die gebruikt worden om de kust in 3D en in de tijd in beeld te brengen uitgekristalliseerd zijn.
6.1.2 Deltares als beheerder
Een 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 Deltares uitgevoerd 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 ontwikkeling van de kustviewer vereist domein en technische kennis die vooral bij Deltares aanwezig is.
Onderhouden
Data opwerken Data opwerken
Figuur 6.2 Omdat uit paragraaf 2.4 bleek dat
het met de huidige technieken niet mogelijk is om dezelfde functionali-teit aan te bieden moet er een nieuw ontwerp gemaakt worden. Te den-ken valt aan het aanbieden van een 2D kaart + tijd voor een deel van de functionaliteit (overzicht suppleties, kustlijnen) en een regionale 3D om-geving voor het andere deel van de functionaliteit (kust lidar, drone data, profielen).
Een andere optie voor het herontwerpen van de viewer is het uitstellen van het nieuwe ontwerp tot de technische mogelijkheden voor het weergeven van 3D ruimtelijke data via het web zijn uitgekristalliseerd.
1209381-008-ZKS-0001, Definitief, 27 februari 2015
6.1.3 Kustviewer herverdelen
Als derde scenario is het te overwegen om de kustviewer te herverdelen. Sinds de kustviewer initieel ontwikkeld werd zijn er diverse andere viewer initiatieven gestart.
Hierbij kan zowel gedacht worden aan het herverdelen van de applicatie als de viewer.
Onderhouden
Data opwerken Data opwerken
Figuur 6.3
Omdat de broncode van de kustvie-wer onder een open licentie (GNU General Public License version 3 (GPLv3)) is, is het voor anderen mo-gelijk om de representaties (webpa-gina’s, kaartlagen en grafieken) die door de kustviewer worden gebruikt na te bouwen of over te nemen. Het vereist wel enige domein kennis en een ontwikkel omgeving die het ma-ken van geavanceerde grafiema-ken op basis van ruimtelijke tijdsafhankelijke data ondersteund.
Op dit moment zijn er alleen al voor de Nederlandse water toepassingen enkele tientallen viewers in gebruik. Omdat juist het viewer gedeelte moet worden herzien valt het te overwegen om de kust 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’s
Van de scenario’s valt alleen voor het Deltares Beheer scenario een duidelijke kosten schatting te geven. Op basis van een kostenschatting van het ontwerp van de huidige viewer schatten we dat het ontwerp van de vervanging van de viewer ongeveer hetzelfde zal kosten, dat wil zeggen in de orde van 100k EUR.
Bij de andere scenario’s komen de kosten terecht bij andere organisaties, bij RWS voor het eerste scenario en bij nog te bepalen partijen voor het herverdeel scenario.
6.2 Overige adviezen
Voor een goede aansluiting bij de in de markt ontwikkelde toepassingen en de bouwstenen ca-talogus is het van belang dat de bouwstenen caca-talogus 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 in het 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. URL http://proceedings.utwente.nl/177/. 1
Damsma, T., F. Baart, G. de Boer, M. V. Koningsveld and A. Bruens, 2009. “Visualization of coastal data through KML.” In Virtual Globes at AGU. URLhttp://adsabs.harvard.edu/ abs/2009AGUFMIN43A1131D. 1
Engels, J., J. Drenth, H. Bruijn and T. Gerritsen, 2012. Bouwstenen Catalogus DID IAP Generiek Hard 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 the visualization of marine and coastal data.” In International Conference on Marine Data and Informatics. 1
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
