[gdal-dev] Problem using gdal_contour after gdal_merge.py

[Jukka Rahkonen]

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-