Open Source GIS Strategie

Inleiding

Het huidige GIS Platform van Rijkswaterstaat is sterk geënt op de software van Esri (ArcGIS Enterprise), de combinatie Vertigis + Sweco + Esri Nederland (GeoWeb), en Safe Software (FME). Er is ook een open source deel gebaseerd op GeoNetwork en GeoServer, maar dit speelt op dit moment een enigszins ondergeschikte rol.

Met de opkomst van cloud computing speelt schaalbaarheid een grotere rol, maar heeft schaalbaarheid ook gevolgen voor de licentiekosten van de software. Schalen met proprietary software kan een dure exercitie worden, afhankelijk van hoe de licentiestructuur precies in elkaar zit. Hier biedt open source software in de regel kansen. Daarnaast zijn onafhankelijkheid en soevereiniteit belangrijk niet alleen in de ICT strategie van Rijkswaterstaat maar ook in de bovenliggende architectuur documenten.

Ook het model dat IVP hanteert, een OTAP (Ontwikkel Test Acceptatie Productie) straat as-a-service, heeft veel gevolgen voor licentie kosten, aangezien je op elke omgeving de licentiekosten betaald. Dit betekent ook dat er soms concessies gedaan worden waarbij afnemers op onze lab omgeving iets testen, aangezien even een nieuwe omgeving erbij opspinnen voor een test te duur is.

Aan de database kant lijkt de open source database (PostgreSQL met PostGIS extensie) inmiddels zo’n beetje de de facto standaard te zijn binnen Rijkswaterstaat.

Met betrekking tot open source moet niet vergeten worden dat licentiekosten slechts een onderdeel zijn van de Total Cost of Ownership (TCO). Andere kosten, zoals beheer en onderhoud, training, betalen voor nieuwe functionaliteit of funding initiatieven voor grote wijzigingen, moeten ook in beschouwing genomen worden. Een goede beschouwing van open source getiteld “The True Value Of Open-Source Software Isn’t Cost Savings” is hier beschreven.

In bovenstaande figuur is een overzicht weergegeven van de ABB’s van het GIS Platform gerangschikt naar de verschillende tiers. Ook is middels de lijnkleur een classificatie gemaakt naar:

• ABB’s die alleen in het open source deel van het GIS Platform beschikbaar zijn – oranje lijnkleur;
• ABB’s die alleen in het proprietary deel van het GIS Platform beschikbaar zijn – rode lijnkleur;
• ABB’s die in beide delen van het GIS Platform beschikbaar zijn, dit betekent dat er ten minste 2 SBB's zijn – paarse lijnkleur.

Wel dient opgemerkt te worden dat QGIS, een open source Desktop GIS, zich op het moment van schrijven nog in de POC fase bevindt.

Uitgangspunten

Uitgangspunt 1: Voortbouwen op bestaande componenten

Het ligt niet voor de hand om bijvoorbeeld GeoServer te vervangen door QGIS Server. Het te selecteren Web GIS platform moet dus goed aansluiten op GeoServer (en GeoServer Cloud).

Uitgangspunt 2: Aansluiten op infrastructuur RWS

Het ligt voor de hand om componenten te selecteren die schaalbaar en cloud-ready zijn, zodat ze naadloos in de RWS hybride private cloud infrastructuur passen.

Uitgangspunt 3: Waar mogelijk aansluiten op andere platformen

Het ligt voor de hand om componenten te selecteren die, waar mogelijk, goed kunnen integreren met de andere platformen van IVP, zoals Business Intelligence (BI), Data Suite (Greenplum) of het Integratie platform.

Uitgangspunt 4: Er is geen budget beschikbaar

De nieuwe componenten moeten in principe budget neutraal geselecteerd worden. Dus dit gaat in principe uit van een open source licentie en interne ondersteuning initieel. Dit betekent dus dat oplossingen zoals GeoApps of GeoNovation KaartViewer Suite niet worden meegenomen. Op den duur kan er budget worden vrijgemaakt door besparingen door te voeren op bestaande licenties.

Uitgangspunt 5: Zorg voor een goed functioneel kader

Zorg voor een goed functioneel kader op basis waarvan de keuze tussen de verschillende bouwstenen van het GIS platform objectief gemaakt kan worden. Wanneer wordt wat ingezet?

Uitgangspunt 6: Zorg voor goede ondersteuning en (interne) opleiding

De inzet van meer open source wordt alleen succesvol als er meer ingezet wordt op goede (interne) ondersteuning en opleiding, zodat de teams die er projecten mee moeten uitvoeren succesvol kunnen zijn.

SWOT analyse

Op het gebied van open standaarden ligt er een sterkte bij de open source GIS implementaties. Ook als we kijken naar cloud ligt hier een voordeel, gezien het feit dat we kunnen schalen zonder dat dit impact heeft op de licentiekosten.

Waar het proprietary platform goed in is betreft de meer complexe use cases, de aansluiting van de verschillende software componenten op elkaar, maar ook opleidingen, support, marketing etc. Dit zijn traditioneel gebieden waar open source GIS wat zwakker in is. In het geval van open source komt er meer verantwoordelijkheid te liggen bij het technisch applicatie beheer (TAB), maar Rijkswaterstaat is wel in het bezit van een competent TAB team.

GeoServer heeft al een goede integratie met de Esri desktop (ArcGIS Pro) middels GeoCat Bridge. Dit vormt letterlijk dus een brug tussen beide omgevingen.

Functionele analyse

Als we puur functioneel kijken dan missen er momenteel een aantal zaken aan de open source kant. Het is niet de verwachting en ook niet de noodzaak om functioneel alles af te dekken wat het proprietary deel van het platform kan, maar het zou een streven kunnen zijn om grofweg 80% van de (meer eenvoudige) use cases af te kunnen dekken, waarbij het complexere deel van het spectrum overgelaten wordt aan het proprietary deel van het platform. In eerste instantie kan daarbij gedacht worden aan mobile / field collection, versioning, A0 print, workflows etc.

De belangrijkste omissie nu is een Web GIS Platform, wat op basis van GeoServer Web GIS applicaties kan bouwen. Qua behoeften is er een spectrum tussen een bibliotheek waarmee ontwikkelteams zelf applicaties kunnen bouwen, versus het middels een wizard in elkaar kunnen draaien van een complete Web GIS applicatie met onderliggende data lagen.

Functioneel gezien is het ook van belang om de verschillende losse componenten goed aan elkaar te knopen / lijmen, en te zorgen dat ze tezamen een functioneel geheel vormen, in plaats van losse componenten. QGIS en de GeoCat Bridge extensie voor QGIS kunnen hierin ook een rol spelen. Denk bijvoorbeeld aan het kunnen openen van een Web Map die in ArcGIS Portal is aangemaakt in ArcGIS Pro, dit zijn functionaliteiten die in principe lastiger te realiseren zijn met losse open source componenten.

Voor het Web GIS Platform wordt er binnenkort een pilot gedaan met MapStore en Shogun. Aan de bibliotheek kant zou je kunnen denken aan OpenLayers voor 2D en Cesium voor 3D. De case voor Leaflet als eenvoudige additionele viewer is moeilijk te maken als je ook andere wat meer complexe applicaties bouwt met OpenLayers en het feit dat OpenLayers in principe inmiddels zo modulair is opgezet dat je daarmee ook een uitgeklede versie kan maken. Maar het is wel een feit dat er binnen Rijkswaterstaat momenteel ook web applicaties met Leaflet voorkomen. Voor bibliotheken is het misschien handig om een manier te bieden waarop ontwikkeltrajecten hun plugins / controls e.d. met elkaar kunnen uitwisselen, zodat hergebruik van maatwerk gestimuleerd wordt. Er kan misschien ook kennis uitgewisseld worden tussen verschillende ontwikkel projecten. Een goed voorbeeld hiervan is de ol-ext bibliotheek van IGN France.

Aan de ETL kant wordt zowel door het BI team als door het GIS platform team gekeken naar Apache Airflow als een mogelijke toekomstige bouwsteen.

Vervolgstappen

Om het fundament goed te leggen, is het van belang om GeoServer op een kubernetes omgeving te deployen. Idealiter kunnen we de tussenstap van CNAP Kubernetes overslaan en meteen landen op het hybride private cloud platform. Dit zou een robuuste omgeving neer moeten zetten voor de GIS motor van het open source deel van het GIS Platform. In de cloud versie van GeoServer zijn een aantal pijnpunten opgelost van de standaard GeoServer, zoals de catalog (opstarttijd).

Voor het uitserveren van RWS open data (GDR), wat nu met een mix van open source en ArcGIS Server gedaan wordt (vanuit een unfederated omgeving in de DMZ), zou er overwogen kunnen worden om dit alleen middels GeoServer en open standaarden te doen, en de ArcGIS MapService en FeatureService uit te faseren op termijn. Dit zou zeker een optie kunnen zijn als de nieuwe moderne OGC API standaarden meer gemeengoed zijn geworden, ook binnen een Esri omgeving.

Het zou mooi zijn als QGIS de POC fase kan ontstijgen, en we de functionele grens goed kunnen definiëren tussen QGIS en ArcGIS Pro. Bridge voor QGIS kan ook een rol spelen in het koppelen van verschillende losse componenten uit het open source eco systeem. Er zijn ook ontwikkelingen om Desktop GIS naar een web-based platform te krijgen, maar dit is meer op de wat langere termijn.

Op een wat meer middellange termijn moet er ook ingezet worden op het uitserveren van data in cloud native formaten (Geoparquet en COG etc.), zodat GIS servers minder benodigd zijn voor het uitserveren van data.

Conclusie

Meer keuze vrijheid, lees meerdere SBB’s per ABB, is in principe een goede zaak. Een hybride eco systeem leidt ook tot betere koppelvlakken, idealiter op het gebied van open standaarden. Er wordt vaak naar open source gekeken op basis van kostenbesparingen, maar er zijn zeker ook andere voordelen, maar realistisch gezien kunnen er ook nadelen zijn op bepaalde aspecten. Een totaal afweging is dus noodzakelijk.

Het belangrijkste functionele hiaat in het open source deel van het GIS Platform is momenteel een Web GIS. Dit loopt uiteen van een bibliotheek / zakmes tot en met een wizard achtige toepassing om Web GIS applicaties te kunnen bouwen. Wel is het van belang om ook te zorgen dat de  RWS deployment van de motor, GeoServer, zo snel mogelijk geschikt wordt gemaakt voor het hybride private cloud platform op basis van GeoServer Cloud. Momenteel wordt de standaard GeoServer deployment gebruikt binnen CloudFoundry (CNAP), uiteindelijk zal dit toe moeten naar het op microservices gebaseerde GeoServer Cloud in een Kubernetes deployment binnen het hybride private cloud platform.

Zelfs op het gebied van Esri applicaties versus GeoWeb applicaties is er momenteel niet echt een duidelijk scheidingsvlak / kader. Wanneer wordt bijvoorbeeld Experience Builder ingezet, of een Web Map op Portal, of ArcGIS Instant Apps, versus GeoWeb. Na toevoeging van een open source Web GIS bouwsteen moet hier misschien over het geheel bezien een keer goed over nagedacht worden, wanneer wat in te zetten zodat er consistente keuzes gemaakt kunnen worden.