I ran the NDR model with InVEST 3.10.2 and was able to calibrate my results to something that seemed realistic. I was also running another model, SDR, and realized a newer version of InVEST was available (3.14.0) with more telling results. For consistency, I want to use the same version of InVEST for all my models, but I am running into issues with the NDR model (everything went well with SDR). Overall, I am not getting the same outputs from the NDR model between the two versions. I am also a bit confused because in the user guide, the list of columns in the biophysical table is not the same as what is shown in the example (NDR: Nutrient Delivery Ratio — InVEST® documentation). The biophysical table example shows usle_c, usle_p, root depth, kc and LULC_veg, which are not described in as needed columns.
Overall, I came across two problems while trying to run the model version 3.14.0:
First, when I put the exact same data input in the version 3.14.0, my biophysical table is rejected and the message (csv : Expected the column “proportion_subsurface_n” but did not find it
) shows, even though I only indicated to calculate phosphorus.
To overcome this, I made another version of my biophysical table with a ‘‘proportion_subsurface_n’’ column with no values. This leads to my second issue, where the results from this run with 3.14.0 are drastically different than with 3.10.2, and show some negative values. The pixel result layer also does not show in QGIS.
That’s correct, the example shown in the users guide is from our sample data which includes the extra columns because it is also sample data for others models. Sorry for that confusion, but only the listed columns are needed and used by the model.
I’m able to reproduce this as well, thanks for pointing this out and I think your work around for this sounds good.
Thanks for sharing your logfiles of both versions. This is pretty interesting and similar to your habitat quality post:
2023-11-30 20:07:06,685 (pygeoprocessing.geoprocessing) geoprocessing.align_and_resize_raster_stack(1000) INFO aligned all 3 rasters.
2023-11-30 20:07:06,973 (osgeo) utils._log_gdal_errors(97) WARNING [errno 1] Too few points in geometry component at or near point 931.63784461152864 -814.10501253132861
2023-11-30 20:07:06,974 (osgeo) utils._log_gdal_errors(97) ERROR [errno 1] Cutline polygon is invalid.
2023-11-30 20:07:07,224 (osgeo) utils._log_gdal_errors(97) WARNING [errno 1] Too few points in geometry component at or near point 931.63784461152864 -814.10501253132861
2023-11-30 20:07:07,224 (osgeo) utils._log_gdal_errors(97) ERROR [errno 1] Cutline polygon is invalid.
2023-11-30 20:07:07,419 (osgeo) utils._log_gdal_errors(97) WARNING [errno 1] Too few points in geometry component at or near point 931.63784461152864 -814.10501253132861
2023-11-30 20:07:07,419 (osgeo) utils._log_gdal_errors(97) ERROR [errno 1] Cutline polygon is invalid.
There’s something funky going on with gdal handling your data. It’s not clear yet what might have changed in gdal between versions that would be handling your data differently. In any case, could you share your data so we can take a closer look at this? An easy way to capture all the inputs in an archive to share can be seen in this post.
Just a quick follow-up here. We actually think this specific error you’re seeing related to “Cutline” will be addressed in the 3.14.1 release which is coming very soon!
In the meantime you can try this development build which should have the fix to get NDR working for you.
Here’s a related community post which experienced similar issues.
Let us know if that development version of InVEST does not fix this issue.
Hello!
Thank you, yes now I successfully installed 3.14.1. I ran my NDR model just like my initial run with 3.10.2. This time I got an error in the execution. Here is the log for details. With 3.14.0, I did not get an error but the result raster layers were empty and did not make sense. Shall I send my raw data? I would like to share it privately if possible. I have sent my data to Doug for another model so I could do the same for this. InVEST-natcap.invest.ndr.ndr-log-2023-12-19–15_25_05.txt (14.3 KB)
I also understand if you all need an invest break for the holidays
Hi @RFrechon , glad the new version is working out.
The final error message indicates:
KeyError: ‘lucode: 0 is present in the landuse raster but missing from the biophysical table’
Is it true that lucode 0 is missing from your table? If not, you may share your input data with me (Doug is off for the holidays) davefisher@stanford.edu
Awesome! Thank you, that was a trivial mistake. The run succeeded and the results are a bit different at the pixel level but in the same order of magnitude. However, I have another questioning regarding the results. One of the main watersheds is not modelled in the result vector layer, could it be because it is bigger than the modelled area? Thank you! InVEST-natcap.invest.ndr.ndr-log-2023-12-19–17_26_37.txt (21.9 KB)
Hi @RFrechon , thanks for sharing your data with me, and for your patience over the holidays.
It appears like many of the watershed polygons are outside of the area where you have valid input data. From the data you shared, the LULC input has the smallest footprint and the results are therefore limited to that same area. Whereas the watershed polygons cover a much larger area, most of which is not modelled.
There is also something strange about the watershed polygons. The ones highlighted here in red are actually represented in the data as one single watershed feature, which seems incorrect.
It’s also probably important for each watershed to be “complete”, whereas the bottom border here seems like it is artificially cutting off part of those watersheds. I think the NDR results will only be valid for watersheds that are completely contained within the area of valid input data.
