Re: [cf-satellite] cf-satellite Digest, Vol 28, Issue 6

NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.

Thanks Randy,

I will take your comments onboard when discuss it with my colleagues.

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 3:06 PM
To: cf-satellite@xxxxxxxxxxxxxxxx
Subject: cf-satellite Digest, Vol 28, Issue 6

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
      (rhorne@xxxxxxxxxxxxxxxxx)


----------------------------------------------------------------------

Message: 1
Date: Wed, 20 Feb 2013 09:06:02 -0500
From: "rhorne@xxxxxxxxxxxxxxxxx" <rhorne@xxxxxxxxxxxxxxxxx>
To: "Jim Biard" <jim.biard@xxxxxxxx>,   "cf-satellite@xxxxxxxxxxxxxxxx"
        <cf-satellite@xxxxxxxxxxxxxxxx>
Subject: Re: [cf-satellite] cf-satellite Digest, Vol 28, Issue 2
Message-ID: <79a7d00d$66d74035$3057f244$@excaliburlabs.com>
Content-Type: text/plain; charset="us-ascii"

Folks:

Don't mean to gum up the works here ...

Earth latitude / longitude / altitude are not always the best coordinates
to use for where the satellite is the center of the aperture of the
sensor.

I have been working on how to make space weather data, which are also
sensed by all types of satellites (e.g. geos, polars, etc), self-describing
and conforming with CF, and J2000 ECI coordinates has advantages.  Note
that these sensing apertures don't point at the Earth.

The implication being that codifying latitude and longitude in the name
mean that more standard names will be needed for these cases.

Also, regarding standard names for the space-based sensing location ....
maybe something like observing_platform_location_x, etc...

I am also wondering whether there would ever need to distinguish between
the location of the satellite (which, if you split hairs, can mean several
things), and the point of rectification (or the center of the sensor
aperture).  The reason I say this revolves around the mapping accuracies
for environmental data do not demand such precision.

very respectfully,

randy

----------------------------------------
 From: "Jim Biard" <jim.biard@xxxxxxxx>
Sent: Wednesday, February 20, 2013 8:30 AM
To: "cf-satellite@xxxxxxxxxxxxxxxx" <cf-satellite@xxxxxxxxxxxxxxxx>
Subject: Re: [cf-satellite] cf-satellite Digest, Vol 28, Issue 2

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_Observa
tions, 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/attachm
ents/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/c2e93148/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 6
*******************************************



  • 2013 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the cf-satellite archives: