Creating generalized contour lines at multiple scales with topological constraint
I've got LIDAR data that I've generated 2 meter contours from. For steep topography this works very well, but on the floodplain it starts look busy. The contour lines tend to look like zig-zags and there are lots of small closed contours. What I'm trying to do is create multiple representations for depicting contour lines at different scales using the different tolerances for representations. Highly generalized lines end up crossing each other, however. I'm wondering if there is some way to build in topological rules into the representation, such as that one contour line can never cross another. Also, I'd like to avoid going back and cleaning up thousands of topological errors.
Mapping Center Answer:
Okay, so there are a couple of big subjects within this area.
1. The flood plain looks too busy.
The higher the resolution your elevation data is, the more of this you will see. The real issue is that some of this noise is legitimate, and some is due to there not being a way to achieve a theoretical surface of "Bare Earth". Therefore, the idea is to find a balance. You also picked up on an important aspect of this issue, which is that you get a pretty decent result in areas of higher local relief. Thus, you don't want to ruin the results in those areas.
The solution is not so easy as describing the problem. One approach I've used is to create a slope grid from my elevation data that I've reclassed, typically into three classes (low, medium, and high slope); the difficulty with giving you specific slope ranges is that the meaning of those terms is going to be different from person to person, i.e, a person in the Scotland will have very different thresholds for high slope than a person in Florida.
Anyway, once I had reclassed that slope grid I also ran the Majority Filter on it to get rid of small pockets of other slope classes. During this process I've also found its okay (and faster) to use a coarser resolution (which also cuts down on the numnber these small pockets).
The result is a grid you can use to create analysis masks for each slope category.
Next, especially to cut down on the noise (small closed contours, etc.) in flat areas I've typically smoothed my LIDAR data before producing contours. I use Focal Stats with a circular neighborhood and mean statistics type. The neighborhood radius is a little trickier; I've been comfortable with something that is less than 2x my contour interval. You might try bumping that up in the low slope areas.
The idea is to smooth each slope class separately and then mosaic the result back together again to produce contours.
2. Generalizing contours.
Okay, you've recognized the danger zone here, which is producing a result that is not topologically correct. There are two strategies for generalizing contour lines, first is eliminating extra contours in areas of relatively high local relief (areas where there are just too many contours to draw and still distinguish between them). William Mackaness, et. al., published a journal article about this topic fairly recently in The Cartographic Journal (Volume 43, Number 2, July 2006 , pp. 144-156(13)).
Part of eliminating contours is to find the contours that are small loops that are not near summits. To do that you would need a point dataset of summits and other control points that can be buffered. Ideally you want to select short segments (pi * (contour Interval * d); here "d" is a multiplier, I would use values between 1.0 and 2.0, and typically I use a value closer to 2.0). The nice thing about this process is that that only short contours are closed loops (or at the edge of your dataset). That means you can select by attribute to get the short segments, and then remove from that selection any using selection by location contours that are within the buffers of your summits/control points. (the reason you want to keep the small loops around those points is that their elevation is typically labeled on the map, and any reader looking closely at those values will see that a contour is missing if you're not careful about this).
Second is simplifying contours; my thinking on this is that the only reason you should simply contours is to make them draw faster without obviously changing their shape. If the contours are too detailed for the scale of map you're making, then generalize your elevation data before producing contours--this minimizes the loss of accuracy as generalizing derivative data products has a bit more risk.
I would not use the simplification geometric filter in ArcGIS representations to accomplish simpflication as this is on-the-fly simplification and contours, relative to your map are absolutely overloaded with vertices. The result would be paralyzingly slow.
If you would like to post a comment, please login.