[Opendap-tech] Does the DAP standard accommodate geodesic grids and coordinate non-monoticity?

[Daily, Jeff A]

The 2.0 spec says that a Grid type is the only one that associates related arrays.  The spec would still need to be modified to say what metadata conventions it supports, such as CF.  The upside is it is likely easier to support metadata conventions than to support new data types.

So if CF conventions were supported...
A user projects for the variable "pressure" which is on a geodesic grid.  It has the "coordinates" CF attribute which points to "latitude" and "longitude" arrays.  So, given what we'd like to accomplish, all three arrays should be returned.

Is there a case for a client NOT wanting the associated variables even if supporting metadata conventions would say otherwise?

Jeff Daily
PNNL

-----Original Message-----
From: opendap-tech-bounces at opendap.org on behalf of Ethan Davis
Sent: Thu 5/1/2008 11:14 AM
To: James Gallagher
Cc: opendap-tech at opendap.org
Subject: Re: [Opendap-tech] Does the DAP standard accommodate geodesic grids and coordinate non-monoticity?
 
James Gallagher wrote:
> On May 1, 2008, at 11:07 AM, Peter Fox wrote:
>   
>> James,
>> Is this a DAP issue or a server side function issue, or both?
>>     
>
> Both. I think the DAP version and "NGrid" are DAP issues. Adding  
> server-side functions to perform geo-referenced selections of data  
> based on the values of the coordinate systems is probably a better  
> way to go than adding relops for arrays. As Ted Haberman pointed out  
> at the last developer meeting, here's a rich body of software out  
> there we can tap into to perform geographic selections and I think we  
> can 'hide' that behind our functional interface very easily.
>   

Are we talking about a DAP 2.1? Or would this go into DAP 4.0?

And is there a version of the spec that is targeted for providing some 
way to discover server-side functions?

>>>> Should the DAP specification be modified to allow for auxiliary
>>>> coordinate variables, and if so, what would this look like?
>>>>         
>>> I would suggest adding a new type that makes the relations explicit
>>> and modifying the spec so that there's some DAP version negotiation
>>> between client and server (with 'no negotiation' causing the server
>>> to assume DAP 2.0 - the current LCD). This will add the new feature
>>> (s) in a way that won't break old clients or hogtie new ones (except
>>> that new clients have to announce to the server they know a
>>> particular DAP version and might wind up talking to an older server).
>>>       

My concern here is the need for more and more new types and the 
reduction of interoperability that might bring. Would all new servers be 
required to have a fall-back representation for the new types? And what 
might those representations look like?

Which leads me to ask, would it be more flexible and less DAP version 
dependent to instead use attribute/metadata conventions for representing 
relationships between data variables and the variables that represent 
their coordinate systems?

>>>> It is unclear to me how to best represent our geodesic data using
>>>> the DAP constructor types.  Here's an example of our data as it
>>>> would appear using the current NetCDF handler and the DDS response:
>>>>
>>>> Dataset {
>>>>     Float32 cke[time = 3][level = 21][grid_cells = 10242];
>>>>     Float64 grid_area[grid_cells = 10242];
>>>>     Float64 grid_center_lat[grid_cells = 10242];
>>>>     Float64 grid_center_lon[grid_cells = 10242];
>>>>     Float64 grid_corner_lat[grid_cells = 10242][grid_corners = 6];
>>>>     Float64 grid_corner_lon[grid_cells = 10242][grid_corners = 6];
>>>>     Float32 level[level = 21];
>>>>     Float64 time[time = 3];
>>>> } cke.nc;
>>>>         

Unless I'm not understanding James' NGrid suggestions or the above 
example, I don't think Jeff's example (which looks like a square celled, 
unstructured grid) would fit into the NGrid type. James, did you mean 
something other than allowing multi-dimensional grid map (coordinate) 
variables?

Ethan

-- 
Ethan R. Davis                                Telephone: (303) 497-8155
Software Engineer                             Fax:       (303) 497-8690
UCAR Unidata Program Center                   E-mail:    edavis at ucar.edu
P.O. Box 3000
Boulder, CO  80307-3000                       http://www.unidata.ucar.edu/
---------------------------------------------------------------------------


_______________________________________________
opendap-tech mailing list
opendap-tech at opendap.org
http://mailman.opendap.org/mailman/listinfo/opendap-tech