space products
Robb Kambic
rkambic at unidata.ucar.edu
Tue Dec 5 09:11:50 MST 2006
Simon,
Do you have newer documentation? Because both the NCEP and EUMETSAT docs
for template 4.3 have bytes 23-34 designated for 1st and 2nd fixed
surfaces. I understand that these values are probably not used in space
products.
robb...
On Tue, 5 Dec 2006, Simon Elliott wrote:
> Hello Robb,
>
> I am glad you are getting further with decoding the data.
>
> >From your question about the first and second surface types I get the
> impression
> you are using Product Definition Template 4.0 to interpret the data.
> In fact, when
> you detected "Product Definition : 30 Satellite product", this should
> trigger you to
> use Product Definition Template 4.30 to interpret Section 4. There you
> will find
> that there are no references to first and second surfaces, but rather
> other information
> describing the satellite data.
>
> You mention that you have never seen a model using these values, but I
> guess this
> is a simple misunderstanding, as we do not generate these values in any
> case.
>
> I hope this helps.
>
> Regards,
>
> Simon
>
> >>> Robb Kambic <rkambic at laraine.unidata.ucar.edu> 04/12/2006 18:54:38
> >>>
> On Fri, 17 Nov 2006, Simon Elliott wrote:
>
> > Hi all,
> >
> > 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.
>
> Hi Simon,
>
> First, let me thank you for your time. There's no problem decoding the
> (HP GRIB.001) file with my decoder that is 803521 bytes long. The
> file
> that was originally sent was not 803521 bytes, but 804420 bytes long.
> When the file was edited, the editor inserted extra bytes into the
> file. This caused the decoder to get confused and it could not extract
> the
> data. As you know the GRIB format is very rigid, so one extra byte can
> change the course of action of the decoder. There was some confusion
> about
> the acquistion of the file and I was unawared that the file was edited,
> so
> I assumed that there was some EUMETSAT changes in the file. Since the
> EUMETSAT datasets are very important to our community, I made an
> effort to decode the file with the extra bytes. When debugging, I
> added
> some code to accomodate the extra bytes but the decoder still got
> confused
> about the data extraction process. When I got an uncorrupted file, my
> decoder work without a problem.
>
>
> There is one question, the level information is using level 0, is that
> correct?
>
> First Surface Type : 0 Reserved
> First Surface value : 0.0
> Second Surface Type : 0 Reserved
> Second Surface value : 0.0
>
> I have never run across a model using these values before, can you
> give
> some insight?
>
> Thanks,
> Robb...
>
> Here's a dump of the Header information of the file, is there an
> problem
> here?
>
> --------------------------------------------------------------------
> Header : GRIB2
> Discipline : 3 Space products
> GRIB Edition : 2
> GRIB length : 803521
> Originating Center : 254 EUMETSAT Operation Centre
> Originating Sub-Center : 0
> Significance of Reference Time : 3 Observation time
> Reference Time : 2006-01-02T11:45:00Z
> Product Status : 1 Operational test products
> Product Type : 6 Processed satellite observations
> Number of data points : 1530169
> Grid Name : 90 Space View Perspective or
> Orthographic
> Grid Shape: 3 Earth oblate spheroid with axes
> specified by
> producer
> Oblate earth major axis: 6378.14
> Oblate earth minor axis: 6356.7554
> Number of points along parallel: 1237
> Number of points along meridian: 1237
> Latitude of sub-satellite point: 0.0
> Longitude of sub-satellite pt: 0.0
> Resolution & Component flags : 0
> i direction increment : 1188.0
> j direction increment : 1187.0
> X-coordinate of sub-satellite : 619.0
> Y-coordinate of sub-satellite : 619.0
> Scanning mode : 192
> Basic angle : 0
> Altitude of the camera : 7.4533146E8
> X-coordinate of origin : 0.0
> Y-coordinate of origin : 0.0
> Product Definition : 30 Satellite product
> Parameter Category : 1 Quantitative_products
> Parameter Name : 2 Cloud_Top_Height
> Parameter Units : m
> Generating Process Type : 8 Observation
> ForecastTime : 0
> First Surface Type : 0 Reserved
> First Surface value : 0.0
> Second Surface Type : 0 Reserved
> Second Surface value : 0.0
> --------------------------------------------------------------------
> Header : GRIB2
> Discipline : 3 Space products
> GRIB Edition : 2
> GRIB length : 803521
> Originating Center : 254 EUMETSAT Operation Centre
> Originating Sub-Center : 0
> Significance of Reference Time : 3 Observation time
> Reference Time : 2006-01-02T11:45:00Z
> Product Status : 1 Operational test products
> Product Type : 6 Processed satellite observations
> Number of data points : 1530169
> Grid Name : 90 Space View Perspective or
> Orthographic
> Grid Shape: 3 Earth oblate spheroid with axes
> specified by
> producer
> Oblate earth major axis: 6378.14
> Oblate earth minor axis: 6356.7554
> Number of points along parallel: 1237
> Number of points along meridian: 1237
> Latitude of sub-satellite point: 0.0
> Longitude of sub-satellite pt: 0.0
> Resolution & Component flags : 0
> i direction increment : 1188.0
> j direction increment : 1187.0
> X-coordinate of sub-satellite : 619.0
> Y-coordinate of sub-satellite : 619.0
> Scanning mode : 192
> Basic angle : 0
> Altitude of the camera : 7.4533146E8
> X-coordinate of origin : 0.0
> Y-coordinate of origin : 0.0
> Product Definition : 30 Satellite product
> Parameter Category : 1 Quantitative_products
> Parameter Name : 3 Cloud_Top_Height_Quality_Indicator
> Parameter Units :
> Generating Process Type : 8 Observation
> ForecastTime : 0
> First Surface Type : 0 Reserved
> First Surface value : 0.0
> Second Surface Type : 0 Reserved
> Second Surface value : 0.0
>
>
> >
> > 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.
> >
> > Simon
> >
> > Dr Simon Elliott
> > Product Implementation Manager
> > Operations Department
> > EUMETSAT
> > tel: (+49) 6151 807385
> > fax: (+49) 6151 807304
> >
> >
==============================================================================
Robb Kambic Unidata Program Center
Software Engineer III Univ. Corp for Atmospheric Research
rkambic at unidata.ucar.edu WWW: http://www.unidata.ucar.edu/
==============================================================================
More information about the decoders
mailing list