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

Re: space products

Hi All-

Robb's out until next week, so I'll chime in.  I'm guessing that
the processing that HP did is adding in the extra chars.  The
problem that our GRIB decoder has with the "raw" products is that
it doesn't skip over the header.  We do that for the products that
we receive in our IDD streams, but it only checks for a header less
than 40k.  I've asked Robb about increasing that to read in the
EUMETCAST files.  When he returns next week, I'll discuss this
with him more.

Thanks for you all your help in tracking down this problem.

Don

HansPeter Roesli wrote:

Hi Simon and Robb
After having read Simon's first reaction I got a slight doubt about what I did. Actually, the file Robb is mentioning is not the original file as retrieved from EUMETSAT's archive U-MARF (you find that now attached). The original file is refused right away by IDV. Therefore, I chopped off the ASCII header with an editor and that is the file Robb is using. Might be that my editor changed things inside the GRIB-7777 clause when I was pruning the file. So, Robb please check again with the attached file which has leading bytes (EUMETSAT's ASCII header) before the bytes spelling GRIB.
Also, Simon, when you are saying that other centres are not having decoding problems, are they getting the data from EUMETCast/GTS or from U-MARF. I am using exclusively U-MARF retrieved products. Might be there is a problem with archived data? 

HP

Simon Elliott wrote:

Hello Robb,

HansPeter has asked me to contact you directly as I am responsible for
the generation of the GRIB2 data from EUMETSAT.  I am interested to read
about the extra characters you found inside hte message.  As I'm sure
you can imagine, we have exchanged the data with other centres using
different software and they have yet to spot this problem.

I suspect either (i) the GRIB data have been chopped up for
dissemination and not been properly re-assembled into the original
message, or (ii) at some stage the data have been transferred with ASCII
FTP ... this happens quite often.

If you could send me the file you mention, or make it availabel for FTP
transfer, I would be happy to investigate.

Regards,

Simon

Dr Simon Elliott
Product Implementation Manager
Operations Department
EUMETSAT
tel: (+49) 6151 807385
fax: (+49) 6151 807304



Robb Kambic <address@hidden> 14/11/2006 22:50:35 >>>

HansPeter,

i investigated the problem with Grib2 decoder not being able to decode
the
space products, ie
MSG1-SEVI-MSGCLTH-0100-0100-20060102114500.000000000Z-12774_GRIB.grb

at first it seemed to be a table problem but that's not the case.
the products do not follow the standard Grib encoding, there are
extra characters inserted between the Grib format sections that's the
problem. i had the same problem with the Grib 1 format from some of
the
european centers. i tried the Grib 1 format fix then the decoder was
able to
decode the first 5 sections of the product but then the 6th section
didn't begin at the correct position. at this time, i could some help
in
finding out the format of the product, so i can modify the decoder. i
did a
quick look for the product information but was unable to get the
information
i needed. Could you contact the data provider to get the structure of
the
product?  or get a contact person for this product?

thanks,
robb...







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