[Requests] Comments on 15-044r3, OGC(R) Web Coverage Service Interface Standard -Coverage Collection Extension

Peter Baumann p.baumann at jacobs-university.de
Sat Apr 2 13:46:26 EDT 2016


All-

submitting comments on the spec.

Due to the incompleteness the RFC actually does not allow the public to assess
the specification properly, therefore I propose to complete the specification,
and then redo the RFC.

cheers,
Peter

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: p.baumann at jacobs-university.de
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: baumann at rasdaman.com
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)


-------------- next part --------------
PART A

1. Evaluator: Peter Baumann, Jacobs University

2. Submission: 15-044r3, OGC Web Coverage Service Interface Standard - Coverage Collection Extension



PART B

1. Requirement: General

2. Implementation Specification Section number: General

3. Criticality: Major

4. Comments/justifications for changes:
The RFC package does not contain the schema to which the spec refers.


PART B

1. Requirement: General

2. Implementation Specification Section number: General

3. Criticality: Major

4. Comments/justifications for changes: 
The specification overlaps with the adopted EO-WCS standard, but defines concepts in an incompatible way. This jeopardizes harmonization and interoperability. WCS Collection Extension should be phrased in a way that EO-WCS collections appear as spacial cases / extensions to it.


PART B

1. Requirement: General

2. Implementation Specification Section number: General

3. Criticality: Major

4. Comments/justifications for changes: 
WCS Collection Extension breaks the space-time axis handling of WCS-Core, effectively rendering this "extension" technically incompatible with the Core.
In WCS-Core, time axes are treated the same way as spatial axes, allowing space/time datacubes with one or more temporal axes and a unified subsetting mechanism. The way WCS Collection Extensions treats time is incompatible in both respects, effectly disallowing temporal subsetting as per WCS Core.


PART B

1. Requirement: General

2. Implementation Specification Section number: General

3. Criticality: Major

4. Comments/justifications for changes: 

WCS Collection Extension is not synchronized - rather conflicting - with CIS 1.1 which is advanced in the adoption process. As CIS 1.1 will be adopted not only by OGC, but also by ISO, WCS Collection Extension will be a singleton specification in the otherwise harmonized WCS universe.


PART B

1. Requirement: General

2. Implementation Specification Section number: General

3. Criticality: Major

4. Comments/justifications for changes:
Standardization targets KVP and POST protocol bindings are technically wrong and incompatible with the WCS standards suite at large.
On a side note, it remains unclear why SOAP, for example, is not considered.


PART B

1. Requirement: General

2. Implementation Specification Section number: General

3. Criticality: Major

4. Comments/justifications for changes:
The concept of collections is a general one (cf. feature collections in GML). One collection might even hold objects of different types, such as feature + coverage + metadata. Therefore, it is recommendeded to establish collections in OWS Common so that all services can benefit, and cross-cutting services (such as WOS) can align appropriately.


PART B

1. Requirement: General

2. Implementation Specification Section number: General

3. Criticality: Major

4. Comments/justifications for changes:
WCS Collection Extension is not generic, as coverage core and extensions are, but trimmed towards a particular application domain (supposedly, MetOcean); example: a collection bounding box is only 2D x/y while a coverage envelope is nD - therefore, an x/y/z colletion cannot be queried for height, for example. As such, it cannot be an extension, the appropriate spec level is an Application Profile, in parallel to EO-WCS.


PART B

1. Requirement: General

2. Implementation Specification Section number: 7

3. Criticality: Major

4. Comments/justifications for changes:
The WCS Collection Extension schema (i) is unnecessarily complicated (see Figure 1) which impedes adoption; (ii) is incompatible with WCS Core (ex: timePeriod, WGS84 bbox; service metadata model).


PART B

1. Requirement: General

2. Implementation Specification Section number: 8

3. Criticality: Major

4. Comments/justifications for changes:
As per 8.1, all collection-type components of all collections need to be listed in the Capabilities document - this potentially makes the Capabilities unwieldy, contrary to the purpose of shortening it.


PART B

1. Requirement: General

2. Implementation Specification Section number: General

3. Criticality: Major

4. Comments/justifications for changes:
The concept of coverage collection profiles is not clarified.


PART B

1. Requirement: General

2. Implementation Specification Section number: 8

3. Criticality: Major

4. Comments/justifications for changes:
Examples do not conform with definitions; ex: p 30, coverage id violates XML NCName definition.


PART B

1. Requirement: General

2. Implementation Specification Section number: 8

3. Criticality: Major

4. Comments/justifications for changes:
The WCS Core concept of service metadata is applied in an inapplicable position and way (ex: Table 11). Therefore, WCS Collection Extension is incompatible with WCS Core.


PART B

1. Requirement: General

2. Implementation Specification Section number: ATS

3. Criticality: Major

4. Comments/justifications for changes:
Test /no-duplicates cannot be evaluated: test will not know what the elements in a given collection are.


PART B

1. Requirement: General

2. Implementation Specification Section number: ATS

3. Criticality: Major

4. Comments/justifications for changes:
Several tests do not indicate how to test. Ex: /xml-encoding requires "Send a xml-post request to the server and pass if the server responds with a valid response" - is this only testing syntactically for a valid XML document? Or does valid mean something else?


PART B

1. Requirement: General

2. Implementation Specification Section number: ATS

3. Criticality: Major

4. Comments/justifications for changes:
Table 8 restricts the WCS Core parameter wcs:DimensioNTrim to "0..5" (!) without any explanation and rationale. As data type is indicated "trimLow trimHigh" - in WCS Core these are parameter names, it's unclear how this can be a type. Also, how one item can have 2 types.


PART B

1. Requirement: General

2. Implementation Specification Section number: General

3. Criticality: Editorial

4. Comments/justifications for changes:
The document has numerous inconsistencies in formatting, and has unmotivated empty lines, and does not keep with its own naming conventions; the latter is critical when it comes to normative text and XML code.


PART B

1. Requirement: General

2. Implementation Specification Section number: General

3. Criticality: Editorial

4. Comments/justifications for changes:
Given the numerous flaws in this specification it may not have been implemented, so there is no evidence that these concepts will work out (underlining the concerns issued earlier).


PART B

1. Requirement: General

2. Implementation Specification Section number: General

3. Criticality: Editorial

4. Comments/justifications for changes:
It is unclear whether a collection listing in the Capabilities contains only direct or also indirect subcollections. If the latter is the case this would lead to a prohibitive blow-up of the Capabilities.


PART B

1. Requirement: General

2. Implementation Specification Section number: General

3. Criticality: Editorial

4. Comments/justifications for changes:
It remains unclear whether a subcollection can be contained within more than one collection. If multiple containments are possible, are these repeated in the Capabilities document?



More information about the Requests mailing list