Open danielballan opened 4 years ago
You may well have a point, but the original rationale was: that all these call xarray loader function
Yes, I think that is sensible early on, just as we currently package a bunch of unrelated drivers together in databroker._drivers
with the intention of splitting them up once things stabilize. Maybe this is worth doing eventually, with some shared utility library containing the xarray loader.
Seems fine to me...
Happy to write it up as a separate issue, but if this would help load zarrs which were not written with xarray, I'd also be in favor.
I'm currently running into a KeyError on _ARRAY_DIMENSIONS
.
load zarrs which were not written with xarray
LIke intake.source.zarr.ZarrArraySource
("ndzarr")?
Thanks, @martindurant. ZarrArraySource
does work for my data.
Intake-xarray lumps together several different I/O backends. Grouping drivers by what they return (xarray in this case) is different from the usual pattern. We propose to break intake-xarray into intake-netcdf, intake-tiff with rasterio support (and maybe also tifffile support?), intake-png, and intake-zarr. We can maintain intake-xarray going forward as a metapackage that depends on these as a convenience and for back-compat.