Use-cases en testscenario’s voor Geospatial Cloud Native Computing

Toepassingen
1

De digitalisering van geo-informatie evolueert richting cloud-native technologieën. Deze ontwikkeling biedt grote kansen: schaalbaarheid, flexibiliteit, snelle innovatie en toegankelijkheid van data en diensten. Maar er zijn ook nog veel vragen over cloud-native standaarden en techniek.

Geonovum werkt samen met CLOUD-NES in een onderzoek naar Cloud-native geospatial data en tools. Het doel is om inzicht te krijgen in hoe geodata, analyses en tooling zich gedragen in een cloudomgeving. Hiermee wenst het onderzoek kennis op te doen en te delen over het gedrag, de presentaties en de toepasbaarheid van de techniek.

Voor bovenstaand initiatief is Geonovum benieuwd naar input op de volgende 3 vragen:

  1. Welke geospatiale use-cases/scenenario’s zijn relevant om te testen?
    Dit kunnen zijn:
    * elementaire (atomaire) operaties
    * gehele domeinspecifieke workflows

  2. Welke datasets stel je voor hierin te gebruiken?
    Momenteel is in beeld:

    data formaat Data Type Current formats comments
    AHN Point Cloud Raster (single-band) LAZ/COPC GeoTIFF/COG COG only for one version
    Aerial photography Raster (multi-bands) GeoTIFF CORS not enabled
    Daily precipitation Tensor NetCDF Available via custom API
    HARMONIE Cy43 meteorological aviation forecast parameters Tensor NetCDF Available via custom API
    Tropomi/S5P - H2O/HDO product Tensor NetCDF Available from dCache

    *Er ontbreekt nog een vector-dataset.

  3. Welke formaten en/of tooling zou je graag getest zien?

    Momenteel is in beeld:

    data formaat Virtual Cube Tools
    Original (GeoTIFF/NetCDF) STAC stackstac, odc-stac, rasteret, xcube-stac
    Original (GeoTIFF/NetCDF) Zarr kerchunk, VirtualiZarr, Zarr-python, Icechunk
    Original (GeoTIFF/NetCDF) VRT GDAL (rasterio, rioxarray)
    COG (tiles) STAC stackstac, odc-stac, rasteret, xcube-stac
    COG (single file) - GDAL (rasterio, rioxarray
    Zarr - Zarr-python, Icechunk

We horen graag jullie ideeën voor 20 juni 2026. Eventueel kunnen we deze meenemen in de vorming van één of meerdere testbeds. Je kunt voor een reactie contact opnemen met Rolf Jonker of hieronder een bericht achterlaten.

1 like
2

Bij de formaten mis ik nog geoparquet, flatgeobuf, flatcitybuf.

3

Een interessant project!

In lijn met VRT is er ook VPC om COPC puntenwolken aan elkaar te plakken. De TU Delft heeft hier ervaring mee en een proof of concept voor het AHN.

4

Ik zag op jullie Open Geodag een mooie keynote presentatie over kansen voor Cloud-native: Portolan — Cloud-Native SDI | Open Geodag 2026 . Het betoog was dat een Spatial Data Infrastructure (SDI) voor een land idealiter schaalbaar en soeverein is, en (ook) gericht op voor de AI-tools (ipv downloads voor mensen). Volgens mij werd daar al een voorschot genomen met de conversie van datasets naar geoparquet; verschillende datasets die op PDOK als download of service worden aangeboden zijn geconverteerd en gepubliceerd als geoparquet en geïndexeerd als STAC. De spreker gebruikte een claude “skill” om vervolgens vragen te stellen/dashboards te genereren over vragen die met ruimtelijke overlap van verschillende datasets te beantwoorden zijn.

Ik zou zeggen; pak deze handschoen op en maak een zo compleet mogelijke parallelle, cloud-native variant van PDOK op basis van de open source software die daar gepresenteerd werd (en breid deze software waar nodig uit). En onderzoek dan waar het handig is het om dit alternatief te gebruiken.

Een andere suggestie is; kijk naar de specificaties en standaarden waar geonovum aan (mee)werkt/ondersteunt, en bedenk of daar ook een cloud-native implementatie/specificatie van te maken is. Neem bijvoorbeeld inspire waar veel data in XML/GML wordt gepubliceerd; dit worden monsterlijk grote XML bestanden zonder index en moeten in zijn geheel ingeladen worden voordat er ook maar 1 relevant object getoond kan worden (QGIS heeft het er zwaar mee). De conceptuele schema’s staan los van XML-schema. Als dit omgezet kan worden voor geoparquet bestanden en er geoparquet en/of pmtiles bestanden voor gepubliceerd worden op een https http-range-capable CORS-enabled endpoint, dan kan het publicatie-pad wellicht sneller/efficiënter.