Hi, I am runnig the Carbon sequestration model and found one issue in my results. My raster has 20 LULC types, 19 show reasonable results and only one delivers zeroes in the carbon values for this particular LULC. It is the same in the four carbon pools and the total C as well. Any idea what could be the trouble?
1 Like
Hello @evselem -
Presumably you have provided non-zero carbon pool values for that LULC type? Can you post an example illustrating the issue? It would be useful to see the carbon pool table, and the results that have the zero values. Thanks!
~ Stacie
HI SWolny,
I hope I’ve done the right path to upload a couple of pictures, the .csv table and ArcMap window showing all the zeros in every pool. Otherwise, please explainme how to attach pictures to this reply. Thanks
Enrique
The problem is in LULC “Bosque de pino” only.
Now I’ve put arbitrary values in the LULCs which had all zeros (water and urban zones), and now I get C values in “bosque de pino”, where I had only zeros before… What happened?
Sorry to be so annoying. Now I’ve rearranged the order of the LULCs in the table so they match the same order as in the attributes table of the LULC raster, and it seems to work OK now. It looks like LULC “Bosque de pino” in the raster was stealing the zeros from LULC “Cuerpo de agua” in the table. Zeros are now where they are intended to be. Perhaps someone else has gone through this issue, hope this thread helps.
Well that’s interesting, and kudos to you @evselem for figuring that out. In theory, I don’t think that it should matter which order the LULC values are in within the carbon pool table. The only thing that should matter is that you’re using the same “lucode” value in the carbon pool table as “Bosque de pino” is assigned in the land use raster.
Could you do us a favor and send the carbon pool tables, or a screenshot of the tables, before it worked and after you fixed it? Thanks!
~ Stacie
Thanks Swolny for the kudos! Here I attach screenshots of the modified .csv table and the atributes table of the raster. I wish there is an explanation to this issue.
Perhaps the “VALUE” column in the atributes table should be renamed to “lucode”?
Thanks @evselem. The “VALUE” column in the raster attribute table must be named VALUE, that is a standard raster column that does not change. The model knows how to find the VALUE column and match it to the “lucode” column in the table.
Can you also post the carbon pool table that did NOT work? I’d like to see what exactly changed between the version that worked and the version that didn’t. Thanks again.
~ Stacie
Hi Swolny, the screenshot of the unuseful table is the first one up here, which I posted yesterday. The one which worked correctly is the last one. Do you need the csv files or just the screenshots?
Did you only change the “lucode” values in the carbon pool table to make things work, or did you also reclassify any of the values in the land use raster?
Looking at the screenshots, the raster attribute table shows Cuerpo de agua with a Value of 10, and Bosque de pino with a Value of 11. But, in the first carbon pool table you posted Bosque de pino has an lucode of 8, and Cuerpo de agua has an lucode of 11. Then in the second carbon pool table you posted, Cuerpo de agua has an lucode of 10, while Bosque de pino has a value of 11.
So I’m thinking that the problem with the first carbon pool table was that there’s a mismatch between the land cover type represented by the raster Values as compared with land cover type represented by the same lucode field in the table. The model matches the raster Value to the carbon pool table lucode to assign the carbon pool values.
So I think the model is working correctly, but I’d advise making sure that all of the lucodes match correctly with the land cover types in the raster.
~ Stacie
Hi Stacie, what I did was reorder the .csv table to match the order in the raster’s table. I think that the model worked correctly, in matching the “lucode” in the table with the “Value” column in the raster. I ignored that there must be coincidence in the LULC code in both tables, that was the failure. A useful experience for the next time, thanks for your assistance!
To be clear for anyone coming here in the future, the lucode column of the biophysical table must contain integer values that match the pixel values of the LULC raster.
InVEST does not read the raster attribute table. The model opens the raster, reads a pixel value from it, and looks up that pixel value in the lucode column of the biophysical table.
Thanks Dave for setting this issue neatly. Perhaps adding a warning in the model guidelines would save others out of this problem
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.