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

Re: [Fwd: NOAAport ingester] (fwd)


===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================

---------- Forwarded message ----------
Date: Wed, 08 Nov 2000 08:31:56 -0700
From: Russ Rew <address@hidden>
To: Robb Kambic <address@hidden>
Subject: Re: [Fwd: NOAAport ingester] (fwd) 

Robb,

> I also thought about modifying pqing to extract the radar products as a
> separate feed type.  In my opinion it's a short term kuldge because what
> about the other feed types in the NWSTG stream, (NGRAPH, NOTHER, and
> NPOINT). Are we going to modify pqing to make them into separate feed
> types too?  If we add the stream specfic information into pqing then it's
> going to be dependant on any changes to the NWSTG stream. This is the same
> type of problem as with pqsurf, it stream dependant.  ...

You may be right, but pqing already handles lots of feed-type specific
details so other programs don't have to.  For example, pqing contains
code for FAA604, AFOS, and WMO messages, HDS-specific code for
checksums, extraction of PIL-like identifiers, extraction of GRIB
model numbers, etc.  I consider pqing to be a place to encapsulate
feed-specific details, so it seems like a good place to deal with
NOAAport-specific information.

However, currently the SSEC SDI software doesn't pass on the NOAAport
category byte (NGRAPH, NIMAGE, NTEXT, NGRID, NOTHER, ...) to pqing, so
pqing would have to be able to figure that out.  Also, there is no
NOAAport category for NEXRAD data, it's currently all classified as
"text" products, even though the zip-compressed products are just
binary.

>                                                  ...  I believe if we
> offer this option, then SSEC will take it.  Then we are back to creating
> intermediate solutions.  I would somehow stress that it is better to parse
> the 20 byte NOAAport header into the correct feed types. ...

Unfortunately, the only way to tell that a NOAAport product is NEXRAD
data is to look at its WMO header to see if it starts with 'SDUS5'.
Whether this should be done by the SDI software or by pqing is the
question.  pqing is already looking at and adding to WMO headers,
whereas the SDI software is just trying to determine if the products
are text or binary by looking at the data.  It seems like we would be
asking the SSEC programmers to make a bigger change to the SDI
software to look at WMO headers to classify products than making the
change to pqing, whose job is to separate and classify products.

>                                                      ... Also, I thought
> that UPC was willing to give our NOAAport card solution to SSEC for free. 
> Then SSEC would be able to market it as their own solution.  It seems to
> me there is already a solution to the NNEXRAD feed type, but the
> implementation of the solution is the hard part.  This is where we need to
> get Ben's imput.

I think you're right that we are willing to give our NOAAport card to
the SSEC for free.  But they are also supporting the system for other
customers besides us, and they may not want to support two
configurations, one with our card and one with theirs.  I'm not sure
we could convince them to throw out their solution and use ours for
all their NOAAport systems.

> I going to write Dan Vieter to see how Unisys plans on distributing the
> Radar products.  

Great, I'd be interested in hearing about Unisys plans.

Also, I wonder if we can convince NWS to tag the compressed NEXRAD
products as something other than "text"?

--Russ