The European Space Agency
Home
APEx Application Propagation Environments
Main navigation
  • Algorithm Services
  • Project Environments
    Web Portal
    Geospatial Explorer
    Documentation Hub
    User Forum
    Product Catalogue
    Collaborative Workspaces
  • Resources
    • Algorithm Services Catalogue
    • Data Catalogue
  • Documentation
  • FAQ
  • About APEx
  • News
Contact us
Main navigation
  • Algorithm Services
  • Project Environments
  • Resources
  • Documentation
  • FAQ
  • About APEx
  • News
APEx - Documentation Portal
  1. Guides
  2. File format recommendations
  • Welcome
  • On-demand EO services
    • Using openEO service
    • APEx-Compliant Platforms
  • Project Tools
    • Use Cases
    • Geospatial Explorer
    • Project Portal
    • User Workspace
    • Interactive Development Environment
    • Product Catalogue
    • Documentation Portal
    • User Forum
  • Algorithm Services
    • On-Demand EO Services
    • Use Cases
    • Algorithm Porting
    • Algorithm Onboarding
    • Algorithm Upscaling
    • Algorithm Enhancement
    • Toolbox Cloudification
    • Algorithm Intercomparison
  • Guides
    • Creating APEx single sign-on token
    • Creating openEO based services
    • Creating EOAP based services
    • Upscaling openEO based services
    • Ingesting STAC metadata in APEx Product Catalogue
    • Linking APEx STAC catalogue with an openEO service
    • File format recommendations
  • Interoperability and Compliance Guidelines
    • Definitions & Actors
    • Algorithm Service Development Options
    • Algorithm Developer and Provider Guidelines
    • Algorithm Hosting Platforms Guidelines
    • Geospatial Explorer
    • Federated Business Model
  1. Guides
  2. File format recommendations

File format recommendations

Within the APEx interoperability and compliance guidelines, PROV-REQ-01 specifies the file formats that projects should use when publishing static data. The information on this page complement that requirement with more detailed recommendations on the use of these formats. Projects are encouraged to consult with the APEx team if they have a use case that does not fit within these guidelines.

Cloud Optimized GeoTIFF

Cloud Optimized GeoTIFF (COG) is the most widely supported format for geospatial raster data, and also one of the most efficient in terms of access costs. It is recommended as the default option to consider when publishing static data products. When combined with STAC metadata, COG can produce self-describing, FAIR-compliant datasets that are easily consumable by various services.

Generating Cloud Optimized GeoTIFF

If you are not familiar with COG or GeoTIFF generation, it is recommended to format your GeoTIFF files using a recent version of GDAL to ensure that they are compliant:

gdal_translate world.tif world_webmerc_cog.tif -of COG

Organizing spatiotemporal multi-band datasets

Many datasets have multiple bands (or ‘variables’), or have a date associated with them. The general recommendation is to store a single band per GeoTIFF file, and to create STAC items with one asset per band. This layout is commonly used by many other datasets, and avoids complexities of multi-band GeoTIFF files, which can be challenging to use.

An exepction to this are the ‘RGB’ style products, where three bands are used to represent a single image. In this case, creating a Cloud Optimized GeoTIFF with three bands is an option.

For associating time information, create one GeoTIFF per timestamp, and one STAC item per timestamp. The GeoTIFF format has not built-in support for conveying time information, but STAC metadata is supporting this very well.

(Geo-)Zarr

Zarr is a format that is gaining traction in the geospatial community, although it is not yet as widely supported as Cloud Optimized GeoTIFF. It’s main advantage lies in its ability to store complex multi-dimensional datasets that go beyond a simple 4D (x, y, time, bands) structure. Just like COG, Zarr allows for efficient cloud access.

At time of writing, there are however these important caveats:

  • GeoZarr aims to define how to store geospatial data in Zarr format, but this standard is not fully developed and lacks widespread tooling support.
  • Overview pyramids for fast online rendering are not yet supported.
  • By design, Zarr allows for many degrees of freedom, which requires the data producer to have a good understanding of the associated trade-offs.
  • By design, Zarr stores data as separate files in a directory structure, optimising cloud access but making direct downloads less convenient.

NetCDF

NetCDF is a self-describing format with some properties similar to Zarr, but less optimised for cloud access. It can be useful for exchanging data cubes as single files through traditional methods. However it is less recommended for convenient sharing of large datasets, for which either COG or Zarr provide better options.

Linking APEx STAC catalogue with an openEO service
Interoperability and Compliance Guidelines