This OGC Web Coverage Service (WCS) – Transaction Extension (in short: WCS Transaction) defines an extension to the WCS Core [OGC 09-110] for updating coverage offer­ings on a server.

This WCS Transaction standard defines three requests:

• InsertCoverage for adding a coverage provided as parameter to the WCS server’s cov­erage offering. After successful completion of the insert request, this coverage will be accessible for all WCS operations.
• DeleteCoverage for entirely removing a coverage. The coverage is identified by its coverage id passed in the request, from the WCS server’s coverage offering. After successful completion of this request, this coverage will not be accessible through any WCS operation. However, subsequently a new coverage may be created using the same identifier; such a coverage will bear no relation to the one previously deleted.
• UpdateCoverage for modifying parts of a coverage existing in a WCS server’s coverage offering. The coverage is identified by its coverage id passed in the request. As per the OGC Coverage Implementation Schema [OGC 09-146r2], all updates must maintain internal consistency of the coverage.

All requests defined in this Transaction Extension adhere to the ACID^[1] (atomicity, consistency, isolation, durability) concepts of database transactions.

The extension name, Transaction, traces back to the database concept of transactions, which has been adopted here.

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, wcs, coverage, transaction

This standard specifies three request types as an extension to the OGC Web Coverage Service (WCS): InsertCoverage, DeleteCoverage, and UpdateCoverage. These operations allow clients to modify a server’s offerings by adding, deleting, and updating coverages, respectively.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

• Jacobs University Bremen
• Envitia Ltd
• European Union Satellite Center (SatCen)

All questions regarding this submission should be directed to the editor or the submitters:

1.    Scope

This OGC WCS Transaction Extension – in short: Transaction Extension or WCS-T – defines how to modify a WCS server’s coverage offering.

2.    Conformance

This document establishes the following requirements and conformance classes:

•   Requirement insert+delete, of URL http://www.opengis.net/spec/WCS_service-extension_transaction/2.0/req/insert+delete. The corresponding conformance class is insert+delete, with URL http://www.opengis.net/spec/WCS_service-extension_transaction/2.0/conf/insert+delete.

This is the mandatory core conformance class of this extension.

•   Requirement update, of URL http://www.opengis.net/spec/WCS_service-extension_transaction/2.0/req/update. The corresponding conformance class is update, with URL http://www.opengis.net/spec/WCS_service-extension_transaction/2.0/conf/update.

The standardization target for all requirements and conformance classes are WCS implementations.

Requirements URLs defined in this document are relative to:

http://www.opengis.net/spec/WCS_service-extension_transaction/2.0/req,

Conformance test URLs are relative to:

 http://www.opengis.net/spec/WCS_service-extension_transaction/2.0/conf.

Annex A lists the conformance tests which shall be exercised on any software artefact claiming to implement WCS-T^[2].

3. Normative References

The following normative documents contain provisions that, through referenced in this text, constitute provisions to this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

This OGC WCS Transaction Extensionstandard consists of the present document and an XML Schema. The complete WCS-T is identified by the OGC URL:

http://www.opengis.net/spec/WCS_service-extension_transaction/2.0.

This document has the OGC URL http://www.opengis.net/doc/IS/WCS_service-extension_transaction/2.0.

The complete WCS standard (core and all extensions) is available for download from http://www.opengeospatial.org/standards/wcs.

Additionally, the XML Schema for this standard is published online at: http://schemas.opengis.net/wcs/transaction/2.0.

In the event of a discrepancy between bundled and schema repository versions of the XML Schema files, the schema repository shall be considered normative.

The normative documents for the conformance classes in this extension are listed in Table 1.

Table : Conformance class dependencies^[3]

Transaction conformance class	Dependency document	Dependency conformance class
insert+delete	OGC 09-146rX, GML 3.2.1 Application Schema for Coverages, version 1.0 OGC 09-110rX, OGC® Web Coverage Service 2.0 Interface Standard - Core	gml-coverage core
update	This document	insert+delete

4. Terms and Definitions

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r8], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of Inter­nat­ional Standards. In particular, the word “shall” (not “must”) is the verb form used to in­dic­ate a requirement to be strictly followed to conform to this standard.

For the purposes of this document, the following additional terms and definitions apply.

4.1 Input coverage

 

Coverage sent to the server through a WCS-T request

4.2 Updated coverage

 

Coverage to be updated through a WCS-T request

5. Conventions

5.1    UML notation

Unified Modeling Language (UML) static structure diagrams appearing in this specification are used as described in Subclause 5.2 of OGC Web Services Common [OGC 06-121r9].

5.2    Data dictionary tables

The UML model data dictionary is specified herein in a series of tables. The contents of the columns in these tables are described in Subclause 5.5 of [OGC 06-121r9]. The contents of these data dictionary tables are normative, including any table footnotes.

5.3    Namespace prefix conventions

The following namespaces are used in this document. The prefix abbreviations used constitute conventions used here, but are notnormative. The namespaces to which the prefixes refer are normative, however.

5.4    Multiple representations

When multiple representations of the same information are given in a standard document these are consistent. Should this not be the case then this is considered an error, and the XML schema shall take precedence.

6.    Insert+deleterequirements class

6.1    Overview

This Clause 6 establishes the mandatory Transaction Extension core requirements class, insert+delete. Clients and servers supporting this insert+delete requirements class shall support insertion into and deletion from a WCS server’s coverage offerings through two dedicated request types, InsertCoverage and DeleteCoverage.

6.2    Modifications to GetCapabilities

A server announces support of the insert+delete requirements class to a client by adding the URL identifying this extension to the list of supported extensions delivered in the Capabilities document.

Requirement 1              
A WCS service implementing requirements class insert+deleteof this Transaction Extension shall include the following URL in the Profile element of the ServiceIdentification in a GetCapabilitiesresponse:  
http://www.opengis.net/spec/WCS_service-extension_transaction/2.0/conf/insert+delete

6.3    Modifications to DescribeCoverage

None.

6.4    Modifications to GetCoverage

None.

6.5    InsertCoverage request

6.5.1    InsertCoverage request

This request adds the coverage passed into the server’s offering. The coverage can be attached directly or via http reference. In any case, the coverage must conform with GMLCOV [OGC 09-146] in some encoding supported by the server. Where the GML coverage schema permits xlink references inside the coverage, these may be utilized to reference the corresponding parts of a coverage instead of providing them verbatim. All references must be resolvable by the server.

A GetCapabilities request sent to a server retrieves information about the encoding formats supported, among other details.

By default, the identifier of the new coverage on the server is the one indicated in the input coverage. As coverage identifiers have to be unique within a WCS offering, sometimes it is not easy for a client to determine an unused name for a new coverage. By setting a flag, useId=new, a client can request that the server shall generate a unique identifier and assign it to the newly inserted coverage. In this case, the identifier value provided with the input coverage is ignored.

The server may use some name generation scheme, such as consecutive numbering or an ASCII encoding of timestamps, coverage type, geographic extension, etc. However, such naming is pure informal convention and not utilized in any way by WCS.

The useId flag impacts behaviour through its mere presence, its value does not matter. By mere convention (and without any obligation for an implementation) new should be used. An implementation – such as the XML Schema being part of this specification – may, therefore, decide to implement this parameter as a flag without value.

By default, coverages inserted can be modified in their domain set (i.e., their spatial / temporal extent) through subsequent updates. By passing the optional parameter isExtensible with a value of false, the coverage is mark­ed as having an extensible domain set (while all other constituents remain fixed, such as the Native CRS^[5] – hence, it is not possible, for example, to change the number of dimensions a coverage has).

See requirements class update for further details.

Requirement 2              
An InsertCoverage request shall adhere to Figure 1, Table 3, and the XML schema defined for this Transaction Extension.

Requirement 3              
An InsertCoverage request shall contain either a coverage or a coverageRef parameter.

Requirement 4              
The coverage parameter in an InsertCoverage request, if present, shall contain a coverage document as per GMLCOV [OGC 09-146].

Requirement 5              
The coverageRef parameter in an InsertCoverage request, if present, shall be a URL resolving to a coverage document as per GMLCOV [OGC 09-146].

6.5.2    InsertCoverage response

The response to a successful InsertCoverage request is the identifier of the newly created coverage.

Requirement 6              
The response to a successful InsertCoverage request shall adhere to Figure 2, Table 4, and the XML schema defined for this Transaction Extension.

If a name was indicated in the coverage this is the name of the new coverage returned; otherwise, the server provides a self-selected name which is unique within this server’s offering.

Requirement 7              
The response to a successful InsertCoverage request shall be:
- some coverage identifier previously not existing in the server’s offering if the request contained a useId pararmeter; or
- the identifier of the input coverage if the request contained no useId pararmeter.

No requirement is placed on the effect of an isExtensible parameter in this requirements class; see Subclause 7.7 (UpdateCoverage) for the effect of this parameter.

Successful requests follow the “durability” aspect of ACID transactions.

Requirement 8              
After completion of a successful InsertCoverage request, the identifier of the coverage established in the server’s offering shall be available in this WCS service’s coverage offering.

Successful requests follow the “consistency” aspect of ACID transactions.

Requirement 9              
After completion of a successful InsertCoverage request, a subsequent GetCoverage request accessing the coverage using the coverage identifier returned by this InsertCoverage shall deliver a valid coverage identical to the one submitted in the InsertCoverage request (except for the coverage identifier if generated by the server).

6.6    DeleteCoverage request

6.6.1    DeleteCoverage request

Requirement 10           
A DeleteCoverage request shall adhere to Figure 3, Table 5, and the XML schema defined for this Transaction Extension.

Requirement 11           
Each coverageId submitted in a DeleteCoverage request shall identify a coverage existing in the coverage offering of the WCS server addressed.

Multiple occurrences of the same identifier are not harmful.

6.6.2    DeleteCoverage response

Requirement 12           
The response to a successful DeleteCoverage request shall be empty.

Requirement 13           
A DeleteCoverage request shall succeed if and only if all coverages addressed in the request have been deleted successfully.

6.7    Atomicity and isolation

Requests follow the “atomicity” (“all or nothing”) aspect of ACID transactions.

Requirement 14           
No partial effect of an InsertCoverage or DeleteCoverage request shall be visible in the WCS server’s behavior after successful completion of this request.

Requirement 15           
No effect of an unsuccessful InsertCoverage or DeleteCoverage request shall be visible in the WCS server’s future behavior.

Requests follow the “isolation” aspect of ACID transactions.

Requirement 16           
During processing of an InsertCoverage or DeleteCoverage request in a WCS server, no intermediate state of processing shall be visible to other, concurrent requests to this WCS server, but only the complete, final result of the operation.

Due to the technicalities of the OGC request structures some of the above aspects overlap.

6.8    Encodings

6.8.1    Overview

This Subclause specifies, for each WCS protocol binding that a client and server support, encoding of an InsertCoverage and DeleteCoverage operation.

6.8.2    GET/KVP Encoding

Requirement 17           
In an InsertCoverage request using the GET/KVP protocol, a coverageRef parameter with http URL url shall be represented by an http key/value pair as follows:
            COVERAGEREF=url

Passing a coverage directly in the request is not supported by the GET/KVP protocol binding.

Requirement 18           
In an InsertCoverage request using the GET/KVP protocol, a useId parameter shall be represented as
            USEID=x
where x is any valid parameter string.

The value will be ignored anyway, but it is recommended to use “new” for documentation purposes:
            USEID=new

Requirement 19           
In an InsertCoverage request using the GET/KVP protocol, an isExtensible parameter shall be represented as
            ISEXTENSIBLE=x
where x is any valid parameter string.

Example    The following is a complete InsertCoverage request in GET/KVP notation. The request results in a new coverage named NewLittleCoverage offered by the service, superseding any coverage identifier the coverage referenced in the request may have:

http://www.acme.com/ows?
        SERVICE=WCS &
        VERSION=2.0 &
        REQUEST=InsertCoverage &
        COVERAGEREF=http://www.acme.com/mycoverage.gml &
        USEID=new &
        ISEXTENSIBLE=true

The COVERAGEREF URL in the above example needs to be escaped properly, as per OWS Common. This escaping has been omitted for the reader’s convenience. Further, blanks have been intro­duced for the same purpose.

Requirement 20           
In a DeleteCoverage request with n>0 coverage identifiers id₁,…,id_n using the GET/KVP protocol, a coverageId parameter shall be represented by an http key/value pair as follows:
            COVERAGEID=id₁,…,id_n

Example    The following is a complete DeleteCoverage request in GET/KVP notation:

http://www.acme.com/ows?
        SERVICE=WCS &
        VERSION=2.0 &
        REQUEST=DeleteCoverage&
        COVERAGEID=GoodByeCoverage

6.8.3    XML/POST Encoding

Requirement 21           
An InsertCoverage request using the XML/POST protocol shall be encoded as an wcst:InsertCoverage element.

Example    The following is a complete InsertCoverage request plus a response (assuming success) in XML/POST encoding:

<?xml version=“1.0” encoding=“UTF-8”?>
 <wcst:InsertCoverage xmlns:wcs=“http://www.opengis.net/wcs/2.0”
     xmlns:wcst=“http://www.opengis.net/wcs_service-extension_transaction/2.0” 
     xmlns:gml=“http://www.opengis.net/gml/3.2”
     xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
     xsi:schemaLocation=“http://www.opengis.net/wcs_service-extension_transaction/2.0 
     http://schemas.opengis.net/wcs/transaction/2.0/wcsTransaction.xsd”
     service=“WCS” version=“2.0”>
     <wcst:coverageRef>
         http://www.acme.com/mycoverage.gml
     </wcst:coverageRef>
    <wcst:useId/>
    <wcst:isExtensible>0</wcst:isExtensible>
 </wcst:InsertCoverage>

<?xml version=“1.0” encoding=“UTF-8”?>
 <wcst:InsertCoverageResponse
     xmlns:wcst=“http://www.opengis.net/wcs_service-extension_transaction/2.0” 
     xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
     xsi:schemaLocation=“http://www.opengis.net/wcs_service-extension_transaction/2.0 
     http://schemas.opengis.net/wcs/transaction/2.0/wcsTransaction.xsd” >
     NewLittleCoverage
 </wcst:InsertCoverageResponse>

Requirement 22           
A DeleteCoverage request using the XML/POST protocol shall be encoded as a wcst:DeleteCoverage element.

Example    The following is a complete DeleteCoverage request in XML/POST encoding:

<?xml version=“1.0” encoding=“UTF-8”?>
 <wcst:DeleteCoverage xmlns:wcs=“http://www.opengis.net/wcs/2.0”
     xmlns:wcst=“http://www.opengis.net/wcs_service-extension_transaction/2.0” 
     xmlns:gml=“http://www.opengis.net/gml/3.2”
     xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
     xsi:schemaLocation=“http://www.opengis.net/wcs_service-extension_transaction/2.0 
     http://schemas.opengis.net/wcs/transaction/2.0/wcsTransaction.xsd”
     service=“WCS” version=“2.0”>
     <wcst:coverageId>GoodByeCoverage</wcst:coverageId>
 </wcst:DeleteCoverage>

6.8.4    SOAP Encoding

Requirement 23           
An InsertCoverage request using the SOAP protocol shall be encoded as an wcst:InsertCoverage element.

Requirement 24           
A DeleteCoverage request using the SOAP protocol shall be encoded as a wcst:DeleteCoverage element.

6.9    Exceptions

Requirement 25           
When a WCS server encounters an error while evaluating an InsertCoverage or DeleteCoverage operation it shall return an exception report message chosen as indicated in Table 6 with a locator parameter value as specified in the right column of Table 6 for each exception­Code listed.

7.    Update requirements class

7.1    Overview

This Clause 7 establishes an optional Transaction Extension requirements class, update. Clients and servers supporting this update requirements class shall support modification of coverages offered by a WCS server.

7.2    Modifications to GetCapabilities

A server announces support of the update requirements class to a client by adding the URL identifying this extension to the list of supported extensions delivered in the Capabilities document.

Requirement 26           
A WCS service implementing requirements class updateof this Transaction Extension shall include the following URL in the Profile element of the ServiceIdentification in a GetCapabilitiesresponse:
 http://www.opengis.net/spec/WCS_service-extension_transaction/2.0/conf/update

7.3    Modifications to DescribeCoverage

None.

7.4    Modifications to GetCoverage

None.

7.5    Modifications to InsertCoverage

None.

7.6    Modifications to DeleteCoverage

None.

7.7    UpdateCoverage request

7.7.1    Overview

The UpdateCoverage request type serves to modify some or all range values of a coverage existing in a coverage offering.

No other coverage components, beyond range set values, can be changed through UpdateCoverage. In particular, it is not possible to change the domain set (i.e., the overall spatio-temporal extent) and the range type (such as nil values).

A coverage’s range set can be replaced completely or partially (so-called “partial update”). For a complete update, no further parameters are required. For a partial update, however, the set of target positions to be updated must be indicated by specifying:

• The domain subset to be updated (unless the whole of the input coverage’s domain set is to be replaced), expressed in the stored coverage’s Native CRS.
• The range components to be updated (unless all range components are to be replaced).

  Example            An UpdateCoverage request may contain an RGB image of which only the red band is used for updating, according to the WCS Range component standard.

• Optionally, a mask indicating which direct positions of the input coverage are to be used for updating the coverage on the server. Only those direct positions are considered for the update where the mask has a direct position as well and where additionally the range value of the mask at this direct position has a value of 1.

By way of these indicators, a subset of the input coverage can be used for updating.

Example    A 2-D lat/long input coverage may replace a rectangular part of a 3-D lat/long/t coverage (e.g., a satellite image timeseries), given by a 3-D bounding box [ lat1 : lat2, long1 : long2, t1 ] indicating a slice at time position t1 with the lat/long extent indicated. Cells outside of this domain will remain unaffected. Further, assuming a hyperspectral range type containing red, green, and blue components, the input coverage may substitute only these three bands, leaving all other bands unaffected. Finally, a mask may be provided indicating those areas to be updated by a value of 1.

7.7.2    UpdateCoverage request

Requirement 27           
An UpdateCoverage request shall adhere to Figure 4, Table 8, and the XML schema defined for this WCS Transaction Extension.

Where URLs are provided these must point to valid coverages.

Requirement 28           
In an UpdateCoverage request containing a URL (as inputCoverageRef or maskRef), each such URL shall reference a valid coverage as per GMLCOV [OGC 09-146].

Several constraints must be maintained in order to ensure consistency of the resulting updated coverage.

In a complete replacement (i.e., where no domain subset, range component, or masking parameter have been indicated):

• Native CRS of input coverage = Native CRS of updated coverage
• Domain set of input coverage = domain set of updated coverage
• Range type of input coverage = range type of updated coverage

The updated coverage’s description (i.e., WCS::CoverageDescription) will stay the same after a complete replacement if the coverage was inserted non-extensible. If, during InsertCoverage, isExtensible=true was specified then the domain set (but no other constituent like Native CRS, dimension, etc.) may be changed through an UpdateCoverage request.

Requirement 29           
In an UpdateCoverage request containing neither a subset, nor a rangeComponent, nor a mask (nor a maskRef) parameter, the following shall hold for an input coverage ci (referenced or passed directly) and an updated coverage cu (where “=” in case of XML elements means deep equality):
– ci/gml:domainSet =
   cu/gml:domainSet
– ci/gmlcov:rangeType/swe:Record/swe:field/@name =
   cu/gmlcov:rangeType/swe:Record/swe:field/@name

In a partial replacement where a domain subset is indicated the following must hold:

• domain subsetting must use the axes present in the axis set of the updated overage’s Native CRS (Requirement 31); and
• only if the coverage has been created as not extensible (see Subclause 6.5) then the target domain to be updated must be a subset of the updated coverage’s domain set. If the coverage has been created as extensible then no such restriction holds.

Requirement 30           
In an UpdateCoverage request containing a subset parameter, the dimension item shall be one of the axis names defined in the CRS in which the domain set of the coverage updated is expressed.

Example    The following specification of the area to be replaced is valid with regard to axis labels if the updated coverage has axis labels Lat, Long, and H, assuming the Get/KVP encoding (see Subclause 7.8):

       SUBSET=Lat(5.0:10.0) & SUBSET=H(0.0)

Requirement 31           
In an UpdateCoverage request containing one or more subset parameter, all dimension names shall be distinct.

Example    The following specification is illegal:

       SUBSET=Lat(5.0:10.0) & SUBSET=Lat(0.0)

Requirement 32           
In an UpdateCoverage request addressing a coverage not marked as extensible (e.g., created through an InsertCoverage request without parameter isExtensible=true), the UpdateCoverage subset domain shall be contained within the domain set of the coverage to be updated.

In a partial replacement where range componentsare indicated the following must hold:

• all input coverage range components indicated must be present in input coverage; and
• all updated coverage range components indicated must be present in updated coverage

Requirement 33           
In an UpdateCoverage request containing a rangeComponent parameter, this parameter shall consist of an unordered list of string pairs (rcu,rci) where:
– the first component rcu is identical to the name attribute of the swe:field element of one of the range components of the updated coverage; and
– the second component rci is identical to the name attribute of the swe:field element of one of the range components of the input coverage.

Example    In the Get/KVP encoding (see Subclause 7.8) of a request updating bands 1, 2, and 5 from an RGB image the rangeComponent parameter can be written as

       RANGECOMPONENT=band4:red,band3:green,band2:blue

In a partial replacement with a mask all range values in the mask are either 0 or 1.

Requirement 34           
In an UpdateCoverage request containing a mask parameter, the range set of this mask­ shall contain only range set values of 0 and 1.

0 and 1 are used as indicator values instead of Boolean true and false because many relevant formats (such as image encodings) do not support a Boolean data type.

Requirement 35           
 In an UpdateCoverage request against a server not supporting the WCS CRS extension, all CRSs occurring (in the input coverage and the mask) shall be identical to the Native CRS of the coverage under inspection.

In other words, utilizing some other CRS is ad­miss­ible only if the WCS addressed also supports the CRS Extension and the particular CRS used by the client.

7.7.3    UpdateCoverage response

The response to a successful UpdateCoverage request is empty. On the server, the following side effects will hold.

These changes will be visible, e.g., in subsequent GetCoverage requests.

Requirement 36           
After a successful UpdateCoverage request the following shall hold:

• the domain set of the new updated coverage is unchanged, unless a subset parameter changes it;
• the range type of the new updated coverage is unchanged; and
• the range set of the new updated coverage is identical to the range set of the input coverage, unless a subset, rangeComponent, or mask parameter changes it.

Requirement 37           

After a successful UpdateCoverage request with a subset parameter, the following shall hold:

• the domain set of the new updated coverage is the union of original updated and input coverage, in case of a gridded coverage: all direct positions of the smallest grid encompassing updated and input coverage; and
• the range set of the new updated coverage consists of
  • the input coverage values, at direct positions  in the domain set of the input coverage, for all range components to be updated;
  • the updated coverage values, at direct positions in the domain set of the original updated coverage, for all range components to be updated; and
  • a value x, for all other direct positions of the new updated coverage, which is taken non-deterministically from the nil values of the updated coverage; or 0 for those range components where no nil value exists.

Requirement 38           
After a successful UpdateCoverage request with a rangeComponent parameter, the following shall hold:

• for each direct position p of the new updated coverage which is affected by the update, range component values are as follows: for each pair (rci,rcu) in the rangeComponent parameter, the range component value named rci of the input coverage at p is identical to the range component value named rcu of the new updated coverage, as per range type definitions of input and updated coverage.

Requirement 39           
After a successful UpdateCoverage request with a mask parameter, the following shall hold:

• for each direct position p of the new updated coverage, the range value is changed (according to the other request parameters) if and only if position p is contained in some direct position q of the mask coverage and the range value of the mask coverage at position q is 1; otherwise the value of the new updated coverage is equal to its original value.

7.8    Encodings

7.8.1    Overview

This Subclause specifies, for each WCS protocol binding that a client and server support, encoding of an UpdateCoverage operation.

7.8.2    GET/KVP Encoding

Requirement 40           
In an UpdateCoverage request using the GET/KVP protocol, a coverageId parameter shall be represented as
            COVERAGEID=c
where c is an string.

Requirement 41           
In an UpdateCoverage request using the GET/KVP protocol, a subset parameter shall be represented as
            SUBSET=a(p1:p2)
or
     SUBSET=a(p)
where a is an string and p, p1, p2 are coordinates of direct positions.

Example    In the Get/KVP encoding of a request using subsetting the following specification is valid with respect to axis labels if the updated coverage has axis labels Lat, Long, and H:

       SUBSET=Lat(5.0:10.0) & SUBSET=H(0.0)

Requirement 42           
In an UpdateCoverage request using the GET/KVP protocol, a rangeComponent parameter shall be represented as
            RANGECOMPONENT=cu₁:ci₁,…,cu_n:ci_n
where cu_i and ci_i are strings for 1≤i≤nÎN.

Example    In the Get/KVP encoding of a request updating bands 1, 2, and 5 from an RGB image the rangeComponent parameter can be written as

       RANGECOMPONENT=band1:red,band2:green,band5:blue

Requirement 43           
In an UpdateCoverage request using the GET/KVP protocol, an inputCoverageRef parameter shall be represented as
            INPUTCOVERAGEREF=u
where u is some URL.

Passing a coverage directly in the request is not supported by the GET/KVP protocol binding.

Requirement 44           
In an UpdateCoverage request using the GET/KVP protocol, a maskRef parameter shall be represented as
            MASKREF=u
where u is some URL.

Example    The following is a complete UpdateCoverage request in GET/KVP encoding:

http://www.acme.com/ows?
        SERVICE=WCS &
        VERSION=2.0 &
        REQUEST=UpdateCoverage &
        COVERAGEID=CoverageToBeUpdated &
        INPUTCOVERAGEREF=http://www.acme.com/update.gml &
        SUBSET=Lat(5.0:10.0) & SUBSET=H(0.0) &
        RANGECOMPONENT=band1:red,band2:green,band5:blue &
        MASKREF=http://www.acme.com/mask.gml

Both the INPUTCOVERAGEREF and MASKREF URLs in the above example need to be escaped properly, as per OWS Common; this has been omitted for the reader’s convenience. Further, blanks have been introduced for the same purpose.

7.8.3    XML/POST Encoding

Requirement 45           
An UpdateCoverage request using the XML/POST protocol shall be encoded as a wcst:Up­dateCoverage element.

Example    The following is a complete UpdateCoverage request in GET/KVP encoding:

<?xml version=“1.0” encoding=“UTF-8”?>
 <wcs:UpdateCoverage
     xmlns:wcst=“http://www.opengis.net/wcs_service-extension_transaction/2.0”
     xmlns:wcs=“http://www.opengis.net/wcs/2.0”
     xmlns:gml=“http://www.opengis.net/gml/3.2”
     xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
     xsi:schemaLocation=“http://www.opengis.net/wcs_service-extension_transaction/2.0 http://schemas.opengis.net/wcs/transaction/2.0/wcsTransaction.xsd”
     service=“WCS” version=“2.0”>
     <wcst:coverageId>CoverageToBeUpdated</wcst:coverageId>
     <wcst:inputCoverageRef>
         http://www.acme.com/update.gml
     </wcst:inputCoverageRef>
     <wcs:DimensionTrim>
         <wcs:Dimension>Lat</wcs:Dimension>
         <wcs:TrimLow>5.0</wcs:TrimLow>
         <wcs:TrimHigh>10.0</wcs:TrimHigh>
     <wcs:DimensionSlice>
         <wcs:Dimension>H</wcs:Dimension>
         <wcs:SlicePoint>0.0</wcs:SlicePoint>
     </wcs:DimensionSlice>
     <wcst:rangeComponent>
         <wcst:inputRangeComponent>
             band1
         </wcst:inputRangeComponent>
         <wcst:updatedRangeComponent>
             red
         </wcst:updatedRangeComponent>
     <wcst:maskRef>
         http://www.acme.com/mask.gml
     </wcst:maskRef>
 </wcst:InsertCoverage>

7.8.4    SOAP Encoding

Requirement 46           
An UpdateCoverage request using the SOAP protocol shall be encoded as a wcst:Update­Coverage element.

7.9    Exceptions

Requirement 47           
When a WCS server encounters an error while evaluating an UpdateCoverage operation it shall return an exception report message chosen as indicated in Table 6 with a locator parameter value as specified in the right column of Table 6 for each exceptionCode listed.

Annex : Conformance Class Abstract Test Suite (Normative)

A Transaction Extension implementation must satisfy the following system characteristics to be conformant with this standard.

Test identifiers below are relative to http://www.opengis.net/spec/WCS/2.0/WCS_service-extension_transaction/2.0/conf.

A.1   Conformance Test Class: insert+delete

The OGC URL identifier of this conformance class is:
http://www.opengis.net/spec/WCS/2.0/conf/WCS_service-extension_transaction/2.0/conf/insert+delete.

A.2  Conformance Test Class: update

The OGC URL identifier of this conformance class is:
http://www.opengis.net/spec/WCS/2.0/conf/WCS_service-extension_transaction/2.0/conf/update.

Annex : Revision history

^[1] https://en.wikipedia.org/wiki/ACID

^[2] In the OGC, conformance to an extension requires conformance to both the core and to the conformance classes defined in the extension.

^[3] An “rX” denotes that all compatible revisions of this document can be used (e.g., GMLCOV/CIS versions 1.0 and 1.1).

^[4] Foreseeably, version 1.0 of this GMLCOV standard is going to be superseded by backwards-compatible version 1.1. This WCS Transaction Extension will fully apply to this version 1.1 as well. Note that, to avoid some common misconceptions, the name of version 1.1 will be changing from “GML 3.2.1 Application Schema – Coverages” to “Coverage Implementation Schema”.

^[5] “Native CRS” is the CRS in which the coverage is stored on the server.