<html xmlns="http://www.w3.org/1999/xhtml"><head><title></title></head><body><div>Thanks Jukka.
</div><div>Good to know about gdalinfo -hist as you said the problem was the incorrect setting for the nodata value.
</div><div>I was using 32767 as suggested in various wikis, but instead now it works as expected by changing the command to:
</div><div>gdal_contour -a elev -snodata "-32768" -i src.tif contour.shp<br>
</div><div>Could this be an issue with how OSX is interpreting the numbers verses Windows or Linux?
</div><div><br></div><div>I’m also now generating the contours and then reprojecting the shape file to EPSG:900913 using ogr2gor
</div><div>For those interested my updated script to automate this is now:
</div><div><a href="https://gist.github.com/subblue/9705999">https://gist.github.com/subblue/9705999</a><br></div><div><br></div><div>Thanks very much for your help!
</div><div>Tom
</div><div><br></div><div><br></div><div><br></div><div class="unibox-signature"></div><div><br></div><blockquote type="cite" class="unibox-hidden"><div>On Mar 24, 2014, at 2:51 PM, Jukka Rahkonen <jukka.rahkonen@mmmtike.fi> wrote:
</div><div><br></div><div>Tom Beddard <tom <at> subblue.com> writes:
</div><div><br></div><blockquote><div><br></div><div><br></div><div>I do specify -i 20 in my scripts (that was a typo just in my original
</div><div><br></div></blockquote><div>email). Does it still work ok for you with an interval of 20 instead of 100?
</div><div><br></div><div>I stopped the test because it was so slow and would probably stopped because<br>of too big shp filesize.
</div><div><br></div><div>You must start to study the problem systematically. I took some first steps
</div><div><br></div><div>E:\demkoe>gdal_contour -a elev -i 20 srtm_36_01.tif small.shp<br>E:\demkoe>ogrinfo -al -so small.shp<br>...<br>Layer name: small<br>Geometry: Line String<br>Feature Count: 44895
</div><div><br></div><div>Feature Count for srtm_36_01.tif is 73291.
</div><div><br></div><div>Thus 118186 linestrings are needed for the contour lines of those to<br>originals. However, it looks like for making the 20 m contour lines from the<br>merged image creates much much more contour lines. Your challange is to find<br>out why. I guess I would start by thinking about the nodata values. You use<br>parameter -snodata 32767
</div><div><br></div><div>However, if I run gdalinfo -hist for the merged file I can see<br>Band 1 Block=6001x1 Type=Int16, ColorInterp=Gray<br>Min=-32768.000 Max=1309.000
</div><div><br></div><div>Looks to me that your nodata value does not exist in the data. Instead there<br>are 35118128 occasions of -32768. It may be that gdal_contour is creating<br>for you 20 m contours starting from 32 kilometers below the sea level. Do<br>all the steps one by one first without mosaic, check the statistics and<br>histogram, open the shapefile with QGIS for visual check and think if the<br>result is correct.
</div><div><br></div><div>I an not sure it bilinear sampling can make troubles. Probably nearest would<br>give about the same end result but you can test that also. Do not change<br>anything else when making comparisons. Good luck for your experiments.
</div><div><br></div><div>-Jukka-
</div><div><br></div><div><br></div><div><br></div><div>_______________________________________________<br>gdal-dev mailing list<br>gdal-dev@lists.osgeo.org<br>http://lists.osgeo.org/mailman/listinfo/gdal-dev
</div><div><br></div></blockquote></body></html>