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

20000217: Bad Year of Century and Lov in NH composite product

>From: Unidata User Support <address@hidden>
>Organization: Unidata Program Center
>Keywords: 200002031940.MAA04384 GINI product header

Hi Barb,

First of all, many thanks for initiating the action that led to the fix
of the lon2 values in the GINI Puerto Rico and Hawaii MERCator projection
products.

Even though the multi-satellite composite products (sector ID 10) are
not part of the NOAAPORT channel 1 or 2 streams (and so are not
considered operational?), they are in channel 4 and so are available
to folks with 4 channel receivers.  In finishing off my McIDAS GINI
ADDE servers, I have occasion to look closely at this product and have
found a couple problems with values in their headers:

o the "Year of Century" (octet 9) is currently being reported as
  0 (zero).  Since this is the 100th year of the 20th century, this
  number should be 100.  A change to 100 would match the Year of Century
  values that are being sent for all of the other GINI image products.

o the Lov value (octet values 28-30)

  "The orientation of the grid; i.e., the east longitude
  value of the meridian which is parallel to the y-axis (or columns
  of the grid) along which latitude increases as the y-coordinate
  increases. (Note: the orientation longitude may or may not appear
  within a particular grid.)",

  is being reported as 2492048.  The Interface Control Document (ICD)
  for AWIPS - National Environmental Satellite, Data, and Information
  Service (NESDIS) AA0130008 CH-2, August 1, 1999, p 27 table states
  that the reference longitude should be 105.0000W.  This means that
  Lov should be reported as 2550000 instead of 2492048.  Using 2550000
  instead of 2492048 results in navigation that matches visible
  landmarks in the image.

Hopefully, these bad values can be changed so that we can remove the
kludges that we have had to put in our software to get around them.

Thanks in advance for any help you can provide on this.

By the way, when we were in Long Beach you mentioned that you had no
way to look at the images after they had been sent though the
broadcast.  Even if you had an AWIPS installation, you would not be
able to see the sorts of things that we are finding.  The reason for
this is that the AWIPS code does not use the navigation parameters in
the GINI headers.  Rather, it finds out what the sector is and then
uses hard coded values.  To us, this approach is self limiting:  in
order for a satellite sector to change, an entirely new build of AWIPS
must be sent out, installed, and tested at at the forecast offices.  If
the AWIPS software used the header info.  new images could be included
in the datastream without having to jump through the redeployment hoops
that are currently needed.

Back to the point.  If you want to look at the GINI imagery from
time-to-time, I can provide you with access to my GINI ADDE servers
here in Boulder.  This, at least, would allow you to put up some images
in McIDAS and see how good or bad the product preparation is.  If you
are interested in this, please let me know so I can provide you with
the needed access information.

Tom Yoksas

>From address@hidden  Thu Feb 17 12:12:38 2000
>cc: address@hidden, address@hidden,
>        address@hidden
>Date: Thu, 17 Feb 2000 14:12:28 -0500
>Subject: Re: 20000217: Bad Year of Century and Lov in NH composite product

You are right.  While the AWIPS  equipment (fourth channel included) was
declared operational last March, the 4-satellite composite which is being
disseminated to users is not an operational product.  To boot, it is also
not being created by the GINI-2 system which is currently providing all
other satellite imagery found on the East and West AWIPS channels (1 & 2).
I'll forward your comments on to the government source for this product,
but can't promise any type of correction timeframe, although the developer
is generally very responsive to customers.

Despite the fact that the Satellite Services Division of SSD is responsible
for the design, operation, and maintenance of the system (GINI-2) which
provides the main geostationary inputs for AWIPS, virtually all system
requirements for this rehost came to us directly from NWS.   We went
through a very complex series of iterations to make the needed corrections
to both their ICD specifications and to the subsequent remaps themselves
for the rehost so that field users could both rely on the header
information out of the new system as well as accurately and precisely
navigate and register image loops.  Like yourself, we discovered that
neither situation was then currently the case, though presumabley that
would have been desireable.  We were under a very tight (year 2000 related)
deadline which could not let any development/deployment schedules slip, so
we made what progress we could to keep rolling.   Again, it is purely
within the domain of NWS to make the final call for their AWIPS systems
requirements, functionality, and operability.

We are supposed to be getting in several AWIPS workstations in the near
future (next month), some of which have already been installed downstairs.
We've been waiting for these a long time and I'm still not certain that
we'll be able to see all 4 channels.  Meanwhile, I'll speak to some of our
software and systems administration folks about your offer.  We here at
NESDIS certainly understand your desire to take out the remaining
"fudge-ware" from your own systems to correct for incoming errors and still
stay afloat.  I will aslo forward your comments onto the working groups who
are readying further NESDIS observational and predictive products which are
likely to come down either that fourth channel or the East and West
mainstays for AWIPS systems.

- Barb