Dapper in-situ conventions spec available

[Thomas LOUBRIEU]

Hi everybody,

I am very happy to see something official starting on in-situ opendap 
conventions and I would like to keep in touch with the discussions on 
the subject.
For CORIOLIS in-situ data center, an opendap in-situ server as been build :
The URL is :
     http://www.ifremer.fr/dap4cor/
and you can find a FAQ and client softwares (matlab example scripts  and 
a dap4cor to netcdf ARGO converter) :
     ftp://ftp.ifremer.fr/ifremer/coriolis/tools/dap4cor/

We want it to be as compliant as possible with other opendap sources of 
in-situ datasets.
So we will change our dds interface from the intial ARGO-DAPPER model to 
the new "geophysical opendap model".

As CORIOLIS data center hosts numerous and various in-situ datasets 
(CTD, XBT, drifting buoys and profilers, gliders, moorings, elephant 
seal...), it is a good context for implementing the "geophysical opendap 
model" convention and we could interacts with you if we notice specific 
in-situ usages.

Thomas


Joe Sirott wrote:
> Hi John,
>
> This list seems (at least to me) to be a reasonable place to have this 
> discussion. Why don't you go ahead and forward your comments? If there 
> are then objections to having the discussion on this mailing list we 
> can set up a different forum...
>
> - Joe
>
> John Caron wrote:
>> Hi Joe, et al:
>>
>> We have some various comments on this. Im wondering if you would 
>> prefer to have a seperate conversation on a possible new version of 
>> the spec, or just discuss the spec as it stands? I guess im wondering 
>> if this is the place to have the discussion Steve Hankins suggested:
>>
>> (Steve's original email)
>>
>> I'm seeking your thoughts here are on how the community can move 
>> rapidly towards the development of a written specification for the 
>> 2-level Sequence representation in OPeNDAP. (I'll refer to this below 
>> as the "DAP-2LS" conventions.)  It looks like the time may be right 
>> next year for pretty rapid growth in the use of OPeNDAP for conveying 
>> in-situ data.  Funding will probably be available for efforts along 
>> these lines.  A written specification is needed if the community is 
>> to take full advantage of these opportunities.
>>
>> Between the DAPPER server and GDS there are successful example 
>> implementations to work from.  Many of the details of the 
>> specification (e.g. encoding of time) can probably be borrowed from 
>> CF.  The emerging PyDAP work promises to bring relational databases 
>> into the fold, too.
>>
>> Clearly funding may be needed to entice someone to take on this 
>> task.  I believe that we can find a source of those funds in NOAA if 
>> we act quickly.  Even if only an initial, draft specification were to 
>> be developed at this time -- with community comments and discussion 
>> left to follow later -- this would be an important contribution.  
>> Multiple venues for community discussion of CF-related conventions 
>> are taking form.  One at Unidata (by September?) will host 
>> discussions about unstructured grid (finite element) conventions.  
>> Another at LLNL is getting started now to press forward with the CF 
>> conventions for more complex curvilinear grids.  With an initial 
>> specification of DAP-2LS conventions in hand I imagine we can entice 
>> someone to host a community discussion, since access to observations 
>> is important to everyone.
>>
>>   - steve
>>
>> P.S. I am just cheer-leading this effort. I do not expect be directly 
>> involved, myself.  The pay-off to the community -- advancing data 
>> interoperability, OPeNDAP, the Common Data Model, etc. etc. -- just 
>> seems too big to ignore. "
>