Raster of C values as landuse

Description

I know that the SDR requires a landuse raster and a biophysical table. What I currently have is a raster of C-values on a pixel by pixel basis rather than a landuse code joined to a table of c and p values.

So I ran the raster layer unique values report to extract the c values, and used them as the lucode in my biophysical table. i added another column of c values and p values, and copied the column names from the SDR tutorial Gura table and populated those columns with 1 for a test run.

The run fails, with the error:

ValueError: Values in the LULC raster were found that are not represented under the ā€˜lucodeā€™

(see log), even though those values came out of my raster.

Maybe I cannot use decimal point values as lucode?
Maybe there is some translation/rounding error in the raster calculation?

If either of these, I suppose I need to recode/transform (I donā€™t know the correct term in GIS langauge) my raster?

If I do need to recode my rasterā€¦ has anyone got a pointer for me as to how to do that? I could perhaps brute-force it in R or something, QGIS is not my strongest point at the momentā€¦

thanks for reading this,

m

Log file

InVEST-natcap.invest.sdr.sdr-log-2022-08-02ā€“08_11_04.txt (41.3 KB)

biophysical table

unique_56_c_values.csv (24.5 KB)

raster

pro_56_rusle_c_clip.tif (5.6 KB)

InVEST version

3.11.0

Hi @gismat -

Sorry thatā€™s so complicated, and youā€™re taking an interesting approach, preserving all of your USLE C values in that way.

The User Guide does specify that the lucode field must be an integer, so Iā€™m not surprised that giving it floating point values causes problems.

I had been going to suggest that you could multiply your original USLE C raster by some large number, then use that to create an integer raster which preserves all of the decimal places that you need. However, since you have a variable number of 0s as the first digits, which will get dropped, this may produce lucodes that are not unique. But if it does produce unique lucodes for each USLE C value, it could be a good method. Youā€™d just need to export your values to a table like you did last time, then divide by that same large number to get the values used in the usle_c column.

Iā€™m trying to think of how you could assign a new integer lucode to each C value, which would retain the link between lucode and value. It might be a little easier if QGIS would finally support raster attribute tables, but even then those usually donā€™t work with floating point rasters, so youā€™d need to do a workaround. Iā€™ll need to ponder this further, and would love to hear ideas from others.

~ Stacie

@gismat how about this, which is similar to what I described earlier:

1/ Use Raster Calculator to add 10 to pro_56_rusle_c_clip.tif, then multiply by 1,000,000 (you may need to adjust the multiplier value to retain the number of significant digits that you want). This will allow you to preserve the variable number of heading zeroes in your floating point values:
(ā€œLULC_p10_x1m@1ā€ + 10) * 1000000

2/ Use the tool Raster > Conversion > Translate to export the result of #1 to an integer raster. To do this, expand the Advanced Parameters and set Output data type to Int32.

3/ Extract the unique raster values from #2 as you did before (which is a tool that I was not aware of, very cool).

4/ To create the biophysical table, keep one column with the large integer values for the lucode, then create the usle_c column, where you divide the integer value by 1,000,000 (or whatever you used in #1) and subtract 10.

5/ Use the result of #2 for your LULC raster.

Let me know if this works for you.

Now, having this C map be your LULC does make it funky for assigning usle_p values, so hopefully you donā€™t need to do that.

~ Stacie

1 Like

it took a while for me to get back to the computer to be able to do this, but yes, it appears to have worked just fine!

Great! Thanks for letting us know.

~ Stacie

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