Latest Contributions by MarkBoucher

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 @tlopezcantu. 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.

Online Status	Offline
Date Last Visited	2 weeks ago

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.