<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi all,</p>
<p>Thanks a lot for the feedback.<br>
</p>
<p>I have also resorted to polygonize (geos-polygonize) and ran into
the classification problem that you mention. There is also the
issue of performance if you have a lot of complex polygons, on a
high res raster, contours would take a couple of seconds, and
geos-polygonize enought time for me to Ctrl+C before the end.</p>
<p>At the time I needed to tile the problem anyway (split heigth
classes into smaller polygons such that the spatial index is
usable, which is not the case if you have huge polygons) so the
classification issue was the only problem I faced in the end.<br>
</p>
<p>I've started the work with the "easy" part: making properly
oriented and classified closed rings (see
<a class="moz-txt-link-freetext" href="https://trac.osgeo.org/gdal/ticket/6526">https://trac.osgeo.org/gdal/ticket/6526</a>).</p>
<p>I'll also try the gdal_polygonize approach, but I don't think
it's the same thingl: with raster-classif + gdal_polygonize, if
you have 3 classes 1,2,3 polygons from 1 can touch a polygon from
3, with contour lines there will always be a polygon of class 2 in
between. <br>
</p>
<p>Or am I missing something.</p>
<p>If someone believes I'm doing something useless and/or stupid
(that also happens), please do tell.</p>
<p>V.<br>
</p>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">Le 20/10/2017 à 01:15, Roberto Ribeiro
a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CANTZQ+yu9D=F2Yno5OSb1g+LvkTSSVuaQEORC=mBvPqFLGC-ug@mail.gmail.com">
<div dir="ltr">
<div>
<div>
<div>I too have run into this problem in the past, though I
believe, if you are to use gdal_contour you have access to
the underlying DEM/TIN/LAS, and if you have that it's much
easier just converting it directly to polygons (using the
technique Jamie posted, or similar ones). It could be a
gdal_contour flag if it makes sense to group it this way
(contour lines and hypsometry maps are closely related,
after all), but it makes more sense to me that it be its
own routine.<br>
<br>
</div>
Turning contour lines into contour polygons is surprisingly
difficult, I found. Closing the polygons is the easy part,
but knowing which polygon to assign which value is
considerably trickier, because a polygon ill have part of
its boundary representing one value, and part representing
another. If you have a natively closed polygon with no inner
ring, you can start from there and assign to the polygon its
outer boundary's values, then proceed to the smallest
polygon that completely encloses the previous one, and so
on. But it's quite possible you'll have no natively closed
loops in your AoI, most noticeably when doing high
resolution work. You can pick a line at random and do an
R-tree search for the closest value, but that can be pretty
heavy if you have a lot of lines (and if you have break
lines it completely throws a wrench at your process).
Thinking about it now, it might work to assign the value
during polygon creation time<br>
</div>
, but that would mean writing a custom polygonize function.
But it might work.<br>
<br>
</div>
I've always been curious about it (given that I tried doing it
once, but resorted to the raster approach), does anyone know of
an algorithm for this?</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2017-10-19 15:57 GMT-02:00 Jamie Adams
<span dir="ltr"><<a href="mailto:jaadfoo@gmail.com"
target="_blank" moz-do-not-send="true">jaadfoo@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">From a user perspective, this can be done
pretty easily using gdal_calc.py & gdal_polygonize.py.
I've used this technique in the past several times. This
doesn't help with gdal_contour of course, but is a viable
way of doing the same thing. Maybe worth considering as a
new python tool.
<div><br>
</div>
<div>Using a random SRTM tile in bash:</div>
<div><br>
</div>
<div>for iso in 800 1000 1200 1400 1600</div>
<div>do </div>
<div>gdal_calc.py --NoDataValue=0 -A N22E005.tif
--calc="A>${iso}" --outfile ${iso}.tif</div>
<div>gdal_polygonize.py -f "ESRI Shapefile" ${iso}.tif
${iso}.shp</div>
<div>done<br>
</div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Oct 19, 2017 at 5:47
AM, Vincent Mora <span dir="ltr"><<a
href="mailto:vincent.mora@oslandia.com"
target="_blank" moz-do-not-send="true">vincent.mora@oslandia.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
Gregers,<br>
<br>
Thanks for your reply.<br>
<br>
The question was not "how to" yet, but "shall I"
;o)<br>
<br>
I think I did something similar to the "ends
matching" in a python<br>
script that creates those polygons (in a
particular context that also<br>
requires tiling).<br>
<br>
What I'd like to know, is if there is a reason why
it's not already<br>
available in gdal, since there is the need for
that and apparently algos<br>
to reach the goal.<br>
<span><br>
> You cannot always make polygons with them
unless you are on a perfect<br>
island<br>
<br>
</span>I'm not sure I understand the that. The
polygons I have in mind are<br>
polygons with holes (multipolygons for a given
class actually), is it<br>
related to what you're saying ?<br>
<span class="m_5699450017164639025HOEnZb"><font
color="#888888"><br>
<br>
V.<br>
</font></span>
<div class="m_5699450017164639025HOEnZb">
<div class="m_5699450017164639025h5"><br>
<br>
Le 19/10/2017 à 14:23, Hans Gregers Hedegaard
Petersen a écrit :<br>
> Hi Vincent,<br>
><br>
>> I know this is old stuff (references
below), but making polygons instead<br>
>> of lines would be a great option for
gdal_contour IMO.<br>
>><br>
>> It could be also another program
included in gdal/app (if it is already,<br>
>> I can't find it).<br>
>><br>
>> What do you think, shall I add that ?
If yes, first or second option ?<br>
> I had a similar problem years ago, and
after making consistent<br>
> orientation [1] it is simply a matter of
running through the lines and<br>
> matching starting points with endpoints
in the linestrings. This is a<br>
> rather fast operation on a spatially
indexed dataset.<br>
><br>
> You cannot always make polygons with them
unless you are on a perfect<br>
> island - for instance I processed Denmark
in tiles (over 43000 tiles<br>
> of 1x1km) and then "glued" the
linestrings together afterwards. Speed<br>
> was essential, so I first glued all
linestrings in a tile (which would<br>
> make a large number of closed
linestrings), then between tiles (but<br>
> only for those that were not yet closed).<br>
><br>
><br>
> Cheers,<br>
><br>
> Gregers<br>
><br>
><br>
> [1]: <a
href="https://trac.osgeo.org/gdal/ticket/3129"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://trac.osgeo.org/gdal/ti<wbr>cket/3129</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org"
target="_blank" moz-do-not-send="true">gdal-dev@lists.osgeo.org</a><br>
<a
href="https://lists.osgeo.org/mailman/listinfo/gdal-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.osgeo.org/mailma<wbr>n/listinfo/gdal-dev</a></div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org"
moz-do-not-send="true">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.osgeo.org/<wbr>mailman/listinfo/gdal-dev</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>