We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RasterBand::read_block
gdal/src/raster/rasterband.rs
Line 534 in d279c9f
We don't validate that T matches the band data type, so there's nothing preventing the user from using a smaller type.
T
I've used something like:
#[derive(Debug)] pub enum TypedBlock { U16(Array2<u16>), I16(Array2<i16>), F32(Array2<f32>), // ... } pub trait RasterBandExt { fn read_typed_block(&self, x: usize, y: usize) -> gdal::errors::Result<TypedBlock>; } impl<'d> RasterBandExt for RasterBand<'d> { fn read_typed_block(&self, x: usize, y: usize) -> gdal::errors::Result<TypedBlock> { match self.band_type() { GdalDataType::UInt16 => { let buf = self.read_block::<u16>((x, y))?; Ok(TypedBlock::U16(buf)) } GdalDataType::Int16 => { let buf = self.read_block::<i16>((x, y))?; Ok(TypedBlock::I16(buf)) } GdalDataType::Float32 => { let buf = self.read_block::<f32>((x, y))?; Ok(TypedBlock::F32(buf)) } // ... } } }
before, but I don't think it's the best possible abstraction here.
The text was updated successfully, but these errors were encountered:
gdal
yes we should check the type here. It is not the same as the normal read raster method where gdal will cast the type.
Sorry, something went wrong.
read_block
Successfully merging a pull request may close this issue.
gdal/src/raster/rasterband.rs
Line 534 in d279c9f
We don't validate that
T
matches the band data type, so there's nothing preventing the user from using a smaller type.I've used something like:
before, but I don't think it's the best possible abstraction here.
The text was updated successfully, but these errors were encountered: