⇐ ⇒

[CF-metadata] New Standard Names for Satellite Data

From: Aleksandar Jelenak - NOAA Affiliate <aleksandar.jelenak>
Date: Thu, 2 May 2013 13:51:14 -0400

Hello Randy,

On Thu, May 2, 2013 at 8:49 AM, rhorne at excaliburlabs.com
<rhorne at excaliburlabs.com> wrote:
> (1) standard_name: sensor_band_central_wavelength
>
> We have read the follow-up discussion regarding this proposed standard name.
> Consider the following:
>
> (a)
>
> The "center" wavelength could either be the mid-point in the band pass or
> the bandpass weighted mean value so even adding "central" would not
> necessarily resolve all possible ambiguities.

The term is "central", not "center". What are scientific uses of the
mid-point of a band interval? I have never heard anyone using the term
"central wavelength" to mean the mid-point in the context of remote
sensing sensors. Can you point me to some references?

> (b)
>[...]
> The applicable
> existing standard_name is radiation_wavelength with definition "The
> radiation wavelength can refer to any electromagnetic wave, such as light,
> heat radiation and radio waves."
>
> Because of these considerations, there is a good argument to be made to
> select a more general term for the center wavelength for a sensor band.
> E.g. "sensor_band_radiation_wavelength" as Jonathan proposed or even making
> due with the existing standard_name "radiation_wavelength". Note that the
> definition of sensor_band_radiation_wavelength could address the
> "terminology used within the community" concerns you bring up.

Why a more general term for central wavelengths? They are more
specific then just any wavelength in the EM spectrum because they
convey the spectral response of sensor detectors. What you are
suggesting to me is similar as asking why have sea_surface_temperature
name when just "temperature" would be enough.

Check, for example, the WMO Observing Systems Capability Analysis and
Review Tool's information on the ABI sensor:

http://www.wmo-sat.info/oscar/instruments/view/3

ans scroll down to the "Detailed characteristics" table. Ask them why
they use "Central wavelength" and not just "Wavelength".

> The other benefit of moving forward this way is that consistency of the
> standard_names related to this functional area is maintained.

I am all for consistency when justified but this is not such a case.

> (2) standard_name: sensor_band_identifier
>
> I took a look at the existing set of standard_names. There are no
> "identifiers".

There is always a first time for everything...

> Also note that band identifiers are program specific, and as
> you suggest can be any kind of alphanumeric string. (For GOES-R, it is a
> number from 1 to 16.) It raises the question why this needs to be a
> standard name. The only application we can think of is that there is a need
> to relate an alphanumeric string to a data variable or portion of a data
> variable. One does not need a standard_name to achieve this. In paragraph
> 4.5 Discrete Axis and paragraph 6.1 Labels of the CF standard there is
> discussion of a capability allowing a coordinate axis to be used to
> associate a character string to a data variable or subset thereof (i.e. a
> string-valued coordinate variable or string-valued scalar coordinate
> variable).
>
> Will this approach satisfy your need ? If not, could you further elaborate
> on what you are specifically trying to accomplish with the establishment
> standard_name ?

Like any other standard name, this one aims to increase data
interoperability and discovery by providing a hint what kind of data
is in such variables. Also, for microwave sensors, several bands can
differ only in measured polarization of the incoming signal and so a
numerical band coordinate variable will not suffice.

These "central" standard names were proposed by NASA, and endorsed by
NOAA, EUMETSAT, and the WMO's Global Space-based Inter-Calibration
System. These names were also vetted by the cf-satellite community and
no one objected the term "central". It is time to close this
discussion.

       -Aleksandar
Received on Thu May 02 2013 - 11:51:14 BST

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

⇐ ⇒