20010904: Possible Change to NCEP frontal position bulletins

Ed,

Thank you for clarifying the proposed changes.

In regards to my program in GEMPAK that is being used to create the images
for the AMS datastream pages, I can tell you:

1) My program does not currently use the strength indicator

2) Eliminating the indicator (your solution 1) will not affect the program.

At present, when my program finds the frontal type, eg COLD, WARM, TROF,
OCFNT, or STNRY, it then looks ahead until it finds the start of a numerical
sequence (eg latlon pair) and continues on looking for latlon pairs until
it hits something non numerical- eg another feature identifier of end of the
bulletin. So, the removal of any strength modifier will not have any adverse
effect. Also, to replace the group with XX as in your second solution would not
cause any problem so long as the  XX group does not use a number (letters "XX"
are fine) but since this does not add any information I would prefer solution
1.

I would rather not see solution 3, since it makes archived data confusing
so that the user would have to know that before a certain date, WK meant
something different than after the date.

The type of changes that would require rewriting the current program
in GEMPAK would be: altering the latlon pair format, changing the
feature types (such as HIGHS, LOWS, or any of the fronts/trof identifiers
listed above), or introducing any separator characters between features.


Steve Chiswell
Unidata User Support




On Wed, 5 Sep 2001, Edwin Danaher wrote:

>       The NWS NCEP Hydrometeorological Prediction Center (HPC) is considering
> a modification to the coding of fronts in the ASUS1 and FSUS2
> bulletins.  Specifically, we wish to delete the reference to frontal
> strength.
>
>       As part of a restructuring of some of our products, we would like to
> eliminate the frontal strength indicator from our graphical and text
> products.  As far as we can tell, these are little used.  This will have
> some ramifications for the coded text messages you are decoding to
> display fronts.
>
>       Currently, fronts are coded with a strength identifier as follows (WK
> is the identifier in this example):
>
>               COLD WK 46178 43177 42175 40172 38168 36165
>
>       There are several ways for us to proceed.  Three possibilities are
> outlined below:
>
> Proposal 1:
>
>       We could code the message without this strength identifier:
>               COLD 46178 43177 42175 40172 38168 36165
> This would be the cleanest solution from our perspective, but might
> require modification to some decoders.
>
> Proposal 2:
>
>       We could change the strength identifier to something else such as XX:
>               COLD XX 46178 43177 42175 40172 38168 36165
>       This would indicate that we no longer assign a strength to the front,
> but may pose less of a problem than proposal 1 to decoders that read but
> do not use this information.
>
> Proposal 3:
>       We could leave the coding as is with the understanding that we do not
> provide this information.  As a default, all fronts would be classified
> as WK. This assumes that the information contained in the frontal
> strength indicator is not being used but is expected to be there by the
> decoder.  The disadvantage is that some users may not be aware that this
> strength information is no longer being assigned.
>
>       What I would like from you is two pieces of information.  First, are
> you using the frontal strength, either on the analysis or prog
> messages?  Second, would proposals 1 or 2 break your decoders?  Our goal
> is to make this modification with as little impact on users as
> possible.  We don't have a timetable yet, but I would hope to have this
> change implemented by late Winter or Spring of 2002.
>
>       Any comments or suggestions would be welcome. I would like to hear from
> you by September 13 if possible so that we can beginning planning this
> modification.  You can respond via email or contact me by phone at (301)
> 763-8000 ext 7354.
>
> Ed Danaher
>
> Tom Yoksas wrote:
> >
> > >From:  Kathryn Ginger <address@hidden>
> > >Organization:  UCAR/DLESE
> > >Keywords:  200108312037.f7VKbKh01117 NOAAPORT front ASUS1 FSUS2 McIDAS
> >
> > Ed,
> >
> > Late last week I became aware of your message to the AMS regarding possible
> > format change to the NOAAPORT ASUS1 and FSUS2 bulletins:
> >
> >   >Date: Fri, 31 Aug 2001 15:15:59 -0400
> >   >From: "Edwin Danaher" <address@hidden>
> >   >Organization: NCEP/HPC  Development and Training Branch
> >   >To: address@hidden
> >   >Subject: Fronts on Datastreme Surface Charts - Possible Change to NCEP 
> > Messages
> >   >
> >   >     I understand that you use text files generated here at the NWS NCEP
> >   >Hydrometeorological Prediction Center to place fronts on the surface
> >   >analysis charts displayed as part of the Datastreme project.  I spoke
> >   >with someone about this sometime ago, but have unfortunately lost his
> >   >name.
> >   >
> >   >     We are considering a change in the coding of this product and would
> >   >like to discuss this with someone knowledgeable about your decoders so
> >   >that we can avoid breaking your code if possible. At your convenience,
> >   >could someone contact me at 301-763-8000 Ext 7354 or provide me with a
> >   >contact via email?
> >   >
> >   >     Thanks in advance.
> >   >
> >   >Ed Danaher
> >
> > The impact of changing the format of the frontal position bulletins
> > extends well beyond the Datastreme project.  The Unidata Program Center
> > of UCAR has included use of these bulletins in supported software for
> > several years.  Unidata packages that would be immediately impacted are
> > GEMPAK and McIDAS.  In addition, we believe that Unisys continues to
> > support use of these ASUS1 and FSUS2 bulletins in its WXP package.
> >
> > Some example displays showing use of the bulletins can be found in:
> >
> > Package       Example display
> > -------------+-------------------------------------
> > GEMPAK        http://www.unidata.ucar.edu/staff/chiz/gifs/sfc_fronts.gif
> > McIDAS        http://mcdemo.unidata.ucar.edu/images/GEFRONT.GIF
> > WXP           http://wxp.unisys.com/
> >
> > I believe that in all cases the use of the products is hardcoded into
> > applications.  Any change in format would necessarily require all of us
> > to make modifications to our respective distributions.
> >
> > Relevant contacts for each of the packages mentioned above are:
> >
> > Package       Contact
> > -------------+-------------------------------------
> > GEMPAK        Steve Chiswell <address@hidden>
> > McIDAS        Tom Yoksas <address@hidden>
> > WXP           Dan Vietor <address@hidden>
> >
> > It would be most valuable if you could provide us with any information
> > on proposed changes including the timeframe for the changes.
> >
> > Thanks in advance...
> >
> > Tom
> > --
> > +-----------------------------------------------------------------------------+
> > * Tom Yoksas                                             UCAR Unidata 
> > Program *
> > * (303) 497-8642 (last resort)                                  P.O. Box 
> > 3000 *
> > * address@hidden                                   Boulder, CO 80307 *
> > * Unidata WWW Service                             
> > http://www.unidata.ucar.edu/*
> > +-----------------------------------------------------------------------------+