Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 9 additions & 9 deletions docs/migration-guide-v0.1.0.md
Original file line number Diff line number Diff line change
Expand Up @@ -96,7 +96,7 @@ ds = xr.open_dataset(

#### Example 1: Global dataset at fixed scale

**Before (v0.1.0):**
**Before (v0.0.x):**
```python
ds = xr.open_dataset(
'ECMWF/ERA5_LAND/MONTHLY_AGGR',
Expand Down Expand Up @@ -128,7 +128,7 @@ ds = xr.open_dataset(

#### Example 2: Regional dataset with EE geometry

**Before (v0.1.0):**
**Before (v0.0.x):**
```python
import ee

Expand Down Expand Up @@ -167,7 +167,7 @@ ds = xr.open_dataset(

#### Example 3: Using source resolution for a custom area

**Before (v0.1.0):**
**Before (v0.0.x):**
```python
# You had to manually determine the scale from the dataset
ds = xr.open_dataset(
Expand Down Expand Up @@ -215,7 +215,7 @@ Xee v0.1.0 outputs dimensions in `[time, y, x]` order (matching CF conventions a

#### Plotting

**Before (v0.1.0):**
**Before (v0.0.x):**
```python
# Required transpose for correct visualization
ds['temperature_2m'].isel(time=0).transpose().plot()
Expand All @@ -231,7 +231,7 @@ ds['temperature_2m'].isel(time=0).plot()

Many geospatial libraries expect `[time, y, x]` ordering. You may have been using `.transpose()` to accommodate this.

**Before (v0.1.0):**
**Before (v0.0.x):**
```python
# Had to transpose for libraries expecting [time, y, x]
data_array = ds['temperature_2m'].transpose('time', 'y', 'x')
Expand All @@ -249,7 +249,7 @@ export_to_geotiff(data_array)

If you have code that explicitly references dimension positions, update it:

**Before (v0.1.0):**
**Before (v0.0.x):**
```python
# Dimensions were [time, x, y]
time_dim, x_dim, y_dim = ds['temperature_2m'].dims
Expand Down Expand Up @@ -280,7 +280,7 @@ time_length = ds.sizes['time']

### Pattern 1: Simple global analysis

**Before (v0.1.0):**
**Before (v0.0.x):**
```python
import ee
import xarray as xr
Expand Down Expand Up @@ -323,7 +323,7 @@ mean_temp.plot() # No transpose needed

### Pattern 2: Regional analysis with preprocessing

**Before (v0.1.0):**
**Before (v0.0.x):**
```python
import ee
import xarray as xr
Expand Down Expand Up @@ -384,7 +384,7 @@ ds = xr.open_dataset(collection, engine='ee', **grid_params)

### Pattern 3: Export workflows

**Before (v0.1.0):**
**Before (v0.0.x):**
```python
import xarray as xr

Expand Down
6 changes: 3 additions & 3 deletions docs/why-xee.md
Original file line number Diff line number Diff line change
Expand Up @@ -76,7 +76,7 @@ Differences:
- **Quota vs No Quota**: Since Earth Engine is API based, there are quota
restrictions that limit IO, namely a 100 QPS limit on data requests. Readers
all need to be authenticated and tied to a GCP project quota. Zarr, on the
other hand, has a lower level access pattern. Reading is delegating to basic
other hand, has a lower level access pattern. Reading is delegated to basic
permissions on cloud buckets.
- **On the fly vs up-front data shaping**: In Zarr, the representation of data
at rest fundamentally influences performance at query time. For this reason,
Expand All @@ -87,7 +87,7 @@ Differences:
server-side), users are free to request the resolution and projection of the
data during dataset open. Similarly, while Earth Engine's internal dataset
does fit an internal chunking scheme, chunking schemes are a lot more
fungibile.
fungible.

We hope that this comparison provides the user of a set of useful precedents for
We hope that this comparison provides the user with a set of useful precedents for
working with cloud-based datasets.