I do specify -i 20 in my scripts (that was a typo just in my original email). Does it still work ok for you with an interval of 20 instead of 100?
I’m actually doing more tests just now. I’ve found that gdal_contour is significantly faster with a far smaller output shape file size if I first reproject to EPSG:3785 using gdalwarp, e.g gdalwarp -s_srs EPSG:4326 -t_srs EPSG:3785 -r bilinear srtm_36_02.tif srtm_36_02_rp.tif Then contour extraction with gdal_contour -a elev -snodata 32767 -i 20 srtm_36_02_rp.tif srtm_36_02_contours.shp Interestingly if I gdalwarp then gdal_merge the contour processing is still pretty fast (but with the artifacts of bilinear warping). But if I first merge, then reproject with gdalwarp then the processing is very slow, or fails due to the ~4GB limit Not entirely sure what is going on, but I’ll put together a script to demonstrate the different issues. Tom > On Mar 24, 2014, at 1:41 PM, Jukka Rahkonen <[email protected]> wrote: > > > Jukka Rahkonen <jukka.rahkonen <at> mmmtike.fi> writes: > > >> >> >> Tom Beddard <tom <at> subblue.com> writes: >> >> >> >> >>> Can anyone else confirm this behaviour when extracting contours from >>> >>> >>> merged SRTM tiles? >> >> >> > > Can you check this command, it is perhaps not that you actually used: > gdal_contour -a elev -snodata 32767 -i uk-3785.tif uk-contour.shp > > > My GDAL gives FAILURE: Neither -i nor -fl are specified. > With -i 100 I have managed to run your commands. Result was 620 MB shapefile > with 135020 linestrings and it took several minutes to run it but it worked > for me. > > > -Jukka Rahkonen- > > > > > > > _______________________________________________ > 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
