NOTE: The cf-pointobsconvention mailing list is no longer active. The list archives are made available for historical reasons.
Dear Point Obs and data model experts,
I am following up on Nan's initial question - we were at the same meeting
where this issue was identified by the oceanographic in situ instrument
community. We are concerned about the proper archiving of climate quality
measurements for the long term and recognize the need to store *very*
complete provenance metadata *with* the instrument data.
We are examining SensorML and ISO 19115 to meet this need, but haven't made
any decisions yet and would entertain other options. We would very much
prefer to embed this important metadata within the NetCDF file. The
question is whether it is possible to store structured information in some
area of the file - perhaps there is new capability in the NetCDF-4?
A highly summarized example of the structured information that we'd like to
store is:
- (1) NetCDF file (containing global and variable metadata)
|
|- (2) Process that created this (1) file
|
|- (3a) Input data file to above process
|
|- (4) Process that created this (3a) file
|
|- (5) Input data stream
|
|- (6) Deployment of instrument
|
|- (7) Instrument details
+
|
|- (8) Parent Deployment
| ...
|
|- (3b) Input data file to above process
| ...
Where attributes of these elements would be like:
1) OPeNDAP URL to file, create time, etc.
2) Process name, process start and end time, reference to source code in
version control, description of the process, host and user that executed the
process, etc.
3) Same as 1
4) Same as 2, additionally with references to calibrations used if direct
instrument datastream output was processed
5) Datastream access URL, create time, etc.
6) Deployment start and end time, references to parent deployment, if any
(e.g. The instrument may be on an AUV, glider, mooring, ship, etc.), nominal
latitude, longitude, depth, etc.
7) Instrument manufacturer, model, serial number and references to any
supporting material: spec sheets, calibration documents, etc.
8) Same as 6
An actual in situ data set would contain the descriptions of the processing
and deployments of dozens of instruments and would have perhaps hundreds of
elements with an indefinite number of processing steps and parent deployment
levels.
We are expecting many new types of more complex oceanographic in situ
instrumentation that will measure essential climate variables such as pH,
Nitrate, Carbon (in its various forms), particulate matter, and chlorophyll
proxies. Having such detailed information about the instruments and the
processing of their output is critical for understanding of the data. We
would like to associate this metadata with the original files contributed to
community archives and have it flow through to the THREDDS Data Servers
where we expect the data will be accessed.
Any advice or discussion on how to proceed would be appreciated.
Cheers,
Mike
--
Mike McCann
Software Engineer
Monterey Bay Aquarium Research Institute
7700 Sandholdt Road
Moss Landing, CA 95039-9644
Voice: 831.775.1769 Fax: 831.775.1736 http://www.mbari.org
On 9/25/09 11:01 AM, "Jonathan Gregory" <j.m.gregory@xxxxxxxxxxxxx> wrote:
> #37: Conventions for Point Observation Data
> -----------------------------+----------------------------------------------
> Reporter: caron | Owner: cf-conventions@xxxxxxxxxxxxxx
> Type: enhancement | Status: new
> Priority: medium | Milestone:
> Component: cf-conventions | Version:
> Resolution: | Keywords: point
> -----------------------------+----------------------------------------------
> Comment (by jonathan):
>
> Dear Nan
>
> The ancillary_variables attribute is intended to point from one data
> variable to another data variable which supplies point-by-point metadata.
> I agree that is appropriate for quality data; that is indeed one of the
> intentions of it, and it might be possible to use one of the standard name
> modifiers to identify it (CF 3.3 and Appendix C). It would be exactly as
> intended for quality data (T,Z) i.e. the same dimensions as the data
> variable. I agree that it seems natural to allow it also for metadata
> which has a subset of the dimensions of the data variable, and it doesn't
> appear to be excluded by the standard or the conformance requirements. If
> there is any possibility of the variable being useful as a coordinate, I
> think it would be fine and helpful to point to it with both the
> coordinates and the ancillary_variables attributes.
>
> Cheers
>
> Jonathan
cf-pointobsconvention archives: