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

20020412: 20020411: Guidance Requested (dcmetr, NWSLI)

Daryl,

Yes, the METAR format isn't the beast when trying to put measurements
into the code that are not typical WMO measurements.

One avenue for this data is FSL's MADIS system (They do distribute
the data in NetCDF files....currently about 4000+ surface stations).
I know that they are always looking for obs. And, if they can do the work to
format/qc/distribute the data, then it saves you lots of time.

I can put you in touch with Patty Miller at FSL if you like.

Steve Chiswell
Unidata User Support






>From: Daryl Herzmann <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200204121641.g3CGffa08247

>Hello!
>       Thanks for the informative email.  Please see my responses below.  
>
>On Thu, 11 Apr 2002, Unidata Support wrote:
>
>>But, if anyone else wanted to decode your product, and their
>>decoders were written strictly to the "CCCC" specification,
>>then you would have a problem there. 
>
>       Yup.  I think that I will shy away from using the NWSLI for the 
>METAR data.  Currently, I am generating bogus sflist files than can be 
>used by sfedit to fill gempak surface files.  The stations report things 
>like Solar Rad and Pavement temps that aren't handled by METAR format.
>
>>You could use other 4 characater identifiers (the NWS does something like
>>this already by creating alpha numeric id's like K7V3 that don't conform to
>>12.6.2 in the above URL). You would want to
>>1) ensure they weren't already assigned elsewhere 
>>2) provide your own station table for decoding-
>>   eg, decode those 1 minute obs with dcmetr and specify the "-s" flag
>>   to as RWIS or school-net specific table.
>
>       I would have to provide a station table to sites, so that is not a 
>big deal.  I am the most concerned about #1 though.  If I distribute the 
>data in a format other than METAR, I may be able to use the NWSLI.  I 
>would still need to make sure my RWIS stations are okay.
>
>>Other options:
>>You could put your data into a NetCDF file with both the station ID
>>and location and anyone wanting to use the data could write an
>>adaptor (like the dcacars, dcsuomi, dcncprof etc) decoders that
>>write GEMPAK files from the NetCDF data.
>
>       I like the idea, but I have not programmed with NetCDF yet and I 
>would have to write the adapter as well.  I don't think many sites would 
>want the data, if they had to write the adapter.  I will look at the dc* 
>programs and see what can be done.  It looks like best route I have.
>
>
>>another question is, do you intend to mix this observations into
>>data files that have other hourly METAR data from the IDD? If so,
>>one set would have observation frequency on the order of 1 minute,
>>while the other is 1 hour. It gets clumsy to display data like that.
>
>       I have data flying all over the place :)  I don't put 1 minute 
>data into GEMPAK surface files, because of all the restrictions I have 
>found with MAX_TIMES with the GEMPAK surface data programs.  I would have 
>to have 1 file per hour and I am not sure how useful it would be for 
>applications.  Currently, I am putting it in a database, which works very 
>well for what I do.  I do put 20 minute data into the surface files for 
>comparisons/plotting with the RWIS, AWOS and others.
>
>>On the other hand, if you have separate files for your decoded data, then
>>you can use whatever station IDs you like.
>
>       Yup.  But I am guessing that some sites would combine the datasets 
>for easy plotting, etc...  Maybe nobody is interested in the data and this 
>is all in vain :)  Hope not...
>
>Thanks!
>Daryl
>
>
>