You are here: > ESRI Forums > arcgis desktop discussion forums > Thread Replies

ArcGIS Desktop Discussion Forums

ArcGIS Desktop - Geoprocessing Scripting (Python, JavaScript, VB) forum

creating topologically correct filled polyg...   dan strobridge Apr 17, 2008
Re: creating topologically correct filled p...   Stephen Lead Apr 17, 2008
Re: creating topologically correct filled p...   dan strobridge Apr 18, 2008
Re: creating topologically correct filled p...   William Huber Apr 18, 2008
Re: creating topologically correct filled p...   Ianko Tchoukanski Apr 20, 2008
Re: creating topologically correct filled p...   dan strobridge Apr 20, 2008
Re: creating topologically correct filled p...   Ianko Tchoukanski Apr 20, 2008
Re: creating topologically correct filled p...   William Huber Apr 20, 2008
Re: creating topologically correct filled p...   Ianko Tchoukanski Apr 20, 2008
Re: creating topologically correct filled p...   Stephen Lead Apr 20, 2008
Re: creating topologically correct filled p...   William Huber Apr 21, 2008
Re: creating topologically correct filled p...   Ianko Tchoukanski Apr 21, 2008
Re: creating topologically correct filled p...   dan strobridge Apr 22, 2008
Re: creating topologically correct filled p...   dan strobridge Apr 22, 2008
Re: creating topologically correct filled p...   Ianko Tchoukanski Apr 23, 2008
Re: creating topologically correct filled p...   Jakub Sisak Feb 09, 2010
Re: creating topologically correct filled p...   dan strobridge Feb 09, 2010
Re: creating topologically correct filled p...   William Huber Apr 22, 2008
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject creating topologically correct filled polygon contour isoshells 
Author dan strobridge 
Date Apr 17, 2008 
Message I've been doing some searching on this subject and could only find one post where someone was trying to do something similar... and there were no solutions. I want to create filled polygons that can be plotted using a color ramp based on contour value. I want to create the polygon file from a line file of contours that have a unique ID field as well as a contour value field. All of my attempts to do this produce a topologically correct polygon file that has had the contour values completely messed up.

My line file was generated using a contour list, but I imagine the solution would be the same for a set contour interval. My lines are all closed because I did a little pre-processing work to depress the edges of my grid down to a uniform value of zero. My original attempts at this involved open lines and a bounding box (just as the person in the aforementioned post was trying).

I've used ET GeoWizards (an amazing utility) to convert the polylines to filled polygons while keeping the database structure and contour values in-tact. The only reason it works is that the resulting file is not topologically correct (it's just a bunch of overlapping polygons none of which have holes in them) but I can sort of use it in my layouts by exploiting the symbol priority to force high-valued polygons to plot on top. The only downside to this is when you have a local depression in the contours (low valued polygon plots within a high valued polygon and therefor gets hidden because it's on the bottom). Virtually any geoprocessing operation (clean&build, intersect, etc... ) will fix the topology on the polygons but will destroy the contour values because duplicate shapes are produced that have two different contour values due to the common line between the now adjacent polgyons. It doesn't seem to me that there is a single logical process that will delete only the polygons that you don't want... leaving low-valued depressions where they should be AND leaving high-valued mounds where they should be.

Can someone smarter than myself please make a suggestion that will get me started down a path that I've not tried before and has a good chance of success? I can do a little python and VBA but do not know the Arc object model at all.

Thanks,
Dan 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: creating topologically correct filled polygon contour isoshells 
Author Stephen Lead 
Date Apr 17, 2008 
Message Dan,

I doubt I'm smarter than yourself, but here's an attempt to help with the problem. It's a bit convoluted but doesn't require any coding.

I did some simple tests with a fake set of contours with elevations of 10-20-30-20-10 with the top section being a depression at the top of a hill. It looks like the limitation with ET Geowizards (which is definitely amazing) is that if you generate polygons with elevation values, successive contours overlap each other - as you found.

If you use the ArcToolbox > Feature To Contour tool, the contour polygons don't overlap, but you don't get the elevation value on the polygon.

So if we take these polygons as the correct geometry, we somehow need to attach the elevation values.

ET Geowizards has the option to create "label points" under > Convert > Polygon to Point. This will create a point which sits within each polygon. Using the polygons created by ArcToolbox, this results in a single point within each unique polygon. If we can obtain an elevation value for the point, we can join it to the polygons to set the elevation for the polygon.

If you generate a TIN from the contour lines, you can then convert the TIN to a GRID and use the Spatial Analyst > Extract Values to Points tool in ArcToolbox to obtain the elevation at the points. (There are other options for obtaining the Z values if necessary, possibly within ET Geowizards.)

So now you have all the elements you need - a topologically correct polygon layer, and label points with elevations. If you do a spatial join from the label points to the polygons, you'll have polygons with elevations.

Except..... the elevations on the label points will be the interpolated value taken from the raster surface (eg 17.6589). Presumably you want your contour polygons to show rounded values, like the original contour lines.

How are you defining the elevation value of the area between contour lines? Eg between contours 10 and 20, what is the desired value of the polygon? 10? 15? You'll have to write some sort of rounding expression on the label points to generate the desired value, eg the expression:

(round(([elevation] - 5) / 10, 0)) * 10

will convert any number > 10 and < 20 into 10. In my case this meant that the polygon in the depression at the top of the hill had an elevation of 0, since the elevation was interpolated as being below 10 when the TIN was created. This is possibly not the value you want, as the lowest contour line value was 10.

You might need to tweak the rounding expression, but hopefully the point-in-polygon approach will work in principle.

Good luck,
Steve 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: creating topologically correct filled polygon contour isoshells 
Author dan strobridge 
Date Apr 18, 2008 
Message Hi Steve,

Thanks so much for taking the time to investigate this. I don't see a "feature to contour" tool. Did you mean "feature to raster"? I like the concept of creating a correct poly file and obtaining a set of unique points representing each polygon and doing a spatial join. This is just the sort of spark I needed to take me in a new direction. I'm using a one to many relationship to attempt to find all the polygons that each point falls within. I was then thinking I could filter that list to return just the minimum area polygon (will return local highs and local lows) for each point id. Once I had the filtered data set, I could then just do another a traditional join, based on featureid, to apply the contour value obtained from the spatial join to the topologically correct polygons. There are two problems I'm encountering. First, the spatial join does not appear to return all of the different polygons that a point falls within and it appears to return some polygons that the point does not fall within. I have a feeling that the weirdness of the ETGeoWizards poly file is responsible for this. The second problem is that I can't figure out how to filter the spatial join table within ArcMap. I think the max() function only works for geodatabases. I guess i could create a geodatabase... but for now, i just created a "flag" field and then did a little work with the dbf for the shapefile in excel to put a 1 in if it's the lowest-area polygon for that point id and 0 if it's not. Regardless, the fact that the spatial join did not work properly is the primary obstacle to be overcome. Can anyone out there point me toward a snippet of VBA that I could use an example to try and manually loop through every polygon for each point to find the smallest one that the point falls within?

Thanks,
Dan 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: creating topologically correct filled polygon contour isoshells 
Author William Huber 
Date Apr 18, 2008 
Message Dan and Steve,

If you're going to make a TIN or a grid, then you might as well generate the "solid contours" directly from that and be done with it.

The challenge, then, is to generate solid contours from a collection of contour lines directly, using vector operations only.

I twice attempted that in ArcView 3, as recently as six years ago, but was forced to abandon the project due to unavoidable bugs in ArcView's geometry calculations. The algorithm works fine--it doesn't even require closed contours--but when errors occur in splitting polygons with polylines, you're screwed.

OK, let's trust ArcGIS 9. Let me share an algorithm with you.

The input is a polygonal region and a set of polylines, each attributed with a number (its "height"). In preliminary steps, union any polylines of the same height together, so that to each height corresponds one unique (possibly disconnected) polyline. Sort these polylines into ascending order by height.

Let's consider the properties that make this a collection of contour lines and not just a bunch of lines scribbled on a map:

1) No two distinct polylines cross each other (intersect transversally).

2) Each polyline must dissect the region into two or more connected polygonal pieces. Each connected component of such a dissection intersects either polylines of lesser height or polylines of greater height, but not both.

(Property 1 is violated by overhangs, which cannot be unambiguously represented by contours.)

(Property 2 does not necessarily hold in some extreme cases: a perfectly level ridge or perfectly level valley, whose heights coincide with a contour value, will violate this property. Such contours are extremely rare, however, and if we consider them to be infinitesimally skinny loops, then property 2 always holds. Thus, as part of preprocessing, you can check for polylines that violate property 2 and replace them with very tiny buffers of those polylines.)

The algorithm exploits these properties. Initially, endow the input region with two null attributes: its lower height and upper height.

Let's see what happens when we start splitting the region with the polylines. (If there are no polylines, just output the entire region and its attributes.) Take the first (lowest) polyline and split the region with it, producing a collection of non-intersecting polygons. Each polygon in this collection inherits the lower height and upper height attributes of its parent (region) polygon. Momentarily retain the elevation, 'h', of this splitting polyline.

Remove the first polyline from the list and proceed to the next polyline. Let its height be 'k'. We are going to compare it to each of the regional components produced in the previous step. There are two possibilities:

(1) They do not intersect. In this case, set the upper height of the component to 'h' and output the polygon and its height attributes.

(2) Otherwise, they do intersect. Set the component's lower height to 'h' and *recursively apply the algorithm* to this component as the starting region, using a clone of the list of remaining polylines (including the one of height 'k').

If you are convinced that step (1) is correct, then the entire algorithm must be correct, because step (2) just applies the algorithm to an identical situation. But it should be obvious that step (1) does the right thing.

Notice that converting polylines to polygons is never done: the basic operations are splitting a polygon by a (potentially closed) polyline and testing whether a polyline intersects the interior of a polygon.

Notice, also, the following properties of the output:

a) Two regional components either do not intersect or else they intersect along a boundary that coincides with one of the original contours.

b) The union of the regional components coincides with the original region.

c) Every regional component has a lower and upper height, either of which may be null. A null lower height means this component is at elevations lower than all contours; a null upper height means it is at elevations higher than all contours.

d) When the original contours were obtained at regular intervals, then the difference between the upper and lower height must equal that interval. (This is implied by the procedure of step (2) in the algorithm.) 
  --Bill Huber
Quantitative Decisions (http://www.quantdec.com )
More GIS Q&A at http://gis.stackexchange.com/q/3083/664 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: creating topologically correct filled polygon contour isoshells 
Author Ianko Tchoukanski 
Date Apr 20, 2008 
Message Another possible approach that looks to me easier and does not need any programming.

1. Convert closed contours to polygons. As you mentioned you will get polygons that will be overlapping. This is what the function does. The polygons however will have all the attributes of the original polylines including the Height. (Dataset1)
2. Apply any of the topological operations you mentioned in your original post on the above dataset, or on the original polylines to get a topologically correct polygon (Clean, Build, etc). As you mentioned you will loose the attributes, which is normal having in mind that each polygon is constructed by several polylines that have different attributes. (Dataset2)

Now we need to find a way to transfer the attributes from Dataset1 to Dataset2. The easiest way to do this is to get a label for each polygon from Dataset1 that is as close to the boundary as possible. This is to ensure that the label will not be inside of the polygon representing the next contour height, which by definition for contours will be smaller (a contour with height of 110 will be inside of the contour with height 100). There are several ways to achieve this, but the easiest (and achievable with the tools available) should be

3. Buffer Dataset1 with a very small NEGATIVE buffer distance. This will shrink the polygons and they will be inside of the original polygons of Dataset1. (Dataset3)
4. Get the From Node of each polygon of Dataset3. It should carry the attributes and will be inside of the corresponding polygon of Dataset1. Tools to achieve this are available. (Dataset4)
5. Use Spatial Join to join the points (Dataset4) to the topologically correct polygons (Dataset2)

The procedure above will give you topologically correct polygons. Each polygon will have the height of the lower (in a case of depression - upper) contour it is created from. Having in mind that the contour intervals are in general the same, you can recalculate the value of the field you want to display together with your classification.
 
  http://www.ian-ko.com 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: creating topologically correct filled polygon contour isoshells 
Author dan strobridge 
Date Apr 20, 2008 
Message Thanks so much for your input Ianko. I sort of follow you but am a little confused as to what the "from node" command you mention is. Do you mean a simple polygon to point conversion? I've found that performing this operation on the original non-topologically correct data set (whether you use polygon centers or label points) results in points that plot within the boundary of multiple polygons. While these points have the attributes of their parents, the spatial join to the topologically correct data set will not work because the location of the point is not in a location that is unique to the parent polygon.

Bill, I trust that your algorithm will give what I need but I am not sure I understand how to implement that. I am going to pursue an option that you mentioned at the beginning of your post however. I remember that in my first attempts to come up with a workflow a year or so ago, I did use the reclass raster technique and extracted polygons from that. It gave non-intersecting polygons with the proper "heights", but the edges had an ugly stair-step pattern because of the grid cell borders and I chose to just use the original floating point grids in my layouts for that job with a classed color symbology and a bicubic interopolation for smoothing the borders between colors. I just realized that the "smooth polygons" option in ET GeoWizards may be able to help me fix the stair-step pattern.

Dan 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: creating topologically correct filled polygon contour isoshells 
Author Ianko Tchoukanski 
Date Apr 20, 2008 
Message Dan,

You just need a point that is inside the polygon and very close to the polygon boundary. In the step 3 of my post above, you get a polygon that is inside of the original polygon. You need one point of the boundary of this polygon to use it as a label point. The easiest one you can get is the node of the polygon boundary. Think about the boundary of a polygon as a polyline. It starts and finishes at the same point. This is the point you can easily get. These are the steps to accomplish step 4. in my previous post:

1. Polygon To Polyline (this will give you the boundary of the polygon as a polyline)
2.Polyline To Points (with "Node" option and "Remove Duplicates" option). Since the “From” and “To” nodes of the closed polylines coincide, this will give you a single point per polyline. In your case this will be a single point inside your original polygon that will be very close to the boundary.
 
  http://www.ian-ko.com 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: creating topologically correct filled polygon contour isoshells 
Author William Huber 
Date Apr 20, 2008 
Message Ianko,

Your method is certainly worth a try. I wonder whether it will produce correct results in very steep sections. One of the (many) problems I encountered in my AV 3.x attempts was that contours generated by Spatial Analyst from grids are jagged and frequently coincide with each other in steep areas. Generalizing or smoothing these contours, such as with the Douglas-Peucker method, can actually cause them to cross in some instances. 
  --Bill Huber
Quantitative Decisions (http://www.quantdec.com )
More GIS Q&A at http://gis.stackexchange.com/q/3083/664 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: creating topologically correct filled polygon contour isoshells 
Author Ianko Tchoukanski 
Date Apr 20, 2008 
Message Bill,

We are discussing here a method to achieve something and the assumption is that the data we are dealing with is accurate enough. I agree that the contours created from grid surfaces are jagged and it cannot be otherwise (we are dealing with a cell based model). If however the accuracy of the source grid is good enough for the relief it represents this should not be a problem. I did not mention anything about generalization in my post, but I agree with you on this point as well - if an inappropriate generalization or smoothing is used, the result might be contours that are crossing each other.

If however the original contours are fine, there is no reason why the method I proposed above will not work.
 
  http://www.ian-ko.com 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: creating topologically correct filled polygon contour isoshells 
Author Stephen Lead 
Date Apr 20, 2008 
Message Dan,

I'm definitely out of my depth in the smarts department now, but if you did still want to try my suggestion, I made a small typo which is why you can't find the tool I mentioned.

In my 3rd paragraph I meant to say the Feature to Polygon tool (found under > ArcToolbox > Data Management Tools > Features), which creates non-overlapping contour polygons with no elevation values.

So you would use this tool to create the polygons from your original contour lines, and ET Geowizards to create the label points from these contour polygons. Because these polygons don't overlap, there should be exactly one label point per polygon.

I'm not sure how to go about Bill's suggestion of creating solid contours directly from the TIN, but the step I took was to generate the TIN from the contour lines, then extract the height of the label points from the TIN, and join the points to the polygons.

This all seemed to work OK on my test data, which was admittedly very simple.

Steve 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: creating topologically correct filled polygon contour isoshells 
Author William Huber 
Date Apr 21, 2008 
Message Ianko,

Thank you for your clarifying response. I do not disagree with your conclusion and consider that point settled. I would like, however, to make two followup comments, even though they are tangential to the original topic.

The first point: it is not necessary for contours derived from a discrete grid (a "cell based model") to be jagged. They can be created, from the outset, as smooth curves using well-known, efficient methods. (The Danish UNIRAS package has been doing it this way since at least the mid-'80s and I'm sure many other contouring packages have followed suit: just not Spatial Analyst.) Jaggedness is purely an artifact of crude algorithms.

The second point is more philosophical and encompasses two ideas. They are not intended to be critical of you (or of anyone else), but some may find them controversial. First, I agree that people who initiate threads are usually looking for "a method to achieve something." However, because our responses are semi-permanent, searchable, and can be read and re-read for years, it behooves us to comment whenever we can on the range of applicability of our suggested solutions. Moreover, I believe that many people are interested in understanding the principles that underlie the solutions, so they can expand their own capabilities. Second, settling for "accurate enough" can be dangerous. When software fails dramatically, by crashing or failing to complete, that's a good thing, because errors are not propagated. At least we know something went wrong! When a procedure can produce incorrect answers without warning, though, it can be a very bad thing indeed, because then the user may proceed to use incorrect output for further analysis or important decision making. Therefore, again, it behooves us to identify the limitations and assumptions in our procedures, *especially* whenever such procedures are quick fixes or rely on special characteristics assumed of the input.

(These concerns motivated my original contribution to this thread.) 
  --Bill Huber
Quantitative Decisions (http://www.quantdec.com )
More GIS Q&A at http://gis.stackexchange.com/q/3083/664 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: creating topologically correct filled polygon contour isoshells 
Author Ianko Tchoukanski 
Date Apr 21, 2008 
Message Bill,

This is getting a bit out of topic, but I think that the way the discussion turned is important and would like to explain my view point on it.

Point 1. “Jagged contours” - I don’t know much about the algorithms you mentioned, so for now I’ll have to agree with you.

Point 2. This is the important one.
- I believe that all participants in this forum “are interested in understanding the principles that underlie the solutions”. My understanding is that everyone that follows the discussions here is a professional that can evaluate the different responses and select the one that is more suitable for his/hers needs. I think that NO RESULT (of any spatial operation) should be accepted as valid until it is thoroughly tested and would like everybody to understand how important this is.

- About the "accurate enough" issue. I do not agree with you on this point. Think about the task that started this discussion. We are trying to represent an elevation range (say 10 meters) with a single polygon. With this we are sacrificing huge amount of information. I agree that this is sometimes necessary in order to represent the data, so we do it. This however is just a derivative of the data that is meant for representations only. My point is that there are thousands of cases where we have to find a solution that is "accurate enough" for the purpose of the exercise.

- On another topic: One should always evaluate the input data before deciding how to approach the task. I’ve seen many people demanding coordinate accuracy of 10 digits after the decimal point for data captured by digitizing from 1:50,000 maps.

With the above I do not say that the method proposed for the task is sacrificing something. It should work 100% for elevation data correctly represented ("accurate enough") by contours.
 
  http://www.ian-ko.com 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: creating topologically correct filled polygon contour isoshells 
Author dan strobridge 
Date Apr 22, 2008 
Message Hi there. I just wanted to thank everyone for their input. I did not mean to start a "feud" but am very grateful for the insights that came out of the dialogue. I know both Ianko and Bill have numerous posts out there and am sure the two of you have had many discussions in the past and respect each other very much.

Ianko's technique worked for my task at hand, but I can certainly envision situations where it would not work. My contours are not actually of elevation but rather concentrations of a contaminant plume that exhibits a several order of magnitude change. In addition, I'm essentially clipping the plume to a certain polygon that represents the intersection of geologic layer and a water table that intersects it. As a result, the plume can exhibit coincident contours where my geologic zone pinches out. If I had left the grid such that the coincident contours would be produced from the contour list extraction (these were jagged intially and I used the smooth polyline feature to make them more appealing), then Ianko's technique would not have worked if one or more of the polygon endpoints fell in the section where the coincident contours were. I am not sure if there were any places where endpoints fell on coincident contours... but I have a total of 15 different plume maps to do (5 contaminants x 3 geologic zones) and I'm sure there among these different scenarios, the situation is likely to happen.

My fix was to slightly smooth the grid prior to contour extraction... this makes it so there is simply a steep slope instead of a vertical face in the grid. The negative buffer distance used in Ianko's workflow will be dependent upon the steepest place in the grid. A value of -1 foot appears to work for me. Rather than doing a spatial join at the end, I simply use the "feature to polygon" tool and use Ianko's polyline end nodes as the label points.

Now all I have to do is renew my copy of ET GeoWizards 9.2 so that I can use his conversion tools in my python script.

Thanks again guys. Steve, while your technique was not the one I ultimately went with, it was just the spark I needed and the one that causes the really big guns to weigh in.

Dan

PS. The "raster to polygon" based on a reclassed raster works but does not produce results that are as pretty as the contour extraction\line smoothing\polygon conversion technique. The primary reason for this is that the "simplify lines" option of the "raster to feature" simply generalizes the line... it does not also smooth it. In addition, this method truly does have problems in areas of steep gradients. 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: creating topologically correct filled polygon contour isoshells 
Author dan strobridge 
Date Apr 22, 2008 
Message the original image was a png. let's see if the jpg uploads. 
  contours.jpg (opens in new window)
 
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: creating topologically correct filled polygon contour isoshells 
Author Ianko Tchoukanski 
Date Apr 23, 2008 
Message Yes. No “feuding” at all. Just a good discussion on some very important topics. 
  http://www.ian-ko.com 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: creating topologically correct filled polygon contour isoshells 
Author Jakub Sisak 
Date Feb 09, 2010 
Message I came across this post accidentally so i just skimmed it, and correct me if i am wrong, but can't this be simply done by symbolizing the raster DEM or TIN surface with the same intervals as the contours? There is no need to convert the surface to polygons if you want to symbolize the areas between the contours. 
  Jakub Sisak
jsisak@dstgroup.com
www.dstgroup.com 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: creating topologically correct filled polygon contour isoshells 
Author dan strobridge 
Date Feb 09, 2010 
Message Thanks for your input. Yes, that was (and sometimes still is) my workaround. I would use a bilinear interopolation to smooth the interval boundaries.

I wanted polgyons for:
a) smooth edges at the boundary of grid values with grid "no data" regions.
b) quick area calculations
c) identify operations with other features, and
d) keeping smaller files on my computer. I wanted to be able to delete the relatively large grid after extracting out the contours of interest.

Dan

Ianko has since incorporated a feature into his ETgeowizards that significantly reduces the effort involved in generating non-overlapping filled contour interval polgyons.

Dan 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: creating topologically correct filled polygon contour isoshells 
Author William Huber 
Date Apr 22, 2008 
Message Dan,

Actually, I don't see any "feuding" going on here at all. The only place where I think Ianko was significantly wrong was in stating that he and I disagree ;-). On the contrary, everything he has written is right.

It would be fun to elaborate on this, but given the limitations of time and space, I will follow up on just one thought. Some of Ianko's assertions draw from personal experience and that can be a legitimate cause of differences of opinion. I, in particular, find that many people who use these forums are not GIS professionals: they are students, they are professionals in other disciplines, or maybe GIS is their livelihood but their formal training lies elsewhere. I suspect this characterizes the majority of GIS users (and a supermajority of people who seek answers to GIS questions on the Web). Thus, although it's an impossible task, we should try to alert people about the range of applicability of solutions we describe, because many of them will not have the experience or the knowledge to anticipate for themselves the shortcomings that might be obvious to others. At bottom, this is just a basic software engineering principle: any correct algorithm cannot be absolutely correct under all circumstances. One must clearly describe the set of data the algorithm will accept and only then can we expect it to work properly.

The interesting twist in the current thread is that our initial assumptions about your data turned out not to be true--they were not topographic elevations and they actually did get very steep--but you were nevertheless successful by virtue of understanding the nature of the solutions you could choose from and processing your data so that the solution you did select could be correct. 
  --Bill Huber
Quantitative Decisions (http://www.quantdec.com )
More GIS Q&A at http://gis.stackexchange.com/q/3083/664