Thanks for clarifying the purpose of the standard names, John. I
earlier had the misunderstanding that I couldn't have more than one
variable with the same standard name in the same file, but I now see
that's ok.
I like that the values for coverage_content_type from ACDD 1.3 are
pulled from a controlled vocabulary. That's more than I had hoped for.
I'll give some more thought to whether to propose a new CF standard name
for the difference variable. I'm working with what I'd casually refer
to as "de-tided water level", the difference of a modelled tide from
observed water levels. I'm already using the standard name
"water_surface_height_above_reference_datum" (and it's required pair
"water_surface_reference_datum_altitude") for the in situ observations
(and now modelled values). And at some point in the not-to-distant
future, I'll be using "sea_water_pressure_at_sea_floor" for data
collected by a bottom pressure recorder.
Cordially,
Aaron
On 12/12/2014 12:46 PM, John Graybeal wrote:
> Just yesterday (really!) I was looking at the almost-ready ACDD 1.3
> convention, and saying "What is the 'coverage_content_type' attribute
> good for?" It appears to be good for almost exactly what you want.
> This attribute is 'highly recommended' for all NetCDF variables, and
> is defined as "An ISO 19115-1 code to indicate the source of the data
> (image, thematicClassification, physicalMeasurement,
> auxiliaryInformation, qualityInformation, referenceInformation,
> modelResult, or coordinate)." However, this covers only 2/3 of what
> you want: physicalMeasurement for in-situ observations, and
> modelResult for a value from a model. The difference is also a
> modelResult in my opinion, but that doesn't help your use case.
>
> If you are looking for a pure CF answer, there's not a complete
> answer, but there are standard names that refer to differences --
> these usually end with the phrase _anomaly (Definition: "anomaly"
> means difference from climatology."); or there's one, umm, anomaly
> that starts with difference_
> (difference_of_air_pressure_from_model_reference). Because the phrase
> _anomaly is already in 5 terms, it shouldn't be an issue to add more
> as needed. And that conveniently bridges the above gap in your use case.
>
> I think there's a reason CF names don't naturally distinguish between
> measured or observed values?CF names tend to describe the meaning of
> the value, and explicitly avoids saying how it was derived. The
> derivation is reserved to other attributes, like the 'source' (which
> should distinguish between a model and an observation, though not in a
> computable way), or 'history'.
>
> Hope that helps, at least a bit.
>
> John
>
> References:
> * ACDD 1.3 convention, almost done now:
> http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_1-3
> * coverage_content_type attribute:
> http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_1-3#coverage_content_type
> * purpose of a standard name:
> http://cfconventions.org/faq.html#stdnames_purpose
>
> ---------------
> John Graybeal
> Marine Metadata Interoperability Project: http://marinemetadata.org
> MMI Ontology Registry and Repository: http://mmisw.org/orr
>
>
>
> On Dec 12, 2014, at 11:01, Aaron Sweeney <aaron.sweeney at noaa.gov
> <mailto:aaron.sweeney at noaa.gov>> wrote:
>
>> Hi,
>>
>> I've looked through the latest CF Conventions and CF Standard
>> Names documents, but have been unable to find an answer (or example)
>> to the following question:
>>
>> How do I indicate that a variable representing a physical
>> quantity is an in situ observation, a value that came from a model,
>> or a difference or residual between an observation and a modelled
>> value (observed minus modelled)?
>>
>> My initial thought was to use the same standard name for each
>> variable, but provide a standard name modifier. But after reading
>> the appendix on modifiers, they seem to be used for something else.
>> The standard names themselves only describe the physical quantity,
>> but not whether or not they are an observed value or modelled value.
>>
>> Please point me toward the appropriate documentation, if it
>> exists. Thanks for your kind attention.
>>
>> Cordially,
>> Aaron
>>
>> --
>> Aaron D. Sweeney
>> Water Level Data Manager
>>
>> Cooperative Institute for Research in Environmental Sciences (CIRES)
>> University of Colorado at Boulder
>> and
>> NOAA National Geophysical Data Center
>> Marine Geology and Geophysics Division
>> 325 Broadway, E/GC3
>> Boulder, CO 80305-3328
>>
>> Phone: 303-497-4797, Fax: 303-497-6513
>>
>> DISCLAIMER: The contents of this message are mine personally and do
>> not necessarily reflect any position of NOAA.
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
Aaron D. Sweeney
Water Level Data Manager
Cooperative Institute for Research in Environmental Sciences (CIRES)
University of Colorado at Boulder
and
NOAA National Geophysical Data Center
Marine Geology and Geophysics Division
325 Broadway, E/GC3
Boulder, CO 80305-3328
Phone: 303-497-4797, Fax: 303-497-6513
DISCLAIMER: The contents of this message are mine personally and do not necessarily reflect any position of NOAA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20141212/deb7e18a/attachment-0001.html>
Received on Fri Dec 12 2014 - 16:26:07 GMT
