Add dem
Xarray accessor mirroring DEM
class
#656
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds the
dem
Xarray accessor mirroring theDEM
class. Relies on GlacioHack/geoutils#446.The accessor allows to access all attributes and run all methods already implemented for DEMs from a
xarray.DataArray
object (e.g.,ds.dem.slope()
,ds.dem.coregister_3d()
), including functionalities from rasters inherited from therst
accessor (e.g.,ds.dem.reproject()
).It also opens up the opportunity to easily add Dask support to run our functionalities out-of-memory. This links to ongoing work in #525 for coregistration, which is one of the most complex applications. For vertical transformation and terrain attributes, we should be able to easily add support using
dask.map_overlap()
.Resolves #392
Summary of changes
To understand the changes below, first see changes related to the
rst
accessor in GeoUtils: GlacioHack/geoutils#446As for the
rst
accessor, most of the contents of theDEM
class are moved into aDEMBase
parent class, inherited by both theDEM
class anddem
accessor class.In this case, however, inheritance is more delicate because
DEM
also needs to inherit functionalities fromRaster
(that are not inRasterBase
) and thedem
accessor needs to inherit functionalities fromrst
(that are not inRasterBase
either).Therefore, the
DEM
class has dual-inheritance ofRaster
andDEMBase
, while thedem
accessor has dual inheritance ofrst
andDEMBase
. This makes things slightly more complex when explicitly callingsuper()
, which is only needed in a few occurences of core functions or__init__
, but otherwise easy for other functionalities!Similar as for the GeoUtils PR, the
from_array
functions allow to return a same-class object. In this case, onlyDEM
needs to override with its ownfrom_array
(asdem
already returns axarray.DataArray
through `rst).TO-DO
Code
Coreg.fit()
support Xarray input, in link with Dask for coregistration #525,DEM.estimate_uncertainty()
support Xarray input,delayed
function for "easy cases": all terrain attributes andto_vcrs
,DEMBase
,DEMAccessor
.Documentation
DEM.function()
toDEM.function()
ords.dem.function()
,Other Dask support to add (will be moved as issues for other PRs)
nd_binning
and use the delayedsubsample
of GeoUtils,