Skeleton of contained coregistration with xDEM

[rhugonnet]

@jpswinski @dshean
This PR is not meant to be merged, just to show the skeleton of what the contained Python code would look like, and move forward on linking the pieces to the container, then running performance tests!

[rhugonnet]

I already tried to write things in a way that should allow to be modular (choosing coregistration method, passing user input through SlideRule, etc).

I guess the way forward is:

1. Link it to the container,
2. Pick test data fetched through SlideRule to test performance. @dshean You had mentioned we should try 3DEP, ArcticDEM mosaic and ArcticDEM strip. What do you think would be a good test location?

[dshean]

Great! Thanks @rhugonnet. For testing, somewhere with relief, dense ICESat-2 coverage, and a reasonable count of ArcticDEM/REMA strips seems good (should be easy to swap in the ArcticDEM/REMA mosaic, but strips are the main priority).
Probably best to isoalate exposed sites, without much ice, vegetation, limited seasonal snow depth. Maybe large, exposed bedrock sites in Arctic Canada or Greenland periphery? Or Dry Valleys in Antarctica. Iceland site might also be a good option, building on all of the great work that's been done there already.
For 3DEP site, somewhere in CONUS desert southwest with recent lidar collection would be good.

[dshean]

A few additional questions/notes for further discussion:

• How to determine appropriate number and representation of samples?
• How to handle “control surface” definitions?
• How to actually apply (and store) the returned transformation, providing the user with co-registered samples (notes on this in previous Slack threads and the larger co-reg requirement doc)
• In most of our use cases, the DEM has a higher "point density" than the ATL06 samples and should be used as the reference for ICP, even though ATL06 has better absolute accuracy, and the inverse transform should be applied to the DEM. We should think about impacts of using the ICESat-2 points as the "reference" vs. using the DEM as the "reference." Perhaps running both ways and ensuring transform and inverse transform are nearly identical.
• Checks on co-registration success and uncertainty, whether the resulting transformation could end up introducing more error than the original geolocation accuracy of the "to be aligned" dataset

I think several of these items are likely addressed in recent xdem work, but let's discuss additional effort required to implement in the cloud (esp if external datasets are required, like landcover classification or glacier polygons)

[jpswinski]

@rhugonnet Just wanted to give you an update that the docker container runner in sliderule has been updated and is ready to go with the latest version of SlideRule. So if you have an updated coregistration Python script you want me to integrate, just let me know.

[rhugonnet]

@jpswinski Great, thanks! 🙂

I'm busy with proposal writing this month, but I had already blocked a week early November to finalizing + testing the container! It's also great timing with results coming together for my study in coregistration with @dshean, and RAM/CPU profiling of coregistration being done separarely in xDEM by @marinebcht @adebardo @belletva.
We could actually share slides on performance to discuss the best approach around Nov?

I think we can get this efficient coreg pairing done by the end of the year! 😉