20010530: 20010529: LDM/IDD: /p and /m portions of headers

Tom,
Back in the FOS feed days, there were 4 separate data streams:
PPS, DDS, IDS, and HDS. DDPLUS is a nemonic for DDS and PPS.

NOAAPORT has no way to separate what is international data, akin to IDS,
and what is domestic data. So, the NWSTG data feed on the IDD is
simply split in to DDPLUS|IDS and HDS. This is essentially
text and non-text from the nwstg channel.

The WMO nemonic is PPS and DDS and IDS and HDS.

So, if you use WMO in your pattern action file, you will effectively
be matching DDPLUS|IDS|HDS. As long as you don't want to exclude
certain HDS that might match the pattern also, you are safe in using WMO.

Steve Chiswell
Unidata User Support







>From: "Thomas L. Mote" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200105310135.f4V1Z4p26394

>
>Steve:
>
>Thanks for the information and for helping us get our 
>NOAAport feed properly running into the LDM. As I said, 
>this will help us switch back and forth between the IDD and 
>NOAAport as needed. It would also allow us to feed other 
>sites if needed, or at least serve as a backup feed. 
>
>I do have one other question. On my IDD feed (from FSU), I 
>see that most NWSTG products come across as IDS|DDPLUS. 
>What is the advantage of this? If I use "WMO" to match in 
>my pqact, I believe I am supposed to get both IDS and 
>DDPLUS. (If I have read my LDM manual correctly.) 
>
>I'm guessing this is designed so that anyone matching ONLY 
>IDS or ONLY DDPLUS would still get all of these products. 
>Is this (wild speculation) correct?
>
>Tom
>
>
>
>> > > >--- Begin Forwarded Message ---
>> > > >Date: Tue, 29 May 2001 15:32:54 -0600
>> > > >From: Unidata Support <address@hidden>
>> > > >Subject: 20010529: LDM/IDD: /p and /m portions of headers
>> > > >Sender: Unidata Support <address@hidden>
>> > > >To: "Thomas L. Mote" <address@hidden>
>> > > >Cc: address@hidden
>> > > >Reply-To: Unidata Support <address@hidden>
>> > > >Message-ID: <address@hidden>
>> > > >
>> > > >
>> > > >
>> > > >Tom,
>> > > >
>> > > >The /p and /m strings were added to the IDD product identifiers to
>> > > > help distinguish between products which otherwise have identical WMO
>> > > > headers. The characters are literal, eg not escape characters.
>> > > >
>> > > >The PIL identifier exists in most US NWS bulletins and is ontained
>> > > > from the line following the WMO identifier. That is, for NWS
>> > > > bulletins having the form:
>> > > >
>> > > >TTAAII CCCC DDHHNN
>> > > >NNNXXX
>> > > >
>> > > >The ingest code in pging/wmo_header.c will determine if the line
>> > > > following the WMO fits the required format of a PIL, which is 6
>> > > > characters (space padded to 6 if less), and not all numberic. If the
>> > > > criteria is met, the /pNNNXXX is added to the LDM product identifier.
>> > > >
>> > > >One example of the utility of using the PIL identifiers are the NEXRAD
>> > > > products which do not have unique WMO identifiers, eg:
>> > > >
>> > > >SDUS55 KBOU 291200 /pFTGN0R
>> > > >SDUS55 KBOU 291200 /pFTGN0V
>> > > >SDUS55 KBOU 291200 /pFTGN0S
>> > > >SDUS55 KBOU 291200 /pFTGVIL
>> > > >
>> > > >Using the PIL allows 2 things"
>> > > >1) you can identify whether the product is a base reflectivity (N0R),
>> > > > velocity (N0V) etc. 2) Some NWS offices have more than 1 RADAR that
>> > > > they dissiminate. In those cases, the CCCC identifier is the same,
>> > > > but the NNN identifies the actual radar. For example SDUS52 KBHM
>> > > > 291200 /pBHXN0R SDUS52 KBHM 291200 /pEHXN0R
>> > > >
>> > > >When trying to identify PILS,
>> > > >SAUS80 KWBC 291200
>> > > >METAR^M
>> > > >......
>> > > >
>> > > >SAUS43 KCYS 291200
>> > > >MTRLND^M
>> > > >
>> > > >WWUS01 KMKC 291200
>> > > >WWANC ^M
>> > > >
>> > > >The word METAR following the SAUS80 line is not a PIL. The carriage
>> > > > return is the 6th character on the line, so the line is not space
>> > > > padded to 6 characters. the MTRLND and WWANC are PILS since they are
>> > > > 6 character lines, and not all numeric.
>> > > >
>> > > >For GRIB data, (now most models have migrated to KWBx from all using
>> > > > KWBC, where each model has a unique code in the KWBx, eg RUC is KWBG,
>> > > > ETA is KWBE), the WMO is generally not unique. The model ID is
>> > > > obtained from the PDS block of the grib using the model center and
>> > > > model ID. The ETA84 tag is created by determining that the bulletiin
>> > > > contains a GRIB message, then finding that the model center is "7"
>> > > > which is NCEP, and the model id is "84" which is the ETA model. The
>> > > > /mETA84 identifies the model uniquely from other versions of the ETA,
>> > > > such as ETA89 or ETA85, and RUC105 versus RUC86.
>> > > >
>> > > >The NCEP model numbers are assigned to different modele, eg RUC is 86,
>> > > > but RUC2 is 105. 84 is now the ETA since all 4 runs are the same
>> > > > model. Previously, when 2 different ETA models were run, eg Early and
>> > > > MESO, 2 different numbers existed.
>> > > >
>> > > >The idea of the /p and /m chacaters is just to add additional
>> > > > information to the LDM product identifier. The actual data  carried
>> > > > by the LDM is not changed in any way.
>> > > >
>> > > >Steve Chiswell
>> > > >Unidata User Support
>> > > >
>> > > >>From: "Thomas L. Mote" <address@hidden>
>> > > >>Organization: UCAR/Unidata
>> > > >>Keywords: 200105291642.f4TGggp09905
>> > > >>
>> > > >>
>> > > >>Robb?
>> > > >>
>> > > >>We just installed a new 3-channel NOAAPort system (PlanetaryData) and
>> > > >>are feeding from it to our LDM box. We have an existing
>> > > >>single-channel system from the same vendor. We bypass the LDM
>> > > >>itself for GINI products, but we feed through the LDM (using a
>> > > >>utility the company provided called pqpdinrs) for other products.
>> > > >>
>> > > >>I started noticing how my pqact.conf file was set up with a "/p"
>> > > >>before the PIL portion of the header (e.g., "/pN0RFFC"). I noticed
>> > > >
>> > > >the "/p" doesn't actually come across NOAAPort. It was simple enough
>> > > >
>> > > >>to change PDI's configuration file to add a "/p" before the PIL.
>> > > >>Where does this come from in the IDD? It appears it is just plain
>> > > >>ASCII text and does not represent and special character.
>> > > >>
>> > > >>Now I want to feed across the GRIB products the same way. I notice
>> > > >>many of them have a PIL-like "/mETA84" or similar. This does not
>> > > >>appear to come from NOAAport. Where does the /m come from? How does
>> > > >>the "ETA84" or similar get added? I am trying to figure out how I can
>> > > >>recreate this. I would like to be able to seamlessly switch between
>> > > >>the IDD and NOAAport as needed, and I certainly don't want to have to
>> > > >>create two different pqact.conf files or put it the WMO headers
>> > > >>for every model.
>> > > >>
>> > > >>I posed some of these questions to the support people at
>> > > >>PlanetaryData. They didn't know the answers and thought it would be
>> > > >>more appropriate for me to contact Unidata support.
>> > > >>
>> > > >>Some of the questions that came up in our discussions were...
>> > > >>
>> > > >>Is there a document or web site that spells out all the possible IDD
>> > > >>value added information and what is expected in that information?
>> > > >>For example, "/m" apparently is used to signify model generation id
>> > > >>applied names - such as ETA, NGM, etc.  What model generation id's
>> > > >>are matched with what strings for consistency? (i.e. - are all model
>> > > >>generation ids #84 and #89 called ETA)?  What is the "/o" and any
>> > > >>other value add codes and what should follow them?  Finally, are the
>> > > >>"/*" codes always literal, as the "/p" appears to be, or do they have
>> > > >>non-ASCII representations at times.
>> > > >>
>> > > >>Sorry for all the "slashing" questions. ;-)
>> > > >>
>> > > >>Tom
>> > > >>
>> > > >>
>> > > >>**********************************************************
>> > > >>Thomas L. Mote                               address@hidden
>> > > >>Associate Professor of Geography         ph:  706-542-2906
>> > > >>University of Georgia                    lab: 706-542-6060
>> > > >>Athens, GA 30602-2502 USA                fax: 706-542-2388
>> > > >
>> > > >**********************************************************************
>> > > >**** ** < Unidata User Support                                    UCAR
>> > > > Unidata Program < (303)497-8644
>> > > > P.O. Box 3000 < address@hidden
>> > > > ---------------------------------------------------------------------
>> > > >---- --- < Unidata WWW Service
>> > > > *********************************************************************
>
>