Hi Rob, all,
This is a useful discussion, thanks for starting it. BTW, the ADAGUC
project in the Netherlands has defined a NetCDF format for along-track
data (
http://adaguc.knmi.nl/).
Just to increase the complexity a little - whereas many satellite
datasets can be represented in the way Rob describes (as a 2D
curvilinear grid, essentially) there are those that can't. For
example, I have SCIAMACHY data in which the instrument scans back and
forth as the satellite moves, essentially giving a zig-zag of
overlapping polygons. Not only that, the data are non-contiguous,
i.e. there are gaps.
In this case, the data can only be represented as a set of discrete
polygons, where each polygon is associated with an explicit time
instant. This representation can also handle gridded swath data,
although not as conveniently.
I'm not an expert in this field but I understand that the SCIAMACHY
data type is unusual, but not unique.
Cheers, Jon
On Thu, Nov 19, 2009 at 4:22 AM, Raskin, Rob (388M)
<robert.g.raskin at jpl.nasa.gov> wrote:
> 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
>
--
Dr Jon Blower
Technical Director, Reading e-Science Centre
Environmental Systems Science Centre
University of Reading
Harry Pitt Building, 3 Earley Gate
Reading RG6 6AL. UK
Tel: +44 (0)118 378 5213
Fax: +44 (0)118 378 6413
j.d.blower at reading.ac.uk
http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm
Received on Thu Nov 19 2009 - 05:53:56 GMT
