Aansluiten op OpenShift en het oplossen van de huidige uitdagingen hierin:
- GeoWeb Modules (gebaseerd op Vertigis) werkt nog niet volledig met ArcGIS for kubernetes (Access Control, Analytics)
- GeoWeb Modules gaat wel langzaam toe naar het beschikbaar stellen van containers (Docker), maar orchestration (k8s) gaan zij niet verzorgen
- FME is in principe OpenShift ready, maar de Esri geodatabase drivers voor FME zijn alleen beschikbaar op Windows, dit betekent dat grofweg 80% van onze workflows nog steeds op Windows VMs moeten blijven draaien via queue control
- ArcGIS for kubernetes ondersteunt nog geen server extensies, zoals Maritime die wij gebruiken
- ArcGIS for kubernetes kan geen named user licenties uitwisselen met huidige ArcGIS Enterprise, dus mogelijk dubbele named user licenties? Mogelijk oplosbaar in ELA.
- GeoServer cloud is in principe productie rijp en beschikbaar, alleen om het in OpenShift draaiend te krijgen zal beheerteam kennis moeten opdoen, tussenstap via CloudBoostr is logisch
- voor GeoNetwork heeft GeoCat op de FOSS4G in Nieuw-Zeeland een presentatie gegeven (er zijn nog wel veel known issues / quirks, vermoedelijk worden die pas in GN5 opgelost), in het kader van GeoCat Live. Maar onduidelijk of we hier zo maar de beschikking over krijgen vanuit onze ELA of dat dit extra kosten met zich mee gaat brengen. Tussenstap via cloudboostr. Misschien kosten afweging tussen SaaS en on premise?
- Beslissing nemen over self-service market place, lab omgeving opspinnen wanneer nodig
Uitbreiden open source componenten, zowel in het kader van exit strategie als het potentieel verminderen van licentiekosten aan de proprietary kant, en het vergroten van de digitale autonomie:
- moet aansluiten op bestaande componenten zoals GeoServer en GeoNetwork
- QGIS is aan de desktop kant een logische keuze, wel zullen we uiteindelijk nog moeten kijken naar een betrouwbare helpdesk analoog aan GeoCat voor GeoServer en GeoNetwork. Ook goed kijken hoe we QGIS kunnen integreren in een hybride systeem zodat het niet als losse component op zichzelf staat
- Zorgen dat we een alternatief hebben voor de dure use case aan de Esri kant, editen van geodata via vele named users en daarbij vast kunnen stellen wie wat gewijzigd heeft en wanneer
- Zorgen dat we enterprise features (e-herkenning, SSO, integratie met keycloak) ook aan kunnen bieden aan de open source kant zodat we daadwerkelijk 80% van de use cases aan kunnen, en alleen het echt moeilijke werk aan het proprietary platform over hoeven te laten
- Mogen we er een proprietary alternatief naast zetten dat goedkoper is, of alleen pure open source oplossingen?
Soevereiniteit:
- We zijn in principe volgend op wat er binnen de overheid besloten wordt
- We moeten ook nog beslissing nemen of we GeoWeb in de DMZ koppelen aan ArcGIS Portal in de DMZ of ArcGIS Online
- Positionering ArcGIS Online heroverwegen, misschien alleen in het geval van externe samenwerking (al kan dat straks ook via e-herkenning)
Meer open standaarden:
- we zijn te afhankelijk van ArcGIS REST
- binaire proprietary opslag (ST_GEOMETRY) in de database leidt tot allerlei problemen, maar is lastig oplosbaar
- streven naar meer inzet van OGC APIs
- meer inzet van cloud native geo formaten zoals Geoparquet, DuckDB, GeoArrow, STAC, COG en GeoZarr
Verantwoorde inzet van generatieve AI:
- rekening houden met wet - en regelgeving
- niet als doel maar als middel
- op een veilige manier
- data kwaliteit en metadata worden meer belangrijk
- aandacht voor MCP (Model Context Protocol) en goede APIs die AI agents kunnen inzetten
Betere ondersteuning voor machine learning:
- ArcGIS Raster Analytics on Kubernetes lijkt een kandidaat als we naar OpenShift gemigreerd zijn
- Aan de desktop kant waarschijnlijk het probleem van geen GPUs op RWS laptops (komt er in OpenShift iets soortgelijks als Google Colaboratory?)
Het goed bedienen van de data scientist:
- ondersteuning voor Jupyter notebooks, mogelijkheid is er wanneer we naar ArcGIS for Kubernetes gaan onder OpenShift
- goede integratie met data warehouses / data analytics platformen (zie hieronder)
- ondersteuning voor moderne cloud formaten, niet geo-specifiek
- integratie met algemene data science platform dat in OpenShift gebouwd gaat worden
Betere ondersteuning voor MKS/MKO:
- huidig platform niet echt geschikt, beperkt high availability (FME, open source, maar niet echt aan de Esri kant)
- OpenShift / kubernetes biedt hiervoor zeker kansen
Metadata vraagstuk:
- rol van GeoNetwork versus CTD, blijft GeoNetwork wel bestaan of in afgeslankte vorm? Misschien minder team resources richting GeoNetwork omdat e.e.a. onzeker is. Vraagstuk ligt grotendeels buiten IVP.
- we moeten richting GeoDCAT ondersteuning in het geval dat GeoNetwork wel relevant blijft
Meer verschuiving naar de browser:
- er zal nog meer functionaliteit verschuiven van de desktop naar mobiel en web
- veel field collection is uitbesteed aan marktpartijen
Aansluiting op digital twin en federatief datastelsel
Strategie voor integreren met data warehouses / data analytics platformen (zowel aan de open source kant als de proprietary kant)
- strategie van Esri lijkt gebaseerd te zijn op de inzet van de GeoAnalytics Engine, waarbij data niet gekopieerd hoeft te worden. Maar greenplum wordt niet ondersteund.
Mirror provenance
- Mirror source
- confluence/spaces/INFRAARCH/pages/226270657/page.metadata.json
- Storage source
- confluence/spaces/INFRAARCH/pages/226270657/page.storage.xhtml
- Access
- Committed snapshot only