From Intamap

Contents 1 GML 3.1 1.1 GML Observation 1.2 GML Coverage 2 The different Geospatial Web Services 2.1 WFS 2.1.1 Overview 2.1.2 WFS Operations 2.1.3 Types of WFS 2.2 WMS 2.2.1 Overview 2.2.2 WMS Operations 2.3 WCS 2.3.1 Overview 2.3.2 WCS Operations 2.4 WPS 2.4.1 Overview 2.4.2 WPS Operations 2.4.3 WPS requests 2.4.3.1 WPS GetCapabilities request 2.4.3.2 WPS DescribeProcess request 2.4.3.3 WPS Execute Request 2.4.4 WPS Exceptions 2.5 WPS 1.0.0 2.5.1 Overview 2.5.2 SOAP 2.5.3 WPS Operations 2.5.4 Conclusion

GML 3.1

GML, standing for the badly named Geography Markup Language, is at the core of many of the OGC developments. It is a dialect of the more general eXtensible Markup Language (XML). GML is an attempt at standardizing the way we describe geographical data. If everybody speaks GML, we can all communicate with each other without having to translate between different languages (ways of describing data). GML 3.1 is the latest version of GML.

A nice example of GML being used in practice (i.e. application schema) can be found in CityGML and also in TransXML.

GML Observation

A GML Observation is a GML Feature that is used to describe the act of observing. It has the following properties:

• location - Inherited from gml:Feature this property describes the location of the observation (can be a point, line or area).
• validTime - A timestamp of the observation.
• resultOf - The actual 'result' of the observation.
• using - Information about how the observing was done. This can be a gml:Feature describing a sensor for instance. It may even be possible to incorporate a specialised mark-up language called SensorML
• target - (or subject) this is what is being observed. It can be either a gml:Feature or a gml:Geometry

gml:Observations can be used directly or they can be extended to include extra information. Below is an example of a gml:Observation instance. (Please note the information is arbitrary)

<gml:Observation gml:id="INTAMAP1">
    <gml:location>
        <gml:Point>
            <gml:pos>103.5607518 96.617081</gml:pos>
        </gml:Point>
    </gml:location>
    <gml:validTime>
        <gml:TimeInstant>
            <gml:timePosition>2006-11-06T10:45:23</gml:timePosition>
        </gml:TimeInstant>
    </gml:validTime>
    <gml:using xlink:href="http://www.intamap.org/sensors/sensor23" />
    <gml:target xlink:href="http://www.intamap.org/locations/Germany14" />
    <gml:resultOf>
        <app:Radiation>84.8382611781537</app:Radiation>
    </gml:resultOf>
</gml:Observation>

A few notes:

• gml:target property can be omitted, in which case it shall be assumed the observation took place at the same location as the observer (i.e. we will use the gml:location). If a gml:target is specified and it contains a gml:Geometry feature then this shall override the use of the gml:location property.
• The coordinate system used can be referenced as an attribute of the gml:location property. It has been omitted for this example.
• Certain parameters that may be useful for interpolation have to be communicated somehow. The obvious property is the gml:using which can be used to describe information about the sensor and what it is observing. However, more information may be needed and how this data is communicated should be discussed.
• The example uses an xlink attribute for both the gml:using and gml:target properties. You can assume that the gml:using points to an instance of a gml:Feature describing a sensor of some sort (sensor number 23) and that the gml:target points to a gml:Geometry defining the location of the observation (somewhere in Germany).
• The gml:resultOf property can contain a 'Unit of Measure' (uom) attribute which could be of use for interpolation.

GML Coverage

We intend to use GML coverages to return the predicted data. An example generated from our prototype:

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 <soap:Body>
  <wfs:FeatureCollection xmlns:wfs="http://www.opengis.net/wfs" xmlns:map="http://www.intamap.org/schema/wfs"
                 xmlns:gml="http://www.opengis.net/gml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                 xsi:schemaLocation="http://www.opengis.net/wfs ../WFS/1.1.0/wfs.xsd">
   <gml:boundedBy>
    <gml:Envelope>
     <gml:lowerCorner>-123149.0 -112497.0</gml:lowerCorner>
     <gml:upperCorner>576251.0 587583.0</gml:upperCorner>
    </gml:Envelope>
   </gml:boundedBy>
   <gml:featureMemeber>
    <gml:RectifiedGridCoverage>
     <gml:rectifiedGridDomain>
      <gml:RectifiedGrid dimension="2">
       <gml:limits>
        <gml:GridEnvelope>
         <gml:low>0 0</gml:low>
         <gml:high>100 100</gml:high>
        </gml:GridEnvelope>
       </gml:limits>
       <gml:axisName>x</gml:axisName>
       <gml:axisName>y</gml:axisName>
       <gml:origin>
        <gml:Point>
         <gml:pos>-123149.0 -112497.0</gml:pos>
        </gml:Point>
       </gml:origin>
       <gml:offsetVector>7000 0</gml:offsetVector>
       <gml:offsetVector>0 7000</gml:offsetVector>
      </gml:RectifiedGrid>
     </gml:rectifiedGridDomain>
     <gml:rangeSet>
      <gml:DataBlock>
       <gml:rangeParameters>
        <gml:ValueArray>
         <gml:valueComponents>
          <map:Mean/>
	  <map:Variance/>
	 </gml:valueComponents>
        </gml:ValueArray>
       </gml:rangeParameters>
       <gml:tupleList>
        108.51,113.35 109.08,112.89 109.58,112.39
        .........................................
        102.66,107.54 102.31,108.34 101.94,109.15
       </gml:tupleList>
      </gml:DataBlock>
     </gml:rangeSet>
    </gml:RectifiedGridCoverage>
   </gml:featureMemeber>
  </wfs:FeatureCollection>
 </soap:Body>
</soap:Envelope>

We have to use a rectified grid type as this is the only option that allows the use of real world coordinates (the reference system is omitted in this example but the data is from the SIC exercise). The data is encoded in a DataBlock which is essentially a space separated list of comma separated tuples whose values are referenced in the rangeParameters property.

Using a coverage greatly reduces the size of the GML especially when combined with a compression algorithm (See discussion). A typical grid of size 100x100 produces a file of approximately 350kb in size before compression.

The different Geospatial Web Services

A key concept in interoperability is the use of service oriented architectures (SOA). To read about SOA check out Wikipedia. For our project this means that we want to implement our interpolation system so that it can be readily integrated into a range of systems easily; this is what SOA aims to facilitate. The most common (but not only) way to implement a SOA is using web services.

The OGC has written a series of standards that should be used when developing a Web service that works with geospatial data. Currently there are only three types of geospatial Web services but more are anticipated.

The three services are:

• Web Feature Service (WFS)
• Web Map Service (WMS)
• Web Coverage Service (WCS)

The three services are described in more detail below.

We should probably also look at OGSA-DAI and how we can relate to this.

WFS

Overview

An OGC Web Feature Service (WFS) allows a client to retrieve and update geospatial data encoded in Geography Markup Language (GML). The WFS can serve so called simple features (vector data), these include points, lines and polygons.

The requirements for a Web Feature Service are:

• The interfaces must be defined in XML.

• GML must be used to express features within the interface.

• At a minimum a WFS must be able to present features using GML.

• The predicate or filter language will be defined in XML and be derived from CQL as defined in the OpenGIS Catalogue Interface Implementation Specification.

• The datastore used to store geographic features should be opaque to client applications and their only view of the data should be through the WFS interface.

• The use of a subset of XPath expressions for referencing properties.

WFS Operations

The WFS interface defines several operations that may or may not be implemented by a particular instance of a Web Feature Service:

• GetCapabilities

A web feature service must be able to describe its capabilities. Specifically, it must indicate which feature types it can service and what operations are supported on each feature type.

• DescribeFeatureType

A web feature service must be able, upon request, to describe the structure of any feature type it can service. This description is typically a GML 3.0 Application Schema.

• GetFeature

A web feature service must be able to service a request to retrieve feature instances. In addition, the client should be able to specify which feature properties to fetch and should be able to constrain the query spatially and non-spatially.

• GetGmlObject

A web feature service may be able to service a request to retrieve element instances by traversing XLinks that refer to their XML IDs. In addition, the client should be able to specify whether nested XLinks embedded in returned element data should also be retrieved.

• Transaction

A web feature service may be able to service transaction requests. A transaction request is composed of operations that modify features; that is create, update, and delete operations on geographic features.

• LockFeature

A web feature service may be able to process a lock request on one or more instances of a feature type for the duration of a transaction. This ensures that serializable transactions are supported.

Types of WFS

Based on the operation descriptions above, three classes of web feature services can be defined:

• Basic WFS

A basic WFS would implement the GetCapabilities, DescribeFeatureType and GetFeature operations. This would be considered a READ-ONLY web feature service.

• XLink WFS

An XLink WFS would support all the operations of a basic web feature service and in addition it would implement the GetGmlObject operation for local and/or remote XLinks, and offer the option for the GetGmlObject operation to be performed during GetFeature operations.

• Transaction WFS

A transaction web feature service would support all the operations of a basic web feature service and in addition it would implement the Transaction operation. Optionally, a transaction WFS could implement the GetGmlObject and/or LockFeature operations.

For a list of the requests our WFS might support see: WFS requests

WMS

Overview

A Web Map Service (WMS) produces maps of spatially referenced data dynamically from geographic information. This International Standard defines a “map” to be a portrayal of geographic information as a digital image file suitable for display on a computer screen. A map is not the data itself. WMS-produced maps are generally rendered in a pictorial format such as PNG, GIF or JPEG, or occasionally as vector-based graphical elements in Scalable Vector Graphics (SVG) or Web Computer Graphics Metafile (WebCGM) formats.

This International Standard defines three operations: one returns service-level metadata; another returns a map whose geographic and dimensional parameters are well-defined; and an optional third operation returns information about particular features shown on a map.

Web Map Service operations can be invoked using a standard web browser by submitting requests in the form of Uniform Resource Locators (URLs). The content of such URLs depends on which operation is requested. In particular, when requesting a map the URL indicates what information is to be shown on the map, what portion of the Earth is to be mapped, the desired coordinate reference system, and the output image width and height.

When two or more maps are produced with the same geographic parameters and output size, the results can be accurately overlaid to produce a composite map. The use of image formats that support transparent backgrounds (e.g. GIF or PNG) allows underlying maps to be visible. Furthermore, individual maps can be requested from different servers. The Web Map Service thus enables the creation of a network of distributed map servers from which clients can build customized maps.

WMS Operations

The WMS provides three operations:

• GetCapabilities (mandatory)

The purpose of the mandatory GetCapabilities operation is to obtain service metadata, which is a machinereadable (and human-readable) description of the server’s information content and acceptable request parameter values.

• GetMap (mandatory)

The GetMap operation returns a map. Upon receiving a GetMap request, a WMS shall either satisfy the request or issue a service exception.

• GetFeatureInfo (optional)

GetFeatureInfo is an optional operation. It is only supported for those Layers for which the attribute queryable="1"(true) has been defined or inherited. A client shall not issue a GetFeatureInfo request for other layers. A WMS shall respond with a properly formatted service exception (XML) response (code = OperationNotSupported) if it receives a GetFeatureInfo request but does not support it.

WCS

Overview

The Web Coverage Service (WCS) supports electronic interchange of geospatial data as "coverages" – that is, digital geospatial information representing space-varying phenomena.

A WCS provides access to potentially detailed and rich sets of geospatial information, in forms that are useful for client-side rendering, multi-valued coverages, and input into scientific models and other clients. The WCS may be compared to the OGC Web Map Service (WMS) and the Web Feature Service (WFS); like them it allows clients to choose portions of a server's information holdings based on spatial constraints and other criteria.

Unlike WMS, which filters and portrays spatial data to return static maps (rendered as pictures by the server), the Web Coverage Service provides available data together with their detailed descriptions; allows complex queries against these data; and returns data with its original semantics (instead of pictures) which can be interpreted, extrapolated, etc. -- and not just portrayed.

Unlike WFS, which returns discrete geospatial features, the Web Coverage Service returns representations of space-varying phenomena that relate a spatio-temporal domain to a (possibly multidimensional) range of properties.

WCS Operations

The Web Coverage Service provides three operations:

• GetCapabilities

The GetCapabilities operation returns an XML document describing the service and brief descriptions of the data collections from which clients may request coverages. Clients would generally run the GetCapabilities operation and cache its result for use throughout a session, or reuse it for multiple sessions. If GetCapabilities cannot return descriptions of its available data, that information must be available from a separate source, such as an image catalog.

• GetCoverage

The DescribeCoverage operation lets clients request a full description of one or more coverages served by a particular WCS server. The server responds with an XML document that fully describes the identified coverages.

• DescribeCoverage

The GetCoverage operation of a Web Coverage Service is normally run after GetCapa-bilities and DescribeCoverage replies have shown what requests are allowed and what data are available. The GetCoverage operation returns a coverage (that is, values or prop-erties of a set of geographic locations), bundled in a well-known coverage format. Its syntax and semantics bear some resemblance to the WMS GetMap and WFS GetFeature requests, but several extensions support the retrieval of coverages rather than static maps or discrete features.

WPS

Overview

The Web Processing Service defines a standardized interface that facilitates the publishing of geospatial processes, and the discovery of an binding to those processes by clients, this is a more task orientated web service when compared with WMS/WFS/WCS that feature-oriented.

A WPS provides the client access to pre-programmed calculations and/or computer models that operate spatially referenced data. The WPS insures that data input/output and transfer follow specif standards facilitating communication and implementation of GIS operations.

WPS Operations

Three operations can be requested by a client and performed by the WPS server:

• GetCapabilities

The GetCapabilities allows for clients to request and receive back service metadata (or Capabilities) documents that describe the abilities of the specific server implementation. It also supports negotiation of the specification version being used by client-server interactions.

• DescribeProcess

The DescribeProcess allows a client to request and recieve back detailed information about one or more process(es) that can be executed by an Execute operation including input parameters and formats, and the outputs.

• Execute

This operation allows a client to run a specified process implemented by the WPS, using provided input parameters values and returning the output produced.

WPS requests

WPS (version 0.4.0) allows for requests to be done by Key Value Pair (KVP) using GET or XML using POST. The use of POST with KVP should not be supported.

GetCapabilities => KVP
DescribeProcess => KVP and optional XML 
Execute => XML and optional KVP

WPS GetCapabilities request

The KVP of the GET request for GetCapabilities used service, request as mandatory parameters.

Example: www.intamap.org/wps.py?Service=WPS&Request=GetCapabilities

Also AcceptVersions, should be implemented for version negotiation.

The normal response should be an XML document containing the sections: ServiceIdentification, ServiceProvider, OperationsMetaData, ProcessOfferings:

Example of ProcessOffering XML section:

<ProcessOfferings>
	<Process processVersion="0.1">
		<ows:Identifier>dummyprocess</ows:Identifier>
		<ows:Title>Dummy Process</ows:Title>
                        <ows:Abstract>Dummy process for testing of the WPS service. 
                        This dummy process will accept 1 inputs number and return the proper XML document
                        with an add 1 operation.
                        </ows:Abstract>
	</Process>
</ProcessOfferings>

WPS DescribeProcess request

The DescribeProcess can be performed by a KVP or XML request. As mandatory parameters it has service, request, version and Identifier (process name indicated in the ProcessOfferings XML reply of GetCapabilities)

Example: www.intamap.org/wps.py?Service=WPS&Request=DescribeProcess&Version=0.4.0&Identifier=DummyProcess

or using a XML sent by POST:

<?xml version="1.0" encoding="UTF-8" ?>
<DescribeProcess service="WPS" version="0.4.0"
xmlns="http://www.opengeospatial.net/wps"
xmlns:ows="http://www.opengeospatial.net/ows"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengeospatial.net/wps..\wpsDescribeProcess.xsd">
    <ows:Identifier>DummyProcess</ows:Identifier>
</DescribeProcess>

The response shall be a ProcessDescription data structure that contains one or more process descriptions for the request process(es) identifier. Each description includes brief information on the process, metadata and description of the inputs and outputs parameters.

Example of Input definition (part of the XML response):

<DataInputs>
	<Input>
		<ows:Identifier>Input1</ows:Identifier>
		<ows:Title>Number Input</ows:Title>
		<LiteralData>
			<SupportedUOMs defaultUOM="meters"/>
			<ows:AnyValue/>
		</LiteralData>
		<MinimumOccurs>1<MinimumOccurs>
	<Input>
</DataInputs>

WPS defines three types of Input/Outputs for data: ComplexData, LiteralData and BoundingBoxData. The ComplexData provides support of XML or imagery (ex: GeoTiff), LiteralData processes mainly simple strings and/or numbers, while BoundingBoxData information provides geoghapical coordinates using a specific Coordinate Reference System (CRS).

WPS Execute Request

The Execute operation allows WPS clients to run a specified process implemented by the server, using input parameter values provided and returning the output values(s) produced. The outputs can be returned as direct response to the request. Alternatively, the server can be directed to store the results(s) as web accessible resources. If stored the XML response will contain an URL to each stored output.

The Execute response can be returned immediately following acceptance by the server of the process execution, in this case the Execute response includes information on the status of the process.

The Execute response only has service, request, version and identifier as mandatory, the DataInputs are not mandatory since some processes can be implemented without inputs. It can also defined the desired output, if the results is stored and if there should be a status reply.

Example: www.intamap.org/wps.py?Service=WPS&Request=Execute&Version=0.4.0&Identifier=DummyProcess&Datainputs=Input1,0

or as XML:

<?xml version="1.0" encoding="UTF-8" ?>
<Execute service="WPS" version="0.4.0" store="false" status="false"
xmlns="http://www.opengeospatial.net/wps"
xmlns:ows="http://www.opengeospatial.net/ows"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengeospatial.net/wps..\wpsExecute.xsd">
	<ows:Identifier>DummyProcess</ows:Identifier>
	<DataInputs>
		<Input>
			<ows:Identifier>Input1</ows:Identifier>
			<ows:Title>Input that will be returned</ows:Title>
			<LiteralValue>100</LiteralValue>
		</Input>
	</DataInputs>
	<!--DataOutput, like DataInputs are not mandatory-->
	<!-- No need to define DataOutput -->
</Execute>

In this simple example of adding one to the input number:

<?xml version="1.0"?>
<ExecuteResponse xmlns="http://www.opengeospatial.net/wps" xmlns:ows="http://www.opengeospatial.net/ows" 
xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.opengeospatial.net/wps http://www.bnhelp.cz/schema/wps/0.4.0/wpsExecute.xsd">
	<ows:Identifier>
		dummyprocess
	</ows:Identifier>
	<ProcessOutputs>
		<Output>
			<ows:Identifier>
				Output1
			</ows:Identifier>
			<ows:Title>
				Returning Output
			</ows:Title>
			<ows:Abstract>
				Value +1 that will be returned from the input1 value
			</ows:Abstract>
			<LiteralValue>
				1.0
			</LiteralValue>
		</Output>
	</ProcessOutputs>
</ExecuteResponse>

WPS Exceptions

Exceptions are raised when the WPS server encounters an error while performing an operation. The exception is reported back as an XML document.

The GetCapabilities and DescribeProcess have the following exception code possibilities: MissingParameterValue, InvalidParamterValue and NoApplicableCode. The Execute operation has the same exceptions and ServerBusy, FileSizeExceeded (Server can't handle the file size of on the inputs). The exception document also indicate which parameter has the problem (indicating the locator)

The GetCapabilities request with out the service parameter would have the following exception:

www.intamap.org/wps.py?Request=GetCapabilities

(version parameter lacking)

<ExceptionReport version="1.0.0">
	<Exception exceptionCode="MissingParameterValue" locator="service"/>
</ExceptionReport>

Currently WPS is in version 0.4.0, the new 1.0.0 will be approved any time soon.

WPS 1.0.0

The WPS 1.0.0 document is under approval of the OGC (05/Nov/2007) for final release. The platform neutral operation and response will not change considerable from WPS 0.4.0, however the same operations requests and responses will be supported by SOAP/WSDL.

Overview

The new WPS 1.0.0 provides new insides on the utility of WPS, this was already "hidden" on 0.4.0 but know they are clearly stated:

- Data can be embedded in the Execute request or referred as a web accessible resource. In the former approach, WPS acts as a stand-alone service. In the later fashion, WPS acts as middleware service for data, by obtaining data from an external resource in order to run a process on the local implementation.

- WPS is normally an atomic function that performs a specific geospatial calculation. Chaining of WPS process facilitates the creation of repeatable workflows. WPS can be incorporated into service chains in a number of ways: 1) A BPEL (Bussiness Process Execution Language) engine can be used to orchestrate a service chain that includes one or more WPS processes. 2) A WPS process can be designed to call a sequence of web services including other WPS processes, thru acting as the service chaining engine. 3) Simple service chains can be encoded as part of the execute query. Such cascading service chains can be executed via a GET interface.

SOAP

SOAP will be supported in WPS 1.0.0 (aside from WSDL). SOAP can work as as "wrapper" around the WPS request and responses, this will offer the ability to add security certificates as well encryption to web-based geoprocessing transactions.

Example of XML request of GetCapabilities (version 1.0.0):

<?xml version="1.0" encoding="UTF-8"?>

<!-- WPS GetCapabilities request-->

<!-- Equivalent GET request is http://foo.bar/foo?Service=WPS&Version=1.0.0&Request=GetCapabilities&Language=en-CA -->

<ows:GetCapabilities xmlns:ows="http://www.opengis.net/ows/1.1" xmlns:wps="http://www.opengis.net/wps/1.0.0" 
xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.opengis.net/ows/1.1 ..\wpsGetCapabilities_request.xsd" language="en-CA" service="WPS">

	<ows:AcceptVersions>

		<ows:Version>1.0.0</ows:Version>

	</ows:AcceptVersions>

</ows:GetCapabilities>

Example of SOAP request for GetCapabilities (version 1.0.0):

<?xml version="1.0" encoding="UTF-8"?>

<!-- WPS GetCapabilities request encoded in SOAP -->

<!-- Equivalent GET request is http://foo.bar/foo?Service=WPS&Version=1.0.0&Request=GetCapabilities&Language=en-CA -->

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

	<soap:Body>

		<ows:GetCapabilities xmlns:ows="http://www.opengis.net/ows/1.1" 
xmlns:wps="http://www.opengis.net/wps/1.0.0" xmlns:xlink="http://www.w3.org/1999/xlink" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.opengis.net/ows/1.1 ..\wpsGetCapabilities_request.xsd" language="en-CA" service="WPS">

			<ows:AcceptVersions>

				<ows:Version>1.0.0</ows:Version>

			</ows:AcceptVersions>

		</ows:GetCapabilities>

	</soap:Body>

</soap:Envelope>

WPS Operations

Operations requesting are note changed from 0.4.0 to 1.0.0, with a requesting encoding using XML was added to GetCapabilities (as optional). The new major introductions are as follow.

• GetCapabilities

New language implementation that should be implemented by all clients and servers using multilingual capabilities. The new GetCapabilities request using KVP will be:

www.intamap.org/wps.py?Service=WPS&Request=GetCapabilities&AcceptVersion=1.0.0&Language=en-CA

The response document will contain and Languages mandatory part with the list of available languages, also new to 1.0.0 is the adding of the location of a WSDL document describing all operations and processes offered by the server.

• DescribeProcess

New language implementation during request (optional), that will also be contained in the response document.

Addition of WSDL document location (as in GetCapabilities).

The inputs that have a ComplexData structure (images, GML etc) have new description called maximumMegabytes that indicates how big can a input be.

• Execute

More emphasis in raw output. The output can be in a form o a XML response document, stored as a web resource or a single server reply containing for example a GeoTiff or GML (the possibilities are described in the DescribreProcess and the format is requested during the Execute).

The operation request has a new optional parameter: ResponseForm, it defines the response type of the WPS, either raw data or XML document. If absent the response shall be a response document containing the outputs

New Language request option.

New implementation of HTTP header/body parameters; The input request may contain the HTTP header data and body that the client wishes to be used in the output.

New ResponseDocument implementation that indicate which response document should be used (the possibilities are described in DescribeProcess).

New RawDataOuput used for requesting raw data and its attributes.

New Lineage request, this boolean parameter indicates if the execute operation response shall include the DataInputs and OutputDefinition elements (in WPS 0.4.0 the DataInputs and OutputDefinitons will be automatically included in the response document).

Considerable change in the DataInputs: A semicolon (;) shall be used to separate one input from the next An equal sign (=) shall be used to separate the input name from its value and attributes , and an attribute name from its value

	
   Example:
   ..DataInputs=Value1=10;Value2=30

An at symbol (@) shall be used to separate an input value from its attributes and one attribute from another.

   Example:
   DataInputs=Object=@xlink:href=http%3A%2F%2Ffoobar.bar%2Ffoo
   (DataInputs=Object=@xlink:href=http://foobar.bar/foo)

Field names and attribute names are case sensitive. Incorrect field names and attributes shall raise an InvalidParameterException.

All field values and attributes values hall be encoded using the standard Internet practice for encoding URLs.

To the original status response of execute (ProcessAccepted, ProcessStarted, ProcessFailed and ProcessSucceded) it was added ProcessPaused that is returned when for some reasson the process has been paused.

The status data structure of the Execute reply now has a creationTime part that indicates the time (UTC) when the process finishes.

New Exception Code responses: FileSizeExceeded, StorageNotSupported, VersionNegociationFailed

- FileSizeExceeded == The file size of one of the input paramenters was to large for the process to handle
- StorageNotSupported == Execution operation request included store=true, but storage is not offered by the server
- VersionNegociationFailed ==Service version for a ComplexData xlin:href input was not supported by the referenced server and version negotiation failed

Conclusion

The major improvements of the new WPS 1.0.0 are related to the SOAP/WSDL, language support and DataInputs