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]