Okay, thanks! So the interpretation we are aiming for is option a): Each band is treated independently, and each one has its own NODATA value. The NODATA value of one band is unrelated to that of the others. That said, the question is whether this behavior is consistently supported across all formats, or if it only works this way in our custom implementation. If not, perhaps the more robust approach would be to separate bands with different NODATA values into different subdatasets. It’s possible that I’ve made a mistake in my implementation, but from what I’ve seen, formats like RST or GeoPackage don’t seem capable of handling this situation properly. In any case, I’ll end up implementing a function that determines how to group bands into datasets, and it will use the NODATA values to decide whether bands should be placed in the same subdataset or split into separate ones. I'm looking forward to hearing your thoughts on what the best approach would be in a case like this.
Abel. ________________________________ De: Even Rouault <even.roua...@spatialys.com> Enviat el: dimecres, 21 de maig de 2025 16:55 Per a: Abel Pau <a....@creaf.cat>; gdal-dev <gdal-dev@lists.osgeo.org> Tema: Re: [gdal-dev] NODATA values in diferents bands in a DataSet Abel, there is a subtelty: a) If bands may have invalid pixels at different locations on different bands, and that those bands have a different nodata value, then using GDALRasterBand::SetNoDataValue() is the way to go. b) If a given pixel is invalid only if its value on all bands matches the nodata value on each band, then NODATA_VALUES should be set instead Example with 2 bands: - Band 1, NoData=1, pixel_1=1, pixel_2=1 - Band 2, NoData=2, pixel_1=2, pixel_2=0 In interpretation a), then pixel_1 and pixel_2 are invalid for Band 1, and pixel_1 is invalid for Band 2 In interpretation b), then only pixel_1 is invalid (for both bands) Le 21/05/2025 à 08:46, Abel Pau via gdal-dev a écrit : Hello, I am implementing a driver that allows different NODATA values for each band in a dataset. >From what I understand in the documentation, I should use the NODATA_VALUES >metadata item to document these values. However, I don't see a clear way to >indicate that a specific band has no NODATA value within the tuple. On the other hand, the documentation also suggests that NODATA_VALUES is not widely honoured, which is not very encouraging. Therefore, would you consider it good practice to separate bands with different NODATA values into separate subdatasets instead? Thank you very much for the clarification. Abel Pau Garcia<https://www.creaf.cat/en/about-us/our-people/abel-pau-garcia> <https://www.creaf.cat/en/about-us/our-people/abel-pau-garcia> [https://www.creaf.cat/sites/default/files/2024-10/logo-creaf-small.jpg] <https://www.creaf.cat/> MiraMon Technical Lead <https://www.creaf.cat/en/about-us/our-people/abel-pau-garcia> a....@creaf.cat<mailto:a....@creaf.cat> <mailto:a....@creaf.cat> [https://www.creaf.cat/sites/default/files/cap_0.png] Let's chat on Teams!<https://teams.microsoft.com/l/chat/0/0?users=a....@creaf.cat> <https://teams.microsoft.com/l/chat/0/0?users=a....@creaf.cat> Tel. +34 [https://www.creaf.cat/sites/default/files/2024-10/x_30.png] <https://twitter.com/CREAF_ecologia> [https://www.creaf.cat/sites/default/files/2024-10/linkedin_30.png] <https://www.linkedin.com/company/creaf/> [https://www.creaf.cat/sites/default/files/2024-10/youtube_30.png] <https://www.youtube.com/c/creafecologia> [https://www.creaf.cat/sites/default/files/2024-10/instagram_30.png] <https://www.instagram.com/CREAF_ecologia/> www.creaf.cat<http://www.creaf.cat> <http://www.creaf.cat> | Latest news<https://www.creaf.cat/en/news-and-agenda/news> <https://www.creaf.cat/en/news-and-agenda/news> CREAF. Campus UAB. Edifici C. 08193 Bellaterra (Barcelona) <https://www.openstreetmap.org/way/123379060> Privacy policy<https://www.creaf.cat/privacy-policy> <https://www.creaf.cat/privacy-policy> [https://www.creaf.cat/sites/default/files/2024-10/corner_right_0.png] Before printing this electronic message, think about the environment. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org> https://lists.osgeo.org/mailman/listinfo/gdal-dev -- http://www.spatialys.com My software is free, but my time generally not.
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
