FOSS4G 2022 general tracks

Matthias Mohr

Software engineer working on geospatial ☁ solutions. Working on openEO, openEO Platform and STAC for the University of Münster and as freelancer.

The speaker's profile picture


openEO: Open Science for Earth Observation Research
Edzer Pebesma, Matthias Mohr

The open standards, open source geospatial and open science communities still have a very limited answer to the question how researchers active in applied domains such as agriculture, ecology, hydrology, oceanography or land use planning can benefit from the large amounts of open Earth Observation (EO) data currently available. Solutions are very much tied to platforms operated and controlled by big tech (Earth Engine, Planetary Computer), particular programming languages, software stacks and/or file formats (xarray, Pangeo, ODC, GeoPySpark/GeoTrellis). The openEO initiative provides an API and a set of processes that separate the “what” from the “how”: users specify what they want to compute, and back-end processing engines decide how to do this. The openEO API is OpenAPI compliant, and has client interfaces for Python, R, and JavaScript, and in addition graphical user interfaces running in the browser or in QGIS. The underlying data model is that of a data cube view: image collections or vector data may be stored as they are, but are analysed as if they were laid out as a raster or vector data cube, e.g. for raster with dimensions x, y, band and time, or for vector with dimensions geometry, band and time. Because openEO assumes that imagery is described as STAC collections and the implementation is composed of open source components, it is relatively easy to set it up and compute on infrastructure where imagery is available through a STAC interface. Having a single interface to carry out computations on back-ends with different architecture makes it possible to compare results across implementations, to verify that EO processing is reproducible. So far, over 100 processes have been defined, and user-defined functions written in Python or R extend this ad infinitum. openEO was initially developed during a H2020 project (2017-2020). It is currently continued with ESA funding that has resulted in the “openEO Platform”, an implementation run by VITO and EODC where the general public can use the openEO interface for large scale computations. Several upcoming Horizon Europe projects will further support continued development of the API and openEO software ecosystem of clients and back-ends. Since the initiative is designed to be an open science, all users and developers are invited to engage. We will present the current state of the openEO ecosystem and give an outlook to forthcoming developments.

A European approach to geospatial open source
Cloud-Native Geospatial with JavaScript
Daniel J. Dufour, Matthias Mohr

The amount of Earth Observation data we have available nowadays is exceeding the capabilities for data processing. Therefore, a lot of data is now made available in the cloud. To make digesting the data easier and more-lightweight, it is getting more and more popular to store the data in so-called “cloud-native” file formats while data processing is also moving towards the data, i.e., into the cloud. This way you only need to retrieve the actual subset of the data you are actually interested in instead of the full data set, which can be in the magnitude of gigabytes or even larger. This technology of cloud-native file formats is usually best used with Browsers, which is the users’ main interface to the internet and the cloud. There the main language is JavaScript. Therefore, this talk will give a high-level introduction about the relevant cloud-native file formats and show whether and how you can make use of these files in client-side JavaScript:

  • COG: Cloud-Optimized GeoTiff ( )
  • COPC: Cloud-Optimized Point Clouds ( )
  • Flatgeobuff ( )
  • GeoParquet ( )
  • STAC: SpatioTemporal Asset Catalog ( )
  • Zarr ( )

This talk will dig into the available open-source libraries and, if JavaScript implementations are available, show their functionality based on examples. If multiple options are available, a high-level comparison will show the main differences in functionality. For COGs for example, we’ll compare the capabilities of the popular mapping libraries Leaflet, OpenLayers and MapLibre GL.

State of software
Room Onice