Carmen Tawalika
Carmen finished her studies in geography where she learned about spatial data and the matching software. She is a passionate geographer and loves traveling the world. After teaching remote sensing to other students and writing her bachelor thesis about a german spatial data exchange format, she started working for mundialis using and creating OSGeo software. One of these is actinia, to which Carmen actively contributes. She is an open source devotee and was very happy to take part in the FOSS4G 2016 organization team for Bonn. She is an OSGeo Charter Member since 2019.
Sessions
„Hello again, my name is actinia. Still new to OSGeo and a Community Project since 2019, you might have heard about me already. In short I am a REST API on top of GRASS GIS to allow location, mapset and geodata management and visualization as well as execution of the many GRASS GIS modules and addons. Processing with other tools like GDAL and snappy is supported as well. I can be installed in a cloud environment, helping to prepare, analyse and provide a large amount of geoinformation. Besides these facts about me there is also a lot to tell about what happened last year! Besides vector upload, citable DOI, QGIS and python client implementations and more, I can be a Spatio Temporal Asset Catalog myself with the actinia-stac-plugin, am able to use data registered in a STAC for processing and after processing register the resulting data. With the ongoing development of the openeo-grassgis-driver, you can use this new functionality either in my native language or via openEO API. To learn about the details, come on over!“
All of us involved in the creation and publication of large amounts of geodata are familiar with the complexities of data management. In the case of geodata created with GRASS GIS, we asked ourselves how they could be made accessible to GeoServer without duplication. To overcome the previous limitation of GRASS GIS having its own data format, we connected the tribes and let Java and C/Python communicate with each other. So the challenge was to be able to efficiently read the GRASS GIS database directly with GeoServer. And why is that? Because this directly links the analytical capabilities of GRASS GIS with the exceptional geo service & publishing capabilities of GeoServer.
Our approach is to use the existing GDAL-GRASS bridge, and add this bridge as a new extension to GeoServer. To this we add two new GRASS GIS addons (r.geoserver.style + r.geoserver.publish) to easily publish the data from a GRASS GIS session as an OGC service. The new GeoServer GRASS raster datastore allows to use GRASS raster data directly in a GeoServer instance. In this way it is now very easy to publish GRASS data as a web service via GeoServer without having to export the data from GRASS GIS to GeoTIFF or COG files. This works for both classic raster data and also for timeseries which can e.g. be inspected as a WMS Time.