Dear Rob,
I too am pleased to see that a discussion has started on the
representation
of satellite swath information. As Steve says, we are, just at the moment,
trying to work out how best to apply CF conventions to NetCDF datasets in
the
upcoming ESA Sentinel-3 instrument products.
Several topics have come to light, including:
1) How to describe the relationship between related product grid sizes,
for instance, between measurements at 500m * 500m resolution and
1km * 1km resolution, where four 500m cells fit exactly within a
1km cell, or with information held on coarser-resolution tie-point
grids,
2) A syntax to identify a relationship between variables in different
NetCDF files. Sentinel-3 will use the SAFE format, which implements
products mostly as a bundle of NetCDF files, where each contains a
distinct dataset. In some cases, referencing attributes such as
?coordinates? and ?ancillary_variables? would, ideally, point to a
variable in a different dataset.
3) Your comments on spectral response. I?ve included notional ?band_centre?
and ?bandwidth? scalar variables in the SLSTR products for the moment.
We also need names for TOA radiance and irradiance.
The GHRSST products will also be updated at the end of this year, in part
to better implement the CF conventions.
Regards,
Tim.
-----------------------------------------------------------------------
Tim Nightingale
Space Science and Technology Department
Rutherford Appleton Laboratory
Chilton, Didcot Phone: +44/0 1235 445914
Oxon OX11 0QX Fax: +44/0 1235 445848
United Kingdom Email: tim.nightingale at stfc.ac.uk
-----------------------------------------------------------------------
On 19/11/2009 12:45, "Stephen Emsley" <SEmsley at argans.co.uk> wrote:
> 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
> SEmsley at argans.co.uk <mailto:SEmsley at argans.co.uk>
> Derriford, Plymouth, PL6 8BY
> Skype?: 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: cf-metadata-bounces at cgd.ucar.edu
> [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of olivier lauret
> Sent: 19 November 2009 09:49
> To: Raskin, Rob (388M); cf-metadata at cgd.ucar.edu
> 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 : cf-metadata-bounces at cgd.ucar.edu
> [mailto:cf-metadata-bounces at cgd.ucar.edu] De la part de Raskin, Rob (388M)
> Envoy? : jeudi 19 novembre 2009 05:22
> ? : cf-metadata at cgd.ucar.edu
> 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
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> Cliquez sur l'url suivante
> https://www.mailcontrol.com/sr/URaG2M1d!ZvTndxI!oX7Uox5a7D76txBucO84elTRs7JKcs
> kQ9wv6+s46xKYZXbCVWq7qVKT17tjEfBJ2k7YZA==
> si ce message est ind?sirable (pourriel).
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Scanned by iCritical.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20091119/88f94025/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3622 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20091119/88f94025/attachment-0002.jpe>
Received on Thu Nov 19 2009 - 07:19:28 GMT
