[Gdal-dev] gdal_merge invalid literal for int(): -3.40282e+038
Bryan Keith
bryan at geomega.com
Thu Jan 26 17:49:34 EST 2006
Matt,
I was having some problems with gdal and no data values of
-3.40282e+038. I think I had the problem with gdal_contour so I had a
sequence like this:
gdalwarp -t_srs UTMNAD83Z13m.wkt -tr 30 30 -srcnodata
-340282346638528860000000000000000000000.000 -dstnodata -99999 -rb
t57r83_g t57r83_g.tif
gdal_contour -a elevation -snodata -99999 -i 10 t57r83_g.tif t57r83_ln.shp
I also see that later in my batch file I used this syntax with gdal_merge:
gdal_merge -o shpodft.tif -ul_lr 1149856.82 16290955.21 1176503.90
16266648.39 -n -340282346638528860000000000000000000000 t56r83_g t55r83_g
I realize this is more of a work-around than a good solution. I'm not
sure where I came up with so much precision for the -3.40282e+038 value.
Bryan
Bryan Keith
GIS Specialist
Geomega, Inc.
Boulder, CO, USA
Matt Wilkie wrote:
> Hi, I'm trying to use gdal_merge to mosiack some dems, but how do I
> get it to ignore a float32 nodata number?
>
> gdlainfo says "NoData Value=-3.40282e+038" but when I try and use it
> gdal_merge pukes:
>
> gdal_merge -o d:\scratch\merged.tif dem1 dem2 -n -3.40282e+038
>
> Traceback (most recent call last):
> File "c:\local\fwtools\bin\gdal_merge.py", line 362, in ?
> nodata = int(argv[i])
> ValueError: invalid literal for int(): -3.40282e+038
>
> thanks!
>
More information about the Gdal-dev
mailing list