<html xmlns="http://www.w3.org/1999/xhtml"><head><title></title></head><body><div>I did try without changing CRS before doing the contour extraction, still no luck.
</div><div>The strange thing is that a single SRTM tile might generate a contour shape file of ~120MB and take just over a minute to process, however combining just two tiles with gdal_merge.py and then running gdal_contour generates a shape file around 4.1GB and takes about 20 mins, so it does seem that something gdal_merge.py is doing is causing a problem.
</div><div><br></div><div>I don’t know how the contour algorithm works so I don’t know if you would expect a linear or quadratic relationship between processing time and the size of the area being analysed. To see such a dramatic increase from just doubling the area seems unexpected.
</div><div><br></div><div>For the moment I’m generating a single contour file for each elevation tile, not ideal as there is a slight visual join of the contours between tiles that I’m having to handle with some careful styling.
</div><div><br></div><div>Can anyone else confirm this behaviour when extracting contours from merged SRTM tiles?
</div><div><br></div><div>Tom
</div><div><br></div><div><br></div><blockquote type="cite"><div>On Mar 23, 2014, at 6:06 AM, Andre Joost <andre+joost@nurfuerspam.de> wrote:
</div><div><br></div><div>Am 22.03.2014 18:59, schrieb Tom Beddard:
</div><div><br></div><blockquote><div>Are there any tricks to generating contours from merged files or is<br>it just going to be a case of scripting the generation of lots of<br>.shp contour files from each of the elevation tiles?
</div><div><br></div><div><br></div><div>Thanks for any help, I’m still on the steep bit of the learning curve<br>with all of this :)
</div><div><br></div><div><br></div></blockquote><div><br></div><div><br></div><div>The SRTM data is in EPSG:4326, so I suggest to do the merging and<br>contour creating in that CRS. Reprojecting of rasters always causes<br>nasty edges, and the contour process might stumble upon that.
</div><div><br></div><div>HTH,<br>André Joost
</div><div><br></div><div>_______________________________________________<br>gdal-dev mailing list<br>gdal-dev@lists.osgeo.org<br>http://lists.osgeo.org/mailman/listinfo/gdal-dev
</div><div><br></div></blockquote></body></html>