Inconsistent raster dimensions when reading + writing GeoTIFF with EOReader (resolved by disabling Dask)

[cmayet]

Hi everyone,

I’ve encountered an issue while reading and writing a cropped GeoTIFF (satellite band) using EOReader.

Summary

• I read a satellite band (Sentinel-2) using EOReader with a spatial subset (window / bounds).
• I check the dimensions of the loaded array → everything looks correct.
• I then write the raster to disk using EOReader utilities.
• However, when inspecting the written file (via gdalinfo), the raster dimensions differ from the original in-memory array.

Expected behavior

The raster written to disk should preserve the exact dimensions of the in-memory array.

Actual behavior

The output raster has different dimensions (as reported by gdalinfo).

Key observation

The issue disappears when Dask is disabled:

os.environ[USE_DASK] = "0"

This strongly suggests that the discrepancy is related to Dask / how Dask is used internally during reading and/or writing.

Reproducible example

import logging
import os
import subprocess

import eoreader.utils
from eodag import EODataAccessGateway, setup_logging
from eoreader.bands import GREEN
from eoreader.env_vars import USE_DASK
from eoreader.keywords import TO_REFLECTANCE
from eoreader.reader import Reader
from eoreader.utils import write
from rasterio.windows import Window
from sertit import logs


# os.environ[USE_DASK] = "0"

# eoreader_logger
logger = logging.getLogger("eoreader")
logs.init_logger(logger)

# eodag logger
setup_logging(1)
dag = EODataAccessGateway()
search_results = dag.search(
    provider="cop_dataspace",
    collection="S2_MSI_L1C",
    start="2025-08-26",
    end="2025-08-27",
    **{"grid:code": "MGRS-28PCC"},
)

logger.info(f"Working on product {search_results[0].properties['id']}")


path = dag.download(
    search_results[0],
)


# Custom user defined read window (is a rasterio Window instance)
window = Window(3208, 2047, 932, 4322)
bounds = (332080.0, 1736310.0, 341400.0, 1779530.0)


# logger.info(f"Rasterio reading window (in pixels): {window}")
to_reflectance = False


reader = Reader()
with reader.open(
    path, remove_tmp=True
) as product:
    dataset = product.load(GREEN, window=bounds, **{TO_REFLECTANCE: to_reflectance})

logger.info(f"Loaded dataset.dims: {dataset.dims}")
logger.info(f"Loaded datarray.shape: {dataset[GREEN].shape}")
logger.info(f"Loaded datarray.rio: {dataset[GREEN].rio.resolution()}")

logger.info(f"Write raster band with eoreader write utility")
out_fname = "/tmp/green.tif"
write(dataset[GREEN], out_fname)

gdalinfo = subprocess.run(
    ["gdalinfo", out_fname],
    capture_output=True,
    text=True,
)
gdalinfo_size = next((l for l in gdalinfo.stdout.splitlines() if "Size is" in l), None)
logger.info(
    f"Get Raster size from gdalinfo on writen file: {gdalinfo_size} !"
)

read = eoreader.utils.read(out_fname)
logger.info(f"After read rio shape: {read.shape}")
logger.info(f"After read rio resolution: {read.rio.resolution()}")

When dask in ON, i get :

2026-05-04 11:01:50,766 - [DEBUG] - Loading bands ['GREEN']
2026-05-04 11:01:50,767 - [DEBUG] - Read GREEN
2026-05-04 11:01:50,851 - [DEBUG] - Manage nodata for band GREEN
.venv/lib/python3.13/site-packages/rasterio/warp.py:385: NotGeoreferencedWarning: Dataset has no geotransform, gcps, or rpcs. The identity matrix will be returned.
  dest = _reproject(
2026-05-04 11:01:52,504 - [INFO] - Loaded dataset.dims: FrozenMappingWarningOnValuesAccess({'x': 932, 'y': 4322, 'band': 1})
2026-05-04 11:01:52,504 - [INFO] - Loaded datarray.shape: (1, 4322, 932)
2026-05-04 11:01:52,504 - [INFO] - Loaded datarray.rio: (10.0, -10.0)
2026-05-04 11:01:52,504 - [INFO] - Write raster band with eoreader write utility
2026-05-04 11:01:53,725 - [INFO] - Get Raster size from gdalinfo on writen file: Size is 960, 4352 !
2026-05-04 11:01:53,737 - [INFO] - After read rio shape: (1, 4352, 960)
2026-05-04 11:01:53,737 - [INFO] - After read rio resolution: (10.0, -10.0)

Questions / investigation points

• Where exactly does Dask intervene in EOReader during:
  - windowed reading?
  - writing (write())?
• Could this be related to chunking, alignment, or lazy evaluation when writing to disk?
• Are there known issues or fixes related to this behavior (either in EOReader or Dask)?

Next steps

I’m happy to help debug further. If this is indeed caused by Dask, I can open an issue upstream—but I’d first like to pinpoint where EOReader relies on Dask in this workflow.

Thanks in advance for your help!

[remi-braun]

Excellent catch! Thank you 🙏 I wouldn't have expected such behaviour from Dask 🤔