Re: dcmetr modification (was 20020615: GEMPAK Laundry List)

Hi Steve,

Thanks again for your insights.  You are absolutely right, as usual, about
the limitations of the METAR format for my purposes.  Augh, I was looking
back through my email archive and re-read your April 11 suggestion that I
should be using netCDF.  I guess that I should head in that direction.  
Here are the formats I am currently dealing with

ASOS [METAR] via UNIDATA
COOP/DCP/HADS [SHEF] via UNIDATA
AWOS [ADAS ASCII file] ftp from the Iowa DOT every 10 minutes. Which, by 
  the way, I will be responsible for generating METARs from come 1 Jul :)
Iowa RWIS [Comma Delimited] ftp from the Iowa DOT 
School Network [ASCII Text] via an Internet data stream.
Soil Climate Sites [HTML] conversion from their website.
ISU AgClimate Sites [Comma Delimited] via ftp

I will try and get them all into netCDF and then worry about getting them 
into GEMPAK surface files. 

I guess that this entire mess is called job security and if worked 
cleanly, I would be out of a job.. :)

Thanks,
  Daryl

On Mon, 17 Jun 2002, Steve Chiswell wrote:

>Daryl,
>
>Dcmetr is an NCEP decoder, (based on the core bridge.a library) so
>changing behavior is more problematic than one of mine, say dcnldn,
>dcacars, etc.
>
>Yes, you can increase the LLMXTIM to 1440. You could also use hourly files.
>The the first point of departure should probably be, "Is METAR the appropriate
>route for your data in the first place". Given the overall limitations
>of the METAR code standard which possibly isn't designed to handle
>some of the mesonet parameters, would it be better to design a decoder
>specifically for your data so that you didn't have to go through the
>extra step of creating METAR bulletins?
>
>I'd be happy to do the latter with you for your data if that is the
>prefered route. Otherwise, I can adapt dcmetr to handle more suitable
>binning (the current structure is based on the data that is currently
>broadcast- and not necessarily the most generic solution).
>
>Steve Chiswell
>Unidata User Support
>
>
>On Sun, 16 Jun 2002, Daryl Herzmann wrote:
>
>> Hi Steve,
>>
>> Thanks for the response.  First on my needs list, is to flag dcmetr to not
>> shift times (1min data).  I see three routes to achieve this goal.
>>
>> 1.  Add another hack (ex set maxtim to 60 ) to force dcgtim.f to set
>>     iomin = irmin and then not adjust date for minit over 45.
>>     This is problematic, since it would be nice to also have 1440 work
>>     as well, but that would require a change to LLMXTM, as you noted
>>     yesterday.  It would also be nice to not have this hack at all and
>>     handle it cleanly.  [Please don't take 'hack' the wrong way, :) ]
>>
>> 2.  Modify dc_gopt and add another flag (ex -f) to not allow time
>>     shifting.  This change would touch many files, I assume.
>>
>> 3.  Remove maxtim 72 hack, and add a dc flag with a bin'ing value.
>>     For example, a value of 0 or 20.  I could maybe add 5 as a supported
>>     flag argument as well.  For legacy support, I could keep the 72 flag
>>     and output a warning to the logs about it.
>>
>> Would any of these options work?  Would you merge patches from any of
>> these options?  Which is your preference?  Maybe there is a different
>> change you would like to see?  Let me know, I will do it.
>>
>> I am willing to code any of the three.  Just let me know.  If you don't
>> want any of these changes, I will just do #1 locally and be happy too!
>>
>> Thanks,
>>   Daryl
>>
>> On Sat, 15 Jun 2002, Steve Chiswell wrote:
>>
>> >
>> >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
>>