Hi Arlindo:
This proposal is now part of CF, see chapter 9 and Appendix H in:
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html
Ill look at your specifics when i can get to it, it looks like a collection of profiles at first glance.
Meanwhile have a look at that doc.
profile | an ordered set of data points along a vertical line at a fixed horizontal position and fixed time | ||
| |||
timeSeriesProfile | a series of profile features at the same horizontal position with monotonically increasing times | ||
| |||
trajectoryProfile | a series of profile features located at points ordered along a trajectory | ||
|
genericProfile | a generic collection of profile features. | ||
|
John
On 2/18/2012 10:53 AM, Arlindo da Silva wrote:On Tue, Dec 30, 2008 at 1:24 PM, John Caron <address@hidden> wrote:
I have proposed a point obs standard to CF here:
http://cf-pcmdi.llnl.gov/trac/ticket/37
http://cf-pcmdi.llnl.gov/trac/wiki/PointObservationConventions
Feedback would be appreciated, as we'd like to start swimming if we dont sink ;^)
This proposal (when accepted) will supercede the "Unidata Observation Dataset Convention". We are looking at being able to encode some of the NWS obs data stream, as it comes in on the IDD. If there are specific requirements you have, send them along and we will include them in our use cases.
I am not sure where is the best place to post this question/coment, so I am starting with you. I am trying to produce CF compliant NetCDF files for NASA's DISCOVER-AQ airborne campaign. Specifically, I have a collection of profiles from "aircraft spirals" around fixed locations which have been binned at a fixed vertical grid. The natural way to index the data is:
data(profile,altitude)
with coordinates:
longitude(profile)latitude(profile)time(profile)
but
altitude(altitude) // vertical grid is the same for *all* profiles.
None of the CF feature types described in this word document
seems to cover this case. The closest is "trajectory" but it has no provision for vertical coordinates and my time coordinate is certainly *not* monotonic. To describe the data I'd need something like:
griddedProfile
a generic collection of profile features on a fixed vertical grid; time is not necessarily monotonic.
data(i,p)
x(p) y(p) z(i) t(p)
BTW, this same data structure would also be needed for the airborne HSRL LIDAR data.
As for my feedback on the current CF draft. I find this notion of "featureType" a bit awkward, given that you may need a large number of permutations to cover all use cases. In particular, the mandatory space-time coordinates is problematic. While requiring (x,y,z,t) coordinates is OK, requiring that they are dimensioned a certain way is too restrictive, specially because this information is easily discoverable. For example, if this restriction would be lifted, the featureType "profile" could be used to describe my data.
Thank you!
Arlindo