Attendees

• Mike McCann
• Francisco Chavez
• Seth Bushinski
• Julien Barde
• Luis Bermudez
• Mike Godin
• Kevin Gomes

Review action items

• BOG in OpenDAP- Mike M.
  Rich S. making a lot of the work. All the profile data is being made available via DAPPER/DHART. Data was loaded in 2 ways: per project and all profiles aggregated. The later had problems that only a maximum of 1000 profiles are shown. Process was: 1) create NetCDF files from BOG. 2) load attributes to Dapper. DCHART, which is an AJAX application reads from DAPPER.
• Mooring data from NetCDF available in OGC / SOS service for OOSTETHYS - Luis B. (3 min)
  Luis working from NetCDF files created by Mike M. He had some discussions with Mike G. about java objects use to store netcdf data/metadata and to pass to an SOS service
• THREDDS aggregation update - Julien B. (3 min)
  Is working on it, problem is metadata that is stored and is overwritten every time the catalog is generated.
• Use case - [ Mooring and AUV ] - Julien B. (3 min)
  Experiment with a PostgreSQL and spatial cartridge, that allows to perform spatial functions, such as: get near by. Using as source DAPPER.
• MOQUA plans for data aggregation at MBARI -  Mike G. (3 min)
  Is a king of DCHART, is going to be build on top of hypersonic, light database easy to put in a WAR file. Intention is to write a generic reader that can sit on top of Thredds, Dapper or an OGC catalog.
• Review/discussion DATA Aggregation Strategy (45 min)
  Luis presented a diagram and general questions for discussion Aggregation strategy issues for discussion

Strategy discussion

Image comments

• DAPPER and DCHART should be two boxes
• MOQUA interfaces with DAPPER and not DCHART
• NETDF REPOSITORY goes directly to DAPPER, DAPPER doesn't interferes with THREDDS.
• OGC interfaces can go directly from DAPPER
• present diagram in UML

General comments

• SSDS, DAPPER and MOQUA are complementary and do not overlap. SSDS concentrates in provenance, while DAPPER being a relational data base, concentrates in the most efficient schema to support NetCDF (OpenDAP) queries. MOQUA is a user interface that tries to aggregate heterogeneous data. An interesting project (for outside funders as well as MBARI) is how to integrate these different technologies, to allow geospatial functionality and more standard serving capabilities (like serving ISO metadata and making available data via OGC interfaces)
• Francisco in charge of starting the thread about a proposal from CENCOOS to NOAA CSC RFP. - we can fold the previous ideas to work on the case 3 of the proposal to getting us started.
• Carbon and Nitrogen Initiative is in its planning phase, and due to the heterogeneity of data being involved, it can be a good test-bed for the technologies being discussed in this project.
• Is not true that the work to be done here is not funded, Julien and Seth are funded by CIMT, and it is also possible to have some SSDS time next year.
• This should start folding in to an internal project to be presented next June.
• Use case is tough due to the 3 dimensionality of the problem.
• DAPPER is an aggregator and seems to have a lot of the functionality that THREDDS has.

Action Items

• Start writing a proposal about the idea of integrating SSDS, DAPPER and MOQUA with OGC capabilities (it shoud be consistent with the CI proposal send by MBARI to ORION). - Luis
• Start building the architecture (updating the image) for data aggregation more formally - Luis , Kevin and Mikes
• Setup meeting next week with CENCOOS to propose a concrete idea for the proposal - Francisco
• Continue testing the spatial functionality in POSTGRESQL and then we can think about how to add the functionality to the technologies that we will use (e.g. DAPPER) - Julien
• Invite Luis to next Carbon Nitrogen discussion meeting - Francisco

• Luis meet with Julien to talk more about OGC and OPenDAP

Next Meeting

Friday - January 26th 9:00 AM - Ocean's View conference room

da-20070112.pdf (application/pdf)