Nop, In line 93 in val_repl.py, the default value is taken as of type Byte. For a quick fix, mention the data type of the raster reported by gdalinfo with the option -ot to the script. Refer to ( http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/python/samples/val_repl.py#L61)
On Sat, Jun 26, 2010 at 2:11 AM, NopMap <ekkeh...@gmx.de> wrote: > > > Thank you for your reply. I played around a little bit but without success. > > When I apply val_repl.py to the data, it appears to cut off all the higher > elevations while the lower areas remain untouched. So the resulting TIF is > unusable. What could cause this problem? > > gdal_contour seems to recognize the nodata values in the cgiar files, it > produces a nice shapefile from the unprocessed data. > > But when I run hillshade.exe from the perrygeo demtools on it, it draws a > huge chasm along the coastline. I have tried to use gdalwarp with > -srcnodata > -32768 -dstnodata 0 but this does not have any visible effect. > > What am I doing wrong? > > Nop > > -- > View this message in context: > http://osgeo-org.1803224.n2.nabble.com/Handling-nodata-values-tp5222453p5223678.html > Sent from the GDAL - Dev mailing list archive at Nabble.com. > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev