Hi Dave. We filled the nodata holes with the appropriate raster cell values and re-tried the SDR model. We still have negative values in the sed_exp and other outputs, If you have any further suggestion, it would be appreciated. Thank you.
Hi Gordon, thanks for the update. I assume you mean you still have negative values in the “scenario - baseline” change raster? If so I would compare the two LULCs and confirm that the new crop pixels in the scenario are actually replacing higher retention landcover types. Glancing at the subset of data you shared, I do think there are some “bare ground” and “urban” pixels being converted to crop in the scenario.
Hi Dave: the bare ground and urban pixels converted to crop are only 0.2 % of the total watershed area and they are not spatially distributed across all of the watershed area… as our negative values in the “scenario - baseline” change raster are.
I will work it it some more. Thanks for the suggestion.
Hi @BVIB , the SDR maintainer has graciously weighed in and provided the following feedback after looking at the DEM you shared earlier in this thread.
that dem is a 1m resolution. that’s way too small for what the SDR science is derived from. having 1m resolution doesn’t get you a better result and in many ways could give you a misleading result about what 1m pixels were important. SDR is derived from “landscape” level studies that are at least dozens of meters long. so offhand, just for science and numerical reasons i’d coarsen it to 30m
the other thing is the floating point resolution on that DEM is 15 decimal places. That extra precision abuts a bug in the DEM pit-filling algorithm that will be fixed in an upcoming release.
Essentially, the precision of the DEM is so high that in some areas the model can’t determine which pixel is higher or lower than the next because the elevation values are too close and being mistaken for equal. That bug will be fixed in an upcoming release, but regardless, it sounds like the way forward is to coarsen the DEM to about 30m and maybe convert it to an integer datatype in the process. Then the DEM will behave appropriately in the SDR model.
Thanks Dave ! The info and advice is greatly appreciated. Thanks to you and to your SDR maintainer for taking the time to look at it for us. We will follow your advice. Appreciated.
Following up on suggestions that you and a few other InVEST / ROOT people have made to us, we have now made some additional pretreatment to our data to attempt to eliminate some of difficulties we had with the negative values in our scenario change rasters. These input data pretreatments consisted of (as suggested to us):
All our input data rasters are now all resampled to 30 x 30 resolution to match the ‘’Landscape level’’ functionality of the InVEST models
Assuring that all rasters are now properly aligned at the pixel levels, with the same extents
All rasters are now with the nodata exactly spatially matched between input rasters, or eliminated
The pixel-to-pixel interference of our ‘’Bare Ground’’ and ‘’Urban’’ pixels between our LULC input raster and scenario raster that was causing negative output values in our change scenario (raster to raster subtraction) has been corrected and eliminated (we hope).
Nonetheless, we still have some negative values in our change scenario (raster to raster subtraction) outputs. We believe that this may be p ossibly related to some remaining biophysical table coefficient overlap in our change scenario (raster to raster subtraction).
Questions:
Do you have any suggestions of methods regarding how we could efficiently screen of biophysical table coefficients for overlap in our change scenario (raster to raster subtraction) ?
Do you have any other suggestions of places in our work we may look for other potential problems that might be creating negative values in our scenario change rasters ?
We appreciate your assistance! All the advice we have received so far from several people has proven very useful and has helped to us to improve our input data.
Hi Gordon, sounds like you’ve made some good progress. All that pre-processing sounds very smart and worth doing. FYI that second step of aligning extents and matching pixel sizes is actually something that’s always done by the invest model, usually using the DEM as the one to match all others to. But it never hurts to do it yourself first!
I’m not sure what you mean by:
But in general, if I want to investigate a specific pixel value in the outputs, I load up all the output & intermediate rasters into GIS, zoom into a specific pixel that has a suspect value (e.g. one of those “negative change” pixels) and use the “identify” tool to examine all the values in that location from the intermediate datasets that might be influencing the final value. Maybe that will reveal something.
@JIahengDu,
Are the negative values very small and close to zero? If so it may just be numeric imprecision as discussed above. If you can attach your output file, that would be helpful
Hii
I have the same problem of the negative values in NDR, my negative values are big and I don’t know what to do about it, I ran the model several times and I get the same result… but I’m pretty sure that my inputs are correct.
Can someone help me please, I will really appreciated
Giovana
you may possibly need to adjust the coefficients in your biophysical table. check them out. they may be generating a negative result in the model due to the coefficients overlapping to a negative sum. Also ensure that there are no empty cells in your input rasters. good luck.
Hello @giogarcia.2907 , I agree with @BVIB’s suggestions. In addition, if the negative values are very large (like -3.4028235e+38) this can sometimes be caused by an incorrectly defined nodata value somewhere in your raster stack. Could you check all of your input rasters to NDR and make sure that they all have a nodata value defined and also that the nodata value matches what you would expect for the layer?
Would you be able to share all your model data inputs for us to investigate further? This post instructs on an easy way to capture all your inputs and share them. You can share a link here to the data or email a link to ddenu@stanford.edu if you’d prefer. Thanks!
Again, thanks for sharing your data and sorry for the slow response. I noticed that your eff_n column had values greater than 1. Those values represent the percentage (as a decimal) of how well the landcover can retain nitrogen. Having values greater than 100% could cause the negative values you are seeing and in fact when changing those values in the table I get results that are all positive.
Let us know if anything else comes up in your use of the model, thanks!