Watershed tool producing a tiny catchment

[ClaireParsons]

I am having real problems with the watershed tool producing a catchment of only a few pixels when i know that the flow direction is downhill (4) from the pour point I am using - Any Ideas?

[EricRice]

Greetings,

Check your extents as this is the most common cause.  Try setting the processing extent to that of the original DEM.

Regards,
Eric

[ClaireParsons]

Hi

I've sorted this now - I ran my shapefile through the snap pour points tool and it now produces large watersheds!!

Claire  😄

[CarinaSchuh]

Hi,

I am having the same problem right now. Some of my watersheds appear as single pixels only. The extension solution does not work. Anyone has another idea?

Thanks!

[ChrisSnyder]

I have learned to always convert the watershed "pour points" (or "pour areas") to a raster. BTW: Make sure you use the flowaccum grid as the snapraster. I noticed when running the watershed tool in a loop via Python that sometimes (even when the point seemed to be right on the center of the pixel), the tool occasionally failed to give the correct watershed delineation - as if the point was somehow interpreted to be in a neighboring pixel even though it wasn't... Anyway adding an extra step to convert the point to a raster solved the issue completely.

[EricRice]

Chris,

The output of Snap Pour Point is a raster.  You input your point features, specify a radius, and it will move the 'feature' to the highest value cell of the flow accumulation grid within the radius.  It's similar to what your doing but easier. It also virtually guarantee's you won't hit that occasional issue you mention.

Watersheds that are single pixels or just a few is basically 99.9% an extent setting issue.  If someone is using pour points, the way to verify the extent is the problem is to take the resulting (wrong) watershed raster and display the nodata pixels as some color.  You'll find the extent of the watershed raster is limited by the geographic extent of the pour points and is not equal in extent to the DEM, flow direction, or flow accumulation rasters.  This issue can be avoided by running the Snap Pour Point tool and specifying output extent = Flow Dir, Accumulation, or DEM.  Snap Raster should always be set.

Regards,
Eric

[EricRice]

Manahoana,

If the extents are all correct, have you verified that your pour points are actually on the flow accumulation raster (where there is high flow)? If not, please use the Snap Pour Point tool.  Lacking this snapping procedure can also, but less common than extent settings, lead to small watersheds.

Here are other threads on the topic.

http://forums.arcgis.com/threads/24716-Watershed-tool-problem?highlight=watershed+extent

http://forums.arcgis.com/threads/20305-Watershed-polygons-cut-off?highlight=watershed+extent

Eric

[ChrisSnyder]

Chris,

The output of Snap Pour Point is a raster.  You input your point features, specify a radius, and it will move the 'feature' to the highest value cell of the flow accumulation grid within the radius.  It's similar to what your doing but easier. It also virtually guarantee's you won't hit that occasional issue you mention.

Watersheds that are single pixels or just a few is basically 99.9% an extent setting issue.  If someone is using pour points, the way to verify the extent is the problem is to take the resulting (wrong) watershed raster and display the nodata pixels as some color.  You'll find the extent of the watershed raster is limited by the geographic extent of the pour points and is not equal in extent to the DEM, flow direction, or flow accumulation rasters.  This issue can be avoided by running the Snap Pour Point tool and specifying output extent = Flow Dir, Accumulation, or DEM.  Snap Raster should always be set.

Regards,
Eric

Not arguing that SnapPourPoint isn't effective at eliminating the problem I mentioned, but that particular tool is problematic when you don't want your input pour point to move at all (when using SnapPourPoint they generally move downstream up to the distance specified in the radius distance parameter, which in my case is not desirable at all). In my experience, I can have ~1000 points (derived from in-field GPS surveys) that are manually moved so that they are dead center on a flow accumulation raster (flowacc > 100 pixels or something). I know, because I snapped the points myself to a point version of my "stream" raster. For whatever reason, a small percentage of the points fail to yield the correct watershed even though they are spot on the flowacc > 100 raster. It is as if the points are somehow interpreted to be in one of the neighboring eight pixels even though they aren't. My work around is to convert each point to its own separate grid (ensuring the flowacc raster is set as the snapraster), and then run the Watershed tool using the grid version of the point as input. When I add the extra point-to-raster conversion step, all ~1000 points yield the correct results.

[CarinaSchuh]

Hi all,
first of all thanks a lot for your help!
Unfortunately I couldn`t solve my problem yet. I have been trying several ways:

1) I made sure that my pour points have been set (manually) on the flowacc layer and all extents and projections are well chosen, then I entered the pour points and the flowdirection files into the watershed tool. --> Result: tiny watersheds

2) I created a few pour points manually and then applied the snap pour points tool on them. --> Result: the snapped pour points appear displaced (each around 8x2 pixels into the same direction) from the old points I set manually. (I am attaching a screenshot).

3) The same thing happens when I convert points to raster. The newly created raster cell always remains displaced from the original point.

I am working with the Magna_Colombia_Bogota projection only and have made sure that it has been set correctly in the Environment options.

Do you see any possible error?

Cheers,
Carina

[ChrisSnyder]

Hmmm... are ALL your input datasets in the same projection and cell allignment?