Re: [cf-satellite] related to scanning direction

Here is the attached snapshot of one of the parameter.


On Wed, Aug 22, 2012 at 7:22 PM, ghansham sangar
<ghanshamsangar@xxxxxxxxx>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> 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
>>
>>
>> --
>> Tom Whittaker
>> University of Wisconsin-Madison
>> Space Science & Engineering Center (SSEC)
>> Cooperative Institute for Meteorological Satellite Studies (CIMSS)
>> 1225 W. Dayton Street
>> Madison, WI  53706  USA
>> ph: +1 608 262 2759
>>
>
>

Attachment: mt_snap1.PNG
Description: PNG image