Closed rhugonnet closed 3 months ago
Tests all passing locally! :partying_face:
To fix them in CI: probably need to release a 0.1.1
for GeoUtils that integrates the recent interp_points
fixes!
@erikmannerfelt Long time since we had that revamping discussion, it's finally done!! :grin:
Tests pass locally but require https://github.com/GlacioHack/geoutils/pull/501
Alelujah OpenCV finally installs on CI again... I've opened a Wiki page to remember how to solve this: https://github.com/GlacioHack/xdem/wiki/Installing-OpenCV-in-CI.
Just thinking: should we add a point cloud to our sample data to document these new features in the documentation?
Yes, maybe once we have #463!
Summary
This PR adds point-raster and point-point support in the base
Coreg
class, with modifications to properly inherit it throughCoregPipeline
andBlockwiseCoreg
, making the treatment of point-raster coregistration fully consistent for the entire coregistration module. It adds point-raster support for allBiasCorr
classes, and maintains current point-raster support forAffineCoreg
classes.In practice
Any
gpd.GeoDataFrame
can now be passed with az_name
argument defining the column name representing the elevation point cloud data, and it can be passed either asreference_elev
, orto_be_aligned_elev
, or both. In the future, it will be easy to pass anxdem.ElevationPointCloud()
that knows thez_name
to avoid multiplying arguments, see #463.A
gpd.GeoDataFrame
is always compared to agu.Raster
usinggu.Raster.interp_points
, fully consistent and tested since https://github.com/GlacioHack/geoutils/pull/484. It mirrorsXarray.interp()
behaviour, but should be faster on equal grids thanks to using directlymap_coordinates
. Agu.Raster
is converted into points usingto_points()
(for tests or for fallback mechanism in theCoreg
class discussed in #402). This still requires some fixes in GeoUtils to avoid passing too many arguments: https://github.com/GlacioHack/geoutils/issues/499.Everything is done through
fit()
andapply()
.Changes
This PR:
apply_pts
andapply
, andfit_pts
andfit
,fit
orapply
into non-public_preproc_...
and_postproc_...
functions for better organisation and clarity depending on input type (point or raster),reference_dem
anddem_to_be_aligned
intoreference_elev
andto_be_aligned_elev
as inputs can be DEMs or elevation point clouds,_fit_func()
into_fit_rst_rst()
(only valid for "Raster-Raster") for all subclasses,_fit_pts_func()
into_fit_rst_pts()
(for "Raster-Point"), and adds a_fit_pts_pts()
(for "Point-Point"); also renames_apply_func()
into_apply_rst()
(apply to a raster) and_apply_pts_func()
into_apply_pts()
(to point),Coreg._fit_func()
which distributes to all otherfit_rst_rst()
,fit_rst_pts()
andfit_pts_pts()
of subclasses. Same forCoreg._apply_func()
that distributes to_apply_rst()
and_apply_pts()
depending on input type.gpd.GeoDataFrame
with a column namez_name
(in the future will easily acceptgu.PointCloud
that can be created easily from an array and read from a point cloud file e.g. LAZ, but need to wait for GeoUtils PRs for this),CoregPipeline._apply_rst()
function by an overriddenapply()
function to work properly for any point/raster input and withBlockwiseCoreg
, this mirrors the overriddenfit()
function added in #436,_fit_rst_pts()
that had inconsistent input/output,apply_matrix()
function into_apply_matrix_rst()
, and moves the code used to apply matrix transforms to point data into a new_apply_matrix_pts()
function, and wraps them into a newapply_matrix()
function that works on any raster or point! Also makesinvert_matrix()
public throughcoreg
,BiasCorr.fit_rst_rst()
intoBiasCorr._fit_biascorr()
to be able to call it throughBiasCorr.fit_rst_pts()
without being overridden by subclass functions, and now calls directly this parent class function in most subclasses, also renamed inBiasCorr1D
,2D
, etc, to maintain the chain of checks,subsample_final
key inCoreg._meta
to save the number of final pixels used during Coreg, see #479,NotImplementCoregFit
andNotImplementedCoregApply
subclasses ofNotImplementedError
to differentiate these specific type of errors made to track the implementation of Coreg subclass methods to other potentialNotImplementedError
.test_biascorr
to check any combination of raster-raster, raster-point or point-raster input for all functionalities, with checks verifying that all corrections indeed remove 99% of the variance introduced artificially,test_coreg/
, almost everything was passing the same way with the new structure!GradientDescending
test values by half a pixel due to previous enforcement of "area" or "point" coordinates,test_affine
will have to come in another PR, see below.Additionally, this PR makes all
UserWarning
fail tests at the package level, and removes the individualwarnings.simplefilter("error")
. All other warnings that depend on our routines are either fixed, filtered or caught if expected during the tests.Resolves #472 Resolves #479 Resolves #402 Resolves #475 Resolves #134 Resolves #404 Resolves #489 Resolves #376 Resolves #377
TO-DO:
biascorr
,test_biascorr
,CoregPipeline
.For later
Reworking tests in
test_affine
and adapting some of the functions: more efficient if done in another PR after working on theAffineCoreg
restructuration for being more modular. Opened #485.