|
6 | 6 | "source": [ |
7 | 7 | "# Building an analysis-ready data cube from Planetary Computer STAC", |
8 | 8 | "", |
9 | | - "A STAC search returns item metadata: hrefs, dates, cloud cover. Analysis usually wants something else, a single aligned array indexed by time, band, and space, that you can run math across. Two libraries build that cube from STAC items: [odc-stac](https://odc-stac.readthedocs.io/) and [stackstac](https://stackstac.readthedocs.io/). They take the same inputs and produce lazy, Dask-backed xarray objects, but they differ in ways that matter on Planetary Computer data.", |
| 9 | + "A STAC search returns item metadata: hrefs, dates, cloud cover. Analysis usually wants something else: a single aligned array indexed by time, band, and space that you can run math across. This notebook builds that cube two ways, with [odc-stac](https://odc-stac.readthedocs.io/) and [stackstac](https://stackstac.readthedocs.io/). Key benefits:", |
10 | 10 | "", |
11 | | - "This notebook loads a few low-cloud [Sentinel-2 L2A](https://planetarycomputer.microsoft.com/dataset/sentinel-2-l2a) scenes over Portland with both libraries and compares them. The companion [data cube tutorial](../overview/odc-stac.md) has the full narrative." |
| 11 | + "1. **Aligned cube**: turn a pile of STAC items into one array indexed by time, band, and space.", |
| 12 | + "2. **Lazy and Dask-backed**: the cube builds without reading pixels until you compute.", |
| 13 | + "3. **CRS handling**: odc-stac infers the projection from STAC metadata; stackstac takes an explicit `epsg=`.", |
| 14 | + "4. **Two shapes**: odc-stac returns a `Dataset` of named `float32` bands; stackstac returns one `float64` `DataArray` with a `band` dimension and every item property as a coordinate.", |
| 15 | + "5. **Same inputs**: both take the same signed STAC items, so you can pick per pipeline.", |
| 16 | + "", |
| 17 | + "We'll load a few low-cloud [Sentinel-2 L2A](https://planetarycomputer.microsoft.com/dataset/sentinel-2-l2a) scenes over Portland, Oregon with both libraries and compare CRS handling, shape, dtype, and metadata.", |
| 18 | + "", |
| 19 | + "The companion [data cube tutorial](../overview/odc-stac.md) has the full narrative." |
12 | 20 | ] |
13 | 21 | }, |
14 | 22 | { |
|
149 | 157 | "cell_type": "markdown", |
150 | 158 | "metadata": {}, |
151 | 159 | "source": [ |
152 | | - "## When to use something else", |
| 160 | + "## You're done", |
| 161 | + "", |
| 162 | + "If both load cells built a cube, you turned four Sentinel-2 scenes into an analysis-ready array two ways: odc-stac's named `float32` `Dataset` and stackstac's `float64` `DataArray` with metadata as coordinates.", |
153 | 163 | "", |
154 | | - "A cube is the right shape for time-series and multi-band analysis across an area. When you only need pixels from a single scene, the cube machinery is overhead; read the window directly with [async-geotiff](../overview/async-geotiff.md) instead." |
| 164 | + "Swap in your own bbox, collection, or band list and the same load applies. When you only need pixels from a single scene rather than a cube, the cube machinery is overhead; read the window directly with the [async-geotiff tutorial](../overview/async-geotiff.md) instead." |
155 | 165 | ] |
156 | 166 | } |
157 | 167 | ], |
|
0 commit comments