I agree that CF has enough things on its plate, and adding the ability
to internally define vertical datum specifications should not be yet
another one.
And so it is important to provide the means to reference existing
vertical datums. I think a single height_above_vertical_datum as a
standard name is more coherent (cogent?) than creating multiple
'height_above_' parameters, whether they're referring to a vertical
datum type (geoid, ellipsoid) or instance (WGS_84).
The height_above_vertical_datum concept lends itself to two cases: (1)
A vertical datum for the entire file; (2) different vertical datums
for different variables. I suppose the case of a vertical datum for
each measurement is fairly degenerate...). Having both cases
supported by attributes would be idea, it seems to me.
The vertical datum reference could be specified in several forms: (a)
a single URI for the vertical datum (or coordinate system
incorporating a vertical datum), (b) organization name + vertical
datum name or ID (note standard vocabularies often aren't defined for
the organization name, so if you want computers to understand, these
two terms would both need controlled vocabularies or some other unique
referencing specification, like URIs or other unique IDs), (c) an
internal reference to a CF-specified datum in the file, as for example
the extended grid concept mentioned earlier. (The last is only needed
to support existing CF specifications that are relevant, if any;
otherwise no need to worry about it.)
I suspect (a), the best choice IMHO, will be implementable within a
year if not months, but maybe is not usable today. Conceivably
attributes for both (a) and (b) could be created, and the user selects
whichever is most appropriate.
John
On Sep 11, 2008, at 10:31 AM, Ethan Davis wrote:
> Hi all,
>
> Jonathan Gregory wrote:
>> Dear Dale
>>
>> It seems none of us who has so far contributed claims to be an
>> expert. If any
>> experts are listening in, they are welcome to comment!
>>
>
> Yes, please.
>
>>> The recommendation is that I request a few new standard names.
>>> Standard names like height_above_geoid and
>>> height_above_reference_ellipsoid seem appropriate
>>>
>> Yes.
>>
>
> As I understand it, a vertical datum can be based on sea levels,
> ellipsoids, or gravitational models. I think it would be better to
> add height_above_vertical_datum rather than the two more specific
> terms above.
>
>>> Can one use in any variable an
>>> attribute normally found in the crs variable such as
>>> vertical_datum_name? For example
>>> float ht_wgs84
>>> ht_wgs84:long_name = "Height referenced to WGS84";
>>> ht_wgs84:standard_name = height_above_reference_ellipsoid
>>> ht_wgs84:vertical_datum_name = "World Geodetic System 1984"
>>>
>> vertical_datum_name is not a CF attribute. CF doesn't preclude
>> other attributes
>> being included, so that's fine, but software implementing CF would
>> not use
>> the attribute.
>>
>> In my earlier posting, I suggested that we could define the geoid by
>> extending the grid_mapping variable (CF 5.6). There is currently
>> not a standard
>> CF way to name the geoid or ellipsoid, but the ellipsoid can be
>> defined
>> geometrically by the grid_mapping variable. Any solution to this
>> would need
>> an addition to the CF standard.
>>
>
> Up to this point, grid mappings have only dealt with horizontal
> coordinates. I think the vertical datum information would fit better
> as attributes on vertical coordinates. That way it is closer to the
> actual coordinate variable and doesn't require a redirection to the
> grid mapping variable. This seems to more closely follow the lead of
> other CRS models (ISO and OGC, including Well-Known-Text) in keeping
> the vertical and horizontal coordinates separate. Combining a 2-D
> horizontal coordinate system and a 1-D vertical coordinate system to
> build a 3-D CRS. [With, as discussed earlier on this list I believe,
> an exception for the case where the 3-D CRS is fully based on an
> ellipsoid model of the earth. And for that we would need some way
> for the vertical coordinate to reference a grid mapping variable as
> the place the vertical datum is defined.]
>
>
> Dale you also asked:
>> In addition, there are locally derived datums that I assume are
>> derived by observation over a specific period of time (e.g. tide
>> datum epoch from1983-2001). Once again one can propose specific
>> standard names, e.g. height_above_mllw. If there is no attribute
>> like vertical_datum_epoch, then the epoch info could go in the
>> comments attribute, but that does not seem satisfying.
>
> I would rather see the definition and description of the vertical
> datum kept somewhere external to the data file and probably external
> to CF. With CF providing a place to reference the keeper of the
> vertical datum definition and an ID for the referenced vertical
> datum (maybe vertical_datum_authority and vertical_datum_name, or
> _id). Are there cases when a vertical datum is well defined but not
> used repeatedly so not worth standardizing? If so, then maybe CF
> should make it possible to capture that information.
>
> Thanks,
>
> Ethan
>
> --
> Ethan R. Davis Telephone: (303)
> 497-8155
> Software Engineer Fax: (303)
> 497-8690
> UCAR Unidata Program Center E-mail: edavis at ucar.edu
> P.O. Box 3000
> Boulder, CO 80307-3000 http://www.unidata.ucar.edu/
> ---------------------------------------------------------------------------
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
John
--------------
John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Interoperability Project:
http://marinemetadata.org
Received on Thu Sep 11 2008 - 11:53:04 BST
