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

19990726: Q's about OABSFC and also terrain overlays.

>From: Justin Sharp <address@hidden>
>Organization: Atmospheric Sciences
>Keywords: 199907262349.RAA09430

>Hi,
>
>I hope you can help me with a couple of Gempak questions.
>
>The first is hopefully the most straight forward of the two.  I noticed
>that in Garp there are a number of nice topo overlays for various areas of
>the country.  How are these overlays displayed from within Gempak?  Is
>there an overlay  available for the Pacific Northwest?  If not, how would
>I go about creating one from the raw elevation data I have available to
>me?

Justin, the topo images are in AREA file format, same as the McIDAS
satellite images. 

If you have raw lat,lon,elevation data, then you can use mcidas to
convert the data into an AREA file. Once you have an area file, you can create
a color lut file for gempak to use as the enhancement.

In any gempak program that handles mapping, you can display the AREA file
by using:
PROJ=sat
SATFIL=areafile_name

>
>My second question is about a possible bug.  I have used OABSFC to
>successfully create surface grid files for a number of fields at several
>different times.  After analyzing the results using gdcntr I decided that
>it would be a good idea to neglect the higher elevation stations of my
>dataset.  So I created a new grid file and ran oabsfc again, but this time
>included SELV<500 at the end of my sfparm list (e.g.
>sfparm=tmax;tmin;snow;p24i;selv<500 instead of
>sfparm=tmax;tmin;snow;p24i).
>
>This produced the desired results for all the parameters at all the grid
>times EXCEPT for one of them (as it happens this was tmax at the initial
>time).  The number of available obs for each time is the same, and the
>number of obs for tmin is the same as for tmax.  Therefore I was baffled
>as to why just one time and parameter was failing.  I looked at the grid
>with gdlist and found that the offending grid DID contain values and these
>values were a FACTOR OF 10 larger than they should have been.  I can work
>around this problem by dividing the whole grid by 10, but I must admit I'm
>curious about what is causing this bizarre behaviour.
>

This seems to work for me. Did you have "SCALE=0" set in GDLIST?
If not, then Gempak will pick the scaling by itself and that may
be the cause of displaying values that look an order of magnitude
too large.
>Many thanks in advance,
>
>Justin Sharp
>-- 
>Justin Sharp           INTERNET: address@hidden
>UUCP:    uw-beaver!atmos.washington.edu!justin
>Dept of Atmospheric Sciences
>University of Washington, Box 351640
>

Steve Chiswell