Too hard to create a raster with a run-time data type

[lnicola]

Driver::create_with_band_type_with_options takes the type as a generic parameter, which is pretty annoying.

[jdroenner]

i guess that depends how you use it. I usually want to read data with the type of the dataset and when creating a dataset i want that to have the type of the data. In both cases it is nice to use the same generic T for rasterio and driver/band creation.
I guess we can also add another method where the type is provided as a parameter.

[metasim]

I find this super frustrating also. As a point of comparison, I have this sort of thing all over my code:

match &raster.cell_type {
    CellType::UInt8 => write_dataset(&raster.data.cast_as::<u8>(), &raster.mask, self),
    CellType::UInt16 => write_dataset(&raster.data.cast_as::<u16>(), &raster.mask, self),
    CellType::UInt32 => write_dataset(&raster.data.cast_as::<u32>(), &raster.mask, self),
    CellType::Int16 => write_dataset(&raster.data.cast_as::<i16>(), &raster.mask, self),
    CellType::Int32 => write_dataset(&raster.data.cast_as::<i32>(), &raster.mask, self),
    CellType::Float32 => write_dataset(&raster.data.cast_as::<f32>(), &raster.mask, self),
    CellType::Float64 => write_dataset(&raster.data.cast_as::<f64>(), &raster.mask, self),
}

As an antidote, i've been working on a side project called erased-cells to allow for compile-time-deferred celltype handling. No GDAL connector yet, but will currently have to gdal_sys directly to get everything I need. :(

[lnicola]

I just realized it's create_with_band_type_with_options and not create_with_band_type_and_options 😅.

Time for a create_with_explicit_band_type_with_options? 😄

[metasim]

ooof 🤢

[geohardtke]

Hi there,
having written the original create_with_band_type_with_options (sorry for the ugly name ;p ) and with some time on my hands (and more knowledge) , I'm happy to help making this better.
Can you explain your use case a bit @lnicola ? Like the snippet you would write and doesn't currently work. I see @metasim example seems to be to write a raster directly from an array, which is slightly different to creating a new empty dataset.
cheers

[lnicola]

Writing an output with the same data type as the input, or with a compatible one if you have multiple inputs with different types. In the end, it boils down to the same thing metasim had.

[geohardtke]

What about create_copy() then? I guess the problem would be that you can't define how many bands you want right?

[lnicola]

Well, I don't want a copy, I want a new dataset/band with runtime-dependent data type. You can even take advantage of the built-in type conversions, e.g. writing a f32 buffer to a GDT_Int16 band, which.

https://docs.rs/gdal/latest/src/gdal/driver.rs.html#188 already takes GdalDataType, but it's not public.

[geohardtke]

Oh, I see now, sorry... the type as an argument to the function rather than a generic :).

[lnicola]

Yeah. I think we can safely rename _create_with_band_type_with_options to create.

[geohardtke]

What about having a DatasetBuilder; Something like:

let filename = "/tmp/image.tif";
let size_x = 256;
let size_y = 256;
let bands = 3;
let data_type = GdalDataType::UInt16;
let options = RasterCreationOptions::from_iter(["COMPRESS=LZW"]);

let driver = DriverManager::get_driver_by_name("GTiff")?;
let dataset = DatasetBuilder::new(filename, size_x, size_y, bands)
    .data_type(data_type)                                // not required, default to u8
    .options(&options)                                     // not required, default to none
    .build(&driver)?;

or would it be too different to the rest of the API ?