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

20020615: GEMPAK Laundry List

Daryl,

As you know, Unidata obtains the GEMPAK distribution from developers at NCEP.
DCSHEF was written by Peggy Bruehl (than at COMET) and is included in the
Unidata distribution - but is not an official part of GEMPAK.

The LLMXTM defined in the $GEMPAK/include files for the number of 
times in a GEMPAK file is 300 in the Unidata distribution. you can increase
this as a compile time configuration. 

See the previous email message I wrote regarding changing the core
library storage of slat and slon as integer hundredths of degrees.
 
Other contributions for device drivers would be welcomed.

Steve Chiswell
Unidata User Support


On Sat, 15 Jun 2002, Daryl Herzmann wrote:

> Good morning!
> 
> (Firstly, I agree that David Oven's suggestion of increasing the LATLON
> precision is needed.  I am currently doing some work with GIS and the
> GEMPAK station tables are not precise enough.  I suppose that a problem
> that would result from increasing the precision 2 places, would be the 4
> extra characters that would be needed in each line and the subsequent line
> wrapping that would happen in most people's editors (not mine, hehe).  
> Maybe 4 spaces could be taken from the station name column and the station
> id column.)
> 
> Okay, as the subject implies, I have a laundry list of 
> complaints/annoyances/suggestions/comments regarding GEMPAK.  I will just 
> list them out in this email and hope for some bites :)
> 
> 1. Does the GEMPAK development team have some sort of bug tracking system,
>    for example, bugzilla?  I have a list of little annoyances, which are
>    probably small bugs that are not worth emails, but could be efficiently
>    handled by a bug tracking system.  It would also be helpful to have 
>    something to manage the RFE [request for enhancement] requests, like 
>    David's station table request.
> 
> 2. Is there an officially supported SHEF decoder in GEMPAK?  This page
> http://www.unidata.ucar.edu/packages/gempak/tutorial/manual/chap6/chap6_toc.shtml
>    does not contain a reference to dcshef, but you can hack a URL which 
>    has the man page for it.
> http://www.unidata.ucar.edu/packages/gempak/tutorial/manual/chap6/chap6.shtml?dcshef
>    Maybe this is a simple web page bug.
> 
> 3. What would be involved in increasing the max number of times size in 
>    GEMPAK surface files?  I believe the current limit is 200.  Is this set
>    somewhere that can be changed so that all programs will accept SF files
>    with 24*60 = 1440 times in it [1 minute data for one day] ?
> 
> 4. As more and more mesonets are created and the temporal resolution 
>    increases, storing 1min or 5min data in GEMPAK surface files becomes
>    necessary.  Has anyone gotten dcmetr to support this?  Currently, I 
>    hack around it, by generating `sfedit`able files and then load them 
>    into GEMPAK surface files to achieve the 1 or 5 minute data.  But then
>    #3 bits me, since I can realistically only put 1 hour in each file and
>    then generating, for example, a 1 minute trace over a day becomes 
>    difficult.
> 
> 5. Has anyone written a GeoTIFF driver for GEMPAK?  Having one would sure
>    be nice for all of those looking to use GEMPAK images in GIS.  Or maybe 
>    there is one already?  Ideas?  Currently, I generate TIFFs and then 
>    geo-reference them by hand.
> 
> 6. Is there anybody maintaining an update2date GEMPAK station table 
>    listing?  Currently, I use Greg Thompson's at RAP, but it is even 
>    outdated.  I would be willing to maintain up2date station files, if 
>    somebody else is not doing it already.  Maybe there is already a place 
>    on the Internet to pick up updated GEMPAK station files.
> 
> 7. Has anyone written Python/Java/Perl/Ruby etc adapters to GEMPAK 
>    routines or data files?  I have a python interface to GEMPAK station 
>    files, if anybody is interested.
> 
> 8. I have been griding NEXRAD STP,N1P products now, which works great!  
>    Now, I would like to add/subtract grids and get accumulations from it.
>    The problem is that if in the first grid the point was missing (no 
>    precip) and the second grid the point was 2 inches, the total according 
>    to GEMPAK is missing.  Basically, precip is needed in both grids for a 
>    point in order to add them.  I poked around in gemlib/df/dfadd.f 
>             IF  ( ERMISS ( dg1 ) .or. ERMISS ( dg2 ) )  THEN
>                 dgg ( numi ) = RMISSD
>               ELSE
>                 dgg ( numi ) = dg1 + dg2
>             END IF
>    So a hack around this would be doable, but my question is if this hack 
>    would break other programs and routines.  Do I need to make a new 
>    function?  Or am I doing something wrong? <- probably the answer :) 
> 
> Well, I had better stop for now.  I sure wish that I knew FORTRAN better, 
> so that I could send fixes with this whining.  Ahh, but whining is fun! 
> 
> Later :)
>   Daryl
> 
>