I did try without changing CRS before doing the contour extraction, still no luck. 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.
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. 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. Can anyone else confirm this behaviour when extracting contours from merged SRTM tiles? Tom > On Mar 23, 2014, at 6:06 AM, Andre Joost <[email protected]> wrote: > > > Am 22.03.2014 18:59, schrieb Tom Beddard: > > >> Are there any tricks to generating contours from merged files or is >> it just going to be a case of scripting the generation of lots of >> .shp contour files from each of the elevation tiles? >> >> >> >> >> Thanks for any help, I’m still on the steep bit of the learning curve >> with all of this :) >> >> >> >> >> > > > > The SRTM data is in EPSG:4326, so I suggest to do the merging and > contour creating in that CRS. Reprojecting of rasters always causes > nasty edges, and the contour process might stumble upon that. > > > HTH, > André Joost > > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > >
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
