Draft Technical Guidance for INSPIRE Download Services Web viewTechnical Guidance for spatial data...

INSPIREInfrastructure for Spatial Information in Europe

Technical Guidance for INSPIRE Spatial Data Services and services allowing spatial data services to be invoked

Title Technical Guidance for INSPIRE Spatial Data Services and services allowing spatial data services to be invoked

Creator Network Services Drafting Team, MIG-T

Date of last update 2016-02-12

Subject Technical Guidance for INSPIRE Spatial Data Services and services allowing spatial data services to be invoked

Status Version 3.2rc2 – for review and comments by MIG-P

Open issue: Since this version proposes changes that are not backwards-compatible to version 3.1 (because it is based on the ISO 19139 metadata schemas without any extensions), should the version be 4.0 (instead of 3.2)?

Publisher MIG-T

Type Text

Description This document defines technical guidance for INSPIRE Spatial Data Services and services allowing spatial data services to be invoked

Format MS Word (doc)

Source Network Services Drafting Team, MIG-T

Rights Reuse is authorised, provided the source is acknowledged. The reuse policy of the European Commission is implemented by a Decision of 12 December 2011.

Identifier document.docx

Language EN

Relation Not applicable

Coverage Project duration

http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32011D0833

http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32011D0833

INSPIRE Technical Guidance for spatial data services and services allowing spatial data services to be invoked

2016-02-12 of 84

Table of contentsForeword................................................................................................................................................ 4

1 Introduction...................................................................................................................................... 61.1 The INSPIRE Directive and Implementing Rules.....................................................................61.2 Technical Guidance for INSPIRE Spatial Data Services and services allowing spatial data services to be invoked......................................................................................................................... 61.3 Spatial Data Services – a crucial component for INSPIRE.......................................................7

2 Normative references...................................................................................................................... 8

3 Terms and abbreviations...............................................................................................................103.1 Terms..................................................................................................................................... 103.2 Symbols and abbreviations....................................................................................................113.3 Verbal forms for the expression of provisions.........................................................................113.4 References............................................................................................................................. 12

4 Technical Guidance....................................................................................................................... 144.1 Categories of INSPIRE Spatial Data Services........................................................................144.2 Requirements according to INSPIRE regulations...................................................................16

4.2.1 Requirements for Spatial Data Services......................................................................164.2.2 Requirements for services allowing spatial data services to be invoked.....................174.2.3 Guiding flow chart........................................................................................................174.2.4 Deadlines.................................................................................................................... 19

4.3 Overview and generic requirements.......................................................................................204.3.1 Generic requirements on xPath, multiplicity, data types and code lists.......................224.3.2 Generic requirements on data quality metadata..........................................................234.3.3 Metadata element required by ISO 19119...................................................................23

4.4 Invocable Spatial Data Services.............................................................................................244.4.1 Category...................................................................................................................... 244.4.2 Resource Locator........................................................................................................264.4.3 Specification................................................................................................................28

4.5 Interoperable Spatial Data Services.......................................................................................314.5.1 Coordinate Reference Systems Identifier....................................................................314.5.2 Quality of Service........................................................................................................334.5.3 Conditions applying to access and use.......................................................................384.5.4 Responsible party........................................................................................................43

4.6 Harmonised spatial data services...........................................................................................444.6.1 Invocation metadata....................................................................................................454.6.2 Quality of the Harmonised Spatial Data Service..........................................................51

4.6.2.1 Normalized testing procedure.................................................................................514.6.3 Encoding of the spatial objects in the Spatial Data Service.........................................524.6.4 Operations for Harmonised Spatial Data Services......................................................52

4.6.4.1 Get Harmonised Spatial Data Service Metadata Description.................................534.6.4.2 Scenario 1 – Get Capabilities response – Metadata URL......................................544.6.4.3 Scenario 2 – Get Capabilities response – Metadata replication.............................54

4.7 Services allowing spatial data services to be invoked............................................................544.8 INSPIRE Metadata Codelists.................................................................................................55

4.8.1 Resource locator description.......................................................................................554.8.2 Conditions applying to access and use.......................................................................554.8.3 Spatial data services categories..................................................................................554.8.4 Criteria......................................................................................................................... 56


2016-02-12 of 84

4.8.5 DCP List...................................................................................................................... 564.8.6 Coordinate reference system......................................................................................57

Annex A – Get Harmonized Spatial Data Service Metadata.................................................................58A.1 Get Harmonized Spatial Data Service Metadata Request..........................................................58A.2 Scenario 1 – Get Harmonized Spatial Data Service Metadata Response..................................59A.3 Scenario 2 – Get Harmonized Spatial Data Service Metadata Response..................................60

Annex B – Metadata textual example...................................................................................................64

Annex C – Complete XML Encoding example......................................................................................65

Annex D – WSDL Example................................................................................................................... 76

Annex E – SDS examples.................................................................................................................... 83

Table of TablesTable 1 - Metadata elements mapping. C: conditional (refer to [ INS MD] for the conditions), M:

Mandatory, =: the obligation is the same as specified in [INS MD]...................................20Table 2 - SV_OperationMetadata detail................................................................................................47Table 3 - SV_Parameter detail..............................................................................................................47Table 4 - Get Harmonized Spatial Data Service Metadata request......................................................59

Table of FiguresFigure 1 - relationship between the INSPIRE Implementing Rules and the associated Technical

Guidance............................................................................................................................ 5Figure 2: Guidance to understand if a spatial data services is in or out of scope of INSPIRE..............15Figure 3 - Spatial data services in the context of INSPIRE and their relationships to different types and

categories of services.......................................................................................................16Figure 4 - Metadata required for SDS...................................................................................................17Figure 5 - Flow chart illustrating the obligations for spatial data services.............................................18


2016-02-12 of 84

ForewordDirective 2007/2/EC of the European Parliament and of the Council [INS DIR], adopted on 14 March 2007 aims at establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) for environmental policies, or policies and activities that have an impact on the environment. INSPIRE will make available relevant, harmonised and quality geographic information to support the formulation, implementation, monitoring and evaluation of policies and activities, which have a direct or indirect impact on the environment.

INSPIRE is based on the infrastructures for spatial information established and operated by the 27 Member States of the European Union. The Directive addresses 34 spatial data themes needed for environmental applications, with key components specified through technical implementing rules. This makes INSPIRE a unique example of a legislative “regional” approach.

To ensure that the spatial data infrastructures of the Member States are compatible and usable in a Community and trans-boundary context, the Directive requires that common Implementing Rules (IR) are adopted in the following areas.

Metadata; The interoperability and harmonisation of spatial data and services for selected themes (as

described in Annexes I, II, III of the Directive); Network Services; Measures on sharing spatial data and services; Co-ordination and monitoring measures.

The Implementing Rules are adopted as Commission Decisions or Regulations, and are binding in their entirety.

In particular with respect the Network Services, Implementing Rules are required for the following services (Article 11(1) of the Directive):

a) “discovery services search for spatial datasets and spatial data services on the basis of the content of corresponding metadata, and display the metadata content;

b) view services as a minimum, display, navigate, zoom in/out, pan, or overlay spatial datasets and display legend information and any relevant content of metadata;

c) download services enabling copies of complete spatial datasets, or of parts of such sets, to be downloaded;

d) transformation services enabling spatial datasets to be transformed with a view to achieving interoperability;

e) invoke spatial data services "enabling data services to be invoked.”

In addition to the Implementing Rules, non-binding Technical Guidance documents describe detailed implementation aspects and relations with existing standards, technologies, and practices. They may need to be revised during the course of implementing the infrastructure to take into account the evolution of technology, new requirements, and cost benefit considerations. Figure 1 illustrates the relationship between the INSPIRE Regulations containing Implementing Rules and their corresponding Technical Guidance documents.


2016-02-12 of 84

Figure 1 - relationship between the INSPIRE Implementing Rules and the associated Technical Guidance.

Technical Guidance documents define how Member States might implement the Implementing Rules described in a Commission Regulation. Technical Guidance documents may include non-binding technical requirements that must be satisfied if a Member State chooses to conform to the Technical Guidance. Implementing this technical guidance will maximise the interoperability of INSPIRE services.

This Technical Guidance relates to the INSPIRE Spatial Data Services and services allowing spatial data services to be invoked. The Technical Guidance contains detailed technical documentation highlighting the mandatory and the recommended elements related to the implementation of INSPIRE Spatial Data Services and services allowing spatial data services to be invoked. The technical provisions and the underlying concepts are often illustrated by use case diagrams and accompanied by examples.

Many of the examples in this document refer to a real service; the description of the spatial data service used in the document is provided in Annex G.

DisclaimerThis document has been developed collaboratively through the INSPIRE maintenance and implementation framework, involving the European Commission, European Environment Agency, EU Member States, the Accession and EFTA Countries. The document should be regarded as presenting an informal consensus position on best practice agreed by all partners. However, the document does not necessarily represent the official, formal position of any of the partners. Hence, the views expressed in the document do not necessarily represent the views of the European Commission.


2016-02-12 of 84

1 Introduction

1.1 The INSPIRE Directive and Implementing RulesDirective 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) was published in the official Journal on the 25th April 2007. The INSPIRE Directive entered into force on the 15th May 2007.

The purpose of the infrastructure is to enable the formulation, implementation, monitoring activities and evaluation of Community environmental policies at all levels – European, national and local – and to provide public information.

INSPIRE builds on the infrastructures for spatial information that have already been created by the Member States. The components of those infrastructures include: metadata, spatial data themes (as described in Annexes I, II, III of the Directive), network services and technologies; agreements on data sharing, access and use; coordination and monitoring mechanisms, processes and procedures.

The guiding principles of INSPIRE are:

that the infrastructures for spatial information in the Member States should be designed to ensure that spatial data are stored, made available and maintained at the most appropriate level;

that it is possible to combine spatial data from different sources across the Community in a consistent way and share them between several users and applications;

that it is possible for spatial data collected at one level of public authority to be shared between all the different levels of public authorities;

that spatial data are made available under conditions that do not restrict their extensive use; and,

that it is easy to discover available spatial data, to evaluate their fitness for purpose and to know the conditions applicable to their use.

The text of the INSPIRE Directive is available from the European Union Law website (EU-LEX) http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32007L0002:EN:NOT . The Directive identifies what needs to be achieved, and Member States have two years from the date of adoption to bring into force national legislation, regulations, and administrative procedures that define how the agreed objectives will be met taking into account the specific situation of each Member State. To ensure that the spatial data infrastructures of the Member States are compatible and usable in a Community and trans-boundary context, the Directive requires that common Implementing Rules (IR) are adopted in a number of specific areas. Implementing Rules are adopted as Commission Decisions, and are binding in their entirety.

According to Article 5(4) of the Directive, the INSPIRE Implementing Rules shall take account of relevant, existing international standards and user requirements.

1.2 Technical Guidance for INSPIRE Spatial Data Services and services allowing spatial data services to be invoked

The scope of this document is to detail the INSPIRE technical requirements for Spatial Data Services and services allowing spatial data services to be invoked from the Implementing Rules, such that these services can be implemented consistently across Europe.

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32007L0002:EN:NOT


2016-02-12 of 84

These Implementing Rules are, as much as possible, in conformance with European and international standards, current practices in stakeholder communities and relevant European initiatives such as e-Government, and the EU interoperability framework.

NOTE It is planned to integrate the metadata-related aspects of this document into the updated version of the INSPIRE Technical Guidelines for metadata, that is currently under preparation by the MIG sub-group MIWP-8.

This technical guidance document relates to developed services relating to harmonised spatial data sets and will not apply to the already specified INSPIRE Network Service.

1.3 Spatial Data Services – a crucial component for INSPIRESpatial data services are services that do not provide the “standard” functionalities for viewing, downloading or transforming spatial data as are offered by network services. They provide added value to users and are therefore usually tailored to a specific application domain. While they are therefore quite diverse, it will be crucial to make them available in the INSPIRE infrastructure – at least by describing them with standardised metadata – in order to allow end users and software developers to integrate the INSPIRE data in their web, mobile and desktop applications.

The following examples of SDS shall illustrate possible scenarios:

IGN-Spain has developed a Web Processing Service (WPS). It offers a web processing utility based on pre-programmed calculations that operate on georeferenced information. Routes and influence areas calculating processes have been implemented. The service complies with the WPS 1.0.0 standard. This open and free service has not only created to be used in the IGN viewer but also for any institution, public or private needing calculate routes or influenced areas, for web or desktop applications.

Similarly, the Spanish Cadastre Agency is providing services for obtaining the provinces of a region, the municipalities of a province, the street of a municipality, the coordinates of a cadastral parcel etc.

SDS produced by the Czech Mapping and Cadastre Authorities are mainly driven by e-governmental activities. As a result, the SDS that are linked with cadastral information (parcels, buildings, addresses and administrative units) are available on-line and free of charge. The demand on SDS for viewing the data, which are available already since 2007, is enormous, and these SDS are used by many (external and internal) applications. Also SDS for downloading the data are expected to be well requested once the data according to the Buildings theme has become available.


2016-02-12 of 84

2 Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

INS DIR Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE), OJ L 108, 24.4.2007, p. 1

INS MD Commission Regulation (EC) No 1205/2008 of 3 December 2008 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata (Text with EEA relevance), OJ L 326, 4.12.2008, p. 12

INS ISDSS Commission Regulation (EU) No 1089/2010 of 23 November 2010 Implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services as amended by Commission Regulation (EU) No 1312/2014 of 10 December 2014, OJ L 354, 11.12.2014, p. 8–16

INS NS Commission Regulation (EU) No 976/2009 of 19 October 2009 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards the Network Services as amended by Commission Regulation (EU) No 1311/2014 of 10 December 2014, OJ L 354, 11.12.2014, p. 6–7

INS NS TG Technical Guidance for the implementation of INSPIRE Download Services, v3.1 (http://inspire.jrc.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_Services_v3.1.pdf)

INS MD TG INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119, v1.3 (http://inspire.ec.europa.eu/documents/Metadata/MD_IR_and_ISO_20131029.pdf)

DC DS Common document collection provided for all INSPIRE Data Specificationshttp://inspire.jrc.ec.europa.eu/index.cfm/pageid/2

OGC WS OGC Web Services Common Standardhttp://portal.opengeospatial.org/files/?artifact_id=38867

ISO 19115 ISO 19115:2003/Cor 1:2006, Geographic information – Metadata – Part 1: Fundamentalshttp://www.iso.org/iso/catalogue_detail.htm?csnumber=26020

ISO 19119 ISO 19119:2005/Amd 1:2008, Geographic information – Serviceshttp://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=44268

ISO 19139 ISO/TS 19139:2007, Geographic information – Metadata – XML schema implementationhttp://www.iso.org/iso/catalogue_detail.htm?csnumber=32557

ISO 19108 ISO 19108:2002/Cor 1:2006, Geographic information - Temporal schemahttp://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=44883

ISO 19111 ISO 19111:2007, Geographic information - Spatial referencing by coordinates

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=44883


http://www.iso.org/iso/catalogue_detail.htm?csnumber=32557



http://www.iso.org/iso/catalogue_detail.htm?csnumber=26020

http://portal.opengeospatial.org/files/?artifact_id=38867

http://inspire.jrc.ec.europa.eu/index.cfm/pageid/2

http://inspire.jrc.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_Services_v3.1.pdf

http://inspire.jrc.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_Services_v3.1.pdf


2016-02-12 of 84


ISO 19118 ISO 19118:2011Geographic information – Encodinghttp://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=44212

ISO 19127 ISO/TS 19127:2005, Geographic information - Geodetic codes and parametershttp://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=41784



http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=44212

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=44212




2016-02-12 of 84

3 Terms and abbreviations

3.1 Terms(1) Access point: an internet address containing a detailed description of a spatial data service,

including a list of endpoints to allow its execution.

(2) End point: the Internet address used to directly call an operation provided by a spatial data service.

(3) Spatial data services means the operations which may be performed, by invoking a computer application, on the spatial data contained in spatial data sets or on the related metadata [INS DIR, Art. 3].

(4) Network services are services provided for in Article 11(1) of [INS DIR] for the discovery, viewing, download and transformation of spatial data sets and services. The service shall be conformant regarding the specific requirements in Commission Regulation (EC) 976/2009.

NOTE In [INS DIR, Art. 11] also a 5th type of network service is defined: “services allowing spatial data services to be invoked”. Since all services can be invoked when metadata is published and accessed through a discovery service, there is no need to have a special service to invoke other services. Instead the discovery service will take the role as making it possible to invoke a service. (see also section 4.2.2).

(5) Discovery service is a service that makes it possible to search for spatial data sets and services on the basis of the content of the corresponding metadata and to display the content of the metadata [INS DIR, Art. 11].

(6) View service is a service making it possible, as a minimum, to display, navigate, zoom in/out, pan, or overlay viewable spatial data sets and to display legend information and any relevant content of metadata [INS DIR, Art. 11].

(7) Download service is a service enabling copies of spatial data sets, or parts of such sets, to be downloaded and, where practicable, accessed directly [INS DIR, Art. 11].

(8) Transformation service is a service enabling spatial data sets to be transformed with a view to achieving interoperability [INS DIR, Art. 11].

(9) Invocable spatial data service is a spatial data service that (a) has metadata which fulfils the requirements of Commission Regulation (EC) 1205/2008, (b) has at least one resource locator that is an access point, (c) is conformant with a documented and publicly available set of technical specifications providing the information necessary for its execution. [INS ISDSS, Art. 2.33]

NOTE The technical specifications could e.g. be a web site documentation explaining how to use the service, or they could be more formal, e.g. a WSDL document or a description of a RESTful interface.

(10) Interoperable spatial data service means an invocable spatial data service which fulfils the requirements of Annex VI of [INS ISDSS]. [INS ISDSS, Art. 2.34]

(11) Harmonised spatial data service means an interoperable spatial data service which fulfils the requirements of Annex VII of [INS ISDSS]. [INS ISDSS, Art. 2.35]

(12) Conformant spatial data set means a spatial data set in conformity with Commission Regula-tion (EU) No 1089/2010. [INS ISDSS, Art. 2.36]


2016-02-12 of 84

(13) Interface: named set of operations that characterise the behaviour of an entity as defined by ISO 19119:2005. [INS ISDSS, Art. 2.38]

(14) Operation: means an action supported by a spatial data service. [INS ISDSS, Art. 2.37]

(15) Resource locator: The resource locator defines the link(s) to the resource and/or the link to additional information about the resource. The value domain of this metadata element is a character string, commonly expressed as uniform resource locator (URL). [INS MD, Annex, Part B 1.4].

3.2 Symbols and abbreviationsDT Drafting Team

MD Metadata

NS Network Services

ISO International Organization for Standardization1

OGC Open Geospatial Consortium2

QoS Quality of Service

SDS Spatial Data Services

ISDSS Interoperability of spatial data services

SOAP Simple Object Access Protocol3

MS Member state

URL Uniform Resource Locator

WSDL Web Services Description Language4

XSD XML Schema Definition

3.3 Verbal forms for the expression of provisionsIn accordance with the ISO rules for drafting, the following verbal forms shall be interpreted in the given way:

“shall” / “shall not”: a requirement, mandatory to comply with the technical guidance “should” / “should not”: a recommendation, but an alternative approach may be chosen for a

specific case if there are reasons to do so

1 http://www.iso.org/iso/home.htm2 http :// www . opengeospatial . org / ogc 3 http://www.w3.org/TR/soap124 http://www.w3.org/TR/wsdl

http://www.w3.org/TR/wsdl

http://www.w3.org/TR/soap12

http://www.opengeospatial.org/ogc









http://www.iso.org/iso/home.htm


2016-02-12 of 84

“may” / “need not”: a permission

Technical Guidance Conformance Classes notation

The Technical Guidance in this document is divided into Conformance Classes, so that it is possible to declare conformance to specific parts of the Technical Guidance. To conform to a Conformance Class it is necessary to meet all of the Requirements (see next section) in that Conformance Class.

Conformance Classes are identified in the document as follows:

TG Conformance Class #: [TITLE] conformance classes are shown using this style

Technical Guidance Requirements and Recommendations notation

Requirements and the recommendations for INSPIRE Spatial Data Services and services allowing spatial data services to be invoked within this technical guidance are highlighted and numbered as shown below:

TG Requirement # requirements are shown using this style

TG Recommendation # recommendations are shown using this style.

Requirements and recommendations belong to the conformance class in which they are found in this document.

Note: It is worth noting that requirements as specified in the INSPIRE Regulations and Implementing Rules are legally binding, and that requirements and recommendations as specified in INSPIRE Technical Guidance are not legally binding. Therefore, within this technical guidance we have used the terms ‘TG requirement’ and ‘TG recommendation’ to indicate what is technically required or recommended to conform to the Technical Guidance.

XML Example notation

XML Examples are shown using Courier New on a grey background with yellow for emphasis as below:

<inspire:example><inspire:highlight>Highlighted Text for emphasis

</inspire:highlight></inspire:example>Note: XML Examples are informative and are provided for information only and are expressly not normative.

3.4 ReferencesReferences within this document are denoted using “Section” or “Annex”. For example, Section 5.3.1 or Annex A.

References to other documents refer to the list of normative references in Section 1.1 and use the abbreviated title as indicated in Bold text. For example, [INS NS] uses the abbreviated title for the document as shown below:


2016-02-12 of 84

Commission Regulation (EU) No 976/2009 of 19 October 2009 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards the Network Services. OJ L 274, 20.10.2009, p. 9

References within other documents are shown as above using the reference code, together with the appropriate section within the document. For example, [INS NS, Section 2.2.3], refers to Section 2.2.3 within the document as listed above.


2016-02-12 of 84

4 Technical GuidanceThis section includes guidance related to categories of SDS (section 4.1), requirements from the different INSPIRE Implementing Rules and the Directive (section 4.2) and instructions on meeting the requirements for SDS included in [INS ISDSS] (sections 4.3 to 4.6) and for services allowing SDS to be invoked (section 4.7).

The technical guidance for the requirements included in [INS ISDSS] are structured according to conformance classes. The conformance classes for invocable SDS (section 4.4) and interoperable SDS (section 4.5) include only requirements on the creation of additional metadata. The conformance class for harmonised SDS includes requirements related to metadata, quality of service, output encoding and the Get Harmonised Spatial Data Service Metadata Operation

4.1 Categories of INSPIRE Spatial Data Services The spatial data services covered by the INSPIRE Directive are defined in Art. 4(3) as follows:

“This Directive shall also cover the spatial data services relating to the data contained in the spatial data sets referred to in paragraph 1.”

This means, the Directive covers all SDS that relate to INSPIRE-relevant data as defined in Art. 4(1) of [INS DIR]. In addition, an SDS could also include other data.

According to Art. 5(1) of [INS DIR], all SDSs within INSPIRE shall be described with metadata in conformity with [INS MD]. Furthermore, all SDS shall meet the requirements for data and service sharing laid down in Art. 17 of [INS DIR].

The SDSs that Member States establish and operate according to Art. 11 of [ INS DIR] are called network services. All network services are shall meet the requirements specified in [INS NS].

Those SDS that are not network services and that have at least one resource locator and follow a publicly available technical specification are called invocable spatial data services. All invocable SDS shall meet the requirements specified in [INS ISDSS]. All other SDS are referred to in this document as other SDS.

The flowchart in Figure 3 provides guidance for distinguishing services that are not within the scope of INSPIRE, network services, invocable SDS and other SDS.


2016-02-12 of 84

Does it correspond to INSPIRE data and have a resource locator?

Is it conformant or should it be conformantto Regulation (EC) No 976/2009?

no

no

no

yes

yes

yes

It is an SDS

It is a Network service

It is an Invocable SDS

I have a service that operate on spatial data

It is an other SDSIs the service invocable?

According to the ISDSS Regulation, an SDS is invocable if it• fulfils the requirements of

Commission Regulation (EC) No 1205/2008

• has at least one resource locator that is an access point

• is conformant with a documented and publicly available set of technical specifications providing the information necessary for its execution

The service is not within the scope of INSPIRE

Figure 2: Guidance to understand if a spatial data services is in or out of scope of INSPIRE

SDS regulated by [INS ISDSS] are further divided into three different categories depending on level of interoperability: Invocable SDS, Interoperable SDS and Harmonised SDS. SDS regulated by [ INS NS] consist of four different types of services: discovery services, view services, download services and transformation services.

Figure 3 gives an overview of the different types of spatial data services.


2016-02-12 of 84

Figure 3 - Spatial data services in the context of INSPIRE and their relationships to different types and categories of services.

4.2 Requirements according to INSPIRE regulations

4.2.1 Requirements for Spatial Data Services

For the spatial data sets and services for which metadata have been created, member states shall establish and operate at least one (but may decide to establish and operate more than one) of each type of network service defined in [INS DIR, Art. 11] for discovery, view, download and, if necessary, transformation.

Transformation services are not mandatory to implement as long as “spatial data sets are made available in conformity with the implementing rules [for data interoperability] through the adaptation of existing spatial data sets” [INS DIR, Art. 7(3)], i.e. if they are transformed into the INSPIRE data models through some other means (e.g. offline transformation or on-the-fly transformation in the download service).

These services shall follow the requirements of [INS NS].

All spatial data services, including network services, shall have metadata according to [ INS MD]. Furthermore, Member States need to adopt measures for data sharing for all spatial data services according to [INS DIR, Art. 17].

Invocable spatial data services, which have a technical specification providing information necessary for its execution (e.g. an API description), shall also have additional metadata as described in Annex V and VI and, where practicable, meet the requirements related to metadata, quality of service, output encoding and the Get Harmonised Spatial Data Service Metadata Operation that are described in Annex VII of [INS ISDSS].

NOTE 1 These additional requirements do not have to be met by network services, as clarified by [INS ISDSS] ("This Regulation does not apply to the network services falling within the scope of Commission Regulation (EC) 976/2009").

The requirements related to metadata are illustrated in Figure 4.


2016-02-12 of 84

SDS regulated by IR Network Services

Discoveryservices

Viewservices

Downloadservices

Transformationservices

Spatial Data Services (SDS)

Invocable Spatial Data Services

InteroperableSpatial Data Services

Harmonised Spatial Data Services

SDS regulated by IR Interoperability Other SDS

Additional metadata according to Annex V of [INS ISDSS]

Additional metadata according to Annex VI of [INS ISDSS]

(Where practicable) additional metadata according to Annex VII of [INS ISDSS]

Metadata according to [INS MD]

Figure 4 - Metadata required for SDS

4.2.2 Requirements for services allowing spatial data services to be invoked

No specific Implementing Rules exist in INSPIRE that specify requirements for “services allowing spatial data services to be invoked” as defined in [INS DIR, Art. 11(1.e)].

However, in the latest amendment of [INS NS] (Commission Regulation (EU) No 1311/2014 of 10 December 2014), the definition of “INSPIRE metadata element” is extended beyond the metadata elements defined in [INS MD] to include also the metadata elements defined in Annexes V-VII of [INS ISDSS].

This means that discovery network services need to provide access also to the additional SDS metadata elements, which contain, among other things, information necessary for the invocation of SDS. Through the provision of these additional elements, the obligation to provide (network) “services allowing spatial data services to be invoked” is being fulfilled.

4.2.3 Guiding flow chart

In the INSPIRE scope it is required to set up Network services to be able to discover, view, download and, if necessary, transform data that is described in [INS DIR, Annexes I-III]. Specific regulations are published for setting up these services. But since other spatial data services can be of broad variation there is no detailed description. To support the understanding of SDS and its requirements the flow chart in Figure 5 can be used.

At the starting point there is an existing service already, it could be a service that was not initially intended as an INSPIRE service when it was set up.


2016-02-12 of 84

Figure 5 - Flow chart illustrating the obligations for spatial data services


2016-02-12 of 84

4.2.4 Deadlines

As for harmonisation of data sets, the fulfilments of the requirements for invocable spatial data services are done step-wise.

15-May-2009

Member States shall adopt measures for the sharing of spatial data sets and service, in accordance with [INS DIR, Art. 17].

03-Dec-2010

Metadata according to [INS MD] shall be available for spatial data services corresponding to Annex I and II themes

09-Nov-2011

Metadata for SDS shall be provided through INSPIRE discovery services, in accordance with [INS NS]

03-Dec-2013

Metadata according to [INS MD] shall be available for spatial data services corresponding to Annex III themes

10-Dec-2015

All invocable spatial data services shall be conformant to Annex V of [INS ISDSS]

10-Dec-2016

Invocable spatial data services related to newly collected and extensively restructured spatial data sets shall be conformant with Annex VI and, where practicable, Annex VII of [INS ISDSS]

10-Dec-2021

All invocable spatial data services shall be conformant with Annexes VI and (where practicable) VII of [INS ISDSS]

NOTE Also the additional metadata that has to be provided for SDS under [INS ISDSS] shall be provided through INSPIRE discovery services, in accordance with [INS NS]


2016-02-12 of 84

4.3 Overview and generic requirementsTable 1 shows the requirements to provide different metadata elements for the different spatial data services conformance classes.

For each metadata element that is not already included in [ INS MD] or for which there are additional requirements, the table contains a reference to the section describing the detailed requirements.

Table 1 - Metadata elements mapping. C: conditional (refer to [INS MD] for the conditions), M: Mandatory, =: the obligation is the same as specified in [INS MD]

Inspire Metadata element Reference to INSPIRE IRs All SDS Invocable

SDSInteroperable

SDSHarmonised

SDS

Resource title [INS MD, Annex B1.1] M = = =

Resource abstract [INS MD, Annex B1.2] M = = =

Resource Type [INS MD, Annex B1.3] M = = =

Resource Locator

[INS MD, Annex B1.4]

[INS ISDSS, Annex V D1]

C M (4.4.2) M (4.4.2) M (4.4.2)

Coupled Resource [INS MD, Annex B1.6] C = = =

Spatial data service type [INS MD, Annex B2.2] M = = =

Keyword value [INS MD, Annex B3.1] M = = =

Geographic Bounding Box [INS MD, Annex B4.1] C = = =

Temporal extent [INS MD, Annex B5.1] C = = =

Date of publication [INS MD, Annex B5.2] C = = =

Date of last revision [INS MD, Annex B5.3] C = = =

Date of creation [INS MD, Annex B5.4] C = = =

Spatial Resolution [INS MD, Annex B6.2] C = = =

Specification



M M (4.4.3) M (4.4.3) M (4.4.3)


2016-02-12 of 84

Inspire Metadata element Reference to INSPIRE IRs All SDS Invocable

SDSInteroperable

SDSHarmonised

SDS

Degree



M M (4.4.3) M (4.4.3) M (4.4.3)

Conditions applying to access and use


[INS ISDSS, Annex VI A1]

M = M(4.5.3) M(4.5.3)

Limitations on public access [INS MD, Annex B8.2] M = = =

Responsible party


[INS ISDSS, Annex VI A2]

M = M (4.5.4) M (4.5.4)

Responsible party role


[INS ISDSS, Annex VI A2

M = M (4.5.4) M (4.5.4)

Metadata point of contact [INS MD, Annex B10.1] M = = =

Metadata Date [INS MD, Annex B10.2] M = = =

Metadata Language [INS MD, Annex B10.3] M = = =

Category [INS ISDSS, Annex V B1] M (4.4.1) M (4.4.1) M (4.4.1)

Coordinate Reference System [INS ISDSS, Annex VI B3] M (4.5.1) M (4.5.1)

Quality of Service - Criteria [INS ISDSS, Annex VI B4.1] M (4.5.2) M (4.5.2)

Quality of Service - Measurement

[INS ISDSS, Annex VI B4.2] M (4.5.2) M (4.5.2)

Invocation metadata [INS ISDSS, Annex VII B3] M (4.6.1)

As explained above, all SDS shall have metadata which fulfils the requirements of [INS MD TG]. The availability of such [INS MD TG]-compliant metadata is assumed, but since the corresponding requirements, mapping rules and metadata elements are already detailed in [INS MD TG], they are not repeated in this TG.

In the following paragraphs you can find the details of the new or extended metadata elements, including a specific encoding example. For details on the other elements, please refer to [INS MD TG].

The requirements are structured in three conformance classes, according to the three categories of SDS.


2016-02-12 of 84

The following generic requirements hold for all metadata elements described in this document. In addition to these generic requirements, some conformance classes contain additional requirements.

4.3.1 Generic requirements on xPath, multiplicity, data types and code lists

TG Requirement 1 Each metadata element shall be present in the metadata document at the XPath defined in the table for that element and shall match the INSPIRE multiplicity of the metadata element, unless the element is conditional and the condition does not hold.

TG Requirement 2 Each metadata element shall use the data type or code list specified in the table for that element.

Section 4.8 includes the value domains (code lists) to be used for the INSPIRE metadata elements described in this technical guidance. For every code list, each value is defined by:

a numerical identifier (No. ID), if any, corresponding, in most cases, to the numerical identifier defined in [INS MD] or to ISO domain code;

a textual name; a language neutral name, if any; an optional definition/description; an URI identifier

TG Requirement 3 Where these technical guidance requires a textual metadata element to be filled with a value from one of these code lists, either the language-neutral name or a combination of the language-neutral name and a xlink:href reference to the URI identifier from the INSPIRE registry (using gmx:Anchor) shall be used.

EXAMPLE 1 Implementation using only the language-neutral name

<gmd:title><gco:CharacterString>invocable</gco:CharacterString>

</gmd:title>

EXAMPLE 2 Implementation using a combination of the language-neutral name and a reference to the http URI identifier from the INSPIRE registry

<gmd:title><gmx:Anchor xlink:href=" http://inspire.ec.europa.eu/metadata-

codelist/Category/invocable">invocable</gmx:Anchor></gmd:title>


2016-02-12 of 84

Open issue: Is there the need to also include requirements and examples for the encoding of code lists coming from [ISO 19115] and [ISO 19119]?

For example, the following example from [ISO 19139], adapted for the new (official?) location of the ISO 19139 code list catalogue (http://standards.iso.org/iso/19139/resources/codelist/):

EXAMPLE 5 Here is a full instance of CI_DateTypeCode expressed in the default language of the metadata (e.g. English):

<CI_DateTypeCode codeList="http://standards.iso.org/iso/19139/resources/codelist/gmxCodelists.xml#CI_DateTypeCode" codeListValue="creation">Creation</CI_DateTypeCode>

Note that currently, the URI http://standards.iso.org/iso/19139/resources/codelist/ does not resolve. We have contacted ISO/TC 211 about this, but have not yet received an answer.

What to do with code lists from [ISO 19119] that are not included in the ISO 19139 code list catalogue, e.g. DCPlist?

An alternative solution could be to add the ISO code lists to the INSPIRE registry and use the http URIs instead, e.g.

<CI_DateTypeCode codeList="http://inspire.ec.europa.eu/metadata-codelist/DateType" codeListValue="http://inspire.ec.europa.eu/metadata-codelist/DateType/creation">Creation</CI_DateTypeCode>

4.3.2 Generic requirements on data quality metadata

The dataQualityInfo element is used for the implementation of several INSPIRE metadata elements. A single ISO 19115/19119 metadata set may comprise more than one dataQualityInfo element.

TG Requirement 4 For each spatial data service, there shall be one and only one set of quality information (dataQualityInfo element) scoped to “service”.

4.3.3 Metadata element required by ISO 19119

In addition to the metadata elements required by INSPIRE, the containsOperation metadata element is required to be compliant with [ISO 19119]. According to [INS MD TG], this element is not required for all SDS; it becomes conditional only for harmonised SDS to provide invocation metadata (as indicated in the table above and further specified section 4.6.1). For all the other conformance classes (invocable and interoperable spatial data services) this element is optional. If there is no data to fill it, it should be filled with the gco:nilReason element; you can find an encoding example below (taken from [INS MD TG, Section A.12.3.2]):

<srv:containsOperations gco:nilReason="missing"/>

http://standards.iso.org/iso/19139/resources/codelist/

http://standards.iso.org/iso/19139/resources/codelist/


2016-02-12 of 84

4.4 Invocable Spatial Data Services

TG Conformance Class 1: Implementation of Invocable Spatial Data Services

This conformance class is inclusive of:

TG Requirement 1 to TG Requirement 8

TG Recommendation 1 to TG Recommendation 3

TG Requirement 5 If a spatial data service (a) has metadata which fulfils the requirements of [INS MD], (b) has at least one resource locator that is an access point, and (c) is conformant with a documented and publicly available set of technical specifications providing the information necessary for its execution, the metadata document for the spatial data service shall include the metadata elements and meet the additional requirements for metadata elements specified in this section.

4.4.1 Category

[INS ISDSS] requires a Category metadata element containing a citation of the status of the spatial data service versus invocability.

The Category metadata element is implemented using the specification and pass sub-element of the DQ_ConformanceResult from [ISO 19115].

TG Recommendation 1 In order to be machine-readable, the specification metadata element should be provided using the gmx:Anchor element.

TG Requirement 6 The value of the pass element shall be set to true.

Metadata element name Category

Reference COMMISSION REGULATION (EU) No 1089/2010, Annex V, Part B 1

Definition Citation of the product specification or user requirement against which data is being evaluated

ISO 19115 number and name 130. specification

ISO/TS 19139 path dataQualityInfo/*/report/*/result/*/specification

INSPIRE obligation / condition Mandatory for invocable spatial data services

INSPIRE multiplicity [1]NOTE 1 The multiplicity is specified as [0..1] in [INS ISDSS], with the condition: “mandatory for an invocable spatial data service”. Since the metadata element is only required for invocable SDS, the multiplicity is factually [1].


2016-02-12 of 84

NOTE 2 Since the multiplicity is [1], only the most comprehensive category should be documented, e.g. interoperable (implying that also the invocable conformance class is met).NOTE 3 The INSPIRE multiplicity refers to the Category metadata element. This does not affect the fact that in ISO 19115 more than one conformity statement is allowed.

Data type (and ISO 19115 no.) 359. CI_Citation

Domain For the title sub-element, the values of the Category code list (sec-tion 4.8.3) shall be used.

NOTE [ISO 19115] requires a date for the specification. For consistency, it is recommended to use the date of publication of the [INS ISDSS], i.e. 2014-12-11.

Example CI_Citation title: invocable (http://inspire.ec.europa.eu/metadata-

codelist/Category/ invocable ) CI_Date

o date: 2014-12-11o type: publication

Comments

Example of XML encoding:

<gmd:dataQualityInfo> <gmd:DQ_DataQuality>

<gmd:scope><gmd:DQ_Scope>

<gmd:level><gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/re-

sources/Codelist/gmxCodelists.xml#MD_ScopeCode" codeListValue="service"/></gmd:level>

</gmd:DQ_Scope></gmd:scope>...<gmd:report>

<gmd:DQ_DomainConsistency><gmd:result>

<gmd:DQ_ConformanceResult><gmd:specification>

<gmd:CI_Citation><gmd:title>

<gmx:Anchor xlink:href=" http://inspire.ec.eu-ropa.eu/metadata-codelist/Category/invocable">invocable</gmx:Anchor>

</gmd:title><gmd:date>

<gmd:CI_Date><gmd:date>

<gco:Date>2014-12-11</gco:Date></gmd:date><gmd:dateType>

<gmd:CI_DateTypeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml #CI_DateTypeCode" codeListValue="publication"/>

http://inspire.ec.europa.eu/metadata-codelist/Category/invocable



2016-02-12 of 84

</gmd:dateType></gmd:CI_Date>

</gmd:date></gmd:CI_Citation>

</gmd:specification><gmd:explanation>

<gco:CharacterString>Conformant to the conformance class "invocable SDS"</gco:CharacterString>

</gmd:explanation><gmd:pass>

<gco:Boolean>true</gco:Boolean></gmd:pass>

</gmd:DQ_ConformanceResult></gmd:result>

</gmd:DQ_DomainConsistency></gmd:report>

...</gmd:DQ_DataQuality>

</gmd:dataQualityInfo>

4.4.2 Resource Locator

[INS MD] requires a resource locator to be provided “if linkage to the service is available”.

[INS ISDSS] requires that the resource locator metadata element also contains all access points from the spatial data service provider, and these access points shall be unambiguously identified as such. This information, that a resource locator represents an access point, is provided through the description element.

TG Requirement 7 There shall be at least one Resource Locator metadata element that contains a locator that is identified as an access point, by providing the value “accessPoint” in the description element of the CI_OnlineResource containing the resource locator.

TG Recommendation 2 In order to be machine readable, the description metadata element shall be provided using the gmx:Anchor element.

Metadata element name Resource locator

Reference COMMISSION REGULATION (EU) No 1089/2010, Annex V, Part D 1

Definition Location (address) for on-line access using a Uniform Resource Locator address or similar addressing scheme

ISO 19115 number and name 397. linkage

ISO/TS 19139 path distributionInfo/*/transferOptions/*/onLine/*/linkage


INSPIRE multiplicity [1..*]

Data type (and ISO 19115 no.) URL


2016-02-12 of 84

Domain URL (IETF RFC1738 and IETF RFC 2056)

Example http://www.dinoservices.nl/geo3dmodelwebservices-1/Geo3DModelService

Comments

Metadata element name Resource locator description


Definition Detailed text description of what the online resource is/does

ISO 19115 number and name 401. description

ISO/TS 19139 path distributionInfo/*/transferOptions/*/onLine/*/description


INSPIRE multiplicity [1]

Data type (and ISO 19115 no.) Free text

Domain Resource locator description code list (4.8.1)

Example accessPoint (http://inspire.ec.europa.eu/metadata-codelist/ResourceLocatorDescription/accessPoint)

Comments


<gmd:MD_Metadata …… <gmd:distributionInfo> <gmd:MD_Distribution> … <gmd:transferOptions> <gmd:MD_DigitalTransferOptions> <gmd:onLine> <gmd:CI_OnlineResource> <gmd:linkage> <gmd:URL>http://www.dinoservices.nl:80/geo3dmodelwebservices-1/Geo3DModelService?wsdl</gmd:URL> </gmd:linkage> <gmd:description>

<gmx:Anchor xlink:href="http://inspire.ec.europa.eu/re-gistry/metadata-codelist/ResourceLocatorDescription/accessPoint">access-Point</gmx:Anchor>

</gmd:description> <gmd:function>

<gmd:CI_OnLineFunctionCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml #CI_OnLineFunc-tionCode" codeListValue="information"></gmd:CI_OnLineFunctionCode>

</gmd:function> </gmd:CI_OnlineResource> </gmd:onLine>

http://inspire.ec.europa.eu/metadata-codelist/ResourceLocatorDescription/accessPoint



2016-02-12 of 84

</gmd:MD_DigitalTransferOptions> </gmd:transferOptions> </gmd:MD_Distribution> </gmd:distributionInfo>…</gmd:MD_Metadata>

4.4.3 Specification

[INS ISDSS] requires that the Specification metadata element refer to or contain technical specifications (such as INSPIRE technical guidance but not only), to which the invocable spatial data service fully conforms, providing all the necessary technical elements (human, and wherever relevant, machine readable) to allow its invocation.

The specification metadata element needs to provide sufficient information to actually invoke the service and enable its usage. If the Specification metadata element does not refer to or contain at least one technical specification to which the invocable spatial data service fully conforms, providing all the necessary technical elements, the service is not an invocable spatial data service.

TG Requirement 8 The Specification metadata element shall at least refer to or contain one technical specification to which the invocable spatial data service fully conforms, providing all the necessary technical elements, to actually invoke the service and enable its usage.

TG Recommendation 3 In order to be machine readable, the specification title metadata element shall be provided using the gmx:Anchor element.

A resource may conform to more than one implementing rules adopted under Article 7(1) of INSPIRE Directive 2007/2/EC or other specification.

Metadata element name Specification


Definition Citation of the product specification or user requirement against which data is being evaluated

ISO 19115 number and name 130. specification

ISO/TS 19139 path dataQualityInfo/*/report/*/result/*/specification



Data type (and ISO 19115 no.) 359. CI_Citation

Domain The following properties are expected: Title (characterString and free text) Reference date (CI_Date):

o dateType: creation, publication or revisiondate: an effective date

Example title: EN ISO 19128:2005(E) : Geographic information — Web map server interface


2016-02-12 of 84

date:o dateType: publicationo date: 2005-12-01

Comments

The metadata element degree contains the degree of conformity of the resource to the specification

Metadata element name Degree


Definition Indication of the conformance result

ISO 19115 number and name 132. pass

ISO/TS 19139 path dataQualityInfo/*/report/*/result/*/pass


INSPIRE multiplicity [1] understood in the context of a conformity statement when reported in the metadata – there may be more than one conformity statement

Data type (and ISO 19115 no.) Boolean5

Domain true if conformant

Example true

Comments

The specification metadata element needs to provide sufficient information to actually invoke the service and enable its usage.

This might include:

- A description of the service interface;

- A WSDL description;

Example of XML encoding of technical specification (conformity references):

<gmd:MD_Metadata……<gmd:dataQualityInfo><gmd:DQ_ConformanceResult>…

<gmd:specification><gmd:CI_Citation>

<gmd:title><gmx:Anchor xlink:href=" http://www.iso.org/iso/iso_catalogue/

catalogue_tc/catalogue_detail.htm?csnumber=32546"> EN ISO 19128:2005(E) : Geographic information — Web map server interface

</gmx:Anchor></gmd:title>

5


2016-02-12 of 84

<gmd:date><gmd:CI_Date>

<gmd:date><gco:Date>2005-12-01</gco:Date>

</gmd:date><gmd:dateType>


</gmd:dateType> </gmd:CI_Date>

</gmd:date> </gmd:CI_Citation> </gmd:specification>http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml <gmd:ex-planation>

<gco:CharacterString>See the referenced specification</gco:Character-String>



</gmd:DQ_ConformanceResult>…<gmd:DQ_ConformanceResult><gmd:dataQualityInfo>…<gmd:MD_Metadata>

Example of XML encoding of technical specification (WSDL):

<gmd:specification> <gmd:CI_Citation> <gmd:title> <gmx:Anchor xlink:href="http://www.dinoservices.nl:80/geo3dmodelweb-services-1/Geo3DModelService?wsdl">Webservice for making virtual boreholes in the Digital Subsurface Models of the Netherlands</gmx:Anchor> </gmd:title> <gmd:date> <gmd:CI_Date> <gmd:date> <gco:Date>2011-11-03</gco:Date> </gmd:date> <gmd:dateType> <gmd:CI_DateTypeCode codeList http://www.isotc211.org/2005/re-sources/Codelist/gmxCodelists.xml#CI_DateTypeCode" codeListValue="publica-tion">publication</gmd:CI_DateTypeCode> </gmd:dateType> </gmd:CI_Date> </gmd:date> </gmd:CI_Citation></gmd:specification>


2016-02-12 of 84

4.5 Interoperable Spatial Data Services

TG Conformance Class 2: Implementation of interoperable Spatial data services


TG Conformance class 1



TG Requirement 9 If at least one of the data sets, to which a spatial data service is related, has been harmonised according to [INS ISDSS], the metadata document for the spatial data service shall include the metadata elements and meet the additional requirements for metadata elements, as specified in this section.

4.5.1 Coordinate Reference Systems Identifier

[INS ISDSS] requires a Coordinate Reference Systems Identifier metadata element, describing, where appropriate, this is the list of coordinate reference systems supported by the spatial data service.

The Coordinate Reference Systems Identifier metadata element is implemented using the RS_Identifier element from [ISO 19115].

TG Requirement 10 Each supported coordinate reference system shall be expressed using an identifier.

TG Requirement 11 Only identifiers contained in a common register shall be used for referring to the coordinate reference systems listed in this Section.

Metadata element name Coordinate Reference SystemReference COMMISSION REGULATION (EU) No 1089/2010, Annex VI,

Part B 3

Definition Description of the coordinate reference system(s) used in the data set.

ISO 19115 number and name 13. referenceSystem

ISO/TS 19139 path referenceSystemInfo

INSPIRE obligation / condition Mandatory if relevant for interoperable spatial data services

INSPIRE multiplicity [0..*] - mandatory if relevant

NOTE In [INS ISDSS], the multiplicity is given as [1..*] with the condition “mandatory if relevant”. In all other cases of conditional metadata elements in [INS MD] and [INS ISDSS], the minimum


2016-02-12 of 84

cardinality is given with 0.

Data type (and ISO 19115 no.) 186.MD_ReferenceSystem

Domain To identify the reference system, the referenceSystemIdentifier (RS_Identifier) shall be provided.

RS_Identifier itself is a complex type (lines 206-207 and 208.1-208.2 from ISO 19115).

At least the following element that is mandatory for ISO should be used (the multiplicity according to ISO 19115 is shown in parentheses):

- 207. code [1] / domain value: free text

Example referenceSystemIdentifier: code: 4258

(http://www.opengis.net/def/crs/EPSG/0/4258)

Comments

TG Recommendation 4 In order to be machine readable, the coordinate reference system identifier metadata element shall be provided using the gmx:Anchor element.

TG Recommendation 5 It is recommended to use the http URIs provided by the Open Geospatial Consortium as coordinate reference system identifiers (see identifiers for the default CRSs in section 4.8.7). These are based on and redirect to the definition in the EPSG Geodetic Parameter Registry (http://www.epsg-registry.org/).


<gmd:MD_Metadata>…<gmd:referenceSystemInfo> <gmd:MD_ReferenceSystem> <gmd:referenceSystemIdentifier> <gmd:RS_Identifier>

<gmd:code><gmx:Anchor

xlink:href="http://www.opengis.net/def/crs/EPSG/0/4258" xlink:title="ETRS89-GRS80">4258</gmx:Anchor>

</gmd:code> </gmd:RS_Identifier> </gmd:referenceSystemIdentifier> </gmd:MD_ReferenceSystem></gmd:referenceSystemInfo> …</gmd:MD_Metadata

http://www.epsg-registry.org/

http://www.epsg-registry.org/

http://www.opengis.net/def/crs/EPSG/0/4258


2016-02-12 of 84

4.5.2 Quality of Service

This is the minimum quality of service estimated by the spatial data service responsible party.

[INS ISDSS] requires three quality of service criteria to be reported in the metadata:

- Availability describes the percentage of time the service is available.

- Performance describes how fast a request to the spatial data service can be completed.

- Capacity describes the maximum number of simultaneous requests that can be completed with the declared performance.

All the quality of service metadata elements contain only static information about the parameters for quality of service, which are in general valid for the service for a long time period.

The Quality of Service metadata elements are implemented using DQ_ConceptualConsistency elements from [ISO 19115].

NOTE It has been agreed by the MIG to use the ISO “dataQuality” element to document quality of service, even if this may not be entirely correct semantically. The rationale for this decision was the goal not to have to extend the ISO metadata schema, but to use existing elements.

TG Requirement 12 There shall be at least one quality result consisting of Description, Value and Unit reported in the metadata for each criterion (availability, performance, capacity).

Metadata element name Criteria

Reference COMMISSION REGULATION (EU) No 1089/2010, Annex VI Part B 4.1

Definition Name of the test applied to the data

ISO 19115 number and name 100. nameOfMeasure

ISO/TS 19139 path dataQualityInfo/*/report/DQ_ConceptualConsistency/nameOfMeasure

INSPIRE obligation / condition Mandatory for interoperable spatial data services

INSPIRE multiplicity [1] - per criterion

NOTE In [INS ISDSS], the Quality of service multiplicity is given as [3..*]. This is fulfilled by reporting on each criterion (availability, performance, capacity).

Data type (and ISO 19115 no.) Free text

Domain Criteria code list (4.8.4)

Example availability (http://inspire.ec.europa.eu/metadata-codelist/Criteria/availability)

Comments The identifier of the measure is enough to retrieve all information about the quality measure. This element enable direct

http://inspire.ec.europa.eu/metadata-codelist/Criteria/availability



2016-02-12 of 84

understanding of the metadata

Metadata element name Description

Reference COMMISSION REGULATION (EU) No 1089/2010, Annex VI Part B 4.2.1

Definition Code identifying a registered standard procedure

ISO 19115 number and name 101. measureIdentification

ISO/TS 19139 path dataQualityInfo/*/report/DQ_ConceptualConsistency/measureIdentification




Data type (and ISO 19115 no.) MD_Identifier/code

Domain Identifier of the quality measure as defined in the quality measure tables

Example INSPIRE_service_performance

Comments

Metadata element name Value


Definition Quantitative value or values, content determined by the evaluation procedure used

ISO 19115 number and name 137. value

ISO/TS 19139 path dataQualityInfo/*/report/DQ_ConceptualConsistency/result/DQ_QuantitativeResult/value




Data type (and ISO 19115 no.) As defined for each measure in the quality measure tables

Domain

Example 1

Comments

Metadata element name Unit


2016-02-12 of 84


Definition Value unit for reporting a data quality result.

ISO 19115 number and name 135. valueUnit

ISO/TS 19139 path dataQualityInfo/*/report/DQ_ConceptualConsistency/result/DQ_QuantitativeResult/valueUnit




Data type (and ISO 19115 no.) UnitOfMeasure

Domain Value unit for the measure as described in the quality measure tables

Example second (implemented by reference in XML : <gmd:valueUnit xlink:href=" http://www.opengis.net/def/uom/SI/second"/>)

Comments

The three tables below describe quality measures for each quality of service criteria: availability, performance and capacity. The tables are formalised as data quality measures following the ISO 19157 data quality measure structure.

TG Recommendation 6 It is recommended to use either these measures or, if other measures are used, to make these publicly available, ideally through a register and following the [ISO 19157] data quality measure structure.

http://www.opengis.net/def/uom/SI/second


2016-02-12 of 84

Service availability

Component Measure Description

Name Service availability

Alias –

Data quality element Conceptual consistency (or Usability, if ISO 19115-1 and ISO 19157 is used)

Data quality basic measure -

Definition percentage of time the service is available.

Description Availability on yearly basis, expressed as percentage of time.The reported value unit should be “unity” (http://www.opengis.net/def/uom/OGC/1.0/unity).

Parameter –

Data quality value type Real

Data quality value structure –

Source reference –

Example 90%

Identifier INSPIRE_service_availability

Service performance


Name Service performance

Alias Average response time


Data quality basic measure

Definition Performance describes how fast a request to the spatial data service can be completed, expressed in second.

Description Average response time, expressed as seconds (http://www.opengis.net/def/uom/SI/second)

Parameter –

Data quality value type Integer



Example 1 s

Identifier INSPIRE_service_performance

http://www.opengis.net/def/uom/SI/second

http://www.opengis.net/def/uom/OGC/1.0/unity


2016-02-12 of 84

Service capacity


Name Service capacity

Alias –


Data quality basic measure

Definition maximum number of simultaneous requests that can be completed with the declared performance

Description Maximum number of simultaneous requests per second meeting the performance criteria, expressed as number of requests per second

Parameter –

Data quality value type Integer



Example 50 requests per second

Identifier INSPIRE_service_capacity


<gmd:MD_Metadata>…<gmd:dataQualityInfo>

<gmd:DQ_DataQuality><gmd:scope>

<gmd:DQ_Scope><gmd:level>

<gmd:MD_ScopeCode codeList=http://www.isotc211.org/2005/re-sources/Codelist/gmxCodelists.xml#MD_ScopeCode codeListValue="service"/>

</gmd:level></gmd:DQ_Scope>

</gmd:scope><gmd:report>

<gmd:DQ_ConceptualConsistency><gmd:nameOfMeasure>

<gmx:Anchor> xlink:href="http://inspire.ec.europa.eu/metadata-codelist/Criteria/availability">availability</gmx:Anchor>

</gmd:nameOfMeasure><gmd:measureIdentification>

<gmd:MD_Identifier><gmd:code>

<gco:CharacterString>INSPIRE_service_availability</gco:CharacterString>

</gmd:code></gmd:MD_Identifier>

</gmd:measureIdentification><gmd:result>

<gmd:DQ_QuantitativeResult><gmd:valueUnit xlink:href="http://www.opengis.net/def/uom/

OGC/1.0/unity”/>


2016-02-12 of 84

<gmd:value> <gco:Record>90</gco:Record>

</gmd:value></gmd:DQ_QuantitativeResult>

</gmd:result></gmd:DQ_ConceptualConsistency>

</gmd:report><gmd:report>


<gmx:Anchor> xlink:href="http://inspire.ec.europa.eu/metadata-codelist/Criteria/performance">performance</gmx:Anchor>



<gco:CharacterString> INSPIRE_service_performance</gco:CharacterString>



<gmd:DQ_QuantitativeResult><gmd:valueUnit xlink:href=" http://www.opengis.net/def/

uom/SI/second"/><gmd:value>

<gco:Record>0.5</gco:Record></gmd:value>

</gmd:DQ_QuantitativeResult></gmd:result>

</gmd:DQ_ConceptualConsistency></gmd:report><gmd:report>


<gmx:Anchor> xlink:href="http://inspire.ec.europa.eu/metadata-codelist/Criteria/capacity">capacity</gmx:Anchor>



<gco:CharacterString>INSPIRE_service_capacity</gco:CharacterString>



<gmd:DQ_QuantitativeResult><gmd:valueUnit gco:nilReason="inapplicable"/><gmd:value>

<gco:Record>50</gco:Record></gmd:value>


</gmd:DQ_ConceptualConsistency></gmd:report>

…</gmd:MD_Metadata


2016-02-12 of 84

4.5.3 Conditions applying to access and use

The access to the spatial data service may have technical restrictions applying to the access and use of the spatial data service.

[INS ISDSS] requires the technical restrictions applying to the access and use of the spatial data service to be documented in the metadata element “conditions applying to access and use”.

TG Requirement 13 Conditions applying to access and use shall be represented by at least one of the following:

- a combination of one instance of MD_LegalConstraints.accessConstraints and one instance of MD_LegalConstraints.otherConstraints. In that case, the element MD_LegalConstraints.accessConstraints shall be set at the value “otherRestrictions”.

- a combination of one instance of MD_LegalConstraints.useConstraints and one instance of MD_LegalConstraints.otherConstraints. In that case, the element MD_LegalConstraints.useConstraints shall be set at the value “otherRestrictions”.

- The otherConstraints element shall NOT contain a link to the code list for Limitations on Public Access in Inspire registry since that is reserved for documenting Limitations on public access.

TG Requirement 14 Descriptions of terms and conditions, including where applicable, the corresponding fees or a link (URL) where these terms and conditions are described shall be provided through the element otherConstraints.

TG Recommendation 7 For detailed information it is recommended to provide a link to a license type (e.g. http://creativecommons.org/licenses/by/3.0), a website or to a document containing the necessary information.

Conditions applying to access

Metadata element name Conditions applying to access

Reference COMMISSION REGULATION (EU) No 1089/2010, Annex VI Part A 1

Definition Restrictions on the access of a resource or metadata

ISO 19115 number and name 70. accessConstraints

ISO/TS 19139 path identificationInfo[1]/*/resourceConstraints/*/accessConstraints

INSPIRE obligation / condition Conditional. Mandatory if useConstraints is not documented.

INSPIRE multiplicity [0..*] for accessConstraints per instance of MD_LegalConstraints

Data type (and ISO 19115 no.) MD_RestrictionCode

Domain Codelist (strictly limited to the value defined in B.5.24 of ISO 19115)


2016-02-12 of 84

Example otherRestrictions (limitation not listed).

Comments

Metadata element name Conditions applying to access (other constraints)


Definition Other restrictions and legal prerequisites for accessing the resource or metadata

ISO 19115 number and name 72. otherConstraints

ISO/TS 19139 path identificationInfo[1]/*/resourceConstraints/*/otherConstraints

INSPIRE obligation / condition Conditional: referring to conditions applying to access. Mandatory if accessConstraints is set at the value “otherRestrictions”

INSPIRE multiplicity [0..*] for otherConstraints per instance of MD_LegalConstraints

Data type (and ISO 19115 no.) CharacterString

Domain Free text

If the values “no conditions apply” or “conditions unknown” are used, the corresponding value from the code list Conditions applying to access and use (4.8.2) shall be used.

Example Example if no conditions apply: noConditionsApply (http://inspire.ec.europa.eu/registry/metadata-codelist/ConditionsApplyingToAccessAndUse/noConditionsApply)Example if there is information about restrictions:The JRC does not provide any assistance or support in using the service

CommentsThe domain of the metadata element otherConstraints is free text. This makes it hard to unambiguously define some common values in all official languages in the Communiy.Therefore it is required to refer to code lists in the INSPIRE registry for some specific values like “no conditions apply” and “conditions unknown” (see Domain).

Conditions applying to use

Metadata element name Conditions applying to use


Definition Restrictions on the use of a resource or metadata

ISO 19115 number and name 71. useConstraints

http://inspire.ec.europa.eu/registry/metadata-codelist/ConditionsApplyingToAccessAndUse/noConditionsApply



2016-02-12 of 84

ISO/TS 19139 path identificationInfo[1]/*/resourceConstraints/*/useConstraints

INSPIRE obligation / condition Conditional. Mandatory if accessConstraints is not documented.

INSPIRE multiplicity [0..*] for useConstraints per instance of MD_LegalConstraints

Data type (and ISO 19115 no.) MD_RestrictionCode

Domain Codelist (strictly limited to the value defined in B.5.24 of ISO 19115)

Example otherRestrictions (limitation not listed).

Comments

Metadata element name Conditions applying to use (other constraints)


Definition Other restrictions and legal prerequisites for accessing and using the resource or metadata

ISO 19115 number and name 72. otherConstraints

ISO/TS 19139 path identificationInfo[1]/*/resourceConstraints/*/otherConstraints

INSPIRE obligation / condition Conditional: referring to conditions applying to use. Mandatory if useConstraints is set at the value “otherRestrictions”

INSPIRE multiplicity [0..*] for otherConstraints per instance of MD_LegalConstraints


Domain Free text

If the values “no conditions apply” or “conditions unknown” are used, the corresponding value from the code list Conditions applying to access and use (4.8.2) shall be used.

Example Example if no conditions apply: noConditionsApply (http://inspire.ec.europa.eu/registry/metadata-codelist/ConditionsApplyingToAccessAndUse/NoConditionsApply ) Example if there is information about restrictions:The JRC does not provide any assistance or support in using the service

Comments The domain of the metadata element otherConstraints is free text. This makes it hard to unambiguously define some common values in all official languages in the Communiy.Therefore it is required to refer to code lists in the INSPIRE registry for some specific values like “no conditions apply” and “conditions unknown” (see Domain).

Conditions applying to access and use (access and use restrictions apply)

<gmd:MD_Metadata …

http://inspire.ec.europa.eu/registry/metadata-codelist/ConditionsApplyingToAccessAndUse/NoConditionsApply


2016-02-12 of 84

…<gmd:identificationInfo>

<srv:SV_ServiceIdentification>… <!-- The ACCESS restriction -- > <gmd:resourceConstraints>

<gmd:MD_LegalConstraints> <gmd:accessConstraints>

<gmd:MD_RestrictionCodecodeList="http://standards.iso.org/ittf/

PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/gmxCodelists.xml#MD_RestrictionCode"codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>

</gmd:accessConstraints><gmd:otherConstraints>

<gco:CharacterString>description of the access restriction …</gco:CharacterString> </gmd:otherConstraints>

</gmd:MD_LegalConstraints></gmd:resourceConstraints>

<!-- The USE restriction -- ><gmd:resourceConstraints>

<gmd:MD_LegalConstraints> <gmd:useConstraints>


PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/gmxCodelists.xml#MD_RestrictionCode"codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>

</gmd:useConstraints><gmd:otherConstraints>

<gco:CharacterString> description of the use restriction … </gco:CharacterString> </gmd:otherConstraints>


…</srv:SV_ServiceIdentification>

</gmd:identificationInfo>…</gmd:MD_Metadata>

No conditions applying to access (using a language neutral identifier - in Swedish)

<gmd:MD_Metadata ……

<gmd:identificationInfo><gmd:MD_DataIdentification>

…<gmd:resourceConstraints>

...(see next example)


2016-02-12 of 84

… </gmd:resourceConstraints><gmd:resourceConstraints>

<gmd:MD_LegalConstraints><gmd:accessConstraints>


PubliclyAvailableStandards/ISO_19139_Schemas/

resources/codelist/gmxCodelists.xml#MD_RestrictionCode"

codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode>


<gmx:Anchor xlink:href="http://inspire.ec.europa.eu/registry/metadata-codelist/ConditionsApplyingToAccessAndUse/NoConditionsApply">inga tillämpliga villkor </gmx:Anchor> </gmd:otherConstraints>


…

4.5.4 Responsible party

[INS ISDSS] requires that the responsible party metadata element shall at least describe the custodian responsible organisation, corresponding to the Custodian responsible party role set out in [INS MD].

TG Requirement 15 There shall be at least one responsible party metadata element, whose responsible party role is “custodian”.

This custodian the party that accepts accountability and responsibility for the resource and ensures ap-propriate care and maintenance of the resource. This can be the same organisation, responsible for the establishment, management, maintenance and distribution of spatial data sets and services as re-quired in [INS MD TG].

Metadata element name Responsible party


Definition Identification of, and means of communication with, person(s) and organization(s) associated with the resource(s)

ISO 19115 number and name 29. pointOfContact

ISO/TS 19139 path identificationInfo[1]/*/pointOfContact


INSPIRE multiplicity [1] Relative to a responsible organisation, but there may be many responsible organisations for a single resource

Data type (and ISO 19115 no.) 374. CI_ResponsibleParty

Domain The following properties are expected:


2016-02-12 of 84

organisationName (characterString and free text) contactInfo (CI_Contact):

o address: electronicMailAddress [1..*] (characterString)

Example organisationName: European Commission, Joint Research Centre

contactInfo:o address:

electronicMailAddress: [email protected]

Comments

Metadata element name Responsible party role


Definition Function performed by the responsible party

ISO 19115 number and name 379. role

ISO/TS 19139 path identificationInfo[1]/*/pointOfContact/*/role


INSPIRE multiplicity [1] relative to a responsible organisation, but there may be many responsible organisations for a single resource

Data type (and ISO 19115 no.) CI_RoleCode

Domain Codelist (see B.5.5 of ISO 19115)

Example custodian

Comments There is a direct mapping between the responsible party roles defined in Part D 6 of the INSPIRE Metadata Regulation 1205/2008/EC and the values of the CI_RoleCode codelist of ISO 19115

Example of XML encoding:<gmd:MD_Metadata … >…<gmd:identificationInfo><srvSV_ServiceIdentification>…<gmd:pointOfContact>

<gmd:CI_ResponsibleParty><gmd:organisationName>

<gco:CharacterString>TNO Geological Survey of the Netherlands</gco:CharacterString>

</gmd:organisationName><gmd:contactInfo>

<gmd:CI_Contact><gmd:address>

<gmd:CI_Address><gmd:electronicMailAddress>

<gco:CharacterString>[email protected]</gco:CharacterString></gmd:electronicMailAddress>


2016-02-12 of 84

</gmd:CI_Address></gmd:address>

</gmd:CI_Contact></gmd:contactInfo><gmd:role>

<gmd:CI_RoleCodecodeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_RoleCode" codeListValue="custodian">custodian</gmd:CI_RoleCode>

</gmd:role></gmd:CI_ResponsibleParty></gmd:pointOfContact>…</srvSV_ServiceIdentification>…</gmd:identificationInfo>…</gmd:MD_Metadata>

4.6 Harmonised spatial data services

TG Conformance Class 3: Implementation of Harmonised Spatial Data Services


TG Conformance class 1, TG Conformance class 2



TG Requirement 16 If at least one of the data sets, to which a spatial data service is related, has been harmonised according to [INS ISDSS], where practicable, the metadata document for the spatial data service shall include the metadata elements and meet the additional requirements for metadata elements, meet the requirements on quality of service, output encoding and the Get Harmonised Spatial Data Service Metadata Operation, as specified in this section.

4.6.1 Invocation metadata

[INS ISDSS] requires invocation metadata element documenting the interfaces of the harmonised spatial data service and lists the end points to enable machine-to machine communication.

To describe the invocation metadata, the SV_OperationMetadata elements from [ISO 19119] are used.

TG Requirement 17 The interface shall be documented

- in a service capabilities, WSDL or comparable document referenced in one [ISO 19119] SV_OperationMetadata element (scenario 1), or


2016-02-12 of 84

- directly in [ISO 19119] SV_OperationMetadata elements, using one SV_OperationMetadata element per method of the service (scenario 2).

EXAMPLE A complete WSDL example is provided in Annex D.

At least the mandatory ISO elements need to be provided, as specified in the mappings and examples below.

The first example describes an XML encoding of scenario 1 (a reference to the complete interface description). The second example of describes an XML encoding of scenario 2. It also provides additional information in optional metadata elements.

Metadata element name operationName

Reference COMMISSION REGULATION (EU) No 1089/2010, Annex VII Part B 3

Definition A unique identifier for this interface

ISO 19119 number and name Table C2 1. operationName

CSW ISO Metadata AP path identificationInfo[1]/*/containsOperations/*/operationName

INSPIRE obligation / condition Mandatory for harmonised spatial data services

INSPIRE multiplicity [1]


Domain

Example GetSampleColumn

Comments

Metadata element name DCP


Definition Distributed computing platforms on which the operation has been implemented.

ISO 19119 number and name Table C2 2. DCP

CSW ISO Metadata AP path identificationInfo[1]/*/containsOperations/*/DCP



Data type (and ISO 19115 no.) DCPlist

Domain DCP List code list (4.8.5)

Example WebServices

Comments


2016-02-12 of 84

Metadata element name connectPoint


Definition Handle for accessing the service interface.

ISO 19119 number and name Table C2 6. connectPoint

CSW ISO Metadata AP path identificationInfo[1]/*/containsOperations/*/connectPoint/*/linkage



Data type (and ISO 19115 no.)

Domain

Example http://www.dinoservices.nl:80/geo3dmodelwebservices-1/Geo3DModelService

Comments

The tables below, taken from [ISO 19119, Section C.2], show the detailed information about the containsOperation element.

Table 2 - SV_OperationMetadata detail

Attribute name / Role name Definition Oblication /

ConditionMaximum occurrence

Attribute class or target class of role

operationName A unique identifier for this interface. M 1 CharacterString

DCP

Distributed Computing Platforms on which the operation has been implemented.

M N DCPlist

operationDescription

Free text description of the intent of the operation and the results of the operation.

O 1 CharacterString

invocationName

The name used to invoke this interface within the context of the DCP. The name is identical for all DCPs.

O 1 CharacterString

parametersThe parameters that are required for this interface.

O 1sequence(SV_Parameter)

(ref. to table 9)

connectPoint Handle for accessing the service interface. M N CI_OnlineResource


2016-02-12 of 84

dependsOn

List of operations that must be completed immediately before current operation is invoked, structured as a list for capturing alternate predecessor paths and sets for capturing parallel predecessor paths.

O 1

set{sequence{operationName} |

set(operationName}

The SV_Parameter is used to provide service parameters.

Table 3 - SV_Parameter detail

Attribute name / Role name Definition Obligation /

ConditionMaximum occurrence

Attribute class or target class of role

NameThe name, as used by the service for this parameter.

M 1 MemberName

Direction

Indication if the parameter is an input to the service, an output or both.

O 1 ParameterDirection

DescriptionA narrative explanation of the role of the parameter

O 1 CharacterString

Optionality Indication if the parameter is required M 1 CharacterString

Repeatability

Indication if more than one value of the parameter may be provided.

M 1 Boolean

ValueType Operation parameters value type O N Association

Example of scenario 1 XML encoding:

<gmd:MD_Metadata ……<gmd:identificationInfo><srv:SV_ServiceIdentification> …<srv:containsOperations>

<srv:SV_OperationMetadata><srv:operationName>

<gco:CharacterString>WSDL</gco:CharacterString>


2016-02-12 of 84

</srv:operationName><srv:DCP>

<srv:DCPList codeList="http://inspire.ec.europa.eu/metadata-codelist/DCPList" codeListValue=" http://inspire.ec.europa.eu/metadata-codelist/DCPList/WebServices">Web services</srv:DCPList>

</srv:DCP><srv:connectPoint>

<gmd:CI_OnlineResource><gmd:linkage>

<gmd:URL> http://www.dinoservices.nl/geo3dmodelwebservices-1/Geo3DModelService?wsdl</gmd:URL>

</gmd:linkage></gmd:CI_OnlineResource>

</srv:connectPoint></srv:SV_OperationMetadata>

</srv:containsOperations>…</srv:SV_ServiceIdentification> </gmd:identificationInfo>…</gmd:MD_Metadata>

Example of scenario 2 XML encoding:

<gmd:MD_Metadata ……<gmd:identificationInfo><srv:SV_ServiceIdentification> …<srv:containsOperations>


<gco:CharacterString>sampleColumn</gco:CharacterString></srv:operationName><srv:DCP>

<srv:DCPList codeList="http://inspire.ec.europa.eu/metadata-codelist/DCPList" codeListValue="WebServices"/>

</srv:DCP><srv:parameters>

<srv:SV_Parameter><srv:name>

<gco:aName><gco:CharacterString>model</gco:CharacterString>

</gco:aName><gco:attributeType>

<gco:TypeName><gco:aName><gco:CharacterString>CharacterString</gco:CharacterString></gco:aName>

</gco:TypeName></gco:attributeType>

</srv:name><srv:direction>

<srv:SV_ParameterDirection>in</srv:SV_ParameterDirection></srv:direction>


2016-02-12 of 84

<srv:optionality><gco:CharacterString>required</gco:CharacterString>

</srv:optionality><srv:repeatability>

<gco:Boolean>false</gco:Boolean></srv:repeatability><srv:valueType>string</srv:valueType>

</srv:SV_Parameter></srv:parameters><srv:parameters>


<gco:aName> <gco:Char-acterString>xCoordinate</gco:CharacterString>





<srv:SV_ParameterDirection>in</srv:SV_ParameterDirection></srv:direction><srv:optionality>

<gco:CharacterString>required</gco:CharacterString></srv:optionality><srv:repeatability>

<gco:Boolean>false</gco:Boolean></srv:repeatability><srv:valueType>double</srv:valueType>



<gco:aName> <gco:Char-acterString>yCoordinate</gco:CharacterString>







<gco:Boolean>false</gco:Boolean></srv:repeatability><srv:valueType>double</srv:valueType>


2016-02-12 of 84



<gco:aName> <gco:Char-acterString>resolution</gco:CharacterString>







<gco:Boolean>false</gco:Boolean></srv:repeatability><srv:valueType>int</srv:valueType>



<gco:aName> <gco:Char-acterString>coordinateSystem</gco:CharacterString>






<gco:CharacterString>optional</gco:CharacterString></srv:optionality><srv:repeatability>

<gco:Boolean>false</gco:Boolean></srv:repeatability><srv:valueType>AvailableCoordinateSystemType</srv:valueType>

</srv:SV_Parameter></srv:parameters><srv:connectPoint>


<gmd:URL>http://www.dinoservices.nl:80/geo3dmodelwebservices-1/Geo3DMod-elService</gmd:URL>


2016-02-12 of 84



</srv:containsOperations>…</srv:SV_ServiceIdentification> </gmd:identificationInfo>…</gmd:MD_Metadata>

4.6.2 Quality of the Harmonised Spatial Data Service

[INS ISDSS] requires that the probability of a harmonised spatial data service to be available shall be 98 % of the time.

4.6.2.1 Normalized testing procedureThe following procedure has been copied from [INS NS TG].

TG Requirement 18 Availability shall be measured consistently based on sample reference requests to a given service. Minimum 10 reference requests per hour shall be issued to the service continuously during its lifetime.

To respect long running operations, the number of requests may be reduced. In such cases, a new request can be issued maximum 6 minutes after the previous request has finished.

EXAMPLE If a previous request for a 1 GB data set was issued at 8:00 and lasts until 8:30, the next reference request shall be issued at the latest at 8:36.

TG Recommendation 8 The sample request issued to the service to measure performance can be used to measure availability as well, thus also fulfilling the same evaluation and assessment criteria.

TG Requirement 19 The availability shall be based on a time frame of one year meaning a maximum unplanned downtime of 3.63 days per year. Periods of planned downtime e.g. because of system maintenance, shall not be included in the measure. Downtime is considered planned when notified to the community well in advance (minimum 1 week), e.g. via notifications to registered users or on portals.

NOTE It is assumed that the availability is calculated in the following way:

100% ↔ 365 x 24 - (planned downtime)

99% ↔ [365 x 24 - (planned downtime)] * 0.99

etc.

TG Recommendation 9 Planned downtime is recommended to be less than 10 hours per month (i.e., less than 120 hours per year).


2016-02-12 of 84

4.6.3 Encoding of the spatial objects in the Spatial Data Service

[INS ISDSS] requires a harmonised spatial data service returning spatial objects in the scope of the [INS DIR] to encode those spatial objects according to [INS ISDSS].

TG Requirement 20 If a request to the spatial data service returns spatial objects in the scope of the [INS DIR], the returned data shall meet the requirements for encoding specified for these spatial objects in Art. 7 and the relevant annexes of [INS ISDSS].

Article 7 of [INS ISDSS] on Encoding requires the following:

1. Every encoding rule used to encode spatial data shall conform to [ISO 19118]. In particular, it shall specify schema conversion rules for all spatial object types and all attributes and association roles and the output data structure used.

2. Every encoding rule used to encode spatial data shall be made available.

The INSPIRE data specifications Technical Guidelines contain default encoding rules for all spatial data themes that meet the requirements of [INS ISDSS].

4.6.4 Operations for Harmonised Spatial Data Services

[INS ISDSS] requires a harmonised spatial data service to include a Get Harmonised Spatial Data Service Metadata operation, as specified in the following sections.

NOTE This operation is similar to the Get Discovery/View/Download/Transformation Service Metadata Operations described in [INS NS].

4.6.4.1 Get Harmonised Spatial Data Service Metadata DescriptionGet Harmonised Spatial Data Service Metadata

It provides the mandatory information about the service and describes the service capabilities. It is inspired by the generic elements of the similar operations as included in [INS NS] for the network services.

Request parameters

o Natural language to be used for the content of the response

Response parameters

o Spatial Data Service Metadata

o Operations Metadata

o Language

Recommended implementation

Get Harmonised Spatial Data Service Metadata Request

Metadata records for Spatial Data Service shall be available in a Discovery Service.


2016-02-12 of 84

Note: The Resource locator metadata element for the Spatial Data Service shall contain a link to the Get Harmonised Spatial Data Service Metadata operation and it shall be unambiguously identified

Get Harmonised Spatial Data Service Metadata Response

The Get Harmonised Spatial Data Service Metadata response will be a custom capabilities document. There are two possibilities to implement this response:

Scenario 1: Repeat all metadata and operations

Scenario 2: Provide a link to ISO metadata and to a document describing the operations provided by the service (e.g. WSDL)

TG Requirement 21 The Resource locator metadata element for the Spatial Data Service shall contain a link to the Get Harmonised Spatial Data Service Metadata operation, and it shall be unambiguously identified using the function described at paragraph 4.4.2. The response shall be provided using one of the two options described in sections 4.6.4.2 and 4.6.4.3.

Open issue: The mapping of the Get Harmonised Spatial Data Service Metadata response to an extended capabilities document works well for OGC web services, which already offer a GetCapabilities operation. However, it may be less suitable for other types of SDS (e.g. RESTful services, custom APIs, …).

An alternative way to provide the required information would be to use a simple XML type GetSDSMetadataResponse consisting of two elements:

gmd:metadata : MD_Metadata (to be provided inline (scenario 1) or through an xlink:href reference to the metadata record (scenario 2)

ins_com:SupportedLanguages : supportedLanguagesType (to provide the supported languages)

Note that the required operations metadata is already included as “invocation metadata” (see section 4.6.1).

4.6.4.2 Scenario 1 – Get Capabilities response – Metadata URLIn this scenario, in order to avoid duplication of metadata already provided in the ISO metadata, the capabilities document returned by the Get Harmonised Spatial Data Service Metadata operation has only to provide the reference to the ISO metadata and to a document that describes all the operation provided by the service itself. This scenario follows more the atom implementation of the download service (use of describedby for each “block”) while still providing explicitly a get service metadata operation.

The reference to the spatial data service metadata is provided through the “MetadataUrl” element in the INSPIRE Extended Capabilities.

The operation section contains the GetCapabilities operation itself and an operation called “DescribeServiceOperations”. This operation is a link to a document (for example a WSDL) that provides all the information needed to invoke the service.


2016-02-12 of 84

An encoding example of this scenario is provided in Annex A.

4.6.4.3 Scenario 2 – Get Capabilities response – Metadata replicationIn this scenario, all the metadata provided in the ISO metadata shall be repeated in the capabilities document (including INSPIRE Extended Capabilities metadata elements).This scenario is based on the experience of the discovery, view and downloads (WFS option) technical guidance.

Open issue: In order to provide all the new metadata needed by the INSPIRE Spatial Data Service, the current XSD describing the INSPIRE Extended Capabilities would need to be extended.

An example for the XSD’s extension is provided in Annex A.

In addition to the service information metadata, an operation for each service’s operation has to be provided in the operation metadata section of the Get Capabilities response.

An encoding example of this scenario is provided in Annex A.

4.7 Services allowing spatial data services to be invoked

TG Requirement 22 When requesting metadata on a spatial data service through the Discover Metadata operation of an INSPIRE Discovery Service, the response shall contain all the elements required to be available for that spatial data service.

4.8 INSPIRE Metadata CodelistsThis section gives a description of the value domains (code lists) to be used for the INSPIRE metadata elements, as specified in the descriptions given in the previous sections. Those domains are defined:

in the metadata [INS MD]; in this [INS MD TG] or in [INS ISDSS]; in the ISO standards.

For every codelist, each value is defined by:

a numerical identifier (No. ID), if any, corresponding, in most cases, to the numerical identifier defined in [INS MD] or to ISO domain code;

a textual name; a language neutral name, if any; an optional definition/description; an URI identifier, if any.

4.8.1 Resource locator description

The code list is to be used for the element “description” required for the INSPIRE metadata element “Resource locator” (for spatial data services).

No. ID

Textual name

Language neutral name

Description / definition INSPIRE Registry URI identifier

Access point accessPoint Containing a detailed description http://inspire.ec.europa.eu/metadata-



2016-02-12 of 84

of a spatial data service, including a list of end points to allow its execution,

codelist/ResourceLocatorDescription/accessPoint

End point endPoint Used to directly call an operation provided by a spatial data service

http://inspire.ec.europa.eu/metadata-codelist/ResourceLocatorDescription/endPoint

4.8.2 Conditions applying to access and use

The code list is to be used for the element “otherConstraints” required for the INSPIRE metadata element “Conditions applying to access and use” if no conditions apply or the conditions are unknown.

No. ID

Textual name



No conditions apply

noConditionsApply no conditions apply to the access and use of the resource


conditions unknown

conditionsUnknown conditions apply to the access and use of the resource are unknown

http://inspire.ec.europa.eu/registry/metadata-codelist/ConditionsApplyingToAccessAndUse/conditionsUnkown

4.8.3 Spatial data services categories

The code list is defined in part B.1 in Annex V of the [INS ISDSS], to be used for the INSPIRE metadata element required for spatial data services “Category”.

No. ID

Textual name



Invocable invocable Invocable spatial data service means the following: a) a spatial data service with metadata according to Regulation (EU) No 1205/2008; b) a spatial data service with at least one resource locator that is an access point; c) and a spatial data service in conformity with a documented and publicly available set of technical specifications providing the information necessary for its execution.


Interoperable interoperable an invocable spatial data service in conformity with the annex VII of the Commission Regulation (EU) No 1089/2010 as amended by the Commission Regulation (EU) No 1312/2014.

http://inspire.ec.europa.eu/metadata-codelist/Category/interoperable

Harmonised harmonised an interoperable spatial data service in conformity with the annex VIII of the Commission Regulation (EU) No 1089/2010 as amended by the Commission Regulation (EU) No 1312/2014.

http://inspire.ec.europa.eu/metadata-codelist/Category/harmonised

Open issue: The proposed URIs for the SDS categories are in line with the general approach to include values from [INS MD] and [INS ISDSS] in the http://inspire.ec.europa.eu/metadata-codelist register. However, since this TG proposes to use the specification title sub-element of the DQ_ConformanceResult element to document the SDS category, it may therefore be more suitable to

http://inspire.ec.europa.eu/metadata-codelist







http://inspire.ec.europa.eu/registry/metadata-codelist/ConditionsApplyingToAccessAndUse/ConditionsUnkown












2016-02-12 of 84

use a conformance class ID for the URI, e.g. http://inspire.ec.europa.eu/conformanceClass/MD/1.4/SDS_Invocable.

4.8.4 Criteria

No. ID

Textual name



Availability availability It describes the percentage of time the service is available.


Performance

performance It describes how fast a request to the spatial data service can be completed.

http://inspire.ec.europa.eu/metadata-codelist/Criteria/performance

Capacity capacity It describes the maximum number of simultaneous requests that can be completed with the declared performance.

http://inspire.ec.europa.eu/metadata-codelist/Criteria/capacity

4.8.5 DCP List

The DCP list is defined in [ISO 19119], to be used for the element “DCP” in the ISO class “SV_OperationMetadata”, required for the INSPIRE harmonized spatial data services.

No. ID

Textual name Language neutral name

Description / definition

URI identifier

XML XML http://inspire.ec.europa.eu/metadata-codelist/DCPList/xml

CORBA CORBA http://inspire.ec.europa.eu/metadata-codelist/DCPList/corba

JAVA JAVA http://inspire.ec.europa.eu/metadata-codelist/DCPList/java

COM COM http://inspire.ec.europa.eu/metadata-codelist/DCPList/com

SQL SQL http://inspire.ec.europa.eu/metadata-codelist/DCPList/sql

Web services WebServices http://inspire.ec.europa.eu/metadata-codelist/DCPList/webServices

4.8.6 Coordinate reference system

Recommended http URIs for the default coordinate reference

No. ID

Textual name Short name Description / definition

URI identifier

3D Cartesian in ETRS89 ETRS89-XYZ http://www.opengis.net/def/crs/EPSG/0/4936

3D geodetic in ETRS89 on GRS80

ETRS89-GRS80h


2D geodetic in ETRS89 on GRS80

ETRS89-GRS80


2D LAEA projection in ETRS89 on GRS80

ETRS89-LAEA


2D LCC projection in ETRS89 on GRS80

ETRS89-LCC http://www.opengis.net/def/crs/EPSG/0/3034






http://inspire.ec.europa.eu/metadata-codelist/DCPList/webServices

http://inspire.ec.europa.eu/metadata-codelist/DCPList/webServices

http://inspire.ec.europa.eu/metadata-codelist/DCPList/sql

http://inspire.ec.europa.eu/metadata-codelist/DCPList/sql

http://inspire.ec.europa.eu/metadata-codelist/DCPList/com

http://inspire.ec.europa.eu/metadata-codelist/DCPList/com

http://inspire.ec.europa.eu/metadata-codelist/DCPList/java

http://inspire.ec.europa.eu/metadata-codelist/DCPList/java

http://inspire.ec.europa.eu/metadata-codelist/DCPList/corba

http://inspire.ec.europa.eu/metadata-codelist/DCPList/corba

http://inspire.ec.europa.eu/metadata-codelist/DCPList/xml

http://inspire.ec.europa.eu/metadata-codelist/DCPList/xml







http://inspire.ec.europa.eu/conformanceClass/MD/1.4/SDS_Invocable


2016-02-12 of 84

2D TM projection in ETRS89 on GRS80, zone 26N (30°W to 24°W)

ETRS89-TM26N



ETRS89-TM27N



ETRS89-TM28N



ETRS89-TM29N


2D TM projection in ETRS89 on GRS80, zone 30N (6°W to 0°)

ETRS89-TM30N


2D TM projection in ETRS89 on GRS80, zone 31N (0° to 6°E)

ETRS89-TM31N


2D TM projection in ETRS89 on GRS80, zone 32N (6°E to 12°E)

ETRS89-TM32N



ETRS89-TM33N



ETRS89-TM34N



ETRS89-TM35N



ETRS89-TM36N



ETRS89-TM37N



ETRS89-TM38N



ETRS89-TM39N


Height in EVRS EVRS http://www.opengis.net/def/crs/EPSG/0/5730

3D compound: 2D geodetic in ETRS89 on GRS80, and EVRS height

ETRS89-GRS80-EVRS



















2016-02-12 of 84

Annex A – Get Harmonized Spatial Data Service MetadataThis is an example of the Get Harmonized Spatial Data Service Metadata operation as described at chapter 4.6.4.

A.1 Get Harmonized Spatial Data Service Metadata RequestThis section contains a description about the GetCapabilities Request, including a table specifying the parameters needed by the request.

In this request there is no need to provide the “service” information (this is a deviation from the standard OWS capabilities).

Table 4 - Get Harmonized Spatial Data Service Metadata request

Request Parameter Mandatory / optional

Description

Request=GetCapabilities M Operation name (text).

Fixed value: GetCapabilities

AcceptVersions=version O Request version: 2.0.2

[INS NS] requires that multilingual aspects for network services are supported. As there is no standard way to deal with multilingualism within the [OGC WS] specifications, the HTTP/GET binding of the GetCapabilities-Operation is extended by an additional parameter that indicates the client’s preferred language.

Request Parameter Parameter value Description

LANGUAGE Codelist (See ISO/TS 19139) based on alpha-3 codes of ISO 639-2.

Use only three-letter codes from in ISO 639-2/B (bibliographic codes),

The list of codes for the 23 official EU languages and EFTA Countries is:

Bulgarian – bul Italian – itaCzech – cze Latvian – lavDanish – dan Liechenstein – gerDutch – dut Lithuanian – litEnglish – eng Maltese – mlt

It is optional for a Client Request.

It is mandatory to be supported for the service and shall be processed if the parameter is present in a client’s request with a supported language code. If the parameter is absent in a client’s request or it requested an unsupported language the service shall response in the service default language.


2016-02-12 of 84

Polish – pol Norwegian – norEstonian – est Portuguese – porFinnish – fin Romanian – rumFrench – fre Romansh - rohGerman – ger Slovak – sloGreek – gre Slovenian – slvHungarian – hun Spanish – spaIrish – gle Swedish – sweIcelandic – iceThe list of all the codes is defined at http://www.loc.gov/standards/iso639-2/

Regional languages also are included in this list.

EXAMPLE GetCapabilities Request KPV Encoding:

http://www.example.com/srv?REQUEST=GetCapabilities&LANGUAGE=eng

A.2 Scenario 1 – Get Harmonized Spatial Data Service Metadata Response

<?xml version="1.0" encoding="UTF-8"?><Capabilities xmlns="http://www.opengis.net/ows/1.1" xmlns:ows="http://www.opengis.net/ows/1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ins_com="http://inspire.ec.europa.eu/schemas/common/1.0" xmlns:ins_vs="http://inspire.ec.europa.eu/schemas/inspire_vs_ows11/1.0" version="1.0.0" xsi:schemaLocation="http://www.opengis.net/ows/1.1 http://schemas.opengis.net/ows/1.1.0/Examples/exampleCapabilities.xsd http://ins-pire.ec.europa.eu/schemas/inspire_vs_ows11/1.0 http://inspire.ec.europa.eu/schemas/inspire_vs_ows11/1.0/inspire_vs_ows_11.xsd">

<ows:OperationsMetadata><ows:Operation name="GetCapabilities">

<ows:DCP><ows:HTTP>

<ows:Get xlink:href="http://www.example.com/service.cgi?"><ows:Constraint name="GetEncoding">

<ows:AllowedValues><ows:Value>KVP</ows:Value>

</ows:AllowedValues></ows:Constraint>

</ows:Get><ows:Post xlink:href="http://www.example.com/service.cgi?">

<ows:Constraint name="PostEncoding"><ows:AllowedValues>

<ows:Value>SOAP</ows:Value></ows:AllowedValues>

http://www.example.com/srv?REQUEST=GetCapabilities&LANGUAGE=eng

2016-02-12 of 84

</ows:Constraint></ows:Post>

</ows:HTTP></ows:DCP>

</ows:Operation><ows:Operation name="DescribeServiceOperation">

<ows:DCP><ows:HTTP>

<ows:Get xlink:href="http://www.dinoservices.nl/geo3dmodelweb-services-1/Geo3DModelService?wsdl">



</ows:Constraint></ows:Get>


</ows:Operation><ins_vs:ExtendedCapabilities>

<ins_com:MetadataUrl><ins_com:URL>http://link-to/discovery-metadata</ins_com:URL>

</ins_com:MetadataUrl><ins_com:SupportedLanguages>

<ins_com:DefaultLanguage><ins_com:Language>dan</ins_com:Language>

</ins_com:DefaultLanguage><ins_com:SupportedLanguage>

<ins_com:Language>eng</ins_com:Language></ins_com:SupportedLanguage>

</ins_com:SupportedLanguages><ins_com:ResponseLanguage>

<ins_com:Language>eng</ins_com:Language></ins_com:ResponseLanguage>

</ins_sds:ExtendedCapabilities></ows:OperationsMetadata>

</Capabilities>

A.3 Scenario 2 – Get Harmonized Spatial Data Service Metadata Response

<?xml version="1.0" encoding="UTF-8"?><Capabilities xmlns="http://www.opengis.net/ows/1.1" xmlns:ows="http://www.opengis.net/ows/1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ins_com="http://inspire.ec.europa.eu/schemas/common/1.0" xmlns:ins_sds="http://inspire.ec.europa.eu/schemas/inspire_sds_ows11/1.0" xmlns:ins_qos="http://to-be-provided/schemas/qos/1.0" xmlns:ins_sdsc="http://to-be-provided/schemas/sdsc/1.0" version="1.0.0" xsi:schemaLocation="http://www.opengis.net/ows/1.1 http://example/example-Capabilities.xsd http://inspire.ec.europa.eu/schemas/inspire_vs_ows11/1.0 http://example/inspire_sds_ows_11.xsd">

<ows:ServiceIdentification>


2016-02-12 of 84

<ows:Title>Geo 3D Model service</ows:Title><ows:Abstract>This Spatial Data Service supports various operations on

the Digital Subsurface Models (Regis, DGM and GeoTop) provided by the Geo-logical Survey of the Netherlands. There is for example an operation to create a “virtual borehole” through one of the subsurface models for any given location in the Netherlands. The result can either be returned as Xml data or as a graphical representation. There is also supported for creating a VerticalSection a depthSection and many others. All operations and re-turned values are in the EPSG:28992 (RDNew) coordinate reference system.</ows:Abstract>

<ows:Keywords><ows:Keyword>infoCoverageAccessService</ows:Keyword><ows:Keyword>subsurface</ows:Keyword><ows:Keyword>geology</ows:Keyword><ows:Keyword>Netherlands</ows:Keyword><ows:Keyword>3D model</ows:Keyword>

</ows:Keywords><ows:ServiceType>other</ows:ServiceType><ows:ServiceTypeVersion>1.0.0</ows:ServiceTypeVersion><ows:Fees>none</ows:Fees><ows:AccessConstraints>TNO terms and conditions apply</ows:AccessCon-

straints></ows:ServiceIdentification><ows:ServiceProvider>

<ows:ProviderName>Geological Survey of the Netherlands</ows:Provider-Name>

<ows:ServiceContact><ows:IndividualName>Servicedesk Geological Survey of the Nether-

lands</ows:IndividualName><ows:ContactInfo>

<ows:Address> <ows:Elec-tronicMailAddress>[email protected]</ows:ElectronicMailAddress>

</ows:Address></ows:ContactInfo>

</ows:ServiceContact></ows:ServiceProvider><ows:OperationsMetadata>

<ows:Operation name="GetCapabilities"><ows:DCP>

<ows:HTTP><ows:Get xlink:href="http://www.example.com/service.cgi?">

<ows:Constraint name="GetEncoding"><ows:AllowedValues>

<ows:Value>KVP</ows:Value></ows:AllowedValues>

</ows:Constraint></ows:Get><ows:Post xlink:href="http://www.example.com/service.cgi?">



</ows:Constraint></ows:Post>


</ows:Operation><ows:Operation name="sampleColumn">

<ows:DCP>

2016-02-12 of 84

<ows:HTTP><ows:Post xlink:href="http://www.dinoservices.nl/geo3dmodelweb-

services-1/Geo3DModelService?wsdl"><ows:Constraint name="GetEncoding">

<ows:AllowedValues><ows:Value>SOAP</ows:Value>


</ows:Post></ows:HTTP>

</ows:DCP></ows:Operation>

<ows:Operation name="drawColumn"><ows:DCP>

<ows:HTTP><ows:Post xlink:href="http://www.dinoservices.nl/geo3dmodelweb-

services-1/Geo3DModelService?wsdl"><ows:Constraint name="GetEncoding">

<ows:AllowedValues><ows:Value>SOAP</ows:Value>


</ows:Post></ows:HTTP>

</ows:DCP></ows:Operation>...

<ins_sds:ExtendedCapabilities>

<ins_com:ResourceLocator><ins_com:URL/>

</ins_com:ResourceLocator><ins_com:ResourceType>service</ins_com:ResourceType><ins_com:TemporalReference/><ins_com:Conformity>

<ins_com:Specification><ins_com:Title>Webservice for making virtual boreholes in the

Digital Subsurface Models of the Netherlands</ins_com:Title><ins_com:DateOfPublication>2011-11-03</ins_com:DateOfPublica-

tion></ins_com:Specification><ins_com:Degree>notEvaluated</ins_com:Degree>

</ins_com:Conformity><ins_com:MetadataPointOfContact>

<ins_com:OrganisationName/><ins_com:EmailAddress>[email protected]</ins_com:EmailAddress>

</ins_com:MetadataPointOfContact><ins_com:MetadataDate>2010-12-08</ins_com:MetadataDate>

<ins_com:SpatialDataServiceType>other</ins_com:SpatialDataServiceType><ins_com:MandatoryKeyword>

<ins_com:KeywordValue>infoCoverageAccessService</ins_com:KeywordValue>

</ins_com:MandatoryKeyword><ins_com:SupportedLanguages>

<ins_com:DefaultLanguage><ins_com:Language>dan</ins_com:Language>

2016-02-12 of 84

</ins_com:DefaultLanguage><ins_com:SupportedLanguage>

<ins_com:Language>eng</ins_com:Language></ins_com:SupportedLanguage>

</ins_com:SupportedLanguages><ins_com:ResponseLanguage>

<ins_com:Language>eng</ins_com:Language></ins_com:ResponseLanguage><ins_qos:QualityOfService>

<ins_qos:criteria>availability</ins_qos:criteria><ins_qos:unit>percentage of time</ins_qos:unit><ins_qos:value>99.0</ins_qos:value><ins_qos:measurementDescription> Availability on yearly basis, ex-

pressed as percentage of time</ins_qos:measurementDescription></ins_qos:QualityOfService><ins_qos:QualityOfService>

<ins_qos:criteria>performance</ins_qos:criteria><ins_qos:unit>seconds</ins_qos:unit><ins_qos:value>1.457</ins_qos:value><ins_qos:measurementDescription>Average response time in

seconds</ins_qos:measurementDescription></ins_qos:QualityOfService><ins_qos:QualityOfService>

<ins_qos:criteria>capacity</ins_qos:criteria><ins_qos:unit>number of requests per second</ins_qos:unit><ins_qos:value>20</ins_qos:value><ins_qos:measurementDescription> Maximum number of simultaneous

requests per second meeting the performance criteria</ins_qos:measurement-Description>

</ins_qos:QualityOfService><ins_sdsc:Category>invocable</ins_sdsc:Category>

</ins_vs:ExtendedCapabilities></ows:OperationsMetadata>

</Capabilities>


2016-02-12 of 84

Annex B – Metadata textual example

NOTE This example will be added (based on the example in Annex C) once the remainder of the document has been finalised.


2016-02-12 of 84

Annex C – Complete XML Encoding exampleThe code below shows a complete example of Inspire SDS. The colours used are related to the metadata to be provided for each class of conformance presented in the TG.

InvocableInteroperableHarmonised

Note: in this example the harmonisation level has the containsOperation filled. As you can see at paragraph 5.9.2, it is not mandatory but conditional: the choice is between providing containsOperation element or a WSDL (example in Annex D) in order to describe the service operations.

H.2 XML encoding example with GML 3.2.0

<?xml version="1.0" encoding="UTF-8"?><gmd:MD_Metadata xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gmx="http://www.isotc211.org/2005/gmx" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gml="http://www.opengis.net/gml" xmlns:gsr="http://www.isotc211.org/2005/gsr" xmlns:gss="http://www.isotc211.org/2005/gss" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:srv="http://www.isotc211.org/2005/srv" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-ins-tance" xsi:schemaLocation="http://www.isotc211.org/2005/gmx http://sche-mas.opengis.net/iso/19139/20060504/gmx/gmx.xsd http://www.isotc211.org/2005/srv http://schemas.opengis.net/iso/19139/20060504/srv/srv.xsd">

<gmd:fileIdentifier><gco:CharacterString>1b5e8d67-758a-43c5-908b-2c8a6b93556a</gco:Charac-

terString></gmd:fileIdentifier><gmd:language>

<gmd:LanguageCode codeList="http://www.isotc211.org/2005/resources/Co-delist/gmxCodelists.xml#LanguageCode" codeListValue="eng">eng</gmd:Langua-geCode>

</gmd:language><gmd:hierarchyLevel>

<gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/Co-delist/gmxCodelists.xml#MD_ScopeCode" codeListValue="service">service</gmd:MD_ScopeCode>

</gmd:hierarchyLevel><gmd:contact>


<gco:CharacterString>TNO Geological Survey of the Netherlands</gco:CharacterString>




<gco:CharacterString>[email protected]</gco:CharacterS-tring>

</gmd:electronicMailAddress>

2016-02-12 of 84

</gmd:CI_Address></gmd:address>

</gmd:CI_Contact></gmd:contactInfo><gmd:role>

<gmd:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_RoleCode" codeListValue="pointOfCon-tact">pointOfContact</gmd:CI_RoleCode>

</gmd:role></gmd:CI_ResponsibleParty>

</gmd:contact><gmd:dateStamp>

<gco:Date>2012-12-05</gco:Date></gmd:dateStamp><gmd:metadataStandardName>

<gco:CharacterString>INSPIRE Spatial Data Services Community Profile of ISO 19115:2005/19139</gco:CharacterString>

</gmd:metadataStandardName><gmd:metadataStandardVersion>

<gco:CharacterString>1.0</gco:CharacterString></gmd:metadataStandardVersion><gmd:referenceSystemInfo>

<gmd:MD_ReferenceSystem><gmd:referenceSystemIdentifier>

<gmd:RS_Identifier><gmd:code>

<gco:CharacterString>http://www.opengis.net/def/crs/EPSG/0/28992</gco:CharacterString>

</gmd:code><gmd:codeSpace>

<gco:CharacterString>EPSG</gco:CharacterString></gmd:codeSpace>

</gmd:RS_Identifier></gmd:referenceSystemIdentifier>

</gmd:MD_ReferenceSystem></gmd:referenceSystemInfo><gmd:identificationInfo>

<srv:SV_ServiceIdentification><gmd:citation>


<gco:CharacterString>Geo 3D Model service</gco:CharacterS-tring>




<gmd:CI_DateTypeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode" codeListValue="publication">publication</gmd:CI_DateTypeCode>



</gmd:citation>


2016-02-12 of 84

<gmd:abstract><gco:CharacterString>This Spatial Data Service supports various

operations on the Digital Subsurface Models (Regis, DGM and GeoTop) provi-ded by the Geological Survey of the Netherlands. There is for example an operation to create a â€œvirtual boreholeâ€� through one of the subsurface models for any given location in the Netherlands. The result can either be returned as Xml data or as a graphical representation. There is also sup-ported for creating a VerticalSection a depthSection and many others. All operations and returned values are in the EPSG:28992 (RDNew) coordinate reference system. The models have a resolution of 100x100 meters horizon-tally and have varying vertical resolutions. </gco:CharacterString>

</gmd:abstract><gmd:pointOfContact>


<gco:CharacterString>Geological Survey of the Netherlands</gco:CharacterString>




<gco:CharacterString>[email protected]</gco:Charac-terString>

</gmd:electronicMailAddress></gmd:CI_Address>

</gmd:address></gmd:CI_Contact>

</gmd:contactInfo><gmd:role>

<gmd:CI_RoleCode codeList="http://www.isotc211.org/2005/re-sources/Codelist/gmxCodelists.xml#CI_RoleCode" codeListValue="custodian">custodian</gmd:CI_RoleCode>

</gmd:role></gmd:CI_ResponsibleParty>

</gmd:pointOfContact><gmd:descriptiveKeywords>

<gmd:MD_Keywords><gmd:keyword>

<gco:CharacterString>infoCoverageAccessService</gco:Charac-terString>

</gmd:keyword><gmd:keyword>

<gco:CharacterString>subsurface</gco:CharacterString></gmd:keyword><gmd:keyword>

<gco:CharacterString>geology</gco:CharacterString></gmd:keyword><gmd:keyword>

<gco:CharacterString>Netherlands</gco:CharacterString></gmd:keyword><gmd:keyword>

<gco:CharacterString>3D model</gco:CharacterString></gmd:keyword>

</gmd:MD_Keywords></gmd:descriptiveKeywords><gmd:resourceConstraints>

<gmd:MD_Constraints>


2016-02-12 of 84

<gmd:useLimitation><gco:CharacterString>Creative Commons Free Culture.</gco:Cha-

racterString></gmd:useLimitation>

</gmd:MD_Constraints></gmd:resourceConstraints><gmd:resourceConstraints>

<gmd:MD_Constraints><gmd:useLimitation>

<gmx:Anchor xlink:href="http://creativecommons.org/licenses/by/3.0/deed.nl">Creative Commons - Attribution 3.0 Unported</gmx:Anchor>

</gmd:useLimitation></gmd:MD_Constraints>

</gmd:resourceConstraints><gmd:resourceConstraints>

<gmd:MD_LegalConstraints><gmd:accessConstraints>

<gmd:MD_RestrictionCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_RestrictionCode" codeListValue="otherRestrictions">otherRestrictions</gmd:MD_Restriction-Code>


<gco:CharacterString>no limitations</gco:CharacterString></gmd:otherConstraints>

</gmd:MD_LegalConstraints></gmd:resourceConstraints><srv:serviceType>

<gco:LocalName>other</gco:LocalName></srv:serviceType><srv:extent>

<gmd:EX_Extent><gmd:geographicElement>

<gmd:EX_GeographicBoundingBox><gmd:westBoundLongitude>

<gco:Decimal>3.047</gco:Decimal></gmd:westBoundLongitude><gmd:eastBoundLongitude>

<gco:Decimal>50.670</gco:Decimal></gmd:eastBoundLongitude><gmd:southBoundLatitude>

<gco:Decimal>7.276</gco:Decimal></gmd:southBoundLatitude><gmd:northBoundLatitude>

<gco:Decimal>53.612</gco:Decimal></gmd:northBoundLatitude>

</gmd:EX_GeographicBoundingBox></gmd:geographicElement>

</gmd:EX_Extent></srv:extent><srv:extent>

<gmd:EX_Extent><gmd:temporalElement>

<gmd:EX_TemporalExtent><gmd:extent>

<gml:TimeInstant gml:id="myid"><gml:timePosition>2001</gml:timePosition>

</gml:TimeInstant></gmd:extent>

2016-02-12 of 84

</gmd:EX_TemporalExtent></gmd:temporalElement>

</gmd:EX_Extent></srv:extent><srv:couplingType>

<srv:SV_CouplingType codeList="./resources/codeList.xml#SV_Cou-plingType" codeListValue="tight">tight</srv:SV_CouplingType>

</srv:couplingType><srv:containsOperations>


<gco:CharacterString>sampleColumn</gco:CharacterString></srv:operationName><srv:DCP>

<srv:DCPList codeList="http://someurl#DCPList" codeListValue="HTTPGet"/>

</srv:DCP><srv:parameters>


<gco:aName><gco:CharacterString>model</gco:CharacterString>


<gco:TypeName><gco:aName>

<gco:CharacterString>CharacterString</gco:Cha-racterString>

</gco:aName></gco:TypeName>

</gco:attributeType></srv:name><srv:direction>

<srv:SV_ParameterDirection>in</srv:SV_ParameterDirec-tion>

</srv:direction><srv:optionality>


<gco:Boolean>false</gco:Boolean></srv:repeatability><srv:valueType>


<gco:CharacterString>string</gco:CharacterString></gco:aName>

</gco:TypeName></srv:valueType>



<gco:aName><gco:CharacterString>xCoordinate</gco:CharacterString>


2016-02-12 of 84










<gco:CharacterString>double</gco:CharacterString></gco:aName>




<gco:aName><gco:CharacterString>yCoordinate</gco:CharacterString>











<gco:CharacterString>double</gco:CharacterString></gco:aName>



2016-02-12 of 84



<gco:aName><gco:CharacterString>resolution</gco:CharacterString>











<gco:CharacterString>int</gco:CharacterString></gco:aName>




<gco:aName><gco:CharacterString>coordinateSystem</gco:CharacterS-

tring></gco:aName><gco:attributeType>







<gco:CharacterString>optional</gco:CharacterString></srv:optionality>


2016-02-12 of 84

<srv:repeatability><gco:Boolean>false</gco:Boolean>

</srv:repeatability><srv:valueType>


<gco:CharacterString>AvailableCoordinateSystemType</gco:CharacterString></gco:aName>


</srv:SV_Parameter></srv:parameters><srv:connectPoint>


<gmd:URL>http://www.dinoservices.nl/geo3dmodelwebser-vices-1/Geo3DModelService</gmd:URL>



</srv:containsOperations><srv:operatesOn xlink:href="http://www.ign.es/csw-inspire/srv/spa/

csw?SERVICE=CSW&VERSION=2.0.2&REQUEST=GetRecordById&outputSche-ma=http://www.isotc211.org/2005/gmd&ElementSetName=full&ID=spaign-capaOI.MosaicElement-wmspnoama20130315#OI.MosaicElement"/>

<srv:operatesOn xlink:href="http://www.ign.es/csw-inspire/srv/spa/csw?SERVICE=CSW&VERSION=2.0.2&REQUEST=GetRecordById&outputSche-ma=http://www.isotc211.org/2005/gmd&ElementSetName=full&ID=spaign-capaOI.OrthoimageCoverage-wmspnoama20130315#OI.OrthoimageCoverage"/>

</srv:SV_ServiceIdentification></gmd:identificationInfo><gmd:distributionInfo>

<gmd:MD_Distribution><gmd:transferOptions>

<gmd:MD_DigitalTransferOptions><gmd:onLine>


<gmd:URL>http://www.dinoservices.nl/geo3dmodelwebser-vices-1/Geo3DModelService</gmd:URL>

</gmd:linkage><gmd:function>

<gmd:CI_OnLineFunctionCode codeList="http://ins-pire.ec.europa.eu/draft-schemas/resources/Codelist/gmxCodelist.xml#INSPIRE_CI_OnLineFunctionCode" codeListValue="accessPoint">accessPoint</gmd:CI_OnLineFunctionCode>

</gmd:function></gmd:CI_OnlineResource>

</gmd:onLine><gmd:onLine>


<gmd:URL>http://link-to/get-service-metadata</gmd:URL></gmd:linkage><gmd:function>

<gmd:CI_OnLineFunctionCode codeList="http://ins-pire.ec.europa.eu/draft-schemas/resources/Codelist/

2016-02-12 of 84

gmxCodelist.xml#INSPIRE_CI_OnLineFunctionCode" codeListValue="providesSer-viceMetadata">providesServiceMetadata</gmd:CI_OnLineFunctionCode>

</gmd:function></gmd:CI_OnlineResource>

</gmd:onLine></gmd:MD_DigitalTransferOptions>

</gmd:transferOptions></gmd:MD_Distribution>

</gmd:distributionInfo><gmd:dataQualityInfo>

<gmd:DQ_DataQuality><gmd:scope>

<gmd:DQ_Scope><gmd:level>

<gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/re-sources/Codelist/gmxCodelists.xml#MD_ScopeCode" codeListValue="service"/>

</gmd:level></gmd:DQ_Scope>

</gmd:scope><gmd:report>

<gmd:DQ_DomainConsistency><gmd:result>

<gmd:DQ_ConformanceResult><gmd:specification>


<gmx:Anchor xlink:href=" http://in-spire.ec.europa.eu/metadata-codelist/Category/invocable">invocable</gmx:An-chor>







</gmd:specification><gmd:explanation>

<gco:CharacterString>Conformant to the conformance class "invocable SDS"</gco:CharacterString>



</gmd:DQ_ConformanceResult></gmd:result>

</gmd:DQ_DomainConsistency></gmd:report><gmd:report>

<gmd:DQ_ConceptualConsistency>

2016-02-12 of 84

<gmd:nameOfMeasure><gmx:Anchor> xlink:href="http://inspire.ec.europa.eu/metada-

ta-codelist/Criteria/availability">availability</gmx:Anchor></gmd:nameOfMeasure><gmd:measureIdentification>


<gco:CharacterString>INSPIRE_service_availability</gco:CharacterString>




OGC/1.0/unity"/><gmd:value>



</gmd:DQ_ConceptualConsistency></gmd:report><gmd:report>


<gmx:Anchor> xlink:href="http://inspire.ec.europa.eu/metada-ta-codelist/Criteria/performance">performance</gmx:Anchor>



<gco:CharacterString> INSPIRE_service_performance</gco:CharacterString>




SI/second"/><gmd:value>

<gco:Record>0.5</gco:Record></gmd:value>


</gmd:DQ_ConceptualConsistency></gmd:report><gmd:report>


<gmx:Anchor> xlink:href="http://inspire.ec.europa.eu/metada-ta-codelist/Criteria/capacity">capacity</gmx:Anchor>


2016-02-12 of 84

<gco:CharacterString>INSPIRE_service_capacity</gco:Cha-racterString>



<gmd:DQ_QuantitativeResult><gmd:valueUnit gco:nilReason="inapplicable"/><gmd:value>



</gmd:DQ_ConceptualConsistency></gmd:report>

</gmd:DQ_DataQuality></gmd:dataQualityInfo>

</gmd:MD_Metadata>

2016-02-12 of 84

Annex D – WSDL Example

Open issue: Is this example still needed in the TGs?

The following code shows a WSLD example that can be provided in order to fulfil TG Requirement 17.

Original URL: http://www.dinoservices.nl/geo3dmodelwebservices-1/Geo3DModelService?wsdl

The code highlighted in yellow is an addition to the original example in order to include an example of a possible way of adding the getCapabilities operation in the WSDL document.

<?xml version="1.0" encoding="UTF-8"?><ws:definitions xmlns:ws="http://schemas.xmlsoap.org/wsdl/" xmlns:types="http://ws.geo3dmodel.dino.nitg.tno.nl/types" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:gml="http://www.opengis.net/gml" xmlns:tns="http://ws.geo3dmodel.dino.nitg.tno.nl/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xmime="http://www.w3.org/2005/05/xmlmime" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://ws.geo3dmodel.dino.nitg.tno.nl/" name="Geo3DMod-elService">

<ws:documentation>This WSDL describes a webservice for making "virtual" boreholes in the

Digital Subsurface Models of DINO. The following operations are provided:1. sampleColumn creates a synthetic borehole for the specified loca-

tion using the specified model.See the documentation in the schema for the types (available at the

schemaLocation below) for additional details.2. listModels lists all models available for sampling.

</ws:documentation><ws:types>

<xs:schema><xs:import namespace="http://ws.geo3dmodel.dino.nitg.tno.nl/types"

schemaLocation="http://www.dinoservices.nl:80/geo3dmodelwebservices-1/Geo3DModelService?xsd=1"/>

</xs:schema></ws:types><ws:message name="sampleColumn">

<ws:part name="parameters" element="types:sampleColumn"/></ws:message><ws:message name="sampleColumnResponse">

<ws:part name="parameters" element="types:sampleColumnResponse"/></ws:message><ws:message name="drawColumn">

<ws:part name="parameters" element="types:drawColumn"/></ws:message><ws:message name="drawColumnResponse">

<ws:part name="parameters" element="types:drawColumnResponse"/></ws:message><ws:message name="listModels">

<ws:part name="parameters" element="types:listModels"/>

http://www.dinoservices.nl/geo3dmodelwebservices-1/Geo3DModelService?wsdl


2016-02-12 of 84

</ws:message><ws:message name="listDocuments">

<ws:part name="parameters" element="types:listDocuments"/></ws:message><ws:message name="listRasters">

<ws:part name="parameters" element="types:listRasters"/></ws:message><ws:message name="listModelsResponse">

<ws:part name="parameters" element="types:listModelsResponse"/></ws:message><ws:message name="listDocumentsResponse">

<ws:part name="parameters" element="types:listDocumentsResponse"/></ws:message><ws:message name="listRastersResponse">

<ws:part name="parameters" element="types:listRastersResponse"/></ws:message><ws:message name="describeModel">

<ws:part name="parameters" element="types:describeModel"/></ws:message><ws:message name="describeModelResponse">

<ws:part name="parameters" element="types:describeModelResponse"/></ws:message><ws:message name="sampleDepth">

<ws:part name="parameters" element="types:sampleDepth"/></ws:message><ws:message name="sampleDepthResponse">

<ws:part name="parameters" element="types:sampleDepthResponse"/></ws:message><ws:message name="drawDepthSection">

<ws:part name="parameters" element="types:drawDepthSection"/></ws:message><ws:message name="drawDepthSectionResponse">

<ws:part name="parameters" element="types:drawDepthSectionResponse"/></ws:message><ws:message name="drawVerticalSection">

<ws:part name="parameters" element="types:drawVerticalSection"/></ws:message><ws:message name="drawVerticalSectionResponse">

<ws:part name="parameters" element="types:drawVerticalSectionRe-sponse"/>

</ws:message><ws:message name="userInputErrorResponse">

<ws:part name="parameters" element="types:userInputErrorResponse"/></ws:message><ws:portType name="Geo3DModelPortType">

<ws:operation name="sampleColumn"><ws:input message="tns:sampleColumn" wsaw:Action="http://ws.geo3d-

model.dino.nitg.tno.nl/sampleColumnRequest"/><ws:output message="tns:sampleColumnResponse" wsaw:Action="http://

ws.geo3dmodel.dino.nitg.tno.nl/sampleColumnResponse"/><ws:fault name="fault" message="tns:userInputErrorResponse"/>

</ws:operation><ws:operation name="drawColumn">

<ws:input message="tns:drawColumn" wsaw:Action="http://ws.geo3dmod-el.dino.nitg.tno.nl/drawColumnRequest"/>

<ws:output message="tns:drawColumnResponse" wsaw:Action="http://ws.-geo3dmodel.dino.nitg.tno.nl/drawColumnResponse"/>

<ws:fault name="fault" message="tns:userInputErrorResponse"/></ws:operation>


2016-02-12 of 84

<ws:operation name="listModels"><ws:input message="tns:listModels" wsaw:Action="http://ws.geo3dmod-

el.dino.nitg.tno.nl/listModelsRequest"/><ws:output message="tns:listModelsResponse" wsaw:Action="http://ws.-

geo3dmodel.dino.nitg.tno.nl/listModelsResponse"/><ws:fault name="fault" message="tns:userInputErrorResponse"/>

</ws:operation><ws:operation name="listDocuments">

<ws:input message="tns:listDocuments" wsaw:Action="http://ws.geo3d-model.dino.nitg.tno.nl/listDocumentsRequest"/>

<ws:output message="tns:listDocumentsResponse" wsaw:Action="http://ws.geo3dmodel.dino.nitg.tno.nl/listDocumentsResponse"/>

<ws:fault name="fault" message="tns:userInputErrorResponse"/></ws:operation><ws:operation name="listRasters">

<ws:input message="tns:listRasters" wsaw:Action="http://ws.geo3dmod-el.dino.nitg.tno.nl/listRastersRequest"/>

<ws:output message="tns:listRastersResponse" wsaw:Action="http://ws.geo3dmodel.dino.nitg.tno.nl/listRastersResponse"/>

<ws:fault name="fault" message="tns:userInputErrorResponse"/></ws:operation><ws:operation name="describeModel">

<ws:input message="tns:describeModel" wsaw:Action="http://ws.geo3d-model.dino.nitg.tno.nl/describeModelRequest"/>

<ws:output message="tns:describeModelResponse" wsaw:Action="http://ws.geo3dmodel.dino.nitg.tno.nl/describeModelResponse"/>

<ws:fault name="fault" message="tns:userInputErrorResponse"/></ws:operation><ws:operation name="sampleDepth">

<ws:input message="tns:sampleDepth" wsaw:Action="http://ws.geo3dmod-el.dino.nitg.tno.nl/sampleDepthRequest"/>

<ws:output message="tns:sampleDepthResponse" wsaw:Action="http://ws.geo3dmodel.dino.nitg.tno.nl/sampleDepthResponse"/>

<ws:fault name="fault" message="tns:userInputErrorResponse"/></ws:operation><ws:operation name="drawDepthSection">

<ws:input message="tns:drawDepthSection" wsaw:Action="http://ws.-geo3dmodel.dino.nitg.tno.nl/drawDepthSectionRequest"/>

<ws:output message="tns:drawDepthSectionResponse" wsaw:Action="http://ws.geo3dmodel.dino.nitg.tno.nl/drawDepthSectionRe-sponse"/>

<ws:fault name="fault" message="tns:userInputErrorResponse"/></ws:operation><ws:operation name="drawVerticalSection">

<ws:input message="tns:drawVerticalSection" wsaw:Action="http://ws.-geo3dmodel.dino.nitg.tno.nl/drawVerticalSectionRequest"/>

<ws:output message="tns:drawVerticalSectionResponse" wsaw:Action="http://ws.geo3dmodel.dino.nitg.tno.nl/drawVerticalSectionRe-sponse"/>

<ws:fault name="fault" message="tns:userInputErrorResponse"/></ws:operation>

</ws:portType><ws:binding name="Geo3DModelServicePortBinding" type="tns:Geo3DModelPort-

Type"><soap:binding transport="http://schemas.xmlsoap.org/soap/http"

style="document"/><ws:operation name="sampleColumn">

<soap:operation soapAction="sampleColumn"/><ws:input>


2016-02-12 of 84

<soap:body use="literal"/></ws:input><ws:output>

<soap:body use="literal"/></ws:output><ws:fault name="fault">

<soap:fault name="fault"/></ws:fault>

</ws:operation><ws:operation name="drawColumn">

<soap:operation soapAction="drawColumn"/><ws:input>




</ws:operation><ws:operation name="listModels">

<soap:operation soapAction="listModels"/><ws:input>




</ws:operation><ws:operation name="listDocuments">

<soap:operation soapAction="listDocuments"/><ws:input>




</ws:operation><ws:operation name="listRasters">

<soap:operation soapAction="listRasters"/><ws:input>




</ws:operation><ws:operation name="describeModel">

<soap:operation soapAction="describeModel"/>

2016-02-12 of 84

<ws:input><soap:body use="literal"/>

</ws:input><ws:output>



</ws:operation><ws:operation name="sampleDepth">

<soap:operation soapAction="sampleDepth"/><ws:input>




</ws:operation><ws:operation name="drawDepthSection">

<soap:operation soapAction="drawDepthSection"/><ws:input>




</ws:operation><ws:operation name="drawVerticalSection">

<soap:operation soapAction="drawVerticalSection"/><ws:input>




</ws:operation></ws:binding><ws:service name="Geo3DModelService">

<ws:port name="Geo3DModelServicePort" binding="tns:Geo3DModelService-PortBinding">

<soap:address location="http://www.dinoservices.nl:80/geo3dmodelweb-services-1/Geo3DModelService"/>

</ws:port></ws:service><ws:message name="GetCapabilitiesRequest">

<ws:part name="Body" element="csw:GetCapabilities"/></ws:message>


2016-02-12 of 84

<ws:message name="DescribeRecordRequest"><ws:part name="Body" element="csw:DescribeRecord"/>

</ws:message><ws:message name="GetRecordsRequest">

<ws:part name="Body" element="csw:GetRecords"/></ws:message><ws:message name="GetRecordByIdRequest">

<ws:part name="Body" element="csw:GetRecordById"/></ws:message><ws:message name="GetDomainRequest">

<ws:part name="Body" element="csw:GetDomain"/></ws:message><ws:message name="HarvestRequest">

<ws:part name="Body" element="csw:Harvest"/></ws:message><ws:message name="TransactionRequest">

<ws:part name="Body" element="csw:Transaction"/></ws:message><ws:portType name="csw">

<ws:operation name="csw.getCapabilities"><ws:input message="csw-req:GetCapabilitiesRequest"/><ws:output message="csw-resp:GetCapabilitiesResponse"/><ws:fault name="ServiceExceptionReport" message="csw-resp:ServiceEx-

ceptionReport"/></ws:operation><ws:operation name="csw.describeRecord">

<ws:input message="csw-req:DescribeRecordRequest"/><ws:output message="csw-resp:DescribeRecordResponse"/><ws:fault name="ServiceExceptionReport" message="csw-resp:ServiceEx-

ceptionReport"/></ws:operation><ws:operation name="csw.getRecords">

<ws:input message="csw-req:GetRecordsRequest"/><ws:output message="csw-resp:GetRecordsResponse"/><ws:fault name="ServiceExceptionReport" message="csw-resp:ServiceEx-

ceptionReport"/></ws:operation><ws:operation name="csw.getRecordById">

<ws:input message="csw-req:GetRecordByIdRequest"/><ws:output message="csw-resp:GetRecordByIdResponse"/><ws:fault name="ServiceExceptionReport" message="csw-resp:ServiceEx-

ceptionReport"/></ws:operation><ws:operation name="csw.getDomain">

<ws:input message="csw-req:GetDomainRequest"/><ws:output message="csw-resp:GetDomainResponse"/><ws:fault name="ServiceExceptionReport" message="csw-resp:ServiceEx-

ceptionReport"/></ws:operation>

</ws:portType><ws:binding name="csw-GET" type="csw-req:csw">

<ws:documentation>CSW interface bound to the HTTP/1.1 GET method.</ws:documentation>

<http:binding verb="GET"/><ws:operation name="csw.getCapabilities">

<http:operation location="GetCapabilities"/><ws:input>

<http:urlEncoded/></ws:input>


2016-02-12 of 84

<ws:output><mime:mimeXml/>

</ws:output><ws:fault name="ServiceExceptionReport">

<soap:fault use="literal" name="ServiceExceptionReport"/></ws:fault>

</ws:operation><ws:operation name="csw.getRecordById">

<http:operation location="GetRecordById"/><ws:input>

<http:urlEncoded/></ws:input><ws:output>

<mime:mimeXml/></ws:output><ws:fault name="ServiceExceptionReport">

<soap:fault use="literal" name="ServiceExceptionReport"/></ws:fault>

</ws:operation></ws:binding><ws:service name="CSW">

<ws:documentation> This is an example </ws:documentation>

<ws:port binding="csw-http-kvp:csw-GET" name="csw-GET-Port"><http:address location="http://someurl.com/example/services/CSWDis-

covery"/></ws:port>

</ws:service></ws:definitions>


2016-02-12 of 84

Annex E – SDS examplesA web site with examples of SDS included in the yearly Member States’ monitoring of INSPIRE data and services is available at http://inspire.ec.europa.eu/examples/sds

Open issue: The exact URI for the examples page still needs to be decided.

http://inspire.ec.europa.eu/examples/sds

Draft Technical Guidance for INSPIRE Download Services Web viewTechnical Guidance for spatial data...

Documents

Transcript of Draft Technical Guidance for INSPIRE Download Services Web viewTechnical Guidance for spatial data...