Hello folks,
I am running the NDR model and it returned an error. It says the encountered 128 is keyerror. I could not figure out what this problem is.
I really appreciate it if anyone could help me figure out what it means. The log is attached.
Hi @urgendalai, There are a number of other posts on this forum about KeyErorr with the NDR model, such as this one InVEST 3.7 and 3.3.3 NDR error
Please take a look and see if the answer is out there somewhere. Also, upgrading to invest 3.8.0 might yield a more descriptive error message for this case.
@dave, thank you for replying. I have updated to 3.8 version and noticed that post. I tried the way you mentioned in the post although I can not find any category name 128 in the landuse raster.
I wonder if I add the additional line with all zeros, would it affect the results of calculation?
Yes, adding a row in the biophysical table for 128 should resolve the error. However, if 128 is supposed to represent nodata in the raster, then a better solution might be to check if the raster has that value correctly set as it’s nodata value. Then the model would appropriately ignore those 128 pixels.
I’m using InVEST 3.8 and just had a similar thing happen with SDR. My input land cover map has a NoData value set to -128 and no pixels have a land cover class Value of 128. Yet, the model gave an error that 128 is missing from the biophysical table.
When I look at aligned_lulc.tif (generated by the model), it does now have pixel Values of 128, which have been assigned where the original LULC has NoData. Meanwhile, that raster’s NoData is still set to -128.
One thing I wonder about: The original LULC raster has a pixel type of signed integer, while aligned_lulc.tif is unsigned integer. Is it possible that something got lost in translation between the two?
Indeed, when I add the lucode of 128 to the biophysical table it runs fine, so that is a useful workaround.
~ Stacie
Thanks for pointing that out Stacie. It does sound problematic that the datatype is changing during the alignment step and overflowing to that new pixel value in the process. I’ll see if I can reproduce that behavior.e
Thank you @swolny and @ dave for helping on this. I have tried to delete the nodata pixels from my land use raster but it does not work still. My LULC does not have any sign to Nodata because I have given a blank when I create the raster.
Please let me know if you have an extra solution to this.
@urgendalai, it’s possible your situation is not identical to what Stacie was experiencing. But if your original raster has any negative values, then it might be the same issue.
Anyway, if you are still seeing a KeyError then you will need to add a row to the biophysical table for the keys that are listed in the error message.
If they key that is listed should be represent nodata, you can still add the row to the table – it will not hurt – but you should probably assign that value as the nodata value for your raster. In general, it’s always a good idea to have a nodata value defined, rather than blank.
If none of this works, then please send me your landuse raster and I will take a closer look. You may upload as an attachment here or send me a private message. Also, please include the latest logfile if you are still getting an error.