20030403: 20030403: 20030401: GINI data in gempak

Mark,

you need to pass the decoder a GEMPAK looking "device"
which specifies the file name, geometry and color style
like you would in the DEVICE specification of a GEMPAK program,
eg PS|filename||C.

As shown in the redbook examples on the web site,
I pipe to a shell script that calls dcredbook_ps like:

#!/bin/csh -f
#
# Filename: dcredbook_ps.csh
#
# This scripts may be used as a pqact.conf action to automatically
# print REDBOOK graphics found on NOAAPORT.
#
# pqact.conf usage:
#
# send all NOAAPORT graphic products (except those from KWAL) to this script
#HRS     ^P..... (K[^W]|KW[^A]|KWA[^L])
#       PIPE    -close  util/dcredbook_ps.csh
#
#
# source the GEMPAK environment so that table, mapfiles etc. are found
#
source /home/gempak/NAWIPS/Gemenviron

# Set a work directory and change directory to it
setenv PSDIR $GEMDATA/web/redbook
cd $PSDIR

cat | dcredbook_ps -v 1 -d $GEMDATA/logs/dcredbook.log 'PS|%P.ps||C'
exit 0


The pqact.conf entry is:

HRS    ^P..... (K[^WK]|KW[^A]|KWA[^L]|KK[^C]|KKC[^I])
       PIPE    -close  util/dcredbook_ps.csh





>From: Mark Tucker <address@hidden>
>Organization: Lyndon State College
>Keywords: 200304032139.h33Lda7U010941

>
>> You should be able to use "tail +3 file > newfile"
>> to dump the product out starting at the 3rd line to a new file.
>> Eventually, you probably want your ingester not to add those lines,
>> or to strip them out through a filter from pqact.
>> 
>> The relevant code in $GEMPAK/source/gemlib/im/imgi2gm.f expects the
>> actual GINI image (the stuff after the WMO header that you see)
>> will begin either 22 or 26 bytes into the product. Typically, the
>> WMO header as comes across NOAAPORT is 21 characters and looks like:
>> TIGE01 KNES 312200\r\r\n
>> So, the image starts at position 22.
>
>Thanks, I've stripped out the extra junk on the receiver and the data is
>flowing in nicely and viewable under gempak.  
>
>Also, as I mentioned in my original message, I've been working on getting the
>redbooks graphics processed through the ldm.  So far I'm able to pull in the
>raw files but the decoder does not seem to be filing the processed files. 
>Here is an example of on of our pqact.conf entries:
>
>NGRAPH  ^PXWA50 .... ([0-3][0-9])([0-2][0-9])([0-5][0-9])
>        PIPE    -close  decoders/dcredbook_ps
>        -v 0
>        -d logs/dcredbook.log
>        -e GEMTBL=/home/gempak/GEMPAK5.6F/tables
>        data/gempak/redbook/lifted_k_index/(\1:yyyy)(\1:mm)\1_\2\3.ps
>
>
>From the log file:
>
>[8885] 030403/2127 [DC 3]
>[8885] 030403/2127 [DC 5]
>[8885] 030403/2127 [DC 2] Number of bulletins read and processed: 0
>[8885] 030403/2127 [DC 6]
>[8897] 030403/2128 [DC 3]
>[8897] 030403/2128 [DC 5]
>[8897] 030403/2128 [DC 2] Number of bulletins read and processed: 0
>[8897] 030403/2128 [DC 6]
>
>
>Any idea what could be wrong?
>
>Thanks.
>
>-- 
>
>Mark Tucker
>Systems Administrator
>Meteorology Dept. 
>Lyndon State College
>http://apollo.lsc.vsc.edu
>address@hidden
>(802)-626-6328
>

Unidata WWW Service              http://my.unidata.ucar.edu/content/support