<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">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">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">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">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">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">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/gdal-dev</a><br></blockquote></div><br></div>