Methodology for creating accurate drainage networks (and catchments) from high resolution LiDAR DEM?

Question

This is not the first time I've stumbled over this issue; it seems that I am unable to generate a correct drainage network model and the resulting catchments from full resolution (1m cells) LiDAR data.

When I generalize the LiDAR dataset, convert it to an integer DEM and fill sinks, all is good and I can easily create what appears to be a very generalized model. However, I would like to produce a detailed site model for a large scale map and this is where I am having problems.

I should point out that most issues occur in flatter areas.

I would like the drainage network to accurately follow the terrain but when I use create the drainage network from an integer DEM input the resulting streams are very general and often "disconnected" in areas where it should not be. The streams are do not even closely follow the natural ridges in the terrain. There are also a lot of "orphan" or "go nowhere" segments. When I use a floating point DEM input, the resulting drainage network is detailed and accurate but very disconnected, clustered and "littered" with orphan streams.

I suspect my problem lies somewhere in the data preparation; integer vs floating point raster DEM input, filling sinks correctly, etc. Or could it be that I have to process the surface data somehow to first create a "hydrologically correct" input DEM?

Can someone describe the correct methodology for creating continuous drainage networks and catchments using high resolution LiDAR?

As it stands I have more success with creating the model from an integer DEM input. This however is not ideal for detailed large scale analysis:

The first attached image is a model produced from an integer DEM input. Several obvious problem areas are circled. Please note that there is actually a stream in what appears to be the main drainage channel. I added a very generalized version of the stream.

EDIT: As I already mentioned I have more success with creating the model from an integer DEM input. The following screen captures illustrate why that is. Even though the integer DEM input has many problems as can be seen above it still produces a drainage network that is less disconnected albeit not conforming to the terrain characteristics. As you can see on the image directly below using a floating point DEM input produces a very disconnected and clustered network full of small orphan segments.

Flow Accumulation raster produced from a floating point DEM

Flow Accumulation raster produced from an integer DEM

As far as i can deduct, both methods yield dramatically different results, both methods are unusable for a detailed model.

EDIT: I apologize for making this post longer and longer (perhaps I am not expressing myself clearly in English) To further illustrate the problem with using a floating point DEM for input I am attaching the resulting Stream Link output as well as the resulting watersheds. What I am expecting is a continuous Stream Network and a the entire area covered in basins that all flow into each other.

Stream Link produced from a floating point input DEM:

Watershed basins produced from a floating point input DEM:

Here is an example (nearby area, same data) of where the entire flow direction of a basin is changed due to the use of integer DEM input: Red arrow is the flow direction of the model and blue arrow indicates the direction of the actual flow. (blue lines - actual streams, red network is the LiDAR derived stream network Strahler order)

Link to data: https://www.yousendit.com/download/MEtSOGNVNXZvQnRFQlE9PQ (Will expire May 13, 2011)

Answer 1

Have you consider to use GRASS GIS analysis? I have expirience that GRASS algorithms have very good accurance on hydrology analysis. For example, I want to generate something like drainage network on DTM with resolution 5x5m. I had compared tools from ArcMap (including ArcHydro Tools) and you can view the result on first picture (red lines). Then I tried to use GRASS GIS function 'r.stream.extract' and I had got result shown on picture 2 (red lines). Both drainage lines are generated with cathement area 3 hectares.

It is really different, and it has pretty accurance in comparsion with real streams (picture 3, real streams are blue). And GRASS GIS has many hydrological tools, i.e. for generate catchement area too.

Answer 2

With regard to generating hydrologicaly correct elevation models, also called drainage enforced, ANUDEM, remains best of breed to my knowledge. It's the program used to generate the Canadian national elevation dataset (CDED, ironically stored as integer-metres). Also the TopoToRaster tool in ArcGIS uses Anudem under the hood (a revision or three behind current).

The USGS used a different program for the United States model, Delta3D by AverStar, but when I enquired (ten years ago) it was a custom program and not available off the shelf (though for a few 100k they'd adapt it for our needs).

I'm not aware of any other tools for generating drainage enforced elevation models, but I'd love to hear about them.

Answer 3

Back in college I worked on a project that did this quite well. I am not a hydrologist, nor did I finish the project (graduated), but you might want to check this out:

TauDEM 5.0

From what I recall, it worked fairly well. Its a free tool and may be just what you need.

Edit: After reading your question more carefully, I believe this is exactly the tool you need. It has no disconnects as you describe, all the flow continues downstream, i.e. no orphaned streams. Most DEM's calculate flow direction with only 8 possible directions, N,E,S,W and NE,SE,SW,NW. This leads to an unnatural flow. TauDEM has a weighted direction, it can flow in 360 degrees. It will have a more natural flow and I assume a more accurate one.

Also, if you have multiple cores, it will utilize them. Using a high resolution LiDAR, TauDEM should process what you need fairly quickly.

Answer 4

Thank you all for you contributions. I have concluded that full resolution LiDAR surface is unsuitable for this type of analysis.

Answer 5

Specifically to the question about using integer or floating point: Integer is best for speed, storage and avoids some kinds of drift due to rounding errors. However when using integer don't use meters for your Z (elevation) values! Change the vertical units to centimeters or millimeters, or keep them as meters and scale the values (multiply by 100 or 1000) which has the same effect. If that is not doable use floating point.

Slope & aspect analysis and other 2nd & 3rd order derivitives are particularily sensitive to the crudeness of metres-based integer elevations. It really is bad practice, however it's also standard practice.

See Terrain analysis: principles and applications (John Peter Wilson & John C. Gallant) in particular section 2.7.2 Elevation Units and Vertical Precision, and The Geomorphological Characterisation of Digital Elevation Models (Jo Wood), search for "integer rounding". Both of those documents are weighty. I first became aware of the problem through a concise and understandable description of the problem in a document about building the first continental elevation model for Australia (circa 2000), using the ANUDEM software, but I can't locate it right now.

Answer 6

Don't know if this will help but I wrote a blog post awhile back on hydro network for 1cm LIDAR DEM. Might have some nuggets for you.

http://www.thadwester.com/1/post/2011/03/hydrologic-networks.html

Answer 7

Just thought I would add something more to think about here. I am now questioning whether the watershed basin delineation process even works. I have a model that I have been manually editing and I am continually coming over areas that are just wrong. I don't think I can rely on ArcGIS computer generated models at all...