noob here again.
I read in geoTIFFs using xarray’s open_rasterio. I notice that the nodatavals attribute is always a tuple of length one, e.g. (nan,) or (-9999.0,). I also only deal (so far) with single band TIFFs. I have searched and, if anything, concluded that there’s not really an official standard here. So, questions I’d really appreciate people’s guidance on are:
- Is it a tuple to deal with the general case of n-bands in the input file, and allow for different nodatavals per band?
- Is it a tuple to deal with multiple nodataval encodings within a single band? (Is this possible? Illegal? Dumb?)
- This flows through to nodatavals being a tuple (of length 1) in the xarray DataArray’s attribute. I’m preserving this as a tuple, but could I (should I?) drop the tuple and just retain the scalar nodataval for the attribute?
- Is there anything special about the nodatavals attribute in xarray? (xarray methods do seem keen to drop attributes, in general, so I’m guessing this isn’t critical at all).
- I’m hazy on this (it’s been a few months now), but some people can create geoTIFFs with no nodatavals tag/metadata. I think open_rasterio defaults to assigning the nodatavals attribute to (nan,) in that case. In the past (several months ago), I was detecting the (nan,) and correcting the data based on what the user had told me was actually used to encode nodata. Given that (nan,) can be a genuine encoding for nodata, is there a better way of detecting that the geoTIFF creator didn’t supply this tag? Note, an acceptable answer is “No, you’d just need to know and explicitly override on a file by file basis.”
This is part of my own IO routine that ingests multiple geoTIFFs and stacks them, so by the time they’re stacked I’d like to have a consistent, single, notion of “nodata” (i.e. np.nan).