"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Geochemistry data examples


Contents

Related pages


Example datasets

Project participants supplied examples of what they anticipate their clients are interested in receiving, as Excel spreadsheets.
  • GeochemExamplesGA - one measurement per row, but with repetition of specimen and procedure information between rows. Limited information is provided regarding the specimen, but much more about the analyte procedure.
  • GeochemExamplesWA - one sample per row, with a suite of analytes laid out across the columns.
  • GeochemExamplesSA -one sample per row, with a suite of analytes laid out across the columns. Detailed description of the specimens, in a table separate from the results.

These examples illustrate different InformationViews that may be applied.

It is expected that most custodians store the data in normalised form on the back-end. The de-normalised reports are generated by appropriate joins.


Preferred XMML encoding

The preferred XMML encoding for the MCA project is the normalised structure, encoded inline pattern.

AndyDent and RobAtkinson have recommendations regarding explicit namespace prefixes.

Units of Measure

In decision recorded MCATechnicalTeam20040816, it was proposed that numeric results should be "canonicalised" into pure numbers. Thus "1.5 ppm{wt}" becomes "1.5e-6 {wt}" where "{wt}" implies an unscaled fraction-by-weight (see http://aurora.regenstrief.org/UCUM/ucum.html#para-12). The goal here is to allow analysis, visualisation (plotting), etc without requiring that the client interpret uom's and perform conversions. As usual, the assumption is that the server knows its data best, and so is in best position to convert values to standard uom (i.e. unity).

However, Geoserver does not currently support transformation of values on the way through from the database to the XML output, so this functionality must be deferred (see WfsSoftwareEnhancements).

Note that the "originalUOM" is metadata: it is sometimes (often?) used by clients to infer "precision". However, this is probably unsafe. The long-term solution is to require that "precision" information is supplied explicitly, as part of the xmml:quality block.

XMML Views available

See GeochemistryMeasurement The measurement view bundles the data into one object per specimen-per-procedure-per-analyte. This view allows maximum detail about a single analyte value determination to be presented.

The sample view shows one object per specimen, with all analyte results bundled as "simple" properties.

The coverage view shows the variation of a single analyte with location.

Mapping views and workflow

The views might correspond to different phases in the analysis process.
  • Initial exploratory analysis is likely to use a coverage view;
  • the complete chemistry of locations of interest is exposed using the sample view;
  • the details of interesting or anomalous values of specific analyte values can be checked using the measurement view.

Processing and data transformation

The different views may be generated
  • on the server-side - in which case a WFS implementation would need to support feature-types corresponding to the different views
    • specimen, measurement, procedure, sample, coverage
  • on the client-side, for example through XSLT transformation of normalised data - in which case the WFS would only have to support the primitive feature types
    • specimen, measurement, procedure

See ADX for an illustration of the use of XSLT to generate tabular views on-the-fly from fully normalised XML input.

Note that the metadata attribute on analyte values in the sample view provides direct links to the related objects from the measurement view.

Client-side transformations

Requires
  1. a client with the necessary process and selection logic, capable of XSLT processing
  2. that all the required primitive objects (specimens, analyses, specimen locations) are loaded into the client prior to processing, so is likely to involve fewer transactions involving more objects each

Server-side transformations

Requires
  1. a client with less processing ability, but must allow generation of a series of WFS requests to the server
  2. many more transactions with the server involving fewer objects each

Greater load-sharing between the client and server requiring a higher-performance server and lower-latency connection

Implementation

See MCAStyleSheets for prototype reports suggested by SA. A brief analysis of the requirements implied by these suggest that a lot of client-side interaction is expected, and a lot of measurement detail required. This suggests that we should start by assuming the "client-side" scenario, with fewer WFS transaction involving more primitive/normalised feature types, and more processing and styling on the client.

-- SimonCox - 10 Sep 2004
Topic revision: r9 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).