20000314: LDM Y2k

Alan,

This was a Y2K bug in LDM5.0.8 in the pqact program. Updated binaries for pqact
were posted- and the bug is fixed in the LDM5.0.9 release. 
Here is the announcement:
http://www.unidata.ucar.edu/packages/ldm/y2k-fix.html

This is a bug with the :yy, however :yyyy will correctly producte the 4 digit 
year.

Steve Chiswell
Unidata User Support



>From: address@hidden
>Organization: .
>Keywords: 200003142059.NAA14993

>
>
>Things seem to be rolling right along.  I have data in what I think is the
>right place.  Here is an example of my pqact entries:
>
>ANY
>^NOAAPORT\.GOES.....\......\.TIG([EHPW])01\.KNES\.([0-3][0-9])([0-2][0-9][0
>-5][0-9])\.*
>     FILE
>/npraid/nawips/nawipsdata/nsat/GINI-\1/1km/VIS/VIS_(\2:yy)(\2:mm)\2_\3
>
>The \2:yy produces a 10 instead of 00.  Have I missed an update to correct
>this?
>
>
>
>
>
>Unidata Support <address@hidden> on 03/13/2000 03:44:22 PM
>                                                              
>                                                              
>                                                              
> To:      Alan Hall/NCDC                                      
>                                                              
> cc:      Unidata Support <address@hidden>   
>                                                              
>                                                              
>                                                              
> Subject: 20000310: GRIB identifiers                          
>                                                              
>
>
>
>
>
>
>
>
>>From: address@hidden
>>Organization: .
>>Keywords: 200003131922.MAA08549
>
>>
>>
>>
>>>The directory structure under $SAT is shown in the nsat section of the
>>tutorial.
>>>The  GOES8 and GOES9 are just convenience variable- not needed. GARP,
>NSAT
>>and
>>>in the next release NMAP, use the directory structure to classify the
>>products.
>>>The sat files can be either GINI from NOAAport or McIDAS area files. The
>>radar
>>>products can be either NIDS format from NOAAport or McIDAS area files.
>>>See: http://www.unidata.ucar.edu/packages/gempak/tutorial/nsat.html
>>
>>NSAT is confusing me a bit.  I understand the directory structure from the
>>nsat.html, but I'm not sure if the actual files get stored there or is it
>a
>>link?  I would be ok with entries in pqact.conf that put these files in
>>your specific directory struture (do you have any sample pqact entries?)
>>I'm also not sure what these scripts do and if I need to set them up since
>>I don't have area files.
>>
>>I know how busy you are, but would appreciate any more info you can
>>provide....
>>
>>Alan.
>>
>>
>>
>>
>
>Alan,
>
>Our AREA files come with names like AREA0120, AREA0121, etc. Those names
>don't
>tell the uses what is in them, so I have to rename them in to the $SAT
>directory struction. These can be either links, or files. Since we have
>McIDAS users as well, I just create links to the files to avoid storing
>duplicate
>sets of data- and I use the areaInfo program to read the area files and
>output
>the necessary file name info from the McIDAS data. You don't have to work
>about any
>of this. My intention of pointing you to the nsat page was to give you the
>basic directory heirachy that Garp and NSAT use to produce the sucession of
>menu entries in the GUI. When you pop up the browser, those GUIs use the
>GOES-8, GINI-E, SUPER-NATIONAL etc names to make a top level of widges to
>select what
>satellite. Then After selecting a widget, the GUI uses the resolution (1km,
>4km, 8km etc)
>subdirectory names under the sector name to provide the next level of menu.
>Finally
>the file/times are presented. Its just a directory structure to shorten the
>search through the available files.
>
>For the GINI data off the NOAAport feed, you can create pqact.conf entries
>to
>file the data directly into the $SAT structure (or Glenn Rutledge had
>mentioned
>using a script from COMET to do the same). In my NOAAport stream, I
>actually
>rename the products so that all the pieces needed in the file structure-
>eg the sector, resolution, band, platform are all in the LDM id...I know
>you
>don't have this.
>
>An example of filing the data directly from pqact.conf would look like:
>
>TIG([EW])01 KNES ([0-3][0-9])([0-2][0-9])([0-5][0-9])
>   FILE  data/gempak/images/sat/GINI-\1/1km/VIS/VIS_(\2:yy)(\2:mm)\2_\3\4
>TIGN01 KNES ([0-3][0-9])([0-2][0-9])([0-5][0-9])
>   FILE
>data/gempak/images/sat/SUPER-NATIONAL/8km/VIS/VIS_(\1:yy)(\1:mm)\1_\2\3
>
>In the above, the first line will capture the 01 (visible) images from
>the CONUS Goes East and GOES West and file them to the appropriate
>ditectory name. The ([EW]) allows the one line to work for both East and
>West.
>The second line is an example of the 8km supernational composite. Though,
>you could have a single line of ([A-Z]) etc for
>GINI-E, GINI-W, GINI-N, GINI-I etc....however, that forces the user to know
>that
>GINI-P is a Puerto Rico sector.
>
>Since the WMO type of names like TIGW01 don't really relate well to
>directory
>names, you just have to have a lot of pqact.conf entries for all the
>different
>combinations of the sector and band identifiers. You just have to copy and
>paste a lot in the pqact.conf file so that you have separate entries for
>01, 02, 03, 04, 05 for VIS, IR, IR12.0, IR3.9 and WV respectively
>as well as sector/resolution names.
>
>My products in the LDM look like:
>
>sat/ch2/GOES-10/WV/20000311 1045/WEST-CONUS/8km/ TIGW05 KNES 111045
>sat/ch2/GOES-10/IR/20000311 1045/WEST-CONUS/4km/ TIGW02 KNES 111045
>sat/ch2/GOES-10/12.0/20000311 1045/WEST-CONUS/4km/ TIGW03 KNES 111045
>sat/ch2/GOES-10/VIS/20000311 1100/WEST-CONUS/1km/ TIGW01 KNES 111100
>sat/ch2/GOES-10/3.9/20000311 1100/WEST-CONUS/4km/ TIGW04 KNES 111100
>
>So I just store the products using the individual pieces I can parse out.
>
>Steve Chiswell
>***************************************************************************
>Unidata User Support                                    UCAR Unidata
>(303)497-8644                                                  P.O. Box
>address@hidden                                   Boulder, CO
>---------------------------------------------------------------------------
>Unidata WWW Service                        http://www.unidata.ucar.edu/
><
>***************************************************************************
>
>
>