This question certainly pops up on a regular basis.
After a discussion on the MMI 'Ask' metadata discussion list, OceanSITES
decided to add 2 attributes to the Z axis variable, one is 'reference',
which
is intended for human readers, and the other is
'coordinate_reference_frame',
which contains a URN that holds the definition of the 3D coordinate
reference
system, which is, at least according to the EPSG, more useful than a simple
datum.
We are dealing only with data relative to instantaneous sea surface; we
don't have
a mechanism for describing height above the sea floor, which we may need
soon.
DEPTH:reference=<R>;
where currently vetted values for R are "mean_sea_level",
"mean_lower_low_water",
"wgs84_geoid" and the default, "sea_level".
DEPTH:coordinate_reference_frame="urn:ogc:crs:EPSG::5831"; or
HEIGHT:coordinate_reference_frame="urn:ogc:crs:EPSG::5829";
5831 and 5829 can be resolved at
http://www.epsg-registry.org/ but are not
meant for human information. They're defined as 'depth (or height)
relative to instantaneous
water level, uncorrected for tide.'
We'd be happy to implement this differently, if CF comes up with a scheme.
Thanks - Nan
On 2/4/14 10:08 AM, Jonathan Gregory wrote:
> Dear Rich
>
> Nothing further has been done in CF about this, but I'd be glad if it could be,
> since it is often asked. I think there is no reason not to do something, since
> there is an evident need, if we could only agree what should be done, and the
> main problem is getting a sufficient understanding of these complexities. So
> I can only repeat my last para in the email you point to:
>
>> The discussion stalled because we didn't really understand what "vertical
>> datum" means! ... [If this concerns the definition of the geoid], we should
>> extend grid_mapping so it can identify the geoid by name, perhaps also giving
>> a URN as you say. Unlike the ref ellipsoid, the geoid cannot be specified
>> by metadata, as it's too complicated!
> Is that the answer to your question of yesterday? i.e. would it suffice to
> specify that by "geoid" in this data, "NAVD88" was meant? Of course, in other
> datasets, geoid might mean a different definition. Specifying which geoid is
> meant is not always possible (for instance in the case of model data), but we
> could make it possible if that's useful. Is NAVD88 not a geoid name in your
> example?
>
> Best wishes
>
> Jonathan
>
> ----- Forwarded message from "Signell, Richard" <rsignell at usgs.gov> -----
>
>> On a telecon yesterday with a coastal inundation modeling group, one
>> of the PIs asked me how to handle vertical datums in NetCDF --
>> specifically where to specify that the model bathymetry and water
>> levels were were relative to NAVD88. I wasn't sure how to reply.
>>
>> Was there any resolution to the 2nd half of this question asked back in 2011?
>> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2011/054483.html
>>
>> I looked at the draft 1.7 spec, and the only vertical datum reference
>> info I found was the ability to specify VERT_DATUM in the new CRS
>> well-known-text (WKT) section:
>> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.7-draft1/ch05s06.html#idp5644304
>>
>> Is this how we should specify the vertical datum in CF, using VERT_DATUM in WKT?
>>
>> Thanks,
>> Rich
>> --
>> Dr. Richard P. Signell (508) 457-2229
>> USGS, 384 Woods Hole Rd.
>> Woods Hole, MA 02543-1598
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> ----- End forwarded message -----
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
*******************************************************
* Nan Galbraith Information Systems Specialist *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 (508) 289-2444 *
*******************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140204/67854291/attachment-0001.html>
Received on Tue Feb 04 2014 - 10:51:21 GMT
