james-willis commented on code in PR #1056:
URL: https://github.com/apache/sedona-db/pull/1056#discussion_r3605848144
##########
rust/sedona-raster-functions/src/rs_setsrid.rs:
##########
@@ -395,9 +395,33 @@ mod tests {
use sedona_raster::traits::RasterRef;
use sedona_schema::crs::deserialize_crs;
use sedona_schema::datatypes::RASTER;
+ use sedona_testing::raster_spec::{assert_rasters_equal, RasterSpec};
use sedona_testing::rasters::generate_test_rasters;
use sedona_testing::testers::ScalarUdfTester;
+ /// The non-null raster that [`generate_test_rasters`] produces at index
+ /// `i`, expressed as a declarative spec: the same per-index geotransform
+ /// arithmetic and sequential UInt16 pixels with nodata 0. Used as the
+ /// expected side after an RS_SetSRID/RS_SetCRS, which only swaps the CRS
+ /// and preserves everything else — so callers append `.crs(...)` with the
+ /// CRS they expect.
+ fn generated_raster_spec(i: usize) -> RasterSpec {
+ let width = i as i64 + 1;
+ let height = i as i64 + 2;
+ let pixels: Vec<u16> = (0..(width * height) as u16).collect();
+ RasterSpec::d2(width, height)
+ .transform([
+ i as f64 + 1.0,
+ i.max(1) as f64 * 0.1,
+ i as f64 * 0.03,
+ i as f64 + 2.0,
+ i as f64 * 0.04,
+ i.max(1) as f64 * -0.2,
+ ])
Review Comment:
arguably. Two reasons we dont:
* bbox always has 0 skew so we wouldn't test that skew values are preserved
* we are testing the geotransform is round tripped so I dont think
abstracting it to a bbox is important here. The actually spatial extent of the
bbox/transform is not important, just the fact it survives the function call
cleanly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
