The result of sed_deposition run based on sample data of SDR looks very strange. What could be the reason? Or have I done something wrong?
Thank you very much for the help in advance!
I think the sed_deposition is not ready to represent the result of soil conservation service. Since sed_retention is not recommended for using, is it reasonable to use usle.tif minus rkls.tif to represent the soil conservation service?
Besides, in comparison to sed_retention, usle, rkls, we can hardly tell anything from the result of sed_deposition. So how can we use sed_deposition to represent the ES?
I seem to have solved this problem.
But I still have a question, which is, why the result of sed_deposition could include data < 0. When I check the equation 69 for the SDR, I think SDR will always be < 1, so that sed_deposition could have no chance to be < 0. So what could the reason be?
Very small negative values, like 2.22e-06 in your first screenshot, are usually just small errors in how QGIS is showing the floating point number. The value is actually zero. If you run the “Raster layer statistics” tool in QGIS or examine the data using GDAL, the minimum should be 0 exactly.
Thank you very much for your reply! I should have mentioned that I use ArcGIS for analyzing. But I understand what you mean. I also met this problem by using my own data. So, I could just reasign the raters with < 0 a new value, which is 0, am I right?
If the negative values you’re seeing are really small and close to 0, then it’s most likely just numerical noise and can be set to 0. But if you’re seeing significant values that are less than 0 when you would not expect them, then there might be something else going on. Let us know either way!
Thank you James for your reply!
I have checked the results of sed_deposition using my data. The negative values are less than 0.0001, which means they should be some noise that could be just ignored.
But I still think there should be no such values that appear, I am thus wondering whether something happens with the model (like bugs or other tiny things). It would be expected and appreciated that the model be checked out and modified.
Yep, these are most likely numerical noise that is the result of accumulated error from operations on floating-point numbers. These values are functionally equal to 0 and should be treated as such.
I understand where you’re coming from and we’ll take a look to see if it’s reasonable to put a lower bound on those numerical values. I assure you, these values are nothing to be concerned about and the model is functioning as expected, but we’ll still take a look.
Thank you for your reply!
I didn’t mean that the model does not function well. On the contrary, I am very grateful that the InVEST models have been developed and open to use. What I’d like to say is that I am very glad to see that these models would be better and I am happy to make a few contributions to their improvements.
Not to worry! We always want to make sure that InVEST is working as expected and for sure we want to fix any issues as we find out about them. In this case it sounds like the issue is just some numerical noise, but we’re also working on a fix to clamp these small negative values to 0 anyways.