You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a lot of steps that extract the NumPy array/transform from a Raster/Xarray dataset, and then re-build the object in the fit function to be able to apply the Raster API consistently. This takes extra memory and computing time.
I see 2 solutions to remedy this issue:
Switch to using Raster and Xarray objects directly in the fit_rst, never going transforming to a NumPy array (just passing the one contained),
Make the Raster API available as separate functions from the class.
We (wisely) decided to not do 1. initially because we did not know if the Raster class was going to be a success. But given that we'll be able to use an Xarray object the same way now, that should not be a problem anymore.
It would still be valuable to have 2. available for some instances.
Minimal changes would be needed for 2., but would make the code harder to read in the Coreg class (calling non-public GeoUtils functions with volatile metadata).
The text was updated successfully, but these errors were encountered:
We have a lot of steps that extract the NumPy array/transform from a
Raster
/Xarray
dataset, and then re-build the object in thefit
function to be able to apply theRaster
API consistently. This takes extra memory and computing time.I see 2 solutions to remedy this issue:
Raster
andXarray
objects directly in thefit_rst
, never going transforming to a NumPy array (just passing the one contained),Raster
API available as separate functions from the class.We (wisely) decided to not do 1. initially because we did not know if the
Raster
class was going to be a success. But given that we'll be able to use an Xarray object the same way now, that should not be a problem anymore.It would still be valuable to have 2. available for some instances.
Minimal changes would be needed for 2., but would make the code harder to read in the
Coreg
class (calling non-public GeoUtils functions with volatile metadata).The text was updated successfully, but these errors were encountered: