[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