Open adebardo opened 1 month ago
remarks:
# Create coregistration object
coregistration_ = Coregistration(cfg) # --> could be Coregistration(name_of_coreg "nuth_kaab", ...) not the full config
# Compute coregistration
_ = coregistration_.compute_coregistration(input_sec, input_ref)
--> for glaciohack, conceptually, we have separated in demcompare way : a Coregistration Class which is a simple factory of CoregistrationTemplate objects depending on a parameter (config, string...). This CoregistrationTemplate is the equivalent of your Coreg class which is the class containing all of common elements and that drive API for all (usually using ABCMeta, abstractmethod but i don't know the equivalent with @overload you seem to use, https://github.com/GlacioHack/xdem/blob/main/xdem/coreg/base.py#L1215). So for a pipeline and a cli this must be solved and validated, i think. To be discussed.
Maybe in two steps, a first basic way as here to make a first cli and another adding a more flexible code organization. Seems not so difficult to add a factory in coreg of xdem. Don't know the potential impact on an API for now.
My 2 cts, hoping it helps
A few comments:
geoutils.rasters.load_multiple_rasters
which optmize memory usage by first downloading only metadata, cropping and reprojecting only in areas of overlap between the two DEMs. fit
method, but you also need to run apply
to get the coregistered DEMAnd to answer @duboise-cnes's questions:
For listing coreg methods: I think it would be easy to maintain a manual list, as we don't add a new method very often (there are list already used in test_biascorr
, test_coreg/test_base
and soon in test_affine
, we could make them consistent by adding an available
dictionary in each coreg sub-module as @duboise-cnes mentions). From the list we could automatically parse the different arguments of each coregistration class.
Note: Regarding the parameters, after the merge of PR https://github.com/GlacioHack/xdem/pull/530 (that I'm working on this week), all Affine
coregistration methods will have exactly the same arguments across the different categories:
This is about to be documented (once https://github.com/GlacioHack/xdem/pull/502 is finalized, hopefully by the time you are all back from holidays :wink:).
@duboise-cnes thanks, i think we could talk about the coregistration architecture in a meeting @adehecq Thanks for the tip. For the fit method, I would prefer to discuss the type of outputs you want and how we want to save things. @rhugonnet Great news for the parameters :)
I plan to revisit this matter after the 21/08/2024 meeting.
I plan to revisit this matter after the 21/08/2024 meeting.
Is there anything new to discuss here?
I plan to revisit this matter after the 21/08/2024 meeting.
Is there anything new to discuss here?
I already changed the ticket regarding the meeting yes, it's okay now
Context
The goal of this ticket is to implement coregistration from the xdem run.
In the code
From the run in the init file, we now need to:
[ ] add the right function to veirfy path, if "path/to/save/folder" doesn't exist, it can be created
[ ] Load the reference and secondary DEMs using the accessor:
reference_elev, to_be_aligned_elev = geoutils.rasters.load_multiple_rasters([config["inputs"]["reference_elev"], config["inputs"]["to_be_aligned_elev"])
[ ] Execute a coregistration:
coregdem, , , = dem_coregistration(reference_elev, to_be_aligned_elev, config["outputs"]["path"])