Re: [galeon] how to handle "slicing" through n-D cubes?

Hello all:

In the CDM, which is more or less an implementation of the CF data model, we use the term 
"slice" to indicate that you want to reduce the dimensionality of the data variable, and 
"section" to indicate that the result is a subset with the same dimensionality, even if 
one or more dimensions have length 1. this sounds consistent with what you are proposing, AFAICT.

CF itself does not specify an API for subsetting, rather its an encoding standard. So if 
a WCS server was returning netCDF-CF in response to a WCS request, it would need to use a 
CF encoding consistent with WCS semantics. So if the "x/t cut from an x/y/z/t 
cube" was meant to indicate a reduced dimensionality, I might guess that the data 
variable would be returned as 2D, eg in netcdf CDL:

(1)

 float var(t, x);
   var:coordinates = "time lon";

 float time(t);
 float lon(x);

I think Steve is indicating (and I agree with him) that a better encoding would 
be:

(2)

 float var(t, x);
   var:coordinates = "time level lat lon";

 float time(t);
 float lon(x);
 float level;
 float lat;

where the value of the scalar coordinates level and lat are the ones specified 
in the slice.

The clients that we write would also be happy with:

(3)

 float var(t, z, y, x);
   var:coordinates = "time level lat lon";

 float time(t);
 float lon(x);
 float level(z);
 float lat(y);
where z and y are dimensions of length 1. But aesthetically I prefer (2). 
From a data model, (2) and (3) are equivalent, and different from (1). So even if a "slice" WCS 
request required returning a 2D data array, it seems to me that the "correct" CRS is 4D, or at 
least a "2D section (manifold) of the 4D domain".


Im guessing Ive replicated at least some of your previous discussion, but I 
thought it would be interesting to see what it looks like in CDL.


John



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.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 
<http://www.faculty.jacobs-university.de/pbaumann>
   mail: p.baumann@xxxxxxxxxxxxxxxxxxxx <mailto:p.baumann@xxxxxxxxxxxxxxxxxxxx>
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 147737)
   www.rasdaman.com <http://www.rasdaman.com>, mail: baumann@xxxxxxxxxxxx 
<mailto: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 
<http://www.faculty.jacobs-university.de/pbaumann>
   mail: p.baumann@xxxxxxxxxxxxxxxxxxxx <mailto:p.baumann@xxxxxxxxxxxxxxxxxxxx>
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 147737)
   www.rasdaman.com <http://www.rasdaman.com>, mail: baumann@xxxxxxxxxxxx 
<mailto: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 mailing list
galeon@xxxxxxxxxxxxxxxx
For list information, to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/ 

------------------------------------------------------------------------

_______________________________________________
galeon mailing list
galeon@xxxxxxxxxxxxxxxx
For list information, to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/