Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

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. enter image description here

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 enter image description here

Flow Accumulation raster produced from an integer DEM enter image description here

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: enter image description here

Watershed basins produced from a floating point input DEM: enter image description here

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) enter image description here

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

share|improve this question
See also related question: Workflow for determining stream gradient? –  Kirk Kuykendall May 3 '11 at 15:02
Where does the hillshading come from? The (black) flow accumulation results do not seem to be derived from the hillshaded elevations. Perhaps you could show us the same map but with a hillshaded rendition of the grid used to obtain the flow accumulation values. –  whuber May 3 '11 at 16:06
Right. I should have mentioned that. The hillshade is derived from the same grid. (And the black stream network is a Stream order (Strahler) derived from the Stream Link raster) Everything on this map except for the location of the stream (blue) is generated from the same grid. –  Jakub May 3 '11 at 16:16
my advice for narrowing down complex problems is to use a simple test case. Clip a small piece of from your raw raster source, and try the steps the way you'd like (e.g., keep as float). Definitely fill sinks, always. Carefully examine the output of each step to make sure it "looks right". –  Mike T May 4 '11 at 19:21
Jakub I get the same exact problems. You aren't alone! The answer I'd been given previously was not to use the LiDAR data for creating drainage networks... –  Jacques Tardie May 4 '11 at 21:35
show 17 more comments

6 Answers

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.

share|improve this answer
I actually tried this but the toold crashes a lot. I used the LiDAR derived contours (2K x 2K subset) then removed small insignificant contours to make the surface simpler and tried the TopoToRaster but it just keeps dying. (Too many points in the contour polyline error) Should I just try points elevations instead? –  Jakub May 6 '11 at 13:27
And speaking of CDED I've had all kinds of issues (still unresolved) with the integer rounding and the resulting "terrace anomaly" issues. –  Jakub May 6 '11 at 13:31
I was able to sucessfuly create a "hydrologicaly correct" surface with the TopoToRaster tool by using the LiDAR points as point (spot) input. I created 2 surfaces with different output cell sizes: 2 and 4. Resulting Flow accumulation raster suffers from the same problems. I am beginning to suspect that this cannot be done in ArcGIS. I would also like to point out that it takes extremely long time to run the TopoToRaster. –  Jakub May 6 '11 at 17:20
add comment

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.

share|improve this answer
I will second this! The D8 flow direction will yield undesirable results on high resolution data where as TauDEM has D-infinity flow direction available. Also, keep in mind the intent of a hydrological flow model. Bigger is not always better (resolution wise). A ultra high-resolution DEM is more your problem than the model. Lidar derived DEM's inherently have real "noise" that was never intended for use in a flow model. I would highly recommend downscaling your DEM. –  Jeffrey Evans Jan 16 '13 at 20:00
add comment

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.


share|improve this answer
Thanks. Obtaining a continuous Flow Direction raster from which I could derive a usable drainage network especially in flat areas seems to be my major issue. Can you please describe how The D8 method can be used in ArcGIS to produce a flow direction raster? –  Jakub Mar 30 '12 at 15:33
Just to add to this. I think the existing algorithm is not infinite - as if it had a cut-off parameter that does not allow it to track the flow upstream if it determines that there could be memory issues. –  Jakub Mar 30 '12 at 15:36
You can create a Flow Direction raster in Arcgis. I can run it for you if you don't have the capability. –  Thad Apr 10 '12 at 12:39
Sorry i meant flow accumulation in the above comment, not flow direction. This is the initial problem as described in this question. The flow direction tool tool does not yield usable results when run on dense Lidar data in low lying areas. In fact using a floating point raster yields irreparable errors while using integer raster generalizes data too much. As it stands it is impossible to derive an accurate drainage model from LiDAR data using ArcGIS tools alone. –  Jakub Apr 10 '12 at 12:50
I don't understand how the density of the data would matter. The data i use is 1 cm^2. way more dense. Let me download your data, and I will try. –  Thad Apr 10 '12 at 12:59
show 1 more comment

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.

share|improve this answer
Thanks Matt. Good stuff. I will try this and report back. Lots of very interesting information. Thanks for the effort you put into this. –  Jakub May 6 '11 at 13:20
When I multiply the input raster by 1000 I get the same results as before. I tried both the integer and the floating point. Resulting Flow Accumulation raster is nearly identical in both cases. Off to try to make the TopoToRaster technique work. –  Jakub May 6 '11 at 14:26
add comment

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

share|improve this answer
this article, Terrain Datasets, The top 10 reasons to use them, has got me thinking that a DEM raster surface is just the wrong data model to use in your case. We rejected TINs for our elevation models as the facets produced too many artifacts in our experiments. However our source data were contours and not a dense field of spot heights like Lidar. –  matt wilkie May 17 '11 at 16:25
add comment

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.... enter image description here

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.