Übersicht:
Favoritenliste:
Favoritenseiten
| Ihre Favoritenliste enthält derzeit keine Seiten. Sie fügen dieser Liste Seiten hinzu, indem Sie im Menü Extras der angezeigten Seite Favorit selektieren. |
Kommentierungszeitraum ist abgelaufen, bitte nicht mehr kommentieren!
Finale Fassung der Kommentierungstabelle (am 28.04.2016 der EU-KOM übermittelt)
Worum geht es?
Eine temporäre Arbeitsgruppe der MIG-T hat einen Entwurf zu technischen Empfehlungen für die Umsetzung von INSPIRE Downloaddiensten auf der Basis des OGC Web Coverage Service (WCS) 2.0 erarbeitet. Der Entwurf wurde nun der MIG-T zur Kommentierung vorgelegt.
Nach der Konsultation durch die MIG-T wird das Dokument auf Grundlage der eingegangen Kommentare überarbeitet und anschließend der MIG-P zur Verabschiedung vorgelegt. Bei der Konsultation durch die MIG-P wird es voraussichtlich erneut eine Gelegenheit zur Kommentierung geben.
Wer sollte sich an der Kommentierung beteiligen?
Die Konsultation richtet sich insbesondere an Experten, die den OGC Web Coverage Service (WCS) 2.0 für die Bereitstellung von INSPIRE Downloaddiensten nutzen möchten.
In Deutschland werden insbesondere der AK Geodienste und der AK Architektur beteiligt.
Relevante Verordnungen und Technical Guidance Dokumente?
Netzdienste
Kommentierungszeitraum?
Kommentare können bis zum 27.04.2016 über diese Seite abgegeben werden.
Zu prüfende Dokumente?
Kommentierungstabelle
Bitte in der nachfolgenden Tabelle Ihre Kommentare eintragen (möglichst in englischer Sprache).
Bitte die Kommentare klassifizieren (Type of comment) nach
- ge = general
- te = technical
- ed = editorial
Bei Fragen wenden Sie sich bitte an Benutzer-1d197 oder Daniela Witter.
| Chapter/Section (e.g. 3.1) | Paragraph/Figure/Table (e.g. Table 1) | Type of comment | Comments | Proposed change | Resolution | Kommentiert von (nur zur internen Verwendung) |
|---|---|---|---|---|---|---|
| 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] | GDI-LSA | |
| 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 ... | GDI-LSA | |
| 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] | GDI-LSA | |
| 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 | GDI-LSA | |
| 2 | (all) | ed | Add missing references. | Add e.g. INS GCM, OGC 09-146r1, OGC WCS, ISO 19101 etc. | GDI-LSA | |
| 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] | GDI-LSA | |
| 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] | GDI-LSA | |
| 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 976/2009 as regards download services and transformation services | 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 | GDI-LSA | |
| 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… | GDI-LSA | |
| 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 | GDI-LSA | |
| 1.2 | p.14, 1st paragraph: Coverage functions are used... | ed | Maybe the mentioning of "functions" is confusing for the general audience. | Check wording. | Peter Baumann | |
| 1.2 | p. 14, 2nd paragraph: ... properties of spatial object types where the type of the property value is a realisation of one of the types... | ed | Not sure people will understand this | Check wording. | Peter Baumann | |
| 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. | Peter Baumann | |
| 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". | Peter Baumann | |
| 1.2 | p. 14, 3rd paragraph, 2nd bullet point: a grid associated with a transformation that can be used to convert grid coordinate values to values of coordinates referenced to a coordinate reference system (see Figure 2, right). | ed | Maybe mention the grid is irregularly spaced? | Peter Baumann | ||
| 1.2 | p. 14, 4th paragraph: In addition, some themes make reference to the types 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). | te | This is confusing, as coverages as well may contain time axes and (unfortunately) WaterML is not harmonized in any way with GMLCOV/CIS. | Peter Baumann | ||
| 1.2 | p. 14, last paragraph: Where possible, ... | This seems like a conclusion. | Shift it after the GMLCOV/CIS discussion below. | Peter Baumann | ||
| 1.2 | p. 14, last paragraph: ... these coverage types... | te | What does “these” refer to? WaterML != OGC coverages. | Peter Baumann | ||
| 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”. | Peter Baumann | ||
| 1.2 | p. 16, paragraph below figure 4: ... GML coverage... | te | Can be any suitable format. | Drop “GML”. | Peter Baumann | |
| 3.1 | (5) coordinate reference systems Systems 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] | ed | Systems for uniquely referencing spatial and/or temporal information in space as a set of coordinates (x, y, z, t) and/or latitude and longitude and height, based on a geodetic horizontal and vertical datum [INSPIRE Directive] | Peter Baumann | ||
| 3.1 | (6) coverage spatial 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[PB1] elevation model (as grid or TIN), point grids etc. | ed | (1) coverage spatial 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. | Peter Baumann | ||
| 3.1 | (12) geographical grid systems NOTE 2 ... Thus, a 'geographical grid' is equivalent to an ISO 19123 coverage. ... | ed | Gridded coverage? | Peter Baumann | ||
| 3.1 | (12) geographical grid systems NOTE 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). | Peter Baumann | |
| 3.1 | (13) GML coverage | ed | Should not contain “GML”, this has led to sustained confusion. | Drop "GML". | Peter Baumann | |
| 3.1 | (13) GML coverage ... subclass (specialization) of a Coverage ... | 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 am not sure it is needed as a specific term, unless we define GeoTIFF coverages, NetCDF coverages, and the like as well. | Drop term (13). | Peter Baumann | |
| 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". | Peter Baumann | |
| 3.1 | (20) spatial data, NOTE | te | Very much agreed with the NOTE. Does it include temporal? | Peter Baumann | ||
| 3.1 | (21) spatial data services operations... | te | Service offers a set of operations, but is not an operation. Example: a WFS instance is not an operation. | Check wording. | Peter Baumann | |
| 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) | Peter Baumann | |
| 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. | Peter Baumann | ||
| 4 | p. 24, 1st paragraph | ed | Replace "exist" with "exists" and add a sentence to clarify the need of a WCS guidance. | Other Technical Guidance exists for describing implementations using other service interfaces such as for Atom Syndication Format, WFS, and SOS. 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]. | Peter Baumann | |
| 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. | Peter Baumann | |
| 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". | Peter Baumann | |
| 4 | p. 25, paragraph below table 4: ... Conversely, when a service has access to a live database (for example one in which coverage data is being continuously updated), ... | te | Maybe the differentiating criterion is not “file vs database” – a file can just as well be updated regularly. | Leave out file/database exemplification. | Peter Baumann | |
| 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 | Peter Baumann | |
| 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. | Peter Baumann | |
| 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. | Peter Baumann | ||
| 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:
| Use just major version number for all standards referenced. | Peter Baumann | |
| 5.1 | p. 35: OGC 09-146r2, OGC® GML Application Schema for Coverages, version 1.0 Conformance classes used:
| 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). | Peter Baumann | |
| 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. | Peter Baumann | |
| 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 are WCS extensions. This way, functionality and encoding are separated. | Peter Baumann | |
| 5.1 | p. 35, 2nd paragraph below TG Requirement 1: Two protocol bindings are currently supported by WCS 2.0: | 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. | Peter Baumann | |
| 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. | Peter Baumann | |
| 5.1 | p. 36, 1st paragraph: Conformance classes used:
| 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. | Peter Baumann | |
| 5.1 | p. 36, 2nd and 4th paragraph | ed | Drop "this". | Support for the | Peter Baumann | |
| 5.1 | p. 36, 2nd paragraph: OGC 09-147r3, WCS 2.0 Interface Standard – KVP Protocol Binding Extension, version 1.0 | 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. | Peter Baumann | |
| 5.1 | p. 36, paragraph above TG Requirement 2: You must support... | ed | Replace "You" with "An implementation". | An implementation must support... | Peter Baumann | |
| 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. | Peter Baumann | |
| 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 WCS protocol bindings (KVP or POST/XML) | Peter Baumann | |
| 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 request and don’t specify any output format the range set will be delivered in XML. | te | No, a coverage is delivered in its Native Format, whatever this might be. CAVEAT: GMLCOV is not GML! | Check and rephrase. | Peter Baumann | |
| 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. | Peter Baumann | ||
| (all) | (all Examples) | ed | Drop "&" in the last row. | e.g. Example 5: http://myserver.ac.uk/some/folders/ows?service=WCS&request=GetCapabilities | Peter Baumann | |
| 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,". | Peter Baumann | |
| 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. | Peter Baumann | |
| 5.1.1.2 | p. 44, TG Requirement 6: A network service [Download Service]... | ed | Drop "network service". | A Download Service ... | Peter Baumann | |
| 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. | Peter Baumann | |
| 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. | Peter Baumann | ||
| 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. | Peter Baumann | |
| 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. | Peter Baumann | |
| 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?
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. | Peter Baumann | |
| 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. | Peter Baumann | ||
| 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 only in their projection. | 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. | Peter Baumann | |
| 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. | Peter Baumann | |
| 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. | Peter Baumann | |
| 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 use these labels (which are case sensitive). ... | 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 subsetting request must use these labels (which are case sensitive). | Peter Baumann | |
| 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 use these labels (which are case sensitive). ... | 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). | Peter Baumann | |
| 5.1.3 | p. 55, Example 26 | te | ISSUE: CRS is 3D, coverage contains 2D coordinates. | Peter Baumann | ||
| 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. | Peter Baumann | |
| 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. | Peter Baumann | |
| 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. | Peter Baumann | |
| 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 two more download operations covered by Part B of INS NS. | Peter Baumann | |
| 6 | p. 58, 4th paragraph: If a network service can’t support both of these two 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.
| 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”.” | Peter Baumann | |
| 6 | p. 58, TG Conformance Class 2: Direct Access WCS: This conformance class is inclusive of: ... | ge | Not sure I understand – does it mean: “requires” ? | Check and clarify. | Peter Baumann | |
| 6.1.1 | p. 58, 1st paragraph: Unfortunately it is not possible to map the Describe Spatial Object Type operation to any WCS 2.0 operation or any extension of WCS 2.0. | 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”. | Peter Baumann | |
| 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. | Peter Baumann | |
| 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. | Peter Baumann | |
| 6.1.1 | p. 59, paragraph below TG Recommendation 5: The WCS DescribeCoverage operation technically returns information on a feature and not on a feature type (or spatial object type). | te | Still puzzled –GetCoverage and DescribeCoverage do return information on the coverage type, so this seems not correct. | Check and rephrase. | Peter Baumann | |
| 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 | Peter Baumann | |
| 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. | Peter Baumann | |
| 6.1.1 | p. 59, paragraphs below Example 32 | ed | Seems editorially strange. Some text lost between the paragraphs? | Check and rephrase. | Peter Baumann | |
| 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. | Peter Baumann | |
| 6.1.1 | p. 61, paragraph below Recommendation 6: Below we list some simple 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. | ed | The WCS XPath extension might be referenced here, OGC 14-121, as it helps exactly here. | Peter Baumann | ||
| 6.1.2 | p. 63: The following conformance classes dependencies apply to the processing extension: | ed | Typo in "classes". | The following conformance class | Peter Baumann | |
| 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. | Peter Baumann | |
| 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). | Peter Baumann | |
| 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 to a live database there is likely to be no relationship between the sequence date and the coverages provided. | 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 ... | Peter Baumann | |
| 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. | Peter Baumann | |
| 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. | Peter Baumann | |
| 7.1 | p. 67, figure 8 | ed | Typo in "network latencey". | Replace "latencey" with "latency". | Peter Baumann | |
| 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 respond, in normal operation. | te | On 1 coverage? | Check and clarify. | Peter Baumann | |
| 7.2.1.5 | p. 68/69 TG Requirement 22 and TG Requirement 23 | ed | Both are identical. | Merge into one requirement. | Peter Baumann | |
| Title | ed | Either integrate the WCS guidance into the existing TG for download services (WFS + ATOM) or rename the existing ones | GDI-NW | |||
| 1 | Paragraph 4, last sentence | ge | „INSPIRE conformant WCS“ - such a service does not exists | Please use s.th. Like „INSPIRE conformant Downloadservice based on WCS“ | GDI-RP | |
| 1 | Table 2 and Table 3 | ed | Please mark those themes for which no other modelling option than coverages are possible. | GDI-RP | ||
| 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, Impelmenting Rules, Decisions). The other things like Technical Guidance and Guidlines concerns only technical things. | GDI-RP | ||
| 4 | Paragraph 1 | ge | The referenced TG for SOS was not already published. | Mark this TG as unpublished. | GDI-RP | |
| 4 | Table 4 | te | Text „Open request (query) parameters” in column 6 | Move to column 5 | GDI-NW | |
| 4 | Paragraph below Table 4, third sentence | ed | „when you provision“ | „when you provide“ | GDI-RP / GDI-BB | |
| 4 | Third paragraph, below Figure 5 – second point | ge | The term „conditional“ is somewhat missleading. This operations are mandatory if the provider will give access thru a direct access service! | |||
| 4.1.1.1 | Table 5, first row, Response, point 5 | ge | „which must include at least one required CRS“ | Is this really mandated by the directive? In case that data is provided as managed by the provider, without the possibility to fullfil the INSPIRE data model, then the data can be distributed unaltered. No transformation sho of CRS should be required. | GDI-RP | |
| 4.1.1.1 | Table 5, „Get Download Service Metadata Response“ | ge | „will be a WCS Capabilities document, which includes“ ...“the spatial datasets metadata“ | Spatial dataset metadata cannot be included in the capabilities document. It is allways referenced via xlink:href elements in MetadataURL tags! | GDI-RP | |
| 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. | GDI-RP | ||
| 4.1.1.2 | Title | ge | „Conditional download options“ | Don't use the term conditional. Maybe „optional“ is better, cause there is no legal demand for providing direct access downloadservices! | GDI-RP | |
| 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. | GDI-NW | |
| 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. | GDI-NW | |
| 4.2 | Table 12, point 2 – Direct Access Download Options | ge | Definition incomplete. | C, shall be M if the download service provides direct access to spatial data sets | GDI-BB | |
| 4.4 | Table 13 | ge | The Table may be omitted and as an alternative a list of CRS should be referenced | GDI-RP | ||
| 5.1 | TG Recommendation 4 | ge | The service should support both KVP and XML/SOAP. Maybe we should recommend POST | GDI-BB | ||
| 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") | GDI-BB | ||
| 5.1.1 | Second paragraph | ed | Strike last sentence „Note that strictly …“ | GDI-RP | ||
| 5.1.1.1 | Second paragraph | ge | Maybe extend list for keywords | Titles, Abstracts, Keywords | GDI-BB | |
| 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. | GDI-RP | |
| 5.1.3 | Second paragraph below Example 22, first sentence | ge | Maybe a further Recommendation makes sense: „The service should support an otf transformation for following CRS: ...“ Argumentation: The provision of coverages in only one CRS harms interoperability and will force the user to do further postprocessing. | GDI-BB | ||
| 6.1.1 | Whole part | 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. | GDI-BB | ||
| 6.1.1 | Paragraph behind Recommendation 7 | ge | Ambigiuos statement. No concrete solution for the problem is given and therefor there is no chance for a consistent implementation. | GDI-BB | ||
| 6.1.2 | TG Requirement 13 | ge | It is not clearly stated which additional metadata is needed! | Be more concrete! | GDI-BB | |
| 6.1.2 | Whole Part | 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. | GDI-BB | ||
| 6.1.2 | TG Recommendation 8 | ge | This Recommendation is not a real recommendation. Maybe it is only a hint or notice. | GDI-RP | ||
| 6.1.2 | TG Recommendation 9 + 10 | ge | This should already be known by all providers. | Omit this both Recommendations and mark them as hint or notice. | GDI-RP | |
| 7.2 | Second and third sentence | ge | Why are the requirements for discovery and view services are given here? | Omit this both sentences. | GDI-RP | |
| 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 | GDI-BB / GDI-RP | |
| 7.2.1.4 | TG Requirements 19 + 20 | ge | Both Requirements can be glued together. | The response to a GetCoverage request shall take not longer than 30 seconds to start to respond, in normal operation. | GDI-BB / GDI-RP | |
| 7.2.1.4 | TG Requirements 22 + 23 | ge | Both Requirements can be glued together. | The response to a ProcessCoverages request shall take not longer than 30 seconds to start to respond, in normal operation. | GDI-BB / GDI-RP | |
| 7.4.1 | TG Requirement 26 | ge | The Requirement is already given from the IR NS. | Omit Requirement 26 | GDI-RP |
Überblick
Inhalte
Aktivität