NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
I didn't meant to assess the implementation effort. I just meant to say that, when slicing is required, the core must also require, implicitly, a server be able to output coverage in more than one CRS. This later requirement shall involve additional parameters in the core, i.e., something an "available output CRS list" which includes at more than one CRS. A client will then define a request CRS (e.g., a 4D CRS) and a response CRS (e.g., a 2D CRS) when requesting slicing. Or, the specification may say that a change of CRS (e.g., 4D to 2D) is implicit and shall not be additionally indicated when slicing is requested. BTW, I like John's summary on the three encoding methods. But I guess that Peter's idea of introducing the slicing function is to reduce dimensionality. Thus, method 3 does not fit with slicing. It is the "trimming" operation by setting low=high. Method 2 still perceives the coverage as 4D and therefore perhaps still does not fit with slicing. Method 1 appears most matching the idea of slicing but some discussions seem warranted regarding where information on the "level" and "lat" is placed/encoded in the output coverage. --Wenli ----- Original Message ----- From: Max Martinez <Max.Martinez@xxxxxxxxx> Date: Thursday, June 17, 2010 2:03 pm Subject: RE: [galeon] how to handle "slicing" through n-D cubes? > I'm a bit confused. > > > > I'm interpreting Wenli's comments to mean that because a slice > operationwill 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 > sliceoperation 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 > locationsof 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 > bothuse 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.html#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) > > >
galeon archives: