Four years later, we've moved forward a lot, and some tools that made sense in the beginning don't fit so well in the package anymore! They should not be discarded, rather moved somewhere that makes more sense, and where we can keep building on top of what we already have :slightly_smiling_face:
The tools concerned are the gap-filling methods of volume.py, with a closely linked API in dDEM, and several related issues (all pretty old now):
254,
247,
184,
109,
97,
72,
41.
Where should we make the distinction?
After many discussions, I see two distinct categories of applicative tools in relation to xDEM:
Tools requiring only one or several DEMs and deriving terrain-related outputs, even when being more useful in a given application, such as the different depression-filling algorithms of RichDEM (used mostly in hydro).
Tools requiring auxiliary data specific to the application (e.g., glacier outlines) and deriving application-related outputs (such as glacier volume change).
Tools like 1/ could fit directly in xDEM, because they are generalizable, while 2/ would fit better in a separate repo.
What would this new repo look like?
We also bumped into this question many times in the past years. (coding @adehecq KH9 repo, and others)
If the nature of the data (elevation) is not the center of this new repo (because you have packages like xDEM for different data types), what should it be?
After a lot of thinking and looking around, there seems to be the need for a "statistical estimation" package for EO surface data, which could combine all types of surface data (whether elevation, spectral, velocity, model estimates such as ice thickness, etc).
In the case of volume change, it happens that we "only" need glacier outlines + DEMs. But most of the other variables estimated for glaciers (SMB, frontal ablation, area change, etc) all require data of different nature.
In short, maybe the right way to organize this in a logical unit would be to create a package focused on the statistical estimation for surface applications (focusing mostly on cryo or glaciers?):
Estimating glacier volume change and mass balance from elevation differences and glacier outlines (including hypsometric gap-filling, density conversion, etc),
Estimating surface mass balance from elevation differences, velocity and ice thickness,
Estimate surface albedo based on spectral data,
Estimating glacier area change from multi-temporal glacier outlines,
Estimating frontal ablation/discharge from velocity fields, fluxgates and glacier outlines,
Delineating glacier outlines from elevation/velocity/spectral data.
Identifying crevasses from spectral+elevation imagery,
etc...
There are a lot of actors in the community and small packages that have such tools coded in (like pDEMtools). We could gather all of those in a repo where we can test and document them consistenty, and easily maintain them and build on top. It would also be the perfect occasion to pair with uncertainty propagation software for Xarray (like ObsArray).
What do you think @erikmannerfelt @atedstone @adehecq?
In the meantime, the volume.py tools of xDEM are slightly documented with user warnings in the API/doc page/gallery example that they will likely get moved.
Four years later, we've moved forward a lot, and some tools that made sense in the beginning don't fit so well in the package anymore! They should not be discarded, rather moved somewhere that makes more sense, and where we can keep building on top of what we already have :slightly_smiling_face:
The tools concerned are the gap-filling methods of
volume.py
, with a closely linked API indDEM
, and several related issues (all pretty old now):254,
247,
184,
109,
97,
72,
41.
Where should we make the distinction?
After many discussions, I see two distinct categories of applicative tools in relation to xDEM:
Tools like 1/ could fit directly in xDEM, because they are generalizable, while 2/ would fit better in a separate repo.
What would this new repo look like?
We also bumped into this question many times in the past years. (coding @adehecq KH9 repo, and others) If the nature of the data (elevation) is not the center of this new repo (because you have packages like xDEM for different data types), what should it be?
After a lot of thinking and looking around, there seems to be the need for a "statistical estimation" package for EO surface data, which could combine all types of surface data (whether elevation, spectral, velocity, model estimates such as ice thickness, etc). In the case of volume change, it happens that we "only" need glacier outlines + DEMs. But most of the other variables estimated for glaciers (SMB, frontal ablation, area change, etc) all require data of different nature.
In short, maybe the right way to organize this in a logical unit would be to create a package focused on the statistical estimation for surface applications (focusing mostly on cryo or glaciers?):
There are a lot of actors in the community and small packages that have such tools coded in (like pDEMtools). We could gather all of those in a repo where we can test and document them consistenty, and easily maintain them and build on top. It would also be the perfect occasion to pair with uncertainty propagation software for Xarray (like ObsArray).
What do you think @erikmannerfelt @atedstone @adehecq?