Dear All, The topic of swath observations is of particular interest here at NOAA's NCDC. Ken Knapp, a scientist within our Remote Sensing Applications Division, has worked with CF for some time now and has expressed interest in a "channel" dimension, similar to John Caron's "wavelength" dimensions described below. He also mentioned the desire to address support for calibration tables. More details are forthcoming as I gain additional feedback and understanding.
Regards, Ken Roberts > Message: 2 > Date: Fri, 20 Nov 2009 05:24:01 -0700 > From: John Caron <[email protected]> > Subject: Re: [CF-metadata] Swath observational data > To: "[email protected]" <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > 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. > -- Ken P. Roberts Programmer Analyst, STG, Inc., Government Contractor Remote Sensing & Applications Division National Climatic Data Center 151 Patton Ave. Asheville, NC 28801-5001 Phone: (828) 271-4083 Fax: (828) 271-4328 [email protected]
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
