(taking the liberty of posting to cf group, since others may have
different thoughts)
Kevin Hodges wrote:
> hi John
>
> thanks for the info. I agree the 5.8.3.3 convention looks like what I was
> heading towards, however, I think my data is a little more complicated.
> As well as the basic track with a longitude and latitude position and
> intensity value there can be additional information associated with the
> track which is more than just other fields values along the track at the
> same track points. For example, if I have a load of vorticity tracks I can
> also associate with these tracks the nearest pressure minima and the
> additional data will take the form of the longitudes and latitudes of the
> pressure minima and the pressure minima values. Additionaly, additional
> fields evaluated at the vorticity locations can also be in the same dataset
> hence it is useful to have the attributes for the number of addititional
> fields and whether they have locational information.
>
as you've noticed, the proposed conventions only describe how to geolate
the data with a single lat/lon/alt/time value. all the extra info that
you have can be included in the file no problem, but generic readers
like the IDV wont do anything special with them.
>
> I also agree that more attribute information should be given in the form of
> descriptive variable names, units, long-name and standard_name attributes to
> each data variable. The coordinate variable must have units and should have
> description and standard_name.
>
> Do you know if these conventions are being taken up by graphical display
> developers, e.g. vcdat, IDV, grads?
>
i know the IDV is because im part of the team working on that. im pretty
sure that grads is working on CF compliance, though i doubt that they
have started implementing this convention since its not yet official. im
not sure of vcdat or other packages. i can say with some assurance that
CF is your best bet for (eventual) inclusion by most generic packages.
specialized software, of course, can do, uh, special things that generic
packages will likely never do, and those may need a different set of
conventions.
>
> Regards
>
> Kevin
>
>
>
>> Date: Mon, 05 Oct 2009 11:45:02 -0600
>> From: John Caron <caron at unidata.ucar.edu>
>> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
>> MIME-Version: 1.0
>> CC: cf-metadata at cgd.ucar.edu, Kevin Hodges <kih at mail.nerc-essc.ac.uk>
>> Subject: Re: [CF-metadata] CF conventions for storing weather system track
>>
> data.
>
>> Content-Transfer-Encoding: 7bit
>> X-Scan-Signature: 3e29eea2a884c6a2f9879ba4bf50090e
>> X-Spam-About: See http://www.reading.ac.uk/ITS/SpamFilter for details.
>> X-Spam-Status: No, hits=1.3 required=5.0
>>
> tests=BAYES_50=0.001,MISSING_HEADERS=1.292,SPF_PASS=-0.001 autolearn=disabled
> version=3.2.3
>
>> X-Spam-Level: *
>>
>> Hi Kevin:
>>
>> It looks like your use case would be covered by these proposed conventions:
>>
>> https://cf-pcmdi.llnl.gov/trac/wiki/PointObservationConventions
>>
>> This proposal would classify your data as "trajectory data", and it looks like
>>
> you are using the "contiguous ragged array" encoding. The "ragged array" allows
> multiple trajectories with different lengths in the same file. The "contiguous"
> stores all the data for each trajectory next to each other, to optimize reading
> all the data for one trajectory.
>
>> So Im thinking that it could be handled by section 5.8.3.3. You could also use
>>
> 5.8.3.4 "Ragged array (non-contiguous)" if its not possible or important to
> group the trajectory data together. It looks like you may already be doing that
> with your index(record) variable, assuming that has the track index in it.
>
>> We are currently finalizing this proposal, so your feedback now would be
>>
> timely.
>
>> Other feedback:
>>
>> CF would encourage you to use more descriptive variable names if possible, and
>>
> also to add units, long-name and standard_name attributes to each data variable.
> The coordinate variable must have units and should have description and
> standard_name. There's probably some other details to iron out also.
>
>> John Caron
>> Unidata
>>
>>
>>
>>
>> Karl Taylor wrote:
>>
>>> Hi all,
>>>
>>> Here is an inquiry from Kevin Hodges. I think CF would treat these
>>> something like weather balloons. Can anyone help?
>>>
>>> thanks,
>>> Karl
>>>
>>> p.s. please copy Kevin kih at mail.nerc-essc.ac.uk because I think he's not
>>> on our list.
>>>
>>> I was wondering if you know of anyone who has thought about a netcdf
>>> convention for weather systems tracks. I know there are various
>>> conventions
>>> for chemical tracer trajectories but these are not really suitable for
>>> weather system tracks.
>>> I have been giving this some thought and have produced something like
>>> the following CDL produced from one of my track files. This could off
>>> coarse be fleshed out further with more attributes. It would be nice
>>> to tie this
>>> to the ability to display weather system tracks in software such as
>>> vcdat.
>>> I've seen GEON IDV can display tracks but again the format is not really
>>> very suitable for weather system tracks where you can have multiple
>>> tracks
>>> of different lengths and a wide range of information associated with
>>> the tracks.
>>> netcdf ff_trs.nctrack {
>>> dimensions:
>>> tracks = 497 ;
>>> record = UNLIMITED ; // (9706 currently)
>>> variables:
>>> int TRACK_ID(tracks) ;
>>> TRACK_ID:add_fld_num = 7 ;
>>> TRACK_ID:tot_add_fld_num = 21 ;
>>> TRACK_ID:loc_flags = 1, 1, 1, 1, 1, 1, 1 ;
>>> int FIRST_PT(tracks) ;
>>> int NUM_PTS(tracks) ;
>>> int index(record) ;
>>> int time(record) ;
>>> float longitude(record) ;
>>> float latitude(record) ;
>>> float intensity(record) ;
>>> float long_1(record) ;
>>> long_1:missing_value = 1.e+12f ;
>>> float lat_1(record) ;
>>> lat_1:missing_value = 1.e+12f ;
>>> float addfld_1(record) ;
>>> addfld_1:missing_value = 1.e+12f ;
>>> float long_2(record) ;
>>> long_2:missing_value = 1.e+12f ;
>>> float lat_2(record) ;
>>> lat_2:missing_value = 1.e+12f ;
>>> float addfld_2(record) ;
>>> addfld_2:missing_value = 1.e+12f ;
>>> float long_3(record) ;
>>> long_3:missing_value = 1.e+12f ;
>>> float lat_3(record) ;
>>> lat_3:missing_value = 1.e+12f ;
>>> float addfld_3(record) ;
>>> addfld_3:missing_value = 1.e+12f ;
>>> float long_4(record) ;
>>> long_4:missing_value = 1.e+12f ;
>>> float lat_4(record) ;
>>> lat_4:missing_value = 1.e+12f ;
>>> float addfld_4(record) ;
>>> addfld_4:missing_value = 1.e+12f ;
>>> float long_5(record) ;
>>> long_5:missing_value = 1.e+12f ;
>>> float lat_5(record) ;
>>> lat_5:missing_value = 1.e+12f ;
>>> float addfld_5(record) ;
>>> addfld_5:missing_value = 1.e+12f ;
>>> float long_6(record) ;
>>> long_6:missing_value = 1.e+12f ;
>>> float lat_6(record) ;
>>> lat_6:missing_value = 1.e+12f ;
>>> float addfld_6(record) ;
>>> addfld_6:missing_value = 1.e+12f ;
>>> float long_7(record) ;
>>> long_7:missing_value = 1.e+12f ;
>>> float lat_7(record) ;
>>> lat_7:missing_value = 1.e+12f ;
>>> float addfld_7(record) ;
>>> addfld_7:missing_value = 1.e+12f ;
>>>
>>> _______________________________________________
>>> CF-metadata mailing list
>>> CF-metadata at cgd.ucar.edu
>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>
>
> --------------------------------------------------------------------------
> | |
> | Kevin I. Hodges |
> | ESSC (Enviromental Systems Science Center) |
> | University of Reading, |
> | Harry Pitt Building, |
> | 3 Earley Gate, |
> | Whiteknights, PO Box 238, Tel: 0118 378 7761 |
> | Reading RG6 6AL, U.K. Fax: 0118 378 6413 |
> | |
> | email: kih at mail.nerc-essc.ac.uk |
> | WWW: http://www.nerc-essc.ac.uk/~kih/Home.html |
> | |
> --------------------------------------------------------------------------
>
>
Received on Mon Oct 05 2009 - 16:32:27 BST
