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 <[email protected]> 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 <[email protected]> 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 >> <[email protected]> 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 <[email protected]> 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 >>>> [email protected] >>>> 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 [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
