This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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/ >> **************************************************************************** >> >