⇐ ⇒

[CF-metadata] Why "surface_altitude" instead of "platform_altitude"?

From: Signell, Richard <rsignell>
Date: Fri, 19 Sep 2014 09:55:42 -0400

Jonathan,

This all makes sense to me. If you would be willing to propose the
ticket, I would definitely support it.

-Rich

On Fri, Sep 19, 2014 at 9:37 AM, Jonathan Gregory <j.m.gregory at reading.ac.uk
> wrote:

> Dear John and Rich
>
> I think platform_altitude would be fine as a standard name. Altitude means
> above the geoid. CF does not define a default geoid. At present it is not
> possible to specify what geoid is being used (if you wish to be precise)
> but
> we have discussed this a few times before. I append some stuff which I
> wrote
> in an email to Rich and others in May. To implement this would require a
> trac
> ticket, proposing to define a geoid_name attribute in Appendix F for the
> grid_mapping variable. I will propose the ticket if you'd support it.
>
> Best wishes
>
> Jonathan
>
> * Vertical coordinate variables generally have CF standard_name attributes
> (standard_names are recommended, though not mandatory). The standard_name
> defines the vertical coordinate relative to a geophysically described
> surface
> e.g. geoid, ellipsoid, mean sea level, surface (= bottom of atmosphere).
> Hence
> it would be redundant to identify the vertical datum in a geophysical way
> in
> any other part of CF metadata. I mean, for instance, CF does *not* have
> vertical coordinate variables of "height" generically. The "height" is
> always
> defined as being wrt a geophysical surface. (The standard_name of height
> means specifically height above the surface i.e. land or sea surface.)
>
> * Some of these special surfaces, especially ellipsoid and geoid, need more
> precise definitions for some purposes. The existing CF grid_mapping
> mechanism
> can define the ellipsoid in terms which translate obviously to WKT terms
> (see
> ticket 80 http://kitt.llnl.gov/trac/ticket/80. (This ticket is agreed but
> not
> yet implemented in the CF standard document.) It would be easy, and I think
> logical, to add an attribute of geoid_name to identify the geoid.
>
>
> ----- Forwarded message from John Caron <caron at ucar.edu> -----
>
> > Date: Thu, 18 Sep 2014 14:01:15 -0600
> > From: John Caron <caron at ucar.edu>
> > To: "Signell, Richard" <rsignell at usgs.gov>
> > CC: CF Metadata List <cf-metadata at cgd.ucar.edu>, John Graybeal
> > <john.graybeal at marinexplore.com>
> > Subject: Re: [CF-metadata] Why "surface_altitude" instead of
> > "platform_altitude"?
> >
> > As I recall, the original proposal was for station_altitude. We decided
> to
> > change "station" to "platform". At the same time it was thought that the
> > existing standard name of "surface altitude" would be synonymous. I at
> > least was thinking of ground stations. So I think we make a mistake there
> > and "platform_altitude" would be the right correction.
> >
> > An altitude of course needs a datum, and I think we have not been clear
> > enough on that. I think we should review our use or non-use of vertical
> > datum. A quick look seems to imply that "WGS 84" is assumed (?)
> >
> > On Thu, Sep 18, 2014 at 1:42 PM, Signell, Richard <rsignell at usgs.gov>
> wrote:
> >
> > > John,
> > > So then the surface needs to be defined relative to some known datum,
> no?
> > >
> > > Maybe we need platform_altitude_above_datum and a specification of
> > > the vertical datum (EPSG:5701 (MSL), EPSG:5703 (NAVD88), etc)
> > >
> > > On Thu, Sep 18, 2014 at 1:47 PM, John Graybeal
> > > <john.graybeal at marinexplore.com> wrote:
> > > > I assume surface_altitude is an important variable for providing the
> > > vertical location of measurements relative to a surface (as opposed to
> > > relative to a geoid -- notwithstanding the definition issue).
> > > >
> > > > John
> > > >
> > > > On Sep 18, 2014, at 08:30, Signell, Richard <rsignell at usgs.gov>
> wrote:
> > > >
> > > >> Maybe a simpler approach would be to just adopt "platform_altitude"
> as
> > > >> an alias for "surface_altitude" and suggest deprecating the use of
> > > >> "surface_altitude"?
> > > >>
> > > >> On Thu, Sep 18, 2014 at 11:15 AM, John Graybeal
> > > >> <john.graybeal at marinexplore.com> wrote:
> > > >>> Interesting that there is so little discussion of this language in
> the
> > > mail list, only in John Caron's 2011.09.16 mail on standard names for
> > > stations (which refers to words already in draft 1.6, I think) -- which
> > > came at the tail end of a long thread on platform names/IDs.
> > > >>>
> > > >>> From those words, I infer that the original drafter thought
> > > surface_altitude was just as good for describing platform location, as
> it
> > > was for describing observation location. I suspect the assumption was
> that
> > > any corresponding observations were at the same location as the
> platform.
> > > >>>
> > > >>> Since this is not always true, I'm with you that there should be a
> > > term platform altitude, and it should be the one used in this sentence.
> > > >>>
> > > >>> I hereby propose the standard name platform_surface_altitude (m),
> > > "Standard names for platform describe the motion and orientation of the
> > > vehicle from which observations are made e.g. aeroplane, ship or
> satellite.
> > > >>> The surface called "surface" means the lower boundary of the
> > > atmosphere. Altitude is the (geometric) height above the horizontal
> > > reference surface."
> > > >>>
> > > >>> Note I've changed the standard wording of the _altitude definition,
> > > which generally says ".. above the geoid, which is the reference
> > > geopotential surface. The geoid is similar to mean sea level." This
> seems
> > > clearly in conflict with the definition of surface_altitude and this
> new
> > > term, and I think it should be changed in surface_altitude's
> definition too.
> > > >>>
> > > >>> I suppose if people agree with you and me, we need to do a Trac
> ticket
> > > for the corresponding change to the standard.
> > > >>>
> > > >>> John
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Sep 18, 2014, at 06:40, Signell, Richard <rsignell at usgs.gov>
> wrote:
> > > >>>
> > > >>>> In the CF-1.6 and CF-1.7 draft doc, in section H.2, we have:
> > > >>>>
> > > >>>> "It is recommended that there should be station variables with
> > > >>>> standard_name attributes " platform_name ", " surface_altitude "
> and ???
> > > >>>> platform_id ??? when applicable."
> > > >>>>
> > > >>>> Why is this "surface_altitude" instead of "platform_altitude"?
> > > >>>>
> > > >>>> In the ocean, we have lots of upward-looking Acoustic Doppler
> Current
> > > >>>> Profilers (ADCP), where the instrument with transducer and other
> > > >>>> sensors is located some distance below the ocean surface. While
> > > >>>> velocity and other properties are measured in vertical bins above
> the
> > > >>>> instrument (timeSeriesProfile), other properties like pressure and
> > > >>>> temperature are measured at the instrument.
> > > >>>>
> > > >>>> Since the instrument is not at the surface, it seems misleading
> to use
> > > >>>> the standard_name "surface_altitude" instead of
> "platform_altitude",
> > > >>>> particularly when we already have "platform_name" and
> "platform_id".
> > > >>>>
> > > >>>> In this example CF_1.6 ADCP dataset:
> > > >>>>
> > > >>>>
> > >
> http://geoport.whoi.edu/thredds/dodsC/usgs/data2/rsignell/data/adcp/7201adc-a_cf16.nc.html
> > > >>>>
> > > >>>> the variable "platform_altitude" has a value of -10.4522 m:
> > > >>>>
> > >
> http://geoport.whoi.edu/thredds/dodsC/usgs/data2/rsignell/data/adcp/7201adc-a_cf16.nc.ascii?platform_altitude
> > > >>>>
> > > >>>> but we are forced to use a standard_name of "surface_altitude".
> > > >>>>
> > > >>>> Why not "platform_altitude"?
> > > >>>>
> > > >>>> 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
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Dr. Richard P. Signell (508) 457-2229
> > > >> USGS, 384 Woods Hole Rd.
> > > >> Woods Hole, MA 02543-1598
> > > >
> > >
> > >
> > >
> > > --
> > > 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
> > >
>
> > _______________________________________________
> > 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
>



-- 
Dr. Richard P. Signell   (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140919/8aa5da45/attachment-0001.html>
Received on Fri Sep 19 2014 - 07:55:42 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:42 BST

⇐ ⇒