Support multi-band GeoTiffs
gillesserco opened this issue · comments
Hello
I manage to use geotiffs as per the examples, that is making single band r/g/b files.
Is it possible to directly use the RGB geotiffs?
Thanks
best regards
Gilles
Nope. If anyone has suggestions for a clean way to support this I may be swayed to implement it.
ok, thanks for the quick reply. And more thanks for this nice tool...
FWIW, our sister project TiTiler exposes the band index parameter bidx: https://developmentseed.org/titiler/endpoints/cog/. Not sure how to make RGB composites from several bands, though.
A way we could support this in Terracotta without changing the API would be to store an (optional) band index with each dataset you register, basically adding a line here:
https://github.com/DHI-GRAS/terracotta/blob/964a72b022bea565a10a73d6cce0a40542304a90/terracotta/drivers/relational_meta_store.py#L242-L248
and passing that value through to the raster reader.
Then you you could just register your multiple-band raster multiple times and assign a different band (or so) key value each time. Then you can render it as RGB the usual way: https://terracotta-python.readthedocs.io/en/latest/concepts.html#data-model.
That would mean zero change to the API, but would mean a change to the database schema.
Interesting, that could work. I remember toying with something similar in #172.
IIRC my main concern was performance, it was my understanding that the COG standard required single-band files. But maybe that was a misread, or it got relaxed in the meantime.
it was my understanding that the COG standard required single-band files
The GDAL COG driver mentions multi-band https://gdal.org/drivers/raster/cog.html#high-level
Not sure about the performance, though, especially if you only read one band at a time and not blocks of all three.
If we implemented the suggested method, we would have an easy way to test that. 😄
it was my understanding that the COG standard required single-band files
The GDAL COG driver mentions multi-band https://gdal.org/drivers/raster/cog.html#high-level
Not sure about the performance, though, especially if you only read one band at a time and not blocks of all three.
If we implemented the suggested method, we would have an easy way to test that. 😄
Specifically, as a requirement for multi-band COGs, the driver documentation mentions that they should be written as pixel interleaved, which makes sense, as the driver can still read a block as one contiguous block of bytes and hence 1 HTTP range request.