ArcHydro AgreeDEM is empty or has pixels with no data.
When delineating the watershed for the Upper Mississippi River Basin, I encountered a strange issue. To be more specific, this was after using the DEM Reconditioning tool (used for obtaining an AgreeDEM by burning a known stream network available over the study area) from ArcHydro toolbox in ArcGIS. The DEM reconditioning tool ran without any errors. However, when inspecting the output (see attached figure) more than half of the AgreeDEM had pixels with No_Data value. Interestingly, the pixels representing the stream were present in the No_Data zone.
I used ArcMap 10.2.2 on a Windows 64 bit machine. The dataframe had a UTM-15N projected coordinate system and the target locations for both vector and raster outputs were properly assigned using ApUtilities -> Set Target Locations. The processing extent was set to default (Geoprocessing -> Environments -> Processing Extent). Upon posting a query on Geonet, Mark Boucher provided some insightful comments on the probable cause for the error.
I was previously successful in getting the AgreeDEM for the same area, on the same machine and ArcMap version. I was repeating the process again as I had access to a more reliable and higher resolution stream network for the study region compared to my previous attempt.
- Use Windows 7 utility Disk Cleanup to empty the Temp folder.
- Open a new ArcMap document and add the DEM raster and the stream network shapefile.
- Ensure that both these files (from step 2) have the same projection. In my case it was UTM 15N.
- Create a folder for the project e.g. C:\MyProject
- Save the ArcMap document as C:\MyProject\MyProject.mxd. This step generally sets the target locations correctly.
- Double-check the target locations before running any ArcHydro functions using ArcHydro toolbar -> ApUtilities -> Set Target Locations -> HydroConfig. When you double click the HydroConfig
- Raster Data should be pointing to C:\MyProject\
- Vector Data should be pointing to C:\MyProject\MyProject.gdb
- Map Name = Layers (Layers is the default name of the dataframe in the ArcMap document)
- Check the processing extent using Geoprocessing -> Environments -> Processing Extent
- I set the extent as Union of Inputs
- Clear Temp folder again using ArcHydro toolbar -> ApUtilities -> Addition Utilities -> Clean User’s Temp Folder
- Run DEM Reconditioning to obtain AgreeDEM.
Discussion:
For the sake of any future GIS enthusiasts who encounter a similar error, I thought I will complete the discussion:
In my opinion, the original issue was not likely due to incorrect processing extents because the AgreeDEM (see attached figure) did burn the stream network for the entire study area (burnt streams represented as black pixels spread over the study area- figure is at maximum zoom-out level). However, the entire left half (you can observe a vertical demarcation in theAgreeDEM – showing white region with black pixels on the LHS and a shaded region on the RHS of the AgreeDEM) of the study area (except the pixels burnt as stream) had pixels with value=No_Data. In the Geonet forum Mark rightly recommended me to check this again, as the legend for AgreeDEM was showing white areas to be of high elevations (272-592). Though not shown in the legend, I have confirmed that most of the left half of the AgreeDEM had No_Data.
The values in the AgreeDEM appear to be strange at first look because by default the Symbology (or legend) for AgreeDEM was set to be Classified with inverted color coding compared to the input DEM. Further the AgreeDEM was run with the following parameters: Smooth drop in Z units = 100, and Sharp drop in Z units = 1000 to exaggerate the burning of pixels representing the stream. Same parameters were eventually used in the solution.
I am not able to pinpoint the exact cause for this error, except to agree that one needs to be careful while setting up the project and follow the best practices recommended by experts like Mark. Finally, if everything fails remember not to give up. Seek help. Start fresh.
This post was originally published on athinkingbubble.blogspot.com