NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTE: The galeon
mailing list is no longer active. The list archives are made available for historical reasons.
Why are stationTimeSeries and stationProfileTimeSeries specific to a station? The optional use of a station name is useful to include in some cases, but I can see running into other cases where several data points are gathered in a time series but there is no associated station. In a couple of documents the stationTimeSeries is likened to the CSML PointSeriesFeature, but PointSeriesFeature does not include a station name or related terminology. The ":CF\:pointFeature" name could be generalized to ":CF\:cdmFeature" or ":CF\:featureType", assuming that there is no additional and necessary semantics to these identifiers being point types vs general types. Minor errata on the description page: -There are several uses of "reletive humidity" instead of "relative humidity" -Several "humidity" definitions have temperature markers in them -"temperacture" is used instead of "temperature" a couple times I may send along further comments, time allowing. Aaron
FYI, I finally submitted a proposed convention for point obs data to the CF group: http://www.unidata.ucar.edu/software/netcdf-java/CDM/CFpoints.html feedback to http://cf-pcmdi.llnl.gov/trac/ticket/37 would be welcome. #37: Conventions for Point Observation Data ----------------------------+----------------------------------------------- Reporter: caron | Owner: cf-conventions@xxxxxxxxxxxxxx Type: enhancement | Status: new Priority: high | Milestone: Component: cf-conventions | Version: Keywords: point | ----------------------------+----------------------------------------------- == 1. Title == Conventions for Point Observation Data == 2. Moderator == TBD == 3. Requirement == Current conventions are oriented towards gridded data. This proposal extends the framework to specify how to encode "point observation" data. == 4. Initial Statement of Technical Proposal == We show six types of point observational data, and describe a general way to encode many variations. The main technical extension is a simple way to describe ragged arrays, for the case when rectangular arrays are too inefficient. == 5. Benefits == * Many data providers would like to use CF conventions when storing their observational data. * This will allow a standard for converting things like BUFR data into netCDF. == 6. Status Quo == Currently sections 5.4 and 5.5 describe 2 examples of point observations (station time series and trajectories). This proposal generalizes those. == 7. Detailed Proposal == Because of the length of this, I have created a [http://www.unidata.ucar.edu/software/netcdf-java/CDM/CFpoints.html seperate web page] to make it easy (for me) to edit. I can reformat later when it is close to being finished, or if others need to edit it. Some background docs and earlier drafts: * [http://www.unidata.ucar.edu/software/netcdf-java/CDM/CDMfeatures.doc CDM Feature Types] * [http://www.unidata.ucar.edu/software/netcdf-java/CDM/CDMpoints.doc CDM Point Feature Types] * [http://www.unidata.ucar.edu/staff/caron/papers/obs2.pdf Draft 2 of proposed spec for Point Observation netCDF encoding]
galeon
archives: