wiki:OwsNotes

Version 4 (modified by spascoe, 12 years ago) (diff)

--

Sub documents

Using OGC Web Services for NDG

Below is a review of the major OWS specifications WMS, WCS, WFS and WPS from the perspective of how we might use these services when implementing NDG data services.

Assumptions

  1. CSML is our model of data.
  2. CSML affordance is our model of operations on a single Feature.

Web Map Service

A web map service is relatively simple. It serves images of a given geospatial coverage (bounding box). WMS servers have the concept of layers that may be nested. There is explicit support for coordinates TIME and ELEVATION and informal support for other dimensions, however each request addresses a single horizontal coverage in these dimensions.

How would WMS map onto CSML?

The WMS data model is much more restricted than the CSML feature model, therefore a means of mapping features to layers is required.

Each CSMLFeature maps onto a WMS layer (except in the case of compound phenomena). How a NDGDataSet is served as a whole is less clear. The IPCC DDC takes the approach of creating a separate WMS service endpoint for each CSMLDataset (aka DataGranule?). This prevents the GetCapabilities? document from growing unmanageble as the number of DataGranules? increase.

Web Feature Service

A WFS is basically a database system that uses GML as it's data model. As GML is itself an extensible language built upon XML schemas, WFS semantics are heavily influenced by XML schema.

The GetFeature? request specifies a feature type and a query. The query specifies which properties of the feature type are wanted in the response and a filter which restricts the set of feature types returned. E.g.

Get me the properties widget and thingemy of all FooFeatures? where property wibble > 100

This is really quite similar to the SQL

   SELECT widget, thingemy
   FROM FooFeature
   WHERE wibble > 100;

(Which sure beats the XML representation ;-)

In the case of WFS all property references can be XPATH expressions and the filter can contain symbolic and goespatial constraints.

It is important to recognise that WFS isn't designed to support operations on features such as would be required to implement CSML affordances. You can constrain your feature set and the properties returned but you can't implement something like SubsetToGridSeries? which creates a totally new GridSeries? from another GridSeries?.

Actually this isn't quite true. There are 3 ways in which affordances could be implemented within WFS:

1. the <Native> tag

This is a loophole in the spec that allows you to implement anything you like.

2. Use GetFeature/Query/Function?

The WFS schema allows an <ogc:Function> element to appear as a child of <wfs:Query> (i.e. in the equivilent of the SELECT clause). However, this isn't documented in the specification and is incompletely documented in the schema. It should probably be considered another loophole.

3. Use the recent FilterModel? extension

This is probably the correct way of doing it but requires the definition of your operation in XML schema. The intention is that a WFS can define view of a FeatureType? (the FilterModel?) which is used as the subject of a query but the result remains the original FeatureType?. This view can restrict the properties visible to the query or add derived properties that aren't present in the returned FeatureType?. However, as the specification points out, the FilterModel? doesn't have to resemble it's associated FeatureType?. The FilterModel? could effectively describe the parameters of an arbitary operation.

Although theoretically one could express affordances as a FilterModel? I can see several disadvantages:

  1. Constructing valid XML schema relating CSML FeatureTypes? to affordance FeatureModels? would be complex. Evaluating a query on the server would probably be even worse.
  1. The WFS spec. is predicated on retrieving FeatureTypes? from a database (in the general sense of the word) but a FeatureType? created from the affordance of another FeatureType? wouldn't be stored on the server (unless the WFS cached it) and wouldn't necessarily be selectable from subsequent WFS requests. This appears to go against the spirit of a WFS.

Another way we could use FilterModels? is to use them to encapsulate selection of parts of a CSML Feature such as it's phenomenum or domain. This would be an alternative to selecting them using XPATH. However, support for XPATH expressions *on the FilterModel?* would still be required according the WFS spec.

Web Processing Service

WPS is easily the most general OWS specification. It simply executes a process converting inputs to outputs. You could wrap a Sudoku solver in a WPS :-).

There are several useful features in the specification:

  • Flexible input methods: Sent in the request or locatable by the server via a URL.
  • Flexible output methods: Returned in the response or stored for future retrieval.
  • Process state polling.

The main drawback of WPS is that because it's a very general spec there will still be lots of design decisions to make in using it.

A WPS would be a natural way of implementing CSML affordances and would allow the server to scale well to affordances that take a while to execute. It could also be used to create visualisation products such as publication-quality plots.

Web Coverage Service

A WCS serves data in the form of "coverages", geospatial information representing space-varying phenomena. Unlike WFS, WCS is not tightly integrated with GML. This has some advantages, for instance WCS is agnostic about the coverage data format, but means that there is not a close correspondence between CSML and the WCS data model. If WCS were to be used in NDG a considerable ammount of work would be required to map these two models onto each other.