Discussion #2609

How to map the Get Spatial Data Set operation to WCS (pre-defined data set download service)

Added by Michael Lutz almost 5 years ago. Updated almost 5 years ago.

Status:Feedback
Priority:Normal
Assignee:James Passmore

Description

Art. 11(1c) of the Directive requires MS to set up download services "enabling copies of spatial data sets, or parts of such sets, to be downloaded and, where practicable, accessed directly". The NS IR require a download service to have a Get Spatial Data Set operation that "allows the retrieval of a Spatial Data Set" (nb that it does not mention "parts of such sets").

The Get Spatial Data Set operation shall have the following input parameters:

  • Language: The Language parameter shall indicate the natural language requested for the Spatial Data Set.
  • Spatial Data Set Identifier: The Spatial Data Set Identifier parameter shall contain the Unique Resource Identifier of the Spatial Data Set.
  • Coordinate Reference System: The Coordinate Reference System parameter shall contain one of the Coordinate Reference Systems included in the list of available Coordinate Reference Systems referred to in the service metadata.

The operation shall return the requested Spatial Data Set in the requested language and in the requested Coordinate Reference System.

These requirements need to be mapped to the WCS specification. It was agreed in the WCS workshop in 2014 that the operation would be mapped to the GetCoverage operation, and that a coverage should be mapped to the notion of "data set".

However, there are still a number of open discussion points (from the workshop minutes):

  • Separate endpoints for each data set series (recommendation)
  • Need for "coverage collection" extension? (cf. EO profile)
  • Could be left up to data provider to decide what should be mapped to a data set; needs to be practical to be downloaded
  • Recommendations in TG, including how to link to dataset (series) metadata
  • For huge coverages, complete download might not make sense... (IR obligation cannot be fulfilled)
  • Map Describe Spatial Object Type operation to DescribeCoverage. "Schema information" is provided through DomainSet and RangeType elements in DescribeCoverageResult
  • What to do with old data – archive or also serve through WCS? (out of scope for TGs)

Please include your proposals or examples of existing data sets and how they could be mapped to the INSPIRE notion of "data set" as comments to this issue.


Subtasks

Discussion #2628: How to map the language parameter for the download servic...FeedbackJames Passmore

History

#1 Updated by Michael Lutz almost 5 years ago

  • Description updated (diff)

#2 Updated by James Passmore almost 5 years ago

This is how I understand the language issue.

First off any individual download service just needs to identify which language it supports using for example the extended capabilities section, other methods could be used, for example it could be part of the HTTP HEAD response in RESTful services using HTTP.

So we can already add an extended capabilities section to a WCS that advertises languages supported, and have a WCS service that supports this.

 

Actually at this point I have a related question, is it only services for pre-defined datasets that need to have such metadata that is the implication from current TG on download services as below:

 

Section 4 INSPIRE Download Services

...

In addition to the above definitions, a pre-defined dataset or a pre-defined part of a dataset is characterised by two conditions:

  • It has a metadata record and can be discovered using an INSPIRE conformant discovery service.

 

In any case a service needs only support one language, the principle requirement is that the service advertises the language it supports even if only one langauge is supprted.

 

For those services that support more than one language there needs to be a defined mechanism by which a client can request a language (or more precisely by which a client can request a language other than the default language).  With WCS 2.0 this mechanism is defined by the GetCapabilites operation of OWS Common 2.0.  The mechanism comes through the use of the acceptlanguages parameter.

 

So for a WCS pre-defined dataset service that wishes to support multi-linguality we just need to state that the server software must support the acceptlanguages parameter.

 

 

 

 

 

 

#3 Updated by Peter Baumann almost 5 years ago

James Passmore wrote:

This is how I understand the language issue. First off any individual download service just needs to identify which language it supports using for example the extended capabilities section, other methods could be used, for example it could be part of the HTTP HEAD response in RESTful services using HTTP. So we can already add an extended capabilities section to a WCS that advertises languages supported, and have a WCS service that supports this.   Actually at this point I have a related question, is it only services for pre-defined datasets that need to have such metadata that is the implication from current TG on download services as below:   Section 4 INSPIRE Download Services ... In addition to the above definitions, a pre-defined dataset or a pre-defined part of a dataset is characterised by two conditions: It has a metadata record and can be discovered using an INSPIRE conformant discovery service.   In any case a service needs only support one language, the principle requirement is that the service advertises the language it supports even if only one langauge is supprted.   For those services that support more than one language there needs to be a defined mechanism by which a client can request a language (or more precisely by which a client can request a language other than the default language).  With WCS 2.0 this mechanism is defined by the GetCapabilites operation of OWS Common 2.0.  The mechanism comes through the use of the acceptlanguages parameter.   So for a WCS pre-defined dataset service that wishes to support multi-linguality we just need to state that the server software must support the acceptlanguages parameter.            

 

It might be advantageous to define the language issue protocol independent first, and then map it to the various protocols WCS supports. BTW, a REST is waiting since long, but only now OGC seems to converge on an opinion about what a RESTful interface should look like.

Such a general mechanism could be the extension mechanism. Similar as functionality, formats, CRSs, and interpolation for example is advertised in the service description, the language could be as well.

If we find an extension-based approach for the multilinguality issue I will be happy to assit in getting it as an extension through the OGC adoption cycle.

 

#4 Updated by James Passmore almost 5 years ago

  • Status changed from New to Feedback

Michael Lutz wrote:

However, there are still a number of open discussion points (from the workshop minutes): Separate endpoints for each data set series (recommendation)

 

Can anyone remember why this was a recommendation, to me it appears to be a limitation.

 

 

#5 Updated by James Passmore almost 5 years ago

Michael Lutz wrote:

The NS IR require a download service to have a Get Spatial Object operation that "allows the retrieval of a Spatial Data Set" (nb that it does not mention "parts of such sets"). The Get Spatial Object operation shall have the following input parameters: Language: The Language parameter shall indicate the natural language requested for the Spatial Data Set. Spatial Data Set Identifier: The Spatial Data Set Identifier parameter shall contain the Unique Resource Identifier of the Spatial Data Set. Coordinate Reference System: The Coordinate Reference System parameter shall contain one of the Coordinate Reference Systems included in the list of available Coordinate Reference Systems referred to in the service metadata. The operation shall return the requested Spatial Data Set in the requested language and in the requested Coordinate Reference System. These requirements need to be mapped to the WCS specification.

 

So an Atom service is not conformant to NS IR because it does not define a Get Spatial Object operation? 

Looking at the current TG a Get Spatial Object operation is actually an operation of a direct access service, and not a pre-defined dataset service (atom or WFS stored procedure). By definition a direct access service provides a subsetting operation as part of the query request so I assume this is why there doesn't need to be an explicit mention of a sub set here (it's implied by definition)?

#6 Updated by Michael Lutz almost 5 years ago

  • Description updated (diff)

I just noted that the description of the issue was referring to the Get Spatial Object rather than the Get Spatial Data Set operation. I just corrected that. 

Regarding multilinguality, we need to distinguish between the language requirements for the Get Spatial Data Set operattion (as described in the issue) and those for the Get Download Service Metadata (aka GetCapabilities) operation. The latter shall support a request parameter indicating the natural language to be used for the content of the Get Download Service Metadata response. The response shall include two language parameters:
— the response Language parameter indicating the natural language used in the Get Download Service Metadata response parameters,
— the Supported languages parameter containing the list of the natural languages supported by the Download Service.

Looking at the WFS section in the existing download services TG, I could not find detailed requirements for how to handle the language request parameter in the  Get Spatial Object and Get Download Service Metadata operations (however, it defines how to handle it in stored queries for the Get Spatial Data Set operation). In the View Services TG, however, there is an extended section on Language Requirements, where the use of a LANGUAGE parameter is explained for the WMS GetCapabilities operation.

I think we should have a common approach for the language parameter mapping for all WxS-based INSPIRE TGs. On the other hand, I don't think it should be our prime focus. I can see why you may want for metadata in another language, but asking for a coverage in another language will not have much sense in most cases. I therefore would suggest to factor this out into a separate issue, and focus this one on the question - what is a pre-defined spatial data set for coverage data. 

 

#7 Updated by Michael Lutz almost 5 years ago

I have created a new sub-task #2628 for the language aspects.

This issue is still about including your proposals or examples of existing data sets and how they could be mapped to the INSPIRE notion of "data set" as comments to this issue.

Also available in: Atom PDF