Tom Beddard <tom <at> subblue.com> writes: > > > 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 stopped the test because it was so slow and would probably stopped because of too big shp filesize. You must start to study the problem systematically. I took some first steps E:\demkoe>gdal_contour -a elev -i 20 srtm_36_01.tif small.shp E:\demkoe>ogrinfo -al -so small.shp ... Layer name: small Geometry: Line String Feature Count: 44895 Feature Count for srtm_36_01.tif is 73291. Thus 118186 linestrings are needed for the contour lines of those to originals. However, it looks like for making the 20 m contour lines from the merged image creates much much more contour lines. Your challange is to find out why. I guess I would start by thinking about the nodata values. You use parameter -snodata 32767 However, if I run gdalinfo -hist for the merged file I can see Band 1 Block=6001x1 Type=Int16, ColorInterp=Gray Min=-32768.000 Max=1309.000 Looks to me that your nodata value does not exist in the data. Instead there are 35118128 occasions of -32768. It may be that gdal_contour is creating for you 20 m contours starting from 32 kilometers below the sea level. Do all the steps one by one first without mosaic, check the statistics and histogram, open the shapefile with QGIS for visual check and think if the result is correct. I an not sure it bilinear sampling can make troubles. Probably nearest would give about the same end result but you can test that also. Do not change anything else when making comparisons. Good luck for your experiments. -Jukka- _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
