feat(rust/sedona-schema): Add Int8, UInt64, Int64 band data types, don't panic in BandMetadataRef

[Kontinuation]

Summary

• Add three new BandDataType variants: Int8, UInt64, Int64
• Derive Hash and Copy on both BandDataType and StorageType enums for ergonomic use
• Update match arms in BandMetadataRefImpl::data_type() to decode the new ordinals
• Update data_type() and storage_type() to return Result, don't panic when observing unknown values
• Extend test coverage and test data generators (generate_random_band_data, get_nodata_value_for_type) to handle all 10 band data types

[Copilot]

Pull request overview

This PR extends the BandDataType enum to support three additional data types (Int8, UInt64, Int64) and aligns all enum discriminants with GDAL's GDALDataType ordinals for non-complex types.

Changes:

• Renumbered existing BandDataType variants from 0-6 to 1-7 and added Int8 (14), UInt64 (12), Int64 (13)
• Derived Hash and Copy traits on BandDataType and StorageType for better ergonomics
• Updated test data generators and test cases to handle all 10 band data types

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
rust/sedona-schema/src/raster.rs	Updated BandDataType and StorageType enum definitions with new variants and trait derivations
rust/sedona-raster/src/array.rs	Updated match arms in BandMetadataRefImpl::data_type() to decode new ordinals
rust/sedona-raster/src/builder.rs	Extended test coverage with new data type test cases
rust/sedona-testing/src/rasters.rs	Refactored generate_random_band_data using macro and added support for new data types

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[paleolimbot]

Thank you!

It's great to align these with GDAL's model but probably better for the Rust enum / internal serialization to be separated from the integer storage.

[paleolimbot]

Should this return an error or is this validated before we get here? (i.e., do we risk a panic for a corrupted raster array?)

[Kontinuation]

Sure. I found that storage_type also need to be fixed, I have changed both storage_type() and data_type() to return Result<...>.

[paleolimbot]

If possible this may be a good time to add test for a corrupted band identifier to make sure it doesn't panic

[Kontinuation]

Added test_invalid_band_metadata_returns_err for testing this

[paleolimbot]

You could handle these with an Other(usize) variant (whose internal representation is opaque bytes).

[Kontinuation]

We don't need Other variant for now since we decided to not enforce the values of BandDataType to match GDAL. I believe that it is a better design.

[paleolimbot]

This is probably more flexible without the #[repr(u16)] since at some point we may need a variant to handle other types of data (e.g., generic fixed size). It's great to align our representation to GDAL's but it is probably better scoped as try_to_gdal_band_data_type() -> u16 and try_from_gdal_band_data_type(gdal_type: u16).

[Kontinuation]

The values here were happened to be the same as GDAL band data types. We'll have functions for converting between then rather than implicitly relying on it. https://github.com/Kontinuation/sedona-db/blob/0e73e17a79332cf7e58b9881084d86dd3f3531c1/rust/sedona-raster-gdal/src/gdal_common.rs#L50-L88

I decided to simply define the values without GDAL awareness just as before.

[paleolimbot]

Thank you!