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

Re: 20040324: LDM6.0.14 pqact.conf question

Josh,

Run "pqing -f HDS  ....etc...."
That will retype all products with SDUS[2357] to feedtype NNEXRAD
and add the PIL (eg N0Rccc, etc) to the WMO identifier so that
the LDM identifier will look like:
SDUS[2357]. CCCC DDHHNN /pNxxxxx

The pil identifiers are only created when the feedtype on the command 
line is a subset of the WMO feedtype (eg DDS, PPS, IDS, HDS, DDPLUS,
etc). The NIDS products are rettyped to feedtype NNEXRAD automatically. 

Steve Chiswell


On Wed, 2004-03-24 at 13:15, Josh Sholes wrote:
> Steve,
> I am my own source for the data. *grin*  The data ingestor machine is reading 
> data from the NOAAPort satellite stream using the pqing utility on a named 
> pipe, then sending it via LDM to the (much beefier, processor-wise) decoder 
> machine.  Can you give me any information on how to configure pqing/LDM on 
> the ingestor to add the /pPILs?
> 
> Thanks for the help so far.
> 
> --Josh
> 
> On Wednesday 24 March 2004 14:55, you wrote:
> > Josh,
> >
> > The Unidata NEXRAD data stream has LDM product identifiers with the
> > /pPILs following the WMO identifier. This is done by the IDD ingestion
> > software to identify the different NEXRAD products that use the same WMO id
> > to transmit different products.
> >
> > Your source for the data is apparently not providing a product identifier
> > that adds the PIL, so the examples you find showing its use will not
> > be valid for your application. You either need to have that done at the
> > ingestion point, or pipe your products to a program which can access the
> > PIL line of the Level III radar product for file name identification.
> >
> > Steve Chiswell
> > Unidata User SUpport
> >
> > On Wed, 24 Mar 2004, Josh Sholes wrote:
> > > Recently, my site was attempting to configure LDM to get data for the
> > > GEMPAK decoder package.
> > > We added the lines from the examples, specifically:
> > >
> > > ANY       ^SDUS[2357]. .... 
> > > ([0-3][0-9])([0-2][0-9])([0-6][0-9]).*/p(...)(...)
> > >   FILE    -close  data/gempak/nexrad/NIDS/\5/\4/\4_(\1:yyyy)(\1:mm)\1_\2\3
> > >
> > > to the pqact.conf file, and got no data at all in the appropriate
> > > directories. Amending the lines to
> > >
> > > ANY       ^SDUS[2357]. .... ([0-3][0-9])([0-2][0-9])([0-6][0-9])
> > >   FILE    -close  data/gempak/nexrad/NIDS/(\1:yyyy)(\1:mm)\1_\2\3
> > >
> > > got lots of radar data, but not seperated in the way GEMPAK expects. 
> > > Since then, we have noticed that none of our pqact.conf lines which
> > > include the "/p" construction (which, if I'm not mistaken, is supposed to
> > > tell pqact to jump down and start reading the second line of the header)
> > > seem to work at all.  Is this a known problem, a change in syntax from
> > > when the examples were written, or what?
> > >
> > > Thanks for any help you can give.
> > >
> > > --
> > > Josh Sholes
> > > ZedX Inc.
> > > address@hidden