License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.

THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.


 

i. Abstract

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:

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.

ii.          Keywords

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

ogcdoc, OGC document, wcs, coverage, transaction

iii.          Preface

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.

iv.          Submitting organizations

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

v.          Submitters

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

Name

Affiliation

OGC Member

Peter Bauman

Jacobs University Bremen, rasdaman GmbH

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:

This is the mandatory core conformance class of this extension.

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.

Table : Namespace mappings
Prefix Namespace URL Description

xsd

http://www.w3.org/2001/XMLSchema

XML Schema namespace

gml

http://www.opengis.net/gml/3.2

GML 3.2.1

gmlcov

http://www.opengis.net/gmlcov/1.0

GML Application Schema for Coverages 1.0[4]

wcs

http://www.opengis.net/wcs/2.0

WCS 2.0 Core

wcst

http://www.opengis.net/wcs_service-extension_transaction/2.0

WCS 2.0 Transaction Extension

 

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.

InsertCoverage request UML diagram
Figure: : InsertCoverage request UML diagram

Table : Components of WCST::InsertCoverage request structure
Name Definition Data type Multiplicity

coverage

Coverage to be inserted into the WCS offering

AbstractCoverage

zero or one
(optional)

coverageRef

Reference to the coverage to be inserted into the WCS offering

anyURI

zero or one
(optional)

useId

Flag indicating that the server shall assign a newly generated coverage id.
Default if not present: use id of input coverage

string

zero or one
(optional)

isExtensible

Flag indicating that the domain set of the coverage created can be altered lateron through Update­Coverages.
Default: domain set is variable

Boolean

zero or one
(optional)

 

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.

InsertCoverage response UML diagram
Figure: : InsertCoverage response UML diagram

Table : Components of WCST::InsertCoverage response structure
Name Definition Data type Multiplicity

coverageId

Identifier of the coverage inserted into the WCS offering

string

one
(mandatory)

 

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.

DeleteCoverage request UML diagram
Figure: : DeleteCoverage request UML diagram

Table : Components of WCST::DeleteCoverage request structure
Name Definition Data type Multiplicity

coverageId

Identifiers of coverages to be deleted from the WCS offering

string

one or more
(mandatory)

 

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 id1,…,idn using the GET/KVP protocol, a coverageId parameter shall be represented by an http key/value pair as follows:
            COVERAGEID=id1,…,idn

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.

Table : Transaction extension exception codes
exceptionCode value HTTP code Meaning of exception code locator value

InvalidCoverage

404

Document uploaded is not a coverage

Position of violating element / parameter

CoverageNotFound

404

Server does not hold any coverage with the identifier provided

Identifier of the non-existing coverage

CannotStoreCoverage

500

Server cannot store coverage submitted for insertion, due to storage space or other constraints

Coverage / cov­er­age reference causing this ex­ception

CoverageTypeNotSupported

501

Server does not support the type of the coverage submitted for insertion

Coverage / cov­er­age reference caus­ing this ex­ception

 

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:

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.

UpdateCoverage request UML diagram
Figure: : UpdateCoverage request UML diagram

Table : Components of WCST::UpdateCoverage request structure
Name Definition Data type Multiplicity

coverageId

Identifier of the coverage to be updated

string

One
(mandatory)

input­Coverage

Coverage providing cell values for replacement

AbstractCoverage

Zero or one
(mandatory)

input­CoverageRef

URL to coverage providing cell values for replacement

anyURI

Zero or one
(optional)

mask

coverage indicating which cell values to update from input coverage

Abstract­Coverage

Zero or one
(optional)

maskRef

URL to coverage indicating which cell values to update from input coverage

anyURI

Zero or one
(optional)

subset

Trim or slice expression, one per updated coverage dimension

Dimension­Subset

Zero or more
(optional)

range­Component

Name of range component to be updated, and corresponding band to be used input coverage

Pair of string

Zero or more
(optional)

 

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):

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:

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:

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:

Requirement 37           

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

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

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

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=cu1:ci1,…,cun:cin
where cui and cii 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.

Table : Exception codes for UpdateCoverage
exceptionCode value HTTP code Meaning of exception code locator value

InvalidCoverage

400

Document uploaded is not a coverage

Input coverage

CoverageNotFound

404

Server does not hold coverage with identifier provided

Coverage identifier

DomainSetMismatch

404

Domain subset specified is not sa subset of server coverage’s domain set

Domain subset

NoSuchRangeComponent

404

One or more of the range components listed is not existing in input or updated coverage

First violating range component name

MaskMismatch

404

Mask domain set is not equal to input coverage domain set (i.e., mask is not aligned with input coverage)

Mask parameter

IllegalMask

400

Mask contains range values other than 0 or 1

Mask parameter

InconsistentChange

404

Update requested would make coverage inconsistent as per OGC Coverage Im­plementation Schema [OGC 09-146X]

Violating input element

NotExtensible

404

Updated coverage does not allow extension, and update area is not completely inside updated coverage domain set

none

 


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.

Requirement 1

Test Purpose:

Requirement 1

Test method:

Send valid GetCapabilities request to system under test. Check Capabilities document returned whether it contains the required element in the proper position.

Test passes if condition is fulfilled.

 

Requirement 2

Test Purpose:

Requirement 2

Test method:

Send InsertCoverage, DeleteCoverage, and UpdateCoverage requests to system under test. Verify that the structures referenced by the requirement are accepted by the server (and returned in responses, respectively), and only those. To this end, send both valid and violating requests. For the case of automatically verifiable definitions (such as XML Schema and Schematron), verify through appropriate tools. Otherwise (such as with UML), implement pertaining tests manually.

Test passes if all conditions are fulfilled.

 

Requirement 3

Test Purpose:

Requirement 3

Test method:

Send InsertCoverage requests to system under test with the following properties:

·      A valid request containing a coverage parameter. Check that a coverage has been established with the values submitted in the coverage parameter.

·      A valid request containing a coverageRef parameter referencing a valid coverage in some format supported by the system under test. Check that a coverage has been established with the values submitted in the coverageRef parameter.

·      An otherwise valid request containing neither a coverage nor a coverageRef parameter. Check that an appropriate exception is returned.

Test passes if all conditions are fulfilled.

 

Requirement 4

Test Purpose:

Requirement 4

Test method:

Send InsertCoverage requests to system under test with the following properties:

·      A valid request containing a coverage parameter with a value as required. Check that the request has been processed according to specification.

·      An otherwise valid request which contains a coverage parameter with a value violating the requirement. Check that an appropriate exception is returned.

Test passes if both conditions are fulfilled.

 

Requirement 5

Test Purpose:

Requirement 5

Test method:

Send InsertCoverage requests to system under test with the following properties:

·      A valid request containing a coverageRef parameter with a value as required. Check that the request has been processed according to specification.

·      An otherwise valid request which contains a coverageRef parameter with a value not resolving to a coverage. Check that an appropriate exception is returned.

·      An otherwise valid request which contains a coverageRef parameter with a value resolving to a coverage which violates the requirement. Check that an appropriate exception is returned.

Test passes if all conditions are fulfilled.

 

Requirement 6

Test Purpose:

Requirement 6

Test method:

Send InsertCoverage requests to system under test. Verify that the structures referenced by the requirement are accepted by the server (and returned in responses, respectively), and only those. To this end, send both valid and violating requests. For the case of automatically verifiable definitions (such as XML Schema and Schematron), verify through appropriate tools. Otherwise (such as with UML), implement pertaining tests manually.

Test passes if condition is fulfilled.

 

Requirement 7

Test Purpose:

Requirement 7

Test method:

Send InsertCoverage requests to system under test with the following properties:

·      A valid request containing no useId parameter and a coverage whose identifier is not occurring in the offering of the system under test. Check the return value to be equal to the identifier provided in the input coverage.

·      A valid request containing no useId parameter and a coverage whose identifier is occurring in the offering of the system under test. Check that an appropriate exception is returned.

·      A valid request containing a useId parameter with some random, but (as per http) syntactically admissible value. Check that the request is successful and that a coverage has been created on the system under test by issuing a GetCoverage request against the coverage identifier returned and verifying that the coverage value is identical to the one provided as input.

Test passes if all conditions are fulfilled.

 

Requirement 8

Test Purpose:

Requirement 8

Test method:

Send a valid InsertCoverage request to system under test. Verify that the request is successful. Send a valid DescribeCoverage request using the input coverage’s id to system under test and check that it is successful.

Test passes if all conditions are fulfilled.

 

Requirement 9

Test Purpose:

Requirement 9

Test method:

Send a valid InsertCoverage request to system under test. Verify that the re­quest is successful. Send a valid GetCoverage request to system under test with the identifier returned in the previous request and no further parameters beyond REQUEST, SERVICE, and VERSION. Check that the coverage returned is identical in all components to the input coverage.

Test passes if all conditions are fulfilled.

 

Requirement 10

Test Purpose:

Requirement 10

Test method:

Send DeleteCoverage requests to system under test. Verify that the structures referenced by the requirement are accepted by the server (and returned in responses, respectively), and only those. To this end, send both valid and violating requests. For the case of automatically verifiable definitions (such as XML Schema and Schematron), verify through appropriate tools. Otherwise (such as with UML), implement pertaining tests manually.

Test passes if all conditions are fulfilled.

 

Requirement 11

Test Purpose:

Requirement 11

Test method:

Send DeleteCoverage requests to system under test with the following properties:

·      One coverage identifier where no corresponding coverage exists on the server. Check that an appropriate exception is returned.

·      One coverage identifier where a corresponding coverage exists on the server. Check that the request succeeds.

·      Repeat test with different coverage id lists and false identifiers at different positions. Check that requests return an appropriate exception.

Test passes if all conditions are fulfilled.

 

Requirement 12

Test Purpose:

Requirement 12

Test method:

Send a valid DeleteCoverage request to system under test. Verify that the response is empty.

Test passes if condition is fulfilled.

 

Requirement 13

Test Purpose:

Requirement 13

Test method:

Send a InsertCoverage request to system under test with more than one coverage identifiers all existing on the server. Verify that the re­quest is successful. Check that each of the coverages whose identifiers have been submitted has been deleted from the server by sending a DescribeCoverage request.

Test passes if all conditions are fulfilled.

 

Requirement 14

Test Purpose:

Requirement 14

Test method:

This requirement is fulfilled if all previous requirements in this insert+de­lete class hold (due to the OGC / W3C Web service request definitions), hence no dedicated test is required.

 

Requirement 15

Test Purpose:

Requirement 15

Test method:

Send an invalid InsertCoverage request to system under test. Then send an invalid DeleteCoverage request to system under test, with an identifier not related to the previous insertion. For each of these coverages, send a DescribeCoverage request after completion and check that the unsuccessful InsertCoverage did not leave a new coverage, and that the unsuccessful DeleteCoverage did not remove the coverage.

Test passes if all conditions are fulfilled.

 

Requirement 16

Test Purpose:

Requirement 16

Test method:

Send a valid InsertCoverage request to system under test submitting a large coverage so that processing takes noticeable time. Within the timeframe between request submission and response, submit WCS Core requests. Verify that only the state before and after the request, but no intermediate state becomes visible through these probing requests.

Perform the same with a DeleteCoverage request containing a long list of coverage identifiers so that processing takes noticeable time.

Test passes if all conditions are fulfilled.

 

Requirement 17

Test Purpose:

Requirement 17

Test method:

Send a valid InsertCoverage request using the Get/KVP protocol to system under test. Provide a coverage parameter through COVERAGEREF following the encoding specification. Check that request was successful.

Test passes if all conditions are fulfilled.

 

Requirement 18

Test Purpose:

Requirement 18

Test method:

Send a valid InsertCoverage request using the Get/KVP protocol to system under test. Provide a useId parameter through USEID following the encoding specification. Check that request was successful.

Test passes if all conditions are fulfilled.

 

Requirement 19

Test Purpose:

Requirement 19

Test method:

Send a valid InsertCoverage request using the Get/KVP protocol to system under test. Provide an isExtensible parameter through ISEXTEN­SIB­LE following the encoding specification. Check that request was successful.

Perform the same with a DeleteCoverage request containing a long list of coverage identifiers so that processing takes noticeable time.

Test passes if all conditions are fulfilled.

 

Requirement 20

Test Purpose:

Requirement 20

Test method:

Send a valid DeleteCoverage request using the Get/KVP protocol to system under test. Provide a coverageId parameter through COVERAGEID following the encoding specification. Check that request was successful.

Test passes if all conditions are fulfilled.

 

Requirement 21

Test Purpose:

Requirement 21

Test method:

Send a valid InsertCoverage request using the XML/POST protocol to system under test with its encoding based on the wcst:InsertCoverage element following the encoding specification. Check that request was successful.

Test passes if all conditions are fulfilled.

 

Requirement 22

Test Purpose:

Requirement 22

Test method:

Send a valid DeleteCoverage request using the XML/POST protocol to system under test with its encoding based on the wcst:DeleteCoverage element following the encoding specification. Check that request was successful.

Test passes if all conditions are fulfilled.

 

Requirement 23

Test Purpose:

Requirement 23

Test method:

Send a valid InsertCoverage request using the SOAP protocol to system under test with its encoding based on the wcst:InsertCoverage element following the encoding specification. Check that request was successful.

Test passes if all conditions are fulfilled.

 

Requirement 24

Test Purpose:

Requirement 24

Test method:

Send a valid DeleteCoverage request using the SOAP protocol to system under test with its encoding based on the wcst:DeleteCoverage element following the encoding specification. Check that request was successful.

Test passes if all conditions are fulfilled.

 

Requirement 25

Test Purpose:

Requirement 25

Test method:

Send InsertCoverage and/or DeleteCoverage requests to system under test which in turn establish an error situation corresponding to each of the exceptions defined in turn. Check that the appropriate exception is returned.

Test passes if all conditions are fulfilled.

 

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.

Requirement 26

Test Purpose:

Requirement 26

Test method:

Send valid GetCapabilities request to system under test. Check Capabilities document returned whether it contains the required element in the proper position.

Test passes if condition is fulfilled.

 

Requirement 27

Test Purpose:

Requirement 27

Test method:

Send UpdateCoverage requests to system under test. Verify that the structures referenced by the requirement are accepted by the server (and returned in responses, respectively), and only those. For this case, send both valid and violating requests; in case of automatically verifiable definitions (such as XML Schema and Schematron), verify through appropriate tools. Otherwise (such as with UML), implement pertaining tests manually.

Test passes if all conditions are fulfilled.

 

Requirement 28

Test Purpose:

Requirement 28

Test method:

Send UpdateCoverage requests to system under test with the following properties:

·      A valid request containing an inputCoverageRef parameter with a value as required. Check that the request has been processed according to specification.

·      An otherwise valid request which contains an inputCoverageRef parameter with a value not resolving to a coverage. Check that an appropriate exception is returned.

·      An otherwise valid request which contains an inputCoverageRef parameter with a value resolving to a coverage which violates the requirement. Check that an appropriate exception is returned.

Repeat the same with the maskRef parameter.

Test passes if all conditions are fulfilled.

 

Requirement 29

Test Purpose:

Requirement 29

Test method:

Send UpdateCoverage requests to system under test as specified:

·      A valid request where the conditions on ci and cu hold. Check that request is successful.

·      Otherwise valid requests where the conditions on ci and cu are violated in various ways. Check that requests fail.

Test passes if all conditions are fulfilled.

 

Requirement 30

Test Purpose:

Requirement 30

Test method:

Send UpdateCoverage request to system under test as specified:

·      A valid request with the dimension constraint fulfilled. Check that request is successful.

·      An otherwise valid request where the dimension constraint is violated. Check that request fails.

Test passes if all conditions are fulfilled.

 

Requirement 31

Test Purpose:

Requirement 31

Test method:

Send UpdateCoverage request to system under test as specified:

·      A valid request with the dimension constraint fulfilled. Check that request is successful.

·      An otherwise valid request where the dimension constraint is violated. Check that request fails.

Test passes if all conditions are fulfilled.

 

Requirement 32

Test Purpose:

Requirement 32

Test method:

Send UpdateCoverage request to system under test as specified:

·      A valid request against an extensible coverage where the updated area is within the target coverage’s domain. Check that request is successful.

·      A valid request against an extensible coverage where the updated area is partially outside the target coverage’s domain. Check that request is successful.

·      A valid request against an extensible coverage where the updated area is completely outside the target coverage’s domain. Check that request is successful.

·      A valid request against a non-extensible coverage where the updated area is within the target coverage’s domain. Check that request is successful.

·      A valid request against a non-extensible coverage where the updated area is partially outside the target coverage’s domain. Check that request fails.

·      A valid request against a non-extensible coverage where the updated area is completely outside the target coverage’s domain. Check that request fails.

Test passes if all conditions are fulfilled.

 

Requirement 33

Test Purpose:

Requirement 33

Test method:

Send UpdateCoverage request to system under test as specified:

·      A valid request with the rangeComponent constraint fulfilled. Check that request is successful.

·      Otherwise valid requests where the rangeComponent constraint is violated in various ways. Check that request fails.

Test passes if all conditions are fulfilled.

 

Requirement 34

Test Purpose:

Requirement 34

Test method:

Send UpdateCoverage request to system under test as specified:

·      A valid request with the mask constraint fulfilled. Check that request is successful.

·      Otherwise valid requests where the mask constraint is violated in various places of the range set. Check that request fails.

Test passes if all conditions are fulfilled.

 

Requirement 35

Test Purpose:

Requirement 35

Test method:

Determine server support for the WCS CRS extension through a GetCapabilities request against the system under test. If it does support, test succeeds.

If it does not support the CRS extension: Send UpdateCoverage requests to system under test as specified:

·      A valid request where all CRSs occurring are identical to the Native CRS of the coverage addressed. Check that requests are successful.

·      Otherwise valid requests where each CRS in turn is set to a value different from the Native CRS of the coverage addressed. Check that appropriate exceptions are returned.

Test passes if all conditions are fulfilled.

 

Requirement 36

Test Purpose:

Requirement 36

Test method:

Send valid UpdateCoverage requests to system under test as specified, varying relevant input parameters. Check that requests are successful.

Test passes if all conditions are fulfilled.

 

Requirement 37

Test Purpose:

Requirement 37

Test method:

Send valid UpdateCoverage requests to system under test as specified, varying relevant input parameters. Check that requests are successful.

Test passes if all conditions are fulfilled.

 

Requirement 38

Test Purpose:

Requirement 38

Test method:

Send valid UpdateCoverage requests to system under test as specified, varying relevant input parameters. Check that requests are successful. Verify, through GetCoverage requests, that the updated coverages fulfil the requirement.

Test passes if all conditions are fulfilled.

 

Requirement 39

Test Purpose:

Requirement 39

Test method:

Send valid UpdateCoverage requests to system under test as specified, varying relevant input parameters. Check that requests are successful. Verify, through GetCoverage requests, that the updated coverages fulfil the requirement.

Test passes if all conditions are fulfilled.

 

Requirement 40

Test Purpose:

Requirement 40

Test method:

Send a valid UpdateCoverage request using the Get/KVP protocol to system under test. Provide a coverageId  parameter through COVERAGEID following the en­coding standard. Check that request was successful.

Test passes if all conditions are fulfilled.

 

Requirement 41

Test Purpose:

Requirement 41

Test method:

Send a valid UpdateCoverage request using the Get/KVP protocol to system under test. Provide a subset parameter through SUBSET following the en­coding standard. Check that request was successful.

Test passes if all conditions are fulfilled.

 

Requirement 42

Test Purpose:

Requirement 42

Test method:

Send a valid UpdateCoverage request using the Get/KVP protocol to system under test. Provide a rangeComponent parameter through RANGECOMPO­NENT following the encoding standard. Check that request was successful.

Test passes if all conditions are fulfilled.

 

Requirement 43

Test Purpose:

Requirement 43

Test method:

Send a valid UpdateCoverage request using the Get/KVP protocol to system under test. Provide a inputCoverageRef parameter through INPUTCOVERAGEREF following the encoding standard. Check that request was successful.

Test passes if all conditions are fulfilled.

 

Requirement 44

Test Purpose:

Requirement 44

Test method:

Send a valid UpdateCoverage request using the Get/KVP protocol to system under test. Provide a maskRef parameter through MASKREF following the encoding standard. Check that request was successful.

Test passes if all conditions are fulfilled.

 

Requirement 45

Test Purpose:

Requirement 45

Test method:

Send a valid UpdateCoverage request using the XML/POST protocol to system under test with its encoding based on the wcst:UpdateCoverage element following the encoding standard. Check that request was successful.

Test passes if all conditions are fulfilled.

 

Requirement 46

Test Purpose:

Requirement 46

Test method:

Send a valid UpdateCoverage request using the SOAP protocol to system under test with its encoding based on the wcst:UpdateCoverage element following the encoding standard. Check that request was successful.

Test passes if all conditions are fulfilled.

 

Requirement 47

Test Purpose:

Requirement 47

Test method:

Send UpdateCoverage requests to system under test which in turn establish an error situation corresponding to each of the exceptions defined in turn. Check that the appropriate exception is returned.

Test passes if all conditions are fulfilled.

 

Annex : Revision history

 

Date Release Author Paragraph modified Description

2014-07-24

2.0.0

Peter Baumann

All

Created

2014-08-19

2.0.0

Peter Baumann

All

Document completed (up to ATS)

2015-08-04

2.0.0

Peter Baumann

Annex

Added ATS

2015-10-29

2.0

C. Reed

Various

Edits in preparation for publication.

2015-12-02

2.0

Peter Baumann

Various

Finalized for publication

2016-03-25

2.0

Scott Simmons

All

Minor edits, prepared for publication

 

 



[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.