Saving tif with scale factor and missval with Rasters changes the underlying data type on disk

[felixcremer]

I am not entirely sure, whether that is a huge problem, but was a bit annoying and it is a difference to how gdalwarp would handle it.
when I am saving a tif with an offset and missingval back to disk I don't get the same data type as the input.
In the example below the type of the data on disk is Int16 and this is then for the computations changed to Float64 due to the scale factor.
When I then save the data back to disk it is a Float64 data and the scale factor is already applied.
This came up, because I wanted to crop a raster by an extent to use the data then for testing and therefore the change in the underlying representation is a problem.

url = "https://github.com/meggart/RQADeforestationTestData/raw/refs/heads/main/V0M2R4/EQUI7_EU020M/E051N018T3/SIG0_20200701T050807__VH_D022_E051N018T3_EU020M_V0M2R4_S1BIWGRDH_TUWIEN.tif"
f = download(url)
r = Raster(f)
write("test.tif", r)
s = Raster("test.tif")

[rafaqz]

I think this is just a bug, it should be converting back to the internal type.

We must be taking the eltype from the wrong place.

(I think the tests are just comparing values and not type on disk so they dont fail as the results are the same)

[tiemvanderdeure]

If it should convert then it should also re-apply the scale factor - but that's not really possible as all kinds of things might have happened to the raster in between.

Just setting raw = true should fix it?

EDIT: that doesn't totally fixed it because the "scale" in the metadata is not written - which probably is a bug?

[rafaqz]

Not sure I understand, if anything happened to the Raster then the modified layer will be wrapped and won't be visible to dispatch, so the current external type will be used. But if ModifiedDiskArray is not wrapped it should write as the internal values

The scale is already inverted during writes so it should work correctly both ways