[gdal-dev] GDAL processing of GRIB2 raster prints hundreds of unsuppressable warnings

[Andrew C Aitchison]

On Fri, 7 Sep 2018, Thomas Horner wrote:

> Hello,
>
> I am processing some GRIB2 raster files from NCEP (weather model stuff). An
> example file would be:
> http://nomads.ncep.noaa.gov/pub/data/nccf/com/hiresw/prod/href.20180907/ensprod/href.t00z.conus.mean.f06.grib2
>
> When I use various GDAL tools to process the file it prints this line for
> each of the dozens of bands in the raster:
>
> Warning: Master table version == 0, was experimental
> I don't have a copy, and don't know where to get oneUse meta data at
> your own risk
>
> Ok, that warning is fine -- but it's a major problem when I process the
> file with raster2pgsql as it dumps that message dozens of times into the
> SQL, which causes an error when I attempt to load it into the db.
> Using gdalwarp
> -q or gdal_translate -q still prints the message hundreds of times despite
> being in quiet mode which makes my log files nearly unreadable as I am
> processing hundreds of these GRIB files.
>
> The piece of GDAL code responsible for this is:
> https://github.com/OSGeo/gdal/blob/master/gdal/frmts/grib/degrib/degrib/metaparse.cpp
>
> I assume NOAA/NCEP will not be fixing their GRIB files any time soon (they
> are a very understaffed federal agency) so what can I do on my end to
> suppress these warnings?  Can this message be fixed or able to be
> suppressed?

I don't know whether that code is resynced with anyone outside gdal,
in which case this suggestion might be a problem ...

I would replace the printf() calls with calls to CPLDebug(), as used in 
degrib1.cpp in the same folder (you need to add an extra argument - 
probably "GRIB").
That way the messages would be suppressed, unless CPL_DEBUG is set appropriately,
and when enabled will appear in the appropriate place in gui applications 
like qgis.

I'd also be tempted to have a counter to control how often the 
message is seen (perhaps every time the counter is a power of two).

> At best, this is annoying and slow -- at worst, it creates significantly
> extra overhead in my processing chain to keep this from breaking my output
> datasets.

-- 
Andrew C. Aitchison					Cambridge, UK
 			andrew at aitchison.me.uk