my results from the usle are to big. for example a agricultural field with almost one hectar has a total soi loss of about 206 t/ha/year (zonal statistics -> sum of the pixels in the field). the mean value for one pixel in this field is about 0.14 t/ha/year. i used a dem with a resolution of 2.5m x 2.5m.
the imputdata was as follows: R=746(all area); K=0.27(all area); C=0.26 (agricultural area) lulc.csv (121 Bytes)
k=2; IC0=0.5; SDR= 0.34
i allready calculated the usle in GIS by myself. with the inputdata especially the c-codes i got quite good results. even the ls-raster from the intermediate_outputs is not to high compared to my ls-raster caluclated in GIS.
the InVest model is calculating succesfully, there is a warning though at the flow acumulation part:
04/20/2019 10:49:09 natcap.invest.sdr INFO calculating flow accumulation 04/20/2019 10:49:09 natcap.invest.pygeoprocessing_0_3_3.routing DEBUG starting flow accumulation 04/20/2019 10:49:14 natcap.invest.pygeoprocessing_0_3_3.routing.routing_core WARNING no flow direction found for 0 2 WARNING no flow direction found for 0 2 04/20/2019 10:49:14 natcap.invest.pygeoprocessing_0_3_3.routing.routing_core WARNING no flow direction found for 0 2 04/20/2019 10:49:22 natcap.invest.pygeoprocessing_0_3_3.routing.routing_core INFO calculate transport cells_to_process.size() = 352 04/20/2019 10:49:22 natcap.invest.sdr INFO calculate ls term 04/20/2019 10:49:22 pygeoprocessing.geoprocessing INFO starting stats_worker 04/20/2019 10:49:22 pygeoprocessing.geoprocessing INFO started stats_worker <Thread(Thread-6, started daemon 11488)> 04/20/2019 10:49:26 pygeoprocessing.geoprocessing INFO 100.0%% complete
not sure if this warning causes proplems calculating the usle…
what do i miss? can anybody help me out here, please?
thank you!
I can’t really speak to whether or why the USLE has high values in this case, but I can say that the warnings you’re seeing are normal and merely extra logging that no flow direction could be found for a specific pixel, which happens if a pixel does not flow into any pixels at all (like when it’s the downstream-most pixel in a watershed).
You might also be interested to note that we’ve been working on an updated version of SDR that you might want to take a look at. We believe the multiple flow direction routing implementation included there to be more biophysically correct than the D-infinity we had before. The link to the development build is below.
Hey! i had some issue with the index values. i think it was the R-Faktor. my result was obviously about 10 times higher. there are some example-files (raster) to download. compare them to your data and you will find the problem.
Thanks for your message.
I also compared the R-factor with other research in the same field, the value is in the right range,but solpe.tiff and ls.tiff seem to be strange when compared with other research ,so I am confused.
I thought i have, but unfortunately i did not solved my problem with the high values.
Calculated with InVest my arable parcels do have an average erosion from 10-200 ton per ha a year. The flattest, most even parcel has about 10 tons per ha a year! Realistically and already calculated “by hand” and Arc (D8 method) the average erosion on the arable-parcels in the catchment is about 1-20 ton per ha a year. –> one of my inputdata is 10 times to high!? The catchment is in Austria/Europe. Meaning all the data is in metric units. it is therefore not a problem of US/metric units.
In austria the R-factors are normaly in (kJ/m²)(mm/a). i corrected that to the Invest unit (MJ/ha)(mm/a). The precipitation a year in my catchment is about 35inches. a bit less than in the sample datas catchment in Corvallis Oregon (aprox. 51inches).
The lulc biophysical table mentioned in the users guide “should be integer” (so are the sample-data), but integer files causes an error. i changed to float numbers. should be fine.
The K-factor (erodibility_SI_clip) in the sample data is low. What kind of soil is it? Maybe my K-factors are to high?
the reason why i am asking so many questions in this forum lately is that i am writing my master-thesis about soil erosion modelling (with InVEST…surprisingly). InVEST is basicly unknown at my university and therefore many colleagues are highly interested about it.
I would double-check your K factor values. They look similar to the values included in the User Guide SDR Appendix A table, which are in US units, and require a conversion factor of 0.1317 to get metric units (which is noted below the table, but maybe not made obvious enough.) The units for both R and K are very confusing!
I’m not sure if this will explain all of the high values you’re seeing, but it might.
Hi @swolny ,
Recently, I am confused about the unit in SDR and NDR model. The output files in SDR model include, sed_export_[Suffix].tif and usle_[Suffix].tif, and the unit of these raster files are all tons/pixel as the description in Interpreting Results. But the unit in the equations is tons/ha. So what is the difference and how is this unit transformed?
If the pixel in my data is 30mĂ—30m, should the unit in output raster files be tons/900m2 as the description in Interpreting Results (tons/pixel)? And if the unit of the raster is tons/ha, how is sed_export in watershed_results_sdr_[Suffix].shp summed as tons/watershed. Same question exsits in NDR model.
@bastian87 Hi, did you find a solution for your problems of high values, i’m experiencing the same problem, the soil loss is very high. i crossed checked everything but still the results come out very high.
Are you seeing high values everywhere, or just in a small number of pixels? It is common for there to be unusually high values in places with very steep slopes. That’s an unfortunate result of basing soil loss on USLE, which was created for places with low slopes, and it does not perform very well on steep slopes. So I often see results where most of the study area has reasonable values, except for steep mountains.
Previously in this thread we talked about checking the units of all of your inputs, and that is important. Also remember that these models need to be calibrated in order to have more confidence in the absolute values. But if you’re seeing uniformly excessive values, then it’s definitely a good idea to look at the values of all of your model inputs. If those seem ok, try looking at the output files in the Workspace’s intermediate folder, perhaps it will give some insight about which step of the calculations is causing the high values.
