Select resampling algo #141
Conversation
|
I've just started using Rust, so I'm not sure this is the best implementation (it introduces some breaking changes). I'm happy to change it if there is a better way! |
|
Looks like this needs rebasing ( |
|
It does. When reading a window, if |
spadarian
force-pushed
the
select_resampling_algo
branch
from
019bf04 to
565d241
Compare
src/raster/rasterband.rs
Outdated
| #[derive(Debug)] | ||
| pub struct RasterIOExtraArg { | ||
| pub n_version: libc::c_int, | ||
| pub e_resample_alg: GDALRIOResampleAlg::Type, |
There was a problem hiding this comment.
i think we should have an enum for the resample algorithms. That will make it easier for most users.
There was a problem hiding this comment.
I think I actually prefer constants here because of the enum exhaustiveness matching issue. See also the layer caps PR.
There was a problem hiding this comment.
GDALRIOResampleAlg::Type are already constants. Should I create a mod inside rasterband to map it?
There was a problem hiding this comment.
@lnicola i don't think that gdal will add more algorithms for resampling and they are an enum in GDAL anyway. Without an enum you can input "9323411". Or is there another issue with the enum approach?
@spadarian i would suggest to add an enum in rasterband.
There was a problem hiding this comment.
@jdroenner I added an enum with the names of the algorithms and a function to map them to integers (GDAL uses integers).
src/raster/rasterband.rs
Outdated
| pub n_version: libc::c_int, | ||
| pub e_resample_alg: GDALRIOResampleAlg::Type, | ||
| pub pfn_progress: gdal_sys::GDALProgressFunc, | ||
| pub p_progress_data: *mut libc::c_void, |
There was a problem hiding this comment.
We should hide the pointer stuff for now. In the long run we could add a callback and/or a future/channel to access the state.
src/raster/rasterband.rs
Outdated
| pub e_resample_alg: GDALRIOResampleAlg::Type, | ||
| pub pfn_progress: gdal_sys::GDALProgressFunc, | ||
| pub p_progress_data: *mut libc::c_void, | ||
| pub b_floating_point_window_validity: libc::c_int, |
There was a problem hiding this comment.
can we change this to i32 or another integer from core?
There was a problem hiding this comment.
I guess an usize should be ok as well.
Just out of curiosity, what would be the difference? Just a "readability" thing? Or is there any technical reason?
spadarian
force-pushed
the
select_resampling_algo
branch
from
00365ac to
969a187
Compare
|
I added the suggested changes and did a rebase. |
CHANGES.mdif knowledge of this change could be valuable to users.This PR changes the functions used to read rasters by adding an extra parameter to select the resampling algorithm used when
buffer_size != window size(GDAL needs to interpolate the values) (closes #140)