Task #2711

Progressing the tasks of the work group (document 2)

Added by James Passmore over 4 years ago. Updated over 4 years ago.

Status:Work in progressStart date:01 Mar 2016
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Proposed change or action:

Description

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:

  • ElevationGridCoverage
  • ElevationTIN
  • HydrogeologicalObject (two data types in scope)
  • GeophProfile
  • GeophSwath
  • GeophStation
  • LandCoverGridCoverage
  • OrthoimageCoverage
  • SoilThemeCoverage
  • SoilThemeDescriptiveCoverage
  • ExistingLandUseGrid
  • EnvironmentalMonitoringFacility
  • ExposedElementCoverage
  • HazardCoverage
  • ObservedEventCoverage
  • RiskCoverage
  • SamplingCoverageObservation (there are many data types that are in scope)
  • MarineLayer
  • SeaBedArea
  • SeaSurfaceArea
  • Habitat
  • RenewableAndWastePotentialCoverage

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.

 

20160413_Issues_Implementing_INSPIRE_Coverages_JEscriu.doc (81 KB) Michael Lutz, 26 Apr 2016 03:13 pm

20160420_Issues_implementing_INSPIRE_coverages_TC3_JEscriu.pptx (2.8 MB) Michael Lutz, 26 Apr 2016 03:13 pm

20160413_List of issues related to coverage data and services_v2_pb.doc (105 KB) Michael Lutz, 28 Apr 2016 02:03 pm

History

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

Thanks

James

 

 

 

 

#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,

Peter

#3 Updated by Michael Lutz over 4 years ago

I suspect that at least the following discussion threads from the Thematic Clusters are relevant:

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.

#4 Updated by Michael Lutz over 4 years ago

  • Status changed from New to Closed

#5 Updated by Michael Lutz over 4 years ago

From Jordi:

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.

Michael

Also available in: Atom PDF