Re: space products

• To: HansPeter Roesli <satmet.hp@xxxxxxxxxx>
• Subject: Re: space products
• From: Don Murray <dmurray@xxxxxxxxxxxxxxxx>
• Date: Fri, 17 Nov 2006 07:31:19 -0700

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