20010807: dcmetr: not processing locally-ingested METAR: resolved

Christian,

There is a program called SFSTNS that will let you update station information
in a GEMPAK file after it is created. However, you don't want to
do that while dcmetr is writing to the file (eg shut the LDM down
for a minute). But, in the case where more than the "-a" add stations
has been exceeded, you won't have the room for additional stations.
But, you can add lat/lon/evevation information from the station
table for additional stations that were added.

Steve Chiswell
Unidata User Support




>From: Christian Page <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200108080936.f789a2117506

>
>Hi,
>
>So the problem is resolved. The problem was because of the station tables
>(that didn't include my new stations) and the fact that stations that can be
>included in a gempak files are defined at the creation of the gempak file usin
> g
>the active station tables, so it is why, even after modifying the station tabl
> es
>I didn't get the new METAR station data in the gempak file.
>
>Thanks a lot for your support,
>
>Christian Page
>UQAM
>
>On Tue, 7 Aug 2001, Unidata Support wrote:
>
>>
>> Christian,
>>
>> my dcmetr example shows the use of "-s sfmetar_sa.tbl".ch is the station tab
> le I maintain from
>> the real-time data feed and periodically update the table with new station I
> Ds and remove
>> old IDs. SFCHCK is useful formaintaining station tables. You can use any sta
> tion
>> table you like. One problem with using sfworld.tbl is that not all stations 
> in sfworld.tbl
>> have STID identifiers (eg some are just WMO identifiers), so they would neve
> r be useful
>> for METAR observations.
>>
>> Steve Chiswell
>> Unidata User Support
>>
>>
>>
>> >From: Christian Page <address@hidden>
>> >Organization: UCAR/Unidata
>> >Keywords: 200108072037.f77Kb9123881
>>
>> >
>> >One question regarding tables: is it possible to use another station table 
> fil
>> > e
>> >for dcmetr than sfstns.tbl? Can I use sfmetar_sa.tbl or sfworld.tbl?
>> >
>> >Christian Page
>> >UQAM
>> >
>> >>
>> >> Christian,
>> >>
>> >> I downloaded 2 bulletins from your LDM and decoded them with dcmetr:
>> >> ldm% feedme -v -l - -h io.sca.uqam.ca -p "SAFR33" -o 3600 > test.data
>> >> :      157 20010807163331.120     IDS 000  SAFR33 LFPW 071600
>> >> :       96 20010807170334.610     IDS 000  SAFR33 LFPW 071630
>> >>
>> >> They did decode OK with dcmetr, so we know that works as your message sta
> tes
>> > .
>> >> I also was successful in using the pqact.conf entry you have (with paths
>> >> appropriately changed)
>> >>
>> >> You are correct that you don't want more than 1 decoder writing to a file
> .
>> >>
>> >> Your action below doesn't specify a "-s" option, so you will use the sfst
> ns.
>> > tbl
>> >> station table, which doesn't have those stations in it. If your surface f
> ile
>> >> was already created before you added those station locations to the table
> ,
>> >> then your GEMPAK file won't have them either.
>> >>
>> >> By default, room for 200 additional stations is allotted unless you
>> >> specify more room with "-a". So, if your GEMPAK file was created by dcmet
> r b
>> > efore
>> >> you added the stations to sfstns.tbl, you won't see the stations unless t
> hey
>> >> are one of the first 200 "new" stations received that aren't in the table
> .
>> >>
>> >> If you have added the sfstns.tbl entries, you should start seeing
>> >> the stations in the GEMPAK files when a new output file is created
>> >> tomorrow.
>> >>
>> >> If you still don't see the stations, then try adding the "-v 4" option
>> >> to dcmetr to see where the decoder is upset with the bulletin.
>> >>
>> >> Steve Chiswell
>> >> Unidata User Support
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> >From: Christian Page <address@hidden>
>> >> >Organization: UCAR/Unidata
>> >> >Keywords: 200108071012.f77ACJ118901
>> >>
>> >> >
>> >> >Hi,
>> >> >
>> >> >I still have some problems regarding dcmetr and locally-ingested METAR. 
> Her
>> > e's
>> >> >  a
>> >> >wrap-up again of my problem:
>> >> >
>> >> >--------------------------------------
>> >> >
>> >> >I generate, from 2 metar reports, by example:
>> >> >---cut here---
>> >> >^A^M^M
>> >> >981 ^M^M
>> >> >SAFR33 LFPW 070900^M^M
>> >> >METAR^M^M
>> >> >LFJL 070900Z AUTO 26010KT 9999 SCT058 SCT070 30/15 Q1022=^M^M
>> >> >LFBG 070900Z 36006KT 320V040 CAVOK 31/16 Q1024=^M^M
>> >> >^M^M
>> >> >^C
>> >> >--- cut here ---
>> >> >
>> >> >I create this text file where ^C etc. are control characters. The EOF of
>  th
>> > e
>> >> >file is just after the ^C. There is no ^J there. The 981 is a dummy numb
> er.
>> >> >SAFR33 is a new dummy WMO header that doesn't exist in the IDS feed.
>> >> >
>> >> >This report is processed correctly by pqact and pqsurf: I get the in my 
> gdb
>> > m
>> >> >database (pqsurf) and in my raw WMO text files (pqact). The problem is t
> hat
>> >  th
>> >> > ey
>> >> >are not put into my gempak files using this pqact.conf entry:
>> >> >
>> >> ># International sfc obs and specials in hourly files yymmddhh_sao.gem
>> >> >WMO     ^S[AP].... .... ([0-3][0-9])([0-2][0-9])
>> >> >        PIPE    /io/gempak/nawips/bin/irix/dcmetr -b 9 -m 72
>> >> >        -d logs/dcmetr.log
>> >> >        -e GEMTBL=/io/gempak/nawips/gempak/tables
>> >> >        data/gempak/surface/sao/YYYYMMDD_sao.gem
>> >> >
>> >> >This works for all reports except those I ingest locally.
>> >> >
>> >> >------------------------------------------
>> >> >More, if I run dcmetr manually, as:
>> >> >
>> >> >cat "SAFR33 LFPW 070900" | /io/gempak/nawips/bin/irix/dcmetr -b 9 -m 72 
> -d
>> >  \
>> >> >logs/dcmetr.log -e GEMTBL=/io/gempak/nawips/gempak/tables test.gem
>> >> >
>> >> >it works. If I run sflist and list the data, these stations are there. A
> lso
>> >  if
>> >> >  I
>> >> >edit the binay gempak file in emacs, I can find LFBG in there.
>> >> >
>> >> >-------------------------------------------
>> >> >But if I try to put it manually into my realtime gempak file, it doesn't
>  wo
>> > rk
>> >> >neither:
>> >> >
>> >> >cat "SAFR33 LFPW 070900" | /io/gempak/nawips/bin/irix/dcmetr -b 9 -m 72 
> -d
>> >  \
>> >> >logs/dcmetr.log -e GEMTBL=/io/gempak/nawips/gempak/tables \
>> >> >/io/ldm/data/gempak/surface/sao/20010807_sao.gem
>> >> >
>> >> >but in that case, maybe I have the risk to corrupt my file since a dcmet
> r
>> >> >invocation is writing at the sametime in the file. Running sflist yields
>  to
>> >  no
>> >> >data from LFBG, and editing read-only the file into emacs, I cannot find
>  an
>> > y
>> >> >LFBG string neither.
>> >> >
>> >> >--------------------------------------------
>> >> >
>> >> >Also, as a note, I assured that LFBG was in the station list tables file
> s,
>> > and
>> >> >  I
>> >> >added an LFBG entry when missing. But this didn't help.
>> >> >
>> >> >Any hint?
>> >> >
>> >> >Christian Page
>> >> >UQAM
>> >> >
>> >>
>> >> *************************************************************************
> ***
>> >> Unidata User Support                                    UCAR Unidata Prog
> ram
>> >> (303)497-8644                                                  P.O. Box 3
> 000
>> >> address@hidden                                   Boulder, CO 80
> 307
>> >> -------------------------------------------------------------------------
> ---
>> >> Unidata WWW Service                        http://www.unidata.ucar.edu/
>> >> *************************************************************************
> ***
>> >>
>> >
>>
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8644                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service                        http://www.unidata.ucar.edu/     
>> ****************************************************************************
>>
>