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


The OWS Common specification defines a schema for GetCapabilities. However, this does not map directly onto individual W*S specifications. Notes on how they are related go here.

OWS common 1.0.0 vs 1.1.0

The spec has changed in 1.1.0 as follows:

  1. Abstract class ServiceMetadata becomes concrete OWSServiceMetadata.
  2. Added OWSContents to OWSServiceMetadata.
  3. Expanded ServiceIdentification with profile attribute.
  4. Many occurances of CharacterString have been replaced with LanguageString. This also increases multiplicity of these attributes (many languages possible).
  5. Domain gets it's own package with many more attributes (possibleValues, valuesUnit, dataType, meaning).
  6. Extra packages modelling GetResourceById and the request model.

WMS 1.3.0 vs OWS common 1.1.0

WMS GetCapabilities? clearly pre-dates OWS common 1.0.0. There are overlaps:

  1. wms:Service maps approximately onto ows:ServiceIdentification and ows:ServiceProvider with some WMS-specific elements (wms:LayerLimit, wms:MaxWidth, wms:MaxHeight).
  2. wms:Request maps approximately onto ows:Operation
  3. wms:Layer could be made to map onto a subclassed ows:Contents.

WCS 1.1.0

WCS uses OWS common 1.1.0.

WPS 0.4.0

WPS uses OWS common 0.3.0. I haven't looked at this closely but it looks similar to OWS 1.0.0.

Mapping OWS common 1.1.0 to WMS 1.3.0


This information will be defined in the ows_server source code using a python decorator. I imagine something like

from ows_common.decorators import *

class WxsController(OwsController):
  @parameter(name, value)
  @constraint(name, value)
  def getCapabilities(self, ...):

This formulation matches the OWS common model for OperationsMetadata?. WMS doesn't use parameters and constraints, however we can define a mapping which is understood by the framework.

Parameter Name Value
"formats" sequence of supported MIME types for the response