-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Harmonize CRS handling across notebooks/utilities #600
Comments
Needed changes look something like this 39c0532, except that there are more places
|
Using
|
We should probably combine this work with replacing calls to |
I didn't see @Kirill888 comment above.....but I agree, this issue dovetails with our need to update |
|
Looks like synchronizing everything would be rather difficult, so I have pushed changes to datacube-core that take care of the current state. So we can proceed with updating sandbox images independently of this work. Still I'd rather see these fixes done earlier than later as notebooks are an essential part of documentation for datacube and related libs so keeping them up to date is a priority. |
This will be resolved better by switching to |
History
The way CRS information is stored and accessed in datacube has changed over the years. Those changes were driven primarily by two factors: better interoperability with xarray/rasterio and other geospatial libraries and better "handling of various xarray operations".
Initially CRS information was stored as a datacube
CRS
class in an attribute namedcrs
on each datavariable and on dataset object returned fromdc.load(..)
. This approach was problematic as it prevented methods likexarray.to_netcdf(..)
from working (didn't know what to do withcrs
attribute that is not a string). It also suffered from "missing attribute" problem, some common xarray operations like type casting could dropcrs
attribute.Datacube code was then changed for a brief period to store
crs
attribute on thex,y
coordinates, and to be a string and not aCRS
class, this allowed for better "survivability" of CRS data across per-pixel operations, as coordinates are essentially copied from source to destination including all the attributes attached to them. Turningcrs
into a string allowed for ability to save data withxarray.to_netcdf
method.Then we had a proposal to change representation yet again to be inline with what NetCDF CF convention is using. This had a lot of merit and provided with cleaner solution than what we had at that point in time, so we went along and implemented that as part of 1.8.0 release.
Current State
spatial_ref
.geobox
"dynamic property", available after importingdatacube
.geobox
can also detect CRS information as returned byxarray.open_(dataset|rasterio)
.crs
property is no longer populated withCRS
class for data returned bydc.load
, one must use.geobox.crs
.crs
property is populated byxarray.open_rasterio
and is set to a string representation of the CRS, usually WKT or EPSG code.geobox
should returnNone
, if it raises an Error of any sort, this should be considered a bug and fixed..geobox
survives round trip to netcdf and back1.8.1
, there is nowdatacube.utils.geometry.assign_crs
method. This is a preferred mechanism to add CRS to unregistered data and to convert simple attribute based representation to a more robust coordinates based representation.Changes Required to Notebooks
xx.crs
, instead accessxx.geobox.crs
, addassert xx.geobox is not None
to indicate to people reading code and to check at run-time that crs information is required/availablecrs
attribute directly into dataset/dataarray. You probably don't need to do it anymore, it probably survived computation just fine, or has been detected if data was returned from one of xarray load functionsxarray
methods, useassign_crs
to convert to Datacube format that survives per pixel operations betterxx.geobox.dims
, this does not work for external datasets inESPG:4326
loaded via xarray open functions (it names coordinates asx,y
always), usedatacube.utils.spatial_dims
instead.Those changes are difficult to make in a way that will work with older and newer versions of datacube, so I propose we just change to support newest version only
1.8.1
and forward. Probably1.8.2
that is yet to be released as there has been some more fixes to.geobox
handling for external sources since1.8.1
.I have been able to run following with current datacube code after some changes to notebooks and to
xr_rasterize
functionbut there are way more notebooks than these...
The tricky part is synchronising updates to sandbox/dea on NCI/notebooks repos.
The text was updated successfully, but these errors were encountered: