I am applying the SDR model in watersheds located in southeastern Brazil, specifically in the Serra da Mantiqueira region. These watersheds are mountainous, with predominantly native vegetation cover and relatively high slopes.
For the analysis, I used the ALOS PALSAR DEM (12.5 m resolution), based on recommendations that it performs better in steep and vegetated areas. The DEM was preprocessed (sink filling), and the watershed delineation was derived from this dataset.
However, when running the SDR model, I noticed that the outputs related to SDR (sed_export, sed_deposition, and avoided_export) present null or empty values in the southern portion of the watershed, which corresponds to a lower elevation area.
Looking into intermediate outputs:
The stream.tif layer appears consistent and correctly represents the drainage network.
However, the what_drains_to_stream.tif output shows values of 0 in this same region, indicating that these pixels are not contributing flow to any stream.
Given that this is a downslope area, I would expect it to contribute to the drainage network.
Has anyone encountered a similar issue or could suggest possible causes for this behavior? Could this be related to DEM preprocessing, flow direction (D8 vs MFD), or stream definition thresholds?
Hi @isabelammartins , I’m not sure how to explain this issue, but it could help to see the results you are looking at. If you are running at least version 3.18.0, then a good way to share images of your results is by sharing the model report: Sharing InVEST Reports
I’m using version 3.16.0, with TFA = 200 (after comparing with the hydrography), and the other parameters are set to default values. The watershed was delineated using the same DEM that is being used as input, but in a different software.
Some intermediate outputs caught my attention:
what_drains_to_stream.tif: shows a value of 0 in this region;
Thanks for the images @isabelammartins . Looking at the basemap that shows the underlying topography, is it possible that those grey pixels actually do drain to the south rather than to the north? I think in order to get reasonable results from this model your input DEM needs to entirely cover the watershed that you wish to evaluate. From this image it’s hard to tell, but it looks like this may not be the case.
It is also possible that one of your other input layers has nodata over part of the watershed because all raster inputs are mutually masked so that the model only computes in the region where all pixels in all input rasters are non-nodata.
As always, it’s also a good idea to upgrade to the latest version. The report really can help identify these data issues more quickly.
I am using a DEM with a 1 km buffer around the watershed boundary. Is this buffer sufficient?
In the image, we can see that the clipped area starts at a hilltop.
All other input layers are valid. I ran the same analysis using the NASADEM (30 m), and the results were complete, with no gaps like those observed with the ALOS PALSAR DEM.
In this situation, would it be appropriate to further decrease the TFA, or should I keep the TFA that best matches the observed stream network despite the gaps observed in the other results?
Another question: does the observed gap indicate that the watershed is hydrologically inconsistent?
I ran the model with TFA = 200, but using the MFD algorithm. In this case, all pixels drained to a stream, and no gaps were observed.
Correct. D8 flow direction conventions encode the flow direction as::
3 2 1
4 x 0
5 6 7
Based on your flow direction maps it does look like some pixels flow out of bounds before meeting a stream. That’s also what the what_drains_to_stream layer tells us. To me that indicates that the DEM does not cover the entirety of the watershed.
I think you probably want to choose the TFA value based on what generates the most realistic streams.
Considering the D8 flow direction image, wouldn’t it be correct that pixels with a flow direction value of 7 should flow toward the interior of the watershed?
I am using a DEM with a 1 km buffer around the watershed. Should I consider using a larger buffer?
If I use the TFA, which generates more realistic streams, the gap (nodata area) still remains within the study area. Could this be considered a problem?
Hi @isabelammartins , thanks for sharing your data. Looking closely at the southern tip of that watershed boundary, I think the issue is simply that some of those pixels drain into a different watershed. They drain directly into the larger stream rather than into the upstream tributary.
So, according to the flow direction map, pixels with value 7 drain into the interior of the watershed but not into a mapped stream, is that correct? Would this explain why, as TFA increases, the gap area decreases?
Does this indicate that the watershed is not hydrologically consistent, or could it be a limitation of the input data I am using?
Also, would it be acceptable to present the results with this gap?
Another point is that when I use the MFD algorithm, the results do not show this gap. Is there any recommendation regarding the choice of flow direction algorithm?
I think this indicates a discrepancy between the watershed polygon boundary and the watershed represented by the DEM. If you want to, you could try using InVEST DelineateIt to generate a watershed polygon using your DEM. In order to get a good result you probably need to create a “pour point” near the bottom of your tributary of interest, but far enough away from the larger stream that your watershed pours into. This might take a few tries to get the placement of the pour point correct with respect to your DEM.
I think that D8 and MFD should produce similar results for delineating watersheds using the same DEM, and using a threshold flow accumulation value that creates similar tributaries between the two methods (which might be the same TFA value for both MFD and D8). Their big difference in output is that D8 streams are consistently 1-2 pixels wide, while MFD tends to create wide streams in floodplains.
D8 is much more commonly used in the hydrology world, and it’s what i tend to use, as it produces the narrow stream network that we’re most used to seeing. Also, for models like SDR, where some outputs are NoData in the stream pixels, often you lose a lot of riparian area with MFD, since it makes wide streams.
