Gaps in GageWatershed outputs

[caiostringari]

Hi,

Thanks for providing this tool.

I am trying to run GageWatershed using a predefined stream network (as the outletfile) but it seems to generate gaps in the resulting file. For ex:

The D8 results are continuous across the DEM. This seems to happen in only a few areas of the DEM.

Any ideas what the causes for this would be?

[dtarb]

I am not sure what I am looking at in the picture, and need a bit more information to help. The program is supposed to label each grid cell in the outputs with the identifier (from column id) of the gage to which it drains directly without passing through any other gages. If there are areas that do not drain to any gage they would appear as gaps. To figure out what is going on it would be helpful to know more about the inputs and what is being shown. A type mismatch on the column ID that ends up writing no data to the output comes to mind as a possibility. Improper flow directions - perhaps related to unfilled pits are also an option, though you said the D8 results were continuous.

[caiostringari]

Thank you very much for the fast reply.

I should've been a bit clearer. The colored points are points representing the stream network extracted at 30m resolution. Each color represents an unique ID. I passing these points as input to gagewatershed command line interface with the -o flag.

The colored raster is the result from gagewatershed. Because of the number of unique "catchments" (not sure if that's the correct term here) it is a bit hard to apply a nice colormap to the raster.

As I mentioned, the D8 results look correct and so do the slope results.

I am wondering if the point data I am passing to gagewatershed are not really what I should be using.

Thanks again for your help, it's much appreciated

[dtarb]

I have two theories. The first is that the unique identifiers for certain points are overflowing the integer variable into which they are written and then leave no data in the result. This could be related to type mismatch. But I do not have much confidence in this because each gage watershed should be attached to a gage and the no data streaks do not always connect to a point. However there may be a loss of resolution in the image and a much closer look may show a but more.

The other theory is that there is numerical rounding in the positioning of the gages that somehow leaves out certain grid cells. I am also not very confident in this.

If you zoom in very close around where these no data areas seem to be starting (their downstream ends as the algorithm propagates upslope) you may learn something. Alternatively, if you want to send me a small art of the data, I could investigate a bit myself.

[caiostringari]

I spent the day looking at the it and could not figure anything out. I put the data here: https://drive.google.com/file/d/1fexJwE5flGWLwQdLIKbweimFps22q9bI/view?usp=sharing

Files are:

• stream_points.shp : input for the -o flag
• D8_Tau.tif: flow directions for the -p flag
• stream_px_ws.tif: current results
• elev_res_flat.tif : pit-filled and flat resolved DEM (for reference)

Thank you very much for your help!

[dtarb]

I checked the data you sent and found that this is due to real pits, and hence internal drainage in the DEM. See https://drive.google.com/drive/folders/1dT-TSdrKU4sYNgcieglqSUO7lwsTQNYW?usp=sharing

[caiostringari]

Thank you so very much for all this insight, it is much appreciated!

I will close the issue now as this is not a TauDEM issue.

Just for a bit extra context, I was following the workflow from here: https://code.usgs.gov/gft/python-gis-flood-tool. I may open a issue there with the information that their workflow may not be fully compatible with TauDEM.