Move glacier-specific tools to a separate package/module

[rhugonnet]

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 🙂

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):

• Add a function to calculate volume change/MB for all features in a vector file #254,
• Interpolation issues on the margins of retreating glaciers #247,
• Include tests for checking mass balance calculation #184,
• Make (hypsometric) interpolation approaches consistent #109,
• Add hypsometric extrapolation methods #97,
• Customize hypsometric binning in DEMCollection and dDEM classes #72,
• Test different options for volume integration #41.

Where should we make the distinction?

After many discussions, I see two distinct categories of applicative tools in relation to xDEM:

1. 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).
2. 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?

[rhugonnet]

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.

[atedstone]

@rhugonnet , thanks for the interesting ideas. Allowing for the fact that I'm an xDEM 'bystander', my initial remarks are as follows:

• I can certainly see a value in grouping geodetic SMB functionality together into its own package. So, anything to do with volume change, potentially area change etc.
• Functionality relating to solid ice discharge seems a bit more challenging/a bit left-of-field, but this isn't really my area so perhaps best left to the experts.
• I don't think we should try to cover other specific cases like crevasse identification, surface albedo from spectral data in the same repository. Where would the line stop here? E.g. what about the various codes that are available for supraglacial hydrology identification? These can be fairly substantial code bases in their own right.

Thanks also for the heads-up on uncertainty propagation software - will look into this.

[rhugonnet]

Thanks @atedstone! I was just chatting with @trchudley about this again this morning.

Where would the line stop here?

Good point! That's indeed the delicate decision 😅.

My thoughts are that, as long as the tools don't require new dependencies (geospatial or numerical), they would all fit very well in the same package, as being both thematically and methodologically very close (cryo + reduction/derivative of pre-processed spatiotemporal data). I also think this would work well because code bases to derive this type of estimates are fairly small, whether it is for instance mass balance (from elevation change + glacier outlines), or frontal ablation (from velocity, ice thickness, elevation change + flux gates and glacier outlines). The hard work is usually pre-processing that georeferenced data (which can be done through other specialized geo-package like xDEM). Once it's only estimation from the temporal stacks of data, it's a fairly small amount of methods/routines.

In that sense, estimating glacier mass change, frontal ablation or surface albedo in the same package wouldn't shock me. The same way OGGM integrates different modules for different modelling aspects.
What do you think? 🤔

It could also be the perfect occasion to build open thematic educational resources surrounding the tools (or valorize existing ones, for instance from Bethan Davies)! (a bit like OGGM-Edu)