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: