UPDATE: March 27, 2008
Xenia documentation is being migrated to http://code.google.com/p/xenia/wiki/XeniaHome
Xenia Demo Powerpoint
Xenia Sample Case
Current script development at http://carocoops.org/xenia
see also XeniaPackageSqlite
UPDATE: December 13, 2006: I've upgraded to version 2 which is designed to support vector observation types, collections, quality control history, etc. The earlier version will work ok for simple observation types, but I plan to focus all my new development efforts on version 2.
I've been trying to reduce and simplify what we're doing in terms of data collection and sharing for ocean observations(http://carocoops.org/portal_rs http://carocoops.org http://carocoops.org/carolinas
) down to a single set of relational database tables and scripts. The name I'm choosing for this effort is 'Xenia' which is a kind of coral found in many marine aquarium coral collections which waves through the water with many palms or hands.
The general issue which we run into is that data is collected to a data 'logger' in tabular format and it involves a lot of manual work to get data from these individual sensor datalogger formats into a more standardized forms which can be more easily aggregated and used.
The initial goal is to develop a good general relational table schema which we can push most all of our aggregated in situ observation data into and pull various products and web services from. The secondary goal is the sharing of scripts which leverage this schema both to aggregate data and to provide output products and web services.
Again the Xenia problem/product I'm trying to address is the common datalogger/filesystem which collects 10-20 obs per hour at 1 to 1000 platforms (say less than 100,000 records total/hour
) and tying that back into our system of systems(CAROCOOPS, SECOORA, IOOS, GEOSS) with a common relational database driven schema infrastructure to develop products up from.
For high-volume data problems with millions of records per hour(model outputs, hf radar, etc)
, this is not something which I think Xenia should address at this time except for possibly in terms of metadata tables describing these products. High-volume data problems can continue being addressed as file/directory based
, batch I/O processing bound problems with discussions more directed towards the organization of the data metadata files for descriptive
(common visual legends for image overlay needs, common agreements on quality control application) and archival
Note: to see which pages have changed recently on this twiki click the 'Changes' link in the left hand sidebar. At each page bottom there is a 'Total page history' link which shows each pages revisions.
Xenia Table Schema
- 26 May 2006