Dear Rob
I would like to join Olivier in asking if you know of other references to best
practices considering swath data and CF conventions. I am currently defining
the packaging format for optical data products for the ESA GMES Sentinel 3
mission (to replace ENVISAT MERIS & AASTR) and we are attempting to conform to
CF Convention.
Concerning multi-spectral data with respect to standard names. My understanding
was that you could define a co-ordinate, wavelength, with standard_name
radiation_wavelength and use this to assign corresponding channel wavelengths
(the canonical unit is metres) to the measurement data one is recording. Of
course this is not quite that simple as, for instance, the OLCI instrument on
Sentinel 3 has 21 channels with programmable centre wavelength and varying
ranges ... I was thinking that the 'bounds' attribute could handle this.
However, we are using SAFE packaging for end-user products with each channel
stored as a separate netCDF file so will distinguish wavelength in the naming
of these files.
As an aside, interesting the recent discussion on cell_methods has been
pertinent as what the CCD actually measures is the accumulation of photons over
the acquisition period and it is recorded at the end of that time period.
---
Dr Stephen Emsley
Tel: +44 (0)1752 764 289
ARGANS Limited
Mobile: +44 (0)7912 515 418
Unit 3 Drake Building
Fax: +44 (0)1752 772 227
Tamar Science Park
[email protected] <mailto:[email protected]>
Derriford, Plymouth, PL6 8BY
Skype(tm): archonsme
This message is to be treated as private and confidential, and the information
in it may not be used or disclosed except for the purpose for which it has been
sent. If you have received this message in error, please notify us and remove
it from your system.
ARGANS Ltd is a limited company registered in England & Wales.
Registered number: 6313966.
Registered address: Thatchers, Russells Water, Henley on Thames, Oxon, RG9 6EU
From: [email protected]
[mailto:[email protected]] On Behalf Of olivier lauret
Sent: 19 November 2009 09:49
To: Raskin, Rob (388M); [email protected]
Cc: didier earith
Subject: Re: [CF-metadata] Swath observational data
Dear Rob,
Good idea. I'm joining you in that way.
Some communities have already applied, or tried to apply, CF conventions to
swath data. I have in mind CNES/NASA/NOAA/EUMETSAT for satellite altimetry <L2
products, I believe that was also the case for GHRSST in the SST domain. Do you
know if there are other best practice that we can consider as references in
remote sensing swath data?
A digression for Opendap users: with my colleague D. Earith we made some
experimentations with aggregation of along-track altimetry products. In that
case the main dimension considered was time, and the altimetry product can
contains either 1 data/second or 20 data/second. The final result was that, in
that case, trying aggregation with Opendap server took lots of..time, too much
unfortunately.
Another digression about your ontological work: this is interesting. Have you
used OWL, or have you preferred SKOS? Is it visible somewhere on the internet?
Kind regards,
Olivier.
Olivier LAURET
CLS - Space Oceanography Division
8-10 rue Hermes, 31520 Ramonville St.Agne
France
Tel. (+33) (0) 561 39 48 51
Fax:(+33) (0) 561 39 47 80
-----Message d'origine-----
De : [email protected] [mailto:[email protected]]
De la part de Raskin, Rob (388M)
Envoyé : jeudi 19 novembre 2009 05:22
À : [email protected]
Objet : [CF-metadata] Swath observational data
While the Point observational conventions document is undergoing final review,
I want to initiate a discussion on a complementary topic - Swath observational
conventions. This model addresses satellite observational measurements and
potentially airborne measurements.
The Swath conceptual model is essentially a grid in spacecraft coordinates. One
dimension of this grid ("along_track") follows the path of the satellite.
Normally there are one or two additional dimensions: "cross_track" and/or
"vertical". The "cross_track" dimension is perpendicular to the satellite path,
as the instrument typically makes "side views" of the surface rather than just
at the nadir. The "vertical" dimension is present when a vertical profiler
instrument is used. CF:FeatureType will need to account for each possible
combination of these 2-D and 3-D swaths.
Typically, time is explicitly stored and associated only with the along-track
dimension. Spatial resolution generally will differ in the along_track and
cross_track directions.
Orbits are not mapped to files in any consistent way: a file might correspond
to a complete orbit, a half-orbit, or some other value. However, it is common
to explicitly consider yet another dimension: "satellite_node", with values
"ascending" (crosses equator going northward) and "descending" (crosses equator
going southward).
Common satellites are in sun-synchronous polar orbits such that the ascending
node remains at a near constant Local Solar Time (LST), while the descending
node remains at a near constant LST shifted by 12 hours. For example, the
ascending node may be at 6am LST and the descending node at 6pm LST. Often
gridded data products are produced from these swaths, with separate grids
corresponding to the AM and PM cases. A new CF time representation for "LST" is
required to indicate that the global data are all at a time such as 6am LST.
Unrelated to the swath geometry, some measurements use spectral band as an
independent variable, as they sample at multiple "channels". This capability
requires a new standard name for "spectral_band" or "spectral_channel" with
values that may be numeric, a numeric range, or string.
Swath data include many new dependent variables that correspond to engineering
parameters of the retrieval rather than geophysical parameters (point spread
function is a common example). If these names are standardized at all, they
should be indicated as being of the engineering type.
In the case of an airborne (rather than satellite) measurement, there is more
commonality with the "trajectory" representation from the Point observation
model. Hence, the focus here is on spacecraft measurements.
Finally, on an unrelated note, I have semantically mapped the entire CF
Standard Name list to an ontological representation. But that is the subject of
a separate communication.
-Rob
------------------------------------
Rob Raskin
Group Supervisor, Science Data Engineering and Archiving
Instrument Software and Science Data Systems Section
Jet Propulsion Laboratory
Pasadena, CA 91109
(818) 354-4228
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Cliquez sur l'url suivante
https://www.mailcontrol.com/sr/URaG2M1d!ZvTndxI!oX7Uox5a7D76txBucO84elTRs7JKcskQ9wv6+s46xKYZXbCVWq7qVKT17tjEfBJ2k7YZA==
si ce message est indésirable (pourriel).
<<image001.jpg>>
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
