Progressing the tasks of the work group (document 2)
|Status:||Work in progress||Start date:||01 Mar 2016|
|Proposed change or action:|
There are two technical guidance documents that we are constructing for this exercise of being able to provide coverage data through an INSPIRE conformant WCS service, and an additional task to propose changes if required to regulation and data specifications.
Task / Document 1¶
The first document (draft as circulated and commented on to date) looks at the various INSPIRE regulations particularly the INSPIRE Network Services Regulation (INS NS) and attempts to map the operations of the WCS 2 interface standard (and extensions to that standard), to the required and conditional operations of the legislation. This document does not have any legal bearing, but rather it hints at how you can create an INSPIRE compliant WCS download service. How to map data to these operational responses is not in scope.
Task / Document 2 ¶
The second document (as yet unwritten) looks at the Data Specifications that mention that the data can be supplied as a coverage (either completely or in part) and attempts to answer the question of how to map the Spatial Object Types (and data types) mentioned in INSPIRE Regulation on the interoperability of spatial datasets and services Regulation (INS ISSDS) and the many amendments to this regulation (this is implicit but mentioned explicitly here for completeness), to the structure of the responses of a WCS 2 service. Particulary it looks at how to map a GetCoverage response to legally defined Spatial Object Types; and as part of that it looks at whether making such a mapping breaks anything in the existing technical guidance/data specifications. How to use any existing software to map the data to the data structure is not in scope.
In relation to the second document we have already, as part of the scoping study, identified a number of Spatial Data themes to be in scope (as identified/described in the first document Tables 2 and 3), and listed below:
- HydrogeologicalObject (two data types in scope)
- SamplingCoverageObservation (there are many data types that are in scope)
I suggest as a basic structure:
- A brief introduction (a copy perhaps of section 1.1) of the first document.
- A general mapping guidance section (there are certain to be commonalities between the Spatial Object Types legally defined and how these can be generally interpreted, and mapped to a WCS 2 response).
- A number of more detailed sections, giving examples
These more detailed sections could be by data theme, or type of coverage, or some combination of the these, for example SamplingCoverageObservation is relevant to AC, MF, and OF spatial data themes.
Task 3 (if required)¶
A third task is to propose changes to the data specification (and legislation) if required. For example, we might want/need to propose changes to the
INS NS to address issues with how QoS is measured, or propose that the Describe Spatial Object Type operation be an optional requirement for Direct Access Download services, or we might need to make changes to the data specifications or suggest alternative encodings.
#1 Updated by James Passmore over 4 years ago
- Tracker changed from Discussion to Call for participation
Can everyone take a look at the basic layout of the second document, that I have suggested, and let me know if this is a sane approach, or if I have missed anything obvious. Does anyone have a better structure in mind?
Can you also comment on whether the list of Spatial Object Types that I have listed is correct, are there any omissions, or is something listed that you don't think is in scope.
Can you also comment on whether you think (or have seen referenced somewhere ~ links would be good) that there are known issues with the existing data specifications that we can investigate and document solutions to etc.
#2 Updated by Peter Baumann over 4 years ago
Doc #2 structure looks very good to me (although I cannot comment on data type completeness, I'm not diving enough into the Annexes).
We might isolate some sample data sets, at least one per coverage type, and use them to play with = provide them as coverages on some server; use output snippets from our forthcoming reference implementations as illustrating examples; etc.
Known issues: If it is of interest that INSPIRE WCS is compatible with vanilla OGC WCS then we might reconsider the INSPIRE coverage definition; as has been pointed out elsewhere they are not compatible, and implementations tend to "forget" some details. Therefore, we might feed a separate, "Purely OGC based" service with these sample data and perform cross-checks as the specification gets nailed down. Being OGC WCS Core Reference Implementation we can gladly take that on our agenda. Such an endeavour might drive thoughts about coverage harmonization.
my 2 cents,
#3 Updated by Michael Lutz over 4 years ago
I suspect that at least the following discussion threads from the Thematic Clusters are relevant:
- Experiences on encoding of Elevation and Orthoimagery coverages
- Need more guidance for Elevation encoding and correct example (for ElevationGridCoverage) on the basis of GMLCOV schema
- How to implement tiling / model mosaic elements, coverages and coverage aggregations in GMLCOV files
Maybe Jordi can point out further discussions.
I would expect that the document clarifies (at least) whether the INSPIRE-defined sub-types of GML coverages should be used when encoding INSPIRE coverages, or whether the additional attributes defined for coverages in the INSPIRE data models should be encoded in some other way.
#5 Updated by Michael Lutz over 4 years ago
- File 20160413_Issues_Implementing_INSPIRE_Coverages_JEscriu.doc added
- File 20160420_Issues_implementing_INSPIRE_coverages_TC3_JEscriu.pptx added
- Tracker changed from Call for participation to Task
- Status changed from Closed to Work in progress
Find attached the discussion paper presented in the MIG-T Meeting in Ispra last week, regarding the issues/questions data providers are facing when implementing coverage data.
I think this documentation is useful to think about a useful / appropriate structure for deliverable “Technical Guidelines for providing INSPIRE coverage data using WCS” in Task 2 of MIWP-7b WCS.
Hope it is useful - Happy to join the discussion later on through the MIG-T platform.
All the best, Jordi
#6 Updated by Michael Lutz over 4 years ago
Jordi, James, all,
please find input from Peter Baumann on the coverage questions raised in the 2 coverage workshops attached.