[gdal-dev] gdalinfo -mm also report n (number of grid cells that are not nodata)

Markus Metz markus.metz.giswork at gmail.com
Thu Jun 14 13:48:23 PDT 2018


On Wed, Jun 13, 2018 at 11:03 PM, Even Rouault <even.rouault at spatialys.com>
wrote:
>
> On mercredi 13 juin 2018 22:14:07 CEST Markus Metz wrote:
> > Many raster bands contain nodata, therefore it would be helpful if the
> > number of non-nodata grid cells could be reported by gdalinfo in some
way.
> >
> > The number of non-nodata grid cells is not available through
> > GDALGetRasterStatistics() / GDALRasterBand::GetStatistics(), probably
> > because approximations can be stored as raster band statistics, and the
> > number of non-nodata grid cells is unknown in case of approximations.
> >
> > Therefore I suggest to report the number of non-nodata grid cells only
if
> > all grid cells are evaluated, i.e. with
> >
> > *gdalinfo -mm* Force computation of the actual min/max values for each
band
> > in the dataset.
> >
> > The number of non-nodata grid cells would be a small piece of quite
useful
> > information to quickly evaluate the usefulness of a raster band.
> >
> > Asking for the possibility to enhance a bit the output of gdalinfo,
>
> Markus,
>
> That would be more something triggered by -stats since this number of non-
> nondata cells is an intermediate result of
GDALRasterBand::ComputeStatistics()
> in gcore/gdalrasterband.cpp. To make it sensical even in the case of
> approximate statistics, why not computing a percentage instead ? That
would
> need to be saved in a metadata item, let's say STATISTICS_VALID_RATIO
(between
> 0 and 1) ?

Considering approximate statistics, something like STATISTICS_VALID_RATIO
would make sense.

However, I am not interested in approximate statistics, therefore my
suggestion to tie it to -mm.

> Wanna take a crack at implementing this ?

Too many API changes required, starting with GDALGetRasterStatistics(),
GDALComputeRasterStatistics() and all else following. There must be an
easier solution. But thanks for your offer:-)

My workaround is to use GRASS r.external to get correct raster band
statistics.

> Otherwise file an
> enhancement ticket about that.
> By the way, since GDAL 2.3.0, there's a STATISTICS_APPROXIMATE=YES
metadata
> item so as to know if the stats have been computed in an approx way or not

Enhancement request: set STATISTICS_APPROXIMATE=UNKNOWN if it is unknown. I
checked with some externally provided sample data and GDAL 2.3.0 does not
report STATISTICS_APPROXIMATE.

I understand that GDAL has to cater for approximate statistics and should
not override metadata provided with raster bands created by other software.
It would help if STATISTICS_APPROXIMATE is always set to NO|YES|UNKNOWN.

Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20180614/551539ce/attachment.html>


More information about the gdal-dev mailing list