Latest Contributions by MarkBoucher

‎01-10-2022

Welcome to Arc Hydro. I created a discussion titled "Arc Hydro Problem Solvers" (https://community.esri.com/t5/water-resources-questions/archydro-problem-solvers/td-p/499200) that could be of help. It is has tips for reducing errors. One is to put your .mxd on your local drive if you are working on a network. This speeds up the processing as well and eliminates many error that may have to do with read/write across the network. There are other settings that help. Others have also contributed. There are some sub-threads that address certain issues. I am not working in ArcGIS Pro yet, so I can't speak to any changes related to using Pro. Best, Mark

‎12-05-2021

ArcHydro is a free add-on that uses Spatial Analyst License to do these things. I have not used it in Pro. You can do these things just using Spatial Analyst w/o ArcHydro.

‎11-22-2021

As for units of the burn, I have always experienced that the units are feet or meters, whatever your project is in. It is not a function of the raster grid size. You can always do a trial and error on that one. I agree with KyleGonterwitz that the depth of the burn doesn't mean anything... that is, if what you are trying to do is come up with a flow direction grid. The bottoms of the burned channels will have elevations relative to the original DEM. If you run the fill function, the sinks w/in the stream bottoms will be filled to make the flow direction correct. If you are trying to lower the known channels that don't show well in the DEM by just a small amount to get a good elevation grid, you can burn the streams to some deep depth and process the DEM one more time using a CON() function where if the elevation is below below 0.00 (negative), then make the elevation 0 (or whatever elevation you need). The burned channel bottoms will all be at the same elevation. You may need to check the flow direction to make sure after you create the flow direction grid that the flows are going in the right direction. There is a tool to correct the flow direction using polylines drawn in the direction of the flow you need.

‎08-30-2021

I’ve found that zonal statistics can have problems if the polygons overlap. Check the topology.

‎08-19-2021

I do this using Spatial Analyst, so it takes that license. You don't have to clip or buffer the rasters unless there is some other reason to do so. I like to use model builder. You could build one like this and then copy and paste it and replace the value raster with the successive rasters and change the field in the calculation to polygon field. I'm sure there is a way to do this with an iterator (iterate through the polygons or something like that) and or in python, but the general idea would be the same: do zonal statistics to a table, the join that table with the polygon layer and use the calculate tool to transfer the statistics you want from the table to the polygon layer and then remove the join. I believe that if there is more than one polygon in the polygon layer this will work unless they overlap. I think that If they overlap you will need to iterate through the features.

‎08-18-2021

Tania, I tried that, but the Con function wouldn't create an unsigned 8-bit integer raster. The signed 8-bit raster can't have 128 and so it for some reason defaults to -128. When I started over this second time I didn't change the folder, I simply deleted the fil and fdr rasters as well as the project's .gdb. This seemed to fix the fdr issue without having to "really" start over. Thanks, Mark

‎08-18-2021

I ran into the same problem again. The process is iterative for me, so I go back and restart. This time I deleted the data in the project .gdb (see below) and the problem went away. For some reason the fdr grid is recreated as a signed integer grid even if I delete it and other previous grid (fil) and recreate it. The 128 direction shows as -128 in the fdr. This time the fac grid was fine, but when I went to delineate subwatersheds, they results were a few patches localized to the batch point and did not go upstream very far.

‎08-18-2021

Thanks for the reminder. I always recommend that too being the starter of the ArcHydro Problem Solvers thread. I have disabled it in the past, but for some reason it was enabled. So many buttons and options. Wouldn't it be nice to be able to make "profiles" where one could change settings all at once for different project circumstances.

‎08-18-2021

Thanks for the response @curtvprice and @TaniaLopezCantu. Things seem to be working except that ArcMap crashes often while doing the geoprocessing. Seems random and is frustrating. It is hard to comprehend why the raster type would change simply due to changing a file name. One thing I have not tried is to delete the tables under the .gdb named after the .mxd (I name mine ArcHydro.mxd since I'm trying to create a process that I'll use in many watersheds in my county). I've always thought of these a "counters" that keep track of the hydroID and the drainID type of numbers. Does it help to delete this .gdb if "starting over"?

‎08-17-2021

In a "last ditch" effort, I renamed my folder by adding "error" and started over. I moved any project based tool boxes to a new folder and started over. The process ran much faster and I didn't have the "errors" I was having in the post above. If the errors come back I'll reply again. May be a little premature, but for some mysterious reason starting from scratch fixed the issue.

‎08-17-2021

Arc Hydro v10.8.0.34, ArcGIS Desktop v10.8.1 (both 32 bit) My flow accumulation grid (fac) is not being created correctly. For some reason, the flow direction grid (fdr) has the north east direction as -128 instead of +128 as I assume it should be. The first image shows the fdr grid and some flow path tracing lines. These are correct event thought the value of the fdr grid is -128. This may not be an issue, but all the examples have 128 instead of -128. I have deleted and repeated the creation of the fdr grid using SA and Arc Hydro tools. In the second image, I show the fdr with the 128 valued cells in yellow to highlight them. They are 128 in the table of contents, but using the i tool they show as -128. In the third image, I show the flow accumulation grid (fac) turned on over the fdr grid. You see the yellow cells “showing through” b/c the fac grid shows NoData. When this happens the flow accumulation starts over. It should continue and the cells should get darker along the flow direction (having higher and higher accumulation). The forth image is a portion of the third image showing the identify tool results on the right and the yellow cell that was selected circled with a blue line as well as the results circled on the right. My expectation was that the fdr value would be a positive 128, and the fac would be ever increasing. The resulting fdr grid is a "signed integer" which means it can have +/- values. A search confirms that in an 8 bit system 8-BIT UNSIGNED: 0 to 256 8-BIT SIGNED: -128 to 127. So, in an 8 bit signed integer raster, there can be no +128 which would make the "D8" flow direction type, it would make sense to use -128 for a signed integer grid (and the flow path tracing tool works with it). In an older "successful" hydrology effort the fdr grid was an unsigned grid. It is not being created as a signed grid. Can anyone shed light on why this is happening? Thanks, Mark First Image - fdr grid and some flow path tracing lines. Second Image - fdr with the 128 valued cells in yellow to highlight them. Third Image - fac turned on over the fdr grid. Yellow 128 direction grids from fdr show through where fac is NoData. Fourth Image - portion of third image showing results of the identify tool click on circled grid cell.

‎08-17-2021

The flow direction is based on a filled DEM. If the filled DEM fills incorrectly, you can get flows going the wrong way. You can also train the flow direction if the results are mostly right, but the direction in the burned streams is incorrect. Maybe you need an outer boundary on the right side.

‎07-28-2021

@FauzanAldi - This is a very common error. I think it means that the process can't find the data it is looking for. This is because: the data connection is broken - possibly the latent time between the server and your PC is too long and something times out - this is my guess as to why it works with fewer errors on your local PC compare to over the network to a server - faster on a local drive anyway, a data or filename is too long for one of the processes - some older ArcHydro routines have legacy file/path/layer name length restrictions - a reason to use the local drive an a simple directory name- raster names have restrictions, you missed a process in the sequence - check that you are not missing a key step you or some process deleted some intermediate data - in retrying processes this can happen - I sometimes delete all the intermediate data and start again with a clean slate. the processing extent has been changed for some reason and the data you want to use exists but is not in the processing extent. I have struggled to understand the root cause of this error in the ArcHydro process, and the above are some "theories" I try to work with in debugging the error. I've actually made a Model Builder model of a key process using logic and Spatial Analyst tools (a workaround). I've had success with this, but it is time consuming to do this "programing" and using it on the next project requires a lot of checking to make sure file paths are correct or I'll overwrite data in the last project. Learning python better would help in this, I'm sure. I have not had the chance to use ArcHydro for many months, so I won't offer to take your data and work with it. Possibly someone else has time to do that. I hope this helps. Best, Mark

‎09-24-2020

Arc Hydro will not calculate flow rates in cubic feet per second (cfs). Arc Hydro is used to help the parameters that go in to equations or models that are used to calculate the flow rate. The tools in Arc Hydro are made to help automate the determination of the the parameters that come from watershed delineation process such as area parameter, flow path length and slope, watershed centroid, using the watershe polygons to convert raster based land values of impervious surface or infiltration rates to averages for the watersheds; thing like that. Hope this helps, Mark

‎09-15-2020

Good instructions. Has the migration happened yet? Looks the same so far. Thanks, Mark

Online Status	Offline
Date Last Visited	‎03-10-2026 11:29 AM

My Ideas

Latest Contributions by MarkBoucher

Re: ArcHydro Continuously Drawing Errors

Re: Working with Hydrologically Conditioned DEM

Re: DEM Reconditioning: Burning culverts into a DEM -- Z units?

Re: ZonalStatisticsAsTable misses 245 zones out of 3108! - ArcPy , ArcGIS Pro 2.8.2.

Re: Land cover classification on multiple rasters

Re: Flow Direction and Flow Accumulation seem erroneous.

Re: Flow Direction and Flow Accumulation seem erroneous.

Re: Flow Direction and Flow Accumulation seem erroneous.

Re: Flow Direction and Flow Accumulation seem erroneous.

Re: Flow Direction and Flow Accumulation seem erroneous.

Flow Direction and Flow Accumulation seem erroneous.

Re: Flow Direction raster showing flow in opposite direction than it should be flowing

Re: Error HRESULT E_FAIL has been returned from a cell to a COM component in HEC GEO HMS

Re: Calculate flow using ArcHydro

Re: A New GeoNet is Coming: How to Prepare Your Content & What to Expect

Re: Error HRESULT E_FAIL has been returned from a ...

Re: DEM Reconditioning does not change DEM

Re: Editing features do not show change until exit...

Re: Why can't I define a stream network?

Re: Hidden/Stacked polylines