[gdal-dev] why do I get a floating point nodata value from a byte raster?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] why do I get a floating point nodata value from a byte raster?

Richard Sharp
I have a byte GTiff dataset that has a nodata value of 0 according to QGIS.  However, when I load it using the gdal python API, I get this:

>>> ds= gdal.Open('cdl10lu83.tif')
>>> band=ds.GetRasterBand(1)
>>> band.GetNoDataValue()
-3.4028230607370965e+38

Also when I run `gdalinfo` I see the same nodata value:

Band 1 Block=128x128 Type=Byte, ColorInterp=Gray
  Min=0.000 Max=26.000
  Minimum=0.000, Maximum=26.000, Mean=10.115, StdDev=5.072
  NoData Value=-3.4028230607370965e+038

I'm running GDAL 1.11.0, although I've also experienced the same behavior on gdalinfo with 1.9.0. I'm using QGIS 2.4 which is built against GDAL 1.9.

Any ideas what's going on and how to handle it?

--
Richard P. Sharp Jr.
Lead Software Architect
Natural Capital Project
Stanford University, U Minnesota, TNC, WWF
371 Serra Mall
Stanford, CA 94305
http://www.stanford.edu/~rpsharp/

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: why do I get a floating point nodata value from a byte raster?

Even Rouault-2
Le jeudi 28 août 2014 23:32:38, Richard Sharp a écrit :
> I have a byte GTiff dataset that has a nodata value of 0 according to QGIS.

Well, I've just created such a file, and with QGIS 1.8, the GUI display well
the -3.4028230607370965e+38 value, but with 2.4, it displays 0. So seems to be
on QGIS side.
That said,  -3.4028230607370965e+38 doesn't make sense as a nodata value for
Byte, which can only range from 0 to 255.
After some testing, it seems that QGIS displays 0 when the nodata value is out
of the range of the data type.

>
>  However, when I load it using the gdal python API, I get this:
> >>> ds= gdal.Open('cdl10lu83.tif')
> >>> band=ds.GetRasterBand(1)
> >>> band.GetNoDataValue()
>
> -3.4028230607370965e+38
>
> Also when I run `gdalinfo` I see the same nodata value:
>
> Band 1 Block=128x128 Type=Byte, ColorInterp=Gray
>   Min=0.000 Max=26.000
>   Minimum=0.000, Maximum=26.000, Mean=10.115, StdDev=5.072
>   NoData Value=-3.4028230607370965e+038
>
> I'm running GDAL 1.11.0, although I've also experienced the same behavior
> on gdalinfo with 1.9.0. I'm using QGIS 2.4 which is built against GDAL 1.9.
>
> Any ideas what's going on and how to handle it?
>
> --
> Richard P. Sharp Jr.
> Lead Software Architect
> Natural Capital Project
> Stanford University, U Minnesota, TNC, WWF
> 371 Serra Mall
> Stanford, CA 94305
> http://www.stanford.edu/~rpsharp/

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: why do I get a floating point nodata value from a byte raster?

Richard Sharp
On Fri, Aug 29, 2014 at 10:34 AM, Even Rouault <[hidden email]> wrote:
Le jeudi 28 août 2014 23:32:38, Richard Sharp a écrit :
> I have a byte GTiff dataset that has a nodata value of 0 according to QGIS.

Well, I've just created such a file, and with QGIS 1.8, the GUI display well
the -3.4028230607370965e+38 value, but with 2.4, it displays 0. So seems to be
on QGIS side.
That said,  -3.4028230607370965e+38 doesn't make sense as a nodata value for
Byte, which can only range from 0 to 255.
After some testing, it seems that QGIS displays 0 when the nodata value is out
of the range of the data type.


Thanks Evan.  Just so I'm clear, you're saying that the raster had its nodata value set to something that exceeded its datatype range.  In that case, it doesn't make sense to interpret the  -3.4028230607370965e+38 as "0" in the byte range, but rather as a nodata value defined for the valid pixels in the raster?
 

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: why do I get a floating point nodata value from a byte raster?

Even Rouault-2
Selon Richard Sharp <[hidden email]>:

> On Fri, Aug 29, 2014 at 10:34 AM, Even Rouault <[hidden email]>
> wrote:
>
> > Le jeudi 28 août 2014 23:32:38, Richard Sharp a écrit :
> > > I have a byte GTiff dataset that has a nodata value of 0 according to
> > QGIS.
> >
> > Well, I've just created such a file, and with QGIS 1.8, the GUI display
> > well
> > the -3.4028230607370965e+38 value, but with 2.4, it displays 0. So seems
> > to be
> > on QGIS side.
> > That said,  -3.4028230607370965e+38 doesn't make sense as a nodata value
> > for
> > Byte, which can only range from 0 to 255.
> > After some testing, it seems that QGIS displays 0 when the nodata value is
> > out
> > of the range of the data type.
> >
> >
> Thanks Evan.  Just so I'm clear, you're saying that the raster had its
> nodata value set to something that exceeded its datatype range.

Yes.

  In that
> case, it doesn't make sense to interpret the  -3.4028230607370965e+38 as
> "0" in the byte range,

Yes, QGIS should ignore the nodata value, as if there was nodata reported

> but rather as a nodata value defined for the valid
> pixels in the raster?

I've not verified if it actually takes 0 as a nodata value, but if it does, yes
that's unexpected.

>


--
Spatialys - Geospatial professional services
http://www.spatialys.com

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev