View source for NC-DAP Project Meeting 8 Jan 2009

A one-hour plus meeting over the phone.

==Agenda==

Agenda for 2009-01-08 Teleconference

* Grant status, schedule, milestones (James, 5 minutes)
* Current status of Unidata effort (Dennis, 5 minutes)
* Current status of OPeNDAP effort (Rikki, 5 minutes)
* Ocapi issues (all, 30 minutes)
* Summary and action items (all, 5 minutes)

==Report==

===Grant status===
We're pretty close to being on track for our milestones as described in [[NC-DAP Project Meeting 3 June 2008]]. We've not quite made the 1.2 deliverable (Ocapi (supporting DAP2) + glue code + netcdf 3 data model 12/2008 Release netcdf version 4.1) but that should be out in the next month, at least as a snapshot. There's a fair amount of the DAP 3.3 stuff implement in libdap++ although some key parts for this project need coordinated effort from both opendap and Unidata to get done.

===Unidata effort=== 
Dennis has modified the Ocapi code so that it reads the response into memory and then either uses pointers or computed offsets into that block of XDR-endoded data instead of allocating new memory and copying values into a 'data value tree' with a structure based on the data set's DDS. The current Ocapi code does the latter and, while it will work in theory, in practice, the resulting data tree is very complex for certain data sets (e.g., those that contain arrays of structures).

===Ocapi status=== 
Rikki has release Ocapi 1.4.2 (just prior to the AGU meeting). This version of the library contains support for various 'usability' features like HTTP basic and digest authentication, SSL authentication and Proxy servers.

===Ocapi & Other issues===

====The ''Array of String'' issue====
The current netCDF handler represents an array of char found in a netCDF3 file as an array of one character strings. This makes writing clients laborious because when client authors cannot assume that an array of String is actually an array of characters, since it's possible that the data set is not a netCDf file and really does contain and array of strings. So, clients must be written to scan these to determine if they are in fact arrays of single characters or real arrays of strings.

This should be addressed by fixing the handler and releasing it so that a client can examine the DAP version and know that at or past a certain DAP version, an array of single characters will be represented as either a String or an array of Bytes (we're not sure which, but there's and action item to sort that out) and that such a variable will also contain a new attribute 'string_length' that can be used to determine the length of the string without having to read the string in order to figure out how big it is. 
<blockquote>
Ah. I think ([[User:Jimg|jimg]] 15:20, 8 January 2009 (PST)) I remember why Reza did this. If you externalize an array of char as a String, there's no way to know how many characters there are in that string from just looking at the DDS. So code like the netCDF Client library cannot provide the information that a netCDF application needs to allocate the memory needed to store that value. The attribute will solve the problem. We should encourage all handler authors to include this attribute with any string variable whenever they can.
</blockquote>

====Dennis' new Ocapi code====
It sounds like this new code is a big plus in that it's more efficient and it works for the Array of Sequences case - thecurrent code does not. This should be checked into SVN as a tag. Rikki can read it over and we can sort out what to do next: Adopt it most likely.

====Groups and Shared Dimensions====
It seems from the discussion that Groups (aka namespaces) and Shared dimensions so hand in hand. Another important point made in the discussion was that shared dimensions are not the same as shared coordinate variables. 

The DAP Grid type provides a mechanism to specify coordinate variables. We can make these more general by relaxing some constraints on Grid. Currently a Grid is exactly one N-dimensional array with N one-dimensional ''maps'' or ''coordinate variables'' (adopting DAP and NetCDF3 vocabulary). We can:
# share the maps/coordinate-variables by allowing more than one array;
# relax the requirement that the arrays all be N-dimensional (but instead be <= N-dimensional);
# expand the maps so that they are no longer limited to one-dimension

In NetCDF4 (aka the Common Data Model) shared dimensions are bound to a Group.

We need to work out the details of this within the context of DAP!