Latest Contributions by MarkBoucher

You may be aware that ESRI is moving GeoNet to a new platform. To preserve this thread I've exported it to a Word Document. The option to export to a pdf wasn't working and it looks like some paragraph numbering was lost in the simple copy/paste to Word. Once the new GeoNet is up and running, and if we last this thread, I will post the document somewhere I think it is searchable. Best, Mark - Original Arc Hydro Problem Solvers poster. ... View more

Annina, I don't recall seeing that recently. First: I assume you have filled the sinks under the DEM Manipulation tools.. If not, make sure you do that. Second: The black lines (DrainageLines) appear to cross each other. Some look like they follow flow paths defined by the DEM (irregular in alignments), others look long and sweeping and like they wouldn't follow a path defined by the DEM. These appear to have have more generalized alignments. Make sure your agreestream layer is correct. I try to limit the agreestream polylines in natural area and only put them in where the DEM misses where water flows under roads or bridges. In developed areas, I put in agreestream polylines where there are pipes. Third: Make sure you are setting the datasets correctly in the Terrain Processing>Data Management Terrain Processing menu. Hope this helps. Mark ... View more

Darin, My initial thought is to suggest you check and ensure that the geoprocessing extents includes the extent of your data. In older versions the processing extents would change during a prior process and not change back if one of the prior processes didn't execute successfully. In my case the geoprocessing extents would match the patch points extents and cut off watersheds to the extent limits of the batch points. A remedy was to reset the geoprocessing extents. I have not used the "append coastal catchments" tool. Could be an error in that process that I've not encountered. If you find the processing extents is the issue, you may want to check the processing extents before and after you run append coastal catchments.  I have run into a similar situation as you and gotten watersheds delineated round a small area instead of what I expected. In those cases the point I clicked was not right on the str grid and I'd get a very small watershed delineated as a result. I then would use the flow trace tool and click on the fdr cells all round the point of interested until I was certain I was on a cell that would work. A bit tedious, but it was a work around. Hope something here helps, Mark ... View more

I have not used the "enhanced flow direction grid". But I believe the stream grid (str) and a flow direction grid are all that are needed to create the stream link (strlnk) grid. The str and strlnk look exactly the same except the str would have 1's and 0's but the strlnk grid has 0's (where no stream is indicated by the flow accumulation grid threshold for str) and integers of 1 and greater. That is what's show on page 37 (pdf pg 38). in the document at  http://downloads.esri.com/archydro/archydro/Tutorial/Doc/Arc%20Hydro%20GP%20Tools%202.0%20-%20Tutorial.pdf. It would be interesting to see what your str grid looks like.  Looking at the image you shared, it makes me wonder if your rawdem is right. ... View more

Emma, My first suspicion is that the inputs to the Stream Segmentation tool are not correct. They should be (at a minimum)  the flow direction grid the stream grid. Mark ... View more

Annina, I can't tell from those error messages what might be going on. The "error message" I'm thinking of is the one that appears while processing. An example is that provided in the image by Anne-Marie Dubois in her post on Aug 8, 2019 7:22 AM. If you can screen shot the run time error messages it might reveal something. I did a Google search on "arcpy memory error" a few of the results could help your Python programmer. (I suspect done this type of search already): A result in GeoNet: memory error with python  A result in ERSI support: Error: ERROR 000426: Out Of Memory  A result in stackexchange: arcpy - Python MemoryError when running ArcGIS Python Toolbox tool - Geographic Information Systems Stack Exchange  Hope this helps. I look forward to seeing the solution. I want to get my Python black belt doing Arc Hydro for me soon so your experience will be goo to follow. Best, Mark ... View more

Annina, Thanks for the ego boost. I am experienced through the "beating the head against the wall" ArcHydro methods gauntlet, so I guess that makes me an "expert". I am not a Python pro at all. I have gotten accustom to deciphering the ESRI error messages. If you can send the text or a screen shot of the error message, I'll see if that can point to a potential problem.   Are you processing the project on your local machine or over a network? That can make a difference, in my experience. Best,  Mark ... View more

Jack, You may want to check out the thread ArcHydro Problem Solvers and see if there is an answer there. I'm not familiar with this particular error. The error message seems to point to the grid, though in the geoprocessing, the tool may convert vector data to a grid, so I can't say for sure if it is the grid you input, or a temporary grid. The inputs to the LongestFlowPath tool are a Drainage Area (polygon) and Flow Direction Grid (grid). Check your inputs to make sure they are correct. Check your inputs to make sure they are in the right projection. Check you processing extents to make sure they cover the processing area. Best, Mark ... View more

What Jacom Helfan said is a good approach. One issue is the different extents of each of the rasters. The suggestion of mine below might be the long way around, but should work. You should make all the rasters for each watershed with the same cell size and grid basis (starting x, y). For each raster, run Con and IsNull to make all the Null cells 0. Create a polygon that encompasses all of the rasters. Create a raster from that one polygon based on the grid size and grid basis of the other rasters and making the value zero. Do raster math and add them all up with the new big raster with zero value as the starting point. This will make sure the extent is right. A key is getting any Null values to 0 because I think in raster math if one of the values is null, the answer will be null. If there is any overlap of the rasters you could get large numbers. There should be an option to use the value of the last raster as the final answer, but that might be mosic (and the problem you  are having. Again, I have not tested this and it is "the long way around" but it seems that it would work. HTH, Mark ... View more

Welcome to the forum. There are several reasons this error comes up. ESRI provides this page. http://resources.esri.com/help/9.3/arcgisengine/dotnet/a3bd05c8-64a6-4dd4-acb3-0d10b021f2f8.htm#ErrorCodes I wrote this about it in 2014. I assume it is still valid. https://community.esri.com/thread/114219 The same question is also posted here with some replies including my own. https://community.esri.com/message/804958-re-error-hresult-efail-has-been-returned-from-a-call-to-a-com-component?commentID=804958 Hope this helps, Mark ... View more

I haven't used that tool. Running the project on the local C: drive does speed processing up quite a bit. If you aren't doing that, you may want to try it. Best, Mark ... View more

I have no code or book. You have to have the velocity in the river based on slope. Without a detail hydraulic model, you can only estimate. If you have varied "roughness" (smoother vs rougher), that can influence velocity. You should be able to Google "estimate river velocity" and find something. Length(ft) = Velocity (ft/sec) X Time (sec). If you have a dem you can created a slope raster. Somehow use that to come up with how far the flow would go in 24 hours. You must have a long river. ... View more

Please, someone correct me if I'm wrong ... ... I believe Batch Point delineation should work no matter what size the stream threshold is. I believe the more Adjoint Catchments you have, the faster the batch processing will go. This is because the batch delineation processes only have to delineate the areas upstream of the Batch Points to the upstream edge of the catchment polygon they are in. The the rest of the delineation happens very quickly by simply selecting the next upstream adjointcatchment. So Adjoint Catchment process is like prepossessing the delineation to make the batch processing faster. It is also used in other tools, so you need to do it for those.  So if you have a huge watershed and a large stream threshold (resulting in fewer adjointcatchment polygons), the batch delineation processes should take longer than if you have a smaller stream threshold (resulting in more adjointcatchment polygons). Until this issue gets addressed, increase your stream threshold (reduce the number of adjointcatchment polygons) until it eventually works. I recall a story that when this was first demonstrated live at a conference, many of the attendees thought it was a joke, a trick, or not real. They couldn't believe it. They were used to delineation taking forever. Using the network analysis capabilities (necessitating HydroID, UpstreamID, NextDownID, etc), Arc Hydro is able to do these tasks relatively quickly. Mark ... View more

The "usual suspects" are also discussed here: https://community.esri.com/message/45017#45017  ... View more

Clipped, linear borders can be a sign that the processing extent was constrained to some domain (sometimes that of the BatchPoints dataset).  Mark ... View more