New cell value created in intermediate layer and is missing from biophysical table

[KLI]

What is the issue or question you have?

I am getting an error ‘The following 1 raster values [15] do not have corresponding entries in the value map’. However, 15 is not a value in the original raster. It appears to be created in an intermediate layer in the sdr module. The intermediate layer is /intermediate_outputs/churn_dir_not_for_humans/aligned_lulc_[my suffix]

What do you expect to happen?

Comparing to the intermediate layer created using a similar raster that didn’t result in an error, I expect the cell with value = 15 to be nodata. The nodata value is 9999 for both the working and problematic rasters, as far as I understand. I’ve attached both rasters for reference (the original inputs, not the intermediate layers).

Also, the problematic raster works without issue for the seasonal water yield module.

What have you tried so far?

I have run the tool successfully using a similar land cover raster (same extent, resolution, projection and land cover classes). I processed that raster to create a new raster to represent a different management scenario, without introducing any new land cover classes (as far as I know). This results in the error described above.

Here is a comparison between the two intermediate layers. The teal area around the second image is cell value 15.

Attach the logfile here:

InVEST-natcap.invest.sdr.sdr-log-2023-07-28–09_48_58.txt (12.0 KB)

Here are the two landcover rasters (the first one runs with no error)

CDL_2022_reproj.tif (44.0 KB)
flrstrp_fld12.tif (21.2 KB)

[dave]

Hi @KLI , great question. And thanks for sharing your data here. The difference between the two rasters you shared is the datatype. In particular, the problematic one is an unsigned-8bit integer (or Byte) type. That is a perfectly acceptable type, but it can only store values between 0 - 255. And the nodata value is set to 9999. So when SDR tried to set the areas outside of the watershed vector to nodata, it ended up trying to squeeze a value of 9999 into an 8-bit integer, which resulted in 15. We can confirm this using python and numpy:

In: numpy.array([9999], dtype=numpy.uint8)
Out: array([15], dtype=uint8)

So your solutions could be to re-define your nodata value to something within 0 - 255, or to export to a new raster using a larger datateype such is 16-bit Integer.

[KLI]

Thank you for explaining this, @dave! I was wondering where the 15 came from. I did not realize the datatype had changed. This clears things up.