What’s new in this release

Access to Sentinel-1 EOPF Zarr products. Users can now pull Sentinel-1 data directly through the EOPF-Zarr data store, alongside the Sentinel-2 support already available in earlier releases.

Support for opening multiple datasets at once. The EOPF-Zarr data store can now open several datasets in a single call, cutting down on repetitive setup for workflows that span more than one product.

Product-specific analysis workflows. New workflows tailored to individual product types make it easier to go from raw data to results without having to hand-roll processing steps for each dataset.

Mosaicking and temporal stacking. Spatially overlapping products can now be mosaicked together, and products across time can be stacked, so users can build seamless views over an area or track change over a time series without stitching tiles manually.

More consistent data cubes. Together, these changes are aimed at producing data cubes that are more consistent and easier to plug straight into further analysis and visualization work.

Why it matters

Each of these additions targets a step that used to require manual handling — locating the right Sentinel-1 products, opening several datasets at once, reconciling overlapping tiles, or aligning imagery over time. With v0.3.4, more of that groundwork is handled by xcube-eopf itself, leaving researchers and analysts with a cleaner data cube to start from.

The release is available now as part of the EOPF Sentinel Zarr Samples Service.

We hope this new location is especially useful for integration with tooling across the broader data science ecosystem, including notebooks, warehouses, and ML platforms. Read on to learn about the dataset’s location, structure, and some tips for working with the embedding files!

Accessing the Data

Figure 1

How the Datacube bucket is organized — everything nests under the bucket root, by acquisition year, by MGRS tile, down to the individual COA files.

How the Data is Organized

Given the scale of global multi-sensor observation data, we had to break it down, and understanding the structure of the dataset is key to efficient access.

Figure 2

The dequantization formula compresses values near zero and spreads out the extremes — small raw values decode to tiny floats, while values near ±127 snap close to ±1.

File Structure

The data is organized logically to make it easier to navigate:

• By Year: The top level is divided into folders for each acquisition year (e.g., 2024).
• By Tile (MGRS Grid): Each year folder is further split into subdirectories based on the Military Grid Reference System (MGRS) tile ID, giving each roughly 110km x 110km region of the globe its own folder (e.g., 33UXP).

Understanding a Single COA File

Each tile directory contains many individual COA files, one per acquisition:

• Tile Size: Each file is 5490 x 5490 pixels at native 20m resolution.
• The 12 Channels: Each pixel has 12 values, corresponding to the B01 through B12 spectral bands captured for that acquisition.
• Efficient Previews (Overviews): To help you quickly visualize or analyze data without downloading the full-resolution file, each COA includes smaller, pre-calculated versions (like 2745×2745, 1372×1372, and so on). These overviews are computed by taking the mean value of the pixels they cover, then renormalizing to a Euclidean length of 1, just like the full-resolution values.

Decoding the Embeddings: The Bin Values

The raw numbers stored in the files are compressed to save space, using signed 8-bit integers (values from -127 to 127). This process is called quantization. A raw value of -128 is reserved to indicate a masked pixel (no clean acquisition available for that location, typically due to cloud cover).

To get the final analysis-ready value (a floating-point number between -1 and 1), you must apply a de-quantization formula: divide by 127.5, square, and then multiply by the sign of the raw value.

Finding What You Need: The Index Files

Trying to find a specific spot on Earth just by looking at file names would be impossible. To solve this, we provide a comprehensive index that maps every file to the exact geographical area and time window it covers.

Index File Formats

You can find the index in Parquet, GeoParquet-style, and CSV formats in the bucket root under /index/.

What the Index Tells You

The index is essential for querying, providing:

• The geometry (the shape) of the file’s coverage in WGS84 (standard Latitude/Longitude)
• The acquisition year and MGRS tile it belongs to
• The exact WGS84 bounds (min/max latitude and longitude) for quick querying
• The cloud-cover percentage recorded for that acquisition

Example: Using BigQuery for Spatial Queries

The index allows you to quickly narrow down the list of files to just the ones that cover your area of interest. The GeoParquet version is supported by many tools, and is a great fit for BigQuery.

To use this example, first download the index and import it into BigQuery (using Create Table from Upload). Once the index is loaded into BigQuery, you can run spatial queries across it.

The following query finds all Datacube files for the year 2024 that cover any point in Austria with less than 10% recorded cloud cover:

It’s worth noting this query looks more complicated than it really is — most of the query is just digging through OpenStreetMap to find the polygon representing Austria. The core of the query is simple: use ST_INTERSECTS to pick out the tiles intersecting your area of interest, and filter on cloud_cover_pct to skip anything too obscured to be useful.

Ready to start exploring?

Now that the Datacube dataset is available directly on Cloud Storage, you have the flexibility to seamlessly integrate it into your existing cloud workflows. Try using the GeoParquet index with your own BigQuery geometries to find and download the exact tiles you need, or access the COA files directly in a notebook or custom cloud environment for global-scale analysis. With Datacube available on both the Analytics Console and Cloud Storage, it’s never been easier to leverage planetary-scale observation data and build custom applications that tackle the most pressing challenges of our ever-changing world!

Footnotes

MGRS tile boundaries follow the standard grid used by Sentinel-2 and similar missions, not the underlying UTM zone boundaries of the source imagery. Files near a tile edge may therefore include reprojected data originally captured in a neighboring UTM zone.