20040415: 20040415: Vietnam and GEMPAK GRIB decoding (cont.)

Mai,

I have answered your GEMPAK specific questions below interspersed
within the original text.

Steve Chiswell
Unidata User Support





>From: Mai Nguyen <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200404160620.i3G6KWCT004942

>Dear Tom,
>
>Thanks for your long and instructive email. It will be
>enough for me to "digest" for the whole weekend!
>
>The meta file is what needed by ntrans.
>
>Bye for now and have a nice weekend.
>
>Mai
>
>Now, on to some other questions you have asked:
>
>>From address@hidden  Tue Apr 13 09: 28:52 2004
>
>>3) MY PREVIOUS QUESTIONS:
>>   + Meta files (how to create them)

Use the "nc" device driver as described in the GEMPAK tutorial:

http://my.unidata.ucar.edu/content/software/gempak/tutorial/ntrans.html


>   
>>4) AND SOME NEW QUESTIONS:
>>   + Is that possible to draw isolines based on the
>>     synoptic observations? 

The general process is to create a grid file and run a Barnes objective
analysis on the surface data to create a grid which can be used 
in the grid programs.

http://my.unidata.ucar.edu/content/software/gempak/tutorial/barnes.html

There is a simple shortcut program called sfcntr that will contour 
a single parameter from the surface data file, but you are limited in
control over the data spacing, grid etc:
http://my.unidata.ucar.edu/content/software/gempak/help_and_documentation/manual/chap4/chap4.php?prog=sfcntr



>>   + It's funny with the QUICKSCAT info. When I load
>>     it, NMAP2 shows that the information is available, but
>>     it shows nothing. The same with ATCF. NMAP2 gives no
>>     error for it. But as I looked in the datatype.tbl of
>>     gempak, the variables defining directory of the data
>>     is not defined. How NMAP2 can see that it's available?
>>     Is that a bug of NMAP2?  

Quickscat data is not available through Unidata.
The NMAP2 gui will not show any available times
without it being present. It is in the menu pulldown as a possible
data set, but unless you have it, it will not find any.

>
>>From address@hidden  Wed Apr 14 09: 16:23 2004
>
>>There is another aspect that may need to be
>>considered. We have another 200 hydrological rain
>>gauge stations which give us rainfall. Therefore,
>>there won't be enough free space in WMO table to put
>>them in.
>
>> + Are the rainfall observations shown in the same
>>   manner as meteorological surface observations?
>>
>>   Or they
>>   are another kind of data? And there are different
>>   tables for rainfall stations?
>
>> + Is there another way to put surface observations in
>>   gempak format? Not from standard WMO text bulletins
>>   but from decoded data? This question arised because we
>>   have done some works on correcting the data defects
>>   (which are very common in our system due to our
>>   not-so-advanced infrastructure!) and it might be nice
>>   to utilize the corrected observations. I am not sure
>>   how dclsfc handle the bad data (just throw them
>>   away?). 

Surface data can be read from a specific ASCII format by the
program SFEDIT. The format is the same that SFLIST will output. See:

http://my.unidata.ucar.edu/content/software/gempak/tutorial/importingdata.html


Steve Chiswell
Unidata User Support



>
>__________________________________
>Do you Yahoo!?
>Yahoo! Tax Center - File online by April 15th
>http://taxes.yahoo.com/filing.html
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.