Summary
The native GeoTIFF/COG/VRT loader is currently available through xrspatial.geotiff.open_geotiff(...) and the .xrs accessors, but it does not appear to be registered as an xarray backend engine. It would be useful to open GeoTIFF sources through xarray's standard backend API:
import xarray as xr
xr.open_dataset("dem.tif", engine="xrspatial_geotiff")
xr.open_mfdataset("*.tif", engine="xrspatial_geotiff")
Current behavior
The package metadata only registers the xrspatial console script under [options.entry_points]; there is no xarray.backends entry point. I also could not find a BackendEntrypoint implementation in the tree.
The documented API is explicit import/use of open_geotiff:
from xrspatial.geotiff import open_geotiff, to_geotiff
open_geotiff("dem.tif")
open_geotiff("dem.tif", chunks=512)
open_geotiff("dem.tif", gpu=True)
open_geotiff returns a DataArray, while xarray backend engines are expected to open a Dataset.
Requested behavior
Add an xarray backend entry point, probably something like:
[options.entry_points]
xarray.backends =
xrspatial_geotiff = xrspatial.geotiff._xarray_backend:GeoTIFFBackendEntrypoint
with a BackendEntrypoint wrapper around open_geotiff(...) that returns a one-variable Dataset.
Design notes / questions
- Engine name:
xrspatial_geotiff, geotiff, or something else?
- Variable naming: use
open_geotiff(..., default_name=...), name=, source stem, or xarray's default data variable naming conventions?
- Forwarding kwargs: map
chunks, gpu, masked, dtype, band, overview_level, window, bbox, stable_only, etc. through backend_kwargs.
- Multi-file behavior: verify
xr.open_mfdataset(..., engine=...) works naturally once each file opens as a compatible Dataset.
- Autodetection: optionally implement
guess_can_open for .tif, .tiff, .vrt, COG URLs, and supported fsspec URIs.
Why
This would let users compose xrspatial's no-GDAL GeoTIFF support with standard xarray workflows and avoid having to import xrspatial explicitly just to access the loader.
Summary
The native GeoTIFF/COG/VRT loader is currently available through
xrspatial.geotiff.open_geotiff(...)and the.xrsaccessors, but it does not appear to be registered as an xarray backend engine. It would be useful to open GeoTIFF sources through xarray's standard backend API:Current behavior
The package metadata only registers the
xrspatialconsole script under[options.entry_points]; there is noxarray.backendsentry point. I also could not find aBackendEntrypointimplementation in the tree.The documented API is explicit import/use of
open_geotiff:open_geotiffreturns aDataArray, while xarray backend engines are expected to open aDataset.Requested behavior
Add an xarray backend entry point, probably something like:
with a
BackendEntrypointwrapper aroundopen_geotiff(...)that returns a one-variableDataset.Design notes / questions
xrspatial_geotiff,geotiff, or something else?open_geotiff(..., default_name=...),name=, source stem, or xarray's default data variable naming conventions?chunks,gpu,masked,dtype,band,overview_level,window,bbox,stable_only, etc. throughbackend_kwargs.xr.open_mfdataset(..., engine=...)works naturally once each file opens as a compatibleDataset.guess_can_openfor.tif,.tiff,.vrt, COG URLs, and supported fsspec URIs.Why
This would let users compose xrspatial's no-GDAL GeoTIFF support with standard xarray workflows and avoid having to import
xrspatialexplicitly just to access the loader.