This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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 >>