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

Tom Beddard tom at subblue.com
Mon Mar 24 10:30:54 PDT 2014


Thanks Jukka.
Good to know about gdalinfo -hist  as you said the problem was the incorrect setting for the nodata value. 
I was using 32767 as suggested in various wikis, but instead now it works as expected by changing the command to:
gdal_contour -a elev -snodata "-32768" -i src.tif contour.shp

Could this be an issue with how OSX is interpreting the numbers verses Windows or Linux?


I’m also now generating the contours and then reprojecting the shape file to EPSG:900913 using ogr2gor
For those interested my updated script to automate this is now:
https://gist.github.com/subblue/9705999




Thanks very much for your help!
Tom









> On Mar 24, 2014, at 2:51 PM, Jukka Rahkonen <jukka.rahkonen at mmmtike.fi> wrote:
> 
> 
> 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
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140324/81cc882b/attachment-0001.html>


More information about the gdal-dev mailing list