This page outlines the key aspects of the data service suite (following a decision to cease development based on the DX). Code will eventually appear in the repository. See also the  DCIP web services page as these two projects will be sharing resources.

Enterprise Viewpoint

(aka primary use case): Need to be able to extract a cruise-section-equivalent from a model dataset (e.g. ERA40) at BADC and difference against a BODC actual cruise (or the same from an atmos profile etc).

Information View Point

  • CSML Schema description of a GridSeriesFeature
    • GridSeriesInterface exposes an extractProfile, but does it expose extractProfileSeries?
  • CSML Schema description of a ProfileSeries
  • CSML Instances at both locations
  • CSML Storage Descriptors
  • Binary Files at both locations

Computational Viewpoint

Some key components (Note relevant specs are reproduced here with the OGC license attached!


Note these three arguments are mandatory:

DescribeFeatureType typename, outputFormat
GetFeature outputFormat,
resultType, propertyName,
featureVersion, maxFeatures, expiry,
srsName, typeName, featureID, filter, bbox, sortBy

Starting assumption. We need to build a wsgi based WFS, which we can gatekeep, and which will serve up a combination of GML and netcdf local to the WFS. That is, we expect the storage descriptors to point to files on the local file system. This system should be standalone python and not depend on any external packages (i.e. not dependence on databases).

The consequence of the no dependencies on external databases is that we can either dynamically parse the CSML in a directory (or directories) which is configured, or we can index the CSML content to some extent, and only parse full CSML documents in response to GetFeature? requests. Of course, it should be possible to use an external database, but it shouldn't be required.

I anticipate building a simple index based on parameters, time and spatial indexes, and features, based on python dictionaries and  QuadTree.

Note that a key issue to be resolved is what outputformats we support. We have to support gml/3.1.1 to be wfs 1.1 compliant, and may have our own as well, provided we advertise the mime type in the Capabilities document. See ticket:650

NDG DataService

extractGridSeries featureId:URI, bbox:GM_Envelope
extractProfile featureId:URI, location:GM_Point
extractSection featureId:URI, path:GM_LineString, depths:MeasureListType


DescribeProcess identifier
ExecuteProcess identifier, store, dataInputs

NDG DiffService

subtract featureId1:URI, featureId2:URI

Although not strictly necessary for this, we obviously need to interact with the  DCIP WMS, which should probably evolve to use the same code stack.

Some intersting third party things are now also in our subversion, some of which may or may not be useful.

Engineering Viewpoint

Starts with this simple picture:

Engineering Viewpoint (Prelim)

We come up with the following coding concepts:

source:TI02-CSML/trunk/services/Engineering Model.JPG


  1. WFS: require a minimum implementation which supports a "store" option (?)
  2. DataService:
    • implements affordance interfaces
    • could operate on a local or remote WFS feature instance
    • thin wrapper over CSML API
    • could exploit WFS DAQM
  3. DiffService
    • Could be based on WPS
    • Could be tightly coupled to DataService?


  • DifferenceFeatureService ...
    • extractEquivalentAndDifference(Feature1,Feature2)