<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="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 class=""><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="HOEnZb"><font color="#888888"><br>
<br>
V.<br>
</font></span><div class="HOEnZb"><div class="h5"><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/<wbr>ticket/3129</a><br>
<br>
<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></div></div></blockquote></div><br></div>