When we launched the dataset inside the Analytics Console, we heard from many researchers that you wanted more flexibility for workflows outside our platform. Now, with the dataset hosted in a public bucket, you can choose whether to work directly with the Collection in the Console or with the embedding files as Cloud Optimized Arrays (COAs) on Cloud Storage.
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
Getting started is simple. The dataset is stored in a public bucket named gs://datacube_foundations. To access the files, you can use the standard cloud storage command-line tool, or read the data through the storage API. This API is supported by many toolkits, including common array-processing libraries (see our companion blog on that).
There is a README file in the bucket root that contains a lot of important technical detail, some of which is summarized below.
The files use a standard chunked array format called Cloud Optimized Array (COA), designed for efficient partial access over the internet.
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.
License and Attribution
This data is made freely available for use under the Creative Commons Attribution 4.0 (CC-BY 4.0) License.
If you use this dataset in your work, please include the following attribution:
“The Datacube dataset is produced by eodc.”
A Note on Cost
The bucket was previously set up as “requester pays” — however, as of August 2026, the bucket has been updated to “provider-pays,” and users will no longer incur any costs associated with data use or download (egress).
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.