IN51B-0812
The Live Access Server � Scientific Product Generation Through Workflow Orchestration
The Live Access Server (LAS) is a well-established Web-application for display and analysis of geo-science data sets. The software, which can be downloaded and installed by anyone, gives data providers an easy way to establish services for their on-line data holdings, so their users can make plots; create and download data sub- sets; compare (difference) fields; and perform simple analyses. Now at version 7.0, LAS has been in operation since 1994. The current �Armstrong� release of LAS V7 consists of three components in a tiered architecture: user interface, workflow orchestration and Web Services. The LAS user interface (UI) communicates with the LAS Product Server via an XML protocol embedded in an HTTP �get� URL. Libraries (APIs) have been developed in Java, JavaScript and perl that can readily generate this URL. As a result of this flexibility it is common to find LAS user interfaces of radically different character, tailored to the nature of specific datasets or the mindset of specific users. When a request is received by the LAS Product Server (LPS -- the workflow orchestration component), business logic converts this request into a series of Web Service requests invoked via SOAP. These �back-end� Web services perform data access and generate products (visualizations, data subsets, analyses, etc.). LPS then packages these outputs into final products (typically HTML pages) via Jakarta Velocity templates for delivery to the end user. �Fine grained� data access is performed by back-end services that may utilize JDBC for data base access; the OPeNDAP �DAPPER� protocol; or (in principle) the OGC WFS protocol. Back-end visualization services are commonly legacy science applications wrapped in Java or Python (or perl) classes and deployed as Web Services accessible via SOAP. Ferret is the default visualization application used by LAS, though other applications such as Matlab, CDAT, and GrADS can also be used. Other back-end services may include generation of Google Earth layers using KML; generation of maps via WMS or ArcIMS protocols; and data manipulation with Unix utilities.
http://www.ferret.noaa.gov/LAS/
IN51B-0813
Serving Geochemical Data Using GeoSciML Compliant Web Services: Next Step in Developing a Generic GeoChemical Database Model
The Geochemical Database Model (GCDM) has been developed under the Geoinformatics for Geochemistry Program (www.geoinfogeochem.org) to provide a generic relational database structure for the broadest range of geochemical data collections. GCDM vastly extends the capabilities of the PetDB data model (Lehnert et al., G3, volume 1, 2000), on which it is based, with respect to applicability, flexibility, and comprehensiveness. For example, GCDM accommodates any type of analytical measurement (�observed value'), including time-series data, in-situ sensor measurements, and derived (model) data such as end-member compositions for seafloor hydrothermal springs or age models; data for any type of sample and material (rock, sediment, porewater, water, etc.); and analytical metadata at the level of individual measurements. It tracks relationships between �parent' samples andany number and levels of subsamples. GCDM can easily respond to the frequently changing requirements for geochemical databases and is modular so various components of the model can be developed independently. Currently, the model is being implemented for SedDB, an information system for marine sediment geochemistry (www.seddb.org), and will be applied to other geochemical databases (PetDB, EarthChem, and VentDB) in the near future. The data model represents a multidimensional cube with the observed value as the basic building block that is described by five basic independent components in the data model, each multidimensional in itself: Data Source, GeoObject (sample), Observed Item, Observation Point, and Method. The data model provides for an easy top- down application of metadata and corrections. Observed values can be grouped logically into �GeoModels' that can be used to generate new data such as the end-member compositions for hydrothermal vents. This way, both actual and derived data can be stored together in a fully integrated model. Almost all attributes found in GCDM are defined in GeoSciML, a markup language developed by the IUGS Commission for Geoscience Information to represent geoscience information associated with geologic maps and observations (http://www.opengis.net/GeoSciML/). GCDM model attributes such as method, sample and item measured can easily be mapped to corresponding types within GeoSciML. Others, like observation point or observed value, can be incorporated within GeoSciML concepts of method, event, and measured value. Web services are developed on top of GCDM databases to serve geochemical data in a GeoSciML compliant schema to facilitate interoperability with other Geoscience data systems.
http://www.geoinfogeochem.org
IN51B-0814
Dynamic User Interface for Cross-plot, Filtering and Upload/Download of Time Series Data
We have generated a user-friendly web-interface that allows for dynamic filtering and cross-plot of time series data. The interface is an extension of our existing php software associated with the Storage Resource Broker (SRB) at the San Diego Supercomputer Center (SDSC). The extension includes the possibility of dynamic low- pass filtering and cross-plotting several time histories associated with a specific site. Moreover, regular-spaced scalar data can be cross-contoured with choice of contour interval, labeling, etc. Also associated with the interface is software to upload and download sets of synthetic time histories and scalar contour data on a regular grid using a web browser. The software is well suited for numerical code validation exercises, generating output such as sliprate histories, rupture time distributions, ground motion histories, and peak ground motions, as well as comparison of ensembles of ground motion scenarios.
http://sceclib.sdsc.edu/TeraShake/