Technical Guidance to implement INSPIRE View services

Transcription

1 INSPIRE Infrastructure for Spatial Information in Europe Technical Guidance to implement INSPIRE View Services IOC Task Force Network Services Title Creator Date Subject Status Version 2.12 Publisher Type Description Contributor Format Source Rights Technical Guidance to implement INSPIRE View services IOC Task Force Network Services Implementing INSPIRE View Services IOC Task Force Network Services Text This document identifies the recommendations and describes the implementation guidelines for View Services to fulfil the requirements of the INSPIRE directive and the Regulation on INSPIRE Network Services, Annex III View Services. Members of the INSPIRE Drafting Team Network Services, members of the IOC Task Force Network Services MS Word (doc) Network Services Drafting Team, Technical Guidance for INSPIRE View Services v2.0 Open access Identifier Technical Guidance View Services v 212 Language Relation Coverage EN Not applicable Project duration

2 Technical Guidance View Services Page 2 of 74 TABLE OF CONTENTS 1. Preface Revision History Introduction 6 3. References INSPIRE Profile of ISO 19128:2005(E)9 3.1 General background View service operations Common requests parameters for the View service operations View service exceptions Get View Service Metadata operation General GetCapabilities operation GetCapabilities response View service metadata Identification RESOURCE TITLE RESOURCE ABSTRACT RESOURCE TYPE RESOURCE LOCATOR COUPLED RESOURCE SPATIAL DATA SERVICE TYPE KEYWORD GEOGRAPHIC BOUNDING BOX CONFORMITY Constraints related to access and use CONDITION FOR ACCESS AND USE LIMITATIONS ON PUBLIC ACCESS RESPONSIBLE ORGANISATION Metadata on metadata METADATA POINT OF CONTACT METADATA DATE TEMPORAL REFERENCE SPATIAL RESOLUTION Operations Metadata GetCapabilities operation metadata GetMap operation metadata Link View Service operation metadata Languages Layers Metadata RESOURCE TITLE RESOURCE ABSTRACT KEYWORD GEOGRAPHIC BOUNDING BOX LINK TO METADATA ON THE SPATIAL DATASET NAME COORDINATE REFERENCE SYSTEMS STYLES LEGEND URL DIMENSION PAIRS.. 28

3 CATEGORY LAYER Get Map Operation GetMap operation GetMap request parameters VERSION REQUEST LAYERS STYLES CRS BBOX WIDTH and HEIGHT FORMAT TRANSPARENT BGCOLOR EXCEPTIONS TIME, ELEVATION and other sample dimension(s) Link View Service operation Language Requirements GetCapabilities-Operation GetMap-Operation Common concept for other operations (optional) Further Perspectives Extended Capabilities XML-Schema for Extended Capabilities for Language Requirements 45 Annex A INSPIRE Profile of Tiling WMS.46 Annex B Language capabilities extension for other profiles.47 WMS Profile47 WMS-C (WMS Tile Caching) Profile..50 Annex C Examples of SLD usage.54 Annex D Tests.56 1 IGNF tests with Geoserver (large scale vector database)..56 Annex E How View services work within INSPIRE59 Annex F The relation of view services to other technical components in INSPIRE 62 Annex G Quality of Services..63 Performance..63 Capacity63 Availability63 Annex H Extended Capabilities 65 INSPIRE XML Schema For Extended Capabilities.65 Design View..65 Schema67 INSPIRE Capabilities Response Document..68

4

5 Technical Guidance View Services Page 5 of Preface The scope of this document is to detail the INSPIRE technical requirements for View services based on the Regulation on INSPIRE Network Services, Annex III View Services, such that these services can be implemented consistently across Europe. This version of the Technical Guidance is still draft and the implementation recommendations are subject to validation through testing that will take place in the context of the Initial Operating Capability in the next few months. The final version is planned to be published towards the end of Revision History Date Release Editor Description 28 July Network Services Drafting Team Two approaches to include INSPIRE metadata as part of the Get View Service Metadata response have been 16 June Initial Operating Capability Task Force 16 June Initial Operating Capability Task Force 16 June Initial Operating Capability Task Force 16 June Initial Operating Capability Task Force 16 June Initial Operating Capability Task Force incorporated The INSPIRE extended Capabilities XML schema has been included in Annex H Links with other technical components in INSPIRE have been described based on the INSPIRE domain model A new interpretation and recommended implementation of the Link Discovery Service operation has been described An approach to implement the required Language parameter has been recommended General editorial changes

6 Technical Guidance View Services Page 6 of Introduction INSPIRE is a Directive proposed by the European Commission in July 2004 which defines the legal framework for the establishment and operation of an Infrastructure for Spatial Information in Europe. 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 INSPIRE 1 web site ( 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. The Commission is assisted in the process of adopting such rules by a regulatory committee composed by representatives of the Member States and European Parliament. The committee is chaired by a representative of the Commission (this is known as the Comitology procedure). The scope of this document is to detail the INSPIRE technical requirements for View services based on the Regulation on INSPIRE Network Services, such that these services can be implemented consistently across Europe. The Technical Guidance is 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. In the context of network services, the European de jure standard EN ISO 19128:2005(E) (WMS 1.3.0) has been identified as the relevant standard to implement INSPIRE View Services. Additional profiles, based on any other standard, can be discussed in annexes to this document as long as they conform with the Regulation on INSPIRE Network Services. Two other OGC de facto standards for portraying geographic information are associated with the EN ISO 19128:2005(E) : OGC Styled Layer Descriptor Profile of the Web Map Service Implementation Specification (05-078r4) and its corrigendum1 for OGC Implementation Specification SLD (07-123r1) ; 1

7 Technical Guidance View Services Page 7 of 74 OGC Symbology Encoding Implementation Specification (05-077r4), which is a language used for styling feature and coverage data, and independent of any service interface specification. This document will be publicly available as a non-paper, as it does not represent an official position of the Commission, and as such cannot be invoked in the context of legal procedures.

8 Technical Guidance View Services Page 8 of References This technical guidance incorporates, by dated or undated references, provisions from other publications. For dated references, subsequent amendments to or revisions of any of these publications apply to this guide only when incorporated in it by amendment or revision. For undated references, the latest edition of the publication referred to applies (including amendments). This technical guidance applies on the D en-00 Implementing Rule document (28 th of November 2008). These normative references are cited at the appropriate places in the text and the publications are listed hereafter: [1] INSPIRE Network services Architecture document ; [2] OGC r4-Version:1.1.0 (revision 4) - Symbology Encoding Implementation Specification OGC r4 Version: (revision 4) - Styled Layer Descriptor profile of the Web Map Service Implementation Specification ; [3] OpenGIS Catalogue Services Specification ISO Metadata Application Profile ; [4] ISO 19128:2005(E) : Geographic information Web map server interface ; [5] Technical Guidance Document for INSPIRE Discovery Services ; [6] INSPIRE NETWORK SERVICES SOAP Framework - ork.pdfhttp://inspire.jrc.ec.europa.eu/reports/implementingrules/network/inspire_network_services_soap_f ramework.pdf ; [7] INSPIRE Domain Model 0.9.1; [8] ISO 19115:2003(E) : Geographic Information Metadata; [9] Implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services - bl+u6m8ocwqlyrvb7ejr+potzwz/2wt/z/jftr7x0hnynbcjdi/bzr4zvdppaur0fohhej8jycn49fa= ; [10] INSPIRE Generic Conceptual Model (D2.5_v3.2). Other important normative references : INSPIRE, INS NS Commission Regulation (EC) 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 ; INSPIRE, 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). See also Corrigendum to INSPIRE Metadata Regulation ; INSPIRE, INS MD IMPL, INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO and EN ISO 19119, v1.1 ( ) ; Data Specifications : See ; ISO/IEC : 1993, Information technology Vocabulary Part 1: Fundamental terms ; ISO : 2005, Geographic information Services ; ISO 19119:2005 PDAM 1, Geographic information Services ; ISO/IEC Directives, Part 2 - Rules for the structure and drafting of International Standards ; EUR 2012 Map projection for Europe Institute for environment and sustainability, JRC, Eurogeographics 2001 ; W3C Recommendation (24 June 2003) : SOAP Version 1.2 Part 1: Messaging Framework, ; W3C. QoS for Web Services : Requirements and Possible Approaches.

9 Technical Guidance View Services Page 9 of INSPIRE Profile of ISO 19128:2005(E) 3.1 General background The base specification of an INSPIRE View Service relies on the ISO 19128:2005(E) international standard. An INSPIRE View Service will implement the minimal mandatory behaviour from an ISO 19128:2005(E) service, extended with the extensions required by the INSPIRE Directive and the Implementing Rules for View services. The 3.2 and subsequent sections specify required extensions to the base specification. They are laid down following the ISO 19128:2005(E) document structure, from its section 6.9. Meteorological data and services need special attention for implementation. Serving meteorological data through a WMS is technically only feasible for end products and not for basic meteorological data, which is complex and voluminous. The definition of these end products (and corresponding CRS) has to be available before they can be handled by a WMS. The use of ISO 19128:2005(E) de jure standard as a basis for implementing an INSPIRE View service implies that this service must comply with the basic WMS conformance class as defined in this de jure standard. Compliance with the basic WMS conformance class should augment the feasibility of reaching Initial Operation Capability (IOC) by the legal deadline of May 9 th 2011 since INSPIRE conform WMS s can be build based on available software that has obtained certification for this standard. 3.2 View service operations The following operations are mandatory for an INSPIRE View service : INSPIRE View Service operations Get View Service Metadata Get Map Link View Service Table 1 - View Service Operations ISO 19128:2005(E) WMS operations GetCapabilities GetMap The first two operations use parameters defined in the ISO 19128:2005(E) WMS standard, but this section specifies the role of some parameters in the INSPIRE context. The Link View Service operation is handled by the Discovery Service. As stated in the ISO 19128:2005(E) standard (see section 6.3.1) support for the GET method is mandatory. It is recommended that the GET method is used for the view service operations Common requests parameters for the View service operations VERSION The VERSION parameter specifies the protocol version number. It is optional for the GetCapabilities operation and mandatory for the GetMap operation. REQUEST The mandatory REQUEST parameter indicates which service operation is being invoked. The value shall be the name of one of the operations offered by the Web Map Server. FORMAT The FORMAT parameter specifies the output format of the response to an operation. It is optional for the GetCapabilities operation and mandatory for the GetMap operation. EXCEPTIONS The optional EXCEPTIONS request parameter states the format in which to report errors. LANGUAGE (INSPIRE extension) See chapter (Language Requirements)..

10 Technical Guidance View Services Page 10 of View service exceptions Internationalization of service exceptions is optional. If service exceptions are internationalized then the error messages (exceptions) are either expressed in the service s default language (suppose that the request is incorrect and the LANGUAGE parameter has not been interpreted before issuing the error/exception text) or in the preferred (requested) language in other cases. See also chapter (Common concept for other operations) Get View Service Metadata operation General According to Article 11 of the INSPIRE Directive any relevant content of metadata for INSPIRE view services shall be available. The NS Regulation further details the extent to which metadata has to be provided as all necessary information about the view service and the view service capabilities. The following metadata response parameters shall be contained in a Get View Service Metadata response : - View Service Metadata; - Operations Metadata; - Layers Metadata; - Languages. Most of the necessary metadata can be provided through the service Capabilities, as defined in the WMS Standard ISO19128:2005, These capabilities are mandatory and defined when a WMS is set up. They consist of server's information, supported operations and parameters values. Based on feedback by Member States, support for access to the metadata of a spatial dataset used by layers is included in this Technical Guideline although it is not required by INSPIRE. Access is provided through a URL that points to the metadata document of the spatial dataset represented in the layer. Besides providing a description of the spatial dataset used to build up a layer, this metadata allows to initialize additional workflows like accessing the data itself. This requires that layers provide a linkage to the metadata description of the spatial dataset. This is done through the element metadataurl as part of the layer metadata. This element is to be populated with a URL that allows access to an unambiguous metadata record. The URL can be : - A HTTP/GET call on the GetRecordById operation of the Discovery Service using the identifier of the metadata document; - A direct link to the metadata document. Example : There is a spatial dataset protectedsites.nl. A metadata document describing this spatial dataset is available through a discovery service. The metadata includes a metadata identifier 1001 and a unique resource identifier protectedsites.nl. The view service exposes the spatial dataset through a layer PS.ProtectedSite (harmonized name defined in the IR on interoperability of spatial data sets and services). As part of the capabilities metadata, the layer includes a MetadataURL pointing to the metadata document in the discovery service: id=1001&outputschema= full Note that the metadata on the spatial dataset is explaining the spatial dataset itself, it does not replace the other metadata on the layer as part of the capabilities GetCapabilities operation The operation for implementing INSPIRE Get View Service Metadata operation is the GetCapabilities operation. The parameters defined within the ISO 19128:2005(E) standard can be

11 Technical Guidance View Services Page 11 of 74 used to convey relevant information in order to get the expected responses as described in Annex III, section 2.2 of the Regulation on INSPIRE Network Services, : Request parameter Mandatory / optional VERSION=version O Request version : Description SERVICE=WMS M Service type. Fixed value : WMS. The ServiceType for an ISO 19128:2005(E) WMS1.3.0 is fixed to WMS. REQUEST=GetCapabilities M Request name. Fixed value : GetCapabilities LANGUAGE=code O Request language (INSPIRE extension). FORMAT=MIME_type O Output format of service metadata. Defaults to text/xml. Table 2 - GetCapabilities core parameters GetCapabilities response View service metadata Two scenarios have been identified for publishing View service metadata conform with the Regulation on INSPIRE Network Services and on Metadata. It is up to the to the Member States to choose which scenario best fits its needs. Since the scenario s aren t mutual exclusive, a Member State can even decide to implement both scenarios. Scenario 1 : INSPIRE network service metadata in a Discovery service is referenced through an extended capability. This scenario involves adding a reference to an online INSPIRE metadata resource in the extended INSPIRE capabilities. The <inspire_vs:metadataurl> element within the extended INSPIRE capabilities of an ISO 19128:2005(E) WMS1.3.0 <wms:capability> element is used to reference the INSPIRE service metadata available through an INSPIRE Discovery service. Service metadata is managed separate from the service in the Discovery catalogue and relevant metadata has to be pushed into the capabilities. Mandatory ISO 19128:2005(E) WMS1.3.0 metadata elements shall be mapped to INSPIRE metadata elements to realize a consistent interface. This scenario assumes the existence of INSPIRE metadata for the network service in an INSPIRE Discovery catalogue. To fulfill the specific language requirements of the NS regulation, a language section needs to be added in the extended capability of the service. Scenario 2 : Use (extended) capabilities to map all INSPIRE metadata elements to the ISO 19128:2005(E) WMS1.3.0 elements. This scenario involves mapping all INSPIRE metadata elements to ISO 19128:2005(E) WMS1.3.0 elements. INSPIRE metadata is mapped to WMS capabilities elements to its full extent. It is mandatory to use the mapping provided in this Technical Guideline (described in ). INSPIRE metadata elements that can't be mapped to available ISO 19128:2005(E) WMS1.3.0 elements are implemented as extended capabilities. Metadata is published through a service's capabilities document and can be harvested by an INSPIRE Discovery service. To fulfill the specific language requirements of the NS regulation, a language section needs to be added in the extended capability of the service in addition to the section containing INSPIRE metadata. In scenario 1, INSPIRE service metadata is managed in an INSPIRE Discovery catalogue and needs to be partially mapped to ISO 19128:2005(E) WMS1.3.0 elements and extended capabilities. In scenario 2, INSPIRE service metadata is fully mapped mapped to ISO 19128:2005(E) WMS1.3.0 elements and extended capabilities and is managed through service capabilities. INSPIRE service metadata needs to be published (harvest or transactional) in an INSPIRE Discovery catalogue to support the INSPIRE View Link service operation.

12 Technical Guidance View Services Page 12 of 74 The full schema for the extended capabilities and an example of a capabilities document for these scenarios is provided in annex H. In sections through the mandatory mappings for supporting these scenarios are described in detail. INSPIRE metadata is mapped to the <WMS_Capabilities> element of the GetCapabilities response. The Regulation on INSPIRE Network Services and on Metadata states that a spatial data service shall contain following INSPIRE Metadata elements : INSPIRE Metadata elements (Mandatory - Conditional) ISO19128:2005(E) elements of <WMS_Capabilities> Resource Title (M) Resource Abstract (M) Resource Type (M) Resource Locator (C) Coupled Resource (C) Spatial Data Service Type (M) Keyword (M) Geographic Bounding Box (M) Temporal Reference (M) Spatial Resolution (C) Conformity (M) wms:title wms:abstract inspire_vs:resourcetype (Extended Capabilities) inspire_vs:resourcelocator (Extended Capabilities) wms:dataurl (Layer property) inspire_vs:spatialdataservicetype (Extended Capabilities) wms:keyword ; inspire_vs:inspirekeywords wms:ex_geographicboundingbox (Layer property) inspire_vs:temporalreference (Extended Capabilities) wms:abstract inspire_vs:conformity (Extended Capabilities) Conditions for Access and Use (M) wms:fees Limitations on Public Access (M) Responsible Organisation (M) Metadata Point of Contact (M) Metadata Date (M) Metadata Language (M) wms:accessconstraints wms:contactinformation inspire_vs:metadatapointofcontact (Extended Capabilities) inspire_vs:metadatadate (Extended Capabilities) inspire_vs:language (Extended Capabilities) Mapping between INSPIRE metadata elements and ISO19128:2005(E) WMS elements Identification A proper identification of the spatial dataset, spatial dataset series and spatial data services is necessary to the implementation of the Directive.

13 Technical Guidance View Services Page 13 of RESOURCE TITLE This is a characteristic and often-unique name by which the resource is known. It is mapped with the <wms:title> element. Example : <wms:wms_capabilities version="1.3.0" xmlns:wms= <wms:service> <wms:name>wms</wms:name> <wms:title>ms INSPIRE View Service</wms:Title> </wms:service> </wms:wms_capabilities> RESOURCE ABSTRACT This is a brief narrative summary of the content of the resource. It is mapped with the <wms:abstract> element. Example : <wms:wms_capabilities version="1.3.0" xmlns:wms= <wms:service> <wms:name>wms</wms:name> <wms:title>ms INSPIRE View Service</wms:Title> <wms:abstract> Service for making available INSPIRE themes </wms:abstract> </wms:service> </wms:wms_capabilities> RESOURCE TYPE The Resource Type defines the scope to which metadata applies. Within the scope defined by the INSPIRE directive the value of the Resource Type shall be fixed to service for spatial data services. As the Resource Type is not supported by EN ISO 19128:2005(E) (WMS 1.3.0), an extension shall be used to map this to an <inspire_vs:resourcetype> element within an <inspire_vs:extendedcapabilities> element. The <inspire_vs:resourcetype> element is typed as a gmd:md_scopecode_propertytype type according the Metadata Implementing Rules and ISO19115:2003. Example : see Annex H RESOURCE LOCATOR The Resource Locator defines the link, commonly expressed as a Uniform Resource Locator(s) (URL) to the service. The Resource Locator might be one of the following: - A link to the service capabilities document; - A link to the service WSDL document (SOAP Binding); - A link to a web page with further instructions; - A link to a client application that directly accesses the service. The <wms:onlineresource> element within the <wms:service> element would be the preferred choice for mapping the Resource Locator metadata element. But for consistency with the INSPIRE Discovery service metadata in the capabilities document it has been decided that an extension shall be used to map this to an <inspire_vs:resourcelocator> element within an <inspire_vs:extendedcapabilities> element. The <inspire_vs:resourcelocator> element is typed as a gmd:ci_onlineresource_type type according the Metadata Implementing Rules and ISO19115:2003.

14 Technical Guidance View Services Page 14 of 74 Example : see Annex H COUPLED RESOURCE Coupled Resource provides information about the datasets that the service operates on. If the datasets, on which the service operates, are online available, then linkage to these resources is mandatory as stated by INSPIRE Metadata Implementing Rules. If there are no online resources available, Coupled Resource metadata should not be documented. Coupled Resource is mapped to the DataURL property of the Layer element. For more information see SPATIAL DATA SERVICE TYPE Given that EN ISO 19128:2005(E) (WMS 1.3.0) has been identified as one of the relevant standards to implement INSPIRE View Services, the technical spatial data service type defined by EN ISO 19128:2005(E) (WMS 1.3.0) is mapped to the <wms:name> element and has a fixed WMS value. For the Spatial Data Service Type as defined by INSPIRE MD IR ( view ) an extension shall be used to map this to an <inspire_vs:spatialdataservicetype> element within an <inspire_vs:extendedcapabilities> element. For an INSPIRE View Service the Spatial Data Service Type shall have a fixed value view. The <inspire_vs:spatialdataservicetype> element is typed as a srv:sv_servicetype_type type according the Metadata Implementing Rules and ISO19115:2003. Example : see Annex H KEYWORD Commonly used word(s), formalized word(s) or phrase(s) used to describe the subject. The INSPIRE Implementing rules for metadata mandate the presence of at least one keyword for spatial data services. The keyword shall at least define the category or subcategory of the service using its language neutral name. In addition to this keyword, others might be added. These may be described as a free text or may originate from any Controlled Vocabulary. If they originate from a Controlled Vocabulary, for example GEMET or INSPIRE, then the citation of the originating Controlled Vocabulary shall be provided. The list of keywords is mapped with the <wms:keywordlist> element, the individual keywords are mapped to the <wms:keyword> element, the referenced vocabulary is mapped to the vocabulary attribute of the <wms:keyword> element. Example : <wms:wms_capabilities version="1.3.0" xmlns:wms= <wms:service> <wms:name>wms</wms:name> <wms:title>ms INSPIRE View Service</wms:Title> <wms:abstract> Service for making available INSPIRE themes </wms:abstract> <wms:keywordlist> <!-- vocabulary in WMS only --> <wms:keyword vocabulary="iso"> infomapaccessservice </wms:keyword> <wms:keyword vocabulary="gemet">keyword</wms:keyword> </wms:keywordlist> </wms:service> </wms:wms_capabilities>

15 Technical Guidance View Services Page 15 of 74 Typing keywords according Metadata Implementing Rules and ISO19115:2003 allows for providing a detailed description of the thesaurus a keyword belongs to. To provide this functionality and keep a similar interface as for Discovery, this approach for describing keywords has been provided as an extended capability. The list of keywords is mapped to the capabilities extension <inspire_vs:inspirekeywords> within an <inspire_vs:extendedcapabilities> element. The list of keywords is of type gmd:md_keywords_type. Example of gmd:keyword and gdm:thesaurusname: see Annex H GEOGRAPHIC BOUNDING BOX Geographic Bounding Box is mapped to the EX_GeographicBoundingBox property of the Layer element. See for more information CONFORMITY The use of Conformity metadata is a specific INSPIRE requirement. Directive 2007/2/EC states that service metadata shall include information on the degree of conformity with the implementing rules provided in Art The Implementing Rules for metadata defines in Part D 5 three degrees of conformity: - conformant or not conformant : When the conformity to an INSPIRE Specification has been evaluated, it shall be reported as a domain consistency element (i.e. an instance of DQ_DomainConsistency) in ISO metadata (see 2.8.1). In that case, if the evaluation has passed, the degree is confomant, otherwise it is not conformant. - not evaluated : The absence of ISO metadata related to the conformity to an INSPIRE specification does imply that the conformity to this specification has not been evaluated. Relevant INSPIRE specifications for View Services are : the INSPIRE Network Services Regulation and the INSPIRE Implementing Rules for metadata. Other relevant specifications may have to be considered at a later stage. There is no element available in EN ISO 19128:2005(E) (WMS 1.3.0) that allows the description of the degree of conformity with a specific specification. An extension shall be used to map this to an <inspire_vs:conformity> element within an <inspire_vs:extended Capabilities> element. The <inspire_vs:conformity> element is typed as a gmd:dq_conformanceresult_type type according the Metadata Implementing Rules and ISO19115:2003. The <gmd:pass> element will have a boolean value of true when the service is conform and a boolean value of false when the service is not conformant to the specification, described in a <gmd:specification> element. If no conformity statements are expressed in <inspire_vs:conformity> elements or in the service metadata referenced by a <inspire_vs:metadataurl>, the service has not been evaluated against any specification. Example : see Annex H Constraints related to access and use CONDITION FOR ACCESS AND USE It defines the conditions for access and use of spatial datasets and services, and where applicable, corresponding fees. It is mapped with the <wms:fees> element. No precise syntax has been defined for the text content of these elements in ISO 19128:2005(E). The use of no conditions apply is recommended when the service is free of charge. Example : <wms:wms_capabilities version="1.3.0" xmlns:wms= <wms:service>

16 Technical Guidance View Services Page 16 of 74 <wms:name>wms</wms:name> <wms:title>ms INSPIRE View Service</wms:Title> <wms:abstract> Service for making available INSPIRE themes </wms:abstract> <wms:keywordlist> <wms:keyword>gemet keyword</wms:keyword> </wms:keywordlist> <wms:fees>no conditions apply</wms:fees> </wms:service> </wms:wms_capabilities> LIMITATIONS ON PUBLIC ACCESS This metadata element shall provide information on the limitations (if they exist) and the reasons for such limitations. It is mapped with <wms:accessconstraints> element. No precise syntax has been defined for the text content of these elements in ISO 19128:2005(E). The use of None is recommended when no limitations on public access apply. When constraints are imposed, it is recommended to use the MD_RestrictionCode codelist names as defined in ISO 19115:2003(E) Annex B Data Dictionary, paragraph Example : <wms:wms_capabilities version="1.3.0" xmlns:wms= <wms:service> <wms:name>wms</wms:name> <wms:title>ms INSPIRE View Service</wms:Title> <wms:abstract> Service for making available INSPIRE themes </wms:abstract> <wms:keywordlist> <wms:keyword>gemet keyword</wms:keyword> </wms:keywordlist> <wms:fees>no conditions apply</wms:fees> <wms:accessconstraints>none</wms:accessconstraints> </wms:service> </wms:wms_capabilities> RESPONSIBLE ORGANISATION The public authority or any other citation to the organization most responsible for the resource and the corresponding role(s). It is mapped with the <wms:contactinformation> element where the most relevant properties are : 1. Organisation ; 2. Role ; 3. Contact address : postal address ; 4. Phone ; 5. It is recommended to use an organization level address. Personal addresses are not recommended ; The function or role performed by the responsible party is one of the following (as defined in Part D 6 of the INSPIRE Implementing Rules for metadata and the CI_RoleCode codelist of ISO ) : resourceprovider, custodian, owner, user, distributor, originator, pointofcontact, principalinvestigator, processor, publisher, author. The Responsible Party as mandated by the Metadata IR is mapped to the <wms:contactorganization> element of the <wms:contactpersonprimary> within the <wms:contactinformation> element.

17 Technical Guidance View Services Page 17 of 74 The Responsible Party Role is mapped to the <wms:contactposition> of the <wms:contactinformation> element. Example : <wms:wms_capabilities version="1.3.0" xmlns:wms= <wms:service> <wms:name>wms</wms:name> <wms:title>ms INSPIRE View Service</wms:Title> <wms:abstract> Service for making available INSPIRE themes </wms:abstract> <wms:keywordlist> <wms:keyword>gemet keyword</wms:keyword> </wms:keywordlist> <wms:contactinformation> <ContactPersonPrimary> <ContactPerson>person or department</contactperson> <ContactOrganization>organisation</ContactOrganization> </ContactPersonPrimary> <ContactPosition>custodian</ContactPosition> <wms:contactaddress> <wms:addresstype>postal</addresstype> <wms:address>street nr., Street name</wms:address> <wms:city>city</wms:city> <wms:stateorprovince>if relevant or empty</wms:stateorprovince> <wms:postcode>postal code</wms:postcode> <wms:country>ms name</wms:country> </wms:contactaddress> <wms:contactvoicetelephone>phone number</wms:contactvoicetelephone> <wms:contactelectronicmailaddress> contactpoint@organisation.country </wms:contactelectronicmailaddress> </wms:contactinformation> <wms:fees>no conditions apply</wms:fees> <wms:accessconstraints>none</wms:accessconstraints> </wms:service> </wms:wms_capabilities> Metadata on metadata METADATA POINT OF CONTACT The Metadata Point Of Contact as mandated by the Metadata IR identifies the party responsible for the metadata information. INSPIRE is more demanding than ISO by mandating both the name of the organisation, and a contact address. The role of the responsible party serving as a metadata point of contact is out of scope of the INSPIRE Implementing Rules, but this property is mandated by ISO Its value shall be defaulted to pointofcontact. Since only one <wms:contactinformation> element is allowed in ISO 19128:2005(E) WMS1.3.0 (to which Responsible Organisation is mapped), an extension shall be used to map this to an <inspire_vs:metadatapointofcontact> element within an <inspire_vs:extended Capabilities> element. The <inspire_vs:metadatapointofcontact> element is typed as a gmd:ci_responsibleparty_type type according the Metadata Implementing Rules and ISO19115:2003. Example : see Annex H

18 Technical Guidance View Services Page 18 of METADATA DATE The date when the INSPIRE View Service metadata was created or updated. ISO is more restrictive because this element shall only contain the date that the metadata was created. The INSPIRE Metadata Implementing Rules also allows the date it was updated. The update date is preferred. As the Metadata Date is not supported by EN ISO 19128:2005(E) (WMS 1.3.0), an extension shall be used to map this to an <inspire_vs:metadatadate> element within an <inspire_vs:extended Capabilities> element. The <inspire_vs:metadatadate> element is typed as a gco:date_type type according the Metadata Implementing Rules and ISO19115:2003. Example : see Annex H TEMPORAL REFERENCE The creation, publishing or revision date of the INSPIRE View Service. To be compliant with the INSPIRE Implementing Rules for Metadata and with ISO it is necessary to use at least one of following dates : date of publication, date of last revision, or the date of creation. Date of last revision is preferred. INSPIRE also allows to use a Temporal Extent as Temporal Reference, this is not supported by ISO As the Temporal Reference is not directly supported by EN ISO 19128:2005(E) (WMS 1.3.0) an extension shall be used to map this to an <inspire_vs:temporalreference> element within an <inspire_vs:extended Capabilities> element. The <inspire_vs:temporalreference> element is typed as a gmd:ex_extent_type type according the Metadata Implementing Rules and ISO19115:2003. Example : see Annex H SPATIAL RESOLUTION As stated by the INSPIRE Implementing Rules for Metadata, It is not possible to express the restriction of a service concerning the spatial resolution in the current version of ISO While the problem is addressed by the standardization community, spatial resolution restrictions for services shall be expressed in the Abstract as mandated by the Metadata IR. Spatial Resolution restrictions at service metadata level shall be declaratively described in the <wms:abstract> element. Nevertheless is it possible to describe the Spatial Resolution of an individual Layer in the resx and resy attributes of a <wms:boundingbox> element. Additional to any Spatial Resolution restrictions expressed in the <wms:abstract> element, the Spatial Resolution for every published Layer can be documented in the in the resx and resy attributes of the <wms:boundingbox> for this Layer. This is not required by INSPIRE Regulations at this moment Operations Metadata The operation metadata are mapped with the <wms:request> element. There are two mandatory operations to be defined in the Operation Metadata : Get View Service Metadata implemented with the GetCapabilities WMS operation and Get Map implemented with the GetMap WMS operation. The third mandatory operation Link View Service, which allows a Public Authority or a Third Party to declare a view Service for the viewing of its resources through the Member State View Service while maintaining the viewing capability at the Public Authority or the Third party location, is implemented through the Discover Metadata operation of the Discovery Service which allows for View service metadata to be retrieved. It is worth noting that the ISO 19128:2005(E) standard only supports HTTP as a transport protocol. The ISO standard further mandates the use of the HTTP GET method GetCapabilities operation metadata 2 There are, as of writing of this document, on-going works on OGC's OWS to support SOAP in DCPType.

19 Technical Guidance View Services Page 19 of 74 These metadata are mapped with the <wms:getcapabilities> element. Example : <wms:wms_capabilities version= xmlns:wms= <wms:service> </wms:service> <wms:capability> <wms:request> <wms:getcapabilities> <wms:format>text/xml</wms:format> <wms:dcptype> <wms:http> <wms:get> <wms:onlineresource xmlns:xlink=" xlink:href=" </wms:get> </wms:http> </wms:dcptype> </wms:getcapabilities> </wms:request> </wms:capability> </wms:wms_capabilities> GetMap operation metadata These metadata are mapped with the <wms:getmap> element. Either PNG or GIF format (without LZW compression) shall be supported by the View service (Annex III, Part B of the Implementing Rules). If PNG format is supported, the View service may select an appropriate bit depth for the returned PNG image. For layers with up to 256 colors, the recommended format is 8-bit indexed PNG. For layers with more than 256 colors, a higher bit depth should be used. Example : <wms:wms_capabilities version= xmlns:wms= <wms:service> </wms:service> <wms:capability> <wms:request> <wms:getcapabilities> <wms:format>text/xml</wms:format> <wms:dcptype> <wms:http> <wms:get> <wms:onlineresource xmlns:xlink=" xlink:href=" </wms:get> </wms:http>

20 Technical Guidance View Services Page 20 of 74 </wms:dcptype> </wms:getcapabilities> <wms:getmap> <wms:format>image/png</wms:format> <wms:dcptype> <wms:http> <wms:get> <wms:onlineresource xmlns:xlink=" xlink:href=" </wms:get> </wms:http> </wms:dcptype> </wms:getmap> </wms:request> </wms:capability> </wms:wms_capabilities> Link View Service operation metadata The use of the Discover Metadata operation of the INSPIRE Discovery service is recommended for implementing the Link View Service operation. The mechanism for publishing a view service s service metadata and discovering a View Service through its service metadata is described in [5] and [7] Languages Refer to METADATA LANGUAGE section Layers Metadata These metadata are mapped with the <wms:layer> element. Example : <wms:wms_capabilities version="1.3.0" xmlns:wms= <wms:service> </wms:service> <wms:capability> <wms:layer> </wms:layer> </wms:capability> </wms:wms_capabilities> The description of a layer shall use elements defined for the service capabilities in the ISO19128:2005(E) standard. This paragraph specifies the role of some parameters for the INSPIRE View Service as stated in the Regulation on INSPIRE Network Services : Resource Title Resource Abstract Metadata elements wms:title ISO19128:2005(E) standard elements of <wms:layer> wms:abstract

21 Technical Guidance View Services Page 21 of 74 Metadata elements ISO19128:2005(E) standard elements of <wms:layer> Keyword Geographic Bounding Box Unique Resource Identifier Name Coordinate Reference Systems Styles Legend URL Dimension Pairs Link to metadata of the corresponding spatial dataset Coupled Resource (Service metadata mapped to a Layer property) wms:keywordlist wms:ex_geographicboundingbox wms:identifier + wms:authorityurl wms:name wms:crs wms:style wms:style/wms:legendurl wms:dimension[@name,@units] wms:metadataurl wms:dataurl Table 3 Mapping between INSPIRE elements and ISO19128:2005(E) WMS elements RESOURCE TITLE The title of the layer, used for human communication, for presentation of the layer e.g. in a menu. It is mapped with <wms:title>. The harmonized title of a layer for an INSPIRE spatial data theme is defined by [9] and is subject to multilingualism (translations will appear in each mono-lingual capabilities localized documents). Example : <wms:wms_capabilities version="1.3.0" xmlns:wms= <wms:service> </wms:service> <wms:capability> <wms:layer> <wms:title>transport networks : Road Area</wms:Title> </wms:layer> </wms:capability> </wms:wms_capabilities> RESOURCE ABSTRACT Layer abstract : text describing the layer. Subject to multilingualism. It is mapped with the <wms:abstract> element. Example : <wms:wms_capabilities version="1.3.0" xmlns:wms= <wms:service> </wms:service> <wms:capability>

22 Technical Guidance View Services Page 22 of 74 <wms:layer> <wms:title>the road network theme : roads</wms:title> <wms:abstract>as defined by TWG</wms:Abstract> </wms:layer> </wms:capability> </wms:wms_capabilities> KEYWORD Additional Keywords : list of keywords describing the layer, to support catalog search (to be harmonized the INSPIRE metadata element Keyword Value, see [5] 3.2.3). It is mapped with the <wms:keywordlist> element. Example : <wms:wms_capabilities version= xmlns:wms= <wms:service> </wms:service> <wms:capability> <wms:layer> <wms:title>transport networks : Road Area</wms:Title> <wms:abstract>as defined by TWG</wms:Abstract> <wms:keywordlist> <wms:keyword>gemet keyword</wms:keyword> </wms:keywordlist> </wms:layer> </wms:capability> </wms:wms_capabilities> GEOGRAPHIC BOUNDING BOX This element is used to facilitate geographic searches. It is mapped with the <wms:ex_geographicboundingbox> element. The minimum bounding rectangle in decimal degrees of the area covered by the Layer shall be supplied regardless of what CRS the map server may support and shall use CRS:84 as Coordinate Reference System. Example : <wms:wms_capabilities version= xmlns:wms= <wms:service> </wms:service> <wms:capability> <wms:layer> <wms:title>transport networks : Road Area</wms:Title> <wms:abstract>as defined by TWG</wms:Abstract> <wms:keywordlist> <wms:keyword>gemet keyword</wms:keyword> </wms:keywordlist> <wms:ex_geographicboundingbox> <wms:westboundlongitude>-31.2</wms:westboundlongitude>

23 Technical Guidance View Services Page 23 of 74 <wms:eastboundlongitude>69.1</wms:eastboundlongitude> <wms:southboundlatitude>27.2</wms:southboundlatitude> <wms:northboundlatitude>80.9</wms:northboundlatitude> </wms:ex_geographicboundingbox> </wms:layer> </wms:capability> </wms:wms_capabilities> LINK TO METADATA ON THE SPATIAL DATASET Metadata provided for each layer shall follow the Regulation on INSPIRE Network Services (See ). Metadata records are stored in an INSPIRE discovery service (so that it is possible to discover datasets and services via the discovery service). The metadata for the spatial dataset a layer exposes is to be linked to the layer through a URL that points to the metadata document of the spatial dataset represented in the layer using operations of the discovery service: HTTP/GET call on the GetRecordById operation of the Discovery Service using the identifier of the metadata document (see example in ). This will return exactly one metadata document. Example : <wms:wms_capabilities version= xmlns:wms= <wms:service> </wms:service> <wms:capability> <wms:layer> <wms:title>transport networks : Road Area</wms:Title> <wms:abstract>as defined by TWG</wms:Abstract> <wms:keywordlist> <wms:keyword>gemet keyword</wms:keyword> </wms:keywordlist> <wms:ex_geographicboundingbox> <wms:westboundlongitude>-31.2</wms:westboundlongitude> <wms:eastboundlongitude>69.1</wms:eastboundlongitude> <wms:southboundlatitude>27.2</wms:southboundlatitude> <wms:northboundlatitude>90</wms:northboundlatitude> </wms:ex_geographicboundingbox> <MetadataURL type="iso19115:2003 > <Format>text/xml</Format> xlink:href=" TADATA_IDENTIFIER]&outputSchema= Name=full" </MetadataURL> </wms:layer> </wms:capability> </wms:wms_capabilities> NAME

24 Technical Guidance View Services Page 24 of 74 The harmonized name of a layer is used for machine-to-machine communication in the GetMap request (see also [3] ). The harmonized name of a layer for an INSPIRE spatial data theme is defined by [9]. The recommended naming convention is THEME.LayerName, with the theme in uppercase and the layer in Pascal case without spaces. For annexes I and II themes, the following names are used : Theme Geographical names Administrative units Addresses Cadastral parcels Transport networks Hydrography Protected sites GN.GeographicalNames AU.AdministrativeUnit AD.Address CP.CadastralParcel Examples of layer names TN.RoadTransportNetwork.RoadArea HY.Network It is mapped with the <wms:name> element. PS.ProtectedSite Table 4 Annexes I&II harmonized name examples Example : <wms:wms_capabilities version= xmlns:wms= <wms:service> </wms:service> <wms:capability> <wms:layer> <wms:name>tn.roadtransportnetwork.roadarea</wms:name> <wms:title> Transport networks : Road Area</wms:Title> <wms:abstract>as defined by TWG</wms:Abstract> <wms:keywordlist> <wms:keyword>gemet keyword</wms:keyword> </wms:keywordlist> <wms:ex_geographicboundingbox> <wms:westboundlongitude>-31.2</wms:westboundlongitude> <wms:eastboundlongitude>69.1</wms:eastboundlongitude> <wms:southboundlatitude>27.2</wms:southboundlatitude> <wms:northboundlatitude>90</wms:northboundlatitude> </wms:ex_geographicboundingbox> <MetadataURL type="iso19115:2003 > <Format>text/xml</Format> xlink:href=" TADATA_IDENTIFIER]&outputSchema= Name=full" </MetadataURL> </wms:layer> </wms:capability> </wms:wms_capabilities> COORDINATE REFERENCE SYSTEMS

25 Technical Guidance View Services Page 25 of 74 List of Coordinate Reference Systems in which the layer is available : coordinate reference system as defined in Annex I of the INSPIRE Directive, Geodesy. It is mandatory to use geographical coordinate system based on ETRS89 in continental Europe and ITRS outside continental Europe. The value of the CRS parameter depends on the coordinate reference systems catalogue being used : using CRS-EU repository (See the relevant code would be : CRS-EU:ETRS89 using EPSG repository (See the relevant code would be : EPSG:4258 As two types of CRS identifiers are permitted ("label" with EPSG, CRS and AUTO2 namespaces, and "URL" identifiers as fully-qualified Uniform Resource Locator that references a publicly-accessible file containing a definition of the CRS that is compliant with ISO 19111), it is recommended to set up a register for the INSPIRE framework. CRS value EPSG: EPSG:4326 CRS:84 Table 5 CRS recommended codes Usage ETRS89 geographic (Continental Europe) ETRS89 geographic (Continental Europe) WGS 84 (World), Low resolution datasets WGS 84 (Outside continental Europe) Example : <wms:wms_capabilities version= xmlns:wms= <wms:service> </wms:service> <wms:capability> <wms:layer> <wms:name>tn.roadtransportnetwork.roadarea</wms:name> <wms:title>transport networks : Road Area</wms:Title> <wms:abstract>as defined by TWG</wms:Abstract> <wms:keywordlist> <wms:keyword>gemet keyword</wms:keyword> </wms:keywordlist> <wms:crs>epsg:4258</wms:crs> <wms:crs> <wms:crs>epsg:4326</wms:crs> <wms:crs>crs:84</wms:crs> <wms:ex_geographicboundingbox> <wms:westboundlongitude>-31.2</wms:westboundlongitude> <wms:eastboundlongitude>69.1</wms:eastboundlongitude> <wms:southboundlatitude>27.2</wms:southboundlatitude> <wms:northboundlatitude>90</wms:northboundlatitude> </wms:ex_geographicboundingbox> <MetadataURL type="iso19115:2003 > <Format>text/xml</Format> xlink:href=" TADATA_IDENTIFIER]&outputSchema= Name=full"

26 Technical Guidance View Services Page 26 of 74 </MetadataURL> </wms:layer> </wms:capability> STYLES List of the rendering styles available for the layer. A Style shall be composed of a Title and a Unique Identifier. An INSPIRE:DEFAULT style for each theme is defined in the "Portrayal" section of the respective INSPIRE Data Specification Guidelines document. For layers with no associated default style, the INSPIRE Generic Conceptual Model [10] defines simple styles to be used in data portrayal, derived from Symbology Encoding Implementation Specification [2]: Point: grey square, 6 pixels Curve: black solid line, 1 pixel Surface: black solid line, 1 pixel, grey fill In addition to the INSPIRE:DEFAULT style, the View Service may provide additional thematic or national styles for each layer, for example IGNF:TRANSPORTNETWORKS.ROADS. If no style is specified in the request or the style parameter is empty, the INSPIRE:DEFAULT style must be used in layer rendering. A legend must be provided for each style defined in the View Service. Style is mapped with the <wms:style> element. The human-readable name is mapped with the <wms:title> element and the Unique Identifier is mapped with the <wms:name> element. Example : <wms:wms_capabilities version="1.3.0" xmlns:wms= <wms:service> </wms:service> <wms:capability> <wms:layer> <wms:name>tn.roadtransportnetwork.roadarea</wms:name> <wms:title>transport networks : Road Area</wms:Title> <wms:abstract>as defined by TWG</wms:Abstract> <wms:keywordlist> </wms:keywordlist> <wms:crs>epsg:4258</wms:crs> <wms:ex_geographicboundingbox> </wms:ex_geographicboundingbox> <wms:style> <wms:name>inspire:default</wms:name> <wms:title>style for roads</wms:title> </wms:style> </wms:layer> </wms:capability> </wms:wms_capabilities> LEGEND URL

27 Technical Guidance View Services Page 27 of 74 Location of the legend for each style. As the capabilities document is a mono-lingual document, internationalized legend may placed in different capabilities document for each value of the LANGUAGE parameter. It is mapped with the <wms:legendurl> element. It is recommended to use "image/png" or "image/gif" mime types for a legend. Example : <wms:wms_capabilities version= xmlns:wms= <wms:service> </wms:service> <wms:capability> <wms:layer> <wms:name>tn.roadtransportnetwork.roadarea</wms:name> <wms:title>transport networks : Road Area</wms:Title> <wms:abstract>as defined by TWG</wms:Abstract> <wms:keywordlist> <wms:keyword>gemet keyword</wms:keyword> </wms:keywordlist> <wms:crs>epsg:4258</wms:crs> <wms:crs>epsg:3034</wms:crs> <wms:crs>epsg:3042</wms:crs> <wms:crs>epsg:3043</wms:crs> <wms:crs>epsg:3044</wms:crs> <wms:ex_geographicboundingbox> <wms:westboundlongitude>-31.2</wms:westboundlongitude> <wms:eastboundlongitude>69.1</wms:eastboundlongitude> <wms:southboundlatitude>27.2</wms:southboundlatitude> <wms:northboundlatitude>90</wms:northboundlatitude> </wms:ex_geographicboundingbox> <MetadataURL type="iso19115:2003 > <Format>text/xml</Format> xlink:href=" TADATA_IDENTIFIER]&outputSchema= Name=full" </MetadataURL> <wms:style> <wms:name>inspire:default</wms:name> <wms:title>style for roads</wms:title> <wms:legendurl width="100" height="100"> <wms:format>image/png</wms:format> <wms:onlineresource xmlns:xlink=" xlink:href="url" <wms:legendurl> </wms:style> </wms:layer> </wms:capability> </wms:wms_capabilities>

28 Technical Guidance View Services Page 28 of DIMENSION PAIRS Indicates the supported two dimensional axis pairs for multi dimensional spatial data sets and spatial data sets series : some geographic information may be available at other dimensions (for example, satellite images in different wavelength bands). The optional <wms:dimension> element is used in service metadata to declare that one or more dimensional parameters are relevant to a layer or group of layers. For more information, refer the Annex C of ISO 19128:2005(E) standard. When the map is fully defined by its two-dimensional axis (defined in the CRS), this metadata element should not be provided. In other cases such as time and elevation, the use of <wms:dimension> is mandatory according to Implementing Rules. Example : <wms:wms_capabilities version= xmlns:wms= <wms:service> </wms:service> <wms:capability> <wms:layer> <wms:name>tn.roadtransportnetwork.roadarea</wms:name> <wms:title>transport networks : Road Area</wms:Title> <wms:abstract>as defined by TWG</wms:Abstract> <wms:keywordlist> <wms:keyword>gemet keyword</wms:keyword> </wms:keywordlist> <wms:crs>epsg:4258</wms:crs> <wms:crs>epsg:3034</wms:crs> <wms:crs>epsg:3042</wms:crs> <wms:crs>epsg:3043</wms:crs> <wms:crs>epsg:3044</wms:crs> <wms:ex_geographicboundingbox> <wms:westboundlongitude>-31.2</wms:westboundlongitude> <wms:eastboundlongitude>69.1</wms:eastboundlongitude> <wms:southboundlatitude>27.2</wms:southboundlatitude> <wms:northboundlatitude>90</wms:northboundlatitude> </wms:ex_geographicboundingbox> <wms:dimension name="time" units="iso8601" defaults=" "> / /PID </wms:dimension> <MetadataURL type="iso19115:2003 > <Format>text/xml</Format> xlink:href=" TADATA_IDENTIFIER]&outputSchema= Name=full" </MetadataURL> <wms:style> <wms:name>inspire:default</wms:name> <wms:title>style for roads</wms:title> <wms:legendurl width="100" height="100"> <wms:format>image/png</wms:format>

29 Technical Guidance View Services Page 29 of 74 <wms:onlineresource xmlns:xlink=" xlink:href="url" <wms:legendurl> </wms:style> </wms:layer> </wms:capability> </wms:wms_capabilities> CATEGORY LAYER Category Layers can be used to describe a layer including more than one featuretype (e.g. 8.8 Hydrography Layers in the Implementing Directive 2007/2/EC as regards interoperability of spatial data sets and services) or a layer consisting of regional separated spatial datasets. A containing Category Layer itself includes a Name by which a map portraying all of the nested layers can be requested at once. If a metadata description of this category composition exists then the MetadataURL for the Category Layer must be provided. For instance, the Category Layer Hydrography Physical Waters Waterbodies could contain HY.PhysicalWaters.Waterbodies.Watercourse and HY.PhysicalWaters.Waterbodies.StandingWater nested layers. Example : <wms:wms_capabilities version= xmlns:wms= <wms:service> </wms:service> <wms:capability> <wms:layer> <wms:name>hy.physicalwaters.waterbodies</wms:name> <wms:title>hydrography Physical Waters : Waterbodies</wms:Title> <MetadataURL type="iso19115:2003 > <Format>text/xml</Format> xlink:href=" TADATA_IDENTIFIER]&outputSchema= Name=full" </MetadataURL> <wms:layer> <wms:name> HY.PHYSICALWATERS.WATERBODIES.WATERCOURSE </wms:name> <wms:title> The hydrography physical waters theme : waterbodies </wms:title> <wms:abstract>as defined by TWG</wms:Abstract> <wms:keywordlist> <wms:keyword>gemet keyword</wms:keyword> </wms:keywordlist>

30 Technical Guidance View Services Page 30 of 74 <wms:ex_geographicboundingbox> <wms:westboundlongitude>-31.2</wms:westboundlongitude> <wms:eastboundlongitude>69.1</wms:eastboundlongitude> <wms:southboundlatitude>27.2</wms:southboundlatitude> <wms:northboundlatitude>90</wms:northboundlatitude> </wms:ex_geographicboundingbox> <MetadataURL type="iso19115:2003 > <Format>text/xml</Format> xlink:href=" TADATA_IDENTIFIER]&outputSchema= Name=full" </MetadataURL> </wms:layer> <wms:layer> <wms:name> HY.PHYSICALWATERS.WATERBODIES.STANDINGWATER </wms:name> <wms:title> The hydrography physical waters theme:standing water </wms:title> <wms:abstract>as defined by TWG</wms:Abstract> <wms:keywordlist> <wms:keyword>gemet keyword</wms:keyword> </wms:keywordlist> <wms:ex_geographicboundingbox> <wms:westboundlongitude>-31.2</wms:westboundlongitude> <wms:eastboundlongitude>69.1</wms:eastboundlongitude> <wms:southboundlatitude>27.2</wms:southboundlatitude> <wms:northboundlatitude>90</wms:northboundlatitude> </wms:ex_geographicboundingbox> <MetadataURL type="iso19115:2003 > <Format>text/xml</Format> xlink:href=" TADATA_IDENTIFIER]&outputSchema= Name=full" </MetadataURL> </wms:layer> </wms:layer> </wms:capability> </wms:wms_capabilities> UNIQUE RESOURCE IDENTIFIER The Unique Resource Identifier of the resource used to create the layer. In [9] the Identifier type is defined as an external unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object. This type minimally consists of : - A local identifier, assigned by the data provider. The local identifier is unique within the namespace, that is no other spatial object carries the same unique identifier.

31 Technical Guidance View Services Page 31 of 74 - A Namespace uniquely identifying the data source of the spatial object. The INS MD Regulation defines a Unique Resource Identifier as a value uniquely identifying an object within a namespace, typed by the MD_Identifier data type. The code property is required at a minimum, and a codespace (namespace) property may be provided. If a codespace is provided, the data type to be used is RS_Identifier. The value of the id attribute assigned to the MD_DataIdentification element may be used for cross-references within the document, or as the fragment identifier in links to the element from external resources. Sample from INS MD Regulation demonstrating this concept : <gmd:md_metadata <gmd:identificationinfo> <gmd:md_dataidentification id="image2000_1_nl2_multi" > <gmd:citation> <gmd:ci_citation> <gmd:identifier> <gmd:rs_identifier> <gmd:code> <gco:characterstring>image2000_1_nl2_multi</gco:characterstring> </gmd:code> <gmd:codespace> <gco:characterstring> </gmd:codespace> </gmd:rs_identifier> </gmd:identifier> </gmd:ci_citation> </gmd:citation> </gmd:md_dataidentification> </gmd:identificationinfo> </gmd:md_metadata> To be able to map the concept of a responsible body/codespace and local identifier/code to ISO19128:2005(E), AuthorityURL and Identifier elements are used. The authority name and explanatory URL are defined in a separate AuthorityURL element, which may be defined once and inherited by subsidiary layers. Identifiers themselves are not inherited. The usage of a UUID (Universal Unique Identifier, as specified by IETF ( is recommended to ensure identifier s uniqueness. Example : <wms:wms_capabilities version= xmlns:wms= <wms:service> </wms:service> <wms:capability> <wms:layer> <wms:name>hy.physicalwaters.waterbodies</wms:name> <wms:title>hydrography Physical Waters : Waterbodies</wms:Title> <AuthorityURL name="agivid"> <OnlineResource xmlns:xlink= xlink:href=" </AuthorityURL> <MetadataURL type="iso19115:2003 > <Format>text/xml</Format>

32 Technical Guidance View Services Page 32 of 74 xlink:href=" TADATA_IDENTIFIER]&outputSchema= Name=full" </MetadataURL> <wms:layer> <wms:name> HY.PHYSICALWATERS.WATERBODIES.WATERCOURSE </wms:name> <wms:title> The hydrography physical waters theme : waterbodies </wms:title> <wms:abstract>as defined by TWG</wms:Abstract> <wms:keywordlist> <wms:keyword>gemet keyword</wms:keyword> </wms:keywordlist> <wms:ex_geographicboundingbox> <wms:westboundlongitude>-31.2</wms:westboundlongitude> <wms:eastboundlongitude>69.1</wms:eastboundlongitude> <wms:southboundlatitude>27.2</wms:southboundlatitude> <wms:northboundlatitude>90</wms:northboundlatitude> </wms:ex_geographicboundingbox> <!-- Identifier whose meaning is defined in an AuthorityURL element --> <Identifier authority="agivid"> 06B42F B-BB4B-5B382388D534 </Identifier> <MetadataURL type="iso19115:2003 > <Format>text/xml</Format> xlink:href=" TADATA_IDENTIFIER]&outputSchema= Name=full" </MetadataURL> </wms:layer> <wms:layer> <wms:name> HY.PHYSICALWATERS.WATERBODIES.STANDINGWATER </wms:name> <wms:title> The hydrography physical waters theme:standing water </wms:title> <wms:abstract>as defined by TWG</wms:Abstract> <wms:keywordlist> <wms:keyword>gemet keyword</wms:keyword> </wms:keywordlist> <wms:ex_geographicboundingbox> <wms:westboundlongitude>-31.2</wms:westboundlongitude> <wms:eastboundlongitude>69.1</wms:eastboundlongitude>

33 Technical Guidance View Services Page 33 of 74 <wms:southboundlatitude>27.2</wms:southboundlatitude> <wms:northboundlatitude>90</wms:northboundlatitude> </wms:ex_geographicboundingbox> <Identifier authority="agivid"> 0245A84E-15B B11E-334C91ABA34F </Identifier> <MetadataURL type="iso19115:2003 > <Format>text/xml</Format> xlink:href=" TADATA_IDENTIFIER]&outputSchema= Name=full" </MetadataURL> </wms:layer> </wms:layer> </wms:capability> </wms:wms_capabilities> COUPLED RESOURCE Coupled Resource provides information about the datasets that the service operates on. If the datasets, on which the service operates, are online available, then linkage to these resources is mandatory as stated by INSIRE Metadata Implementing Rules. If there are no online resources available, Coupled Resource metadata should not be documented. Coupled Resource is mapped to the <wms:dataurl>. The <OnlineResource> element is used to reference the online resource. The online resource can be a reference to an INSPIRE direct access download service (WFS GetCapabilities) or contains a link (URL) to a location where the dataset or part of the dataset can be immediately downloaded by a simple HTTP-protocol request. In the latter case the URL can optionally link to a resource where horizontal services (for example a Member State download application) can be invoked prior to the simple download by use of HTTP-protocol. Example : <wms:wms_capabilities version= xmlns:wms= <wms:service> </wms:service> <wms:capability> <wms:layer> <wms:name>hy.physicalwaters.waterbodies</wms:name> <wms:title>hydrography Physical Waters : Waterbodies</wms:Title> <AuthorityURL name="agivid"> <OnlineResource xmlns:xlink= xlink:href=" </AuthorityURL> <MetadataURL type="iso19115:2003 > <Format>text/xml</Format> xlink:href=" TADATA_IDENTIFIER]&outputSchema= Name=full"

34 Technical Guidance View Services Page 34 of 74 </MetadataURL> <wms:layer> <wms:name> HY.PHYSICALWATERS.WATERBODIES.WATERCOURSE </wms:name> <wms:title> The hydrography physical waters theme : waterbodies </wms:title> <wms:abstract>as defined by TWG</wms:Abstract> <wms:keywordlist> <wms:keyword>gemet keyword</wms:keyword> </wms:keywordlist> <wms:ex_geographicboundingbox> <wms:westboundlongitude>-31.2</wms:westboundlongitude> <wms:eastboundlongitude>69.1</wms:eastboundlongitude> <wms:southboundlatitude>27.2</wms:southboundlatitude> <wms:northboundlatitude>90</wms:northboundlatitude> </wms:ex_geographicboundingbox> <!-- Identifier whose meaning is defined in an AuthorityURL element --> <Identifier authority="agivid"> 06B42F B-BB4B-5B382388D534 </Identifier> <MetadataURL type="iso19115:2003 > <Format>text/xml</Format> xlink:href=" TADATA_IDENTIFIER]&outputSchema= Name=full" </MetadataURL> <DataURL> <Format>application/zip</Format> xlink:href=" 5B382388D534" </DataURL> </wms:layer> <wms:layer> <wms:name> HY.PHYSICALWATERS.WATERBODIES.STANDINGWATER </wms:name> <wms:title> The hydrography physical waters theme:standing water </wms:title> <wms:abstract>as defined by TWG</wms:Abstract> <wms:keywordlist> <wms:keyword>gemet keyword</wms:keyword> </wms:keywordlist> <wms:ex_geographicboundingbox> <wms:westboundlongitude>-31.2</wms:westboundlongitude>

35 Technical Guidance View Services Page 35 of 74 <wms:eastboundlongitude>69.1</wms:eastboundlongitude> <wms:southboundlatitude>27.2</wms:southboundlatitude> <wms:northboundlatitude>90</wms:northboundlatitude> </wms:ex_geographicboundingbox> <Identifier authority="agivid"> 0245A84E-15B B11E-334C91ABA34F </Identifier> <MetadataURL type="iso19115:2003 > <Format>text/xml</Format> xlink:href=" TADATA_IDENTIFIER]&outputSchema= Name=full" </MetadataURL> <DataURL> <Format>text/xml</Format> xlink:href=" Service=WFS&Request=GetCapabilities&Version=1.0.0 </DataURL> </wms:layer> </wms:layer> </wms:capability> </wms:wms_capabilities> Get Map Operation GetMap operation The GetMap operation returns a map. Upon receiving a GetMap request, a WMS shall either satisfy the request or issue a service exception. Implementing Rules state that this map is an image spatially referenced : the GetMap request is geo-referencing the returned image at least by the use of the Bounding box and Coordinate Reference System parameters. The following table show INSPIRE parameters that shall be used within the WMS GetMap operation according to the Implementing Rules : INSPIRE parameters ISO19128:2005(E) parameters Layers Styles Coordinate Reference System Bounding box Image width Image height Image format LAYERS STYLES CRS BBOX WIDTH HEIGHT FORMAT

36 Technical Guidance View Services Page 36 of 74 Language Dimension Pair None. See LANGUAGE section TIME, ELEVATION or other sample dimension(s). In case of 2D request, the standard does not request this parameter. Table 6 INSPIRE and WMS parameters mapping GetMap request parameters Request parameter Mandatory/ optional VERSION=1.3.0 M Request version Description REQUEST=GetMap M Request name LAYERS=name,name M Comma-separated list of one or more map layers names. Names are harmonized INSPIRE layers names. STYLES=name,name M Comma-separated list of one rendering style per layer requested. When the STYLES parameter is left blank in the GetMap request, the INSPIRE default styling applies in the GetMap response to all layers (INSPIRE:DEFAULT) CRS=namespace:identifier M Coordinate reference system BBOX=minx,miny,maxx,maxy M Bounding box corners (lower left, upper right) in CRS units and in the axis order of the CRS WIDTH=output_width M Width in pixels of map picture HEIGHT=output_height M Height in pixels of map picture FORMAT=output_format M Output format of map. At least supported : Portable Network Graphics format(png; MIME type "image/png") or the GIF (Graphics Interchange Format) without LZW compression (MIME type "image/gif") TRANSPARENT=TRUE FALSE M Background transparency of map (default=true) BGCOLOR=color_value O Hexadecimal red-green-blue colour value for the background color (default=0xffffff) EXCEPTIONS=error_format O The format in which exceptions are to be reported by the WMS (default=xml) TIME=time C Time value of layer desired ELEVATION=elevation C Elevation of layer desired Other sample dimension(s) C Value of other dimensions as appropriate Table 7 - GetMap core parameters

37 Technical Guidance View Services Page 37 of VERSION The mandatory VERSION parameter. The value "1.3.0" shall be used for GetMap requests that comply with the ISO19128:2005(E) standard REQUEST The mandatory REQUEST parameter is defined in To invoke the GetMap operation, the value "GetMap" shall be used to comply with the ISO19128:2005(E) standard LAYERS The mandatory LAYERS parameter lists the map layer(s) to be returned by this GetMap request. The value of the LAYERS parameter is a comma-separated list of one or more valid INSPIRE harmonized layer names STYLES The mandatory STYLES parameter lists the style in which each layer is to be rendered. The value of the STYLES parameter is a comma-separated list of one or more valid INSPIRE style names. A client may request the default Style using a null value (as in "STYLES="). This has the same effect of putting STYLES=INSPIRE:DEFAULT for each layer in the GetMap request CRS The CRS request parameter states what Layer CRS applies to the BBOX request parameter. Values must be CRS that are defined in the INSPIRE Annex I, theme 1, Geodesy. Recommended CRS are listed in BBOX The mandatory BBOX parameter allows a Client to request a particular Bounding Box. The value of the BBOX parameter in a GetMap request is a list of comma-separated real numbers in the form "minx,miny,maxx,maxy". These values specify the minimum X, minimum Y, maximum X, and maximum Y values of a region in the Layer CRS of the request. The units, ordering and direction of increment of the X and Y axes are as defined by the Layer CRS. The four bounding box values indicate the outside limits of the region WIDTH and HEIGHT The mandatory WIDTH and HEIGHT parameters specify the size in integer pixels of the map to be produced FORMAT The mandatory FORMAT parameter states the desired format of the map. The implementing rules Annex III, Part B, section 2 Image format states that at least one of image/png or image/gif must be supported and therefore advertised in the GetCapabilities operation TRANSPARENT The mandatory TRANSPARENT parameter specifies whether the map background is to be made transparent or not BGCOLOR The optional BGCOLOR parameter is a string that specifies the color to be used as the background (non-date) pixels of the map EXCEPTIONS The default value is "XML" if this parameter is absent from the request. Other values are INIMAGE and BLANK TIME, ELEVATION and other sample dimension(s) Used when issuing request using Temporal coordinate system, height coordinate system or other dimensions. For more information, see Annexes C and D of the ISO19128:2005(E) standard. In case of 2D request, the standard does not require this parameter.

38 Technical Guidance View Services Page 38 of Link View Service operation This operation allows a Public Authority or a Third Party to declare a view Service for the viewing of its resources through the Member State View Service while maintaining the viewing capability at the Public Authority or the Third party location. This operation shall be implemented with the Discovery Metadata operation of the Discovery Service. The mechanism for publishing a view service s service metadata and discovering a View Service through its service metadata is described in [5] and [7]. The Publish Discovery Service operation supports publishing a Third Party s INSPIRE View Service in a Discovery catalogue. Based on the View Service s service metadata obtained from a Discovery Service through the GetRecords operation, the Capabilities of a remote INSPIRE View Service can be requested and spatial data published through the Layers defined in this View Service can be consumed by a View Service client. In this case the collation of maps served by different View Services is handled by the client application. In the case where it is more preferable to collate served spatial data in a View Service (for example : the Member State View Service collates spatial data that is server locally with spatial data that is served remote by a Third Party), the principal INSPIRE View Service has to include the service metadata in his own service metadata (capabilities document). In some COTS software the service metadata is harvested automatically, in other ones the service metadata has to be configured manually. The Layer definition for spatial data that is remotely served by the Third Party s INSPIRE View Service shall in this case use the cascaded attribute of the <wms:layer> element to indicate that the layer is hosted by a remote View Service. Every time spatial data from a View Service is cascaded through another View Service the value of the cascaded attribute shall be incremented by 1. The actual collation of spatial data is out of scope for this Technical Guideline Language Requirements The IR Network Services requires supporting multilingual aspects for network services. General concept: The basic principle of the realisation to support multilingualism is as follows: A network service metadata response shall contain a list of the natural languages supported by the service. This list shall contain one or more languages that are supported. A client may indicate in a request a specific language. If the requested language is contained in the list of supported languages, the natural language fields of the service response shall be in that specific language. It the requested language is not supported this parameter is to be ignored by the service. General considerations: There is not yet a standard way to deal with multilingualism when using the current ISO or OGC public Standard specifications to implement INSPIRE Network Services. For this reason INSPIRE Network Services extend the OGC-standards for multilingualism in the following way: GetCapabilities-Operation GetCapabilities-Request: The http/get binding of the GetCapabilities-Operation is extended by an additional parameter that indicates the client s preferred language. The Name of this parameter is LANGUAGE. The parameter values are based on ISO 639-2/B alpha 3 codes as used in the INSPIRE Metadata Implementing Rule. Parameter Name Parameter Value Is mandatory for a Client Request? Is mandatory to support for the Service?

39 Technical Guidance View Services Page 39 of 74 LANGUAGE ISO 639-2/B alpha 3 code (corresponds to the code used in the INSPIRE Metadata Implementing Rules) No, it is optional. Yes, it is mandatory to be supported 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 clients request or it requested an unsupported language the service shall response in the service default language. Schema: [OCG-GetCapabilities-Request]&LANGUAGE=<ISO 639-2/B alpha 3 code> Example: GetCapabilities-Response: If a Client requested a specific supported language the following fields of the GetCapabilties- Response are affected: Titles Abstracts Descriptions If a Client requested an unsupported language or the parameter is absent in the request, these fields shall be in the service default language. This behaviour equals as if the parameter is ignored and assures that any clients may still interact with the service as supplied by the OGC standard. Extended Capabilities To advertise the supported languages the service shall respond with Extended Capabilities. The Extended Capabilities shall 1. indicate the current used language for the current GetCapabilities-Response, 2. contain a list of supported languages and 3. indicate the service default language. Current used language: Depending on the requested language the value of the current language corresponds to the current used language. If a supported language was requested, the current language field shall correspond to that requested language. If an unsupported language was requested or if no specific language was requested the current language field shall correspond to the default language. List of supported languages: The list of supported languages shall consist of at least one supported language. Regardless of the requested language, the list of supported languages is invariant for each GetCapabilities-Response. Current used language: Exact one language of the listed languages shall be indicated as the service default language (default= true ). Regardless of the requested language, the service default language is invariant for each GetCapabilities-Response. The Extended Capabilities use the XML Schema as defined in chapter Example 1, service supports French and English, Service default language is French

40 Technical Guidance View Services Page 40 of 74 Response to [OCG-GetCapabilities-Request]&LANGUAGE=eng <inspire_vs:extendedcapabilities> <inspire_vs:languages> <!-- list of supported languages --> <inspire_vs:language>eng</inspire_vs:language> <inspire_vs:language default="true">fre</inspire_vs:language> </inspire_vs:languages> <inspire_vs:currentlanguage>eng</inspire_vs:currentlanguage> </inspire_vs:extendedcapabilities> Response to [OCG-GetCapabilities-Request] or [OCG-GetCapabilities-Request]&LANGUAGE=fre <inspire_vs:extendedcapabilities> <inspire_vs:languages> <!-- list of supported languages --> <inspire_vs:language>eng</inspire_vs:language> <inspire_vs:language default="true">fre</inspire_vs:language> </inspire_vs:languages> <inspire_vs:currentlanguage>fre</inspire_vs:currentlanguage> </inspire_vs:extendedcapabilities> Example 2, service supports only German Response to any GetCapabilities-Request: <inspire_vs:extendedcapabilities <inspire_vs:languages> <inspire_vs:language default="true">ger</inspire_vs:language> </inspire_vs:languages> <inspire_vs:currentlanguage>ger</inspire_vs:currentlanguage> </inspire_vs:extendedcapabilities> GetMap-Operation Neither the network service implementing rule nor the current implementing rule regards interoperability of spatial data sets and services require that rendered text on the map has to be in a specific language. If any portrayal rules will require language support for rendered text - e.g. by further amendments for Annex II or Annex III -, INSPIRE View Services shall implement the common concept as stated in chapter Common concept for other operations (optional) Although further multilingual support is not required for INSPIRE Network Services, it may be desired by a service provider to implement further multilingual support such as multilingual error messages multilingual GetFeatureInfo-Operation for WMS multilingual GetMap-Operation for WMS For that reason a further implementation concept for multilingual aspects is recommended as follows: The required INSPIRE Extension described before already provides language specific capabilities for a service. For further language support for other operations it is recommended to replace the operation-online-resources in each language specific GetCapabilities-Response by a specific operation-online-resource for that language. To support the additional operation-online-resources the service shall listen at the language specific operation end points to distinguish for the requested languages.

41 Technical Guidance View Services Page 41 of 74 To show the behaviour hereafter an example of the behaviour is given. The example shows how to extend the WMS.getMap()-Operation to support multilingual error messages. It is adaptable for other operations and the discovery services in the same way. 1. The client sends the initial Request for Capabilities: [OCG-GetCapabilities-Request] 2. The service responses with extended Capabilities including the supported Languages: <inspire_vs:extendedcapabilities> <inspire_vs:languages> <inspire_vs:language default="true">eng</inspire_vs:language> <inspire_vs:language>fre</inspire_vs:language> <inspire_vs:language>ger</inspire_vs:language> </inspire_vs:languages> <inspire_vs:currentlanguage>eng</inspire_vs:currentlanguage> </inspire_vs:extendedcapabilities> 3. The Client sends a language specific request for capabilities [OCG-GetCapabilities-Request]&LANGUAGE=eng 4. The service response with language specific capabilities containing: a. translated natural language fields (titles, abstracts) b. language specific entry points for all other language specific operations: Response to [OCG-GetCapabilities-Request]&LANGUAGE=eng or [OCG- GetCapabilities-Request] <GetMap> <Format>image/png</Format> <DCPType> <HTTP> <Get> <OnlineResource xlink:href=" </Get> </HTTP> </DCPType> </GetMap> Response to [OCG-GetCapabilities-Request]&LANGUAGE=ger <GetMap> <Format>image/png</Format> <DCPType> <HTTP> <Get> <OnlineResource xlink:href=" > </Get> </HTTP> </DCPType> </GetMap> c. 5. The Client sends a GetMap-Request to either the English or the German operation endpoint. To enforce an error message the following example sends a GetMap-Requests for a nonexistent layer: a. Example using English operation end point: Request: xistentlayer&[]

42 Technical Guidance View Services Page 42 of 74 Response: The service responses with a WMS exception including an English exception message: e.g. the requested layer does not exist. b. Example using the German operation end point: request: xistentlayer&[] response: The service responses with a WMS exception including a German exception message: e.g. der angefragte Layer existiert nicht Further Perspectives With the onward completion of OWS Common it is expected that further versions of OGC Standards do include language support. For some technical reasons the concept of OWS common were not suitable to extend the current standards. However, with the availability of further versions of the OGC base standards the concept to support multilingualism needs to be revisited Extended Capabilities The following XML instance demonstrates the additional information on multilingual aspects. This information has to be provided in a capabilities documents that is returned by an INSPIRE View Service. The XML Elements that comply with the language concept shall be applied for the <_ExtendedCapabilities> section of the capabilities document. <?xml version="1.0" encoding="utf- 8"?> <WMS_Capabilities version="1.3.0" xmlns=" xmlns:inspire_vs=" xmlns:xlink=" xmlns:xsi=" instance" xsi:schemalocation=" <Service> <Name>WMS</Name> <Title>FR INSPIRE View Service </Title> <Abstract>Service for making available INSPIRE themes</abstract> <KeywordList> <!- - vocabulary in WMS only - - > <Keyword vocabulary="iso">infomapaccessservice</keyword><!- - ISO - - > <Keyword vocabulary="gemet">keyword</keyword><!- - for themes exposed - - > </KeywordList> xlink:href=" <ContactInformation> <ContactElectronicMailAddress>contactPoint@organisation.country</ContactElectronicMail Address> </ContactInformation> <Fees>no conditions apply</fees> <AccessConstraints>None Need a key/token </AccessConstraints> <LayerLimit>1</LayerLimit><!- - WMS : ease performance, allow overlays as ask by IR - - > </Service> <Capability> <Request> <GetCapabilities> <Format>text/xml</Format>

43 Technical Guidance View Services Page 43 of 74 <DCPType> <HTTP> <Get> xlink:href="url" </Get> </HTTP> </DCPType> </GetCapabilities> <GetMap> <Format>image/png</Format> <Format>image/gif</Format> <DCPType> <HTTP> <Get> xlink:href="url" </Get> </HTTP> </DCPType> </GetMap> </Request> <Exception> <Format>XML</Format> </Exception> <inspire_vs:extendedcapabilities> <inspire_vs:metadataurl> <gmd:linkage> <gmd:url> cordbyid&version=2.0.2&id=[metadata_identifier]&outputschem a= </gmd:url> </gmd:linkage> </inspire_vs:metadataurl> <inspire_vs:languages> <inspire_vs:language>eng</inspire_vs:language> <inspire_vs:language default="true">fre</inspire_vs:language> </inspire_vs:languages> <inspire_vs:currentlanguage>eng</inspire_vs:currentlanguage> </inspire_vs:extendedcapabilities> <Layer> <Name>HARMONIZED.NAME</Name> <Title>Data specification theme title</title> <Abstract>As defined by Data specification</abstract> <KeywordList> <Keyword>GEMET keyword</keyword> </KeywordList> <CRS>EPSG:4258</CRS><!- - in WMS aliases - - > <!- - WMS : - - > <EX_GeographicBoundingBox> <westboundlongitude>lon_min</westboundlongitude> <eastboundlongitude>lon_max</eastboundlongitude> <southboundlatitude>lat_min</southboundlatitude> <northboundlatitude>lat_max</northboundlatitude> </EX_GeographicBoundingBox> <!- - if needed :

44 Technical Guidance View Services Page 44 of 74 <Dimension name="time" units="iso8601" defaults=" "> / /PID</Dimension> - - > <MetadataURL type="iso19115:2003"><!- - FIXME: needs a discovery link- - > <!- - FIXME: the xlink:href contains a URL with ID=MD_Identifier in discovery - - > <!- - compatible with OGC - - > <!- - INSPIRE: the URL + ID is then processed to issue a discovery query - - > <Format>text/xml</Format> xlink:href="discoveryserviceurl?service=csw&request=getrecordbyid&version=2.0.2&id=[me TADATA_IDENTIFIER]&outputSchema= </MetadataURL> <Style> <Name>INSPIRE:DEFAULT</Name> <Title>Data specification theme style title</title> <LegendURL width="100" height="100"> <Format>image/png</Format> xlink:href="url" </LegendURL> </Style> </Layer> <!- - Compound layer : - - > <Layer> <Title>Data specification theme title</title> <Abstract>As defined by Data specification</abstract> <KeywordList> <Keyword>GEMET keyword</keyword> </KeywordList> <CRS>EPSG:4258</CRS><!- - in WMS aliases - - > <!- - WMS : - - > <EX_GeographicBoundingBox> <westboundlongitude>lon_min</westboundlongitude> <eastboundlongitude>lon_max</eastboundlongitude> <southboundlatitude>lat_min</southboundlatitude> <northboundlatitude>lat_max</northboundlatitude> </EX_GeographicBoundingBox> <!- - if needed : <Dimension name="time" units="iso8601" defaults=" "> / /PID</Dimension> - - > <MetadataURL type="iso19115:2003"><!- - FIXME: needs a discovery link- - > <!- - FIXME: the xlink:href contains a URL with ID=MD_Identifier in discovery - - > <!- - compatible with OGC - - > <!- - INSPIRE: the URL + ID is then processed to issue a discovery query - - > <Format>text/xml</Format> xlink:href="discoveryserviceurl?service=csw&request=getrecordbyid&version=2.0.2&id=[me TADATA_IDENTIFIER]&outputSchema=

45 Technical Guidance View Services Page 45 of 74 </MetadataURL> <Style> <Name>INSPIRE:DEFAULT</Name> <Title>Data specification theme style title</title> <LegendURL width="100" height="100"> <Format>image/png</Format> xlink:href="url" </LegendURL> </Style> <!- - aggregation of : 1..*- - > <Layer> <Name>HARMONIZED.NAME</Name><!- - several sub- layers may have the same name nothing prevents that in the standard so far- - > <Title>Data specification theme title</title> <!- - WMS : its extent - - > <EX_GeographicBoundingBox> <westboundlongitude>lon_min</westboundlongitude> <eastboundlongitude>lon_max</eastboundlongitude> <southboundlatitude>lat_min</southboundlatitude> <northboundlatitude>lat_max</northboundlatitude> </EX_GeographicBoundingBox> <MetadataURL type="iso19115:2003"><!- - FIXME: needs a discovery link- - > <!- - FIXME: the xlink:href contains a URL with ID=MD_Identifier in discovery - - > <!- - compatible with OGC - - > <!- - INSPIRE: the URL + ID is then processed to issue a discovery query - - > <Format>text/xml</Format> xlink:href="discoveryserviceurl?service=csw&request=getrecordbyid&version=2.0.2&id=[me TADATA_IDENTIFIER]&outputSchema= </MetadataURL> <!- - FIXME: ScaleHint to help- - > </Layer> </Layer> </Capability> </WMS_Capabilities> XML-Schema for Extended Capabilities for Language Requirements See Annex H.

46 Technical Guidance View Services Page 46 of 74 Annex A INSPIRE Profile of Tiling WMS This annex is to be considered for future work. Operating a WMS can be stressing for a MS infrastructure when MS datasets are large and the INSPIRE performances have to be met. A lightweight profile of WMS can be used to lower the initial effort to bring datasets to the network. Whilst OGC has published a request for comments on its public web site ( there is still publicly available standard. It is worth noting that this public request for comments document holds both the GetMap() operation (standard WMS) and GetTile() operation (for tile access). As a result of FOSS4G 2007 and based on OGC's WMS 1.1.1, it is possible to use a Tile caching service as defined in or a Cache WMS as defined in The main differences with the ISO 19128:2005(E) are in the GetCapabilities and GetMap operations : 1. The GetMap operation supports a new parameter called TILED whose value is always TRUE ; 2. The CRS parameter of GetMap operation is now named SRS, but values for the INSPIRE view service are still relevant. It is worth noting that WMS allows only EPSG and AUTO namespaces ; It is recommended to use ETRS89 ellipsoidal coordinate reference system when using a tile cache map service : EPSG:4258. The most important point bound to the SRS is the tiling scheme definition (pyramid resolutions and tiles width and height).

47 Technical Guidance View Services Page 47 of 74 Annex B Language capabilities extension for other profiles. WMS Profile <?xml version="1.0" encoding="utf- 8"?> <!DOCTYPE WMT_MS_Capabilities SYSTEM " [ <!ELEMENT VendorSpecificCapabilities (INSPIRE:NetworkServicesCapabilities) > <!ELEMENT INSPIRE:NetworkServicesCapabilities (INSPIRE:Languages?, INSPIRE:CurrentLanguage)> <!ATTLIST INSPIRE:NetworkServicesCapabilities xmlns:inspire CDATA #FIXED "TBD"> <!ELEMENT INSPIRE:Languages (INSPIRE:Language+)> <!ELEMENT INSPIRE:Language (#PCDATA)> <!ATTLIST INSPIRE:Language default (true false) "false"> <!ELEMENT INSPIRE:CurrentLanguage (INSPIRE:Language)> ]> <WMT_MS_Capabilities version="1.1.1"> <Service> <Name>WMS</Name> <Title>FR INSPIRE View Service </Title> <Abstract>Service for making available INSPIRE themes</abstract> <KeywordList> <Keyword>ViewService</Keyword><!- - FIXME - - > <Keyword>infoMapAccessService</Keyword><!- - ISO - - > <Keyword>keyword</Keyword><!- - for themes exposed - - > </KeywordList> <!- - link INSPIRE metadata for this NS - - > xlink:href="discoveryserviceurl?service=csw&request=getrecordbyid&version=2.0.2&id=[me TADATA_IDENTIFIER]&outputSchema= <ContactInformation> <ContactElectronicMailAddress>contactPoint@organisation.country</ContactElectronicMail Address> </ContactInformation> <!- - FIXME: values should be listed in TG : - - > <Fees>None </Fees> <AccessConstraints>None Need a key/token </AccessConstraints> </Service> <Capability> <Request> <GetCapabilities> <Format>text/xml</Format> <DCPType> <HTTP> <Get> xlink:href="url" </Get> </HTTP> </DCPType> </GetCapabilities> <GetMap> <Format>image/png</Format>

48 Technical Guidance View Services Page 48 of 74 <Format>image/gif</Format> <DCPType> <HTTP> <Get> xlink:href="url" </Get> </HTTP> </DCPType> </GetMap> </Request> <VendorSpecificCapabilities><!- - in WMS > <INSPIRE:NetworkServicesCapabilities><!- - FIXME:keep INSPIRE namespace?- - > <INSPIRE:Languages> <INSPIRE:Language>eng</Language> <INSPIRE:Language default="true">fre</language> </INSPIRE:Languages> <INSPIRE:CurrentLanguage> <INSPIRE:Language>eng</Language> </INSPIRE:CurrentLanguage> </INSPIRE:NetworkServicesCapabilities> </VendorSpecificCapabilities><!- - in WMS > <!- - Layer made up by one dataset : - - > <Layer> <Name>HARMONIZED.NAME</Name> <Title>Data specification theme title</title> <Abstract>As defined by Data specification</abstract> <KeywordList> <Keyword>GEMET keyword</keyword> </KeywordList> <SRS>EPSG:4258</SRS><!- - in WMS aliases - - > <!- - WMS : - - > <LatLonBoundingBox minx="lon_min" miny="lat_min" maxx="lon_max" maxy="lat_max" <!- - if needed : <Dimension name="time" units="iso8601" defaults=" "> / /PID</Dimension> - - > <MetadataURL type="tc211"><!- - in WMS ><!- - FIXME: needs a discovery link - - > <!- - FIXME: the xlink:href contains a URL with ID=MD_Identifier in discovery - - > <!- - compatible with OGC - - > <!- - INSPIRE: the URL + ID is then processed to issue a discovery query - - > <Format>text/xml</Format> xlink:href="discoveryserviceurl?service=csw&request=getrecordbyid&version=2.0.2&id=[me TADATA_IDENTIFIER]&outputSchema= </MetadataURL> <Style> <Name>INSPIRE:DEFAULT</Name> <Title>Data specification theme style title</title> <LegendURL width="100" height="100"> <Format>image/png</Format>

49 Technical Guidance View Services Page 49 of 74 xlink:href="url" </LegendURL> </Style> </Layer> <!- - Compound layer : - - > <Layer> <Title>Data specification theme title</title> <Abstract>As defined by Data specification</abstract> <KeywordList> <Keyword>GEMET keyword</keyword> </KeywordList> <SRS>EPSG:4258</SRS><!- - in WMS aliases - - > <!- - WMS : extent of aggregation - - > <LatLonBoundingBox minx="lon_min" miny="lat_min" maxx="lon_max" maxy="lat_max" <!- - if needed : <Dimension name="time" units="iso8601" defaults=" "> / /PID</Dimension> - - > <MetadataURL type="tc211"><!- - in WMS ><!- - FIXME: needs a discovery link- - > <!- - FIXME: the xlink:href contains a URL with ID=MD_Identifier in discovery - - > <!- - compatible with OGC - - > <!- - INSPIRE: the URL + ID is then processed to issue a discovery query - - > <Format>text/xml</Format> xlink:href="discoveryserviceurl?service=csw&request=getrecordbyid&version=2.0.2&id=[me TADATA_IDENTIFIER]&outputSchema= </MetadataURL> <Style> <Name>INSPIRE:DEFAULT</Name> <Title>Data specification theme style title</title> <LegendURL width="100" height="100"> <Format>image/png</Format> xlink:href="url" </LegendURL> </Style> <!- - aggregation of : 1..*- - > <Layer> <Name>HARMONIZED.NAME</Name><!- - several sub- layers may have the same name nothing prevents that in the standard so far- - > <Title>Data specification theme title</title> <!- - WMS : its extent - - > <LatLonBoundingBox minx="lon_min" miny="lat_min" maxx="lon_max" maxy="lat_max" <MetadataURL type="tc211"><!- - in WMS ><!- - FIXME: needs a discovery link- - > <!- - FIXME: the xlink:href contains a URL with ID=MD_Identifier in discovery - - >

50 Technical Guidance View Services Page 50 of > discovery query - - > <!- - <!- - compatible with OGC INSPIRE: the URL + ID is then processed to issue a <Format>text/xml</Format> xlink:href="discoveryserviceurl?service=csw&request=getrecordbyid&version=2.0.2&id=[me TADATA_IDENTIFIER]&outputSchema= </MetadataURL> <!- - FIXME: ScaleHint to help- - > </Layer> </Layer> </Capability> </WMT_MS_Capabilities> WMS-C (WMS Tile Caching) Profile <?xml version="1.0" encoding="utf- 8"?> <!DOCTYPE WMT_MS_Capabilities SYSTEM " [ <!ELEMENT VendorSpecificCapabilities (INSPIRE:NetworkServicesCapabilities, TileSet*) > <!ELEMENT INSPIRE:NetworkServicesCapabilities (INSPIRE:Languages?, INSPIRE:CurrentLanguage)> <!ATTLIST INSPIRE:NetworkServicesCapabilities xmlns:inspire CDATA #FIXED "TBD"> <!ELEMENT INSPIRE:Languages (INSPIRE:Language+)> <!ELEMENT INSPIRE:Language (#PCDATA)> <!ATTLIST INSPIRE:Language default (true false) "false"> <!ELEMENT INSPIRE:CurrentLanguage (INSPIRE:Language)> ]> <WMT_MS_Capabilities version="1.1.1"> <Service> <Name>WMS</Name> <Title>FR INSPIRE View Service </Title> <Abstract>Service for making available INSPIRE themes</abstract> <KeywordList> <Keyword>ViewService</Keyword><!- - FIXME - - > <Keyword>tiled</Keyword> <Keyword>infoMapAccessService</Keyword><!- - ISO - - > <Keyword>keyword</Keyword><!- - for themes exposed - - > </KeywordList> <!- - link INSPIRE metadata for this NS - - > xlink:href="discoveryserviceurl?service=csw&request=getrecordbyid&version=2.0.2&id=[me TADATA_IDENTIFIER]&outputSchema= <ContactInformation> <ContactElectronicMailAddress>contactPoint@organisation.country</ContactElectronicMail Address> </ContactInformation> <!- - FIXME: values should be listed in TG : - - > <Fees>None </Fees> <AccessConstraints>None Need a key/token </AccessConstraints> </Service> <Capability> <Request> <GetCapabilities>

51 Technical Guidance View Services Page 51 of 74 <Format>text/xml</Format> <DCPType> <HTTP> <Get> xlink:href="url" </Get> </HTTP> </DCPType> </GetCapabilities> <GetMap> <Format>image/png</Format> <Format>image/gif</Format> <DCPType> <HTTP> <Get> xlink:href="url" </Get> </HTTP> </DCPType> </GetMap> </Request> <VendorSpecificCapabilities><!- - in WMS > <INSPIRE:NetworkServicesCapabilities><!- - FIXME:keep INSPIRE namespace?- - > <INSPIRE:Languages> <INSPIRE:Language>eng</Language> <INSPIRE:Language default="true">fre</language> </INSPIRE:Languages> <INSPIRE:CurrentLanguage> <INSPIRE:Language>eng</Language> </INSPIRE:CurrentLanguage> </INSPIRE:NetworkServicesCapabilities> <TileSet> <SRS>EPSG:4258</SRS> <BoundingBox srs="epsg:4258" minx="lon_min" miny="lat_min" maxx="lon_max" maxy="lat_max" <Resolutions>x 2x 4x </Resolutions><!- - TODO: fix resolutions in INSPIRE impl.- - > <Width>256</Width><!- - FIXME: why not 512 for the web- - > <Height>256</Height><!- - FIXME: why not 512 for the web- - > <Format>image/png image/gif</format> <Layers>HARMONIZED.NAME </Layers> </TileSet> </VendorSpecificCapabilities><!- - in WMS > <Layer> <Name>HARMONIZED.NAME</Name> <Title>Data specification theme title</title> <Abstract>As defined by Data specification</abstract> <KeywordList> <Keyword>GEMET keyword</keyword> </KeywordList> <SRS>EPSG:4258</SRS><!- - in WMS aliases - - > <!- - WMS : - - > <LatLonBoundingBox minx="lon_min" miny="lat_min" maxx="lon_max" maxy="lat_max" <!- - if needed :

52 Technical Guidance View Services Page 52 of 74 <Dimension name="time" units="iso8601" defaults=" "> / /PID</Dimension> - - > <MetadataURL type="tc211"><!- - in WMS ><!- - FIXME: needs a discovery link- - > <!- - FIXME: the xlink:href contains a URL with ID=MD_Identifier in discovery - - > <!- - compatible with OGC - - > <!- - INSPIRE: the URL + ID is then processed to issue a discovery query - - > <Format>text/xml</Format> xlink:href="discoveryserviceurl?service=csw&request=getrecordbyid&version=2.0.2&id=[me TADATA_IDENTIFIER]&outputSchema= </MetadataURL> <Style> <Name>INSPIRE:DEFAULT</Name> <Title>Data specification theme style title</title> <LegendURL width="100" height="100"> <Format>image/png</Format> xlink:href="url" </LegendURL> </Style> </Layer> <!- - Compound layer : - - > <Layer> <Title>Data specification theme title</title> <Abstract>As defined by Data specification</abstract> <KeywordList> <Keyword>GEMET keyword</keyword> </KeywordList> <SRS>EPSG:4258</SRS><!- - in WMS aliases - - > <!- - WMS : extent of aggregation - - > <LatLonBoundingBox minx="lon_min" miny="lat_min" maxx="lon_max" maxy="lat_max" <!- - if needed : <Dimension name="time" units="iso8601" defaults=" "> / /PID</Dimension> - - > <MetadataURL type="tc211"><!- - in WMS ><!- - FIXME: needs a discovery link- - > <!- - FIXME: the xlink:href contains a URL with ID=MD_Identifier in discovery - - > <!- - compatible with OGC - - > <!- - INSPIRE: the URL + ID is then processed to issue a discovery query - - > <Format>text/xml</Format> xlink:href="discoveryserviceurl?service=csw&request=getrecordbyid&version=2.0.2&id=[me TADATA_IDENTIFIER]&outputSchema= </MetadataURL>

53 Technical Guidance View Services Page 53 of 74 <Style> <Name>INSPIRE:DEFAULT</Name> <Title>Data specification theme style title</title> <LegendURL width="100" height="100"> <Format>image/png</Format> xlink:href="url" </LegendURL> </Style> <!- - aggregation of : 1..*- - > <Layer> <Name>HARMONIZED.NAME</Name><!- - several sub- layers may have the same name nothing prevents that in the standard so far- - > <Title>Data specification theme title</title> <!- - WMS : its extent - - > <LatLonBoundingBox minx="lon_min" miny="lat_min" maxx="lon_max" maxy="lat_max" <MetadataURL type="tc211"><!- - in WMS ><!- - FIXME: needs a discovery link- - > <!- - FIXME: the xlink:href contains a URL with ID=MD_Identifier in discovery - - > <!- - compatible with OGC - - > <!- - INSPIRE: the URL + ID is then processed to issue a discovery query - - > <Format>text/xml</Format> xlink:href="discoveryserviceurl?service=csw&request=getrecordbyid&version=2.0.2&id=[me TADATA_IDENTIFIER]&outputSchema= </MetadataURL> <!- - FIXME: ScaleHint to help- - > </Layer> </Layer> </Capability> </WMT_MS_Capabilities>

54 Technical Guidance View Services Page 54 of 74 Annex C Examples of SLD usage The following XML description is an example of SLD (Styled Layer Descriptor) to define a symbol for a point representing a borehole (FeatureType : BSS_Sondage). Three rules are used to define this symbol according to values of some properties. <StyledLayerDescriptor version="1.1.0" xmlns:ogc=" xmlns:xlink=" <NamedLayer> <Name>BSS_Sondages</Name> <UserStyle> <FeatureTypeStyle> <FeatureTypeName>BSS_Sondage</FeatureTypeName> Rule #1: If there is more than one image (NB_IMAGES>1) then a border is drawn (border.gif) <Rule> <ogc:filter> <ogc:propertyisgreaterthan> <ogc:propertyname>nb_images</ogc:propertyname> <ogc:literal>0</ogc:literal> </ogc:propertyisgreaterthan> </ogc:filter> <PointSymbolizer> <Graphic> <ExternalGraphic> <OnlineResource xlink:href=" <Format>image/gif</Format> </ExternalGraphic> <Size>15</Size> </Graphic> </PointSymbolizer> </Rule>

55 Technical Guidance View Services Page 55 of 74 Rule #2 : If a «COUPE»(borehole description or drawing) is available then the symbol is filled with the «remp.gif» background <Rule> <ogc:filter> <ogc:or> <ogc:propertyisequalto> <ogc:propertyname>coupe_geologique</ogc:propertyname> <ogc:literal>presente</ogc:literal> </ogc:propertyisequalto> <ogc:propertyisequalto> <ogc:propertyname>coupe_simplifiee</ogc:propertyname> <ogc:literal>presente</ogc:literal> </ogc:propertyisequalto> </ogc:or> </ogc:filter> <PointSymbolizer> <Graphic> <ExternalGraphic> <OnlineResource xlink:href=" <Format>image/gif</Format> </ExternalGraphic> <Size>15</Size> </Graphic> </PointSymbolizer> </Rule Rule #3 : If the borehole is an «OUVRAGE» then the symbol «croix.gif» is drawn <Rule> <ogc:filter> <ogc:propertyisequalto> <ogc:propertyname>ouvrage</ogc:propertyname> <ogc:literal>oui</ogc:literal> </ogc:propertyisequalto> </ogc:filter> <PointSymbolizer> <Graphic> <ExternalGraphic> <OnlineResource xlink:href=" <Format>image/gif</Format> </ExternalGraphic> <Size>15</Size> </Graphic> </PointSymbolizer> </Rule> </FeatureTypeStyle> </UserStyle> </NamedLayer> </StyledLayerDescriptor>

56 Technical Guidance View Services Page 56 of 74 Annex D Tests 1 IGNF tests with Geoserver (large scale vector database) The French National Mapping Agency (IGNF) has conducted benchmarks on a multi-scales vector databases. The aim of these benchmarks was to find out the expected architecture for meeting INSPIRE quality of services requirements. The first benchmark has been made on three (3) instances of Geoserver, running on one 4 dualcore processors, 4Gbytes of RAM server, running under Linux, each instance with 512Mbytes of RAM. The second one was conducted on seven (7) instances of Geoserver, running on two 4 dual-core processors, 4Gbytes of RAM server, running under Linux (3 on one, 4 on the other), each instance with 512Mbytes of RAM Both benchmarks used a release of Geoserver application that exposes a WMS The Java runtime was a 1.6.0_07 release. It is worth noting that the lastest release of Geoserver is faster than the one used. More benchmarks will be made with this 1.7.x releases. The vector database was made up by a collection of tables from EuroGlobalMap covering France down to 1meter resolution vector entirely covering France mainland (around 20 millions of objects). The data were stored on postgresql 8.1 running on a different dedicated server. There were half a thousand pre-prepared requests randomly played to simulate incoming requests. The target SRS was the same as the source SRS, no coordinate transformation applied during the test. The benchmarks have been done on different time slices to measure the overall stress of the infrastructure. The styling was not the INSPIRE default styling, but also not a very complex cartography (rules applied on the values of one property combined with scale rules). Image 800x600 pixels Performance for full capacities in seconds 3 instances 7 instances GIF PNG GIF PNG 1/5, /10, /15, /20, Table 8.a- Tests on Geoserver for roads vector datasets Image 800x600 pixels Performance for full capacities in seconds 3 instances 7 instances GIF PNG GIF PNG 1/5, /10, /15, /20, Table - Tests on Geoserver for bulding vector datasets Image 800x600 pixels Performance for full capacities in seconds

57 Technical Guidance View Services Page 57 of 74 3 instances 7 instances GIF PNG GIF PNG 1/5, /10, /15, /20,000 N/A Table - Tests on Geoserver for all themes (1 request per theme) vector datasets The test suite used HTTP GET requests, generated by the command line tool wget. Logs of the mod_jk apache module used in front of the instances were processed in order to compute meaningful values of performances. The duration of each test didn't exceed 10 minutes. Tests on a longer term (up to 2 hours) are currently carried out. They underline the stability of the performance measured on shorter term tests. The performance results exposed here were assessed on a large scale database (1 meter resolution), because we assumed it would be the bottleneck in term of scale. One has to be particularly careful on using the right database at the right scale. Another remark is on the targeted format : GIF images are worst to view than PNG, but the latter seems to be consuming more resources on server side. The last table shows that when requesting several INSPIRE layers the performances are better due to the fact that the replies come back faster on some layers whilst the capacity remains the same! Buildings at 1:20,000 scale

58 Technical Guidance View Services Page 58 of 74 Roads at 1:20,000 scale

59 Technical Guidance View Services Page 59 of 74 Annex E How View services work within INSPIRE This section describes essential use cases of View Services. These use cases show interactions between providers, users, as well as services. Figure 5 shows the overall system that contains major interactions between the actors. An actor is a person, organization or external system that plays a role in one or more interactions with the system. Four actors are identified : Publisher : A publisher publishes layers through a View Service. This actor may also be the owner of the resource that is described. It is assumed that the organisation or individual performing the publisher role has the owners permission to publish the metadata ;A layer is basic unit of geographic information that may be requested as a map from a server; this set of features makes up a basic unit of geographic information that may be requested as a map. 1. Viewer : This actor asks for layers and uses their visualization ; 2. View Service : This is a system that allows the viewing of one or more layers ; 3. Administrator : This actor manages the establishment and maintenance of the View Service. Figure : View Services use cases Within the domain of View Service five use cases are essential: publish, discover, request map, request info on a feature, and manage. The discover use case is not in the View Service scope but in the Discovery Service scope, and it is essential because to view a layer (representing features) it must have been discovered first. The discover use case is described in the Discovery Services chapter (Paragraph ). Publish use case A publisher publishes layers and owns the resource. As an alternative, the publisher might be a broker that does not own the resource, but publishes layers on behalf of a publisher. A layer is a welldefined set of INSPIRE features portrayed according to portrayal rules. Request capabilities use case A viewer, searches for data, and therefore requests a View service to send him its capabilities on itself and the data it serves. Request map use case A viewer, having discovered data that satisfies his or her requirements (through the discover use case) requests those layer(s) to be returned as a map (visualisation, view) of that data within a defined geographic extent

60 Technical Guidance View Services Page 60 of 74 Figure : Request Map result in a client application Request feature info use case Once the View Service has sent the map to the client application, a viewer may ask for information on a feature he points out on the map. Manage use case An administrator manages the View Service including the data (layers) available from this service.

61 Technical Guidance View Services Page 61 of 74

62 Technical Guidance View Services Page 62 of 74 Annex F The relation of view services to other technical components in INSPIRE The aim technical guidance document is to describe how INSPIRE view services should be implemented. The focus of this limited to the characteristics of this service type, in the broader context of the technical infrastructure for INSPIRE it is only one single building block. Many use cases and workflows in a spatial data infrastructure are comprehensive and span across various technical components. These workflows and use cases are not directly handled in the INSPIRE technical guidance document, so each of them addresses single aspects only; e.g. for each of the network service types, metadata, spatial data. To provide guidance and to help understanding the nature of technical components (entities), their relationships, their context and how they could interact to realize use cases and workflows is the purpose of the INSPIRE domain model. Beside others, three major cross technical component aspects are of importance for INSPIRE view services: 1) Layers and spatial datasets Layers provide a visualization representation of spatial datasets. The IR interoperability of spatial data sets and services provide definitions for layers. These definitions mandate the layers name, its title, its minimum symbolization and the spatial object types to be used as data sources, given that spatial object types are represented through spatial datasets. This has a major impact on the way that the layers of a view service are organized (and possibly how a member state organizes its view services). This is especially through the fact that the layer name is used as identifier and needs to be unambiguous within a view service instance, meaning that only one instance of layer with the layer name following the official layer definition can be used. Category layers can help in situations, where the corresponding spatial datasets is more than one. 2) Linkages to metadata records As described, layers provide a visualization representation of spatial datasets. Metadata records for these spatial datasets exist and are accessible through discovery services. Beside providing a description of the spatial dataset used to build up a layer, the metadata allows to initialize additional workflows like accessing the data itself. This requires that layers provide a linkage to the metadata description of the spatial dataset. This is done through the element metadataurl as part of the capabilities. This element is to be populated with a single URL that allows access to an unambiguous metadata record. The discovery service provides the GetRecordById operation. This operation allows expressing access in a single HTTP/GET URL but requires a metadata element fileidentifier which is the identifier of a metadata record. 3) Metadata for view services and relation to metadata for spatial datasets The minimum geospatial resource that is been described through metadata is a spatial dataset. However it might be required or wished that also view services are described with a dedicated metadata document in order to provide more information on the service itself. Such service metadata would obviously benefit if they are related to the metadata of spatial datasets they operate on; now that I found this spatial dataset, show me services that provide access to it. This is facilitated through the metadata element operateson using the resource identifier of the spatial dataset. For automated invocation, metadata for view services provide two mechanism: simple binding using the metadata element resourcelocator pointing to the capabilities of the view service or an extended binding allowing to express that a targeted operation on the view service needs to be invoked (like a getmap operation directly referencing a particular layer). The INSPIRE domain model describes these aspects in details. It is therefore recommended to get familiar with it parallel with this technical guidance document.

63 Technical Guidance View Services Page 63 of 74 Annex G Quality of Services Performance For a 470 Kilobytes image (e.g. 800x600 pixels with a colour depth of 8 bits), the response time for sending the initial response to a Get Map Request to a view service shall be maximum 5 seconds in normal situation. Normal situation represents periods out of peak load. It is set at 90% of the time. For performance reasons the maximum number of layers a client is permitted to include in a single GetMap request can be limited to 1. To limit the number of layers, the optional <wms:layerlimit> element should be used. Capacity The minimum number of served simultaneous service requests to a view service according to the performance quality of service shall be 20 per second. Availability The probability of a Network Service to be available shall be 99% of the time. As there are 24 hours a day, 7 days a week are worth 168 hours. There are 4.33 weeks per month (average) which is approximately hours per month. The following table shows the maximum downtime according to the implementing rules : %Uptime Max. Downtime/week Max. Downtime/month Max. Downtime/year 98% 3.4 hours hours 7.27 days 98.6% 2.4 hours hours 5.09 days 99% 1.7 hours 7.27 hours 3.63 days 99.5% 0.8 hours 3.64 hours 1.82 days 99.9% 10 minutes 0.73 hours 8.73 hours 99.99% 1 minute 4 minutes 52 minutes % 6 seconds 26 seconds 5 minutes Table Downtime per week, month, year It is recommended to evaluate availability based on a time frame of one year.

64 Technical Guidance View Services Page 64 of 74

65 Technical Guidance View Services Page 65 of 74 Annex H Extended Capabilities INSPIRE XML Schema For Extended Capabilities The following XML schema defines the additional information on metadata and multilingual aspects. The capabilities documents that is returned by an INSPIRE View Service shall declare the INSPIRE namespace in the XML root element as follows : xmlns:inspire_vs=" Design View

66 Technical Guidance View Services Page 66 of 74