Raskin, Rob (388M) 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
Hi Rob, thanks for starting this up.
We have done some preliminary thinking about the "swath feature type" in the
CDM data model, though we dont have any implementations.
A prototype coordinate system would look something like:
dimension:
scan = 1234;
xscan = 987;
wavelength = 123;
variables:
double lon(scan, xscan);
double lat(scan, xscan);
double alt(scan, xscan);
double time(scan);
double wavelength(wavelength);
byte data( scan, xscan);
data:coordinates = "lon lat time alt";
byte spectral( scan, xscan, wavelength);
spectral:coordinates = "lon lat time alt";
I think this should handle zigzags or grids, although perhaps adding a "scan
strategy" attribute would be good.
The geometry of each point is an interesting wrinkle, and may need some new
conventions. would a rotated ellipse work (3 params) or do we need a more
general polygon? Does it have to be specified per point, or can is be common to
all points? I would imagine that quick visualizers might ignore the details of
this (essentially assuming a tesselating grid), but more sophisticated and
specialized tools would need this.
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
