[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: space products

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: space products
  • Date: Fri, 17 Nov 2006 08:40:53 -0700
Hi Simon-

Simon Elliott wrote:

WHen I look at the file attached by HansPeter (HP GRIB.001) it looks
fine to me.  The GRIB part can be found after the first 899 bytes.  The
remaining part (GRIB to 7777, inclusive) is 803521 bytes long, which is
as indicated in octets 9 to 16 of Section 0.


I'll work with Robb on this next week.  I think he made some
changes to skip the header, but I don't have access to his
changes so it still fails in what I have.


The users who have been looking at the data have received it via
EUMETCast, and also via ftp from me.  Maybe some got data from the
UMARF, but I don't get to hear about them.  I think that as long as a
decoder looks through a file and pulls out GRIB (or BUFR) messages
before decoding, then it doesn't matter how they are packed into files.


I agree in principle.  It's fine if you are passing a file
to a decoder and are assured that the decoder is a GRIB decoder
and that the user says that there is a GRIB message in the
file.  However, in our case, we have a top level data handler
that has to determine which decoder to pass it to. This
top level handler can open netCDF files, GRIB1, GRIB2, OPeNDAP
remote URLs, etc.  So, it has to make some determination at the
start about what is in the particular file.  Usually, it does
this by looking at the first few bytes of a file.  For a netCDF
file, it looks for the netCDF header, for a GRIB file, it looks
for GRIB1 or GRIB2. The question is how far into the file do you
look before giving up?  Also, should a decoder have to handle both
GRIB and BUFR in the same file?

Anyway, we'll wait for Robb's return and work on this more at
that time.

Thanks for your help and input.

Don
*************************************************************
Don Murray                               UCAR Unidata Program
address@hidden                        P.O. Box 3000
(303) 497-8628                              Boulder, CO 80307
http://www.unidata.ucar.edu/staff/donm
*************************************************************