<div>Hi,</div><div>I've tackled a similar problem.</div><div>Correctness of contour is a simple matter, except for one thing. That is the issue of saddles.</div><div>That issue cannot be solved "correctly" since typically the data can be interpreted in several ways.</div>
<div>This is also described in a wikipedia article (google for it, if you like).</div><div>Imagine a (descending) mountainridge, which may have towers and gaps in it (sometimes referred to as sentinels when climbing).</div>
<div>When the (dem) grid is too coarse, these won't show.</div><div>I found that I had to write my own routine to handle this.</div><div>Roughly as follows:</div><div>When gridsquare with values equal or larger than the contourvalue are isolated, except they touch diagonally, you have a potential saddle situation.</div>
<div>My "correctness" is that I continue straight on when the average of the four surrounding gridpoints is equal to or larger than the contour value.</div><div>If not, the contour is divided in two subcontours.</div>
<div>Hope this helps and tell me whether you need such code.</div><div>I have been considering offering it for the gdal and saga communities, but have not had enough time to make the code nice enough.</div><div>Jan<br><br>
</div><div class="gmail_quote">On Thu, Feb 14, 2013 at 4:15 AM, nav <span dir="ltr"><<a href="mailto:navin.pro@gmail.com" target="_blank">navin.pro@gmail.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
Am creating an app which correctly calculates contours from a DEM file or any<br>
height-map given to it. The correctness of the contour holding the most<br>
importance, since a person viewing the contours shouldn't end up taking<br>
wrong planning decisions and maybe losing their life by the route they<br>
choose after looking at the map.<br>
<br>
I have already tried using GDAL 1.7 source code, compiled it and added some<br>
features of my own to it for some other objective. Now I want to<br>
add-to/modify the source to be able to use the contour generation function<br>
of GDAL in C++.<br>
<br>
But before proceeding, I wanted to know:<br>
1. If GDAL offers the best free contour generation algorithm available or is<br>
there any other library which I can link to my code and feed my DEM map to<br>
it and receive contour vector lines (or go thru research papers and<br>
implement the contour generation algorithm myself in C++)? If GDAL, then why<br>
is it the best?<br>
2. A generated contour will basically be points connected with straight<br>
lines. Is it more correct for a contour to be depicted with connected<br>
straight lines or will it give a more correct result to use a spline to<br>
smoothen out the lines?<br>
<br>
I won't be interpolating any contours or the DEM because I've read on this<br>
website that interpolation leads to incorrect results.<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://osgeo-org.1560.n6.nabble.com/Most-optimal-algorithm-for-contour-correctness-tp5034148.html" target="_blank">http://osgeo-org.1560.n6.nabble.com/Most-optimal-algorithm-for-contour-correctness-tp5034148.html</a><br>

Sent from the GDAL - Dev mailing list archive at Nabble.com.<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div><br>