NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.
Hi. I'm currently building such a product for the NPP VIIRS sensor. It is, strictly speaking, a NOAA Level 1b data set. I am storing the satellite position, velocity, and attitude data with the measurement data, but for various reasons (including space considerations) I am storing the parameters needed for calibration and geolocation algorithms in a separate file. Just for the record, the definitions of the various NOAA data product levels, as defined in the Federal Geographic Data Committee (FGDC) Content Standard for Digital Geospatial Metadata (CSDGM): Extensions for Remote Sensing Metadata (FGDC-STD-012-2002) are: Level 0 data products are unprocessed telemetry data as received from the observing platform excluding communications artifacts introduced by the ground system. Level 1a data products are telemetry data that have been extracted but not decommutated from Level 0 and formatted into time-sequenced datasets for easier processing. The Level 1a formats are NOAA's internal formats and are only used for NOAA processing. They only exist briefly for the purpose of creating the Level 1b datasets. Levels 2-4 are the same as NASA levels 2-4. Level 1b data products are discrete, instrument-specific datasets derived from Level 1a containing unprocessed data at full resolution, time-referenced, and annotated with ancillary information including data quality indicators, calibration coefficients and georeferencing parameters. Level 2 data products are derived geophysical variables at the same resolution and locations as the Level 1 source data. Notice that Level 1b products have been "decommutated" (split up into variables), but no calibrations or geolocations have actually been done. NASA's definitions (which are also defined in the standard) are somewhat different. The NASA equivalent for such a data product is Level 1A. Grace and peace, Jim Jim Biard Research Scholar Cooperative Institute for Climate and Satellites Remote Sensing and Applications Division National Climatic Data Center 151 Patton Ave, Asheville, NC 28801-5001 jim.biard@xxxxxxxx 828-271-4900 On Aug 22, 2012, at 2:01 PM, David Santek wrote: > Yes, when you have an L1 file, lat/lon by pixel is necessary for the reasons > you and Jim state. > > But, will the CF conventions also be applied for a more raw format (Level 0) > where orbit and scanning information would be useful to carry along? > > Dave > > On 8/22/12 11:20 AM, Armstrong, Edward M (388M) wrote: >> Hi, >> >> I just wanted to add that from the perspective of a satellite data center >> where I work, our experience is that the user generally wants to start >> working with the data as quickly as possible. Thus, its best to have an >> explicit lon/lat for every pixel in L1/L2 data or a very very simple way to >> interpolate it. >> >> I think specifying scanning geometry in CF is overly complex and will be >> probably not be used very much (and confuse some folks). I do agree that >> these characteristics must be captured "upstream" in other metadata formats >> for data/algorithm provenance purposes. >> >> >> On Aug 22, 2012, at 7:41 AM, Jim Biard wrote: >> >>> Hi. >>> >>> From my experience, the algorithms used to determine the ray vector for >>> each pixel is quite complicated and different for each satellite. I doubt >>> there is a useful way to encode the necessary information in a standard >>> format. In addition, for LEO satellites (non-geostationary), the TLE is >>> not sufficient for the accuracy needed. I know that is the case for the >>> NPP VIIRS and CrIS instruments, and it's also true for the commercial >>> imaging satellites. You need a corrected time series of satellite >>> position, velocity, and attitude covering the path over the time the image >>> was acquired. And you then need a significant amount of information about >>> the sensor geometry and position on the satellite frame relative to the >>> satellite center of motion. You may want to store all of the needed >>> information in the file, but you won't be using generic software to turn it >>> into geolocations. (Well, you might be able to, but that will require >>> developing an abstract sensor model and a set of parameters to that model >>> that are sufficient to handle any satellite. This is akin to the issue >>> with geographic coordinate systems. There are so many different ways that >>> these have been defined that there is no single model that fully handles >>> every case.) >>> >>> Grace and peace, >>> >>> Jim >>> >>> Jim Biard >>> Research Scholar >>> Cooperative Institute for Climate and Satellites >>> Remote Sensing and Applications Division >>> National Climatic Data Center >>> 151 Patton Ave, Asheville, NC 28801-5001 >>> >>> jim.biard@xxxxxxxx >>> 828-271-4900 >>> >>> On Aug 22, 2012, at 10:05 AM, David Santek wrote: >>> >>>> 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> 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 >>>>> >>>> > > _______________________________________________ > cf-satellite mailing list > cf-satellite@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/
cf-satellite archives: