SOAPifying WCS

SOAPifying WCS: Approach and Issues

Kari Hoijarvi, CAPITA, hoijarvi@me.wustl.edu

Fixing the WCS Schema

The official schemas are copied into in http://datafed.net/xs/OGC/wcs/1.0.0/ . Schemas gml4wcs.xsd and xlinks.xsd were used as is, but the other schemas were not legal.

Problems: schemas attempt to "import" instead of "include" from the same namespace. The rule is, that schemas with different namespaces must import and a namespace that is partitioned must be included. Therefore http://datafed.net/xs/OGC/wcs/1.0.0/wcsfix.xsd contains all the schemas from namespace http://www.opengis.net/wcs. In my opinion, xml schema include is a mistake and should not be used.

Edits: The schamas values.xsd worked as is and is in wcsfix owsBase.xsd had several things that .NET 1.1, .NET 2.0 and MSXML 6.0 did not consider legal. Due to complexity of the schema language, I do not know if the schemas were illegal or if they exposed bugs from Microsoft's validators. I have previously experienced both. These are tagged with comment in wcsfix.xsd

wcsCapabilities had a problematic type AbstractDescriptionBaseType which was edited heavily. wcsDescribecoverage was inserted as the were

wcsGetCoverage has our extension FilterExtensionType which currently has only one element: loc_code to query point data for time view from a location. This cannot be implemented with bbox since locations may have the same lat+lon coordinates. WFS has a standard way to put in such a filter, but WCS does not. Here is an exaple of WFS service using loc_code filter and this is how our WCS query with loc_code looks. It would be a good idea to allow servers implement their own filter and aggregator extensions, just like WMS allows server specific parameters in the url.

The schema http://datafed.net/xs/OGC/wcs/1.0.0/wcsfix.xsd was the inserted into our WCS service WSDL http://webapps.datafed.net/WCS.asmx?WSDL

Looking into nodes <message name="GetCapabilitiesIn">, you'll see that the input messages as well as the XML-based output messages are straight from wcs schema: input, output wcs:GetCapabilities, wcs:WCS_Capabilities wcs:DescribeCoverage, wcs:CoverageDescription wcs:GetCoverage, N/A

The GetCoverage call is problematic, because WCS returns often binary types like NetCDF, GeoTIFF etc.

We Created element dfc:GetCoverageResponse for output:

<xs:element name="GetCoverageResponse">
  <xs:complexType>
      <xs:all>
          <xs:element name="data" type="xs:anyURI"/>
          <xs:element name="content_type" type="xs:string"/>
          <xs:element name="format" type="xs:string"/>
          <xs:element name="domainSubset" type="wcs:DomainSubsetType"/>
          <xs:element ref="ncml:netcdf" minOccurs="0"/>
          <xs:element ref="lin:Statistics" minOccurs="0"/>
          <xs:element ref="lin:LineageList" minOccurs="0"/>
      </xs:all>
 </xs:complexType>
</xs:element>

Although it is possible to embed binary data to soap output using mime types or base64 encoding, we did not go that way. The output contains an url to data, so that it can be retrieved using HTTP-GET request. In addition to this pointer to data, the envelope has:

content type: for example application/x-netcdf format: the format that was used to query this data, for example NetCDF domainSubset: space and time boundaries for data ncml:netcdf: ncML description of data, if the data is in NetCDF cube Statistics: min, max, avg, sum, total_count, null_count LineageList: Soap input Envelope that was used for the query, optionally other comments like the actual SQL clause that was performed, the actual URL that was retrieved, etc.

So basically to SOAPify WCS required:

fix schema
create output type
wrap xml to envelope

To create SOAP out of xml is just matter of wrapping it into an envelope:

<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
  <Body>
      <GetCoverage ...
  </Body>
</Envelope>

Example: Example SOAP Envelope