Upendra,
On 7/26/11 1:07 PM, Upendra Dadi wrote:
Jim,
Could you please clarify how to represent data which contain bands
with multiple spatial resolutions using you scheme? I am thinking of
MODIS data:
http://en.wikipedia.org/wiki/Moderate-Resolution_Imaging_Spectroradiometer#MODIS_Bands
As you can see, not all the bands have same spatial resolution (or
spatial dimensions), even though all of them have same units. Could we
even store all the bands in the same variable?
I think multiple resolutions in same variable would be difficult and
impracticable,
the CF conventions for defining Projections, analytic or lat/lon, don't
work like
this. You'd probably have to define another dimension to index the
different
resolutions for the data, lon and lat variables. I would think this
would be
pretty messy.
Tom
Upendra
On 7/26/2011 12:35 PM, Jim Biard wrote:
Edward,
Could you clarify what you are thinking of when talking about having
data counts and some form of per-pixel QC in the same variable? In
my mind, this would be an example of a situation where you would
have two variables - one for the data counts, and one for the
per-pixel QC. All elements of a variable must be measurements with
the same units. We shouldn't do anything to violate that convention.
You are right that this can be more generic than satellite image
data. I'd say it's not gridded data, since that already implies map
grids to too many people. The term that seems to be accepted is
swath data, and like you said, airborne scanners, digital imagery,
etc can all fit with no real problem. I believe that the general
thought is, "don't try to cover too much ground", and so we aren't
worrying too much about whether or not our solution is applicable in
someone else's domain. I've got some background in photogrammetry
though, so I keep those same thoughts in the back of my mind. If
things are clear without inserting the word satellite, we should
probably leave it out.
Grace and peace,
Jim
On 7/26/2011 11:57 AM, Edward.King@xxxxxxxx wrote:
Jim, Tom,
Great discussion. I have been particularly struck by the need,
pointed out by Tom, for a handle (name) for application developers
to grasp hold of, like 'band', or 'index' in Jim's example, that
triggers an exploration of a series of other variables that describe
parameters of each band.
It is fairly clear that there are examples where what appears to be
the natural 'band' coordinate does not easily record distinct
physical values (e.g. a multiband instrument with bands of different
widths but the same centre, or just multiple polarisations). But
even worse you may find sensor data counts and some form of
per-pixel qc in adjacent bands in the same variable, so the band
axis doesn't even have a homogeneous physical meaning. In that case
heading for something very generic, without physical units or
interpretation, seems like an idea that will be hard to break.
Also on the subject of standard names, and I know this is the
CF-satellite list, but aren't we really talking about something like
"gridded sensor channels" rather than "satellite image data"?
Practically everything that has been discussed is equally applicable
and relevant to airborne hyperspectral scanners, pre-launch sensor
simulators, or just plain old digital cameras. If we're going to
adopt a very generic stone, we might as well use it to kill as many
birds as we can.
Edward.
-----Original Message-----
From: cf-satellite-bounces@xxxxxxxxxxxxxxxx
[mailto:cf-satellite-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Jim Biard
Sent: Wednesday, 27 July 2011 12:57 AM
To: Tom Whittaker
Cc: cf-satellite@xxxxxxxxxxxxxxxx
Subject: Re: [cf-satellite] very rough draft of way to represent band
Tom,
I used "the_image" because I was too lazy to hunt up a proper name. I
think the standard name for the image data will vary widely
depending on
the contents. It could be brightness temperature, radiance, or
something else altogether. I don't think there will be a single
standard name.
In this example, there is no problem with sequential-valued coordinate
variables. The only true coordinate variable is the one named bandit.
The others are data variables that are identified as auxiliary
coordinates in the coordinates attribute of the image variable. These
variables can have values that repeat, alternate, etc. Everything is
driven by the parametric coordinate variable bandit. (Which, as I
suggested previously, could be an array of strings that uniquely named
the different bands instead of an array of integers. It functions as a
key.)
There are no end of questions that aren't answered by this bit of CDL,
but at least it gives us something to point fingers at. I'll try to
provide updates based on the results of discussion.
Jim
On 7/26/2011 10:28 AM, Tom Whittaker wrote:
Jim --
I like your summary. Based on that, here is what I see are the
specific points we need to propose (after we all agree on them, of
course):
1. several "standard_names" to accommodate our domain. From your
CDL example:
a. the_image (I am not in favor of this, but to answer Tom
Rink's question about when you have single-banded data, I think it is
essential to define a standard_name for "satellite image data")
b. band
c. radiation_polarization
d. radiation_bandwidth
e. radiation_central_wavelength
2. a new axis type that uniquely identifies this "dimension variable"
as such. I am concerned with John's declaration that coordinate
variables need to be monotonically increasing, because as has been
pointed out by you and Tom Rink, that is not always the case.
However, in your example, you use a sort of generic "index" as the
"axis type" -- I like that since it then allows for other variables to
be used as appropriate for the data.
I will look forward to hearing from other data providers, and John
Caron about the appropriateness of this idea. Thanks again for
putting this together, as it will be important to have several
examples on hand for people to refer to....
tom
On Tue, Jul 26, 2011 at 8:19 AM, Jim Biard<Jim.Biard@xxxxxxxx>
wrote:
Hi.
I thought it might be useful to throw out a very rough draft of
the sort of
thing I think we are talking about for representing bands. So
here is a bit
of CDL.
netcdf file:/san3/npp/jbiard/NcmlSamples/band_ideas.ncml {
dimensions:
bandit = 4;
lines = 5000;
samples = 5000;
variables:
float image(bandit=4, lines=5000, samples=5000);
:coordinates = "bandit polarization wavelength bandwidth";
:units = "W m-2";
:long_name = "the image";
:standard_name = "the_image";
short bandit(bandit=4);
:axis = "index";
:long_name = "band";
:standard_name = "band";
float wavelength(bandit=4);
:coordinates = "bandit";
:units = "um";
:long_name = "center wavelength";
:standard_name = "radiation_center_wavelength";
float bandwidth(bandit=4);
:coordinates = "bandit";
:units = "um";
:long_name = "bandwidth";
:standard_name = "radiation_bandwidth";
short polarization(bandit=4);
:coordinates = "bandit";
:units = "radians";
:long_name = "polarization";
:standard_name = "radiation_polarization";
}
--
Jim Biard
Government Contractor, STG Inc.
Remote Sensing and Applications Division (RSAD)
National Climatic Data Center
151 Patton Ave.
Asheville, NC 28801-5001
jim.biard@xxxxxxxx
828-271-4900
_______________________________________________
cf-satellite mailing list
cf-satellite@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
_______________________________________________
cf-satellite mailing list
cf-satellite@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
