Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
EC all all ed The document uses different formatting (in particular space before/after paragraphs)
Harmonise the formatting across the document.
accepted with modifications: The intention is to have consistent formatting however extra paragraph spacing may be added to prevent orphaning or to improve readability
EC all all ed The document is using “don’t”, “doesn’t”, “isn’t” etc. in several places.
Replace with “do not”, “does not”, “is not” etc. accepted
NL Ge The document leaves (especially at the end of the document, e.g. 6.1.1.) much room for multiple interpretations of the specifics. For those implementing the WCS services and those implementing the clients using (different) services this will be a challenge. This comment is based on our experiences in getting CSW, WMS and Atom feed services running and connected with the (Dutch) INSPIRE infrastructure.
not accepted / nothing to do: Not sure how the document leaves multiple interpretations for the specifics,
There is no current solution for 6.1.1 so the reading of the document is correct in this respect.
DE (all) (all Examples)
ed Drop "&" in the last row. e.g. Example 5: http://myserver.ac.uk/some/folders/ows?service=WCS&request=GetCapabilities&
not accepted: Trailing & is conformant with KVP syntax as specified in [OWS 2]
DE Title ed Either integrate the WCS guidance into the existing TG for download services (WFS + ATOM) or rename the existing ones.
not accepted / nothing to do: The intention is to have separate documents for Atom, SOS, WFS, and WCS. The current title reflects this intention.
UK Front page
Date Ed Other documents have dates in ISO 8601 form: YYYY-MM-DD
Change “23-03-2016” to “2016-03-23”, although of course it will be a different date
accepted
EC Annex A: ATS
ge An Abstract Test Suite should be developed in order to check the testability of the requirements and allow the development of executable test suites.
Develop an ATS before final adoption of the document.
not accepted
EC Foreword Disclaimer and legal notice
ed Use the new disclaimer/legal notice proposed by DG ENV.
Disclaimer
This document has been developed collaboratively through the INSPIRE maintenance and implementation framework, involving the European Commission, European Environment Agency, EU Member States, the Accession
accepted
1 Type of comment: ge = general te = technical ed = editorial page 1 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
and EFTA Countries. The document should be regarded as presenting an informal consensus position on best practice agreed by all partners. However, the document does not necessarily represent the official, formal position of any of the partners. Hence, the views expressed in the document do not necessarily represent the views of the European Commission.
CZ Foreword Paragraph 9 ed This paragraph is incosistent with the purpose of this document.
Remove it. accepted
DE Foreword / 1.1
1st paragraph: Directive 2007/2/EC of the European Parliament and of the Council [Directive 2007/2/EC], … /Table 2: SPATIAL DATA THEMES in Annex II of [INSPIRE Directive]
ed Be consistent with other similar documents. Directive 2007/2/EC of the European Parliament and of the Council [INS DIR], … /SPATIAL DATA THEMES in Annex II of [INS DIR]
accepted
EC 1 penultimate para
ed “The scope of this document is to detail the INSPIRE technical requirements for Download Services from the Implementing Rules, such that these services can be implemented consistently across Europe.”
This sounds as if this were the only possible way to implement the IRs.
Clarify that these TG are based on WCS, and that there are other Download service TGs based on other standards, e.g.“The scope of this document is to provide Technical Guidance for the implementation of technical service interfaces for INSPIRE Download Services using WCS. Other Technical Guidance exist for describing implementations using other service interfaces such as for Atom Syndication Format, WFS,
accepted
1 Type of comment: ge = general te = technical ed = editorial page 2 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
and SOS.”
UK 1 Paragraph below bullet list
Ed The hyperlink to the directive is “correct”, in that it works, but the permanent link should be the one given on that page
Change link text & target to http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32007L0002
accepted
UK 1 Paragraph below bullet list
Ed Perhaps the text describing the Directive & what the Member States had to do should largely be in the past tense now, at least some of it.
Change “The Directive identifies what needs to be achieved, and Member States have two years … that define … will be met” to “The Directive identified what needed to be achieved, and Member States had two years … that defined … would be met”
accepted
UK 1 Ge The Introduction suggests that this is about the whole of Download Services. As it’s only about coverages, say so.
Add sentence saying that the scope of this TG is the download of coverage data
accepted
DE 1.1 4th paragraph: This technical guidance shows how the operations required by the INS NS ...last paragraph: The Spatial Object Types defined in INS ISSDS that ...
ed Put all references in square brackets. This technical guidance shows how the operations required by the [INS NS] ...The Spatial Object Types defined in [INS ISSDS] that ...
accepted
DE 1 (actually 1.1.)
Paragraph 4, last sentence
ge „INSPIRE conformant WCS“ - such a service does not exists
Please use s.th. like „INSPIRE conformant Download Service based on WCS“
accepted
DE 1 (actually 1.1.)
Table 2 and Table 3
ed Please mark those themes for which no other modelling option than coverages are possible.
accepted
EC 1.1 Table 3 ge The list of spatial object types using coverages is more relevant to the 2nd deliverable of the
Remove table 3 and include it in the 2nd deliverable of the MIWP-7b sub-group.
not accepted: It might be found to be subsequently correct that the table is more
1 Type of comment: ge = general te = technical ed = editorial page 3 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
MIWP-7b sub-group. To illustrate the relevance of this TG to the different INSPIRE themes, the list of themes included in the text is sufficient.
relevant elsewhere, but it doesn’t follow that it isn’t relevant in its current location.
UK 1.1 3 ge To help service providers decide whether to implement download services via WCS, it would be helpful to add more information in this section on the benefits and constraints vis-a-vis WFS/ATOM particularly in relation to quality of service criteria. We are concerned about possible performance and capacity issues.
not accepted: It isn’t the purpose of the WCS document to list benefits vs constraints of using WCS vs other download services. The general guidance document for all download services could do this though.
EC 1.2 grey text ed The grey background illustrates in the DS documents that this is boilerplate text from the DS template. This is not required here.
Remove the grey background. accepted
FR 1.2 Figure 3 Editorial I am afraid mentioning the context of ‘timeries’ in the WCS document might confuse end users with the SOS guidance.This was a subject already discussed when drafting D2.9 back in time. Conceptually WaterML2 Part:1 Timeseries (and now TimeseriesML) are realisation of CV_DiscreteCoverage and this might be discussed whether they could be made available via WCS.But I think these discussions are more of a ‘research’ topic and that these TG guidance docs target direct operation by MemberStates. I’d rather stick with the current community agreement to use SOS for timeseries exchange.
Remove reference to Timeseries “WaterML 2.0: Part 1” and Figure 3
discuss: The whole section currently in grey is boilerplate text used verbatim, however it might not be entirely correct in this context, so we might decide to cut it out or modify it.
Has the discussion mentioned taken place with regards WaterML?
DE 1.2 p. 14, 4th paragraph: In addition, some themes make reference to the types
te This is confusing, as coverages as well may contain time axes and (unfortunately) WaterML is not harmonized in any way with GMLCOV/CIS.
discuss: It appears that WaterML reference should be cut…
1 Type of comment: ge = general te = technical ed = editorial page 4 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
TimeValuePair and Timeseries defined in Taylor, Peter (ed.), OGC® WaterML 2.0: Part 1 – Time series, v2.0.0, Open Geospatial Consortium, 2012. These provide a representation of the time instant/value pairs, i.e. time series (see Figure 3).
DE 1.2 p. 14, last paragraph: ... these coverage types...
te What does “these” refer to? WaterML != OGC coverages.
discuss: Part of the ongoing WaterML discussion. Not sure I understand the WaterML != OGC comment though WaterML is an OGC standard.
DE 1.2 3rd paragraph: … is included in the Generic Conceptual Model in 9.9.4
ed Use the correct name and add the reference. is included in the INSPIRE Generic Conceptual Model in 9.9.[INS GCM]
accepted
DE 1.2 p.14, 1st paragraph: Coverage functions are used...
ed Maybe the mentioning of "functions" is confusing for the general audience.
Check wording. discuss: The whole section currently in grey is boilerplate text used verbatim, however it might not be entirely correct in this context, so we might decide to cut it out or modify it.
DE 1.2 p. 14, 2nd paragraph: ...
ed Not sure people will understand this Check wording. discuss: The whole section currently in grey
1 Type of comment: ge = general te = technical ed = editorial page 5 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
properties of spatial object types where the type of the property value is a realisation of one of the types...
is boilerplate text used verbatim, however it might not be entirely correct in this context, so we might decide to cut it out or modify it.
DE 1.2 p. 14, 3rd paragraph, 1st bullet point: ... a grid for which there is an affine transformation between the grif coordinates and the coordinates of a coordinate reference system (see figure 2, left).
te This is high-level and abstract. Add a stanza like "constant spacing along the axes".
discuss: The whole section currently in grey is boilerplate text used verbatim, however it might not be entirely correct in this context, so we might decide to cut it out or modify it.
Though agree that such a stanza would add useful information
DE 1.2 p. 14, 2nd paragraph: ... ISO 19123
te The 19123 coverage model is abstract, and, therefore, allows many non-interoperable concretizations.
Better refer to GMLCOV/CIS which is based on 19123 (too) and concise enough to be interoperable.
discuss: The whole section currently in grey is boilerplate text used verbatim, however it might not be entirely correct in this context, so we might decide to cut it out or modify it.
DE 1.2 p. 14, 3rd paragraph, 2nd bullet point: a grid associated with a transformation that can be used to
ed Maybe mention the grid is irregularly spaced? discuss: The whole section currently in grey is boilerplate text used verbatim, however it might not be entirely correct in this context, so we might decide to cut it out or modify it.
Though agree that such a comment would add useful information
1 Type of comment: ge = general te = technical ed = editorial page 6 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
convert grid coordinate values to values of coordinates referenced to a coordinate reference system (see Figure 2, right).
DE 1.2 p. 14, last paragraph: Where possible, ...
This seems like a conclusion. Shift it after the GMLCOV/CIS discussion below.
accepted
DE 1.2 p. 15, last paragraph: ... extension to GML 3.2.1...
ed Suggest, for clarification, “extension to the conceptual model of GML 3.2.1 which can be mapped to GML or any other suitable format”.
accepted
DE 1.2 p. 16, paragraph below figure 4: ... GML coverage...
te Can be any suitable format. Drop “GML”. accepted
EC 1.2 Text on GML coverage schema and Figure 4
ge This text and figure seem to be more relevant to the 2nd deliverable of the MIWP-7b sub-group.
Consider removing the text section and figure from this TG.
not accepted Not sure why it is regarded as more relevant to the second deliverable. It is relevant in this document so we should keep it.
CZ 1.2 and 2 ge OGC 09-146r1 document (OGC GML Application Schema - Coverages) is used for coverage definition in chapter 1.2, but in references there is listed OGC 09-146r2 (new version of the abovementioned document).
Change the references in section 1.2 to OGC 09-146r2 document or add OGC 09-146r1 document to Normative references section.
accepted
EC 2 ed The following citations do not have short names to be used for references in the text: OGC 06-121r9, OGC Web Services
Common Standard, version 2.0 OGC 09-149r1, OGC Web Coverage
Service 2.0 Interface Standard –
Add short names (and use them for references in the text).
accepted
1 Type of comment: ge = general te = technical ed = editorial page 7 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
XML/SOAP Protocol Binding Extension, version 1.0
OGC 09-147r3, WCS 2.0 Interface Standard – KVP Protocol Binding Extension, version 1.0
OGC 09-146r2, GML 3.2.1 Application Schema – Coverages
OGC 12-100r1, GML Application Schema - Coverages - GeoTIFF Coverage Encoding Profile
OGC 08-059r4, OGC Web Coverage Service WCS Interface Standard - Processing Extension, version 2.0
DE 2 INSPIRE, Implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial datasets and services, INSPIRE Directive
ed Work uniform with other similar documents (see e.g. Draft “Technical Guidance for INSPIRE Spatial Data Services and services allowing spatial data services to be invoked”).
INS DIR INSPIRE, Implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial datasets and services
accepted
DE 2 (all) ed Add missing references. Add e.g. INS GCM, OGC 09-146r1, OGC WCS, ISO 19101 etc.
accepted
DE 2 List of references
ed Please use another header for the list of OGC specs and INSPIRE CRS than „normative“ references. Normative are only those, which implements legal bindings (Directive, Regulations, Implementing Rules, Decisions). The other things like Technical Guidance and Guidelines concerns only technical things.
accepted: renamed section to References with sub headings for Normative and technical
NL 3.1 Page 20 te Relation between spatial dataset and spatial not accepted: Definitions of these terms is
1 Type of comment: ge = general te = technical ed = editorial page 8 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
object is not clear. If a spatial object is part of a spatial dataset should it cover the spatial object entirely? What is the difference with Coverage?
included in section 3.
UK 3.1 (5) Ed Each term should appear in its singular form Replace ‘systems’ with ‘system’ in both the bold term & the first word of the definition
accepted
UK 3.1 (9) Ed Each term should appear in its singular form Replace “services” with “service” in term accepted
UK 3.1 (9) Ed Definition incomplete: nothing defines what it actually is
Insert “network service” before the word “enabling” (make the words “network service” bold, as they will refer to (16))
accepted with modifications: added with ellipsis to show that whilst the directive infers network service here, it isn’t a direct quote.
UK 3.1 (10) Ed Each term should appear in its singular form Replace “features” with “feature” in term accepted with modifications: Changing features to feature (OK) but this also requires changing phenomena (plural) to phenomenon (singular)
UK 3.1 (12) Ed Each term should appear in its singular form Replace “systems” with “system” in term (OK in the note)
accepted
UK 3.1 (16) Ed Each term should appear in its singular form Replace “services” with “service” in term accepted
UK 3.1 (18) Ed Definition incorrect, at least with respect to ISO 19135:2015
Replace “database” with “set of files” accepted
UK 3.1 (20) NOTE Ed Using dashes to “call out” a word that is to be discussed is rather confusing, especially given software’s tendency to vary the length of each dash automatically. Use single or double quotation marks instead. There is also one dash in use a piece of punctuation – which is OK, but not in this mix!(Note: in the cell to the left, there are several lengths of dash – I can hardly control that; I hope you can find the text I’m referring to!)
Replace “-spatial” with “’spatial’”Replace “-geographic-“ with “’geographic’”Consider replacing “which … scope – and includes” with “, which … scope, to include”Replace “term -spatial data” with “term ‘spatial data’”Replace “term –geographic data” with “term ‘geographic data’”Replace “as –data …Earth” with “as ‘data … Earth’“
accepted
UK 3.1 (21) Ed Each term should appear in its singular form Replace “services” with “service” in term accepted
UK 3.1 (23) NOTE Ed Using dashes to “call out” a word that is to be discussed is rather confusing, especially given software’s tendency to vary the length of each
Replace “term –(geographic) as feature” with “term ‘(geographic) feature’ as”
accepted
1 Type of comment: ge = general te = technical ed = editorial page 9 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
dash automatically. Use single or double quotation marks instead.(Note: in the cell to the left, there are several lengths of dash – I can hardly control that; I hope you can find the text I’m referring to!)
DE 3.1 (1) … conceptual schema for data required by one or more applications [ISO 19101] etc.
ed Write all references in bold. conceptual schema for data required by one or more applications [ISO 19101]
accepted
DE 3.1 (12) NOTE 2: The INSPIRE generic concept model document …(23) NOTE: … and in the INSPIRE Generic Conceptual model document is used synonymously with spatial object. [Note modified from INSPIRE Generic Conceptual model]
ed Use the correct name. The INSPIRE Generic Conceptual Model document …
… and in the INSPIRE Generic Conceptual Model document is used synonymously with spatial object. [Note modified from INSPIRE Generic Conceptual Model]
accepted
DE 3.1 (5) coordinate reference
ed Systems for uniquely referencing spatial and/or temporal information in space as a set of coordinates (x, y, z, t) and/or
not accepted: The INSPIRE directive does not mention temporal when discussing CRS.
1 Type of comment: ge = general te = technical ed = editorial page 10 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
systemsSystems for uniquely referencing spatial information in space as a set of coordinates (x, y, z) and/or latitude and longitude and height, based on a geodetic horizontal and vertical datum [INSPIRE Directive]
latitude and longitude and height, based on a geodetic horizontal and vertical datum [INSPIRE Directive]
DE 3.1 (6) coveragespatial object that acts as a function to return values from its range for any direct position within its spatial, temporal or spatiotemporal domain, in accordance with ISO 19123:2007 [INS ISDSS]EXAMPLE Orthoimage, digital elevation model (as
ed (1) coveragespatial object that acts as a function to return values from its range for any direct position within its spatial, temporal or spatiotemporal domain, in accordance with ISO 19123:2007 [INS ISDSS]EXAMPLE Orthoimage, Image timeseries, digital elevation model (as grid or TIN), point grids etc.
accepted
1 Type of comment: ge = general te = technical ed = editorial page 11 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
grid or TIN), point grids etc.
DE 3.1 (12) geographical grid systemsNOTE 2 ... Thus, a 'geographical grid' is equivalent to an ISO 19123 coverage. ...
ed Gridded coverage? discuss: What is the proposed change or problem that needs addressing?
DE 3.1 (12) geographical grid systemsNOTE 2 ... The unqualified term 'grid' may refer either to a grid geometry or a geographical grid (coverage) depending on the context.
ed For the reader’s understanding, what is the difference?
Add clarification for the difference between grid geometry and geographical grid (coverage).
accepted: clarification note should be added
DE 3.1 (13) GML coverage
ed Should not contain “GML”, this has led to sustained confusion.
Drop "GML". Not accepted: The term is valid.
But could add a note to for clarification of GML issues.
DE 3.1 (13) GML coverage... subclass (specializatio
te Not sure I can follow this, and hard to understand anyway. The term suggests a simple interpretation, which is consistent with OGC: a coverage encoded in GML. As such, I
Drop term (13). Not accepted: The term GML coverage is used in the body of the text
1 Type of comment: ge = general te = technical ed = editorial page 12 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
n) of a Coverage ...
am not sure it is needed as a specific term, unless we define GeoTIFF coverages, NetCDF coverages, and the like as well.
DE 3.1 (17) range (of a coverage)... feature attribute...
ed Suggest to drop these words – it is not clear what they mean, and they are not necessary either.
Drop "feature attribute". Not accepted: The term feature attribute is used in the terms list to define other terms.
DE 3.1 (20) spatial data, NOTE
te Very much agreed with the NOTE. Does it include temporal?
accepted: Will add to the note that temporal is included in this document with respect to spatial data
DE 3.1 (21) spatial data servicesoperations...
te Service offers a set of operations, but is not an operation. Example: a WFS instance is not an operation.
Check wording. not accepted: This is the wording of the directive
DE 3.4 2nd paragraph: For example, [INS NS]uses the abbreviated title for the document as shown below:INSPIRE Network Services Regulation, INS NS, COMMISSION REGULATION (EU) No 1088/2010 of 23 November 2010 amending Regulation (EC) No
ed Be consistent with other similar documents (e.g. Draft “Technical Guidance for INSPIRE Spatial Data Services and services allowing spatial data services to be invoked”)
For example, [INS NS] uses the abbreviated title for the document as shown below:COMMISSION REGULATION (EU) No 1088/2010 of 23 November 2010 amending Regulation (EC) No 976/2009 as regards download services and transformation services
not accepted: square brackets are used in the document when citing references, but in the references themselves the abbreviation is only shown in bold. This section (3.4 References) gives an example of a reference,
1 Type of comment: ge = general te = technical ed = editorial page 13 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
976/2009 as regards download services and transformation services
DE 3.5 p. 23, 2nd paragraph, 1st bullet point: Updates to the Coverage Data Model (GML 3.2.1 Application Schema - Coverages version 1.0.1, OGC 09-146r2, becomes Coverage Implementation Schema 1.1).
ed Replace "becomes" with "is advanced to" or similar expression.
Updates to the Coverage Data Model (GML 3.2.1 Application Schema - Coverages version 1.0.1, OGC 09-146r2, is advanced to Coverage Implementation Schema 1.1)
accepted
DE 3.5 p. 23, 2nd paragraph, last bullet point:SelectCapabilities extension to WCS core, being adopted
ge Not sure about this, there are numerous reservations on this spec. Maybe we should not anticipate anything in this (normative) document.
accepted: Removed mention of SelectCapabilities
NL 4 Page 24 te References to table: direct access download and other download not clear.
accepted: Changed ‘table below’ to
NL 4 Page 24 Ge How will clients using download services deal with the different download services provided?
not accepted: It is not in scope of this TG to discuss how clients will handle any download
NL 4 Page 24 & te Which of the two types is “Direct access”? not accepted: The table already identifies
1 Type of comment: ge = general te = technical ed = editorial page 14 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
Table 4 the Direct Access download service operations.
EC 4 p. 24 ed What does “M1” in “[INS NS] (M1)” stand for? Explain. accepted: changed to [INS NS (Amendment M1)]
EC 4 p. 24 / Table 4
ed Implementers that already know the other Download service TGs may benefit from a note on “pre-defined dataset download services”
Add a note saying that download services implementing only the mandatory operations (“Other download services” in Table 4) are called “pre-defined dataset download services” in the other Download service TGs.
not accepted: It’s not in scope of this WCS document to discuss how TG’s for download services based on other interface standards classify the operations. Additionally, in the scope of creating this TG for WCS, the predefined vs direct access classification of operations was considered and rejected as not being useful. Making a note that other TGs use the term predefined for some operations may lead to confusion.
EC 4 Table 4 ed “Open request (query) parameters” is in the wrong table cell
Move into “Get Spatial Object” column accepted
DE 4 Table 4 te Text „Open request (query) parameters” in column 6
Move to column 5 accepted
FR 4 Table 4 ed Open request should be in column 5: GetSpatialObject
Move from column 6 to 5 accepted
EC 4 Table 4 te I think table 4 is overly complicated. I think it would be enough to illustrate that all download services need to support the first 4 operations, and that Direct Access Download Services need to also support operations 5+6.
Simplify the table accordingly. accepted
DE 4 p. 25, Table 4, row 1 and 2
ed Not sure about meaning of this row 2: another service? Detailing of row 1 = headline?
Check and clarify. accepted: Table headings will be clarified
DE 4 p. 25, Table 4, last row: "NOT ABLE TO SUPPORT"
te Based on the explanation below, maybe it is better understandable to leave out this “NOT ABLE” and just state “By definition, if a service ….”
Drop "NOT ABLE TO SUPPORT". not accepted: It is useful to show that these operations are not supported. The footnote was added to show that this is a not possible vs a can’t (not permitted)
NL 4 Figure 5 ed Swap coverage/WCS with polygon/WFS to align with the Spatial objects figures on the right.
accepted
EC 4 Figure 5 te Figure 5 is helpful, but not correct or over- Discuss revision of the figure with JRC. Action JRC1 Type of comment: ge = general te = technical ed = editorial
page 15 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
simplified in some aspects.The intention of the figure is to be a simple representation.If the figure is incorrect, please provide or suggest corrections.
DE 4 p. 26, figure 5: Each file has it's own spatial data set identifier; Each coverage has it's own spatial data set identifier
ed Replace "it's" with "its". Each file has its own spatial data set identifier; Each coverage has its own spatial data set identifier
accepted
UK 4 First Ed Singular/plural mismatch Change “Other Technical Guidance exist” to “Other Technical Guidance exists”
accepted
DE 4 p. 24, 1st paragraph
ed Replace "exist" with "exists" Other Technical Guidance exists for describing implementations using other service interfaces such as for Atom Syndication Format, WFS, and SOS.
accepted
and add a sentence to clarify the need of a WCS guidance.
However, only WCS allows extraction and processing of coverage subsets. This WCS guidance is based on the abstract model established in the INSPIRE Network Services Regulation [INS NS].
discuss: Do we need to add such a sentence here?
UK 4 Just above second bullet list
Ed Double space and missing coma Change “provided the” to “provided, the” accepted
UK 4 Third below the diagram
Ed Extra space before full stop. Change “datasets .” to “datasets.” accepted
DE 4 Paragraph 1 ge The referenced TG for SOS is not published yet.
Mark this TG as unpublished. accepted
DE 4 p. 25, paragraph
te Maybe the differentiating criterion is not “file vs database” – a file can just as well be updated
Leave out file/database exemplification. accepted with modifications: A database is a set of files, though most people don’t
1 Type of comment: ge = general te = technical ed = editorial page 16 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
below table 4: ...Conversely, when a service has access to a live database (for example one in which coverage data is being continuously updated), ...
regularly. think of it this way. The intention was to comment on static content vs dynamic content. Will amend the text to make it more obvious that this static vs dynamic comparison is intended.
DE 4 Paragraph below Table 4, third sentence
ed Typo in „when you provision“. Replace “provision” with „provide“. not accepted: provision is intended
DE 4 p. 26, paragraph below figure 5: ...a coverage can be mapped to the term spatial object.
ed A very abstract view – maybe innocent readers understand this wrong.
Check and clarify. not accepted: The text fits with the simplified view of the figure.
DE 4 Third paragraph, below Figure 5 – second point
ge The term „conditional“ is somewhat misleading. This operations are mandatory if the provider will give access through a direct access service!
Check and clarify. accepted
UK 4.1.1.1 Table 5 Get Download Services Metadata Request
Te Get Download Services Metadata Request: what URL is expected in the metadata record? Some people expect ‘the end point’, with the OGC standard part appended by the client & others expect/provide the full GetCapabilities request to be in the record.It may be helpful to provide this detail, although arguable, it should be in the Metadata TG, and consistent across all the network services.
Turn into an atomic requirement not accepted table 5 already tells us that:The Resource Locator metadata element for the Download Service shall contain a link to the service endpoint
1 Type of comment: ge = general te = technical ed = editorial page 17 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
Language: “The … request is a …” – surely this is a TG Requirement: “The …. request shall be a…”
accepted
UK 4.1.1.1 Table 5 Get Download Services Metadata Response
Te The text implies that the same two scenarios that are in the other network services TGs apply. Is this explicit further on in the document? Perhaps it could be more explicit here.
Turn into an atomic requirement, which may then have two scenarios for conforming to that requirement – or are there two conformance class for this?
not accepted: There is no implication that the two methods of obtaining metadata are in other network service TG’s.
Language: “The … response will be”; surely this is a TG Requirement “The … response shall be”
accepted
DE 4.1.1.1 Table 5, first row, Response, point 5: „which must include at least one required CRS“
ge Is this really mandated by the directive? In case that data is provided as managed by the provider, without the possibility to fulfil the INSPIRE data model, then the data can be distributed unaltered. No transformation of CRS should be required.
Check and clarify. not accepted: The directive does indeed state that each dataset will supply a list of supported CRS; though this can be just one CRS. Also, as is discussed elsewhere in the document, there is no requirement for any download service to offer any (including CRS) transformation.
DE 4.1.1.1 Table 5, „Get Spatial Data Set“
ge Spatial Data Set Identifier is defined to be a request parameter. How can this be done with a GetCoverage request? In this request the coverage identifier is normally used. The Spatial Data Set Identifier came from the dataset metadata and may be given in the WCS capabilities, but is not a request parameter for the GetCoverage request.
not accepted: The coverage identifier is the Spatial Data Set Identifier. There’s no reason why an identifier in a service metadata record can’t be a coverage identifier.
DE 4.1.1.1 Table 5, „Get Download Service Metadata Response“:„will be a
ge Spatial dataset metadata cannot be included in the capabilities document. It is always referenced via xlink:href elements in MetadataURL tags!
Check and clarify. not accepted: The GetCapabilities response is itself a metadata response..
1 Type of comment: ge = general te = technical ed = editorial page 18 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
WCS Capabilities document, which includes“ ...“the spatial datasets metadata“
UK 4.1.1.1 Table 6: Get Spatial Data Set Request
Te Surely this is a TG requirement – the service shall respond to ..
Change “can be requested” to “shall be requested”
accepted
UK 4.1.1.1 Table 7 Describe Spatial Data Set request
Te Surely this is a TG requirement – the service shall respond to ..
Change “can be described” to “shall be described”
accepted
DE 4.1.1.2 Title: „Conditional download options“
ge Don't use the term conditional. Maybe „optional“ is better, cause there is no legal demand for providing direct access download services!
Change title. not accepted: the term conditional is used correctly here
DE 4.1.1.2 Table 9 te The DescribeCoverage request of a WCS delivers already a description of the „spatial object“, which is in the case of a coverage the coverage itself.
The Recommended WCS-based implementation should be the same as in Table 7.
discuss: Can a WCS DescribeCoverage operation satisfy all the requirements for a Describe Spatial Object Type operation?We have been saying that it can’t because it can’t supply the ‘Spatial Object Type’ as part of the request. It might be correct that the results of a WCS DescribeCoverage operation can or could provide data that is equivalent to the results of such a Describe Spatial Object Type operation for a coverage, but is this good enough? What about the requirement that if no spatial object type is provided, the response should include all Spatial Object Types available in the service?Leaning here to a not accepted…
UK 4.1.1.2 Table 9 Te There appear to be two options described here. I think the recommended implementation would be clearer with a more explicit last sentence specific reference to requirements in
Replace last sentence with something like:This operation can be implemented in either of two ways:
discuss: Assuming that we don’t reverse the decision that there are no WCS operations that can map to the Describe Spatial Object Type, should we be more
1 Type of comment: ge = general te = technical ed = editorial page 19 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
TG Discovery Service. If there really is an option using the GetCapabilities response, then that needs further description.Note: I think the relevant part of the Metadata would be Content Information, which is only specified for the Buildings theme.I’m not sure that the idea to the right really works
- By a Discover Metadata request to the Discovery Service
- By searching the Get Download Services Metadata response.
The first case depends on the service metadata record containing a list of spatial object types, which may be in (or referenced from) the Content Information section.The second case depends on the response including Layers metadata (?)
proactive in putting forward a recommended solution?
DE 4.1.1.2 Table 10 te The requirement to implement the WCS processing extension to realize a direct access download service forms a big obstacle for many service providers. All of the requirements for a direct access service from IR NS can be provided by the GetCoverage operation: e.g. domain subsetting, bounding box, slicing etc. What more query functionality would be needed? And coordinate transformation is not a requirement for INSPIRE download services. If there is really more functionality needed than WCS 2.0 core delivers, it would be better to split the requirements in a part, where WCS 2.0 core is sufficient, and another part, where the WCS processing extension is needed.
Check carefully, if the WCS processing extension must be mandatory to implement a direct access service. If not, define the GetSpatioObject Operation by the use of the GetCoverage function.
not accepted: The Get Spatial Object operation requires a request to construct a query. It is not possible to construct the required query in a GetCoverage request. The WCS processing extension allows the construction of such a query.It might be correct that to realize an INSPIRE direct access download service using WCS will be a big hurdle for many service operators, but this shouldn’t in itself be a big problem. All the mandatory operations for a WCS download service are covered by core WCS operations, so there’s no requirement to have a Direct Access service
UK 4.1.2 Note Ge This note is true & very useful, but I assume that you do not intend to disallow the use of IETF URIs within the ‘code’?
Assuming they are not disallowed, extend the note to say “although an IETF URI may be used as INSPIRE unique resource identifier, in which case it is placed in the ‘code’ field”
accepted
EC 4.2 Conformance classes
te The other download service TGs also use numbers for conformance classes. This may be confusing.
Remove numbers from conformance class names and make names unique (i.e. include a reference to WCS).
not accepted: The section explicitly mentions ‘this document’.
EC 4.2 2 paras under the table
te The specification of conformance classes should not be described in this TG, but rather in the TG for MD (and it should use the same approach for all TGs using conformance classes).
Remove the 2 paragraphs discussing the declaration of conformance with a conformance class.
not accepted: These paragraphs are acceptable in the current TG for download service, so should be acceptable here too.
DE 4.2 Table 12, ge Definition is incomplete. C, shall be M if the download service provides accepted1 Type of comment: ge = general te = technical ed = editorial
page 20 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
point 2 – Direct Access Download Options
direct access to spatial data sets
NL 4.3.1. Page 32 te Do not understand how an Accept-Language enviroment variable and header will work. The environment variable is specified by the server and cannot be changed by the client…..
not accepted / nothing to do: This is no different from a client requesting a language in the body of an HTTP request. The client requests versions/languages/content type, the server provides what it is best able to supply based on the request.
UK 4.3.1 Ge These HTTP language negotiations would form a useful part of the other network service TGs as well.
not accepted / nothing to do: agreed that it would be useful, however it is mentioned here specifically because it is part of the [OWS 2] specification used by WCS 2. Other service interface standards (such as WFS) do not reference [OWS 2], and there could be no expectation that any WFS software would support such negotiation.
DE 4.3.1 p. 32, example 2
ge Should this document maybe support best practice and adhere to the conventions of upper case for the parameter names? I know, some implementations are lax, but IMHO being a standard it should stick with the regulations.
not accepted: Syntax is correct according to https://tools.ietf.org/html/rfc7231
NL 4.4 Page 34 te Note: The Lambert Azimuthal Equal Area is perfectly applicable to coverages. Data can also be offered by a data provider in this projection
not accepted / nothing to do: Agreed Lambert Equal Area is perfectly acceptable, and is listed as such already in table 13.
EC 4.4 ed The section does not actually contain any requirements on CRS. Therefore the title is misleading.
Change the title or remove the section (see below), moving some of the content into relevant other sections.
not accepted: The section does contain reference to the requirements (it used to list the requirements directly but this was changed to the referencing of the requirements in a recent edit). There should be some reference to CRS requirements in the document I think.
EC 4.4 te The recommendation to use the EPSG/OGC http URIs recommended for CRS in the DS TG
Consider removing the section and moving some of the content into section 5.1.3.
not accepted: CRS applies to operations other than the Get Spatial Data operation
1 Type of comment: ge = general te = technical ed = editorial page 21 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
could be included in section 5.1.3, where the CRS query parameter is discussed.The table seems unnecessary. Other CRSs could be used too.
Replace the table by one or two examples and a reference to the DS TG.
(section 5.13) so moving it there doesn’t make sense.
DE 4.4 Table 13 ge The Table may be omitted and as an alternative a list of CRS should be referenced
not accepted: Unclear on the difference between a table of CRS and a list of CRS
FR 5.1 TG Recommendation 4
te This recommendation let us think that the WCS 2.0 ISO version will only support POST/XML and not Get/KVP.
This recommendation would have to be aligned once ISO work will be done.
discuss: As I understand it the recommendation to ISO is to adopt the POST/XML protocol binding, so a recommendation to support this is very likely to ensure compliance. It is unlikely that ISO will reject the recommendation though it may also opt to support KVP. Should this recommendation stand or should the recommendation change to include support for KVP, or should we just delete the recommendation?
DE 5.1 TG Recommendation 4
ge The service should support both KVP and XML/SOAP. Maybe we should recommend POST.
discuss: (same issue as above)
DE 5.1 p. 36, paragraph above TG Requirement 2: ... you should note that it is the XML/SOAP binding that is proposed for the ISO coverage service implementation.
te Caveat: only informal discussion currently, no concrete ISO opinion stated.
Check and rephrase, if applicable. discuss: (same issue as above)
EC 5.1 TG req 1 (and other requirements and
te The standardisation target is not entirely clear - “the implementation: could mean a software product, a service instance, … The target should be a download service instance.
Reword all requirements/recommendations to “The download service instance shall/should …”
accepted
1 Type of comment: ge = general te = technical ed = editorial page 22 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
recommendations)
EC 5.1 Introduction ed Should “Note that the OGC WCS 2.0 Core specification in turn conforms to the following classes” read “Note that the OGC WCS 2.0 Core specification in turn requires conformance to the following classes”?
Rephrase. accepted
CZ 5.1 Table 13 (Table 14 intended)
te Missing jpeg2000 output format, that is recommended e. g. in Data Specification on Orthoimagery.
Add this output format to the table. accepted
UK 5.1 Table 14 Te The EL data spec calls for GeoTiff, Tiff or JPEG 2000 for the range set, whereas this table could be read to suggest PNG or ASCII GRID for EL gridded data.We’d prefer ASCII GRID, but it was removed from EL late in development for some reason.
Resolve with DS EL – will they allow e.g. ASCII GRID?Add whatever EL will allow to this table.
accepted
EC 5.1 Discussion of output formats
te This text and table seem to be more relevant to the 2nd deliverable of the MIWP-7b sub-group.
Consider removing the text section and figure from this TG.
not accepted: Table seems relevant here and others (above) have asked for it to be extended
DE 5.1 p. 37, Table 14
ge Based on the points made in the table, why not establish a recommendation for say JSON for 1D; TIFF for 2D; NetCDF for 3D, 4D? Or maybe tie format recommendations to the Annex themes?As it stands, clients might have a hard time confronted with the myriads of format choices.
not accepted: It’s not in scope in this document to give recommendations of formats. The intention here is show possibilities; to show it isn’t all about GML.
DE 5.1 p. 35: OGC 09-146r2, OGC® GML Application Schema for Coverages, version 1.0
ge For all standards referenced, suggest to use just major version number. Reasons:By definition, all 1.x are compatible, therefore anything that works with 1. should also work with 1.1. Confining this would introduce artificial constraintsLater changes, say from 1.0 to 1.1 will require major work, such as edits + new version
Use just major version number for all standards referenced.
discuss: The text originally had 2.x, then was changed to 2 only, then on request from JRC back to 2.x, should it go to 2 again? Obviously there is an argument that 2 would be better because it would limit the requirement for changes when version 2.1 comes out. However there are issues with the conformance classes I think If we say that. So we will need to wait till 2.1 becomes available and then create an updated version. In any case it should be remembered that this TG isn’t a standard or
1 Type of comment: ge = general te = technical ed = editorial page 23 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
a legal requirement, it’s just a document that tells a service provider how they might create an INSPIRE download service using WCS 2.0. It doesn’t in any way preclude the configuring of a WCS 2.1 service in the future.
Leaning to no accepted…
DE 5.1 p. 35: OGC 09-146r2, OGC® GML Application Schema for Coverages, version 1.0Conformance classes used:gml-coverage
te This seems to express that only GML encodings are wanted.
Add further classes, such as other-format (allowing binary formats like GeoTIFF) and multipart (GML header + binary format).
not accepted: The conformance classes listed are those listed in WCS 2.0 core as being required. Adding further classes not specified as being required by WCS 2.0 core would be misleading I think.
DE 5.1 p. 35, TG Requirement 1: Implementations shall conform to OGC 09-110r4 Conformance Class ‘core WCS’
ge Recommend to not use concrete document numbers, better reference the version desired (reasons, see above).
Reference the version desired. accepted
DE 5.1 p. 35, paragraph below TG Requirement 1
ed Rephrase paragraph. The WCS core specification specifies the core operations required to be implemented by any WCS, remaining agnostic of the request encoding; protocol bindings areWCS extensions. This way, functionality and encoding are separated.
accepted with modifications: Will change the text to include something about functionality separated from encoding, but not verbatim text suggested here.
DE 5.1 p. 35, 2nd paragraph below TG
te Three bindings, actually: GET, POST, SOAP. REST is under preparation.BTW, you list only one.
Replace "Two" with "Three" and add missing bindings in the list.
not accepted: Two protocol bindings are referencedXML/SOAP protocol binding extension and
1 Type of comment: ge = general te = technical ed = editorial page 24 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
Requirement 1:Two protocol bindings are currently supported by WCS 2.0:
KVP Protocol Binding extension
REST is not mentioned as a protocol because REST is not a protocol (it is protocol agnostic).
DE 5.1 p. 35, 3rd paragraph below TG Requirement 1: Note that the XML/SOAP Protocol Binding Extension specification in addition to conforming to WCS core also conforms to the following classes:
te Do the others not conform to OWS Common 2.0? Is there any source for this statement?
Check and clarify. not accepted: The document doesn’t state that only XML/SOAP supports OWS common 2.0. This sentence just lays out what XML/SOAP conforms to. Elsewhere we have what KVP conforms to, and that includes OWS common 2.0.
DE 5.1 p. 36, 1st paragraph:Conformance classes used: HTTP
POST SOAP
encoding
te Trying to interpret this I think it wants to say: “INSPIRE WCS Download Services use the following protocol bindings”. If so, shouldn’t this be a formal requirement? (if it is about WCS SOAP, that has only 1 class)
Check and clarify. not accepted: The section is showing what the protocol bindings must conform to. The formal requirement is that one of the protocol bindings must be supported.
DE 5.1 p. 36, 2nd and 4th paragraph
ed Drop "this". Support for the this protocol binding is indicated in a WCS GetCapabilities response as:
accepted
UK 5.1 Ed Replace “Support for the this” with “Support for this” (twice)
accepted
DE 5.1 p. 36, 2nd paragraph: OGC 09-
ed This formatting is very confusing. Only late I understood that the paragraphs below go _under_ this bullet. Indentation might help.
Check and change format. accepted: Will review/modify formatting or add text to make it clearer that we are
1 Type of comment: ge = general te = technical ed = editorial page 25 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
147r3, WCS 2.0 Interface Standard – KVP Protocol Binding Extension, version 1.0
discussing first XML/SOAP and then KVP
DE 5.1 p. 36, paragraph above TG Requirement 2: You must support...
ed Replace "You" with "An implementation". An implementation must support... accepted
UK 5.1 Ed Language: one paragraph slips into second person “You must….”, which is quite nice, but isn’t the style used in the rest of the document. The next paragraph starts “We”Perhaps decide that INSPIRE TGs should be written in this more friendly tone?
accepted / noted
DE 5.1 p. 36, TG Requirement 2: Implementations shall support at least one of the two supported protocol bindings (KVP or POST/XML)
ed Replace "supported" with "WCS" Implementations shall support at least one of the two WCSprotocol bindings (KVP or POST/XML)
accepted
DE 5.1 p. 36, paragraph below TG Recommendation 4: GMLCOV is already included as part of WCS core, i.e. if you make a GetCoverage
te No, a coverage is delivered in its Native Format, whatever this might be.CAVEAT: GMLCOV is not GML!
Check and rephrase. accepted: will change GMLCOV to GML
1 Type of comment: ge = general te = technical ed = editorial page 26 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
request and don’t specify any output format the range set will be delivered in XML.
DE 5.1 Paragraph below TG Recommendation 4
ge Maybe there is a contradiction in OGC 09-110r4? At p.24: "The default format for the coverage response is the coverage’s Native Format." At p.26 it is defined as GMLCOV : "The response to a successful GetCoverage request is a coverage as per [OGC 09-146r2]." Remark: OGC 09-146r2 = GML 3.2.1 Application Schema - Coverages ("GMLCOV")
discuss: What are the implications of a contradiction in OGC 09-110r4 for this TG?
FR 5.1.1 Example : Ed Example 9 is not valid, * is not an accept language.
Update example. not accepted: [OWS 2] tells us that * is an accepted value.
EC 5.1.1 te The mapping of the language parameter required in the IR to the WCS standard is not sufficiently clear. Ideally, there should be only one implementation (probably the AcceptLanguages parameter).
Clarify the mapping (in this section or in the mapping table in 4.1.1.1). Restrict the mapping to one option. The other option (e.g. HTTP_ACCEPT_LANGUAGE) should be an optional addition (not alternative).
not accepted: Yes Ideally, but this handling of languages is part of [OWS 2] and thus inherited by WCS 2. Any ATS would have to pass a service that handled languages using this method because it would conform to the WCS specification.
EC 5.1.1 TG req 4 te The requirement on the service instance is unclear. Isn’t the AcceptLanguages parameter already included in the WCS 2.0 Core?
Rephrase the requirement or turn it into normal text explaining how the language parameter is implemented in WCS.
accepted: requirement is part of the WCS specification, so no need to have this as a separate requirement
DE 5.1.1 p. 39, TG Requirement 4: When using either the XML/POST or GET/KVP protocol bindings, the name ...
te Language is not contingent on protocol, so why not remain generic so that future extensions will not need to touch this.
Drop "When using either the XML/POST or GET/KVP protocol bindings,".
accepted: (resolution as above)
DE 5.1.1 Second paragraph
ed Strike last sentence „Note that strictly …“ accepted
UK 5.1.1 Third Ed Multiple spaces Reduce the spacing between “names” and “to” accepted
1 Type of comment: ge = general te = technical ed = editorial page 27 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
paragraph to single.
UK 5.1.1 Paragraph below Example 5
Ed Multiple spaces Reduce the spacing between “versions)” and “that”
accepted
UK 5.1.1 Paragraph below Example 7
Ed Missing possessive apostrophe Replace “servers” with “server’s” accepted
UK 5.1.1 Paragraph below Example 7
Te Document is correct in that AcceptVersions starts with a capital letter (as defined in OGC Catalogue Services spec 3.0). The most normative reference I can find tot the AcceptLanguages parameter is in the OWS 2.0 owsGetCapabilities.xsd – it has an initial capital there. 06-121r9 is internally inconsistent on this – and for AcceptVersions!
Replace “acceptLanguages” with “AcceptLanguages”(as perTG Requirement 4)
accepted
UK 5.1.1.1 Table 15 Ed Whilst creating the ATS for the Discovery Service, we have discovered the headache caused by putting lists into documents – they get out of step!
Find or create an INSPIRE Register of allowable languages and their 2 & 3 letter codes, and reference it, rather than list them in the document.
discuss: In theory this sounds a reasonable request, but as far as I can tell there is no such schema / codelist available. I think it should be noted too that the list given in Table 15 is intended to be informative, that is it tells you what the language codes are for the 24 official EU languages and the EFTA languages are, but it’s not saying that these (and only these codes can be used). So any schema/code list created for this purpose would need to account for all languages I think. Is it in scope for this activity to create a list to validate against?
DE 5.1.1.1 Second paragraph
ge Maybe extend list for keywords Titles, Abstracts, Keywords not accepted: Whilst it might be regarded as a nice feature to include keywords, it isn’t required for INSPIRE conformance
EC 5.1.1.2 TG req 5 te Be more specific about the schema to be used. Rephrase the requirement to: “The Extended Capabilities shall use [be valid against?] the XML Schema as defined in the INSPIRE online schema repository at http://inspire.ec.europa.eu/schemas/inspire_dls/1.0/inspire_dls.xsd“
accepted with modifications: changed the requirements text to make schema validation a requirement, but like the WFS guidance do not reference the schema location explicitly.
1 Type of comment: ge = general te = technical ed = editorial page 28 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
CH 5.1.1.2 Table 16 te We assume that for the Geographic Bounding Box that “coverage property” equals the keyword “CoverageSummary”. If this is the case, then use the keyword (as done for Keyword-> ExtendedCapabilities)
Change “coverage property” to “CoverageSummary”
accepted: Will change coverage property with CoverageSummary in the table
EC 5.1.1.2 TG req 8 te TG requirement 8 does not reflect a requirement in the IRs
Make this a recommendation. accepted
CZ 5.1.1.2 The last paragraph
ed Links to “figure 4” and “figure 5” are not corresponding to the figures.
Change links to “figure 3” and “figure 4”. not accepted: can’t find the mislabelled figures. It might be that the latest version has already corrected this issue.
DE 5.1.1.2 p. 40, last paragraph: ... it is up to the implementing Member State to decide...
ge Is this special for this choice? Why not implementing institution, for example?
Check and rephrase, if applicable. discuss: This is standard text, but as it is pointed out here it is rarely the country that decides for all its institutions. Should we change?
DE 5.1.1.2 p. 44, TG Requirement 6: A network service [Download Service]...
ed Drop "network service". A Download Service ... accepted
DE 5.1.1.2 Example 11 ge The use of the namespace „://“ is not common to the other TG documents
Maybe this should be altered in all other documents or be omitted.
accepted
EC 5.1.1.3 Para under table 17
ed This is a request to JRC to update the schema and should not be included in the TGs.
Remove this paragraph. not accepted: The statement is correct the INSPIRE schema doesn’t include all the languages. The fact that there is a request in to fix the issue is incidental.
EC 5.1.1.3 TG req 11 te Isn’t the requirement ensured by requiring compliance with the schema?
If so, please remove the requirement. accepted
CZ 5.1.1.3 ed There could be a table for language parameter codes, that would show differences in language codes defined by RFC 4646 and ISO 639-2/B.
Add the table of language codes. discuss: Would such a table be beneficial?
UK 5.1.1.3 Table 17 Ed Whilst creating the ATS for the Discovery Find or create an INSPIRE Register of not accepted: Schemas are already
1 Type of comment: ge = general te = technical ed = editorial page 29 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
Service, we have discovered the headache caused by putting lists into documents – they get out of step!
allowable languages and their 2 & 3 letter codes, and reference it, rather than list them in the document.
referenced
UK 5.1.1.3 Bilingual examples
Ge This is the first time I’ve realised that the service should flip its response language depending on the requested language
Transfer this explanation to e.g. TG Discovery. It is specified there, but not so well described!
accepted / no action for this document, but action on JRC to amend TG discovery?
DE 5.1.1.3 p. 48, paragraph below Example 12: A service supports French and English and the service default language is French
ed Strange sentence, maybe incomplete? Check and rephrase. accepted: Added (repeated) the paragraph on each of the examples it applies to in the text to make it clearer.
EC 5.1.2 te The mapping of the language and spatial data set identifier parameters required in the IR to the WCS standard is not sufficiently clear.
Include a sentence that explains the mapping (in this section or in the mapping table in 4.1.1.1).
accepted with modifications: adding clarification of the mapping of coverage id to spatial data set identifier. Language is already addressed in the section, but repeating text from earlier in the document to aid clarification.
EC 5.1.3 te The mapping of the language, spatial data set identifier and coordinate reference system parameters required in the IR to the WCS standard is not sufficiently clear.
Include a sentence that explains the mapping (in this section or in the mapping table in 4.1.1.1).
accepted with modifications: adding clarification of the mapping of coverage id to spatial data set identifier. Language is already addressed in the section, but repeating text from earlier in the document to aid clarification. CRS is covered in enough detail
EC 5.1.3 Coordinate transformations, p.52
te Should the conformance with the CRS profiles/extensions be made a (conditional) requirement.
Consider adding a requirement stating that, if the service offers a coverage in more than one CRS, it shall be conformant with the xxx profiles/extensions.
accepted
EC 5.1.3 ed The section discusses different aspects in one section.
Sub-divide the section into sub-sections, e.g. on CRS support, sub-setting parameters, …
not accepted: The content is closely interlinked
1 Type of comment: ge = general te = technical ed = editorial page 30 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
UK 5.1.3 Third para Ed Typo Change “response to a such a” to “response to such a”
accepted
DE 5.1.3 p. 51, 1st paragraph: ... response to an envelope (or “bounding box”), ...
te Caveat: “envelope”, as inherited from GML, does not need to be the smallest bbox.
not accepted / nothing to do: I don’t think there’s any need to add any caveat here. We are effectively talking about a client request. The client can specify any BBOX
DE 5.1.3 p. 51, 3rd paragraph: The coverage data provided in the response to such a GetCoverage request is supplied in the native coordinate reference system, ...
te Plus, bbox is expressed in the coverage’s Native CRS, unless WCS CRS extension parameters are used. Maybe this should be mentioned for completeness.
Check and rephrase. not accepted: It’s not relevant at this location in the text to discuss that a bbox is stated in the native CRS. At this stage in the text we are talking about a request where no bbox is used in the request
DE 5.1.3 p. 52, paragraph below Example 22: Whilst it is common for OGC web services to support reprojection of the data sets it operates on, ...
ed WCS CRS extension should be mentioned here by name, like the other specs.
Check and rephrase. accepted
DE 5.1.3 Second paragraph below
ge Maybe a further Recommendation makes sense: „The service should support an otf transformation for following CRS: ...“
not accepted : it’s not is scope to recommend any CRS to be supported, only to list what the requirements are with respect
1 Type of comment: ge = general te = technical ed = editorial page 31 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
Example 22, first sentence
Argumentation: The provision of coverages in only one CRS harms interoperability and will force the user to do further postprocessing.
supported CRS.
DE 5.1.3 p. 52/53, last paragraph
ed Further explanation required. Support for the extension is indicated in the GetCapabilities response by the following profile information:The first conformance class is the WCS CRS core conformance class, crs:<ows:Profile>http://www.opengis.net/spec/WCS_service-extension_crs/1.0/conf/crs</ows:Profile>Second, the WCS CRS specialization for gridded coverages needs to be supported for raster-type coverages:<ows:Profile>http://www.opengis.net/spec/WCS_service-extension_crs/1.0/conf/crs-gridded-coverage</ows:Profile>If the WCS CRS extension is supported then all actually supported CRSs are listed in the crsSupported elements of the Capabilities document:...Example 23: ...Note that such CRSs can be spatial, temporal, or mixed spatio-temporal. The OGC Name Type Specification for CRSs (OGC 11-135r2) establishes how to compose new CRSs from existing ones, such as adding a time axis to a horizontal CRS for obtaining image timeseries, as expressed in the following example:http://www.opengis.net/def/crs-compound? 1=http://www.opengis.net/def/crs/EPSG/0/4326& 2=http://www.opengis.net/def/crs/OGC/0/8601
accepted with modifications: Will add further explanation in line with proposed changes
1 Type of comment: ge = general te = technical ed = editorial page 32 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
The list of reported supported CRS is NOT in any order and cannot be used to imply the native CRS of any coverage.A WCS server supporting the CRS extension allows two additional parameters in the GetCoverage request: outputCrs for determining the CRS into which the coverage is to be projected before encoding and delivery and subsettingCrs indicating the CRS in which the request bounding box is expressed.
DE 5.1.3 p. 54, paragraph below Example 25
ed If the service cannot support a coordinate transformation(i.e.., the WCS CRS extension) then the coverage must be available a native CRS which is one of the coordinate reference systems defined by INS ISSDS Annex II.
accepted
DE 5.1.3 p. 54, 2nd paragraph below Example 25: In the future (through the proposed Coveragecollections extension) there will be a way to group coverages into collections; such collections could be used to group a set of coverages that differ
te Maybe it is premature to mention this extension; due to numerous reservations this seems to need substantial revision, and it is not clear today if, when, and in what shape it can become standard.
Check and rephrase. accepted: will cull this sentence
1 Type of comment: ge = general te = technical ed = editorial page 33 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
only in their projection.
DE 5.1.3 p. 54, last paragraph: Technically you should be able to specify an outputCrs parameter in any request, even if the service doesn’t support coordinate transformation, because if the server doesn’t understand any parameter it should ignore it; this will return the coverage data set in its native projection.
te Yes, but this should not be endorsed IMHO – among others, it is error prone.
Check and rephrase. accepted: Will check and rephrase. The intention isn’t to be a full endorsement, but rather a statement of what is possible. Will add some caveat that it could be error prone, or some such.
DE 5.1.3 p. 55, 1st paragraph: ... the request must use the axisLabels reported.
ed Add "for addressing the coordinate axes". ... the request must use the axisLabels reported for addressing the coordinate axes.
accepted
DE 5.1.3 p. 55, 2nd paragraph: For example in the following response
ed Spelling of "Lat" and "Long" is wrong (applies also to Example 26).
For example in the following response part (from a DescribeCoverage request for a coverage with id of BGS_EMODNET_AegeanLevantineSeas-MCol) and CRS EPSG:4258 the axes are labelled ‘Lat’ and ‘Long’ and ‘h’, so any
accepted with modifications: Will change Lat Long, but h is not appropriate here
1 Type of comment: ge = general te = technical ed = editorial page 34 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
part (from a DescribeCoverage request for a coverage with id of BGS_EMODNET_AegeanLevantineSeas-MCol) the axes are labelled ‘lat’ and ‘long’, so any subsetting request must use these labels (which are case sensitive). ...
subsetting request must use these labels (which are case sensitive).
DE 5.1.3 p. 55, 2nd paragraph: For example in the following response part (from a DescribeCoverage request for a coverage with id of BGS_EMODNET_AegeanLevantineSeas-MCol) the axes are labelled ‘lat’ and ‘long’, so any subsetting request must
te I fear that BGS_EMODNET_AegeanLevantineSeas-MCol is not possible as coverage name because GML type NCName requires [_a-zA-Z0-9].
Check and change coverage name, if applicable (applies also to Example 26).
not accepted: BGS_EMODNET_AegeanLevantineSeas-MCol conforms to NCName according to oXygen validator, but have different REGEX pattern: [\i-[:]][\c-[:]]*Example comes from a GeoServer service
1 Type of comment: ge = general te = technical ed = editorial page 35 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
use these labels (which are case sensitive). ...
DE p. 55, Example 26
te ISSUE: CRS is 3D, coverage contains 2D coordinates.
not accepted: EPSG:4258 is not a 3D CRS
DE 5.1.3 p. 55 ed After Example 26 a paragraph for further explanation should be added.
Subsetting is subdivided into trimming and slicing.Trimming retains the dimension of the coverage, it just reduces the extent along one or more axes; for example, trimming a 2D coverage yields a 2D output. Syntactically, trimming is expressed by indicating a lower and upper bound for the axis along which subsetting takes place.
accepted with modification: Will add further detail on Trimming and slicing but necessarily at the locations proposed
DE 5.1.3 p. 56 ed After Example 27 a paragraph for further explanation should be added.
Slicing reduces the dimension of the output by cutting out a (hyper-) plane at the slice point indicated. For example, in an x/y/t image timeseries a slice point at a particular point in time would extract a 2D x/y image. Conversely, slicing in x and y would extract a 1D timeseries. Obviously, the output format chosen must be able to encode the coverage extract; in the 2D case discussed this might be GeoTIFF, whereas in the 1D timeseries extract GML or JSON might be appropriate.
accepted with modification: Will add further detail on Trimming and slicing but necessarily at the locations proposed
DE 5.1.3 p. 57, Example 31
ed Suggest to uniformly keep parameter names in uppercase. In this example we have 3 different conventions!
Check all examples and change notation, where applicable.
accepted with modification: SUBSET is wrong but other parameters are correct and stick to the same convention
DE 6 p. 58, 4th paragraph: If a network service can’t support both of these two
te What are the concrete consequences / is the concrete advice for service operators? I have a hard time understanding what the net effect of this statement is from a service provider’s view.
“Both additional operations are required. Note: if this is technically not possible then a separate service endpoint might offer the extra functionality; this is referred to as “hybrid service”.”
accepted
1 Type of comment: ge = general te = technical ed = editorial page 36 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
additional operations it cannot be classified as an INSPIRE direct access download service. In such a situation a hybrid network service may be employed where one or other (or both) of the operations is supplied by a different services.
EC 6 para above the conformance class
te The hybrid approach where one operation is implemented using WCS and one using another standard is not entirely clear.
Elaborate on the hybrid approach and give an example.
accepted: Will elaborate on the meaning of hybridity here, as per DE proposed text (above).
DE 6 p. 58, 2nd paragraph
ed The paragraph is hard to understand – it feels like there is an operating option for a WCS which allows to switch mode.
Where the WCS service is used as desribed by the direct access concept, in addition to the download operations specified by Part A of INS NS that are covered in Chapter 5 services, it shall support discovery and retrieval as twomore download operations covered by Part B of INS NS.
accepted with modifications: will modify the paragraph to aid clarity. However it should be noted that the additional operations are not discovery and retrieval, they are ‘Get Spatial Object’ and ‘Describe Spatial Object Type’
DE 6 p. 58, TG Conformance Class 2: Direct Access WCS: This
ge Not sure I understand – does it mean: “requires” ?
Check and clarify. not accepted: inclusive is standard text
1 Type of comment: ge = general te = technical ed = editorial page 37 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
conformance class is inclusive of: ...
NL 6.1.1 Page 58 te Described Spatial Object Type is not clear enough. It seems that there are multiple ways to implement it. May be a preferred way should be given. Please consider to make a choice which one is preferred.
discuss: The reading of the section is correct; there are multiple ways that it can be implemented
Should we make a recommendation on which is preferred, if so which one?
NL 6.1.1 Page 59 ed typnename -> typename accepted
FR 6.1.1 Te Part 4.1.1.2 mentioned a mapping within the metadata record, through the discovery service but here it says that this operation cannot be mapped.
Please make these parts coherent. If the metadata approach is used, precise which metadata elements are made mandatory.
accepted: Will check that the sections are coherent and non-conflicting
DE 6.1.1 (all) ge The difference between featuretype and spatial object type is uncertain. There have to be clear examples for representations of both entities.
Maybe it will be good to alter the Recommendation 5 to a Requirement. Then there is only one representation for each service and we will get only one response to a DescribeSpatialObjectType request. Then we may not need the operation at all.
not accepted: The premise of changing the recommendation to a requirement is flawed. A direct access download service needs a Describe Spatial Object Type operation. That’s what the IR rules tell us.
The discussion of the difference between a spatial object type and a feature type is attempted elsewhere.
Spatial Object Types are defined by the INSPIRE Directive, for example RiskCoverage is a Spatial Object Type defined in Annex III under the natural risk Zones (NZ) spatial data theme, it’s probably not worthwhile repeating the definition for this example SOT here.
DE 6.1.1 p. 58, 1st paragraph: Unfortunately it is not possible to
ed Use of “type” is unusual and confusing. Maybe briefly explain to the reader what a “spatial object type” is.Further, rearrange so that this “disappointing” statement is next to the statement in the following paragraph that “there is no need”.
not accepted ‘Describe Spatial Object Type’ is the name of the required operation.
1 Type of comment: ge = general te = technical ed = editorial page 38 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
map the Describe Spatial Object Type operation to any WCS 2.0 operation or any extension of WCS 2.0.
DE 6.1.1 p. 58, 2nd paragraph
ge I am lost, as a reader. This discussion requires background which few will have.
Check and clarify. accepted: The section needs rewording (or even scrapping) The intention here was to show why the Describe Spatial Object type operation was made a required operation for direct access download services (which de facto meant WFS). Basically it’s required for a WFS to describe the feature, so that you can subsequently do a GetFeature request with Filter encoding… But in a WCS such an (intermediary) operation is not required.
DE 6.1.1 p. 58, TG Recommendation 5: An INSPIRE WCS download service should have only one representation of a Spatial Object Type per service.
ge What does this mean operationally, what should a service operator do concretely?
Check and clarify. accepted: will reword to add clarity
DE 6.1.1 p. 59, paragraph below TG Recommendation 5: The WCS DescribeCoverage
te Still puzzled –GetCoverage and DescribeCoverage do return information on the coverage type, so this seems not correct.
Check and rephrase. accepted: The section needs rewording (or even scrapping) The intention here was to show why the Describe Spatial Object type operation was made a required operation for direct access download services (which de facto meant WFS). Basically it’s required for a WFS to describe the feature, so that you can subsequently do a GetFeature request
1 Type of comment: ge = general te = technical ed = editorial page 39 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
operation technically returns information on a feature and not on a feature type (or spatial object type).
with Filter encoding… But in a WCS such an (intermediary) operation is not required.We have previously said that the DescribeCoverage (and thus the GetCoverage) do not map to all of the requirements for the required ‘Describe Spatial Object Type’ operation. So part of the discussion we should have is either what is the minimum that we can get away with to be conformant with the regulation, or can we specify some operation that would be additionally useful here…
DE 6.1.1 p. 59, paragraph below TG Recommendation 5: The WCS DescribeCoverage operation is regarded as not being in scope here, because it technically returns information on a feature and not on a feature type (or spatial object type).
ed Drop "is regarded as not being in scope here, because it".
The WCS DescribeCoverage operation is regarded as not being in scope here, because it technically returns information on a feature and not on a feature type (or spatial object type).
accepted
DE 6.1.1 p. 59, Example 32:typename=RiskCoverage
te If you want to make this a type, why not derive it from some coverage type via XML substitution group? That would yield exactly the desired information in DescribeCoverage – as far as I can follow this discussion.
Check and change notation, if applicable. not accepted: the purpose of the pseudo code example is to show how a WPS might be used to provide information on the spatial object type, in accordance with the Describe Spatial Object Type operation.
1 Type of comment: ge = general te = technical ed = editorial page 40 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
RiskCoverage is a Spatial Object Type, as defined by Annex III of the INSPIRE directive, as referenced in table 3 of this WCS TG.
Yes we could derive the RiskCoverage from some coverage type, but that isn’t the issue here.We have said previously that DescribeCoverage doesn’t map to the Get Spatial Object Type operation, so the question is how to get information about the RiskCoverage Spatial Object Type when we can’t use a DescribeCoverage?
DE 6.1.1 p. 59, paragraphs below Example 32
ed Seems editorially strange. Some text lost between the paragraphs?
Check and rephrase. accepted will append the two short sentences
DE 6.1.1 p. 61, TG Recommendation 6: Services should list the Spatial Object Types (as defined by INS ISSDS) that they support in their service metadata records.
te This does not normatively state where and how.
Indicate the concrete element in the XML Schema.
not accepted There may be multiple ways of listing the Spatial Object Types, depending on which service metadata is used.
DE 6.1.1 p. 61, paragraph below Recommendation 6: Below we list some simple
ed The WCS XPath extension might be referenced here, OGC 14-121, as it helps exactly here.
accepted: WCS XPath extension might be referenced here, will consider adding it. though it isn’t required to be supported in a WCS service for a client to be able to construct an XPath query, and indeed we’re not saying that you need this extension, just
1 Type of comment: ge = general te = technical ed = editorial page 41 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
example XPath expressions that might be used to query the Coverage description and metadata to extract information that could be used to construct a subsequent query of the spatial objects.
that it might be useful.
DE 6.1.1 Paragraph behind Recommendation 7
ge Ambiguous statement. No concrete solution for the problem is given and therefore there is no chance for a consistent implementation.
discuss: Do we need to have a concrete solution, if so what should it be?
UK 6.1.1 & 6.1.2
Te As 6.1.2 appears to say that Get Spatial Object is about extracting specific values from the coverage, then wouldn’t I make sense for Describe Spatial Object to return information about the record structure at each point?Otherwise, if holding to the position that each coverage is a feature instance, then Get Spatial Object would be the same as Get Spatial Data Set.
not accepted: The requirement is to describe the object type not the object. It is quite possible that a ‘Get Spatial Object’ operation and a ‘Get Spatial Data Set’ can return the same data/object. The difference in the operations is only in the way you can construct a query.
FR 6.1.2 TG Requirement 13
Te Is this requirement about GetSpatialObject or a way to fulfill Describe Spatial Object requirement?
Please put it in the right part accepted It’s a Describe Spatial Object Type operation requirement
EC 6.1.2 te TG requirement 13 is unclear Rephrase. discuss: The requirement tells us that the additional metadata required is that which describes the spatial object type information. Do we need to be more prescriptive? If so
FR 6.1.2 TG Requirement 13
Te It is not clear what additional metadata shall be provided.
Clarify the requirement (what metadata? And where/how to provide them).
1 Type of comment: ge = general te = technical ed = editorial page 42 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
how do we handle the fact that different SOT have different metadata?
DE 6.1.2 TG Requirement 13
ge It is not clearly stated which additional metadata is needed.
Make it more concrete.
FR 6.1.2 6.1.2 te It is not clear/explained why the processing extension has to be used for supporting the INSPIRE Get Spatial Object.GetCoverage propose already slicing/trimming capabilities.
Clarify this choice and the addition which are required by the INSPIRE Get Spatial Object operation. If not required than mention it as a recommandation.
accepted Will add the reasoning why the processing extension is required to fulfil the requirements of the Get Spatial Object operation.
DE 6.1.2 (all) ge In this part it is not clearly formulated, that the operations 6.1.1 and 6.1.2 are connected. You need to make a DescribeSpatialObjectType request and parse the response to formulate a GetSpatialObject request.
discuss: The connection between the ‘Describe Spatial Object Type’ and the ‘Get Spatial Object’ operations is mentioned in many places in the document.
The legislation tells us that both operations are required for a direct access download service (DADS); however the back story here is that the legislators were really guided by the operations of a WFS. In a WFS the ‘Describe Spatial Object Type’ is required to enable any query. And the Get Spatial Object’ operation, is the operation that runs any such query. So in a WFS DADS the two operations are complementary
In a WCS we have DescribeCoverage operation, but we have said elsewhere that the DescribeCoverage operation doesn’t map to the requirements of a ‘Describe Spatial Object Type’. So really it is a moot point if a WCS actually needs a ‘Describe Spatial Object Type’ operation. If only it were optional and not mandatory, then we would just omit it I think.
So in a WCS DADS the two operations are not necessarily complementary. If that message comes across in the TG then it is the intended meaning.
1 Type of comment: ge = general te = technical ed = editorial page 43 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
Do we need to change anything here?
DE 6.1.2 p. 63: The following conformance classes dependencies apply to the processing extension:
ed Typo in "classes". The following conformance classes dependencies apply to the processing extension:
accepted
DE 6.1.2 TG Recommendation 8
ge This Recommendation is not a real recommendation. Maybe it is only a hint or notice.
discuss: Is it reasonable to make this recommendation, or should we just cut it?
DE 6.1.2 p. 64, Example 43
te Rasdaman allows this in extending beyond the standard. WCPS itself requires a $ prefix, so not all implementations will support $-less variables.
Add $ prefixes in <abstractSyntax> section. accepted: will modify example
DE 6.1.2 p. 64, Title of Example 43
ed Add "returning a 1D timeseries encoded in CSV (comma-separated values)"
A slicing query on a coverage using a ProcessCoverages request (XML/POST), returning a 1D timeseries encoded in CSV (comma-separated values).
accepted
DE 6.1.2 p. 64/65, paragraph below Example 43: ...For a service where there the data sets provisioned are static files, the updateSequence date might align closely to an update of the coverage data, but in a service with direct access
ed Add "Further, a coverage may be updated piecewise – consequently, the date of last update can vary greatly across the pixels in the coverage."
For a service where there the data sets provisioned are static files, the updateSequence date might align closely to an update of the coverage data, but in a service with direct access to a live database there is likely to be no relationship between the sequence date and the coverages provided.Further, a coverage may be updated piecewise – consequently, the date of last update can vary greatly across the pixels in the coverage. Similarly ...
accepted
1 Type of comment: ge = general te = technical ed = editorial page 44 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
to a live database there is likely to be no relationship between the sequence date and the coverages provided.
DE 6.1.2 p. 65, paragraph below Example 43: ... Use of the updateSequence should be restricted therefore to advertising changes to the service metadata, not the coverages themselves.
te This appears to be an INSPIRE-specific data semantics then.
Put it into the INSPIRE metadata. discuss:
I can’t recall where this requirement to handle coverage date has come from. Can anyone remember?
I have a feeling it stems from Spatial Object Types (SOT) that define dates, such as the SoilThemeCoverage SOT that defines a ‘beginLifespanVersion’ attribute with a definition of ‘Date and time at which this version of the spatial object was inserted or changed in the spatial data set.’I feel that there is probably some merit in keeping the warning against using the update sequence to hold coverage updates, but perhaps we should just cull the recommendation?
DE 6.1.2 p. 65, TG Recommendation 10: The date of update of a coverage should be advertised in the coverage metadata.
te How, concretely? Make it more concrete. accepted (with caveat). If we decide to keep the recommendation (dependent on outcome of the above discussion) then we should give an example of how to handle dates
EC 6.1.2 te The conformance with the Processing Add a TG requirement on conformance with accepted
1 Type of comment: ge = general te = technical ed = editorial page 45 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
Extension should be a TG requirement. the Processing Extension.
EC 6.1.2 te The mapping of the parameters required in the IR to the WCS standard is not sufficiently clear.
Include a sentence that explains the mapping (in this section or in the mapping table in 4.1.1.1).
accepted with modifications: adding clarification of the mapping of coverage id to spatial data set identifier. For Language will repeat text from earlier in the document to aid clarification. Will add some statement of CRS options as well.
EC 6.1.2 TG rec 9 ed The recommendation is not worded as a recommendation.It could also be merged with recommendation 10.
Reword rec 9 to: “The WCS GetCapabilities updateSequence should not be used to advertise the date that [when?] a coverage has been updated.”
Or reword rec 9+10 to: “The date of update of a coverage should be advertised in the coverage metadata and not in the WCS GetCapabilities updateSequence.”.
accepted: Will merge the recommendations and reword
DE 7.1 p. 67, figure 8
ed Typo in "network latencey". Replace "latencey" with "latency". accepted with modifications: yes the spelling is incorrect, however it should be noted that this figure is borrowed from existing TG. Will attempt to fix but formatting may look slightly odd.
DE 7.2 Second and third sentence
ge Why are the requirements for discovery and view services are given here?
Omit this both sentences. accepted
EC 7.2.1 ed The IR requirements also include requirements for discovery and view services.
Remove the requirements irrelevant for download services
accepted
DE 7.2.1.3 p.68, TG Requirement 16: The response to a DescribeCoverage request shall take no longer than 10 seconds to start to
te On 1 coverage? Check and clarify. not accepted / no action: Yes on one coverage. The requirement is correctly stated.
1 Type of comment: ge = general te = technical ed = editorial page 46 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
respond, in normal operation.
DE 7.2.1.4 TG Requirement 20: The response to a GetCoverage request with a least one subsetting operation…
ed Replace a with at. The response to a GetCoverage request with at least one subsetting operation…
accepted
DE 7.2.1.4 TG Requirement 18
ge The using of a WCS as View Service is not defined in the TG for View Services. Why does this Requirement exists?
Omit Requirement 18 accepted
EC 7.2.2 TG req 18 te This is not a requirement for download services.
Remove the requirement. accepted
DE 7.2.1.4 TG Requirements 19 + 20
ge Both Requirements can be glued together. The response to a GetCoverage request shall take no longer than 30 seconds to start to respond, in normal operation.
accepted
EC 7.2.2 TG reqs 19+20
ed The two requirements can be merged. Merge the requirements. accepted
DE 7.2.1.5 TG Requirement 23: The response to a ProcessCoverages request with a least one subsetting operation...
ed Replace a with at. The response to a ProcessCoverages request with at least one subsetting operation
accepted
DE 7.2.1.4 TG Requirements 22 + 23
ge Both Requirements can be glued together. The response to a ProcessCoverages request shall take no longer than 30 seconds to start to respond, in normal operation.
accepted
DE 7.2.1.5 p. 68/69 TG Requirement 22 and TG
ed Both are identical. Merge into one requirement. accepted
1 Type of comment: ge = general te = technical ed = editorial page 47 of 48
Comments Country: CH,CZ,DE,EC,FR,NL,UK Date: 7 April to 6 May Document: TG for WCS-based download services v1.0rc1 Project: MIWP-7b / MIG-T
MS Chapter/ Section(e.g. 3.1)
Paragraph/ Figure/ Table/(e.g. Table 1)
Type of comment1
Comments Proposed change Resolution
Requirement 23
EC 7.2.2 te The current download service establishes “normalized testing procedures” – could this also be done for WCS?
Consider adding further instructions on how to perform the QoS testing.
not accepted: It is not in the scope of this document to go into detail about how to test service performance. Section 7.2.1.6 mentions this.
DE 7.4.1 TG Requirement 26
ge The Requirement is already given from the IR NS.
Omit Requirement 26. not accepted: All of the QoS requirements are in the IR NS, can’t see why this requirement needs any special handling
1 Type of comment: ge = general te = technical ed = editorial page 48 of 48