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

20011105: Sort of related . . .

Stonie,

GEMPAK/N-AWIPS development continues to occur at NCEP,
so that is the avenue that I obtain new releases.

The note you refer to from our policy committee was drafted
in support of our community use of GEMPAK which continues to be
an important display and analysis tool for our users. In particular,
many of our users would continue to rely on GEMPAK even if development
at NCEP had ceased. If that were to happen, we would want to ensure that
our users could continue to obtain GEMPAK so long as it was useful
(eg, we would not want to lose that right).

Since NMAP is going to continue to be used to produce products
at the National Centers within the AWIPS framework, additional
development should occur as well.

As for the Redbook graphics, their use existed before NMAP was
able to create the product. NMAP is used to create certain of the products
that we see now. Some (such as TPC products) are not created by NMAP.
The driving factor there was to move away from the intergraph system which
produced many products on DIFAX (which is becoming obsolete).

I have had limited success with certain aspects of the FCM-S2-1994
documentation. In particular, I get to some "internal" map
specifications which are not documented. According to
the web page: http://205.156.54.206/software/index.html
Redbook decoding software will be under the auspices of NCEP, but
no further information tyhat I see.

I do not know of a VGF interface control document.

Steve Chiswell
Unidata User Support


On Sat, 3 Nov 2001, Stonie R. Cooper wrote:

> Steve,
>
> Back when we were getting the N-AWIPS source from NCEP, we stayed a little
> more in tune with the politics of who maintained what code.  In fact, it
> appeared for a while the General Kelley was trying to get Mary, et al, to get
> off of the N-AWIPS bandwagon altogether . . . and we saw a note from UNIDATA
> asking that the code be transferred to UNIDATA if NOAA stopped funding work,
> etc. etc.
>
> Since we have been getting N-AWIPS from UNIDATA . . . we know longer are
> really "in the know".
>
> And we have an issue (with NOAA), but before we go off and raise a lot of
> stink, we would like to make some lower level approaches to rectify the issue.
>
> Do you know who maintains the code base for the RBK segments of N-AWIPS?
>
> Our concern deals with the fact that almost all NOAAPort delivered RedBook
> messages are apparantly generated using GEMPAK.  It could be that the N-AWIPS
> RBK implementation was designed to replicate (exactly) some other system, but
> given that NOAA has just decided to make NMAP/NMAP2/GEMPAK part of AWIPS
> installations for drawing capabilities . . . it tends hint that the source is
> GEMPAK.  If I were to guess, I would claim that the RedBook NCEP/NOAA/HPC
> authors use NMAP to generate the products via VGF, then do a convert to the
> AWIPS style of RedBook via GEMPAK (like gpmap - setting color to "C" to get
> the AWIPS RedBook variety).  And that's why I am trying to chase down the
> maintainer of the RBK code.
>
> Declan is working the parallel research to this - to see if my above
> assumption is correct.
>
> This is definitely not a complaint of GEMPAK, UNIDATA, etc - but of NOAA; the
> problem lies in the broken format of the current RedBook implementation.  Of
> special note is the fact the FCM-S2-1994 documentation is not followed - and
> if it were, the resulting RedBook messages would give us nearly lossless
> convertability to VGF - preserving color, line types, mnemonics, etc.  The
> structure is present . . . but not properly utlized.
>
> Thanks in advance for any information . . . I see in the archives that
> Mullenax and possibly others had asked about format information of VGF.  I
> have looked at the code, and understand it relatively well, but I was
> wondering if you know of any formal ICD for VGF - that takes into account all
> possibilities.  Rather than just telling NOAA that they have something broken
> and it needs fixed, we're sorking up a GPL solution to fix it - if they would
> only implement it.
> --
> Stonie R. Cooper,
> Science Officer
> Planetary Data, Incorporated
> 3495 Liberty Road
> Villa Rica, Georgia  30180
> ph. (770) 456-0700; pg. (888) 974-5017; fx. (770) 459-0016
>