Discussion #2628

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

How to map the language parameter for the download services operations?

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

Status:Feedback
Priority:Normal
Assignee:James Passmore

Description

The following language requirements are laid down in the NS IRs:

  1. The Get Download Service Metadata operation shall support a request parameter Language 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.
  2. The Get Spatial Data Set operation shall support a request parameter Language, which shall indicate the natural language requested for the Spatial Data Set. The operation shall return the requested Spatial Data Set in the requested language and in the requested Coordinate Reference System.
  3. The Describe Spatial Data Set operation shall support a request parameter Language, which shall indicate the natural language requested for the description of the Spatial Objects type. The operation shall return the description of the Spatial Objects in the requested Spatial Data Set and in the requested language.
  4. The Get Spatial Data Object operation shall support a request parameter Language, which shall indicate the natural language requested for the Spatial Objects. The operation shall return the set of Spatial Objects which complies with Regulation (EU) No 1089/2010 and fulfils the search criteria in the query, in the requested language and in the Coordinate Reference System.
  5. The Describe Spatial Data Object operation shall support a request parameter Language, which shall indicate the natural language requested for the description of the Spatial Object type. The operation shall return the description of the spatial object type, in conformity with Regulation (EU) No 1089/2010.

The requirements are covered as follows in the WFS section of the existing download services TG:

  1. The language requirements of the Get Download Service Metadata and Describe Spatial Data Set operations (mapped to GetCapabiluities) is implemented through a language parameter in the GetCapabilities-Operation and requirements for the extended capabilities (section 6.7.1)
  2. The language requirements of the Get Spatial Data Set operation is implemented as a parameter of the Stored Query (section 6.4)
  3. The language requirements of the Describe Spatial Object operation is not implemented, since the DescribeFeatureType operation returns a description of the spatial object types in schema language and hence a parameter related to a natural language is not relevant.
  4. The language requirements of the Get Spatial Object operation is not implemented, since the the INSPIRE application schemas are modelled in a way so that in cases where multiple languages are possible for a feature property, the values in all languages may be provided simultaneously (e.g. for geographical names). i.e., if multilingual data is provided by a download service, all languages are provided by the download service. As a result, this parameter is not applicable for the GetFeature operation in practice.

Then, in section 6.7.2, there are some optional recommendations for multi-lingual support of error messages by setting up language-specific endpoints.

Could someone make a corresponding proposal for the WCS?


Related issues

Related to MIWP-7b: WCS-based download services - Discussion #2627: TG for DLS using WCS: Language considerations New 27 Nov 2015

History

#1 Updated by Michael Lutz almost 5 years ago

I have added sub-groups MIWP-7a and 7b as watchers for this issue, since it may be relevant for both the SOS and WCS sections of the download services TGs.

#2 Updated by Peter Baumann almost 5 years ago

Here a proposal that would fit with current handling of other service properties: extend the Profile section in the Capabilities document to carry language identifiers.

In WCS, the same mechanism is used for CRSs, encoding formats, interpolation methods, extensions supported.

Example:

<wcs:Capabilities ...>
  ...
  <wcs:ServiceMetadata xmlns="http://www.opengis.net/ows/2.0">
    <wcs:formatSupported>image/tiff</wcs:formatSupported>
    <wcs:formatSupported>application/gml+xml</wcs:formatSupported>
    <wcs:Extension>
      <int:InterpolationMetadata xmlns:int="http://www.opengis.net/wcs/interpolation/1.0">
        <int:InterpolationSupported>http://www.opengis.net/def/interpolation/OGC/0/nearest-neighbor</int:InterpolationSupported>
      </int:InterpolationMetadata>
      <lang:Languages>
        <lang:LanguageSupported>en_EN</lang:LanguageSupported>
        <lang:LanguageSupported>de_DE</lang:LanguageSupported>
      </lang:Languages>

    </wcs:Extension>
  </wcs:ServiceMetadata>
    ...
</wcs:Capabilities>

 

Discussion very welcome.

-Peter

 

#3 Updated by James Passmore almost 5 years ago

  • Status changed from New to Feedback

There appear to be two issues, first how to make requests for language specific content, and second how to respond and/or display such information.

For requests to WCS 2.0 services, the WCS specification defines an appropriate request parameter (derived from OWS common) and that request parameter is acceptlanguages=&.  The current WMS and WFS specifications do not use OWS common and therefore for INSPIRE there was a need to create another language request parameter (LANGUAGE=&).

 

For me it would be wrong to use LANGUAGE=& with WCS 2.0 as it already has it's own defined mechanism.  In the future with WMS 2.0 and WFS 3.0 the expectation would be that they would also be based on OWS common and therefore have acceptlanguages=& as a defined request paramenter for handling languages.

Does SOS derive its capabilities from OWS common 2.0? if so it also has acceptlanguages=& defined.

 

On the response at the moment we have the ability (using the INSPIRE download service extended capability section) to announce the languages supported by the service.  

<wcs:Extension>
<ows:ExtendedCapabilities>
<inspire_dls:ExtendedCapabilities>
<inspire_common:ResourceLocator>
<inspire_common:URL>http://earthserver.bgs.ac.uk/rasdaman/ows?</inspire_common:URL>
</inspire_common:ResourceLocator>
<inspire_common:ResourceType>service</inspire_common:ResourceType>
<inspire_common:TemporalReference>
<inspire_common:DateOfLastRevision>2014-07-01</inspire_common:DateOfLastRevision>
</inspire_common:TemporalReference>
<inspire_common:Conformity>
<inspire_common:Specification>
<inspire_common:Title>
Technical Guidance for INSPIRE Download Services 3.1
</inspire_common:Title>
<inspire_common:DateOfLastRevision>2013-08-09</inspire_common:DateOfLastRevision>
</inspire_common:Specification>
<inspire_common:Degree>notEvaluated</inspire_common:Degree>
</inspire_common:Conformity>
<inspire_common:MetadataPointOfContact>
<inspire_common:OrganisationName>British Geological Survey</inspire_common:OrganisationName>
<inspire_common:EmailAddress>enquiries@bgs.ac.uk</inspire_common:EmailAddress>
</inspire_common:MetadataPointOfContact>
<inspire_common:MetadataDate>2012-11-26</inspire_common:MetadataDate>
<inspire_common:SpatialDataServiceType>download</inspire_common:SpatialDataServiceType>
<inspire_common:MandatoryKeyword>
<inspire_common:KeywordValue>infoCoverageAccessService</inspire_common:KeywordValue>
</inspire_common:MandatoryKeyword>
<inspire_common:SupportedLanguages>
<inspire_common:DefaultLanguage>
<inspire_common:Language>eng</inspire_common:Language>
</inspire_common:DefaultLanguage>
</inspire_common:SupportedLanguages>
<inspire_common:ResponseLanguage>
<inspire_common:Language>eng</inspire_common:Language>
</inspire_common:ResponseLanguage>
<inspire_dls:SpatialDataSetIdentifier>
<inspire_common:Code>fc929094-8a30-2617-e044-002128a47908</inspire_common:Code>
</inspire_dls:SpatialDataSetIdentifier>
</inspire_dls:ExtendedCapabilities>
</ows:ExtendedCapabilities>
<int:InterpolationMetadata xmlns:int="http://www.opengis.net/wcs/interpolation/1.0">
<int:InterpolationSupported>
http://www.opengis.net/def/interpolation/OGC/0/nearest-neighbor
</int:InterpolationSupported>
</int:InterpolationMetadata>
</wcs:Extension>

We could also look at going further as per Peter's suggestion, becuase at the moment the extended capabilites section is just there as static metadata for the defined data in ther service whereas I assume with Peter's suggestion we would be talking about native support for languages that the service supports?

 

 

 

 

 

 

 

 

#4 Updated by Peter Baumann almost 5 years ago

ah, I wasn't aware of this existing mechanism (should read OWS Common again). Seeing this I fully agree with your view.

#5 Updated by James Passmore almost 5 years ago

James Passmore wrote:

Does SOS derive its capabilities from OWS common 2.0? if so it also has acceptlanguages=& defined.   

Answqering my own question, the answer here is that it it uses OWS common 1.1.0, and therefore doesn't have acceptlanguages as a defined parameter.

... http://www.opengis.net/spec/SOS/2.0/req/core/gc-ows Requirement 4 The GetCapabilities operation request shall be implemented as specified in Clause 7 of OWS Common [OGC 06-121r3] ...

Also available in: Atom PDF