[GEMPAK #MIL-606935]: station table precision & grid input

> Dear Sir or Madam,
> 
> I'm currently working on using Gempak to overlay radar data with
> contours of surface pressure, temperature, etc. from the Oklahoma
> mesonet.  I'm doing a time-space transformation on the mesonet data, so
> I would need to be able to plot data with a resolution of more than the
> currently allowed hundredths of a degree of latitude or longitude.
> 
> In looking through the threads of previous support emails, I came across
> this topic, and saw a suggested fix (on 20020615, msg00431):
> 
> "The SF library routines currently store SLAT and SLON as integers
> (hundredths of degrees). The library routines know implicitly to
> multiply and divide by 100 to convert from the stored value and the
> actual value. This is aside from the table reading routines for reading
> station tables.
> 
> One could change this for more precision, but in order to be able to
> recognize other files, for example archives, case studies etc), you
> would have to amend the data management section of the surface file to
> reflect the scaling factor when something other than 100 is used for
> backward compatibility."
> 
> I'm wondering what exact library routines I would need to change for
> this (and for that matter, how would I change them?)  I wouldn't need
> to worry about backward compatibility -- the only other data I am going
> to plot is the radar data, and I figured I could simply tweak the radar
> projection table to reflect the new scaling factor.

Becky,

Unfortunately, its a pretty complicated process where the SF_ASTN routine 
implicitly
computes NINT(slat * 100) and NINT(slon * 100), and then translates the number 
into
a character representation for the word value that is stored. The SF_CREF 
routine
that creates the surface file defines the kslat and kslon word number in the 
file
which must correspond to the location in the packed word that SF_ASTN uses in
the DM_ library call that writes the data to the file. Any change in size here 
must 
be identically reflected in the search and read routine access to the surface 
file so that
the correct translation of the slat and slon words can be correctly located.
I don't have a simple one location answer for the steps there since the DM_ 
interface is rather structured.


> 
> 
> Secondly, I've also already computed grids of the data using the MQD
> analysis scheme.  Is it possible to input these grids into Gempak and
> have it contour them?  I was guessing the program GDCFIL would be
> useful here, but it seems like that would run them through the
> Barnes analysis before contouring.

GDCFIL creates a new (and empty) GEMPAK grid file with a specified projection 
and number of
grids. You can import a grid into a GEMPAK grid file (without running the OS 
objective analysis 
routines) by putting your grid data io the format produced be "GDLIST". That 
ascii format can
be read into the GRID file using the "GDEDIT" program. Alternatively, if you can
produce a grid using GRIB representation, you could import the data using a 
nagrib or dcgrib2.

To interface your gridding routine directly to the GEMPAK library routines, you 
might look at the GDEDIT
or GDDIAG programs, where you could modify the routine so that you could 
interface your MQD grid at the 
point where the routines writes the data to the grid file (created by GDCFIL). 
The GDDIAG program can create
a grid file of a specified projection, so that combines 2 steps.

Steve Chiswell
Unidata User Support

> 
> Thanks for your help!
> Becky Adams
> 
> 


Ticket Details
===================
Ticket ID: MIL-606935
Department: Support GEMPAK
Priority: Critical
Status: Closed