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

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

Christian,

my dcmetr example shows the use of "-s sfmetar_sa.tbl".ch is the station table 
I maintain from
the real-time data feed and periodically update the table with new station IDs 
and remove
old IDs. SFCHCK is useful formaintaining station tables. You can use any station
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 never 
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 states
> .
>> 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 sfstns.
> tbl
>> station table, which doesn't have those stations in it. If your surface file
>> 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 dcmetr b
> efore
>> you added the stations to sfstns.tbl, you won't see the stations unless they
>> 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 number.
>> >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 that
>  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. Also
>  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 dcmetr
>> >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 files, 
> and
>> >  I
>> >added an LFBG entry when missing. But this didn't help.
>> >
>> >Any hint?
>> >
>> >Christian Page
>> >UQAM
>> >
>>
>> ****************************************************************************
>> 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/     
>> ****************************************************************************
>>
>