I'm a bit confused.
I'm interpreting Wenli's comments to mean that because a slice operation
will put an onus on the server to construct and make available a CRS
definition which is different than the one used by the offered coverage,
some implementers will wish to either limit or disallow slicing on their
coverages. The means he seams to be envisioning for doing so is the same
means by which a coverage would be reprojected, i.e., by offering a list
of CRS'es in which the coverage or its subsets may be requested. Up
until now, my understanding was that this functionality would not be in
the core. Can you clarify what you mean, Peter? Are you moving the slice
operation to an extension (my recommendation)?
Max
________________________________
From: Peter Baumann [mailto:p.baumann@xxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, June 17, 2010 1:27 PM
To: Wenli Yang
Cc: Max Martinez; Steven Keens; Unidata GALEON
Subject: Re: [galeon] how to handle "slicing" through n-D cubes?
Wenli-
absolutely on board, this is the way it will be in the Core.
-Peter
Wenli Yang wrote:
Peter,
As I mentioned in yesterday's meeting. If core requires slicing, it
would also require offering of a CRS different from the offered
coverage's original (or native/etc) CRS. Other than that, I think
slicing is a good function, i.e., we can say an output coverage being 2D
(x,Y) instead of 4D (1,1,X,Y). Of course, information on the locations
of the trimmed 2Ds should still be provided somewhere in the coverage.
Wenli
________________________________
you're right, Max. I missed to add that, thanks for clarifying.
What I wanted to say is that with the mimics chosen we can support both
use cases.
-Peter
Max Martinez wrote:
I read his
response differently. His
description sounds to me that the equivalent behavior in a WCS
would be
to trim
with a coincident upper and lower bound and return a coverage
with the
same
dimensionality and CRS just a whole bunch of data trimmed out of
it.
They
wouldn't use a slice.
Perhaps I'm
misunderstanding his
response.
________________________________
From:
Peter Baumann [mailto:p.baumann@xxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, June
17, 2010
10:36 AM
To: Steve Hankin
Cc: Unidata GALEON;
Steven Keens;
Max Martinez
Subject: Re: [galeon]
how to
handle "slicing" through n-D cubes?
Steve,
thanks again for explaining to me how your community handles the
case.
In the end we agreed to go as follows in WCS:
- the slicing operation defines which axes remain in the output
coverage
- the server is obliged to provide some fitting CRS for the
resulting
axis
constellation (essentially, this only says: return a consistent
coverage)
This should give degree of freedeom to servers to respond with
something
appropriate for their situation, and it allows us to keep all
the
intricate CRS
issues out of the core.
>From what I understand when reading the page you list below
this is
compatible
with our approach chosen.
So thanks again, that helped.
-Peter
Steve Hankin wrote:
Peter Baumann wrote:
Steve-
thanks a lot for taking time on this. Some questions inline:
Steve Hankin wrote:
Hi Peter,
I'll start the ball on this with a short answer.
CF datasets are self-describing. They do not reference a
controlled
vocabulary of coordinate reference systems external to the file.
Thus a
CF subset of a valid CF dataset is always another valid CF
dataset and
its geo-location is self-describing -- even if it has fewer
dimensions
than the parent file. The question you are asking does not
really apply
to CF datasets "in their native habitat".
I see. Does this inline description change
during
subsetting? I.e., when you are building 2-D slices (just as an
example)
is
elevation and time information removed from the embedded CRS
information? (They
may well remain somewhere in a metadata description, this is not
our
concern
for now.)
If we imagine extracting (say) a single 2D
slice in
the XT (lon-time) plane from a 4D XYZT dataset, then the Y and Z
axes
are
conceptually reduced to single points ("projected"). A well
constructed CF dataset will include single point axes (*) for Y
and Z,
just as
it includes multi-point axes for X and T. We sometimes speak of
the 2D
slice as being a degenerate
4D
dataset, since it still possesses the full 4D coordinate
machinery.
The way in which the slice is embedded into the larger
coordinate
system
remains self-describing.
In a similar manner, an in situ observation of a vertical
profile or of
a time
series may simply be regarded as a degenerate 4D dataset. With
this
outlook
broad classes of data may legitimately be thought of as
"gridded"
(though using that term would lead to confusion in some
circles). This
is
part of the power of the netCDF data model -- that it unifies
the
representation and semantics of so many different types of
features.
(*) footnote to say that there is a also a short-hand way to
represent
scalar
axes in CF ... but using it doesn't alter the self-describing
nature of
the
file.
- Steve
Echoing your question back: CF 1.2 (??) added a section on
"5.6. Grid
Mappings and Projections Horizontal Coordinate Reference
Systems", which
is specifically to handle the associations between CF datasets
and the
corresponding crs.
(http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.ht
ml#grid-mappings-and-projections).
Should this mapping be refined to address solutions to 4D (n-D)
subsetting that you have developed in WCS?
Interesting to read this, it helps us to
understand
your approach. Actually, we are not yet in a position to answer
this
question,
currently we are trying to disentangle issues of slicing
functionality
and CRS
handling (the former we would like to have in the core, the
latter in
an
extension). We will gladly come back for this reverse discussion
once
we have
something in our hands.
-Peter
- Steve
=============================
Peter Baumann wrote:
Hi community,
in the WCS group we are wondering how you deal with subsetting
operations in n-D data spaces - obviously a result with less
dimensions than the original cube needs to get a different CRS
associated. How do you find the appropriate result CRS, for
example,
for a x/t cut from an x/y/z/t cube?
thanks in advance for any bits of wisdom,
Peter
--
Dr. Peter Baumann
- Professor of Computer Science, Jacobs University Bremen
www.faculty.jacobs-university.de/pbaumann
mail: p.baumann@xxxxxxxxxxxxxxxxxxxx
tel: +49-421-200-3178, fax: +49-421-200-493178
- Executive Director, rasdaman GmbH Bremen (HRB 147737)
www.rasdaman.com, mail: baumann@xxxxxxxxxxxx
tel: 0800-rasdaman, fax: 0800-rasdafax, mobile:
+49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola
incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui
soli destinata, nec preripiat quisquam non sibi parata." (mail
disclaimer, AD 10xx)
--
Dr. Peter Baumann
- Professor of Computer Science, Jacobs University Bremen
www.faculty.jacobs-university.de/pbaumann
mail: p.baumann@xxxxxxxxxxxxxxxxxxxx
tel: +49-421-200-3178, fax: +49-421-200-493178
- Executive Director, rasdaman GmbH Bremen (HRB 147737)
www.rasdaman.com, mail: baumann@xxxxxxxxxxxx
tel: 0800-rasdaman, fax: 0800-rasdafax, mobile:
+49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola
incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui
soli destinata, nec preripiat quisquam non sibi parata." (mail
disclaimer, AD 10xx)
--
Dr. Peter Baumann
- Professor of Computer Science, Jacobs University Bremen
www.faculty.jacobs-university.de/pbaumann
mail: p.baumann@xxxxxxxxxxxxxxxxxxxx
tel: +49-421-200-3178, fax: +49-421-200-493178
- Executive Director, rasdaman GmbH Bremen (HRB 147737)
www.rasdaman.com, mail: baumann@xxxxxxxxxxxx
tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis
ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli
destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD
10xx)
--
Dr. Peter Baumann
- Professor of Computer Science, Jacobs University Bremen
www.faculty.jacobs-university.de/pbaumann
mail: p.baumann@xxxxxxxxxxxxxxxxxxxx
tel: +49-421-200-3178, fax: +49-421-200-493178
- Executive Director, rasdaman GmbH Bremen (HRB 147737)
www.rasdaman.com, mail: baumann@xxxxxxxxxxxx
tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis
ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli
destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD
10xx)
