NDR KeyError under 3.7 version

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.

  1. List itInVEST-Nutrient-Delivery-Ratio-Model-(NDR)-log-2020-04-14–21_38_39.txt (10.2 KB) em

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.

1 Like

@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.

Hi,

I am having a similar, but seemingly different error.

KeyError encountered: -3.4e38

I am running NDR v 3.7. I have six land cover classes from 1 to 101. I have tried making all raster values <1 NA, changing raster NA values to a value of 255, and adding -3.4e38 to the biophysical table.

I also found this entry in the change log: https://invest.readthedocs.io/en/latest/changelog.html

2.4.3 (2012-10-19)

  • Fixed a minor issue with hydropower output vaulation rasters whose statistics were not pre-calculated. This would cause the range in ArcGIS to show ther rasters at -3e38 to 3e38.

Any suggestions on dealing with this issue?

Thanks in advance!

Cheers,

Caitie

Hi @cdkuempel,

The -3.4e38 is almost certainly intended to be a nodata value that’s set incorrectly. Setting your nodata value should be the solution here. Changing raster nodata values to 255 won’t fix it unless you also indicate that the nodata value is now 255. If you’re sure that it is set correctly, feel free to share your data and I’ll try to replicate the problem.

This shouldn’t have anything to do with that changelog entry. -3e38 or -3.4e38 are numbers that commonly come up because it’s the minimum value that can be stored in a certain number type in the computer’s memory. Because of that it’s often used as the nodata value.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.