Personal tools
You are here: Home Development Meetings Meetings before March 2007 Meeting OOSTethys 20070125

Meeting OOSTethys 20070125

Participants

  • Bruce Beaumont
  • Eric Bridger
  • Riley Young Morse
  • DavidĀ Forrest
  • Tony Cook
  • Luis Bermudez
  • Bill Howe
  • Donna Cote

Review Action Items

  • Tony - sent information about how the parameter time should be called ( maybe following WMS) ONGOING
  • All - implement the parameter time in get observation. TBD
  • All - check that in the and if there is a value then the values for indeterminatePosition cannot be unknown or now. DONE
  • All - add the short names using the suggested namespaces Eric TBD
  • Tony - start page suggesting templates to call the SOS service using POST HTTP. ONGOING
  • Luis - JAVA toolkit ONGOING
  • Luis- Make available MBARI data DONE - one mooring is available
  • Bruce - post code in SF - TBD - not current priority
  • Eric - post code in SF - TBD - not current priority
  • Riley - send suggestions to the group about the web page - SOON - will send email today
  • Interfaces between portal and catalog DONE - there is one service called http://score.itsc.uah.edu/MMI/GetURLs.pl
  • Best practices document - TBD

Issues

Code in sourceforge - strategy for branching (CVS vs. SVN) Not currently a prority, better not to branch, SVN is preferred

Acceptance of new members - If invited by one of OOSTethys participants its OK

Eric - added functionality to the MAP and started working on the post support

Database-config backend:

We have different databases (Xenia, SSDS, 52North, GOMOOS, SSDS). some of them support SOS services (52North), while others can be improved to support SOS services. What if there is a data provider that has an arbitrary schemas or uses a directory structure to store files. - Is it better to create a simple database that they can updated easily or to configure a set of SQL statements to query on the fly the data base and extract the information needed ? - what is the best approach for a data provider to make available plain files ?

'Don't really need a database, maybe for new OOS that have no database, this could probably help. Better to have in the config file SQL statements'

We need to support systems based on directory/file systems with ASCII data, NetCDF files, and Relational Data Bases (by SQL queries). This could be done cia the config file of via an API for different languages?

To think about: - should OOSTethys be a toolkit or a cookbook ? Do we support system that need to create complex config files to publish an SOS, or a light config file wich needs some further development in diferent languages?

Others

  • controlled vocabulary - Luis clean it - make it clear is the OOSTethys page that that's the vocabulary needed, not just examples.

We didn't have time to discuss the following:

  • Roadmap OOSTethys - Planing toolkit versions
  • Simple congif system that serves station data and metadata in different ways : SOS, WFS, KML, FGDC, ISO, etc..

Summary action items:

  • Tony - finish to post information about time and POST templates
  • Luis - update the templates in the repository
  • Riley - send email about web changes
  • Bruce - send email for get all URLs
  • Luis - cookbook in JAVA
  • Luis - controlled vocabulary - clean up
  • Bill - send Python examples - possible python cookbook
  • Eric - Bill - Luis - revise config file
  • Luis - start topic in the plone site about cookbook vs toolkit
Document Actions