Earth Observation Product Metadata Mapping to STAC
Contributors
Description
The standard for Spatio-Temporal Asset Catalogs (STAC) has matured and is widely being adopted. Capabilities, extensibility and tool support go beyond the existing OGC EOP, OpenSearch and OData standards. Implementing a catalogue with interfaces according to a standard requires good specifications and examples. This always has been an area for improvements. The OGC EOP standards have undergone a series of evolutions to become adult, onto which young STAC standard is still on the way. With a little help, the young apprentice will soon overtake its master. In this paper two areas of improvements and suitable solutions are presented: a) provide an overview of the metadata specification and b) provide a generic tool for metadata mapping and extraction.
OGC provides a good path to setup, present and maintain the specifications for standards. On the other hand, good specifications on complex subjects become difficult to read, especially if the standard bases on other standards. Quickly the content gets obscured by a complexity of inheritance and distributed information. We extract the structure of the metadata specified over several documents into one table to serve as an overview. Such a table then also serves as a checklist and can be extended with mapping columns to other related standards. For example, in this case depicting the complete EOP metadata structure and providing a mapping to STAC.
Creating STAC metadata is simple, just run the specific stac-tool on the target data product and voilà, it outputs the JSON file for it. This works for many earth observation product types from the Copernicus Sentinel missions, over Planet datasets and many other datasets with a large community support. But here it ends, the extracted STAC metadata has been implemented to suit specific needs, but covers only a fraction of the full metadata available for a product. New products require coding their own stac-tool, which can be a challenge if you have a variety of products to manage. Searching for exhaustive STAC examples is often fruitless, in many cases you only get excerpts of what is possible. Some of the examples stem from STACs childhood and contain errors perpetuated in early implementations of the stac-tools. Having an overview of the full EOP or STAC metadata specification makes it easier to detect historically grown inconsistencies.
The tabularized metadata specification allows cross-checking the available metadata for any product source and enables creating mapping tables to generate consistent and conform JSON STAC metadata output. This has led us to create a python library that is able to read data products in multiple formats like ZIP, gzip, tar, SAFE, NetCDF, single file or directory tree and using a mapping table to extract the metadata within, then with a jinja2 template create the desired output format like STAC, EOP XML, GeoJSON or anything else.
The STAC overview and the generic DLR stac-tool is available as open source and harmonizes the procedure of identifying, specifying and generating valid STAC metadata for existing and future earth observation data products.
Files
PV2023_STAC-EOMetadataMapping_DLR-Reck.pdf
Files
(446.8 kB)
Name | Size | Download all |
---|---|---|
md5:8463c1ef332ba374a30867d09ef5a8b6
|
446.8 kB | Preview Download |