Hello Ghansham,
Yes, from an Earth perspective (latitude,longitude) the scanning
geometry is complicated. But, from an orbit and scanning perspective,
most polar satellites behave about the same.
Polar Orbits: They have high inclinations to cover the poles or low
inclination for the tropics.
Scanning: cross track for most instruments; conical for microwave [to
keep incidence angle constant].
So, the CF specification will need to include orbit information [the Two
Line Elements (TLE) define this] and scanning information [incidence
angle, sweep angle, etc.] so that the latitude/longitude can be
determined for each pixel.
Dave
On 8/22/12 8:52 AM, ghansham sangar wrote:
Hello Sir..
Hope you are doing fine.
I understand you point of frame of reference. Even I was also confused
when
I saw that dataset for the first time. But later I realized in one of
the conversation with
Tom Rink Sir, also, this is what came out (as told in earlier mail too):
The orbit has an inclination of as low as 20 deg (no coverage on poles).
The reason is to improve the temporal resolution over the tropics.
And the sensor scans across track w.r.t to such low inclination track.
And that is why the data is packed also in that manner (up down).
The best thing I can do is post one snapshot generated from toolsUI
of one
of the parameter displayed as image to have a better understanding of
what exactly
the data looks like. I know its a pretty tough scanning geometry to
understand.
regards
Ghansham
On Wed, Aug 22, 2012 at 2:35 AM, Tom Whittaker <whittaker@xxxxxxxx
<mailto:whittaker@xxxxxxxx>> wrote:
Hello Ghansham...
I hope you are well.
I believe the "scan direction" (either "up/down" or "left/right") is a
matter of perspective -- if the frame of reference is on the
satellite, looking "forward" along the flight path, then I would be
more inclined to say "left/right", as "up/down" would refer to some
vertical scanning -- from my frame of reference on the satellite.
Regarding CF Conventions. There are no conventions for dealing with
this. There have been discussions in the past dealing with "swath
data", and you might have a Google of that (plus 'netcdf') and see
what others have been thinking about.
There is also at least one reference to some data already being
written to hdf files, which might prove of interest. The sad fact is
that the satellite community for the longest time did not embrace
NetCDF, and so we must play "catch-up" with the people who have
defined conventions for model/gridded data and in-situ data.
My take is that some common characteristics (like 'band' and
'central_wavelength' (or _wavenumber) should be defined using
conventions and "standard_names", but that characteristics of
particular platforms must, by necessity, be defined for those
platforms. I also think that the use of the "standard_names" will go
a long way toward helping application developers in writing file
readers that can understand some of the basic structures of the data,
while at the same time providing end users an opportunity to write
specialized interfaces that meet their particular research or
operational needs.
Best wishes,
tom
