@metasim yes, to determine the celltype correctly we need
sampleFormat, bitsPerSample is number of bits per tiff sample, and the
sampleFormat is used to determin the ‘sing’ of values.
LIBTIFF exposes this information and in geotiff native jvm reader we also use this information to determine the cellType properly: https://github.com/locationtech/geotrellis/blob/7871e015129ae4a1ccfd06a23544a6de9ac68c6e/raster/src/main/scala/geotrellis/raster/io/geotiff/BandTypes.scala#L37
However GDAL doesn’t expose such information, or I didn’t find a proper way of doing it. Probably you can find smth in the GDAL C API and somehow get the information from the used driver about the raster cellType, but I’m not sure that it is possible to expose such information via GDAL
import geotrellis.spark._in the call scope. If you have it and function still doesnt work try to use
withGetBoundsMethod(rdd).getGridBoundsin your code, this at least will give you a readble compile time error.
It would be awesome if you could sign an ECA https://github.com/locationtech/geotrellis/blob/master/docs/CONTRIBUTING.rst#eclipse-contributor-agreement-eca
after that commit changes via
git commit -s -m “commit message” command
@metasim we didnt resolve that; imagine the case that you have multiple RasterSources
you want to figure out how to tile them to some layout in some projection…
it would mean that you probably need to collect metadata in some CRS or reprojet it into some CRS to have some idea of the entire rasters list extent