NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.
Peter, This issue with altitude is exactly why it is critical to include the geographic coordinate system used - both the horizontal and vertical datum. That's where the issue lies. It's not with the concept of altitude, per se. The problem you describe with different groups using the same object points out the importance of not over-describing a standard name. The units attribute can carry the units information, so if specification of units is not necessary when defining the standard name, don't do it. This can be quite a mess to navigate through, and I appreciate you and Aleksandar's (and others!) efforts to develop these standard names! Grace and peace, Jim Jim Biard Research Scholar Cooperative Institute for Climate and Satellites Remote Sensing and Applications Division National Climatic Data Center 151 Patton Ave, Asheville, NC 28801-5001 jim.biard@xxxxxxxx 828-271-4900 On Feb 20, 2013, at 10:40 AM, Peter Miu <Peter.Miu@xxxxxxxxxxxx> wrote: > Hi Jim, > > Thanks for the suggestions and further feedback. > > rectification_longitude and rectification_latitude sounds good. > > Regarding the altitude query, here is an extract of a discussion on altitude > presented to me by a colleague who is involved with expert groups at the WMO. > > -------------------- > platform_altitude is a very sensitive thing, especially for aircraft! Be > really careful. If you are approaching Frankfurt airport (112m above mean > sea level) and tell the pilot the platform_altitude is 120m she will be 8m > above the runway and on the point of landing. If you tell her that her > platform_altitude is 110m and she understands it as altitude, the plane will > crash. Generally (at WMO) we have very complex regulations about the datum > from which altitude is measured. Often you measure wind using a pole 10m > high: in this case you might think the platform_altitude is 10m but if the > pole is in EUMESAT's grounds (144m above msl) should we put 10m or 154m. > Nightmare stuff - heavily regulated - safety issues if you involve aircraft. > -------------------- > If you want to further understand the nightmare, then check out the WMO > tables: > > Tables are found under > http://www.wmo.int/pages/prog/www/WMOCodes/WMO306_vI2/LatestVERSION/WMO306_vI2_BUFRCREX_TableB_en.pdf, > in Class 7 for height as a coordinate and Class 10 for height as a measured > parameter. > -------------------- > > I completely agree with you regarding duplicating 'objects'. > > The problem I find is different groups use the same 'object' to describe > something specific to their needs. > If I propose a change to any attribute of the object (e.g. using cm instead > of m in the units) then I'm the bad guy and they want my head on a stick ;o) > > To overcome this, qualifying the name will reduce the ambiguity. > > I will discuss your input with my colleagues when updating the proposed names > and units, thanks. > > Regards, > > Pete. > > -----Original Message----- > From: cf-satellite-bounces@xxxxxxxxxxxxxxxx > [mailto:cf-satellite-bounces@xxxxxxxxxxxxxxxx] On Behalf Of > cf-satellite-request@xxxxxxxxxxxxxxxx > Sent: Wednesday, February 20, 2013 2:31 PM > To: cf-satellite@xxxxxxxxxxxxxxxx > Subject: cf-satellite Digest, Vol 28, Issue 5 > > Send cf-satellite mailing list submissions to > cf-satellite@xxxxxxxxxxxxxxxx > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.unidata.ucar.edu/mailman/listinfo/cf-satellite > or, via email, send a message with subject or body 'help' to > cf-satellite-request@xxxxxxxxxxxxxxxx > > You can reach the person managing the list at > cf-satellite-owner@xxxxxxxxxxxxxxxx > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cf-satellite digest..." > > > Today's Topics: > > 1. Re: cf-satellite Digest, Vol 28, Issue 2 (Jim Biard) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 20 Feb 2013 08:30:24 -0500 > From: Jim Biard <jim.biard@xxxxxxxx> > To: "cf-satellite@xxxxxxxxxxxxxxxx" <cf-satellite@xxxxxxxxxxxxxxxx> > Subject: Re: [cf-satellite] cf-satellite Digest, Vol 28, Issue 2 > Message-ID: <AE16D5CB-9770-4A54-A884-A9F5C2729B9D@xxxxxxxx> > Content-Type: text/plain; charset="us-ascii" > > Pete, > > Perhaps the terms rectification_longitude and rectification_latitude would be > better terms to use, since it seems that in your case these are not > necessarily the latitude and longitude of the satellite. It would bother me > to have the standard name "satellite longitude" used to describe something > which is not the longitude of the satellite. > > Regarding the altitude, in what way do you see the altitude of an airplane as > different from that of a satellite? In all my work in photogrammetry with > both, I have found no difference. > > The standard names, as I understand them, are intended to describe classes - > or types - of things. Taking an object-oriented approach to this, it is best > to avoid having multiple classes that differ only in name. If there is no > driving reason to differentiate satellite altitude from the altitude of any > other observing platform, isn't it best to avoid the duplication? > > Grace and peace, > > Jim > > Jim Biard > Research Scholar > Cooperative Institute for Climate and Satellites > Remote Sensing and Applications Division > National Climatic Data Center > 151 Patton Ave, Asheville, NC 28801-5001 > > jim.biard@xxxxxxxx > 828-271-4900 > > On Feb 20, 2013, at 5:23 AM, Peter Miu <Peter.Miu@xxxxxxxxxxxx> wrote: > >> Morning Jim, >> >> Thank you for your prompt and constructive comments. >> >> In simple terms, the sub-satellite point is a reference longitude and >> latitude point where the data is measured from. It may not be the actual >> longitude and latitude of the satellite. Internally at EUMETSAT, we call >> this the rectification point. I think its needed but will check if an update >> can be made to clarify this. >> >> The discussions we (internally, with our Met services, with our >> international partners and users) had before the submission of the proposal >> suggested we make the standard names satellite specific as it reduces >> ambiguity. For example the platform_altitude for aircraft is different to a >> satellite. From Mike Grant's feedback, we will look if the word platform >> should be replaced by satellite. >> >> A side comments is I'm not a meteorologist or a scientist but a software >> engineer, and whilst compiling these proposals, I endured many discussion on >> what 'things' mean so being specific removes ambiguity. Nevertheless, I >> will take your comments onboard check with the relevant forces here and see >> if updates can be made. >> >> Regards, >> >> Pete. >> >> ------------------------------ >> >> Message: 3 >> Date: Tue, 19 Feb 2013 13:35:55 -0500 >> From: Jim Biard <jim.biard@xxxxxxxx> >> To: cf-satellite@xxxxxxxxxxxxxxxx >> Subject: Re: [cf-satellite] EUMETSAT proposed CF convention updates to >> the Standard Names and Units for Satellite Data. >> Message-ID: <30695AF9-D6D6-43D8-B08F-2BD412550726@xxxxxxxx> >> Content-Type: text/plain; charset="windows-1252" >> >> A few comments/questions regarding the platform latitude, longitude, and >> altitude: >> >> Sub-satellite point means the intersection of a line from the center of the >> Earth to the satellite with the surface of the Earth. >> >> Is referring to the sub-satellite point necessary? At first glance, I think >> it isn't needed. >> >> I don't see a need to make any of these names satellite-specific. >> >> Use the word height instead of altitude in the definition for >> platform_altitude to avoid recursion (the altitude is the altitude). >> >> Latitude, longitude, and altitude should be considered in relation to the >> coordinate system defined for the file. I think it would be best to remove >> the reference to mean sea level from the definition of the altitude. It is >> the height above the coordinate system vertical datum, which might not be >> sea level. (In particular, if geometric heights on an ellipsoid are used, >> there can be significant differences. And, in fact, WGS84 and the WGS84 >> ellipsoid are often used in satellite work.) >> >> And while I'm at it, would it also be useful to include platform_x, >> platform_y, and platform_z in the set? These would be useful in the case >> where the coordinates are in Earth-centered Cartesian coordinates (ECF, >> ECI), as well as cases where a projected coordinate system was used. The >> projected coordinate case would clearly be for a subset of an orbit, but >> could still be completely valid. This would also be useful for other moving >> platform cases (aircraft, ships, etc). >> >> Grace and peace, >> >> Jim >> >> Jim Biard >> Research Scholar >> Cooperative Institute for Climate and Satellites >> Remote Sensing and Applications Division >> National Climatic Data Center >> 151 Patton Ave, Asheville, NC 28801-5001 >> >> jim.biard@xxxxxxxx >> 828-271-4900 >> >> On Feb 19, 2013, at 12:47 PM, Mike Grant <mggr@xxxxxxxxx> wrote: >> >>> On 19/02/13 15:00, Mike Grant wrote: >>>> To make replies easier and as some of us (normally me!) may be too lazy >>> >>> And now for a reply (comments inline).. >>> >>> First, did you coordinate with Aleksandar Jelenak's proposed new names? >>> They should be in the list archive for this list 19/Sept/2012 "New Standard >>> Names for Satellite Data" and for the main CF-metadata list on 7/Oct/2012 >>> "New standard names for satellite obs data" and summarised at >>> http://wiki.esipfed.org/index.php?title=Standard_Names_For_Satellite_Observations, >>> before it got derailed by string-based time variables debate. >>> >>> I think the platform ones fit well with your proposals (so perhaps you >>> already coordinated?) - perhaps by reincluding or referencing them in your >>> submission, you could rescue those parts from the time-string swamp. >>> >>> Either way, it may be wise to split these proposals into multiple parts to >>> ensure that the whole set aren't hung up on a single argument. Perhaps >>> split into 3 parts by platform, sensor and toa names? >>> >>>> azimuth_angle >>>> * degrees >>>> * Azimuth angle is the angle measured towards the east, from north, >>>> along the astronomical horizon to the intersection of the great circle >>>> passing through the point and the astronomical zenith with the >>>> astronomical horizon. >>>> >>>> platform_latitude >>>> * degrees_north >>>> * Latitude of the satellite measured at the sub-satellite point >>>> >>>> platform_longitude >>>> * degrees_east >>>> * Longitude of the satellite measured at the sub-satellite point >>>> >>>> platform_altitude >>>> * m >>>> * Altitude of the satellite above mean sea level >>> >>> If these are specifically about satellites, it may be worth renaming them >>> to satellite_XXX. I think it would be more useful to keep them as >>> platforms, in which case perhaps change the word "satellite" to "platform" >>> in the descriptions. >>> >>> Either way, it would be nice to more clearly define what's meant by the >>> "sub-satellite point" for non-specialists (CF is used by all sorts of >>> people) or, better, rephrase it in generic "platform" language. Is this >>> the position on the surface/geoid/ellipsoid (intersection of the line >>> between the platform location and the centre of the Earth with the >>> geoid/ellipsoid)? >>> >>> It might be worth stealing parts of the definition of the general term >>> "altitude" as it's nicely written: >>> "Altitude is the (geometric) height above the geoid, which is the reference >>> geopotential surface. The geoid is similar to mean sea level." >>> >>>> sensor_band_spectral_width >>>> * cm-1 >>>> * Bandwidth of the satellite?s spectral channel >>> >>> This also fits nicely with the sensor_band_ proposals Aleksandar made on >>> this list, but they didn't seem to go onto the CF list. Might be worth >>> rescuing too, unless Aleksander is reading and had another reason not to >>> submit? >>> >>> Again, it would be good to replace "satellite" with "sensor". Unless it's >>> intentionally vague, perhaps define more clearly what's meant by the >>> bandwidth (e.g. full width half max?) >>> >>>> toa_spectral_irradiance >>>> * mW m-2 (cm-1)-1 >>>> * "toa" means top of atmosphere; irradiance which is relevant for any >>>> sensor measuring in the UV-VIS and NIR. This parameter is reported by >>>> integrating over the whole sphere. >>> >>> Might be worth stealing wording from other standard definitions >>> incorporating irradiance, e.g. >>> >>> omnidirectional_spectral_spherical_irradiance_in_sea_water >>> - "spectral" means per unit wavelength or as a function of wavelength; >>> spectral quantities are sometimes called "monochromatic". Radiation >>> wavelength has standard name radiation_wavelength. Omnidirectional >>> spherical irradiance is the radiation incident on unit area of a spherical >>> (or "4-pi") collector. It is sometimes called "scalar irradiance". >>> Radiation incident on a 2-pi collector has standard names of "spherical >>> irradiance" which specify up/downwelling. >>> >>> In fact, perhaps the name should be >>> toa_omnidirectional_spectral_spherical_irradiance ? >>> >>>> toa_spectral_reflectance >>>> * 1 (dimensionless) >>>> * Ratio of radiance to irradiance I/I0, reflection from a thick layer >>>> where the layer, here the atmosphere, is part of the reflection's property. >>> >>> Stealing a few bits from toa_bidirectional_reflectance, perhaps.. >>> >>> Reflectance is the ratio of the energy of the reflected to the incident >>> radiation. "spectral" means per unit wavelength or as a function of >>> wavelength; spectral quantities are sometimes called "monochromatic". A >>> coordinate variable of radiation_wavelength or radiation_frequency can be >>> used to specify the wavelength or frequency, respectively, of the >>> radiation. "toa" means top of atmosphere. toa_spectral_reflectance is the >>> ratio of radiance to irradiance I/I0, reflection from a thick layer where >>> the layer, here the atmosphere, is part of the reflection's property. >>> >>>> toa_outgoing_inband_radiance >>>> * mW m-2 sr-1 >>>> * "toa" means top of atmosphere; "outgoing" means emitted toward outer >>>> space; the radiance is integrated over a discrete band. >>> >>> I think this one is quite new to CF (integrating over a band), so you're >>> probably setting a standard here. It may be worth saying that the band can >>> be specified by (e.g.) a coordinate variable or other ancillary data. >>> >>>> toa_reflectance >>>> * Percent >>>> * Ratio of the energy of reflected to incident light at the top of >>>> atmosphere. >>> >>> Steal most of the text from toa_bidirectional_reflectance? >>> >>> Should this be unitless, like toa_bidirectional_reflectance and >>> toa_spectral_reflectance? >>> >>> Ok, that was longer than I thought - hope it was helpful, but feel free to >>> take what you wish and reject what you don't. I think the splitting idea >>> may be worth it to avoid getting tied up in arguments though. >>> >>> Cheers, >>> >>> Mike. >>> >>> >>> Latest news: www.pml.ac.uk and @PlymouthMarine >>> >>> Plymouth Marine Laboratory (PML) is a company limited by guarantee >>> registered in England & Wales, company number 4178503. Registered Charity >>> No. 1091222. Registered Office: Prospect Place, The Hoe, Plymouth PL1 3DH, >>> UK. >>> This message is private and confidential. If you have received this message >>> in error, please notify the sender and remove it from your system. You are >>> reminded that e-mail communications are not secure and may contain viruses; >>> PML accepts no liability for any loss or damage which may be caused by >>> viruses. >>> >>> _______________________________________________ >>> cf-satellite mailing list >>> cf-satellite@xxxxxxxxxxxxxxxx >>> For list information or to unsubscribe, visit: >>> http://www.unidata.ucar.edu/mailing_lists/ >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> <http://mailman.unidata.ucar.edu/mailing_lists/archives/cf-satellite/attachments/20130219/8cfc6200/attachment.html> >> >> ------------------------------ >> >> _______________________________________________ >> cf-satellite mailing list >> cf-satellite@xxxxxxxxxxxxxxxx >> For list information or to unsubscribe, visit: >> http://www.unidata.ucar.edu/mailing_lists/ >> >> >> End of cf-satellite Digest, Vol 28, Issue 2 >> ******************************************* >> >> _______________________________________________ >> cf-satellite mailing list >> cf-satellite@xxxxxxxxxxxxxxxx >> For list information or to unsubscribe, visit: >> http://www.unidata.ucar.edu/mailing_lists/ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://mailman.unidata.ucar.edu/mailing_lists/archives/cf-satellite/attachments/20130220/1c436b1c/attachment.html> > > ------------------------------ > > _______________________________________________ > cf-satellite mailing list > cf-satellite@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ > > > End of cf-satellite Digest, Vol 28, Issue 5 > ******************************************* > > _______________________________________________ > cf-satellite mailing list > cf-satellite@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/
cf-satellite archives: