INSPIRE Infrastructure for Spatial Information in Europe D2.8.I.

7 INSPIRE Data Specification on Transport Networks Guidelines

Title Creator Date Subject Publisher Type Description Contributor Format Source Rights Identifier Language Relation Public INSPIRE_DataSpecification_TN_v3.0.1.pdf En Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) Project duration D2.8.I.7 INSPIRE Data Specification on Transport Networks Guidelines INSPIRE Thematic Working Group Transport Networks 2009-10-02 INSPIRE Data Specification for the spatial data theme Transport Networks INSPIRE Thematic Working Group Transport Networks Text This document describes the INSPIRE Data Specification for the spatial data theme Transport Networks Members of the INSPIRE Thematic Working Group Transport Networks Portable Document Format (PDF)

Coverage

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page II

Foreword How to read the document?

This guideline describes the INSPIRE Data Specification on Transport Networks as developed by the Thematic Working Group Transport Networks using both natural and a conceptual schema language. The data specification is based on the agreed common INSPIRE data specification template. The guideline contains detailed technical documentation of the data specification highlighting the mandatory and the recommended elements related to the implementation of INSPIRE. The technical provisions and the underlying concepts are often illustrated by examples. Smaller examples are within the text of the specification, while longer explanatory examples are attached in the annexes. The technical details are expected to be of prime interest to those organisations that are/will be responsible for implementing INSPIRE within the field of Transport Networks. At the beginning of the document, two executive summaries are included that provide a quick overview of the INSPIRE data specification process in general, and the content of the data specification on Transport Networks in particular. We highly recommend that managers, decision makers, and all those new to the INSPIRE process and/or information modelling should read these executive summaries first. The UML diagrams (in Chapter 5) offer a rapid way to see the main elements of the specifications and their relationships. Chapter 5 also contains the Feature Catalogue including the definition of the spatial object types, attributes, and relationships. People having thematic expertise but not familiar with UML can fully understand the content of the data model focusing on the Feature Catalogue. Users might also find the Feature Catalogue especially useful to check if it contains the data necessary for the applications that they run. The document will be publicly available as a non-paper. It does not represent an official position of the European Commission, and as such can not be invoked in the context of legal procedures. Legal Notice Neither the European Commission nor any person acting on behalf of the Commission is responsible for the use which might be made of this publication.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page III

Interoperability of Spatial Data Sets and Services General Executive Summary

The challenges regarding the lack of availability, quality, organisation, accessibility, and sharing of spatial information are common to a large number of policies and activities and are experienced across the various levels of public authority in Europe. In order to solve these problems it is necessary to take measures of coordination between the users and providers of spatial information. The Directive 2007/2/EC of the European Parliament and of the Council adopted on 14 March 2007 aims at establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) for environmental policies, or policies and activities that have an impact on the environment. INSPIRE will be based on the infrastructures for spatial information that are created and maintained by the Member States. To support the establishment of a European infrastructure, Implementing Rules addressing the following components of the infrastructure are being specified: metadata, interoperability of spatial data themes (as described in Annexes I, II, III of the Directive) and spatial data services, network services and technologies, data and service sharing, and monitoring and reporting procedures. INSPIRE does not require collection of new data. However, after the period specified in the Directive1 Member States have to make their data available according to the Implementing Rules. Interoperability in INSPIRE means the possibility to combine spatial data and services from different sources across the European Community in a consistent way without involving specific efforts of humans or machines. It is important to note that interoperability is understood as providing access to spatial data sets through network services, typically via Internet. Interoperability may be achieved by either changing (harmonising) and storing existing data sets or transforming them via services for publication in the INSPIRE infrastructure. It is expected that users will spend less time and efforts on understanding and integrating data when they build their applications based on data delivered within INSPIRE. In order to benefit from the endeavours of international standardisation bodies and organisations established under international law their standards and technical means have been referenced, whenever possible. To facilitate the implementation of INSPIRE, it is important that all stakeholders have the opportunity to participate its specification and development. For this reason, the Commission has put in place a consensus building process involving data users and providers together with representatives of industry, research, and government. These stakeholders, organised through Spatial Data Interest Communities (SDIC) and Legally Mandated Organisations (LMO)2, have provided reference materials, participated in the user requirement and technical3 surveys, proposed experts for the Data Specification Drafting Team4 and Thematic Working Groups5, expressed their views on the drafts of the technical documents of the data specification development framework6; they have reviewed and tested the draft data specifications and have been invited to comment the draft structure of the implementing rule on interoperability of spatial data sets and services. The development framework elaborated by the Data Specification Drafting Team aims at keeping the data specifications of the different themes coherent. It summarises the methodology to be used for the
1

For Annex I data: within two years of the adoption of the corresponding Implementing Rules for newly collected and extensively restructured data and within 7 years for other data in electronic format still in use. 2 The number of SDICs and LMOs on 21/08/2009 was 301 and 176 respectively 3 Surveys on unique identifiers and usage of the elements of the spatial and temporal schema, 4 The Data Specification Drafting Team has been composed of experts from Austria, Belgium, Czech Republic, France, Germany, Greece, Italy, Netherlands, Norway, Poland, Switzerland, UK, and the European Environmental Agency 5 The Thematic Working Groups of Annex I themes have been composed of experts from Belgium, Czech Republic, Denmark, Finland, France, Germany, Hungary, Italy Netherland, Norway, Poland, Portugal, Slovenia, Spain, Sweden, Switzerland, UK, the European Commission, and the European Environmental Agency 6 Four documents describing common principles for data specifications across all spatial data themes. See further details in the text.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page IV

data specifications and provides a coherent set of requirements and recommendations to achieve interoperability. The pillars of the framework are four technical documents: - The Definition of Annex Themes and Scope7 describes in greater detail the spatial data themes defined in the Directive, and thus provides a sound starting point for the thematic aspects of the data specification development. - The Generic Conceptual Model8 defines the elements necessary for interoperability and data harmonisation including cross-theme issues. It specifies requirements and recommendations with regard to data specification elements of common use, like the spatial and temporal schema, unique identifier management, object referencing, a generic network model, some common code lists, etc. Those requirements of the Generic Conceptual Model that are directly implementable will be included in the Implementing Rule on Interoperability of Spatial Data Sets and Services. - The Methodology for the Development of Data Specifications9 defines a repeatable methodology enabling to arrive from user requirements to a data specification through a number of steps including use-case development, initial specification development and analysis of analogies and gaps for further specification refinement. - The Guidelines for the Encoding of Spatial Data10 defines how geographic information can be encoded to enable transfer processes between the systems of the data providers in the Member States. Even though it does not specify a mandatory encoding rule it sets GML (ISO 19136) as the default encoding for INSPIRE. Based on the data specification development framework, the Thematic Working Groups have created the INSPIRE data specification for each Annex I theme. The data specifications follow the structure of ISO 19131 Geographic information - Data product specifications standard. They include the technical documentation of the application schema, the spatial object types with their properties, and other specifics of the spatial data themes using natural language as well as a formal conceptual schema language11. A consolidated model repository, feature concept dictionary, and glossary are being maintained to support the consistent specification development process and potential further reuse of specification elements. The consolidated model consists of the harmonised models of the relevant standards from the ISO 19100 series, the INSPIRE Generic Conceptual Model, and the application schemas12 developed for each spatial data theme. The multilingual INSPIRE Feature Concept Dictionary contains the definition and description of the INSPIRE themes together with the definition of the spatial object types present in the specification. The INSPIRE Glossary defines all the terms (beyond the spatial object types) necessary for understanding the INSPIRE documentation including the terminology of other components (metadata, network services, data sharing, and monitoring). By listing a number of requirements and making the necessary recommendations, the data specifications enable full system interoperability across the Member States, within the scope of the application areas targeted by the Directive. They are published as technical guidelines and provide the basis for the content of the Implementing Rule on Interoperability of Spatial Data Sets and Services for data themes included in Annex I of the Directive. The Implementing Rule will be extracted from the data specifications keeping in mind the technical feasibility as well as cost-benefit considerations. The Implementing Rule will be legally binding for the Member States. In addition to providing a basis for the interoperability of spatial data in INSPIRE, the data specification development framework and the thematic data specifications can be reused in other environments at

http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.3_Definition_of_Annex_Theme s_and_scope_v3.0.pdf 8 http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.5_v3.1.pdf 9 http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.6_v3.0.pdf 10 http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.7_v3.0.pdf 11 UML Unified Modelling Language 12 Conceptual models related to specific areas (e.g. INSPIRE themes)

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page V

local, regional, national and global level contributing to improvements in the coherence and interoperability of data in spatial data infrastructures.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page VI

Transport networks Executive Summary

Purpose INSPIRE Directive (2007/2/EC, 14.03.2007) defines the spatial data theme (theme) Transport Networks as: Road, rail, air and water transport networks and related infrastructure. Includes links between different networks. Also includes the trans-European transport network as defined in Decision 1692/96/EC of the European Parliament and of the Council of 23 July 1996 on Community guidelines for the development of the trans-European transport network (13) and future revisions of that Decision. This version (v3.0.1) of the data specification on Transport networks provides: - the basis for the development of the part of the Implementing Rules, defined in the Article 7(1) of the INSPIRE Directive, related to the spatial data theme Transport networks and - the implementation guidelines that will accompany the Implementing Rule on the Interoperability of Spatial Data Sets and Services according to Article 7(1) of the INSPIRE Directive. The data specification has been prepared by the INSPIRE Thematic Working Group Transport Networks (TWG-TN), a multinational team of experts in the field drawn from different parts of the European Union (14), in the frame of the common and transparent development process. This version of the INSPIRE data specification for Transport networks has been compiled from reference material submitted by the Spatial Data Interest Communities (SDICs) and Legally Mandated Organisation (LMOs) of INSPIRE, plus the responses to the User Requirements Survey and a set of agreed use cases - some of which have been specifically prepared by the TWG-TN based on their knowledge and experience, like environmental impact assessment, noise mapping, speed limits (related to the in-car information systems) and journey planning. A large amount of submitted reference material was available for the road networks, largely from the mapping agencies and less input from road authorities. For the other sub-themes Rail, Water and Air transport networks the TWG-TN has had to undertake additional research, building on existing material and documentation. Research has included supporting material regarding trans-European networks and the objects required to support them, such as TEN-T, as well as other initiatives for example: specific documentation from Eurocontrol for air documentation. Scope and description The transport component should comprise of an integrated transport network, and related features, that are seamless within each national border. In accordance with Article 10(2) of the INSPIRE Directive, national transport networks may also be seamless at European level, i.e. connected at national borders. Transportation data includes topographic features that are related to transport by road, rail, water, and air. It is important that the features form networks where appropriate, and that links between different networks are established, i.e. multi-modal nodes, especially at the local level, in order to satisfy the requirements for intelligent transport systems such as location based services (LBS) and telematics. The transport network should also support the referencing of transport flows to enable the navigation services. The data specification is extensive, covering major transport networks types that are defined in the five distinct transport themes (sub-themes): Road, Rail, Water, Air transport and Cableways15, including the connections between those types. The sub-themes are defined in a way that they can be used together to support an integrated approach to transport and they may be used with other spatial data themes. It is evident that there are a very large number of applications that can potentially use the Transport networks.

13 14

OJ L 228, 9.9.1996, p.1. Decision as last amended by Council Regulation (EC) No 1791/2006 (OJ L 363, 20.12.2006, p.1). The Thematic Working Group Transport Networks (TWG-TN) is composed of the experts from Belgium, France, Spain, Sweden and the United Kingdom. 15 Included in the data specification as a separate sub-theme based on the comments received in the consultation process.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page VII

Taking into account the variety of responsibilities in collecting, managing and using the data and different approaches in the data base management practice, from simple models to complex data arrangements, this data specification is provided as basic framework and with the purpose to maximize the reuse and sharing of the data about a network. It is mainly focused on the widely reused widely referenced segments of spatial objects, supporting the loose linkage between the diverse organizational data with these spatial objects and allowing the extensibility to fit into diverse applications and users needs. This approach provides a framework for users to configure and associate their own information (from surface condition surveys, to journey planning, to trans-European transport policy making etc.) using existing transport networks information in each Member State. The datasets in scope are used extensively at the local level and extended to regional, national and European levels. This data specification provides a coherent approach to the forms of the representation (physical topographic area objects or centreline representations) and consistency between data sets, the latest as different types of coherence (between spatial objects of the same theme at different levels of detail, between different spatial objects within a same area or coherence at state boundaries). All the spatial data sub-themes are based on the INSPIRE Generic Conceptual Model (GCM)(16) that relies on several ISO 19100(17) series of geographic information standards to provide the foundations for specific aspects of interoperability. Within the GCM, the Generic Network Model (GNM)(18) is defined to be shared by any network spatial data theme (e.g. Hydrography) to ensure a consistent approach across all network themes. Specific mechanisms, used in the data specification and defined in the GNM, include: - Network connection mechanism to establish the cross-border connectivity (a simple crossreferencing system to establish cross-border connections between the transport networks) or to establish intermodal connectivity (by linking two transport network elements from different transport networks which use a different mode of transport); - Object referencing to support the reuse of information (for example to avoid the duplication of the geometry and to link complementary feature types from different organistaions); - Linear referencing(19) to support and link the different transport properties to the transport elements it is used to position phenomena along a linear object, using a distance from the beginning of the linear object and - The mechanism to combine the network elements into high-level semantic meanings. The elements in the network are handled as nodes, links, aggregated links, areas and points. In addition, the individual transport links can be combined to form transport link sequences or further the combination of both can be used to form the transport link sets. The data specification includes three types of geometry: (a) (topographic) area objects, (b) centreline objects and (c) point objects. The types (a) and (b) may be alternative representations of the same real world phenomena about which the user can associate their own information (objects). The type (c) is, apart from network nodes, only included in the specification for marker posts. The basic spatial representation type is 2D vector. Topology is handled in the data specification implicitly rather than explicitly, with the main reason to keep the model simple as possible but expecting that most applications will use the network data within a topological environment. .There is therefore a prerequisite for implicit topology, where the
16 Generic Conceptual Model is part of the data specification development framework; http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.5_v3.1.pdf 17 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc_browse.htm?commid=54904 18 Generic Network Model (GNM) is described in the Generic Conceptual Model (v3.1). The GNM provides the basic structure for network nodes, links, aggregated links and areas and basic mechanisms for: grade separating crossings between network elements, cross-referencing, adding properties to a network (including the use of linear referencing) and adding inter-network connections. 19 Linear referencing is included in the GNM based on ISO 19148 (which is currently under development).

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page VIII

data provided must be sufficiently clean and capable of automated topological construction within a users application. This concept is framed with the specific requirements, including the data quality information. There are relationships with other spatial data themes, in particular with: - Hydrography, where the water transport sub-theme reuses the INSPIRE river network model for inland transportation purposes and - Addresses, where the majority of addresses can be linked to the transport links (roads, rivers, etc.). Next steps in the development It is intended that this data specification will be maintained in accordance with the future development of the INSPIRE data specification framework documents, new identified user requirements or policy requirements, development of the standards (used as a basis for data specification) and based on the best practices and on the input from the implementation of the INSPIRE Implementing Rules. The data specification guidelines will be will be published on INSPIRE web site(20).

20

http://inspire.jrc.ec.europa.eu/

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page IX

Acknowledgements
Many individuals and organisations have contributed to the development of these Guidelines. The Thematic Working Group Transport Networks (TWG-TN) included: Keith Murray (TWG Facilitator), Jordi Escriu Paradell (TWG Co-editor), Ward Verlinden (TWG Coeditor), Lars Wikstrm (TWG Co-editor), Alain Chaumet, Mark Lepage, Dave Russell, Ulf Sandgren, Darja Lihteneger (European Commission contact point). The Drafting Team Data Specifications included: Clemens Portele (Chair), Andreas Illert (Vice-chair), Kristine Asch, Marek Baranowski, Eric Bayers, Andre Bernath, Francis Bertrand, Markus Erhard, Stephan Gruber, Heinz Habrich, Stepan Kafka, Dominique Laurent, Arvid Lillethun, Ute Maurer-Rurack, Keith Murray, George Panopoulos, Claudia Pegoraro, Marcel Reuvers, Anne Ruas, Markus Seifert, Peter Van Oosterom, Andrew Woolf and the European Commission contact points: Steve Peedell, Katalin Tth, Paul Smits, Vanda Nunes de Lima. The data specifications team of the Spatial Data Infrastructures Unit of the Joint Research Centre included the members who have been participating at different steps of the process: Freddy Fierens, Anders Friis-Christensen, Darja Lihteneger, Michael Lutz, Vanda Nunes de Lima, Nicole Ostlnder, Steve Peedell, Jan Schulze Althoff, Paul Smits, Robert Tomas, Katalin Tth, Martin Tuchyna. The Consolidated UML repository has been set up by Michael Lutz, Anders Friis-Christensen, and Clemens Portele. The INSPIRE Registry has been developed by Angelo Quaglia and Michael Lutz. The INSPIRE Feature Concept Dictionary and Glossary has been consolidated by Darja Lihteneger. The data specification testing has been coordinated by Martin Tuchyna. The Testing Wiki has been set up by Loizos Bailas, Karen Fullerton and Nicole Ostlnder. Web communication and tools for the consultations have been developed by Karen Fullerton and Hildegard Gerlach. The stakeholders participated, as Spatial Data Interested Communities (SDIC) or Legally Mandated Organisations (LMO), in different steps of the development of the data specification development framework documents and the technical guidelines, providing information on questionnaires and user surveys, participating in the consultation process and workshops, testing the draft data specifications and supporting the work of their members in the Thematic Working Groups and Drafting Team Data Specifications.

Contact information Vanda Nunes de Lima European Commission Joint Research Centre Institute for Environment and Sustainability Spatial Data Infrastructures Unit TP262, Via Fermi 2749 I-21027 Ispra (VA) ITALY E-mail: [email protected] Tel.: +39-0332-7865052 Fax: +39-0332-7866325 http://ies.jrc.ec.europa.eu/ http://ec.europa.eu/dgs/jrc/ http://inspire.jrc.ec.europa.eu/

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page X

Table of contents
1 2 Scope............................................................................................................................................... 1 Overview ......................................................................................................................................... 1 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 3 4 5 Name and acronyms .............................................................................................................. 1 Informal description................................................................................................................ 1 Normative References ........................................................................................................... 1 Information about the creation of the specification ................................................................ 2 Terms and definitions............................................................................................................. 2 Symbols and abbreviations .................................................................................................... 2 Notation of requirements and recommendations ................................................................... 4 Conformance.......................................................................................................................... 4

Specification scopes...................................................................................................................... 4 Identification information .............................................................................................................. 4 Data content and structure ......................................................................................................... 12 5.1 Basic notions........................................................................................................................ 13 5.1.1 Placeholder and candidate types..................................................................................... 13 5.1.2 Voidable characteristics................................................................................................... 14 5.1.3 Code lists and Enumerations........................................................................................... 15 5.1.3.1 Style ........................................................................................................................ 15 5.1.3.2 Governance............................................................................................................. 15 5.1.4 Stereotypes...................................................................................................................... 15 5.1.5 Constraints....................................................................................................................... 15 5.2 Application schema Common Transport Elements.............................................................. 16 5.2.1 Description ....................................................................................................................... 16 5.2.1.1 Narrative description ............................................................................................... 16 5.2.1.2 UML Overview......................................................................................................... 16 5.2.1.3 Consistency between spatial data sets................................................................... 18 5.2.1.4 Identifier management ............................................................................................ 19 5.2.1.5 Modelling of object references ................................................................................ 20 5.2.1.6 Geometry representation ........................................................................................ 22 5.2.1.7 Temporality representation ..................................................................................... 25 5.2.2 Feature catalogue............................................................................................................ 25 5.2.2.1 Spatial object types ................................................................................................. 30 5.2.2.2 Enumerations and code lists................................................................................... 36 5.2.2.3 Imported types (informative) ................................................................................... 38 5.3 Application schema Road Transport Networks.................................................................... 40 5.3.1 Description ....................................................................................................................... 40 5.3.1.1 Narrative description ............................................................................................... 40 5.3.1.2 UML Overview......................................................................................................... 41 5.3.1.3 Consistency between spatial data sets................................................................... 41 5.3.1.4 Identifier management ............................................................................................ 42 5.3.1.5 Modelling of object references ................................................................................ 42 5.3.1.6 Geometry representation ........................................................................................ 42 5.3.1.7 Temporality representation ..................................................................................... 42 5.3.2 Feature catalogue............................................................................................................ 42 5.3.2.1 Spatial object types ................................................................................................. 43 5.3.2.2 Enumerations and code lists................................................................................... 53 5.3.2.3 Imported types (informative) ................................................................................... 62 5.4 Application schema Rail Transport Networks ...................................................................... 64 5.4.1 Description ....................................................................................................................... 64 5.4.1.1 Narrative description ............................................................................................... 64 5.4.1.2 UML Overview......................................................................................................... 65 5.4.1.3 Consistency between spatial data sets................................................................... 65 5.4.1.4 Identifier management ............................................................................................ 66

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page XI

5.4.1.5 Modelling of object references ................................................................................ 66 5.4.1.6 Geometry representation ........................................................................................ 66 5.4.1.7 Temporality representation ..................................................................................... 66 5.4.2 Feature catalogue............................................................................................................ 66 5.4.2.1 Spatial object types ................................................................................................. 68 5.4.2.2 Spatial object types ................................................................................................. 70 5.4.2.3 Enumerations and code lists................................................................................... 75 5.4.2.4 Imported types (informative) ................................................................................... 77 5.5 Application schema Cable Transport Networks ................................................................... 79 5.5.1 Description ....................................................................................................................... 79 5.5.1.1 Narrative description ............................................................................................... 79 5.5.1.2 UML Overview......................................................................................................... 80 5.5.1.3 Consistency between spatial data sets................................................................... 80 5.5.1.4 Identifier management ............................................................................................ 80 5.5.1.5 Modelling of object references ................................................................................ 80 5.5.1.6 Geometry representation ........................................................................................ 81 5.5.1.7 Temporality representation ..................................................................................... 81 5.5.2 Feature catalogue............................................................................................................ 81 5.5.2.1 Spatial object types ................................................................................................. 82 5.5.2.2 Enumerations and code lists................................................................................... 84 5.5.2.3 Imported types (informative) ................................................................................... 84 5.6 Application schema Water Transport Networks................................................................... 86 5.6.1 Description ....................................................................................................................... 86 5.6.1.1 Narrative description ............................................................................................... 86 5.6.1.2 UML Overview......................................................................................................... 87 5.6.1.3 Consistency between spatial data sets................................................................... 87 5.6.1.4 Identifier management ............................................................................................ 87 5.6.1.5 Modelling of object references ................................................................................ 88 5.6.1.6 Geometry representation ........................................................................................ 88 5.6.1.7 Temporality representation ..................................................................................... 88 5.6.2 Feature catalogue............................................................................................................ 88 5.6.2.1 Spatial object types ................................................................................................. 90 5.6.2.2 Enumerations and code lists................................................................................. 100 5.6.2.3 Imported types (informative) ................................................................................. 102 5.7 Application schema Air Transport Networks ...................................................................... 103 5.7.1 Description ..................................................................................................................... 103 5.7.1.1 Narrative description ............................................................................................. 103 5.7.1.2 UML Overview....................................................................................................... 105 5.7.1.3 Consistency between spatial data sets................................................................. 106 5.7.1.4 Identifier management .......................................................................................... 106 5.7.1.5 Modelling of object references .............................................................................. 106 5.7.1.6 Geometry representation ...................................................................................... 106 5.7.1.7 Temporality representation ................................................................................... 106 5.7.2 Feature catalogue.......................................................................................................... 106 5.7.2.1 Spatial object types ............................................................................................... 108 5.7.2.2 Enumerations and code lists................................................................................. 121 5.7.2.3 Candidate types and placeholders........................................................................ 127 5.7.2.4 Imported types (informative) ................................................................................. 127 6 Reference systems..................................................................................................................... 129 6.1 Coordinate reference systems ........................................................................................... 129 6.1.1 Datum ............................................................................................................................ 129 6.1.2 Coordinate reference systems....................................................................................... 129 6.1.3 Display ........................................................................................................................... 130 6.1.4 Identifiers for coordinate reference systems.................................................................. 130 6.2 Temporal reference system ............................................................................................... 130 7 Data quality ................................................................................................................................. 131 7.1 Completeness .................................................................................................................... 132 7.1.1 Commission ................................................................................................................... 132

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page XII

7.1.1.1 Rate of Excess items ............................................................................................ 132 7.1.1.2 Number of duplicate feature instances ................................................................. 133 7.1.2 Omission ........................................................................................................................ 133 7.1.2.1 Rate of missing items............................................................................................ 133 7.2 Logical consistency ............................................................................................................ 133 7.2.1 Conceptual consistency................................................................................................. 134 7.2.1.1 Conceptual schema compliance ........................................................................... 134 7.2.2 Domain consistency....................................................................................................... 134 7.2.2.1 Value domain non conformance rate .................................................................... 134 7.2.3 Format consistency........................................................................................................ 135 7.2.3.1 Physical structure conflict rate .............................................................................. 135 7.2.4 Topological consistency................................................................................................. 135 7.2.4.1 Number of invalid overlaps of surfaces................................................................. 135 7.2.4.2 Number of missing connections due to undershoots............................................ 136 7.2.4.3 Number of missing connections due to overshoots .............................................. 137 7.2.4.4 Number of invalid slivers ....................................................................................... 138 7.2.4.5 Number of invalid self-intersect errors .................................................................. 139 7.2.4.6 Number of invalid self-overlap errors .................................................................... 140 7.3 Positional accuracy ............................................................................................................ 140 7.3.1 Absolute or external accuracy ....................................................................................... 140 7.3.1.1 Mean value of positional uncertainties.................................................................. 140 7.4 Thematic accuracy ............................................................................................................. 141 7.4.1 Classification correctness .............................................................................................. 141 7.4.1.1 Misclassification rate ............................................................................................. 141 7.4.2 Non-quantitative attribute correctness........................................................................... 142 7.4.2.1 Rate of incorrect classification for national identifier............................................. 142 8 Dataset-level metadata .............................................................................................................. 142 8.1 Mandatory and conditional metadata elements ................................................................. 143 8.1.1 Coordinate Reference System....................................................................................... 144 8.1.2 Temporal Reference System ......................................................................................... 145 8.1.3 Encoding ........................................................................................................................ 145 8.1.4 Character Encoding ....................................................................................................... 146 8.1.5 Data Quality Logical Consistency Topological Consistency.................................... 146 8.2 Optional metadata elements .............................................................................................. 147 8.2.1 Maintenance Information ............................................................................................... 147 8.2.2 Data Quality Completeness Commission ................................................................ 148 8.2.3 Data Quality Completeness Omission..................................................................... 148 8.2.4 Data Quality Logical Consistency Topological Consistency.................................... 149 8.2.5 Data Quality Positional Accuracy Absolute or external accuracy............................ 149 8.2.6 Data Quality Logical Consistency Conceptual Consistency.................................... 149 8.2.7 Data Quality Logical Consistency Domain Consistency.......................................... 150 8.2.8 Data Quality Logical Consistency - Format Consistency ........................................... 150 8.2.9 Data Quality Thematic Accuracy Thematic Classification Correctness .................. 151 8.2.10 Data Quality Thematic accuracy Non-quantitative correctness............................... 151 8.3 Guidelines on using metadata elements defined in Regulation 1205/2008/EC................. 151 8.3.1 Conformity...................................................................................................................... 151 8.3.2 Lineage .......................................................................................................................... 152 8.3.3 Temporal reference ....................................................................................................... 152 9 Delivery ....................................................................................................................................... 152 9.1 Delivery medium ................................................................................................................ 152 9.2 Encodings........................................................................................................................... 153 9.2.1 Encoding for application schema Common Transport Elements .................................. 153 9.2.1.1 Default Encoding: GML Application Schema ........................................................ 153 9.2.2 Encoding for application schema of Road transport networks ...................................... 153 9.2.2.1 Default Encoding: GML Application Schema ........................................................ 153 9.2.3 Encoding for application schema of Rail transport networks......................................... 154 9.2.3.1 Default Encoding: GML Application Schema ........................................................ 154 9.2.4 Encoding for application schema of Cable transport networks ..................................... 154

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page XIII

9.2.4.1 Default Encoding: GML Application Schema ........................................................ 154 9.2.5 Encoding for application schema of Water transport networks ..................................... 154 9.2.5.1 Default Encoding: GML Application Schema ........................................................ 154 9.2.6 Encoding for application schema of Air transport networks .......................................... 155 9.2.6.1 Default Encoding: GML Application Schema ........................................................ 155 10 10.1 10.2 10.3 10.4 11 11.1 11.2 11.3 11.4 12 Data Capture ........................................................................................................................... 155 Centrelines ......................................................................................................................... 155 Ensuring Network Connectivity .......................................................................................... 156 Linear Referencing............................................................................................................. 158 Alternative and Multiple Representations .......................................................................... 158 Portrayal .................................................................................................................................. 159 Layer Types ....................................................................................................................... 159 Default Styles ..................................................................................................................... 161 Other Well-defined Styles .................................................................................................. 171 Layers organization............................................................................................................ 172 Bibliography............................................................................................................................ 172

Annex A (normative) Abstract Test Suite ...................................................................................... 179 Annex B (informative) Imported Types .......................................................................................... 180 B.1 Spatial object types ............................................................................................................ 180 B.1.1 CrossReference ............................................................................................................. 180 B.1.2 GeneralisedLink ............................................................................................................. 180 B.1.3 GradeSeparatedCrossing .............................................................................................. 180 B.1.4 Link ................................................................................................................................ 181 B.1.5 LinkSequence ................................................................................................................ 181 B.1.6 LinkSet ........................................................................................................................... 181 B.1.7 Network.......................................................................................................................... 181 B.1.8 NetworkArea .................................................................................................................. 181 B.1.9 NetworkConnection ....................................................................................................... 181 B.1.10 NetworkElement ........................................................................................................ 183 B.1.11 NetworkProperty........................................................................................................ 183 B.1.12 Node .......................................................................................................................... 184 B.2 Data types .......................................................................................................................... 185 B.2.1 DirectedLink ................................................................................................................... 185 B.2.2 LinkReference................................................................................................................ 185 B.2.3 NetworkReference ......................................................................................................... 186 B.2.4 SimpleLinearReference ................................................................................................. 186 B.2.5 SimplePointReference ................................................................................................... 186 B.3 Enumerations and code lists .............................................................................................. 187 B.3.1 ConnectionTypeValue ................................................................................................... 187 B.3.2 LinkDirectionValue......................................................................................................... 187 Annex C (informative) Supplementary Information regarding alternative representations of network objects ................................................................................................................................. 188 C.1 Alternative Representations ............................................................................................... 188

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 1

1 Scope
This document specifies a harmonised data specification for the spatial data theme Transport Networks as defined in Annex I of the INSPIRE Directive. This data specification provides the basis for the drafting of Implementing Rules according to Article 7 (1) of the INSPIRE Directive [Directive 2007/2/EC]. The entire data specification will be published as implementation guidelines accompanying these Implementing Rules.

2 Overview
2.1 Name and acronyms
INSPIRE data specification for the theme Transport Networks

2.2 Informal description

Definition: The Transport Networks theme is defined within the INSPIRE Directive as: Road, rail, air and water transport networks and related infrastructure. Includes links between different networks. Also includes the trans-European transport network as defined in Decision No 1692/96/EC of the European Parliament and of the Council of 23 July 1996 on Community Guidelines for the development of the trans-European transport network (1) and future revisions of that Decision. (1) OJ L 228, 9.9.1996, p. 1. Decision as last amended by Council Regulation (EC) No 1791/2006 (OJ L 363, 20.12.2006, p. 1) [Directive 2007/2/EC] Description: It is further described in the INSPIRE Feature Concept Dictionary as follows: The transport component should comprise an integrated transport network, and related features, that are seamless within each national border. In accordance with article 10.2 of the Directive, national transport networks may also be seamless at European level, i.e. connected at national borders. Transportation data includes topographic features related to transport by road, rail, water, and air. It is important that the features form networks where appropriate, and that links between different networks are established, i.e. multi-modal nodes, especially at the local level, in order to satisfy the requirements for intelligent transport systems such as location based services (LBS) and telematics. The transport network should also support the referencing of transport flow to enable our navigation services. [INSPIRE Feature Concept Dictionary].

2.3 Normative References

[Directive 2007/2/EC] Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 2

[ISO 19107] [ISO 19113] [ISO 19115] [ISO 19118] [ISO 19138]

EN ISO 19107:2005, Geographic Information Spatial Schema EN ISO 19113:2005, Geographic Information Quality principles EN ISO 19115:2005, Geographic information Metadata (ISO 19115:2003) EN ISO 19118:2006, Geographic information Encoding (ISO 19118:2005) ISO/TS 19138:2006, Geographic Information Data quality measures

[Regulation 1205/2008/EC] Regulation 1205/2008/EC implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata ISO/AWI 19148 Geographic information -- Location based services -- Linear referencing system Regulation L228, 09/09/1996 Community Guidelines for the development of the trans-European transport network.
Decision No 884/2004/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 29 April 2004 amending Decision No 1692/96/EC on Community guidelines for the development of the Trans-European transport network Directive of 27 June 1985 on the assessment of the effects of certain public and private projects on the environment (85/337/EEC) (OJ L 175, 5.7.1985, p. 40)

2.4 Information about the creation of the specification

Document title: Reference date: Responsible party: Language: INSPIRE Data Specification Transport Networks 2009-07-17 INSPIRE TWG Transport Networks English

2.5 Terms and definitions

Terms and definitions necessary for understanding this document are defined in the INSPIRE Glossary21. There are no new terms defined in this specification.

2.6 Symbols and abbreviations

This is a list of abbreviations and acronyms used in the data specification AICM/AIXM ARP ATS ATZ CEDR Aeronautical Information Exchange Airport Reference Point ATS Route as described in ICAO Annex 11 Airport Traffic Zone Conference of European Directors of Roads

CEMT CTA CTR

21

EuropeanConferenceofMinistersofTransport. ControlArea ControlZone

The INSPIRE Glossary is available from http://inspire-registry.jrc.ec.europa.eu/registers/GLOSSARY

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 3

D DME
Eurocontrol EuroRoadS FATO FIR GCM GDF GNM IAF IAP IATA ICAO IFR

DangerArea DistanceMeasuringEquipment
Eurocontrol is the European Organisation for the Safety of Air Navigation. An EC funded project (2003-2006) with the aim of producing a specification framework to support interoperable road information Final Approach and Take Off Area for Helicopters Flight Information Region Generic Conceptual Model Geographic Data Files Generic Network Model Initial Approach Fix Point Instrument Approach Procedure International Air Transport Association International Civil Aviation Organization Instrument Flight Rules International Hydrographic Organization Instrument Landing System ILS with collocated DME International Maritime Organization International Organization for Standardization Localizer LOC and DME collocated Marker Beacon Microwave Landing System MLS with collocated DME North Atlantic Track (part of Organized Track System) Non-Directional Radio Beacon NDB and DME collocated Non-Directional Radio Beacon and Marker Beacon Swedish National Road Database Prohibited Area Restricted Area Road Administration Data Exchange Format Area Navigation Route IHO Hydrographic Geospatial Standard for Marine Data and Information IHO International Hydrographic Dictionary Standard Instrument Departure Standard Instrument Arrival Tactical Air Navigation Beacon; Tactical Air Navigation Route Trans-European Network - Transport Transponder Landing System Terminal Control Area Transport Networks Traffic Separation Scheme Thematic Working Group Upper Flight Information Region Visual Flight Rules VHF Omnidirectional Radio Range VOR and DME collocated VOR and TACAN collocated

IHO ILS ILSDME IMO ISO LOC LOCDME MKR MLS MLSDME NAT NDB NDBDME NDBMKR
NVDB P R RADEF RNAV S-100 S-32 SID STAR TACAN TEN-T TLS TMA TN TSS TWG UIR VFR VOR VOR-DME VORTAC

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 4

2.7 Notation of requirements and recommendations

To make it easier to identify the mandatory requirements and the recommendations for spatial data sets in the text, they are highlighted and numbered. Requirement X Requirements are shown using this style.

Recommendation X Recommendations are shown using this style.

2.8 Conformance
Requirement 1 Any dataset claiming conformance with this INSPIRE data specification shall pass the requirements described in the abstract test suite presented in Annex A.

3 Specification scopes
This data specification has only one scope, the general scope.

4 Identification information
Table 1 Information identifying the INSPIRE data specification Transport Networks Title 4.1 NSPIRE data specification on Transport Networks Abstract 4.2 Transport Networks is defined within the INSPIRE Feature Concept Dictionary as: The transport component should comprise an integrated transport network, and related features, that are seamless within each national border. In accordance with article 10.2 of the Directive, national transport networks may also be seamless at European level, i.e. connected at national borders. Transportation data includes topographic features related to transport by road, rail, water, and air. It is important that the features form networks where appropriate, and that links between different networks are established, i.e. multi-modal nodes, especially at the local level, in order to satisfy the requirements for intelligent transport systems such as location based services (LBS) and telematics. The transport network should also support the referencing of transport flow to enable our navigation services. [INSPIRE Feature Concept Dictionary] The INSPIRE Directive sets out the key requirements in the following Articles of the Directive.

Article 4 1. This Directive shall cover spatial data sets which fulfil the following conditions:

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 5

(a) they relate to an area where a Member State has and/or exercises jurisdictional rights; (b) they are in electronic format; (c) they are held by or on behalf of any of the following: (i) a public authority, having been produced or received by a public authority, or being managed or updated by that authority and falling within the scope of its public tasks; (ii) a third party to whom the network has been made available in accordance with Article 12; (d) they relate to one or more of the themes listed in Annex I, II or III. 2. In cases where multiple identical copies of the same spatial data set are held by or on behalf of various public authorities, this Directive shall apply only to the reference version from which the various copies are derived. 4. This Directive does not require collection of new spatial data. Article 7 1. Implementing rules laying down technical arrangements for the interoperability and, where practicable, harmonisation of spatial data sets and services, designed to amend non-essential elements of this Directive by supplementing it, shall be adopted in accordance with the regulatory procedure with scrutiny referred to in Article 22(3). Relevant user requirements, existing initiatives and international standards for the harmonisation of spatial data sets, as well as feasibility and cost-benefit considerations shall be taken into account in the development of the implementing rules. 4. Implementing rules referred to in paragraph 1 shall cover the definition and classification of spatial objects relevant to spatial data sets related to the themes listed in Annex I, II or III and the way in which those spatial data are geo-referenced. Article 8 1. In the case of spatial data sets corresponding to one or more of the themes listed in Annex I or II, the implementing rules provided for in Article 7(1) shall meet the conditions laid down in paragraphs 2, 3 and 4 of this Article. 2. The implementing rules shall address the following aspects of spatial data: (a) a common framework for the unique identification of spatial objects, to which identifiers under national systems can be mapped in order to ensure interoperability between them; (b) the relationship between spatial objects; (c) the key attributes and the corresponding multilingual thesauri commonly required for policies which may have an impact on the environment; (d) information on the temporal dimension of the data; (e) updates of the data. 3. The implementing rules shall be designed to ensure consistency between items of information which refer to the same location or between items of information which refer to the same object represented at different scales. 4. The implementing rules shall be designed to ensure that information derived from different spatial data sets is comparable as regards the aspects referred to in Article 7(4) and in paragraph 2 of this Article

To support a consistent approach to all themes the European Commission, through the Data Specifications Drafting Team, developed the Generic Conceptual Model [GCM] which was reviewed and published prior to the commencement of work on the Annex I themes. This is the foundation model for every theme with the intention that any theme may be combined in future and used in a way that is predicable.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 6

The scope of the INSPIRE Transport Networks Data Product Specification incorporates five distinct transport themes: Road transport Rail transport Water transport Air transport Cableways This is summarised in the diagram below which shows how the Directive guides the Generic Conceptual Model [D2.5] which contains a basic framework for any kind of network model (the Generic Network Model [GNM]). From the GNM a Common Transport application schema is adapted and this then is used as the basis for all five application schema. Collectively these are drawn together in this document as the Transport Networks Data Product Specification [D2.8.1.7].

Figure 1 Document framework for this data product specification [key documents only]

These themes can be used together to support an integrated approach to transport but as noted above - they may be used with other themes developed to the same standard (e.g. response to an emergency where a fuel tanker over turns on a highway and discharges into an adjacent river network). It is evident that there are a very large number of applications that can potentially use the Transport Networks theme. Understanding of the Generic Conceptual Model is essential and the GCM/GNM should be read in conjunction with this document. The GCM which describes the basic form of real world abstraction through to a comprehensive set of data interoperability. The GNM adapts this and describes the basic concepts that underpin and define the Common Transport Application Schema upon which all five themes are based. The GCM relies on ISO standards and the 19xxx series in

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 7

particular. Topic categories Geographic description Purpose 4.3 Transportation Transport Networks 4.4 This INSPIRE data specification covers spatial data sets which relate to an area where a Member State has and/or exercises jurisdictional rights. 4.5 The purpose of this document is to specify a harmonised data specification for the spatial data theme Transport Networks as defined in Annex I of the INSPIRE Directive. However each organisation will have different responsibilities from the next and this will influence the kind of data they collect and manage and use. In turn some organisations may use simple models; others by necessity will have complex data arrangements. This data specification is provided as basic framework which users can adopt and if required extend for themselves. The model is structured to maximise reuse and the sharing of organisational data about a network. The specification is concerned only with the core spatial objects required by Transport Networks (while acknowledging that the boundary of any object grouping is never black and white). Figure 2 below outlines the scope of the specification and how it relates to associated spatial objects which are less generically used.

Figure 2 Scope of Transport Network data

Spatial Objects (core application specific) This specification is mainly focussed on the widely reused widely referenced segment of spatial objects (ie network centrelines etc). It does not attempt to try and incorporate every spatial object that might be used by any application. In Figure 2 above such objects maybe lighting columns, gantries, signals, sensors etc These are all of the type application specific and will be used/referenced by at least one organisation. Associated non-Geographic data Any non geographic data (the majority of the data holdings in any organisation) is also out of scope of this specification such records maybe an asset condition report, traffic flow records, images of assets, statistics, timetables, noise

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 8

data and so on. Therefore much of the data used in the telematics industry is classed application specific. While associated with the network all these examples are closer to the application end of the spectrum than generic use by a wide community whether they represent a geographic entity or non-geographic data. To maximise reuse the linkage of such organisational data with the spatial objects should be loose in the sense that these are ideally defined as different data objects in a database. Configured correctly such data may then reused in several different applications and any associated information shared and exchanged as desired. User defined views and flexibility The model itself is flexible and will permit a cross organisational approach where different users may collect and use different kinds of information about a network. By referencing they can relate one view e.g. a highway name, classification, route, condition survey and so on simply by using references against a common geographic framework. Methods that will be found within the GNM that support this are the linkset and link sequence. Any third party may further add their own views, thereby enabling greater reuse and easier exchange of information around a common standard set of information components. This approach enables several organisations to contribute and easily combine several views of the transport network. For a road example the combinations and contributors might be: Underlying link and node geometry: mapping agency (national or state level) Highway name: municipality National highway classification: national highway authority European highway classification: European highway authority Many of these contributors may also collect and maintain application objects and business data which can be linked to the same infrastructure. Extensibility Users can extend the schema and add their own spatial objects to support an application. Data architects should use the GCM as the basis for any such extension. To illustrate this a small number of objects that are primarily of an application need (than generic) are included in this specification. Examples of these are: Linear speed limits in the Roads theme Point kilometer posts on the Roads and Rail Area* - Port area, Railway station area, etc.

*In practice these areas may be defined by aggregations of some other area object types using objects from other themes e.g. buildings. Applications and use cases While INSPIRE is primarily an environmental directive, Transport Networks data enjoys a wide variety of applications as recognised in the footnote to the theme statement in Annex I of the Directive. The following use cases are highlighted to demonstrate the width and breadth of applications (the list is not exhaustive). o o o o o o Asset Management Capacity Planning Construction Design & Planning Disaster management Emergency response

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 9

o o o o o o o o o o o o o

Environmental Impact Assessments (incl. Noise) Estate management Flow modelling In car information systems Incident management Journey Planning Maintenance Navigation Network operation Rerouting & diversions Routing Traffic Control Traffic management

The applications in bold above were used as use cases in the preparation of this specification. These represent applications at the European, national, local public sector levels and in the private sector. It is evident that the scope of the specific does not attempt to support all these applications. User extensibility is supported and encouraged. Future revisions may incorporate further object types if it is felt that further standardisation is necessary. Characteristics of the specification The key characteristics of the Transport Networks datasets are: They contain information of specific interest for the public sector in its role to support economic growth through efficient transportation, passenger safety, environmental impacts and social planning, etc. The information is applicable from local to European levels of operation. The data represents a structure or methods of operation that is stable over time (even if parts of the data content frequently changes). Supports cross border (pan-European) applications. Being a part of the European Spatial Data Infrastructure the data may be more easily used with other kinds of data themes, such as geographical names, administrative units, and addresses etc. Private sector applications are extensive. Spatial representation type . 4.6 The spatial representation type for this theme is: 2D vector

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 10

Spatial resolution

4.7 Local to European level capability From the use case list above it is evident that the specification has wide application and at several levels. Many applications would like to move seamlessly from the macro to micro view but this is rarely possible today for many reasons chiefly todays datasets were not designed to operate in that way. Local, Regional, National and European relevance of the specification The datasets in scope are used extensively at the local level and extend to regional, national and European levels. Usage can change with levels of operation or within an organisation. The specification is mainly focussed on establishing a more coherent approach to those datasets that universally used, probably held at national or regional level and at the highest resolution within this context. This section describes the context within this respect. Area and link types of representation at the higher resolution level Some applications require a centreline network approach, some require the extent of carriageway or other form of transport, and some applications use both forms of representation. These are alternative forms of representation of a real world entity. The specification therefore supports alternative forms of representation and these may be cross referenced to support easy data exchange between the two. Only the centreline (link) can be formed into network (e.g. using the linkset). Seamless resolution representations at the local and regional level In these and other domains lower resolution representations may be preferred e.g. to view traffic flows in a region or capacity of the network. A user may wish to zoom from city level to a specific street seamlessly. Such an approach is recognised in D2.5 and outlined in D2.6. However such data management processes and methodologies remain immature. Ideally the lower resolution datasets would be derived from the local/high resolution data - outlined in the previous paragraph and referenced (no geographic) data could then be aggregated and disaggregated as desired. Multiple representations at regional, national and European levels. Ideally the same data would be scalable dynamically from local to European level seamlessly. Since the current datasets and methods are insufficiently mature to support this - several levels of detail will usually be stored to represent the network at different operational levels. Unfortunately today there is very little correspondence between each level. Ideally it would be easy to seamlessly move from the highest to the lowest resolution with corresponding scaling and aggregation and disaggregation of the associated organisational information (as we do on statistical datasets) e.g. for reporting purposes or trans European analysis, real time management, planning and policy making. Such a multiple resolution approach is discussed in D2.6 Annex A.19 and Annex B.1 of this document. Transport networks lend themselves to such an approach. In the meantime this specification applies to all levels of detail. Further proving of the approach is required to support truly seamless integration of the levels of detail*. In the meantime data providers are encouraged to introduce this specification at the local level as a priority. *It is reported that some organisations are currently investigating such an approach but it is not yet formally adopted to such a level to document it in this version of the Transport networks specification (TN specification). This is an area that requires further research to improve both the capability and automation potential.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 11

Supplementary information

4.8 Overview Structure of the Transport Networks data product specification and commentary on specific issues within the specification

Structure The structure follows the ISO standard for data specifications (ISO 19xxx). Sections 1-3 are prepared to a defined pattern for all themes. This section (4) provides context, background and some introductory information to the specification. Section 5 contains a combination of the outputs from the UML model (application schemas) for the Common Transport Model and each of the five themes. This is supplemented by a descriptive narrative. Sections 6 11 are largely harmonised across all themes with variations that are essential to support aspects of this theme. The Annex are informative and include the Abstract Test Suite and further background information and examples. Linear Referencing Linear referencing is incorporated in the specification. This uses an approach aligned with the current draft standard ISO 19148; which establishes linear referencing within a spatial environment (rather than a traditional standalone approach). The aim of this is to better support data sharing across referencing mechanisms, and to offer coordinates for any object referenced linearly, in the same national coordinate system. Logical networks Logical networks (see Annex B.1) can be used within the model but their spatial value is very limited or in some cases may be non-existent. Therefore caution is required. Where these are in operation alongside the above forms of representation it is suggested that any corresponding nodes are reused or at least cross referenced to provide a relationship between the systems to preserve the potential for data sharing and exchange where that is both relevant and appropriate. Network Interconnections There are several cases where networks need to be joined up. For example at national, regional or dataset boundaries and at intermodal points within networks. This is provided by the Network Connection component which is defined in the Generic Network Model. Relationships with other themes There are linkages to other themes. In particular: Hydrography [HY] the water transport theme reuses the INSPIRE river network model, for inland transportation purposes. To avoid undue interference with the river network - connections link inland ports with the nearest node on the river network. In marine waters the model is influenced by specifications from the International Hydrographic Office [IHO]. Addresses [AD] the majority of addresses are linked to transport links (roads, some rivers etc) and thoroughfares are not part of the transport network defined in this specifications (e.g. pedestrian ways). However there is no link shown in the TN model this is more logically made from the address to the transport object to which it is associated. The primary purpose for such a link would be to ensure consistency of geographic highway/thoroughfare name and to support address to address navigation via transport networks. Source material The Transport Networks data product specification (TN DPS) has been developed using the reference material, expertise and dialogue with LMO and SDIC. Other material submitted by LMO/SDIC has been supplemented by research to fill in the

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 12

gaps in evidence. The TN specification is extensive and has therefore been broken into five interoperable transport themes: Road, Rail, Water, Air transport and Cableway networks. Topology Topology is handled implicitly rather than explicitly in the entire transport schema. This is to keep the model simple as possible. Generally systems will build topology in a form that best meets the users application. It is expected that most applications will use the network data within a topological environment. There is therefore a prerequisite for implicit topology. This means that the data provided must be sufficiently clean and capable of automated topological construction within a users application. There are therefore specific data capture requirements and these are described in Chapter 7 on Data Quality and in Chapter 10 on Data Capture. Future Updates of this specification It is intended that this specification will be maintained in accordance with current proposals outlined by the Data Specifications Drafting Team. It is not possible to state at this time when the next update will occur.

5 Data content and structure

Requirement 2 Spatial data sets related to the theme Transport Networks shall be provided using the spatial object types and data types specified in the application schemas in this section.

Requirement 3

Each spatial object shall comply with all constraints specified for its spatial object type or data types used in values of its properties, respectively.

Recommendation 1 The reason for a void value should be provided where possible using a listed value from the VoidValueReason code list to indicate the reason for the missing value. NOTE The application schema specifies requirements on the properties of each spatial object including its multiplicity, domain of valid values, constraints, etc. All properties have to be reported, if the relevant information is part of the data set. Most properties may be reported as void, if the data set does not include relevant information. See the Generic Conceptual Model [INSPIRE DS-D2.5] for more details.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 13

class Transport Netw orks ov erv iew INSPIRE Generic Conceptual Model applicationSchema Netw ork

(from Base Models )

INSPIRE Data Specification Transport Networks applicationSchema Road Transport Netw ork applicationSchema Air Transport Netw ork applicationSchema Common Transport Elements applicationSchema Railw ay Transport Netw ork

applicationSchema Water Transport Netw ork applicationSchema Cable Transport Netw ork

Figure 3 UML class diagram: Overview of the Transport Networks UML structure and dependencies The dependencies between the different Transport Networks application schemas are illustrated in Figure 3. All five of the Transport Networks (Road, Rail, Cable, Water and Air) application schemas depend on the Common Transport Elements application schema which defines a number of common transport classes. In turn, Common Transport Elements depends on the Generic Network Model on which it is based.

5.1 Basic notions

This section explains some of the basic notions used in the INSPIRE application schemas. These explanations are based on the GCM [DS-D2.5].

5.1.1 Placeholder and candidate types

This data specification may include types (typically spatial object types) that will be fully specified as part of an Annex II or III spatial data theme, but is already used as a value type of an attribute or association role of a type included in this data specification. Two kinds of such types are distinguished: A placeholder type acts as a placeholder for a spatial object type for which only a definition is specified (based on the requirements of the Annex I theme). It receives the stereotype placeholder.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 14

A candidate type already has a preliminary specification comprising the definition as well as attributes and associations to other types. It does not receive a specific stereotype. Both placeholder and candidate types are placed in the application schema package of the thematically related Annex II or III spatial data theme Their specifications will be revisited during the specification work of the Annex II or III theme. If the existing preliminary specification elements of such types fulfil the requirements of the spatial data themes of Annex II or II they are kept and, if necessary, are complemented with further attributes or association roles. If the existing preliminary specifications of a placeholder or candidate type do not fulfil the requirements of the spatial data theme of Annex II or III the placeholder or the candidate type will be moved into the application schema of the Annex I theme, and, if necessary, their specification will be completed. For the Annex II or III spatial data theme a new spatial object will be created. Placeholders and candidate types are listed in a separate subsection of the Feature Catalogue.

5.1.2 Voidable characteristics

If a characteristic of a spatial object is not present in the spatial data set, but may be present or applicable in the real world, the property shall receive this stereotype. If and only if a property receives this stereotype, the value of void may be used as a value of the property. A void value shall imply that no corresponding value is contained in the spatial data set maintained by the data provider or no corresponding value can be derived from existing values at reasonable costs, even though the characteristic may be present or applicable in the real world. It is possible to qualify a value of void in the data with a reason using the VoidValueReason type. The VoidValueReason type is a code list, which includes the following pre-defined values: Unpopulated: The characteristic is not part of the dataset maintained by the data provider. However, the characteristic may exist in the real world. For example when the elevation of the water body above the sea level has not been included in a dataset containing lake spatial objects, then the reason for a void value of this property would be Unpopulated. The characteristic receives this value for all objects in the spatial data set. Unknown: The correct value for the specific spatial object is not known to, and not computable by the data provider. However, a correct value may exist. For example when the elevation of the water body above the sea level of a certain lake has not been measured, then the reason for a void value of this property would be Unknown. This value is applied on an object-byobject basis in a spatial data set. NOTE It is expected that additional reasons will be identified in the future, in particular to support reasons / special values in coverage ranges. The voidable stereotype does not give any information on whether or not a characteristic exists in the real world. This is expressed using the multiplicity: If a characteristic may or may not exist in the real world, its minimum cardinality shall be defined as 0. For example, an if an Address may or may not have a house number, the multiplicity of the corresponding property shall be 0..1. If at least one value for a certain characteristic exists in the real world, the minimum cardinality shall be defined as 1. For example, if an Administrative Unit always has at least one name, the multiplicity of the corresponding property shall be 1..*. In both cases, the voidable stereotype can be applied. A value (the real value or void) only needs to be made available for properties that have a minimum cardinality of 1.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 15

5.1.3 Code lists and Enumerations

5.1.3.1 Style
All code lists and enumerations shall use the following modelling style: No initial value, but only the attribute name part, shall be used. The attribute name shall conform to the rules for attributes names, i.e. is a lowerCamelCase name. Exceptions are words that consist of all uppercase letters (acronyms).

5.1.3.2 Governance
Two types of code lists can be distinguished: code lists that shall be managed centrally in the INSPIRE code list register and only values from that register may be used, and code lists that may be extended by data providers. All code lists that are centrally managed shall receive the tagged value "codeList" with the preliminary value "urn:x-inspire:def:codeList:INSPIRE:<name of the class>".

5.1.4 Stereotypes
In the application schemas in this sections several stereotypes are used that have been defined as part of a UML profile for use in INSPIRE [INSPIRE DS-D2.5]. These are explained in Table 2 below. Table 2 Stereotypes (adapted from [INSPIRE DS-D2.5]) Stereotype applicationSchema featureType Type dataType Union enumeration codeList placeholder voidable lifeCycleInfo version Model element Package Class Class Class Class Class Class Class Attribute, association role Attribute, association role Association role Description An INSPIRE application schema according to ISO 19109 and the Generic Conceptual Model. A spatial object type. A conceptual, abstract type that is not a spatial object type. A structured data type without identity. A structured data type without identity where exactly one of the properties of the type is present in any instance. A fixed list of valid identifiers of named literal values. Attributes of an enumerated type may only take values from this list. A flexible enumeration that uses string values for expressing a list of potential values. A placeholder class (see definition in section 5.1.1). A voidable attribute or association role (see definition in section 5.1.1). If in an application schema a property is considered to be part of the life-cycle information of a spatial object type, the property shall receive this stereotype. If in an application schema an association role ends at a spatial object type, this stereotype denotes that the value of the property is meant to be a specific version of the spatial object, not the spatial object in general.

5.1.5 Constraints
NOTE In this version of the data specifications, constraints are only specified in natural language. The OCL expressions of the constraints will be added in a future version.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 16

5.2 Application schema Common Transport Elements

5.2.1 Description
5.2.1.1 Narrative description
The Common Transport Elements application schema covers elements that are shared by subthemes Road, Rail, Cable, Water and Air. These subthemes have been modelled as separate application schemas within the Transport Networks theme. Many of the common transport elements are specializations of common definitions for networks and network elements available in the GNM. Elements in networks are handled as nodes, links, aggregated links, areas and points. Cross-border connectivity (connections between networks across national and regional borders) is also included. It uses a mechanism provided by the GNM and inherited by the specific transport network classes. Using the same mechanism from the GNM, intermodal connectivity (connections between elements in networks which use a different mode of transport) may also be included. The Common Transport Elements application schema also defines a number of common transport property classes (as specializations of the generic Network Property class in the GNM). These classes are used to describe properties of transport network elements and they can apply to the whole of the network element they are associated with or - for linear features - be described using linear referencing. The primary aspects modelled for transport network elements are: Spatial. Geometric (point, line and surface (i.e. areas (topographic areas)) representation of various elements that are parts of a network. Typically, the network is handled as a network of connected linear elements (links) with optional points (nodes) at the ends of the lines (at junctions, road ends etc). Also, points (other than nodes) and areas with a function in a network may be represented in the dataset. Temporal. All elements in a network may have a temporal validity (i.e. description of when the network element exists in the real world) and also information on when data was entered, modified or deleted in the dataset. Thematic. Depending on subtheme, the specializations for nodes, links and areas can be further characterized through various types of attributes and/or links to common or subtheme-specific property types.

5.2.1.2 UML Overview

As illustrated by Figure 4, many of the important mechanisms that are used to properly describe a transport network are defined by the GNM, and inherited by components of the transport network application schemas. Although these classes and relationships only appear in the informative paragraphs about imported types in the Transport Networks specification, they are very important for a correct implementation of this specification. They include: The relationships between Nodes, Links, Link Sequences and Link Sets, Network Properties and the different ways of linking them to an element of a (transport) network, The mechanism for cross-border and intermodal connections, Grade separated crossings. NOTE: In Figure 4, only the most important relationships between the Common Transport Networks application schema and the GNM are shown. Not all classes are present in the diagram and most of the attributes are removed in the intrest of clarity. In the following paragraphs, the use of these mechanisms will be further explained.

INSPIRE TWG-TN

class Common Transport Elements Ov erv iew featureType TransportProperty

featureType TransportObject featureType TransportArea featureType TransportNetw ork

voidable + geographicalName: GeographicalName [0..1]

Generic Network Model (from GCM) featureType Network::NetworkArea + +element version 1 dataType Netw ork:: Netw orkReference geometry: GM_Surface + inspireId: Identifier [0..1] +elements 1..* featureType Network::NetworkElement 0..* +inNetwork voidable featureType Netw ork::Netw ork voidable + geographicalName: GeographicalName [0..*]

featureType TransportPoint

geometry: GM_Point

featureType Network::NetworkProperty + inspireId: Identifier [0..1] voidable + networkRef: NetworkReference [1..*]

featureType Network::LinkSet 1..*

featureType +link Network::GeneralisedLink

featureType Network::LinkSequence + link: DirectedLink [1..*] {ordered} +

featureType Network::Link

+spokeStart +startNode 0..* voidable 0..1 +

featureType Network::Node geometry: GM_Point

featureType MarkerPost dataType Netw ork::DirectedLink + direction: Sign 0..*

centrelineGeometry: GM_Curve 0..* 0..1 +spokeEnd +endNode voidable +link 1

+post 0..* voidable

+route voidable 1 featureType TransportLinkSet featureType TransportLinkSequence

featureType TransportLink

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 17

Figure 4 UML class diagram: Overview of the Transport Networks application schema and its relationships with the GNM
featureType TransportNode

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 18

5.2.1.3 Consistency between spatial data sets

As described in D2.6 A.18 there are three topic areas regarding consistency between spatial data sets, these are: a) Coherence between spatial objects of the same theme at different levels of detail b) Coherence between different spatial objects within a same area c) Coherence at state boundaries. [a] For Transport networks the specification incorporates two alternative forms of representation: Physical topographic area objects (usually surveyed to a high accuracy) Centreline representations (often an approximation of the centreline)

At any level of detail data integrity demands that these two forms need to be consistent with each other both positionally and logically. For example, where both exist, a road centreline will always fall within the limits of the corresponding road area object. Similarly, nodes in the road centreline representation will always fall inside the road area object that corresponds to the topographic junction where the node occurs. Requirement 4 Transport Networks centreline representations and nodes shall always be located within the extent of the area representation of the same object.

[b]

Both forms of representation will often be combined with other themes in a wide variety of applications. Again data integrity demands that these should be positionally consistent to ensure both a faithful representation of the real world and a professional appearance that will fill the user with confidence. For example buildings, rivers and forests with the transportation system.

Recommendation 2 The objects in the Transport Networks theme should be positionally consistent with spatial objects from other themes (e.g. with buildings and rivers, forestry extents)

[c]

It is essential that continuity of transport network information is preserved positionally, logically and semantically across state borders and where applicable also across regional borders within member states. This is vital to interoperable pan-European spatial information. The methods to support this are outlined in D2.6 Annex B.

The GNM provides a simple cross-referencing system to establish cross-border connections between Transport Networks. In practice, this is done by linking a transport network element in a data set on one side of the border and the connected or corresponding network element in a data set on the other side of the border to a Network Connection object which has been qualified as cross-border connected (when the linked network elements connect to each other) or as cross-border identical (when the linked network elements are representations in each data set of the same real world object). The Network Connection class is defined in the GNM.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 19

R ailwayNode IdE lement1=B E 37

R ailwayNode IdE lement1=DE 48

NetworkConnection Id N M ConnectionType cross-border identical cross-border connected BE-401 IdElement1 BE-37 DE-398 IdElement2 DE-48

R oadL ink IdE lement1=DE 398

R oadL ink IdE lement1=B E 401

Figure 5 Examples of cross-border connections between Transport Networks For Transport Networks the use of a Network Connection to establish cross-border connectivity is mandatory. Furthermore, it is recommended that the respective authorities seek to fully resolve the positional alignment of cross-border connected elements of Transport Networks in accordance to the rules for network connectivity outlined in section 10.2 (Ensuring Network Connectivity). Requirement 5 Connectivity between Transport Networks across state borders and where applicable also across regional borders (and datasets) within member states shall be established and maintained by the respective authorities, using the crossborder connectivity mechanisms provided by the GNM.

Recommendation 3 In considering reconciliation across borders the respective authorities should seek to fully resolve the positional alignment that minimises positional deficiencies that would require repeated manual interval in updates or detract from the use of the data in applications.

5.2.1.4 Identifier management

As is required by the GCM, all spatial objects must have a unique identifier. This must be persistent and will usually be supported by a defined lifecycle to ensure that users understand the conditions that the identifier may be created, modified (in terms of its relationship with the spatial object) and deleted. The unique object identifier will be modelled on the form described in D2.5 9.8.2 and 9.7 and D2.7 Chapter 7 where a country code and namespace is applied as a prefix to the existing local identifier used by the authority responsible for the data. This will both ensure that the identifier is: Unique in the European spatial data infrastructure The object is traceable in that infrastructure

All spatial objects in the Transport networks will have a unique object identifier this includes those spatial objects that contain geometry and those that may not (e.g. Associated objects, AggregatedLink objects and those defined by linear referencing etc).

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 20

Requirement 6

All spatial objects in the Transport Networks themes shall have a persistent unique identifier as defined in the INSPIRE documents D2.5 and D2.7.

NOTE: All spatial object classes in the Transport Networks application schemas inherit their unique identifier from the GNM where it is defined with a cardinality of 0..1. In the transport networks classes the unique identifier is mandatory for all objects, which corresponds to a cardinality of 1. Ideally all objects should be supported by a defined lifecycle model and a method of versioning (see D2.5 9.7) that assists the user in distinguishing between current objects and previous versions. Recommendation 4 The spatial object unique identifier should be supported by a documented lifecycle to provide users with a defined behaviour pattern as conditions which affect the object change over time. Recommendation 5 The spatial object unique identifier should be supported by a defined form of versioning to ensure that users refer to the correct version in applications.

5.2.1.5 Modelling of object references

The INSPIRE Directive promotes the reuse of information. Object referencing is designed to support that aim whereby an existing object e.g. a transport link is used by several other objects, which may be collected by different organisations (e.g. surface condition survey, speed limit/restrictions etc). Such objects would normally inherit geometry from underlying referenced objects. Data Association As described in D2.5 Chapter 13 an associated object would reference the base network (data association). The link is physically achieved by cross referencing one object with another using the unique identifiers provided (and ideally the version information), This is common practice in several existing transport networks and the Transport networks specification supports this approach. Recommendation 6 All associated spatial objects in the Transport Networks theme should use object referencing to an existing set of transport links rather than duplicate the geometry. Recommendation 7 All centreline spatial objects in the Transport Networks theme should use object referencing to the topographic area objects to support both data sharing of application data and the support synchronisation of the two representations over time.

Transport properties and linear referencing Many of the thematic properties of the Transport Networks objects are defined as Transport Properties. All Transport Property classes are subtypes of the GNM Network Property class. As such, they inherit the mechanisms that are defined in the GNM to link them to transport network elements (such as Transport links, Transport Link Sequences, Transport Link Sets, Transport Nodes and Transport Areas) using object referencing. Transport Properties also offer a way the easily extend the Transport Networks specification. For different applications, additional Transport Property classes can be defined and linked to the appropriate Network Elements.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 21

A Transport Property can be linked to an entire transport element or, when the target is a Transport Link or more typically a Transport Link Sequence, to part of it using linear referencing. Linear referencing is included in the GNM with caveats until ISO 19148 is formally adopted (see also Chapter 10.2) and a simple approach is included until the standard is more widely used. This can be of value in many applications where a consistent approach to data capture and referencing is absent today for example speed limit extents as shown in Figure 6 below.

0km 1.2km 7.5km

NetworkL inkS equence

L ine ar N e tw re fe re nc ork L ink S e from s t e qu e a nc e rt of

70
P roperty(egs peedlimit of70km/h):begins at 1.2kmfromthes tartofthe linksequence,ends at 4.5km

T rans portNetworkNode T rans portNetworkL ink

Figure 6 example of linear referencing to locate the start and end of a speed restriction zone. Recommendation 8 Linear referencing should be adopted to support the location of changes in condition or other phenomena along a link or link sequence where there is no requirement to disturb the link and node structure Linear referencing is used to position phenomena a long a linear object, using a distance from the beginning of the linear object. Some systems disconnect the linear reference from the geometry of the linear object in the dataset, adding a calibrated linear coordinate to the object, corresponding to the distance measured along the real world object or interpolated between fixed marker posts (which themselves may not be exactly located at the distance they indicate). For Transport Networks, all supplied linear references will use the distance along the geometry of the linear object in the database. Requirement 7 When linear referencing is used in Transport Networks data, the position of referenced properties on links and link sequences shall be expressed as distances measured along the supplied geometry of the underlying link object(s).

Intermodal connections

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 22

The Transport Networks specification inherits a simple approach to intermodal connections from the GNM that has been adopted in the absence of any commonly adopted standards. Spatial objects within the Transport Networks specification can be linked (cross-referenced) to support connectivity between any two transport networks that use different modes of transport. This is to support journey planning, navigation etc. In practice, intermodal connections can be established by linking two transport network elements (from different transport networks which use a different mode of transport) to a Network Connection object which is qualified as an intermodal connection. The Network Connection class is defined in the GNM. Several types of transport network elements, including links, link sequences, link sets, areas and nodes can participate in intermodal connections. The use of nodes is recommended since this allows for a more accurate positioning of the connection in the two networks. Figure 7 demonstrates the concept of the intermodal connection. In this example, a node in a road transport network is connected to a node in the railway network. These nodes may, but do not have to, share the same location.

NetworkConnection Id ConnectionType IdElement1 IdElement2

R oadNode IdE lement1=13

intermodal

13

27

R oad R ailway

R ailwayS tationA rea R ailwayS tationNode IdE lement12=27

Figure 7 The intermodal connection linking two different Transport networks themes Rail and Road Requirement 8 An intermodal connection shall always reference two elements which belong to different networks.

Recommendation 9 An intermodal connection should be established between transport nodes.

5.2.1.6 Geometry representation

There are three types of geometry in this specification: a) (Topographic) Area objects in Transport Networks b) Centreline objects in Transport Networks

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 23

c) Point objects in Transport Networks Types (a) and (b) may be alternative representations of the same real world phenomena about which the user can associate their own information (objects) See Annex B1 for more background. Type (c) is, apart from network nodes, only included in the specification for marker posts. However users may wish to collect such data and associate it with the network (e.g. the location of network infrastructure components e.g. traffic lights, lighting columns, beacons, navigation lights etc). The geometric basis of a transport network consists of a number of connected linear elements (Transport Links) with optional point elements (Transport Nodes) at the ends of the lines (at junctions, terminals, etc). Section 10.2 (Ensuring Network Connectivity) contains the necessary rules for ensuring connectivity within Transport Networks. Connections between Transport Networks are established by using the cross-border and intermodal connection mechanisms present in the GNM and further explained in sections 5.2.1.3 (Consistency between spatial data sets) and 5.2.1.5 (Modelling of object references) respectively. Requirement 9 Transport links shall intersect wherever a connection exists between the real world phenomena they represent. No intersections shall be created at crossing network elements when it is not possible to pass from one element to another.

NOTE: Grade separated crossings can be modeled using the GradeSeparatedCrossing class from the GNM. This class enables the ordered linking of two (Transport) Links. In this ordered relationship, the first Link is always the lower of the two. Recommendation 10 In Transport Networks data, Transport Nodes should be present wherever Transport Links connect or end If a Transport Networks data set contains nodes, they can only occur where a connection exists between two Transport Links or where a Transport Link ends (end or dangle node). Nodes shall not occur where two links cross but not intersect, for instance at grade separated crossings. Requirement 10 In a Transport Networks data set which contains nodes, these nodes shall only be present where Transport Links connect or end.

The individual Transport Links can be combined to form Transport Link Sequences, using the mechanism provided by the GNM. As an ordered sequence of Transport Links, Transport Link Sequences have no geometry of their own. Their position is defined by the composing Transport Links. Transport Link Sequences and/or Transport Links can be further combined to form Transport Link Sets. This way, looped and forked elements of a transport network can be represented. Like Transport Link Sequences, Transport Link Sets have no geometry of their own.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 24

Individual links and link sequences form link set (eg motorway with exits)

A1

TransportLinkSet

Individual links are used to build link sequences (eg for linear referencing of transport properties

e renc r refe k Linea tart of lin s from nce e sequ

k sequence operty on lin Transport pr it) (eg speed lim

TransportLinkSequence

Basic network of transport links and (optional) nodes TransportNode

TransportLink

Figure 8 Example of the use of Link, Node, Link Sequence and Link Set Levels of detail: The specification addresses the highest resolution of data capture in Transport Networks and is also applicable to any derived lower resolution levels of detail where the number of coordinates is reduced and the geometry simplified to support viewing and reporting at regional, national and European levels. See also Chapter D10.4 and Annex B.1 This specification cannot advise on the form of representation at the highest resolution nor the accuracy since this will be driven by member state needs. Ideally derived lower resolution datasets will use the approach outlined in D2.6 A.19 where all the objects are related from lowest to highest resolution and any user information collected about the network can be simply aggregated at the lower resolution level or disaggregated as the user increases the resolution. Recommendation 11 All Transport Networks spatial objects should be provided at the source resolution (and accuracy) where possible. Recommendation 12 Lower order resolutions should be derived from the highest order representation of the transport network, and any user information captured once and referenced to each geometrical representation Requirement 11 The value domain of spatial properties used in this specification is restricted to the Simple Feature spatial schema as defined by [OGC 06-103r3] (Implementation Specification for Geographic Information Simple feature access Part 1: Common Architecture v1.2.0).

NOTE The specification restricts the spatial schema to 0-, 1-, 2-, and 2.5-dimensional geometries where all curve interpolations are linear. NOTE The topological relations of two spatial objects based on their specific geometry and topology properties can in principle be investigated by invoking the operations of the types defined in ISO 19107 (or the methods specified in OGC 06-103r3).

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 25

5.2.1.7 Temporality representation

The application schemas use the derived attributes "beginLifespanObject" and "endLifespanObject" to record the lifespan of a spatial object. The attributes "beginLifespanVersion" specifies the date and time at which this version of the spatial object was inserted or changed in the spatial data set. The attribute "endLifespanVersion" specifies the date and time at which this version of the spatial object was superseded or retired in the spatial data set. NOTE 1 The attributes specify the beginning of the lifespan of the version in the spatial data set itself, which is different from the temporal characteristics of the real-world phenomenon described by the spatial object. This lifespan information, if available, supports mainly two requirements: First, knowledge about the spatial data set content at a specific time; second, knowledge about changes to a data set in a specific time frame. The lifespan information should be as detailed as in the data set (i.e., if the lifespan information in the data set includes seconds, the seconds should be represented in data published in INSPIRE) and include time zone information. NOTE 2 Changes to the attribute "endLifespanVersion" does not trigger a change in the attribute "beginLifespanVersion". Recommendation 13 If life-cycle information is not maintained as part of the spatial data set, all spatial objects belonging to this data set should provide a void value with a reason of "unpopulated".

The attribute validFrom specifies the date and time at which the real word phenomena that are represented by the spatial objects in a spatial data set started to exist in the real world. The attribute validTo specifies from which date and time these phenomena no longer exist. Recommendation 14 If information about the actual start and end of the existence of transport network elements is not maintained as part of the spatial data set, all spatial objects belonging to this data set should provide a void value with a reason of "unknown".

5.2.2 Feature catalogue

Table 3 Feature catalogue metadata Feature catalogue name Scope Version number Version date Definition source INSPIRE feature catalogue Common Transport Elements Common Transport Elements 3.0.1 2009-10-02 INSPIRE data specification Common Transport Elements Table 4 Types defined in the feature catalogue Type AccessRestriction ConditionOfFacility MaintenanceAuthority MarkerPost OwnerAuthority Package Common Transport Elements Common Transport Elements Common Transport Elements Common Transport Elements Common Transport Elements Stereotypes featureType featureType featureType featureType featureType Section 5.2.2.1.1 5.2.2.1.2 5.2.2.1.3 5.2.2.1.4 5.2.2.1.5

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 26

Type RestrictionForVehicles RestrictionTypeValue TrafficFlowDirection TransportArea TransportLink TransportLinkSequence TransportLinkSet TransportNetwork TransportNode TransportObject TransportPoint TransportProperty TransportTypeValue VerticalPosition AccessRestrictionValue

Package Common Transport Elements Common Transport Elements Common Transport Elements Common Transport Elements Common Transport Elements Common Transport Elements Common Transport Elements Common Transport Elements Common Transport Elements Common Transport Elements Common Transport Elements Common Transport Elements Common Transport Elements Common Transport Elements Common Transport Elements

Stereotypes Section featureType 5.2.2.1.6 codeList 5.2.2.2.2 featureType 5.2.2.1.7 featureType 5.2.2.1.8 featureType 5.2.2.1.9 featureType 5.2.2.1.10 featureType 5.2.2.1.11 featureType 5.2.2.1.12 featureType 5.2.2.1.13 featureType 5.2.2.1.14 featureType 5.2.2.1.14 featureType 5.2.2.1.16 enumeration 5.2.2.2.1 featureType 5.2.2.1.17 codeList 5.2.2.2.3

INSPIRE TWG-TN

class Common Transport Elements: Spatial obj ect types - Links, Nodes and Areas Generic Network Model (form GCM) featureType Network::NetworkElement + lifeCycleInfo, voidable + beginLifespanVersion: DateTime + endLifespanVersion: DateTime [0..1] + inspireId: Identifier [0..1] featureType Network::NetworkArea geometry: GM_Surface

featureType Network::LinkSet +link 1..*

featureType Network::GeneralisedLink

featureType Netw ork::GradeSeparatedCrossing

+element featureType Network::LinkSequence + link: DirectedLink [1..*] {ordered} + + featureType Network::Link

2..* {ordered} featureType Network::Node geometry: GM_Point

+spokeStart +startNode voidable 0..* 0..1 +spokeEnd +endNode centrelineGeometry: GM_Curve + voidable fictitious: Boolean = false 0..* 0..1

featureType TransportLinkSet voidable + validFrom: DateTime + validTo: DateTime [0..1] constraints {All components belong to same transport network} {All objects have inspireId} constraints {All objects have inspireId} voidable + validFrom: DateTime + validTo: DateTime [0..1]

featureType TransportLinkSequence

featureType TransportLink

featureType TransportNode voidable + validFrom: DateTime + validTo: DateTime [0..1] constraints {All objects have inspireId}

featureType TransportArea voidable + validFrom: DateTime + validTo: DateTime [0..1] constraints {All objects have inspireId}

voidable + validFrom: DateTime + validTo: DateTime [0..1]

constraints {All components belong to same transport network} {All objects have inspireId}

Figure 9 UML class diagram: Spatial object types Transport Link, Node and Area
featureType TransportObject voidable + geographicalName: GeographicalName [0..1]

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 27

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 28

class Common Transport Elements: Spatial obj ect types - Transport Points Generic Network Model (from GCM) featureType Network::NetworkElement + inspireId: Identifier [0..1]

featureType Network::LinkSet

lifeCycleInfo, voidable + beginLifespanVersion: DateTime + endLifespanVersion: DateTime [0..1]

featureType TransportObject voidable + geographicalName: GeographicalName [0..1]

featureType TransportPoint + geometry: GM_Point

voidable + validFrom: DateTime + validT o: DateTime [0..1] constraints {All objects have inspireId}

featureType TransportLinkSet featureType MarkerPost + location: Distance +post voidable 0..* +route voidable voidable + validFrom: DateTime + validTo: DateTime [0..1] 1 constraints {All components belong to same transport network} {All objects have inspireId}

Figure 10 UML class diagram: Spatial object types Transport Point

class Common Transport Elements: Spatial obj ect types - Netw ork Connections Generic Network M odel (from GCM ) featureT ype Network::NetworkElement + inspireId: Identifier [0..1] +inNetwork +elem ents voidable 0..* featureT ype Netw ork::Netw ork

lifeCycleInfo, voidable + beginLifespanVersion: DateT im e + endLifespanVersion: DateT im e [0..1]

1..* voidable + geographicalNam e: GeographicalNam e [0..*]

+elem ent

2..* {ordered}

featureT ype Netw ork::Netw orkConnection voidable + type: ConnectionT ypeValue constraints {Elem ents in different networks}

codeList Netw ork:: ConnectionTypeValue + + + crossBorderConnected crossBorderIdentical interm odal

featureT ype TransportNetw ork + + inspireId: Identifier typeOfT ransport: T ransportT ypeValue

Figure 11 UML class diagram: Spatial object types Transport Network

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 29

class Common Transport Elements: Spatial obj ect types - Transport Properties Generic Network M odel (from GCM ) dataT ype Netw ork:: Netw orkReference

featureT ype Network::NetworkProperty + inspireId: Identifier [0..1] dataT ype Netw ork::LinkReference voidable + applicableDirection: LinkDirectionValue constraints {elem ent.oclIsKindOf(GeneralisedLink)}

voidable, lifeCycleInfo + beginLifespanVersion: DateT im e + endLifespanVersion: DateT im e [0..1] voidable + networkRef: NetworkReference [1..*]

dataT ype Netw ork::SimplePointReference + atPosition: Length

dataT ype Netw ork::SimpleLinearReference + + from Position: Length toPosition: Length

voidable + offset: Length [0..1]

voidable + offset: Length [0..1]

featureT ype TransportProperty voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All objects have inspireId}

featureT ype AccessRestriction + restriction: AccessRestrictionValue

featureT ype RestrictionForVehicles + + m easure: M easure restrictionT ype: RestrictionT ypeValue

featureT ype M aintenanceAuthority + authority: CI_Citation

featureT ype ConditionOfFacility + currentStatus: ConditionOfFacilityValue

featureT ype Ow nerAuthority + authority: CI_Citation featureT ype TrafficFlow Direction + featureT ype VerticalPosition + verticalPosition: VerticalPositionValue direction: LinkDirectionValue

constraints {Applies to Link and LinkSequence only}

Figure 12 UML class diagram: Spatial object types Transport Properties

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 30

5.2.2.1 Spatial object types

5.2.2.1.1 AccessRestriction AccessRestriction Subtype of: Definition: Status: Stereotypes: TransportProperty A restriction on the access to a transport element. Proposed featureType

Attribute: restriction Value type: AccessRestrictionValue Definition: Nature of the access restriction. Multiplicity: 1 5.2.2.1.2 ConditionOfFacility ConditionOfFacility Subtype of: Definition: Status: Stereotypes: TransportProperty State of a transport network element with regards to its completion and use. Proposed featureType

Attribute: currentStatus Value type: ConditionOfFacilityValue Definition: Current status value of a transport network element with regards to its completion and use. Multiplicity: 1 5.2.2.1.3 MaintenanceAuthority MaintenanceAuthority Subtype of: Definition: Status: Stereotypes: TransportProperty The authority responsible for maintenance of the transport element. Proposed featureType

Attribute: authority Value type: CI_Citation Definition: Identification of the maintenance authority. Multiplicity: 1 5.2.2.1.4 MarkerPost MarkerPost Subtype of: Definition: Description: Status: Stereotypes: TransportPoint Reference marker placed along a route in a transport network, mostly at regular intervals, indicating the distance from the beginning of the route, or some other reference point, to the point where the marker is located. EXAMPLE Examples of routes along which marker posts can be found are roads, railway lines and navigable waterways. Proposed featureType

Attribute: location Value type: Distance Definition: Distance from the beginning of the route, or some other reference point, to the point where a marker post is located. Multiplicity: 1 Association role: route Value type: TransportLinkSet Definition: Route in a transport network along which the marker post is placed.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 31

MarkerPost Multiplicity: Stereotypes: 1 voidable

5.2.2.1.5 OwnerAuthority OwnerAuthority Subtype of: Definition: Status: Stereotypes: TransportProperty The authority owning the transport element. Proposed featureType

Attribute: authority Value type: CI_Citation Definition: Identification of the owning authority. Multiplicity: 1 5.2.2.1.6 RestrictionForVehicles RestrictionForVehicles Subtype of: Definition: Status: Stereotypes: Attribute: measure Value type: Definition: Description: Multiplicity: TransportProperty Restriction on vehicles on a transport element. Proposed featureType Measure The measure for the restriction . SOURCE [Euroroads]. 1

Attribute: restrictionType Value type: RestrictionTypeValue Definition: The type of restriction . Description: SOURCE [Euroroads]. Multiplicity: 1 5.2.2.1.7 TrafficFlowDirection TrafficFlowDirection Subtype of: Definition: Status: Stereotypes: TransportProperty Indicates the direction of the flow of traffic in relation to the direction of the transport link vector. Proposed featureType

Attribute: direction Value type: LinkDirectionValue Definition: Indicates the direction of the flow of traffic. Multiplicity: 1 Constraint: Applies to Link and LinkSequence only Natural This property can only be associated with a spatial object of the type Link or language: LinkSequence. OCL: 5.2.2.1.8 TransportArea TransportArea (abstract) Subtype of: Definition: Status: NetworkArea, TransportObject Surface that represents the spatial extent of an element of a transport network. Proposed

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 32

TransportArea (abstract) Stereotypes: featureType Attribute: validFrom Value type: DateTime Definition: The time when the transport area started to exist in the real world. Multiplicity: 1 Stereotypes: voidable Attribute: validTo Value type: Definition: Multiplicity: Stereotypes: DateTime The time from which the transport area no longer exists in the real world. 0..1 voidable

Constraint: All objects have inspireId Natural All transport areas have an external object identifier. language: OCL: inv:inspireId->notEmpty() 5.2.2.1.9 TransportLink TransportLink (abstract) Subtype of: Definition: Status: Stereotypes: Link, TransportObject A linear spatial object that describes the geometry and connectivity of a transport network between two points in the network. Proposed featureType

Attribute: validFrom Value type: DateTime Definition: The time when the transport link started to exist in the real world. Multiplicity: 1 Stereotypes: voidable Attribute: validTo Value type: Definition: Multiplicity: Stereotypes: DateTime The time from which the transport link no longer exists in the real world. 0..1 voidable

Constraint: All objects have inspireId Natural All transport links have an external object identifier. language: OCL: inv:inspireId->notEmpty() 5.2.2.1.10 TransportLinkSequence TransportLinkSequence (abstract) Subtype of: Definition: LinkSequence, TransportObject A linear spatial object, composed of an ordered collection of transport links, which represents a continuous path in the transport network without any branches. The element has a defined beginning and end and every position on the transport link sequence is identifiable with one single parameter such as length. It describes an element of the transport network, characterized by one or more thematical identifiers and/or properties. Proposed featureType

Status: Stereotypes:

Attribute: validFrom Value type: DateTime Definition: The time when the transport link sequence started to exist in the real world.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 33

TransportLinkSequence (abstract) Multiplicity: Stereotypes: Attribute: validTo Value type: Definition: Multiplicity: Stereotypes: 1 voidable DateTime The time from which the transport link sequence no longer exists in the real world. 0..1 voidable

Constraint: All components belong to same transport network Natural A transport link sequence must be composed of transport links that all belong to language: the same transport network. OCL: Constraint: All objects have inspireId Natural All transport link sequences have an external object identifier. language: OCL: inv:inspireId->notEmpty() 5.2.2.1.11 TransportLinkSet TransportLinkSet (abstract) Subtype of: Definition: Description: LinkSet, TransportObject A collection of transport link sequences and or individual transport links that has a specific function or siginificance in a transport network. NOTE This spatial object type supports the aggregation of links to form objects with branches, loops, parallel sequences of links, gaps, etc. EXAMPLE A dual carriageway road, as a collection of the two link sequences that represent each carriageway. Proposed featureType

Status: Stereotypes:

Attribute: validFrom Value type: DateTime Definition: The time when the transport link set started to exist in the real world. Multiplicity: 1 Stereotypes: voidable Attribute: validTo Value type: Definition: Multiplicity: Stereotypes: DateTime The time from which the transport link set no longer exists in the real world. 0..1 voidable

Association role: post Value type: MarkerPost Definition: Marker post along a route in a transport network. Multiplicity: 0..* Stereotypes: voidable Constraint: All components belong to same transport network A transport link set must be composed of transport links and or transport link Natural sequences that all belong to the same transport network. language: OCL: Constraint: All objects have inspireId Natural All transport link sets have an external object identifier. language:

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 34

TransportLinkSet (abstract) OCL: inv:inspireId->notEmpty()

5.2.2.1.12 TransportNetwork TransportNetwork Subtype of: Definition: Description: Network Collection of network elements that belong to a single mode of transport. NOTE Road, rail, water and air transport are always considered separate transport modes. Even within these four categories, multiple modes of transport can be defined, based on infrastructure, vehicle types, propulsion system, operation and/or other defining characteristics. EXAMPLE All road transport can be considered one mode of transport for some applications. For other applications, it might be necessary to distinguish between different public road transport networks. Within water transport, marine and inland water transport can be considered to be separate modes of transport for some applications, as they use different types of ships. Proposed featureType

Status: Stereotypes:

Attribute: inspireId Value type: Identifier Definition: External object identifier of the transport network. Multiplicity: 1 Attribute: typeOfTransport Value type: TransportTypeValue Definition: Type of transport network, based on the type of infrastructure the network uses. Multiplicity: 1 5.2.2.1.13 TransportNode TransportNode (abstract) Subtype of: Definition: Description: Status: Stereotypes: Node, TransportObject A point spatial object which is used for connectivity. Nodes are found at either end of the TransportLink. Proposed featureType

Attribute: validFrom Value type: DateTime Definition: The time when the transport node started to exist in the real world. Multiplicity: 1 Stereotypes: voidable Attribute: validTo Value type: Definition: Multiplicity: Stereotypes: DateTime The time from which the transport node no longer exists in the real world. 0..1 voidable

Constraint: All objects have inspireId Natural All transport nodes have an external object identifier. language: OCL: inv:inspireId->notEmpty() 5.2.2.1.14 TransportObject TransportObject (abstract) Definition: An identity base for transport network objects in the real world.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 35

TransportObject (abstract) Description: Status: Stereotypes: NOTE Derived 'views' of real-world transport objects are represented through specialisations in other application schemas; all representations of the same real-world object share a common geographic name. Proposed featureType

Attribute: geographicalName Value type: GeographicalName Definition: A geographical name that is used to identify the transport network object in the real world. It provides a 'key' for implicitly associating different representations of the object. Multiplicity: 0..1 Stereotypes: voidable 5.2.2.1.15 TransportPoint TransportPoint (abstract) Subtype of: Definition: Status: Stereotypes: NetworkElement, TransportObject A point spatial object - which is not a node - that represents the position of an element of a transport network. Proposed featureType

Attribute: geometry Value type: GM_Point Definition: The location of the transport point. Multiplicity: 1 Attribute: validFrom Value type: DateTime Definition: The time when the transport point started to exist in the real world. Multiplicity: 1 Stereotypes: voidable Attribute: validTo Value type: Definition: Multiplicity: Stereotypes: DateTime The time from which the transport point no longer exists in the real world. 0..1 voidable

Constraint: All objects have inspireId Natural All transport points have an external object identfier. language: OCL: inv:inspireId->notEmpty() 5.2.2.1.16 TransportProperty TransportProperty (abstract) Subtype of: Definition: Status: Stereotypes: NetworkProperty A reference to a property that falls upon the network. This property can apply to the whole of the network element it is associated with or - for linear spatial objects - be described using linear referencing. Proposed featureType

Attribute: validFrom Value type: DateTime Definition: The time when the transport property started to exist in the real world. Multiplicity: 1 Stereotypes: voidable

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 36

TransportProperty (abstract) Attribute: validTo Value type: DateTime Definition: The time from which the transport property no longer exists in the real world. Multiplicity: 0..1 Stereotypes: voidable Constraint: All objects have inspireId Natural All transport properties have an external object identifier. language: OCL: inv:inspireId->notEmpty() 5.2.2.1.17 VerticalPosition VerticalPosition Subtype of: Definition: Status: Stereotypes: TransportProperty Vertical level relative to other transport network elements. Proposed featureType

Attribute: verticalPosition Value type: VerticalPositionValue Definition: Relative vertical position of the transport element. Multiplicity: 1

5.2.2.2 Enumerations and code lists

class Common Transport Elements: Enumerations and Code Lists codeList AccessRestrictionValue + + + + + + forbiddenLegally physicallyIm possible private publicAccess seasonal toll + + +

codeList Netw ork::LinkDirectionValue bothDirections inDirection inOppositeDirection

codeList Base Types:: ConditionOfFacilityValue + + + + disused functional projected underConstruction enum eration TransportTypeValue air cable rail road water

enum eration Base Types:: VerticalPositionValue onGroundSurface suspendedOrElevated underground

codeList RestrictionTypeValue + + + + + + + m axim um DoubleAxleWeight m axim um Height m axim um Length m axim um SingleAxleWeight m axim um T otalWeight m axim um T ripleAxleWeight m axim um Width

Figure 13 UML class diagram: Enumerations and code lists

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 37

5.2.2.2.1 TransportTypeValue TransportTypeValue Definition: Status: Stereotypes: Value: air Definition: Value: cable Definition: Value: rail Definition: Value: road Definition: Value: water Definition: Possible types on transport networks. Proposed enumeration The transport network consists of transport by air. The transport network consists of transport by cable. The transport network consists of transport by rail. The transport network consists of transport by road. The transport network consists of transport by water.

5.2.2.2.2 RestrictionTypeValue RestrictionTypeValue Definition: Status: Stereotypes: Governance: Possible restrictions on vehicles that can access a transport element. Proposed codeList Centrally managed in INSPIRE code list register. URN: inspire:def:codeList:INSPIRE:RestrictionTypeValues

urn:x-

Value: maximumDoubleAxleWeight Definition: The maximum weight per double axle of a vehicle allowed at a transport element. Description: SOURCE Adapted from [Euroroads]. NOTE This value applies to wheeled vehicles only. Value: maximumHeight Definition: The maximum height of a vehicle which can pass under another object . Description: SOURCE [Euroroads]. Value: maximumLength Definition: The maximum length of a vehicle allowed at a transport element. Description: SOURCE Adapted from [Euroroads]. Value: maximumSingleAxleWeight Definition: The maximum weight per single axle of a vehicle allowed at a transport element. Description: SOURCE Adapted from [Euroroads]. NOTE This value applies to wheeled vehicles only. Value: maximumTotalWeight Definition: The maximum total weight of a vehicle allowed at a transport element. Description: SOURCE Adapted from [Euroroads]. Value: maximumTripleAxleWeight Definition: The maximum weight per triple axle of a vehicle allowed at a transport element. Description: SOURCE Adapted from [Euroroads]. NOTE This value applies to wheeled vehicles only. Value: maximumWidth Definition: The maximum width of a vehicle allowed on a transport element. Description: SOURCE Adapted from [Euroroads].

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 38

5.2.2.2.3 AccessRestrictionValue AccessRestrictionValue Definition: Status: Stereotypes: Governance: Types of access restrictions for a transport element. Proposed codeList Centrally managed in INSPIRE code list register. inspire:def:codeList:INSPIRE:AccessRestrictionValues

URN:

urn:x-

Value: forbiddenLegally Definition: Access to the transport element is forbidden by law. Value: physicallyImpossible Access to the transport element is physically impossible due to the presence of Definition: barriers or other physical obstacles. Value: private Definition: Access to the transport element is restricted because it is privately owned.

Value: publicAccess Definition: The transport element is open to public access. Value: seasonal Definition: Value: toll Definition: Access to the transport element depends on the season. Access to the transport element is subject to toll.

5.2.2.3 Imported types (informative)

This section lists definitions for feature types, data types and enumerations and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references. 5.2.2.3.1 GeographicalName GeographicalName Package: Definition: Geographical Names [see DS-D2.8.I.3] Proper noun applied to a real world entity.

5.2.2.3.2 LinkSequence LinkSequence (abstract) Package: Definition: Description: Network [see DS-D2.5] A network element which represents a continuous path in the network without any branches. The element has a defined beginning and end and every position on the link sequence is identifiable with one single parameter such as length. EXAMPLE A link sequence may represent a route.

5.2.2.3.3 NetworkArea NetworkArea (abstract) Package: Definition: Network [see DS-D2.5] A 2-dimensional element in a network.

5.2.2.3.4 NetworkProperty NetworkProperty (abstract) Package: Definition: Network [see DS-D2.5] Abstract base type representing phenomena located at or along a network element. This base type provides general properties to associate the networkrelated phenomena (network properties) with the network elements.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 39

NetworkProperty (abstract) Description: In the simplest case (NetworkReference), the network property applies to the whole network element. In the case of a Link, the spatial reference may be restricted to part of the Link by using a linear reference. ISO/TC 211 is currently in the early stages of developing a standard for Linear Referencing (ISO 19148). A simple mechanism to express linear references is provided in this version of the network model; it is expected that the model will be extended once ISO 19148 is stable. The current simple model requires for all linear references two expressions representing a distance from the start of the Link along its curve geometry. The network property applies to the part of the Link between fromPosition and toPosition.

5.2.2.3.5 NetworkElement NetworkElement (abstract) Package: Definition: 5.2.2.3.6 Link Link (abstract) Package: Definition: Network [see DS-D2.5] Curvilinear network element that connects two positions and represents a homogeneous path in the network. The connected positions may be represented as nodes. Network [see DS-D2.5] Abstract base type representing an element in a network. Every element in a network provides some function that is of interest in the network.

5.2.2.3.7 LinkSet LinkSet (abstract) Package: Definition: Description: Network [see DS-D2.5] A collection of link sequences and/or individual links that has a specific function or significance in a network. NOTE This spatial object type supports the aggregation of links to form objects with branches, loops, parallel sequences of links, gaps, etc. EXAMPLE A dual carriageway road, as a collection of the two link sequences that represent each carriageway. 5.2.2.3.8 Network Network Network [see DS-D2.5] A network is a collection of network elements. The reason for collecting certain elements in a certain network may vary (e.g. connected elements for the same mode of transport)

Package: Definition: Description: 5.2.2.3.9 Node Node (abstract) Package: Definition: Description:

Network [see DS-D2.5] Represents a significant position in the network that always occurs at the beginning or the end of a link. NOTE if a topological representation of the network is used the road node is either a topological connection between two or more links or the termination of a ink. If a geometric representation of the network is used road nodes are represented by points or alternatively another geometric shape. [EuroRoadS]

5.2.2.3.10 Identifier Identifier Package: Base Types [see DS-D2.5]

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 40

Identifier Definition: Description: Unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object. NOTE1 External object identifiers are distinct from thematic object identifiers. NOTE 2 The voidable version identifier attribute is not part of the unique identifier of a spatial object and may be used to distinguish two versions of the same spatial object. NOTE 3 The unique identifier will not change during the life-time of a spatial object. 5.2.2.3.11 VerticalPositionValue VerticalPositionValue Package: Definition: Base Types [see DS-D2.5] The relative vertical position of a spatial object.

5.2.2.3.12 LinkDirectionValue LinkDirectionValue Package: Definition: Network [see DS-D2.5] List of values for directions relative to a link

5.2.2.3.13 ConditionOfFacilityValue ConditionOfFacilityValue Package: Definition: Base Types [see DS-D2.5] The status of a facility with regards to its completion and use.

5.3 Application schema Road Transport Networks

5.3.1 Description
5.3.1.1 Narrative description
The Road Transport Networks application schema (Roads Schema) employs a link and node structure to represent a road system used for the transportation of vehicles in the form of a linear network. The Roads Schema inherits classes from the Common Transport Schema and also creates its own classes to describe properties of the road network such as Ownership and traffic direction that can apply to whole sections of the network element or subsections that can be described using linear referencing. The primary aspects modelled for road network elements are: Spatial. Geometric (point, line and area (topographic)) representation of various elements that are parts of a network. Typically, the network is handled as a network of connected linear elements (links) with points (nodes) at the ends of the lines (at junctions, road ends etc). Also real objects with a function in a network may be represented in the dataset. Network connectivity within the roads network is essential but between elements in the other networks is an optional spatial aspect. Temporal. All elements in a network may have a temporal validity (i.e. description of when the network element exists in the real world) and also optional information on when data was entered, modified or deleted in the dataset. Thematic. The road schema can be thematically displayed via several of the attributes defined within the specification such as ownerAuthority or speedLimits.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 41

5.3.1.2 UML Overview

class Road Transport Netw ork Ov erv iew featureT ype RoadServ iceArea featureT ype RoadArea

Area featureT ype Common Transport Elements:: TransportArea featureT ype VehicleTrafficArea

LinkSet featureT ype Common Transport Elements:: TransportLinkSet

LinkSequence featureT ype Common Transport Elements:: TransportLinkSequence

Link featureT ype Common Transport Elements:: TransportLink

Node featureT ype Common Transport Elements:: TransportNode

featureT ype Road

featureT ype RoadLinkSequence

featureT ype RoadLink

featureT ype RoadNode

featureT ype ERoad

featureT ype FunctionalRoadClass featureT ype RoadSurfaceCategory featureT ype FormOfWay Netw orkProperty featureT ype Common Transport Elements:: TransportProperty featureT ype RoadWidth featureT ype RoadServ iceType

featureT ype RoadName featureT ype SpeedLimit featureT ype NumberOfLanes

Figure 14 UML class diagram: Overview of the Road Transport Networks

5.3.1.3 Consistency between spatial data sets

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.3) apply to the corresponding specialized elements/classes in the Road transport networks.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 42

5.3.1.4 Identifier management

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.4) apply to the corresponding specialized elements/classes in the Road transport networks.

5.3.1.5 Modelling of object references

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.5) apply to the corresponding specialized elements/classes in the Road transport networks.

5.3.1.6 Geometry representation

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.6) apply to the corresponding specialized elements/classes in the Road transport networks.

5.3.1.7 Temporality representation

All attributes describing the lifespan of spatial objects or the phenomena in the real world they describe are inherited from the Common Transport Elements application schema. Refer to section 5.2.1.7 for more information.

5.3.2 Feature catalogue

Table 5 Feature catalogue metadata Feature catalogue name Scope Version number Version date Definition source INSPIRE feature catalogue Road Transport Network Road Transport Network 3.0 2009-09-07 INSPIRE data specification Road Transport Network

Table 6 Types defined in the feature catalogue Type AreaConditionValue ERoad FormOfWay FunctionalRoadClass MinMaxLaneValue NumberOfLanes RoadLinkSequence RoadName RoadPartValue RoadServiceArea RoadServiceType RoadSurfaceCategory RoadSurfaceCategoryValue Package Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Stereotypes Section codeList 5.3.2.2.4 featureType 5.3.2.1.1 featureType 5.3.2.1.2 featureType 5.3.2.1.3 enumeration 5.3.2.2.1 featureType 5.3.2.1.4 featureType 5.3.2.1.5 featureType 5.3.2.1.6 codeList 5.3.2.2.5 featureType 5.3.2.1.7 featureType 5.3.2.1.8 featureType 5.3.2.1.9 codeList 5.3.2.2.6

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 43

Type RoadWidth SpeedLimit SpeedLimitMinMaxValue SpeedLimitSourceValue VehicleTrafficArea VehicleTypeValue WeatherConditionValue FormOfRoadNodeValue FormOfWayValue FunctionalRoadClassValue Road RoadArea RoadLink RoadNode RoadServiceTypeValue ServiceFacilityValue

Package Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network Road Transport Network

Stereotypes Section featureType 5.3.2.1.10 featureType 5.3.2.1.11 enumeration 5.3.2.2.2 codeList 5.3.2.2.7 featureType 5.3.2.1.12 codeList 5.3.2.2.8 codeList 5.3.2.2.9 codeList 5.3.2.2.10 codeList 5.3.2.2.11 enumeration 5.3.2.2.3 featureType 5.3.2.1.13 featureType 5.3.2.1.14 featureType 5.3.2.1.15 featureType 5.3.2.1.16 codeList 5.3.2.2.12 codeList 5.3.2.2.13

5.3.2.1 Spatial object types

INSPIRE TWG-TN

class Road Transport Netw ork: Spatial obj ect types - Links, Nodes and Areas featureT ype RoadServ iceArea

Area featureT ype Common Transport Elements::TransportArea voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All objects have inspireId} featureT ype VehicleTrafficArea

featureT ype RoadArea

LinkSet featureT ype Common Transport Elements:: TransportLinkSequence voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All com ponents belong to sam e transport network} {All objects have inspireId} voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All objects have inspireId}

LinkSequence

Link featureT ype Common Transport Elements::TransportLink

Node featureT ype Common Transport Elements::TransportNode voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All objects have inspireId}

featureT ype Common Transport Elements::TransportLinkSet

voidable + validFrom : DateT im e + validT o: DateT im e [0..1]

constraints {All com ponents belong to sam e transport network} {All objects have inspireId}

featureT ype Road featureT ype RoadLinkSequence

voidable + localRoadCode: CharacterString [0..1] + nationalRoadCode: CharacterString [0..1]

featureT ype RoadLink

featureT ype RoadNode voidable + form OfRoadNode: Form OfRoadNodeValue

featureT ype ERoad

Figure 15 UML class diagram: Road Transport Networks Spatial object types Links, Nodes and Areas

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 44

voidable + europeanRouteNum ber: CharacterString

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 45

class Road Transport Netw ork: Spatial obj ect types - Transport Properties featureT ype FunctionalRoadClass + functionalClass: FunctionalRoadClassValue + featureT ype RoadSurfaceCategory surfaceCategory: RoadSurfaceCategoryValue

constraints {Applies to road transport elem ents only}

constraints {Applies to road transport elem ents only} featureT ype FormOfWay + form OfWay: Form OfWayValue Netw orkProperty constraints {Applies to road transport elem ents only} featureT ype Common Transport Elements:: TransportProperty + featureT ype RoadWidth + width: M easure voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All objects have inspireId} featureT ype RoadName nam e: GeographicalNam e

constraints {Applies to road transport elem ents only}

voidable + m easuredRoadPart: RoadPartValue constraints {Applies to road transport elem ents only}

featureT ype RoadServ iceType + + availableFacility: ServiceFacilityValue [0..*] type: RoadServiceT ypeValue

featureT ype SpeedLimit + + speedLim itM inM axT ype: SpeedLimitM inM axValue = M axim um speedLim itValue: Velocity

constraints {Applies to road service areas only}

voidable + areaCondition: AreaConditionValue [0..1] + direction: LinkDirectionValue [0..1] + laneExtension: Integer [0..1] + speedLim itSource: SpeedLim itSourceValue [0..1] + startLane: Integer [0..1] + validityPeriod: T M _Period [0..1] + vehicleT ype: VehicleT ypeValue [0..1] + weatherCondition: WeatherConditionValue [0..1] constraints {Applies to road transport elem ents only}

featureT ype NumberOfLanes + num berOfLanes: Integer

voidable + direction: LinkDirectionValue [0..1] + m inM axNum berOfLanes: M inM axLaneValue [0..1] constraints {Applies to road transport elem ents only}

Figure 16 UML class diagram: Road Transport Networks Spatial object types Transport Properties

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 46

Figure 17 Overview of the main Road Transport Networks objects 5.3.2.1.1 ERoad ERoad TransportLinkSet A collection of road link sequences and or individual road links that represents a route that is part of the international E-road network, characterized by its European route number. EXAMPLE E40. Proposed featureType

Subtype of: Definition: Description: Status: Stereotypes:

Attribute: europeanRouteNumber Value type: CharacterString Definition: Code, identifying the route in the international E-road network. The code always starts with a letter 'E', followed by a one-, two- or three-digit number. Multiplicity: 1 Stereotypes: voidable 5.3.2.1.2 FormOfWay FormOfWay Subtype of: Definition: Status: Stereotypes: TransportProperty A classification based on the physical properties of the Road Link. [TWG TN, based on EuroRoadS] Proposed featureType

Attribute: formOfWay Value type: FormOfWayValue

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 47

FormOfWay Definition: Multiplicity: Physical form of the way. 1

Constraint: Applies to road transport elements only Natural This property can only be associated with a spatial object that is part of a road language: transport network. OCL: 5.3.2.1.3 FunctionalRoadClass FunctionalRoadClass Subtype of: Definition: Description: Status: Stereotypes: TransportProperty A classification based on the importance of the role that the road performs in the road network. SOURCE Adapted from [GDF, EuroRoadS]. Proposed featureType

Attribute: functionalClass Value type: FunctionalRoadClassValue Definition: Functional rank of the road link in the road network. Description: NOTE Where functional classification systems are used that have fewer classes/ranks than the number provided by FunctionalRoadClassValues, classes with codes 1 to n will be used, where n corresponds to the number of classes that are used in the classification system. Multiplicity: 1 Constraint: Applies to road transport elements only Natural This property can only be associated with a spatial object that is part of a road language: transport network. OCL: 5.3.2.1.4 NumberOfLanes NumberOfLanes Subtype of: Definition: Description: Status: Stereotypes: TransportProperty The number of lanes of a road element. SOURCE Adapated from [Euroroads]. Proposed featureType

Attribute: direction Value type: LinkDirectionValue Definition: Indicates which direction the number of lanes is valid for. Description: SOURCE [Euroroads]. NOTE When the value for this attribute is 'both', numberOfLanes contains the sum of the number of lanes in both directions of travel. NOTE This attribute only applies when the property is associated with a road link or road link sequence. Multiplicity: 0..1 Stereotypes: voidable Attribute: minMaxNumberOfLanes Value type: MinMaxLaneValue Definition: Indicates if the number of lanes are counted as minimum or maximum value. Description: SOURCE [Euroroads]. NOTE This attribute only applies when the value in numberOfLanes is not an exact value. 0..1

Multiplicity:

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 48

NumberOfLanes Stereotypes: voidable Attribute: numberOfLanes Value type: Integer Definition: Number of lanes. Description: SOURCE [Euroroads]. Multiplicity: 1 Constraint: Applies to road transport elements only Natural This property can only be associated with a spatial object that is part of a road language: transport network. OCL: 5.3.2.1.5 RoadLinkSequence RoadLinkSequence Subtype of: Definition: TransportLinkSequence A linear spatial object, composed of an ordered collection of road links, which represents a continuous path in a road network without any branches. The element has a defined beginning and end and every position on the road link sequence is identifiable with one single parameter such as length. It describes an element of the road network, characterized by one or more thematic identifiers and/or properties. Proposed featureType

Status: Stereotypes:

5.3.2.1.6 RoadName RoadName Subtype of: Definition: Status: Stereotypes: Attribute: name Value type: Definition: Multiplicity: TransportProperty Name of a road, as assigned by the responsible authority. Proposed featureType GeographicalName Name of the road. 1

Constraint: Applies to road transport elements only Natural This property can only be associated with a spatial object that is part of a road language: transport network. OCL: 5.3.2.1.7 RoadServiceArea RoadServiceArea Subtype of: Definition: Description: Status: Stereotypes: TransportArea Surface annexed to a road and devoted to offer particular services for it. EXAMPLES Gas station, rest area, toll area. Proposed featureType

5.3.2.1.8 RoadServiceType RoadServiceType Subtype of: Definition: Status: Stereotypes: TransportProperty Description of the type of road service area and the available facilities. Proposed featureType

Attribute: availableFacility

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 49

RoadServiceType Value type: Definition: Multiplicity: Attribute: type Value type: Definition: Multiplicity: ServiceFacilityValue Facility that is available for a given road service area. 0..* RoadServiceTypeValue Type of road service area. 1

Constraint: Applies to road service areas only Natural This property can only be associated with a spatial object of the type language: RoadServiceArea or RoadNode (when formOfRoadNode=roadServiceArea). OCL: 5.3.2.1.9 RoadSurfaceCategory RoadSurfaceCategory Subtype of: Definition: Description: Status: Stereotypes: TransportProperty Specification of the state of the surface of the associated Road Element. Indicates whether a road is paved or unpaved. SOURCE [GDF3, Euroroads]. Proposed featureType

Attribute: surfaceCategory Value type: RoadSurfaceCategoryValue Definition: Type of road surface. Multiplicity: 1 Constraint: Applies to road transport elements only Natural This property can only be associated with a spatial object that is part of a road language: transport network. OCL: 5.3.2.1.10 RoadWidth RoadWidth Subtype of: Definition: Description: Status: Stereotypes: TransportProperty The width of the road, measured as an average value. SOURCE [Euroroads]. Proposed featureType

Attribute: measuredRoadPart Value type: RoadPartValue Definition: Indicates to which part of a road the value for the attribute 'width' applies. Multiplicity: 1 Stereotypes: voidable Attribute: width Value type: Definition: Multiplicity: Measure Road width value. 1

Constraint: Applies to road transport elements only Natural This property can only be associated with a spatial object that is part of a road language: transport network. OCL: 5.3.2.1.11 SpeedLimit SpeedLimit

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 50

SpeedLimit Subtype of: Definition: Description: Status: Stereotypes: TransportProperty Limit for the speed of a vehicle on a road.. SOURCE [Euroroads]. Proposed featureType

Attribute: areaCondition Value type: AreaConditionValue Definition: Speed limit is dependent on environmental circumstances. Description: SOURCE [Euroroads]. Multiplicity: 0..1 Stereotypes: voidable Attribute: direction Value type: LinkDirectionValue Definition: Indicates which direction the speed limit is valid for. Description: SOURCE [Euroroads]. NOTE This attribute only applies when the property is associated with a road link or road link sequence. Multiplicity: 0..1 Stereotypes: voidable Attribute: laneExtension Value type: Integer Definition: Number of lanes including the start lane counted from the right hand side for which the speed limit applies. Description: SOURCE [Euroroads]. NOTE This attribute only applies when the property is associated with a road link or road link sequence. Multiplicity: 0..1 Stereotypes: voidable Attribute: speedLimitMinMaxType Value type: SpeedLimitMinMaxValue Definition: Indicates if the speed limit is maximum or minimum and if it is recommended. Description: SOURCE [Euroroads]. Multiplicity: 1 Attribute: speedLimitSource Value type: SpeedLimitSourceValue Definition: Source for speed limit. Description: SOURCE [Euroroads]. Multiplicity: 0..1 Stereotypes: voidable Attribute: speedLimitValue Value type: Velocity Definition: Value for speed limit. Description: SOURCE [Euroroads]. Multiplicity: 1 Attribute: startLane Value type: Integer Definition: Start lane counted from the right side for which speed limit applies. Description: SOURCE [Euroroads]. NOTE This attribute only applies when the property is associated with a road link or road link sequence. Multiplicity: 0..1 Stereotypes: voidable

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 51

SpeedLimit Attribute: validityPeriod Value type: TM_Period Definition: Period during which the speed limit is valid. Multiplicity: 0..1 Stereotypes: voidable Attribute: vehicleType Value type: VehicleTypeValue Definition: Vehicle type the speed limit is restricted to. Description: SOURCE Adapted from [Euroroads]. Multiplicity: 0..1 Stereotypes: voidable Attribute: weatherCondition Value type: WeatherConditionValue Definition: Weather condition the speed limit is dependent on. Description: SOURCE Adapted from [Euroroads]. Multiplicity: 0..1 Stereotypes: voidable Constraint: Applies to road transport elements only Natural This property can only be associated with a spatial object that is part of a road language: transport network. OCL: 5.3.2.1.12 VehicleTrafficArea VehicleTrafficArea Subtype of: Definition: Status: Stereotypes: 5.3.2.1.13 Road Road Subtype of: Definition: Description: Status: Stereotypes: TransportLinkSet A collection of road link sequences and/or individual road links that are characterized by one or more thematic identifiers and/or properties. EXAMPLE Examples are roads characterized by a specific identification code, used by road management authorities or tourist routes, identified by a specific name. Proposed featureType TransportArea Surface that represents the part of a road which is used for the normal traffic of vehicles. Proposed featureType

Attribute: localRoadCode Value type: CharacterString Definition: Identification code assigned to the road by the local road authority. Multiplicity: 0..1 Stereotypes: voidable Attribute: nationalRoadCode Value type: CharacterString Definition: The national number of the road. Description: SOURCE [Euroroads]. Multiplicity: 0..1 Stereotypes: voidable

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 52

5.3.2.1.14 RoadArea RoadArea Subtype of: Definition: Description: Status: Stereotypes: 5.3.2.1.15 RoadLink RoadLink Subtype of: Definition: TransportLink A linear spatial object that describes the geometry and connectivity of a road network between two points in the network. Road links can represent paths, bicycle roads, single carriageways, multiple carriageway roads and even fictitious trajectories across traffic squares. Proposed featureType TransportArea Surface which extends to the limits of a road, including vehicular areas and other parts of it. EAXMPLE Pedestrian areas. Proposed featureType

Status: Stereotypes:

5.3.2.1.16 RoadNode RoadNode Subtype of: Definition: Status: Stereotypes: TransportNode A point spatial object that is used to either represent connectivity between two road links or to represent a significant spatial object such as a services station or roundabout. Proposed featureType

Attribute: formOfRoadNode Value type: FormOfRoadNodeValue Definition: Description of the function of a road node in the road transport network. Multiplicity: 1 Stereotypes: voidable

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 53

5.3.2.2 Enumerations and code lists

class Road Transport Netw ork: Enumerations and Code Lists codeList RoadServ iceTypeValue + + + + busStation parking restArea toll + + + + + + + codeList Serv iceFacilityValue drinks food fuel picnicArea playground shop toilets + + + + + + + + codeList FormOfRoadNodeValue enclosedT rafficArea junction levelCrossing pseudoNode roadEnd roadServiceArea roundabout trafficSquare + + + + + + + + + + + + + + + + + + + + + + + + + + + + + codeList VehicleTypeValue allVehicle bicycle carWithT railer deliveryT ruck em ergencyVehicle em ployeeVehicle facilityVehicle farm Vehicle highOccupancyVehicle lightRail m ailVehicle m ilitaryVehicle m oped m otorcycle passengerCar pedestrian privateBus publicBus residentialVehicle schoolBus snowChainEquippedVehicle tanker taxi transportT ruck trolleyBus vehicleForDisabledPerson vehicleWithExplosiveLoad vehicleWithOtherDangerousLoad vehicleWithWaterPollutingLoad

codeList FormOfWayValue + + + + + + + + + + + + + + + bicycleRoad dualCarriageway enclosedT rafficArea entranceOrExitCarPark entranceOrExitService freeway m otorway pedestrianZone roundabout serviceRoad singleCarriageway slipRoad tractor trafficSquare walkway + +

enum eration FunctionalRoadClassValue m ainRoad firstClass secondClass thirdClass fourthClass fifthClass sixthClass seventhClass eighthClass ninthClass

codeList WeatherConditionValue + + + + + fog ice rain sm og snow

codeList SpeedLimitSourceValue + + + fixedT rafficSign regulation variableT rafficSign

codeList RoadPartValue carriageway pavedSurface

codeList AreaConditionValue + + + + + + inNationalPark insideCities nearRailroadCrossing nearSchool outsideCities trafficCalm ingArea

enum eration SpeedLimitM inM axValue codeList RoadSurfaceCategoryValue + + paved unpaved m axim um m inim um recom m endedM axim um recom m endedM inim um enum eration M inM axLaneValue m axim um m inim um average

Figure 18 UML class diagram: Road Transport Networks Enumerations and code lists

5.3.2.2.1 MinMaxLaneValue MinMaxLaneValue Definition: Description: Status: Stereotypes: Value: maximum Definition: Description: Value: minimum Definition: Description: Value: average Definition: Description: Values to indicate whether number of lanes are counted as the maximum, minimum or average number. SOURCE Adapted from [Euroroads]. Proposed enumeration The number of lanes is the maximum value for a given part of the road network. SOURCE Adapted from [Euroroads]. The number of lanes is the minimum value for a given part of the road network. SOURCE [Euroroads]. The number of lanes is the average value for a given part of the road network. SOURCE [Euroroads].

5.3.2.2.2 SpeedLimitMinMaxValue SpeedLimitMinMaxValue

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 54

SpeedLimitMinMaxValue Definition: Status: Stereotypes: Value: maximum Definition: Description: Value: minimum Definition: Description: Possible values to indicate the nature of a speed limit. Proposed enumeration Speed limit is a maximum value SOURCE [Euroroads]. Speed limit is a minmum value SOURCE [Euroroads].

Value: recommendedMaximum Definition: Speed limit is a recommended maximum value Description: SOURCE [Euroroads]. Value: recommendedMinimum Definition: Speed limit is a recommended minimum value Description: SOURCE [Euroroads]. 5.3.2.2.3 FunctionalRoadClassValue FunctionalRoadClassValue Definition: Description: Status: Stereotypes: Value: mainRoad Definition: Description: Value: firstClass Definition: Description: Values for the functional road classification. This classification is based on the importance of the role that the road performs in the road network. SOURCE Adapted from [GDF, EuroRoadS]. Proposed enumeration The most important roads in a given network. SOURCE [GDF], [Euroroads]. The second most important road in a given network. SOURCE [Euroroads].

Value: secondClass Definition: The third most important road in a given network. Description: SOURCE [Euroroads]. Value: thirdClass Definition: Description: The fourth most important road in a given network. SOURCE [Euroroads].

Value: fourthClass Definition: The fifth most important road in a given network. Description: SOURCE [Euroroads]. Value: fifthClass Definition: Description: Value: sixthClass Definition: Description: The sixth most important road in a given network. SOURCE [Euroroads]. The seventh most important road in a given network. SOURCE [Euroroads].

Value: seventhClass Definition: The eigth most important road in a given network. Description: SOURCE [Euroroads]. Value: eighthClass Definition: The ninth most important road in a given network. Description: SOURCE [Euroroads]. Value: ninthClass

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 55

FunctionalRoadClassValue Definition: Description: The least important roads in a given network. SOURCE [GDF] NOTE The farthest ways in the forest road network. It has no regular maintenance. [NVDB] [Euroroads]. 5.3.2.2.4 AreaConditionValue AreaConditionValue Definition: Description: Status: Stereotypes: Governance: Speed limit restriction depending on the area.. SOURCE [Euroroads]. Proposed codeList Centrally managed in INSPIRE code list inspire:def:codeList:INSPIRE:AreaConditionValues

register.

URN:

urn:x-

Value: inNationalPark Definition: Speed limit restriction inside national park. Description: SOURCE [Euroroads]. Value: insideCities Definition: Speed limit restriction inside cities. Description: SOURCE [Euroroads]. Value: nearRailroadCrossing Definition: Speed limit restriction near rail road crossing. Description: SOURCE [Euroroads]. Value: nearSchool Definition: Speed limit restriction near school. Description: SOURCE [Euroroads]. Value: outsideCities Definition: Speed limit restriction outside cities. Description: SOURCE [Euroroads]. Value: trafficCalmingArea Definition: Speed limit restriction in traffic calming area. Description: SOURCE [Euroroads]. 5.3.2.2.5 RoadPartValue RoadPartValue Definition: Status: Stereotypes: Governance: Parts that make up a road. Proposed codeList Centrally managed in INSPIRE code inspire:def:codeList:INSPIRE:RoadPartValues

list

register.

URN:

urn:x-

Value: carriageway Definition: The part of a road which is reserved for traffic. Value: pavedSurface Definition: The part of the road which is paved. 5.3.2.2.6 RoadSurfaceCategoryValue RoadSurfaceCategoryValue Definition: Status: Stereotypes: Governance: Values to indicate whether a road is paved or not paved. Proposed codeList Centrally managed in INSPIRE code list register. inspire:def:codeList:INSPIRE:RoadSurfaceCategoryValues

URN:

urn:x-

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 56

RoadSurfaceCategoryValue Value: paved Definition: Road with a hard paved surface. Description: SOURCE [Euroroads]. EXAMPLES Asphalt or concrete. Value: unpaved Definition: Description: Road not paved. SOURCE [Euroroads]. EXAMPLE Gravelled road. 5.3.2.2.7 SpeedLimitSourceValue SpeedLimitSourceValue Definition: Status: Stereotypes: Governance: Possible sources for speed limits. Proposed codeList Centrally managed in INSPIRE code list register. inspire:def:codeList:INSPIRE:SpeedLimitSourceValues

URN:

urn:x-

Value: fixedTrafficSign Definition: Source is a fixed traffic sign (site specific administrative order, explicit speed limit). Description: SOURCE [Euroroads]. Value: regulation Definition: Description: Source is a regulation (national regulation, rule or 'implicit speed limit'). SOURCE [Euroroads].

Value: variableTrafficSign Definition: Source is a variable traffic sign. Description: SOURCE [Euroroads]. 5.3.2.2.8 VehicleTypeValue VehicleTypeValue Definition: Status: Stereotypes: Governance: Value: allVehicle Definition: Description: Value: bicycle Definition: Description: Possible types of vehicles. Proposed codeList Centrally managed in INSPIRE code list inspire:def:codeList:INSPIRE:VehicleTypeValues Any vehicle, not including pedestrians. SOURCE [Euroroads]. pedal-driven two-wheeled vehicle. SOURCE [Euroroads].

register.

URN:

urn:x-

Value: carWithTrailer Definition: A passenger car with an attached trailer. Description: SOURCE [Euroroads]. Value: deliveryTruck A truck vehicle of relatively small size, whose principal use is for delivery of Definition: goods and materials. Description: SOURCE [Euroroads]. Value: emergencyVehicle A vehicle engaged in emergency response, included but not limited to police, Definition: ambulance and fire.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 57

VehicleTypeValue Description: SOURCE [Euroroads]. Value: employeeVehicle Definition: A vehicle operated by an employee of an organization that is used within that organization's ground. Description: SOURCE [Euroroads]. Value: facilityVehicle Definition: A vehicle dedicated to a localized area within a private or restricted estate. Description: SOURCE [Euroroads]. EXAMPLE Facilities roads within an airport or theme park. Value: farmVehicle Definition: Vehicle commonly associated with farming activities. Description: SOURCE [Euroroads]. Value: highOccupancyVehicle Definition: Vehicle populated with a number of occupants corresponding to (or exceeding) the specified minimum number of passengers. Description: SOURCE [Euroroads]. Value: lightRail Definition: Description: Train-like transport vehicle limited to a rail network within a limited area. SOURCE [Euroroads]. NOTE Does not include heavy rail lines. Value: mailVehicle Definition: A vehicle that collects, carries or delivers mail. Description: SOURCE [Euroroads]. Value: militaryVehicle Definition: Vehicle authorized by a military authority. Description: SOURCE [Euroroads]. Value: moped Definition: Description: Two or three wheeled vehicle equipped with internal combustion engine, with size less than 50 cc and maximum speed that does not exceed 45 km/h (28mph). SOURCE Adapted from [CADaS/CARE].

Value: motorcycle Definition: Two or three wheeled vehicle equipped with internal combustion engine, with size more than 50 cc and maximum speed that does exceed 45 km/h (28mph). Description: SOURCE Adapted from [CADaS/CARE]. Value: passengerCar Definition: A small vehicle designed for private transport of people. Description: SOURCE [Euroroads]. Value: pedestrian Definition: Description: A person on foot. SOURCE [Euroroads].

Value: privateBus A vehicle designed for transport of large groups of people, privately owned or Definition: chartered. Description: SOURCE [Euroroads]. Value: publicBus Definition: Description: A vehicle designed for transport of large groups of people that is generally charterized by published routes and schedules. SOURCE [Euroroads].

Value: residentialVehicle

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 58

VehicleTypeValue Definition: Description: A vehicle whose owner is resident (or a guest) of particular street or town area. SOURCE [Euroroads].

Value: schoolBus Definition: Vehicle operated on behalf of a school to transport students. Description: SOURCE [Euroroads]. Value: snowChainEquippedVehicle Definition: Any vehicle equipped with snow chains. Description: SOURCE [Euroroads]. Value: tanker Definition: Description: Value: taxi Definition: Description: A truck with more than two axels used to transport liquid loads in bulk. SOURCE [Euroroads]. A vehicle licensed for hire usually fitted with a meter. SOURCE [Euroroads].

Value: transportTruck Definition: A truck vehicle for long range transport of goods. Description: SOURCE [Euroroads]. Value: trolleyBus Definition: Description: A bus-like mass transport vehicle hooked up to an electrical network for power supply. SOURCE [Euroroads].

Value: vehicleForDisabledPerson A vehicle with supporting identification that designates a vehicle for disabled Definition: persons. Description: SOURCE [Euroroads]. Value: vehicleWithExplosiveLoad Definition: Vehicle transporting explosive cargo. Description: SOURCE [Euroroads]. Value: vehicleWithOtherDangerousLoad Definition: Vehicle transporting dangerous cargo, other than explosive or waterpollution loads. Description: SOURCE [Euroroads]. Value: vehicleWithWaterPollutingLoad Definition: Vehicle transporting water-polluting cargo. Description: SOURCE [Euroroads]. 5.3.2.2.9 WeatherConditionValue WeatherConditionValue Definition: Status: Stereotypes: Governance: Value: fog Definition: Description: Value: ice Definition: Description: Value: rain Definition: Values to indicate weather conditions that affect speed limits. Proposed codeList Centrally managed in INSPIRE code list register. inspire:def:codeList:INSPIRE:WeatherConditionValues Speed applies when fog is present. SOURCE Adapted from [Euroroads]. Speed applies when ice is present. SOURCE Adapted from [Euroroads]. Speed applies when rain is present.

URN:

urn:x-

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 59

WeatherConditionValue Description: Value: smog Definition: Value: snow Definition: SOURCE Adapted from [Euroroads]. Speed applies when a certain amount of smog is present. Speed applies when snow is present.

5.3.2.2.10 FormOfRoadNodeValue FormOfRoadNodeValue Definition: Status: Stereotypes: Governance: Functions of road nodes within Euroroads. Proposed codeList Centrally managed in INSPIRE code list register. inspire:def:codeList:INSPIRE:FormOfRoadNodeValues

URN:

urn:x-

Value: enclosedTrafficArea Definition: The road node is situated inside and/or represents an enclosed traffic area. A traffic area is an area with no internal structure of legally defined driving directions. At least two roads are connected to the area.. Description: SOURCE [Euroroads]. Value: junction Definition: Three or more road links intersect at the road node.

Value: levelCrossing Definition: A railway crosses a road on the same level at the position of the road node. Value: pseudoNode Definition: Exactly two road links connect to the road node. Value: roadEnd Definition: Only one road link connects to the road node. It signifies the end of a road.

Value: roadServiceArea Definition: Surface annexed to a road and devoted to offer particular services for it. Description: EXAMPLES Gas station, rest area, toll area. Value: roundabout Definition: The road node represents or is a part of a roundabout. Value: trafficSquare Definition: The road node is situated inside and/or represents a traffic square. A traffic square is an area (partly) enclosed by roads which is used for non-traffic purposes and which is not a roundabout. Description: SOURCE [GDF, Euroroads]. 5.3.2.2.11 FormOfWayValue FormOfWayValue Definition: Description: Status: Stereotypes: Governance: Classification based on the physical properties of the road link. SOURCE Based on [Euroroads]. Proposed codeList Centrally managed in INSPIRE code list register. inspire:def:codeList:INSPIRE:FormOfWayValues

URN:

urn:x-

Value: bicycleRoad Definition: Road where bicycles are the only vehicles allowed. Description: SOURCE Adapted from [Euroroads]. Value: dualCarriageway Definition: Road with physically separated carriageways regardless of the number of lanes, which is not a motorway or a freeway. Description: SOURCE Based on [NVDB/GDF, Euroroads].

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 60

FormOfWayValue Value: enclosedTrafficArea Area with no internal structure of legally defined driving directions. At least two Definition: roads are connected to the area. Description: SOURCE [Euroroads]. Value: entranceOrExitCarPark Definition: Road specially designed to enter or to leave a parking area. Description: SOURCE [GDF], [Euroroads]. Value: entranceOrExitService Definition: Road used only to enter or to leave a service. Description: SOURCE [GDF], [Euroroads]. Value: freeway Definition: Description: Value: motorway Definition: Description: Road having no single level crossings with other roads. SOURCE Adapted from [Euroroads]. NOTE This means that connections with other roads consist of slip roads. Road permitted for motorized vehicles only in combination with a prescribed minimum speed. It has two or more mostly physically separated carriageways and no single level-crossings. SOURCE [GDF], [Euroroads].

Value: pedestrianZone Definition: Area with a road network which is especially designed for use by pedestrians. Description: SOURCE [GDF], [Euroroads]. NOTE Pedestrian zones are usually located in urban areas. Except for emergency vehicles and for delivery vehicles during certain hours no traffic is allowed on the road network elements which are located inside the zone. Value: roundabout Definition: Road which forms a ring on which traffic travelling in only one direction is allowed. Description: SOURCE Based on [GDF], [Euroroads]. NOTE The Road elements which make up a roundabout are connected to one another and they form exactly one ring. Value: serviceRoad Definition: Road running parallel to and connecting to a road with a relatively high connectivity function, which is especially designed to enable access from the connecting roads to roads with a low connectivity function in its vicinity. Description: SOURCE Based on [GDF], [Euroroads]. NOTE Generally, service roads have the same name as the higher class road it runs parallel to and are only divided from it by small constructions like walkways, traffic islands etc. Value: singleCarriageway Definition: Road where the traffic is not separated by any physical object. Description: SOURCE [GDF], [Euroroads]. NOTE All roads without separate carriageways are considered as roads with a single carriageway. Value: slipRoad Definition: Description: Value: tractor Road especially designed to enter or leave a road. SOURCE Adapted from [Euroroads].

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 61

FormOfWayValue Definition: Description: Arranged road only usable for a tractor (farm vehicle or forest machine) or terrain vehicle (a vehicle with higher ground clearance, big wheels and 4 wheel drive). SOURCE Based on [Euroroads].

Value: trafficSquare Definition: Area (partly) enclosed by roads which is used for non-traffic purposes and which is not a roundabout. Description: SOURCE [GDF], [Euroroads]. Value: walkway Definition: Description: Road reserved for pedestrian use and closed for regular vehicular use by a physically barrier. SOURCE Adapted from [Euroroads]. NOTE Occasional use by (emergency) services may occur. 5.3.2.2.12 RoadServiceTypeValue RoadServiceTypeValue Definition: Status: Stereotypes: Governance: Types of road service areas. Proposed codeList Centrally managed in INSPIRE code list register. inspire:def:codeList:INSPIRE:RoadServiceTypeValues

URN:

urn:x-

Value: busStation Definition: The road service is a bus stop. Value: parking Definition: Value: restArea Definition: Value: toll Definition: The road service areea is a parking facility. The road service is a rest area. Area that provides toll services such as ticket dispensers or toll payment services.

5.3.2.2.13 ServiceFacilityValue ServiceFacilityValue Definition: Status: Stereotypes: Governance: Value: drinks Definition: Value: food Definition: Value: fuel Definition: Possible service facilities available at a road service area. Proposed codeList Centrally managed in INSPIRE code list register. inspire:def:codeList:INSPIRE:ServiceFacilityValues Drinks are available. Food is available. Fuel is available.

URN:

urn:x-

Value: picnicArea Definition: A picnic area is present. Value: playground Definition: A playground area is present. Value: shop Definition: Value: toilets Definition: A shop is present. Toilets are present.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 62

5.3.2.3 Imported types (informative)

This section lists definitions for feature types, data types and enumerations and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references. 5.3.2.3.1 TransportLinkSequence TransportLinkSequence (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] A linear spatial object, composed of an ordered collection of transport links, which represents a continuous path in the transport network without any branches. The element has a defined beginning and end and every position on the transport link sequence is identifiable with one single parameter such as length. It describes an element of the transport network, characterized by one or more thematical identifiers and/or properties.

5.3.2.3.2 TransportLink TransportLink (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] A linear spatial object that describes the geometry and connectivity of a transport network between two points in the network.

5.3.2.3.3 TransportArea TransportArea (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] Surface that represents the spatial extent of an element of a transport network.

5.3.2.3.4 TransportNode TransportNode (abstract) Package: Definition: Description: Common Transport Elements [see section 5.2.2] A point spatial object which is used for connectivity. Nodes are found at either end of the TransportLink.

5.3.2.3.5 TransportProperty TransportProperty (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] A reference to a property that falls upon the network. This property can apply to the whole of the network element it is associated with or - for linear spatial objects - be described using linear referencing.

5.3.2.3.6 TransportLinkSet TransportLinkSet (abstract) Package: Definition: Description: Common Transport Elements [see section 5.2.2] A collection of transport link sequences and or individual transport links that has a specific function or siginificance in a transport network. NOTE This spatial object type supports the aggregation of links to form objects with branches, loops, parallel sequences of links, gaps, etc. EXAMPLE A dual carriageway road, as a collection of the two link sequences that represent each carriageway. 5.3.2.3.7 GeographicalName GeographicalName Package: Geographical Names [see EC DS-D2.8.I.3]

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 63

GeographicalName Definition: Proper noun applied to a real world entity.

5.3.2.3.8 LinkDirectionValue LinkDirectionValue Package: Definition: Network [see DS-D2.5] List of values for directions relative to a link

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 64

5.4 Application schema Rail Transport Networks

5.4.1 Description
5.4.1.1 Narrative description
The Rail Transport Networks application schema (Rail Schema) employs a link and node structure to represent the rail tracks used for transportation in the form of a linear network. The Rail Schema inherits classes from the Common Transport Schema and also creates its own classes to describe properties of the rail network such as Ownership and restrictions that can apply to whole sections of the network element or subsections that can be described using linear referencing. The primary aspects modelled for rail network elements are: Spatial. Geometric (point, line and area (topographic)) representation of various elements that are parts of a network. Typically, the network is handled as a network of connected linear elements (links) with points (nodes) at the ends of the lines (at junctions, rail ends etc). Also real objects with a function in a network may be represented in the dataset. Network connectivity within the rail network is essential but between elements in the other networks is an optional spatial aspect. Temporal. All elements in a network may have a temporal validity (i.e. description of when the network element exists in the real world) and also optional information on when data was entered, modified or deleted in the dataset. Thematic. The Rail Schema can be thematically displayed via several of the attributes defined within the specification such as railwayGauge or owningAuthority.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 65

5.4.1.2 UML Overview

class Railw ay Transport Netw ork Ov erv iew featureT ype Railw ayArea featureT ype Railw ayStationArea

Area featureT ype Common Transport Elements:: TransportArea featureT ype Railw ayYardArea

Li nkSet featureT ype Common Transport Elements:: TransportLinkSet

Li nkSequence featureT ype Common Transport Elements:: TransportLinkSequence

Link featureT ype Common Transport Elements:: TransportLink

Node featureT ype Common Transport Elements:: TransportNode

featureT ype Railw ayLine

featureT ype Railw ayLinkSequence

featureT ype Railw ayLink

featureT ype Railw ayNode

featureT ype Railw ayYardNode

featureT ype Railw ayStationNode

featureT ype Railw ayGauge

featureT ype Railw ayElectrification

featureT ype Railw ayUse

Netw orkProperty featureT ype Common Transport Elements:: TransportProperty

featureT ype Railw ayType

featureT ype DesignSpeed

featureT ype NumberOfTracks

Figure 19 UML class diagram: Overview of the Rail Transport Networks application schema

5.4.1.3 Consistency between spatial data sets

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.3) apply to the corresponding specialized elements/classes in the Rail transport networks.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 66

5.4.1.4 Identifier management

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.4) apply to the corresponding specialized elements/classes in the Rail transport networks.

5.4.1.5 Modelling of object references

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.5) apply to the corresponding specialized elements/classes in the Rail transport networks.

5.4.1.6 Geometry representation

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.6) apply to the corresponding specialized elements/classes in the Rail transport networks.

5.4.1.7 Temporality representation

All attributes describing the lifespan of spatial objects or the phenomena in the real world they describe are inherited from the Common Transport Elements application schema. Refer to section 5.2.1.7 for more information.

5.4.2 Feature catalogue

Table 7 Feature catalogue metadata Feature catalogue name Scope Version number Version date Definition source INSPIRE feature catalogue Railway Transport Network Railway Transport Network 3.0 2009-09-07 INSPIRE data specification Railway Transport Network Table 8 Types defined in the feature catalogue Type DesignSpeed FormOfRailwayNodeValue MinMaxTrackValue NumberOfTracks RailwayArea RailwayElectrification RailwayGauge RailwayGaugeCategoryValue RailwayLine RailwayLink RailwayLinkSequence RailwayNode RailwayStationArea Package Railway Transport Network Railway Transport Network Railway Transport Network Railway Transport Network Railway Transport Network Railway Transport Network Railway Transport Network Railway Transport Network Railway Transport Network Railway Transport Network Railway Transport Network Railway Transport Network Railway Transport Network Stereotypes Section featureType 5.4.2.2.1 codeList 5.4.2.3.3 enumeration 5.4.2.3.1 featureType 5.4.2.2.2 featureType 5.4.2.2.3 featureType 5.4.2.2.4 featureType 5.4.2.2.5 enumeration 5.4.2.3.2 featureType 5.4.2.2.6 featureType 5.4.2.2.7 featureType 5.4.2.2.8 featureType 5.4.2.2.9 featureType 5.4.2.2.10

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 67

Type RailwayStationNode RailwayType RailwayTypeValue RailwayUse RailwayUseValue RailwayYardArea RailwayYardNode

Package Railway Transport Network Railway Transport Network Railway Transport Network Railway Transport Network Railway Transport Network Railway Transport Network Railway Transport Network

Stereotypes featureType featureType codeList featureType codeList featureType featureType

Section 5.4.2.2.11 5.4.2.2.12 5.4.2.3.4 5.4.2.2.13 5.4.2.3.5 5.4.2.2.14 5.4.2.2.15

INSPIRE TWG-TN

class Railw ay Transport Netw ork: Spatial obj ects types - Links, Nodes and Areas featureT ype Railw ayArea

Area featureT ype Common Transport Elements::TransportArea + stationCode: CharacterString voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All objects have inspireId} featureT ype Railw ayYardArea featureT ype Railw ayStationArea

5.4.2.1 Spatial object types

LinkSet featureT ype Common Transport Elements:: TransportLinkSequence voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All com ponents belong to sam e transport network} {All objects have inspireId} constraints {All objects have inspireId} voidable + validFrom : DateT im e + validT o: DateT im e [0..1] featureT ype Common Transport Elements::TransportLink

LinkSequence

Link

Node featureT ype Common Transport Elements::TransportNode voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All objects have inspireId}

featureT ype Common Transport Elements::TransportLinkSet

voidable + validFrom : DateT im e + validT o: DateT im e [0..1]

constraints {All com ponents belong to sam e transport network} {All objects have inspireId}

featureT ype Railw ayLine

featureT ype Railw ayLinkSequence

featureT ype Railw ayLink voidable + fictitious: boolean

featureT ype Railw ayNode voidable + form OfNode: Form OfRailwayNodeValue

voidable + railwayLineCode: CharacterString

featureT ype Railw ayYardNode

featureT ype Railw ayStationNode

constraints {form OfNode is always RailwayStop}

voidable + num berOfPlatform s: Integer + stationCode: CharacterString constraints {form OfNode is always RailwayStop}

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 68

Figure 20 UML class diagram: Railway Transport Networks Spatial object types Links, Nodes and Areas

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 69

class Railw ay Transport Netw ork: Spatial Obj ect Types - Transport Properties featureT ype Railw ayGauge voidable + gauge: M easure [0..1] + gaugeCategory: RailwayGaugeCategoryValue [0..1] constraints {Applies to railway transport classes only} +

featureT ype Railw ayElectrification electrified: boolean

constraints {Applies to railway transport classes only} featureT ype Railw ayUse + use: RailwayUseValue Netw orkProperty featureT ype Common Transport Elements:: TransportProperty voidable + validFrom : DateT im e + validT o: DateT im e [0..1] featureT ype DesignSpeed + speed: Velocity featureT ype NumberOfTracks + num berOfT racks: Integer constraints {All objects have inspireId} + featureT ype Railw ayType type: RailwayT ypeValue

constraints {Applies to Railway T ransport classes oly}

constraints {Applies to railway transport classes only}

constraints {Applies to railway transport classes only}

voidable + m inM axNumberOfT racks: M inM axLaneValues constraints {Applies to railway transport classes only}

Figure 21 UML class diagram: Railway Transport Networks Spatial object types Transport Properties

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 70

Figure 22 Overview of the main Rail Transport Networks objects

5.4.2.2 Spatial object types

5.4.2.2.1 DesignSpeed DesignSpeed Subtype of: Definition: Status: Stereotypes: Attribute: speed Value type: Definition: Multiplicity: TransportProperty The specification of the maximum speed to which a railway line is designed for. Proposed featureType Velocity The specification of the maximum speed to which a railway line is designed for. 1

Constraint: Applies to railway transport classes only Natural This property can only be associated with a spatial object that is part of a railway language: transport network. OCL: 5.4.2.2.2 NumberOfTracks NumberOfTracks Subtype of: Definition: Description: Status: Stereotypes: TransportProperty The number of tracks for a railway stretch. This is dependent on the resolution of the data. Proposed featureType

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 71

NumberOfTracks Attribute: minMaxNumberOfTracks Value type: MinMaxLaneValues Definition: Indicates whether the number of tracks are counted as minimum or maximum value. Description: NOTE This attribute only applies when the value in numberOfTracks is not an exact value. Multiplicity: 1 Stereotypes: voidable Attribute: numberOfTracks Value type: Integer Definition: The number of tracks present. Multiplicity: 1 Constraint: Applies to railway transport classes only Natural This property can only be associated with a spatial object that is part of a railway language: transport network. OCL: 5.4.2.2.3 RailwayArea RailwayArea Subtype of: Definition: Status: Stereotypes: TransportArea Surface occupied by a railway track, including ballast. Proposed featureType

5.4.2.2.4 RailwayElectrification RailwayElectrification Subtype of: Definition: Status: Stereotypes: TransportProperty Indication whether the railway is provided with an electric system to power vehicles moving along it. Proposed featureType

Attribute: electrified Value type: boolean Definition: Inidicates whether the railway is provided with an electric system to power vehicles moving along it. Multiplicity: 1 Constraint: Applies to railway transport classes only Natural This property can only be associated with a spatial object that is part of a railway language: transport network. OCL: 5.4.2.2.5 RailwayGauge RailwayGauge Subtype of: Definition: Status: Stereotypes: Attribute: gauge Value type: Definition: Multiplicity: Stereotypes: TransportProperty The distance between the two outer rails (gauge) of a railway. Proposed featureType Measure An exact measure that indicates the gauge of a railway. 0..1 voidable

Attribute: gaugeCategory

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 72

RailwayGauge Value type: Definition: Multiplicity: Stereotypes: RailwayGaugeCategoryValue Provision of the gauge of a railway as a fuzzy category with respect to the European standard gauge. 0..1 voidable

Constraint: Applies to railway transport classes only Natural This property can only be associated with a spatial object that is part of a railway language: transport network. OCL: 5.4.2.2.6 RailwayLine RailwayLine Subtype of: Definition: Description: Status: Stereotypes: TransportLinkSet A collection of railway link sequences and or individual railway links that are characterized by one or more thematical identifiers and/or properties. EXAMPLE Railway lines characterized by a specific identification code, used by railroad companies or tourist railways, identified by a specific name. Proposed featureType

Attribute: railwayLineCode Value type: CharacterString Definition: A unique code assigned to a railway line. Multiplicity: 1 Stereotypes: voidable 5.4.2.2.7 RailwayLink RailwayLink Subtype of: Definition: Description: Status: Stereotypes: TransportLink A linear spatial object that describes the geometry and connectivity of a railway network between two points in the network. NOTE Railway links can be used to represent stretches of railway with one or multiple tracks. Proposed featureType

Attribute: fictitious Value type: boolean Definition: The railway link does not represent a real and existing railway track but a fictitious trajectory. Description: EXAMPLE A fictitious trajectory to connect railway links across a turntable. Multiplicity: 1 Stereotypes: voidable 5.4.2.2.8 RailwayLinkSequence RailwayLinkSequence Subtype of: Definition: TransportLinkSequence A linear spatial object, composed of an ordered collection of railway links, which represents a continuous path in a railway network without any branches. The element has a defined beginning and end and every position on the road link sequence is identifiable with one single parameter such as length. It describes an element of the railway network, characterized by one or more thematical identifiers and/or properties. Proposed featureType

Status: Stereotypes:

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 73

5.4.2.2.9 RailwayNode RailwayNode Subtype of: Definition: Status: Stereotypes: TransportNode A point spatial object which represents a significant point along the railway network or defines an intersection of railway tracks used to describe its connectivity. Proposed featureType

Attribute: formOfNode Value type: FormOfRailwayNodeValue Definition: The function of a railway node within the railway network. Multiplicity: 1 Stereotypes: voidable 5.4.2.2.10 RailwayStationArea RailwayStationArea Subtype of: Definition: Status: Stereotypes: TransportArea An area spatial object which is used to represent the topographical limits of the facilities of a railway station (buildings, railway yards, installations and equipment) devoted to carry out railway station operations. Proposed featureType

Attribute: stationCode Value type: CharacterString Definition: A unique code assigned to a railway station. Multiplicity: 1 5.4.2.2.11 RailwayStationNode RailwayStationNode Subtype of: Definition: Status: Stereotypes: RailwayNode A railway node which represents the location of a railway station along the railway network. Proposed featureType

Attribute: numberOfPlatforms Value type: Integer Definition: A value indicating the number of platforms available at a railway station. Multiplicity: 1 Stereotypes: voidable Attribute: stationCode Value type: CharacterString Definition: A unique code assigned to a railway station. Multiplicity: 1 Stereotypes: voidable Constraint: formOfNode is always RailwayStop Natural For a RailwayStationNode, the value for the "formOfNode" attribute shall always language: be "RailwayStop". OCL: 5.4.2.2.12 RailwayType RailwayType Subtype of: Definition: Status: TransportProperty The type of railway transport to which the line is designed for. Proposed

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 74

RailwayType Stereotypes: Attribute: type Value type: Definition: Multiplicity: featureType RailwayTypeValue The type of railway transport to which the line is designed for. 1

Constraint: Applies to railway transport classes only Natural This property can only be associated with a spatial object that is part of a railway language: transport network. OCL: 5.4.2.2.13 RailwayUse RailwayUse Subtype of: Definition: Status: Stereotypes: Attribute: use Value type: Definition: Multiplicity: TransportProperty The current use of the railway. Proposed featureType RailwayUseValue The use of the railway. 1

Constraint: Applies to Railway Transport classes oly Natural This property can only be associated with a spatial object that is part of a railway language: transport network. OCL: 5.4.2.2.14 RailwayYardArea RailwayYardArea Subtype of: Definition: TransportArea An area spatial object which is used to represent the topographical limits of a railway yard. DEFINITION Railway yard: An area crossed by a number of parallel railway tracks (usually more than two) interconnected between them, which are used to stop trains in order to load / unload freight without interrupting the traffic of a main railway line. Proposed featureType

Status: Stereotypes:

5.4.2.2.15 RailwayYardNode RailwayYardNode Subtype of: Definition: RailwayNode A railway node which occurs within a railway yard area. DEFINTION Railway yard: An area crossed by a number of parallel railway tracks (usually more than two) interconnected between them, which are used to stop trains in order to load / unload freight without interrupting the traffic of a main railway line. Proposed featureType

Status: Stereotypes:

Constraint: formOfNode is always RailwayStop Natural For a RailwayYardNode, the value for the "formOfNode" attribute shall always be language: "RailwayStop". OCL:

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 75

5.4.2.3 Enumerations and code lists

class Railw ay Transport Netw ork: Enumerations and Code Lists codeList FormOfRailw ayNodeValue + + + + + junction levelCrossing pseudoNode railwayEnd railwayStop enum eration Railw ayGaugeCategoryValue broad standard narrow notApplicable

codeList Railw ayTypeValue + + + + + + + + cogRailway funicular m agneticLevitation m etro m onorail suspendedRail train tram way + + + +

codeList Railw ayUseValue cargo carShuttle m ixed passengers

enum eration M inM axTrackValue average m axim um m inim um

Figure 23 UML class diagram: Railway Transport Networks Enumerations and Code lists

5.4.2.3.1 MinMaxTrackValue MinMaxTrackValue Definition: Status: Stereotypes: Value: average Definition: Value: maximum Definition: Value: minimum Definition: Values to indicate whether number of tracks are counted as the maximum, minimum or average number. Proposed enumeration The number of tracks is the average value for a given part of the railway network. The number of tracks is the maximum value for a given part of the railway network. The number of tracks is the minimum value for a given part of the railway network.

5.4.2.3.2 RailwayGaugeCategoryValue RailwayGaugeCategoryValue Definition: Status: Stereotypes: Value: broad Definition: Value: standard Definition: Value: narrow Definition: The possible categories of railways concerning its railway gauge. Proposed enumeration The railway gauge property is broader than the standard one. The railway gauge property is equal to the European standard (1435 milimeters). The railway gauge property is narrower than the standard one.

Value: notApplicable

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 76

RailwayGaugeCategoryValue Definition: Description: The definition of a railway gauge property is not applicable to the type of railway transport. EXAMPLE Monorail.

5.4.2.3.3 FormOfRailwayNodeValue FormOfRailwayNodeValue Definition: Status: Stereotypes: Governance: Value: junction Definition: The possible functions of a railway node within the railway network. Proposed codeList Centrally managed in INSPIRE code list register. URN: inspire:def:codeList:INSPIRE:FormOfRailwayNodeValues

urn:x-

A railway node where the railway network have a mechanism consisting on a railroad track with two movable rails and the necessary connections, which let vehicles turn from one track to another.

Value: levelCrossing A railway node where the railway network is a crossed by a road at the same Definition: level. Value: pseudoNode Definition: A railway node which represents a point where one or more attributes of the railway links connected to it change their value, or a point necessary to describe the geometry of the network. Value: railwayEnd Definition: A railway node where the railway starts or ends. The railway network is interrupted at this point. Value: railwayStop A place in the railway network where trains stop to load/unload cargo or to let Definition: passengers get on and off the train. 5.4.2.3.4 RailwayTypeValue RailwayTypeValue Definition: Status: Stereotypes: Governance: The possible types of railway transport. Proposed codeList Centrally managed in INSPIRE code list inspire:def:codeList:INSPIRE:RailwayTypeValues

register.

URN:

urn:x-

Value: cogRailway Definition: A railway transport which allows the vehicles to operate on steep gradients, consisting on a railway provided with a toothed rack rail (usually between the running rails) where vehicles are fitted with one or more cog wheels or pinions that mesh with this rack rail. Description: Synonyms: cog railway, pens and rails railway, rack-and-pinion railway or rack railway. Value: funicular Definition: Description: A railway transport consisting on a cable attached to a vehicle on rails which moves them up and down a very steep slope, where it is possible the ascending and descending vehicles counterbalancing each other. Synonyms: funicular railway, incline, inclined railway, inclined plane or cliff railway.

Value: magneticLevitation Definition: A railway transport based on a single rail which acts as guideway of a vehicle and support it by means of a magnetic levitation mechanism. Value: metro

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 77

RailwayTypeValue Definition: Description: Value: monorail Definition: An urban railway transport system used in large urban areas, which runs on a separate track from other transport systems, is usually electrically powered and in some cases runs under ground. . Synonyms: metro, subway, tube, underground. A railway transport based on a single rail which acts either as its only support and guideway.

Value: suspendedRail A railway transport based on a single rail, acting either as support and guideway, Definition: from which a vehicle is suspended to move along the railway. Value: train Definition: A railway transport usually consisting on two parallel rails on which a poweredvehicle or train machine pulls a connected series of vehicles to move them along the railway in order to transport freight or passengers from one destination to another. A railway transport system used in urban areas, which often runs at street level, sharing road space with motor traffic and pedestrians. Tramways are usually electrically powered.

Value: tramway Definition:

5.4.2.3.5 RailwayUseValue RailwayUseValue Definition: Status: Stereotypes: Governance: Value: cargo Definition: Value: carShuttle Definition: Value: mixed Definition: The possible uses of railways. Proposed codeList Centrally managed in INSPIRE code list inspire:def:codeList:INSPIRE:RailwayUseValues The use of railway is exclusively for cargo operations. The use of railway is exclusively to perform car shuttle transport. The use of railway is mixed. It is used to transport passengers and cargo..

register.

URN:

urn:x-

Value: passengers Definition: The use of railway is exclusively to transport passengers[TWG-TN].

5.4.2.4 Imported types (informative)

This section lists definitions for feature types, data types and enumerations and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references. 5.4.2.4.1 TransportLinkSequence TransportLinkSequence (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] A linear spatial object, composed of an ordered collection of transport links, which represents a continuous path in the transport network without any branches. The element has a defined beginning and end and every position on the transport link sequence is identifiable with one single parameter such as length. It describes an element of the transport network, characterized by one or more thematical identifiers and/or properties.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 78

5.4.2.4.2 TransportLink TransportLink (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] A linear spatial object that describes the geometry and connectivity of a transport network between two points in the network.

5.4.2.4.3 TransportArea TransportArea (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] Surface that represents the spatial extent of an element of a transport network.

5.4.2.4.4 TransportNode TransportNode (abstract) Package: Definition: Description: Common Transport Elements [see section 5.2.2] A point spatial object which is used for connectivity. Nodes are found at either end of the TransportLink.

5.4.2.4.5 TransportProperty TransportProperty (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] A reference to a property that falls upon the network. This property can apply to the whole of the network element it is associated with or - for linear spatial objects - be described using linear referencing.

5.4.2.4.6 TransportLinkSet TransportLinkSet (abstract) Package: Definition: Description: Common Transport Elements [see section 5.2.2] A collection of transport link sequences and or individual transport links that has a specific function or siginificance in a transport network. NOTE This spatial object type supports the aggregation of links to form objects with branches, loops, parallel sequences of links, gaps, etc. EXAMPLE A dual carriageway road, as a collection of the two link sequences that represent each carriageway. 5.4.2.4.7 MinMaxLaneValue MinMaxLaneValue Package: Definition: Description: 5.4.2.4.8 Boolean Boolean Truth [see ISO/TS 19103] Most valuable in the predicate calculus, where items are either True or False, unless they are ill formed. Road Transport Network [see section 5.3.2] Values to indicate whether number of lanes are counted as the maximum, minimum or average number. SOURCE Adapted from [Euroroads].

Package: Definition:

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 79

5.5 Application schema Cable Transport Networks

5.5.1 Description
5.5.1.1 Narrative description
The Cable Transport Networks application schema (Cable Schema) employs a link and node structure to represent the cableways used for transportation of hung vehicles in the form of a linear network. It can play an important role especially in isolated areas having none or difficult access by means of other types of transport (e.g. mountain areas). The Cable Schema inherits classes from the Common Transport Elements application schema, including the possibility to create classes to describe properties of the cableway network and restrictions that can apply to whole sections of the network element or subsections that can be described using linear referencing. This type of network is modelled in a basic way in the specifications. The primary aspects modelled for cableway network elements are: Spatial. Geometric (point and line) representation of various elements that are parts of a network. Typically, the network is handled as a network of connected linear elements (links) with points (nodes) at the ends of the lines (at junctions, cable ends etc). Also real objects with a function in a network may be represented in the dataset. Network connectivity within the cable network is essential but between elements in the other networks is an optional spatial aspect. Temporal. All elements in a network may have a temporal validity (i.e. description of when the network element exists in the real world) and also optional information on when data was entered, modified or deleted in the dataset. Thematic. The Cable Schema can be thematically enriched through the use of Transport Properties as defined in the Common Transport Elements application schema.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 80

5.5.1.2 UML Overview

class Cable Transport Netw ork Ov erv iew LinkSet featureT ype Common Transport Elements:: TransportLinkSet LinkSequence featureT ype Common Transport Elements:: TransportLinkSequence

featureT ype Cablew ayLinkSet

featureT ype Cablew ayLinkSequence

Link featureT ype Common Transport Elements:: TransportLink

Node featureT ype Common Transport Elements:: TransportNode

featureT ype Cablew ayLink

featureT ype Cablew ayNode

Figure 24 UML class diagram: Overview of the Cableway Transport Networks application schema

5.5.1.3 Consistency between spatial data sets

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.3) apply to the corresponding specialized elements/classes in the Cable transport networks.

5.5.1.4 Identifier management

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.4) apply to the corresponding specialized elements/classes in the Cable transport networks.

5.5.1.5 Modelling of object references

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.5) apply to the corresponding specialized elements/classes in the Cable transport networks.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 81

5.5.1.6 Geometry representation

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.6) apply to the corresponding specialized elements/classes in the Cable transport networks.

5.5.1.7 Temporality representation

All attributes describing the lifespan of spatial objects or the phenomena in the real world they describe are inherited from the Common Transport Elements application schema. Refer to section 5.2.1.7 for more information.

5.5.2 Feature catalogue

Table 9 Feature catalogue metadata Feature catalogue name Scope Version number Version date Definition source INSPIRE feature catalogue Cable Transport Network Cable Transport Network 3.0 2009-09-07 INSPIRE data specification Cable Transport Network Table 10 Types defined in the feature catalogue Type CablewayLink CablewayLinkSequence CablewayLinkSet CablewayNode CablewayTypeValue Package Cable Transport Network Cable Transport Network Cable Transport Network Cable Transport Network Cable Transport Network Stereotypes featureType featureType featureType featureType codeList Section 5.5.2.1.1 5.5.2.1.2 5.5.2.1.3 5.5.2.1.4 5.5.2.2.1

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 82

5.5.2.1 Spatial object types

class Cable Transport Netw ork: Spatial obj ect types Link featureT ype Common Transport Elements:: TransportLink voidable + validFrom : DateT im e + validT o: DateT im e [0..1] Node featureT ype Common Transport Elements:: TransportNode voidable + validFrom : DateT im e + validT o: DateT im e [0..1]

featureT ype Cablew ayLink voidable + cablewayT ype: CablewayT ypeValue

featureT ype Cablew ayNode

LinkSet featureT ype Common Transport Elements:: TransportLinkSet voidable + validFrom : DateT im e + validT o: DateT im e [0..1]

LinkSequence featureT ype Common Transport Elements:: TransportLinkSequence voidable + validFrom : DateT im e + validT o: DateT im e [0..1]

featureT ype Cablew ayLinkSet

featureT ype Cablew ayLinkSequence

Figure 25 UML class diagram: Cable Transport Networks Spatial object types

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 83

Figure 26 Overview of the main Cable Transport Networks objects 5.5.2.1.1 CablewayLink CablewayLink Subtype of: Definition: Description: Status: Stereotypes: TransportLink Linear spatial object that describes the geometry and connectivity of a cable network between two points in a cableway transport network. NOTE Cableway transport is a form of transport based on a cable suspended normally from a set of consecutive towers. Proposed featureType

Attribute: cablewayType Value type: CablewayTypeValue Definition: The type of a cableway transport. Multiplicity: 1 Stereotypes: voidable 5.5.2.1.2 CablewayLinkSequence CablewayLinkSequence Subtype of: Definition: Status: Stereotypes: TransportLinkSequence An ordered collection of cableway links that are characterized by one or more thematic identifiers and/or properties. Proposed featureType

5.5.2.1.3 CablewayLinkSet CablewayLinkSet

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 84

CablewayLinkSet Subtype of: Definition: Status: Stereotypes: TransportLinkSet A collection of cableway link sequences and or individual cableway links that has a specific function or significance in a cable transport network. Proposed featureType

5.5.2.1.4 CablewayNode CablewayNode Subtype of: Definition: Status: Stereotypes: TransportNode A point spatial object that is used to represent connectivity between two consecutive cableway links. Proposed featureType

5.5.2.2 Enumerations and code lists

class Cable Transport Netw ork: Enum... codeList Cablew ayTypeValue + + + cabinCableCar chairLift skiT ow

Figure 27 UML class diagram: Cable Transport Networks Enumerations and code lists

5.5.2.2.1 CablewayTypeValue CablewayTypeValue Definition: Status: Stereotypes: Governance: The possible types of cableway transport. Proposed codeList Centrally managed in INSPIRE code list inspire:def:codeList:INSPIRE:CablewayTypeValues

register.

URN:

urn:x-

Value: cabinCableCar A cableway transport whose vehicles consist on a suspended cabin to carry Definition: groups of people and/or goods inside it from one destination to another. Value: chairLift Definition: Description: Value: skiTow Definition: Description: A cableway transport whose vehicles consist on suspended chairs to carry individuals or groups of people from one destination to another via a steel cable or rope which is looped around two points. It Is traditionally found on mountains or steep hills but is being used more and more in amusement parks. A cableway transport is a mechanised system for pulling skiers and snowboarders uphill. Passengers grab hold of the rope and are pulled along while standing on their skis or snowboards and sliding up the hill. Synonyms: rope tow, handle tow.

5.5.2.3 Imported types (informative)

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 85

This section lists definitions for feature types, data types and enumerations and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references. 5.5.2.3.1 TransportLinkSequence TransportLinkSequence (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] A linear spatial object, composed of an ordered collection of transport links, which represents a continuous path in the transport network without any branches. The element has a defined beginning and end and every position on the transport link sequence is identifiable with one single parameter such as length. It describes an element of the transport network, characterized by one or more thematical identifiers and/or properties.

5.5.2.3.2 TransportLink TransportLink (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] A linear spatial object that describes the geometry and connectivity of a transport network between two points in the network.

5.5.2.3.3 TransportNode TransportNode (abstract) Package: Definition: Description: Common Transport Elements [see section 5.2.2] A point spatial object which is used for connectivity. Nodes are found at either end of the TransportLink.

5.5.2.3.4 TransportLinkSet TransportLinkSet (abstract) Package: Definition: Description: Common Transport Elements [see section 5.2.2] A collection of transport link sequences and or individual transport links that has a specific function or siginificance in a transport network. NOTE This spatial object type supports the aggregation of links to form objects with branches, loops, parallel sequences of links, gaps, etc. EXAMPLE A dual carriageway road, as a collection of the two link sequences that represent each carriageway.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 86

5.6 Application schema Water Transport Networks

5.6.1 Description
5.6.1.1 Narrative description
The Water transport network schema employs a link and node structure to represent navigable waterways and ports within water bodies (main marine waterways and ships routeing systems - traffic separation schemes - at the sea, and inland waterways defined across rivers and canals) allowing transportation in the form of a linear network. The water transport network reuse the centreline geometry of the Hydrography themes network (hydrographic network) of rivers and canals as the basis for most inland water transport. However, when this is not enough to describe it properly, specific water transport networks centrelines can also be used (waterway links), in combination to the previous ones, in order to complete the network. The water schema also inherits classes from the Common Transport Schema and also creates its own classes to describe properties of the water network such as water traffic flow direction and any restrictions that can apply to whole sections of the network element or subsections that can be described using linear referencing. The primary aspects modelled for water network elements are: Spatial. Geometric (point, line and area (topographic)) representation of various elements that are parts of a network. Typically, the network is handled as a network of connected linear elements (links) with points (nodes) at the ends of the lines (at junctions, ports etc). Also real objects with a function in a network may be represented in the dataset. Network connectivity within the water network is essential but between elements in the other networks is an optional spatial aspect. Temporal. All elements in a network may have a temporal validity (i.e. description of when the network element exists in the real world) and also optional information on when data was entered, modified or deleted in the dataset. Thematic. The water schema can be thematically displayed via several of the attributes defined within the specification such as CEMTClass.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 87

5.6.1.2 UML Overview

class Water Transport Netw ork Ov erv iew featureT ype TrafficSeparationSchemeSeparator Area featureT ype Common Transport Elements:: TransportArea featureT ype PortArea

featureT ype TrafficSeparationSchemeCrossing

featureT ype Fairw ayArea

featureT ype TrafficSeparationSchemeLane

featureT ype TrafficSeparationSchemeArea

+com ponent 1..*

featureT ype TrafficSeparationScheme

featureT ype TrafficSeparationSchemeRoundabout

0..* +m arker featureT ype Buoy +m arineWaterRoute 0..*

0..* +m arker featureT ype Beacon

LinkSet featureT ype Common Transport Elements:: TransportLinkSet featureT ype Waterway

featureT ype M arineWaterw ay Netw orkElement featureT ype Common Transport Elements:: TransportPoint

featureT ype FerryCrossing

featureT ype InlandWaterw ay

LinkSequence featureT ype Common Transport Elements:: TransportLinkSequence

Link featureT ype Common Transport Elements:: TransportLink

-- Definition -Water T ransport will use the WatercourseLink class provided by the INSPIRE Hydrography Data Specification - wherever posible. HydroObject Link

Node featureT ype Common Transport Elements:: TransportNode

featureT ype WaterLinkSequence

featureT ype Waterw ayLink

featureT ype Hydro - Netw ork:: WatercourseLink

featureT ype WaterNode

featureT ype Waterw ayNode

featureT ype PortNode

Figure 28 UML class diagram: Overview of the Water Transport Networks application schema

5.6.1.3 Consistency between spatial data sets

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.3) apply to the corresponding specialized elements/classes in the Water transport networks.

5.6.1.4 Identifier management

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 88

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.4) apply to the corresponding specialized elements/classes in the Water transport networks.

5.6.1.5 Modelling of object references

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.5) apply to the corresponding specialized elements/classes in the Water transport networks. In particular the Water transport networks theme reuses the existing water network in the Hydrography theme for the majority of the inland Water transport networks geometry. This is a case of object referencing. Requirement 12 The Water transport networks shall use, where it exists and is practicable, object referencing to link the water transport course with the existing water network geometry in the Hydrography theme.

5.6.1.6 Geometry representation

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.6) apply to the corresponding specialized elements/classes in the Water transport networks.

5.6.1.7 Temporality representation

All attributes describing the lifespan of spatial objects or the phenomena in the real world they describe are inherited from the Common Transport Elements application schema. Refer to section 5.2.1.7 for more information.

5.6.2 Feature catalogue

Table 11 Feature catalogue metadata Feature catalogue name Scope Version number Version date Definition source INSPIRE feature catalogue Water Transport Network Water Transport Network 3.0 2009-09-07 INSPIRE data specification Water Transport Network Table 12 Types defined in the feature catalogue Type Beacon Buoy CEMTClass CEMTClassValue ConditionOfWaterFacility FairwayArea FerryCrossing FerryUse Package Water Transport Network Water Transport Network Water Transport Network Water Transport Network Water Transport Network Water Transport Network Water Transport Network Water Transport Network Stereotypes Section featureType 5.6.2.1.1 featureType 5.6.2.1.2 featureType 5.6.2.1.3 enumeration 5.6.2.2.1 featureType 5.6.2.1.4 featureType 5.6.2.1.5 featureType 5.6.2.1.6 featureType 5.6.2.1.7

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 89

Type Package FerryUseValue Water Transport Network FormOfWaterwayNodeValue Water Transport Network InlandWaterway Water Transport Network MarineWaterway Water Transport Network PortArea Water Transport Network PortNode Water Transport Network RestrictionForWaterVehicles Water Transport Network TrafficSeparationScheme Water Transport Network TrafficSeparationSchemeArea Water Transport Network TrafficSeparationSchemeCrossing Water Transport Network TrafficSeparationSchemeLane Water Transport Network TrafficSeparationSchemeRoundabout Water Transport Network TrafficSeparationSchemeSeparator Water Transport Network WaterLinkSequence Water Transport Network WaterNode Water Transport Network WaterTrafficFlowDirection Water Transport Network Waterway Water Transport Network WaterwayLink Water Transport Network WaterwayNode Water Transport Network

Stereotypes Section codeList 5.6.2.2.2 codeList 5.6.2.2.3 featureType 5.6.2.1.8 featureType 5.6.2.1.9 featureType 5.6.2.1.10 featureType 5.6.2.1.11 featureType 5.6.2.1.12 featureType 5.6.2.1.13 featureType 5.6.2.1.14 featureType 5.6.2.1.15 featureType 5.6.2.1.16 featureType 5.6.2.1.17 featureType 5.6.2.1.18 featureType 5.6.2.1.19 featureType 5.6.2.1.20 featureType 5.6.2.1.21 featureType 5.6.2.1.22 featureType 5.6.2.1.23 featureType 5.6.2.1.24

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 90

5.6.2.1 Spatial object types

class Water Transport Netw orks: Spatial obj ect types - Links, Areas and Points featureT ype TrafficSeparationSchemeSeparator Area featureT ype Common Transport Elements::TransportArea voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All objects have inspireId} featureT ype PortArea

featureT ype TrafficSeparationSchemeCrossing

featureT ype Fairw ayArea

featureT ype TrafficSeparationSchemeLane featureT ype TrafficSeparationSchemeArea featureT ype TrafficSeparationSchemeRoundabout 0..* featureT ype M arineWaterw ay voidable + deepWaterRoute: Boolean featureT ype TrafficSeparationScheme

+com ponent 1..*

+m arineWaterRoute

LinkSet featureT ype Common Transport Elements::TransportLinkSet voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All com ponents belong to sam e transport network} {All objects have inspireId} featureT ype Waterway

featureT ype InlandWaterw ay

featureT ype FerryCrossing

LinkSequence featureT ype Common Transport Elements:: TransportLinkSequence voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All com ponents belong to sam e transport network} {All objects have inspireId}

Link featureT ype Common Transport Elements::TransportLink voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All objects have inspireId}

featureT ype WaterLinkSequence

featureT ype Waterw ayLink

Figure 29 UML class diagram: Water Transport Networks Spatial object types Links and Areas

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 91

class Water Transport Netw orks: Spatial obj ect types - Nodes Node featureT ype Common Transport Elements::TransportNode voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All objects have inspireId}

featureT ype WaterNode

featureT ype PortNode

featureT ype Waterw ayNode voidable + form OfWaterwayNode: Form OfWaterwayNodeValue

Figure 30 UML class diagram: Water Transport Networks Spatial object types Nodes
class Water Transport Netw orks: Spatial Obj ect Typ... featureT ype TrafficSeparationScheme

0..* +m arker featureT ype Buoy

0..* +m arker featureT ype Beacon

Netw orkElement featureT ype Common Transport Elements::TransportPoint + geom etry: GM _Point

voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All objects have inspireId}

Figure 31 UML class diagram: Water Transport Networks Spatial object types Transport Points

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 92

class Water Transport Netw orks: Spatial obj ect types - Transport Properties featureT ype ConditionOfWaterFacility

constraints {Applies to PortNode and PortArea only}

featureT ype Common Transport Elements:: ConditionOfFacility + featureT ype FerryUse + ferryUse: FerryUseValue [1..*] Netw orkProperty featureT ype Common Transport Elements:: TransportProperty voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All objects have inspireId} + currentStatus: ConditionOfFacilityValue

featureT ype WaterTrafficFlow Direction

constraints {Applies to WaterwayLink and WaterLinkSequence only}

constraints {Applies to FerryCrossing only}

featureT ype Common Transport Elements:: TrafficFlow Direction direction: LinkDirectionValue

featureT ype CEM TClass + CEM T Class: CEM T ClassValue

constraints {Applies to Link and LinkSequence only}

constraints {Applies to InlandWaterway only} featureT ype Common Transport Elements:: RestrictionForVehicles + + m easure: M easure restrictionT ype: RestrictionT ypeValue

featureT ype RestrictionForWaterVehicles

constraints {Applies to WaterwayLink and WaterwayNode only} {Only 'm axim um Width', 'm axim um Height' and 'm axim um T otalWeight' perm itted}

Figure 32 UML class diagram: Water Transport Networks Spatial object types Transport Properties

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 93

Figure 33 Overview of the main Water Transport Networks objects

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 94

5.6.2.1.1 Beacon

Beacon TransportPoint A prominent specially constructed object forming a conspicuous mark as a fixed aid to navigation, or for use in hydrographic survey. SOURCE [S-32 - IHO International Hydrographic Dictionary]. Proposed featureType

Subtype of: Definition: Description: Status: Stereotypes: 5.6.2.1.2 Buoy Buoy

Subtype of: Definition: Description:

TransportPoint A floating object moored to the bottom in a particular (charted) place, as an aid to navigation or for other specific purposes. SOURCE [S-32 - IHO International Hydrographic Dictionary] NOTE Navigational buoys may be classified according to: (a) their shape, appearance, or construction, such as barrel, can, cask, conical, cylindrical, dan, keg, nun, pillar, spar, spherical, or topmark buoy; (b) their colour, such as black, chequered, green, red buoy; (c) their location, such as bifurcation, fairway, junction, mid-channel, middle-ground, or turning buoy; (d) the various kinds of hazards or dangers to navigation which they mark, such as bar, isolated danger, fish trap, obstruction, spoil ground, telegraph or wreck buoy; (e) their particular purpose or use, such as anchor, anchorage, compass adjustment, dredging, farewell (or landfall), marker, quarantine, station (or watch), or warping buoy. [S32 - IHO International Hydrographic Dictionary]. Proposed featureType

Status: Stereotypes:

5.6.2.1.3 CEMTClass CEMTClass Subtype of: Definition: Status: Stereotypes: TransportProperty Classification of an inland waterway according to CEMT (European Conference of Ministers of Transport). Proposed featureType

Attribute: CEMTClass Value type: CEMTClassValue Definition: Value indicating the classification of an Inland waterway according to CEMT (European Conference of Ministers of Transport). Multiplicity: 1 Constraint: Applies to InlandWaterway only Natural This property can only be associated with a spatial object that is part of a water language: transport network. OCL: 5.6.2.1.4 ConditionOfWaterFacility ConditionOfWaterFacility Subtype of: Definition: Status: Stereotypes: ConditionOfFacility State of a water transport network element with regards to its completion and use. Proposed featureType

Constraint: Applies to PortNode and PortArea only

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 95

ConditionOfWaterFacility Natural language: OCL: This property can only be associated with a spatial object that is part of a water transport network.

5.6.2.1.5 FairwayArea FairwayArea Subtype of: Definition: Description: TransportArea The main travelled part of a waterway. SOURCE [International Hydrographic Dictionary]. NOTE That part of a river, harbour and so on, where the main navigable channel for vessels of larger size lies. It is also the usual course followed by vessels entering or leaving harbours, called 'ship channel' [IHO Hidrographic Registry]. Proposed featureType

Status: Stereotypes:

5.6.2.1.6 FerryCrossing FerryCrossing Subtype of: Definition: Status: Stereotypes: 5.6.2.1.7 FerryUse FerryUse Subtype of: Definition: Status: Stereotypes: TransportProperty The type of transport carried out by a ferry crossing. Proposed featureType Waterway A special waterway aimed at supporting the transport of passengers, vehicles or other cargo/freight across a water body, and which is normally used as a connection linking two or more nodes of a land based transport network. Proposed featureType

Attribute: ferryUse Value type: FerryUseValue Definition: Value indicating the type of transport carried out by a ferry crossing. Multiplicity: 1..* Constraint: Applies to FerryCrossing only Natural This property can only be associated with a spatial object that is part of a water language: transport network. OCL: 5.6.2.1.8 InlandWaterway InlandWaterway Subtype of: Definition: Description: Status: Stereotypes: Waterway Waterway which is defined at inland continental waters. EXAMPLE The inland waterways classified by the CEMT (European Conference of Ministers of Transport). Proposed featureType

5.6.2.1.9 MarineWaterway MarineWaterway Subtype of: Definition: Status: Waterway Waterway which is defined at sea waters. Proposed

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 96

MarineWaterway Stereotypes: featureType Attribute: deepWaterRoute Value type: Boolean Definition: Attribute which indicates if the maritime waterway is a deep water route. DEFINITION Deep water route: A route in a designated area within defined limits which has been accurately surveyed for clearance of sea bottom and submerged obstacles to a minimum indicated depth of water [S-32 - IHO International Hydrographic Dictionary]. Multiplicity: 1 Stereotypes: voidable 5.6.2.1.10 PortArea PortArea Subtype of: Definition: Status: Stereotypes: 5.6.2.1.11 PortNode PortNode Subtype of: Definition: Description: Status: Stereotypes: WaterNode A point spatial object which is used to represent a sea or inland port in a simplified way, aproximately located at the bank of the waterbody where the port is placed. NOTE It is used to connect the port with the rest of the water transport network, by means of the different waterway links which arrive to / depart from it. Proposed featureType TransportArea An area spatial object which is used to represent the physical limits of all the facilities which constitute the terrestrial zone of a sea or inland port. Proposed featureType

5.6.2.1.12 RestrictionForWaterVehicles RestrictionForWaterVehicles Subtype of: Definition: Status: Stereotypes: RestrictionForVehicles Restriction on vehicles on a water transport element. Proposed featureType

Constraint: Applies to WaterwayLink and WaterwayNode only Natural This property can only be associated with a spatial object that is part of a water language: transport network. OCL: Constraint: Only 'maximumWidth', 'maximumHeight' and 'maximumTotalWeight' permitted Natural This property can only be associated with a spatial object that is part of a water language: transport network. OCL: 5.6.2.1.13 TrafficSeparationScheme TrafficSeparationScheme (abstract) Definition: A scheme which aims at reducing the risk of collision in congested and/or converging areas by separating traffic moving in opposite, or nearly opposite, directions.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 97

TrafficSeparationScheme (abstract) Description: SOURCE [S-32 - IHO International Hydrographic Dictionary] NOTE 1 Acronym: TSS. NOTE 2 TSSs constitute main components of maritime routing measures for hydrographic transport. Proposed featureType

Status: Stereotypes:

Association role: component Value type: TrafficSeparationSchemeArea Definition: A component of a traffic separation scheme. Multiplicity: 1..* Association role: marker Value type: Buoy Definition: A marker forming part of a traffic separation scheme. Multiplicity: 0..* Association role: marineWaterRoute Value type: MarineWaterway Definition: The collection of marine waterways associated with a traffic separation scheme. Multiplicity: 0..* Association role: marker Value type: Beacon Definition: A marker forming part of a traffic separation scheme. Multiplicity: 0..* 5.6.2.1.14 TrafficSeparationSchemeArea TrafficSeparationSchemeArea (abstract) Subtype of: Definition: Status: Stereotypes: TransportArea An area spatial object forming part of a traffic seperation scheme. Proposed featureType

5.6.2.1.15 TrafficSeparationSchemeCrossing TrafficSeparationSchemeCrossing Subtype of: Definition: Description: Status: Stereotypes: TrafficSeparationSchemeArea A defined area where traffic lanes cross. SOURCE [IHO Hydrographic Registry]. Proposed featureType

5.6.2.1.16 TrafficSeparationSchemeLane TrafficSeparationSchemeLane Subtype of: Definition: Description: Status: Stereotypes: TrafficSeparationSchemeArea An area within defined limits in which one-way traffic flow is established. SOURCE [IMO Ships Routeing, 6th Edition], [IHO Hydrographic Registry]. Proposed featureType

5.6.2.1.17 TrafficSeparationSchemeRoundabout TrafficSeparationSchemeRoundabout Subtype of: Definition: TrafficSeparationSchemeArea A traffic separation scheme in which traffic moves in a counter-clockwise direction around a specified point or zone.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 98

TrafficSeparationSchemeRoundabout Description: Status: Stereotypes: SOURCE [IHO Hydrographic Registry]. Proposed featureType

5.6.2.1.18 TrafficSeparationSchemeSeparator TrafficSeparationSchemeSeparator Subtype of: Definition: Description: Status: Stereotypes: TrafficSeparationSchemeArea A zone separating the lanes in which ships are proceeding in opposite or nearly opposite directions; or separating traffic lanes designated for particular classes of ships proceeding in the same direction. SOURCE [IHO Hydrographic Registry]. Proposed featureType

5.6.2.1.19 WaterLinkSequence WaterLinkSequence Subtype of: Definition: Description: TransportLinkSequence A linear spatial object, composed of an ordered collection of waterway and/or watercourse links (as necessary), which represents a continuous path in the water network without any branches. NOTE The element has a defined beginning and end and every position on the water link sequence is identifiable with one single parameter such as length. It describes a element of the water network, which is a navigable path within a water body (oceans, seas, rivers, lakes, channels or canals) and could be characterized by one or more thematical identifiers and/or properties. Proposed featureType

Status: Stereotypes:

5.6.2.1.20 WaterNode WaterNode (abstract) Subtype of: Definition: Description: Status: Stereotypes: TransportNode A point spatial object which is used to represent the connectivity between two different waterway links, or between a waterway link and a watercourse link, in the water transport network. NOTE It is also used to represent a significant feature in the network, such as a port. Proposed featureType

5.6.2.1.21 WaterTrafficFlowDirection WaterTrafficFlowDirection Subtype of: Definition: Status: Stereotypes: TrafficFlowDirection Indicates the direction of the flow of water transport traffic in relation to the direction of the water transport link vector. Proposed featureType

Constraint: Applies to WaterwayLink and WaterLinkSequence only Natural This property can only be associated with a spatial object that is part of a water language: transport network. OCL: 5.6.2.1.22 Waterway Waterway (abstract) Subtype of: TransportLinkSet

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 99

Waterway (abstract) Definition: A collection of water link sequences and or individual waterway and/or watercourse links (as necessary) that are characterized by one or more thematical identifiers and/or properties, which perform a navigable route within a water body (oceans, seas, rivers, lakes, channels or canals). Proposed featureType

Status: Stereotypes:

5.6.2.1.23 WaterwayLink WaterwayLink Subtype of: Definition: Description: Status: Stereotypes: TransportLink A linear spatial object that describes the geometry or connectivity of the water transport network between two consecutive waterway or watercourse nodes. It represents a linear section across a body of water which is used for shipping. NOTE Water Transport Networks will use the WatercourseLink class - provided by the INSPIRE Hydrography Data Specification - wherever possible. Proposed featureType

5.6.2.1.24 WaterwayNode WaterwayNode Subtype of: Definition: Status: Stereotypes: WaterNode A point spatial object which is used to represent the connectivity between two different waterway links, or between a waterway link and a watercourse link, in the water transport network. Proposed featureType

Attribute: formOfWaterwayNode Value type: FormOfWaterwayNodeValue Definition: Description of the function of a waterway node in the water transport network. Multiplicity: 1 Stereotypes: voidable

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 100

5.6.2.2 Enumerations and code lists

class Water Transport Netw ork: Enumerations and Code lists enum eration CEM TClassValue I II III IV Va Vb VIa VIb VIc VII + + + + + codeList FerryUseValue cars other passengers train trucks

codeList FormOfWaterw ayNodeValue + + + + + + junctionFork lockCom plex m ovableBridge shipLift term inal turningBasin

Figure 34 UML class diagram: Water Transport Networks Enumerations and code lists

5.6.2.2.1 CEMTClassValue CEMTClassValue Definition: Status: Stereotypes: Value: I Definition: Value: II Definition: Value: III Definition: Value: IV Definition: Value: Va Definition: Value: Vb Definition: Value: VIa Definition: Value: VIb Definition: Inland waterway classification according to CEMT (European Conference of Ministers of Transport) Resolution No.92/2. Proposed enumeration Inland waterway belonging to CEMT-class I, defined by the European Conference of Ministers of Transport, Resolution No.92/2 - Table 1. Inland waterway belonging to CEMT-class II, defined by the European Conference of Ministers of Transport, Resolution No.92/2 - Table 1. Inland waterway belonging to CEMT-class III, defined by the European Conference of Ministers of Transport, Resolution No.92/2 - Table 1. Inland waterway belonging to CEMT-class IV, defined by the European Conference of Ministers of Transport, Resolution No.92/2 - Table 1. Inland waterway belonging to CEMT-class Va, defined by the European Conference of Ministers of Transport, Resolution No.92/2 - Table 1. Inland waterway belonging to CEMT-class Vb, defined by the European Conference of Ministers of Transport, Resolution No.92/2 - Table 1. Inland waterway belonging to CEMT-class VIa, defined by the European Conference of Ministers of Transport, Resolution No.92/2 - Table 1. Inland waterway belonging to CEMT-class VIb, defined by the European Conference of Ministers of Transport, Resolution No.92/2 - Table 1.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 101

CEMTClassValue Value: VIc Definition: Value: VII Definition:

Inland waterway belonging to CEMT-class VIc, defined by the European Conference of Ministers of Transport, Resolution No.92/2 - Table 1. Inland waterway belonging to CEMT-class VII, defined by the European Conference of Ministers of Transport, Resolution No.92/2 - Table 1.

5.6.2.2.2 FerryUseValue FerryUseValue Definition: Status: Stereotypes: Governance: Value: cars Definition: Value: other Definition: Types of transport carried out by a ferry. Proposed codeList Centrally managed in INSPIRE code inspire:def:codeList:INSPIRE:FerryUseValue Ferry carries cars. Ferry carries others forms of transport than passengers, cars, trucks or trains.

list

register.

URN:

urn:x-

Value: passengers Definition: Ferry carries passengers. Value: train Definition: Value: trucks Definition: Ferry carries trains. Ferry carries trucks.

5.6.2.2.3 FormOfWaterwayNodeValue FormOfWaterwayNodeValue Definition: Status: Stereotypes: Governance: Function of a WaterwayNode in the water transport network. Proposed codeList Centrally managed in INSPIRE code list register. inspire:def:codeList:INSPIRE:FormOfWaterwayNodeValue

URN:

urn:x-

Value: junctionFork Definition: Infrastructure elements where the one vessel traffic flow crosses another vessel traffic flow or points where vessel traffic flows divide or come together. Description: SOURCE [COMPRIS]. Value: lockComplex Definition: Lock or group of locks, intended for raising and lowering boats between stretches of water of different levels on river and canal waterways. Value: movableBridge Definition: Bridge that can be raised or turned to allow the passage of ships. Value: shipLift Definition: Description: Value: terminal Definition: Description: A machine for transporting boats between water bodies at two different elevations, which is used as an alternative to the canal locks.. NOTE Synonyms: boat lift, lift lock. The location where goods are transhipped. SOURCE [COMPRIS]. NOTE A terminal forms a link between the various transport modes, of which shipping is one. A terminal therefore has waterside loading and unloading places [COMPRIS].

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 102

FormOfWaterwayNodeValue Value: turningBasin A place where a canal or narrow waterway is widened to allow boats to turn Definition: around.

5.6.2.3 Imported types (informative)

This section lists definitions for feature types, data types and enumerations and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references. 5.6.2.3.1 TransportLinkSequence TransportLinkSequence (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] A linear spatial object, composed of an ordered collection of transport links, which represents a continuous path in the transport network without any branches. The element has a defined beginning and end and every position on the transport link sequence is identifiable with one single parameter such as length. It describes an element of the transport network, characterized by one or more thematical identifiers and/or properties.

5.6.2.3.2 RestrictionForVehicles RestrictionForVehicles Package: Definition: Common Transport Elements [see section 5.2.2] Restriction on vehicles on a transport element.

5.6.2.3.3 TrafficFlowDirection TrafficFlowDirection Package: Definition: Common Transport Elements [see section 5.2.2] Indicates the direction of the flow of traffic in relation to the direction of the transport link vector.

5.6.2.3.4 TransportLink TransportLink (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] A linear spatial object that describes the geometry and connectivity of a transport network between two points in the network.

5.6.2.3.5 ConditionOfFacility ConditionOfFacility Package: Definition: Common Transport Elements [see section 5.2.2] State of a transport network element with regards to its completion and use.

5.6.2.3.6 TransportArea TransportArea (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] Surface that represents the spatial extent of an element of a transport network.

5.6.2.3.7 TransportNode TransportNode (abstract) Package: Definition: Description: Common Transport Elements [see section 5.2.2] A point spatial object which is used for connectivity. Nodes are found at either end of the TransportLink.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 103

5.6.2.3.8 TransportProperty TransportProperty (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] A reference to a property that falls upon the network. This property can apply to the whole of the network element it is associated with or - for linear spatial objects - be described using linear referencing.

5.6.2.3.9 TransportLinkSet TransportLinkSet (abstract) Package: Definition: Description: Common Transport Elements [see section 5.2.2] A collection of transport link sequences and or individual transport links that has a specific function or siginificance in a transport network. NOTE This spatial object type supports the aggregation of links to form objects with branches, loops, parallel sequences of links, gaps, etc. EXAMPLE A dual carriageway road, as a collection of the two link sequences that represent each carriageway. 5.6.2.3.10 TransportPoint TransportPoint (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] A point spatial object - which is not a node - that represents the position of an element of a transport network.

5.7 Application schema Air Transport Networks

5.7.1 Description
5.7.1.1 Narrative description
The Air Transport Networks application schema (Air Schema) employs a link and node structure to represent the Air routes used for transportation in the form of a linear network. The Air Schema inherits classes from the Common Transport Schema and also creates its own classes to describe properties of the air network such as air route type and restrictions that can apply to whole sections of the network element or subsections that can be described using linear referencing. The primary aspects modelled for air network elements are: Spatial. Geometric (point, line and area (topographic)) representation of various elements that are parts of a network. Typically, the network is handled as a network of connected linear elements (links) with points (nodes) at the air route junctions (usually over the position of significant points, such as navigation aids and designated points) or at the ends of the lines (at aerodromes airports or heliports). Also real objects with a function in a network may be represented in the dataset. Network connectivity within the roads and rail networks (where this exists) is essential but between elements in the other networks is an optional spatial aspect. Temporal. All elements in a network may have a temporal validity (i.e. description of when the network element exists in the real world) and also optional information on when data was entered, modified or deleted in the dataset. Thematic. The air schema can be thematically displayed via several of the attributes defined within the specification such as altitude.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 104

Please Note: The ControlTower feature has been inserted as a Placeholder in this version of the Transport Networks data specification (v3.0.1) for future population by the INSPIRE "Buildings" theme when the "[AppSchemaName]" should be updated. This affects the relevant entry in Table 14 and and in section 5.7.2.1.13.

INSPIRE TWG-TN

class Air Transport Netw ork Ov erv iew featureT ype Runw ayArea featureT ype Taxiw ayArea Area

5.7.1.2 UML Overview

featureT ype AerodromeArea

featureT ype AirspaceArea featureT ype ApronArea

featureT ype Common Transport Elements:: TransportArea

LinkSet featureT ype Common Transport Elements:: TransportLink featureT ype Common Transport Elements:: TransportNode

LinkSequence

Link

Node

featureT ype Common Transport Elements:: TransportLinkSet

featureT ype Common Transport Elements:: TransportLinkSequence

featureT ype Nav aid

featureT ype AirRoute

featureT ype AirLinkSequence

featureT ype AirLink

featureT ype AirNode

featureT ype DesignatedPoint

featureT ype Runw ayCentrelinePoint featureT ype AirRouteLink featureT ype ProcedureLink featureT ype TouchDow nLiftOff featureT ype AerodromeNode 1 0..* placeholder ControlTow er

Figure 35 UML class diagram: Overview of the Air Transport Networks application schema
featureT ype InstrumentApproachProcedure featureT ype StandardInstrumentArriv al

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 105

featureT ype StandardInstrumentDeparture

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 106

5.7.1.3 Consistency between spatial data sets

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.3) apply to the corresponding specialized elements/classes in the Air transport networks.

5.7.1.4 Identifier management

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.4) apply to the corresponding specialized elements/classes in the Air transport networks.

5.7.1.5 Modelling of object references

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.5) apply to the corresponding specialized elements/classes in the Air transport networks.

5.7.1.6 Geometry representation

All requirements and recommendations on transport networks, defined in the Common Transport Elements application schema (see section 5.2.1.6) apply to the corresponding specialized elements/classes in the Air transport networks.

5.7.1.7 Temporality representation

All attributes describing the lifespan of spatial objects or the phenomena in the real world they describe are inherited from the Common Transport Elements application schema. Refer to section 5.2.1.7 for more information.

5.7.2 Feature catalogue

Table 13 Feature catalogue metadata Feature catalogue name Scope Version number Version date Definition source INSPIRE feature catalogue Air Transport Network Air Transport Network 3.0 2009-09-07 INSPIRE data specification Air Transport Network Table 14 Types defined in the feature catalogue Type AerodromeArea AerodromeCategory AerodromeCategoryValue AerodromeNode AerodromeType AerodromeTypeValue AirLink AirLinkSequence AirNode Package Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Stereotypes featureType featureType codeList featureType featureType codeList featureType featureType featureType Section 5.7.2.1.1 5.7.2.1.2 5.7.2.2.1 5.7.2.1.3 5.7.2.1.4 5.7.2.2.2 5.7.2.1.5 5.7.2.1.6 5.7.2.1.7

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 107

Type AirRoute AirRouteLink AirRouteLinkClassValue AirRouteTypeValue AirspaceArea AirspaceAreaTypeValue AirUseRestrictionValue ApronArea ConditionOfAirFacility DesignatedPoint ElementLength ElementWidth FieldElevation InstrumentApproachProcedure LowerAltitudeLimit Navaid NavaidTypeValue PointRoleValue ProcedureLink RunwayArea RunwayCentrelinePoint RunwayTypeValue StandardInstrumentArrival StandardInstrumentDeparture SurfaceComposition SurfaceCompositionValue TaxiwayArea TouchDownLiftOff UpperAltitudeLimit useRestriction ControlTower

Package Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Air Transport Network Buildings

Stereotypes featureType featureType codeList codeList featureType codeList codeList featureType featureType featureType featureType featureType featureType featureType featureType featureType codeList codeList featureType featureType featureType codeList featureType featureType featureType codeList featureType featureType featureType featureType placeholder,featureType

Section 5.7.2.1.8 5.7.2.1.9 5.7.2.2.3 5.7.2.2.4 5.7.2.1.10 5.7.2.2.5 5.7.2.2.6 5.7.2.1.11 5.7.2.1.12 5.7.2.1.13 5.7.2.1.14 5.7.2.1.15 5.7.2.1.16 5.7.2.1.17 5.7.2.1.18 5.7.2.1.19 5.7.2.2.7 5.7.2.2.8 5.7.2.1.20 5.7.2.1.21 5.7.2.1.22 5.7.2.2.9 5.7.2.1.23 5.7.2.1.24 5.7.2.1.25 5.7.2.2.10 5.7.2.1.26 5.7.2.1.27 5.7.2.1.28 5.7.2.1.29 5.7.2.3.1

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 108

5.7.2.1 Spatial object types

class Air Transport Netw ork: Spatial obj ect types - Links and Areas featureT ype Runw ayArea voidable + designator: CharacterString + runwayT ype: RunwayT ypeValue

featureT ype AirspaceArea + AirspaceAreaT ype: AirspaceAreaT ypeValue

featureT ype AerodromeArea

Area featureT ype Common Transport Elements::TransportArea voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All objects have inspireId}

featureT ype Taxiw ayArea voidable + designator: CharacterString

featureT ype ApronArea

LinkSet featureT ype Common Transport Elements::TransportLinkSet voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All com ponents belong to sam e transport network} {All objects have inspireId}

LinkSequence featureT ype Common Transport Elements:: TransportLinkSequence voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All com ponents belong to sam e transport network} {All objects have inspireId}

Link featureT ype Common Transport Elements::TransportLink voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All objects have inspireId}

featureT ype AirRoute voidable + airRouteT ype: AirRouteT ypeValue + designator: CharacterString

featureT ype AirLinkSequence

featureT ype AirLink

featureT ype ProcedureLink

featureT ype AirRouteLink voidable + airRouteLinkClass: AirRouteLinkClassValue

featureT ype StandardInstrumentDeparture voidable + designator: CharacterString

featureT ype InstrumentApproachProcedure

featureT ype StandardInstrumentArriv al voidable + designator: CharacterString

Figure 36 UML class diagram: Air Transport Networks Spatial object types Links and Areas

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 109

class Air Transport Netw ork: Spatial obj ect types - Nodes Node featureT ype Common Transport Elements:: TransportNode voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All objects have inspireId} placeholder ControlTow er

featureT ype Nav aid voidable + designator: CharacterString + navaidT ype: NavaidT ypeValue

+controlT owers voidable +airport/heliport voidable

0..*

featureT ype AirNode featureT ype DesignatedPoint voidable + designator: CharacterString featureT ype TouchDow nLiftOff + significantPoint: Boolean

featureT ype AerodromeNode voidable + designatorIAT A: CharacterString + locationIndicatorICAO: CharacterString

featureT ype Runw ayCentrelinePoint + pointRole: PointRoleValue

voidable + designator: CharacterString

Figure 37 UML class diagram: Air Transport Networks Spatial object types - Nodes
class Air Transport Netw ork: Spatial obj ect types - Transport Properties featureT ype ConditionOfAirFacility

constraints {Applies only to Aerodrom eNode, Aerodrom eArea and RunwayArea}

featureT ype UpperAltitudeLimit + altitude: M easure +

featureT ype Common Transport Elements:: ConditionOfFacility currentStatus: ConditionOfFacilityValue

featureT ype AerodromeCategory + aerodrom eCategory: Aerodrom eCategoryValue

constraints {Applies to AirRouteLink and AirspaceArea only}

constraints {Applies to Aerodrom eNode and Aerodrom eArea only}

featureT ype FieldElev ation + altitude: M easure

featureT ype ElementWidth Netw orkProperty featureT ype Common Transport Elements:: TransportProperty voidable + validFrom : DateT im e + validT o: DateT im e [0..1] constraints {All objects have inspireId} + width: M easure

constraints {Applies to Aerodrom eNode and Aerodrom eArea only}

constraints {Applies to RunwayArea, TaxiwayArea and T ouchDownLiftOff only}

featureT ype ElementLength + length: M easure

featureT ype Low erAltitudeLimit + altitude: M easure

constraints {Applies to RunwayArea, TaxiwayArea and T ouchDownLiftOff only}

constraints {Applies to AirRouteLink and AirspaceArea only} featureT ype useRestriction featureT ype AerodromeType + aerodrom eT ype: Aerodrom eT ypeValue + restriction: AirUseRestrictionValue

constraints {Applies to AirRoute, AirLinks, AirNodes and Aerodrom eArea only}

constraints {Applies to Aerodrom eNode and Aerodrom eArea only}

featureT ype SurfaceComposition + surfaceCom position: SurfaceCom positionValue

constraints {Applies to RunwayArea, T axiwayArea, ApronArea and T ouchDowhLiftOff only}

Figure 38 UML class diagram: Air Transport Networks Spatial object types Transport Properties

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 110

Figure 39 Overview of the main Air Transport Networks objects 5.7.2.1.1 AerodromeArea AerodromeArea Subtype of: Definition: Description: TransportArea A defined area on land or water (including any buildings, installations and equipment) intended to be used either wholly or in part for the arrival, departure and surface movement of aircraft and/or helicopters. SOURCE [AIXM5.0]. NOTE An area spatial object which is used to represent the physical limits of all the facilities which form part of an inland aerodrome. Proposed featureType

Status: Stereotypes:

5.7.2.1.2 AerodromeCategory AerodromeCategory Subtype of: Definition: Status: Stereotypes: TransportProperty Aerodrome category concerning the scope and importance of the air traffic services offered from and to it. Proposed featureType

Attribute: aerodromeCategory Value type: AerodromeCategoryValue Definition: Value which indicates the category of an aerodrome. Multiplicity: 1

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 111

AerodromeCategory Constraint: Applies to AerodromeNode and AerodromeArea only Natural This property can only be associated with a spatial object that is an Aerodrome language: Node or an Aerodrome Area. OCL: 5.7.2.1.3 AerodromeNode AerodromeNode Subtype of: Definition: AirNode Node located at the aerodrome reference point of an airport/heliport, which is used to represent it in a simplified way. DEFINITION Aerodrome Reference Point (ARP): The designated geographical location of an aerodrome, located near the initial or planned geometric centre of the aerodrome and normally remaining where originally established [AIXM3.3]. DEFINITION Airport/heliport: A defined area on land or water (including any buildings, installations and equipment) intended to be used either wholly or in part for the arrival, departure and surface movement of aircraft/helicopters [AIXM5.0]. SOURCE [AIXM5.0]. Proposed featureType

Description: Status: Stereotypes:

Attribute: designatorIATA Value type: CharacterString Definition: The three letter IATA designator of the aerodrome (airport/heliport). Description: SOURCE [AIXM5.0]. Multiplicity: 1 Stereotypes: voidable Attribute: locationIndicatorICAO Value type: CharacterString Definition: The four letter ICAO location indicator of the aerodrome (airport/heliport), as listed in ICAO DOC 7910. Description: SOURCE [AIXM5.0]. Multiplicity: 1 Stereotypes: voidable Association role: controlTowers Value type: ControlTower Definition: The set of control towers belonging to an aerodrome (airport/heliport). Multiplicity: 0..* Stereotypes: voidable 5.7.2.1.4 AerodromeType AerodromeType Subtype of: Definition: Description: Status: Stereotypes: TransportProperty A code specifying the type of aerodrome. SOURCE [AIXM5.0]. EXAMPLE Aerodrome only, combined aerodrome/heliport or simple landing site. Proposed featureType

Attribute: aerodromeType Value type: AerodromeTypeValue Definition: The type of aerodrome. Multiplicity: 1 Constraint: Applies to AerodromeNode and AerodromeArea only

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 112

AerodromeType Natural language: OCL: 5.7.2.1.5 AirLink AirLink (abstract) Subtype of: Definition: Status: Stereotypes: TransportLink A linear spatial object that describes the geometry and connectivity of the air network between two points in the network. Proposed featureType This property can only be associated with a spatial object that is an Aerodrome Node or Aerodrome Area.

5.7.2.1.6 AirLinkSequence AirLinkSequence Subtype of: Definition: Description: TransportLinkSequence A linear spatial object, composed of an ordered collection of air links, which represents a continuous path in the air network without any branches. NOTE 1 The element has a defined beginning and end and every position on the air link sequence is identifiable with one single parameter such as length. It describes an element of the air network, which could be characterized by one or more thematical identifiers and/or properties. NOTE 2 This collection of air links is equivalent to RoutePortion feature in AIXM5.0. RoutePortion: A group of two or more consecutive segments of the same route, which have the usage and/or the same flight restrictions [AIXM5.0]. Proposed featureType

Status: Stereotypes: 5.7.2.1.7 AirNode AirNode (abstract) Subtype of: Definition: Status: Stereotypes:

TransportNode A node which occurs in a air network. Proposed featureType

Attribute: significantPoint Value type: Boolean Attribute which indicates whether the air node is or is not a significant point. Definition: DEFINITION Significant point: A specified geographical location used to define an ATS route, the flight path of an aircraft or for other navigation/ATS purposes [AIXM5.0]. Description: NOTE Significant Points are specific air nodes which normally define air routes. Multiplicity: 1 5.7.2.1.8 AirRoute AirRoute Subtype of: Definition: Description: TransportLinkSet A specified route designed for channelling the flow of traffic as necessary for the provision of air traffic services, from the end of the take-off and initial climb phase to the commencement of the approach and landing phase. SOURCE [Route - AIXM5.0]. NOTE A collection of air link sequences and or individual air links that are characterized by one or more thematic identifiers and /or properties, which perform a Route. Proposed

Status:

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 113

AirRoute Stereotypes: featureType Attribute: airRouteType Value type: AirRouteTypeValue Definition: Route classification. Description: SOURCE [AIXM5.0]. Multiplicity: 1 Stereotypes: voidable Attribute: designator Value type: CharacterString Definition: Code or designator that identifies an Air Route. Multiplicity: 1 Stereotypes: voidable 5.7.2.1.9 AirRouteLink AirRouteLink Subtype of: Definition: Description: AirLink A portion of a route to be flown usually without an intermediate stop, as defined by two consecutive significant points. SOURCE [AirRouteSegment - AIXM5.0]. NOTE The presence of air nodes (normally defining Significant Points) is not mandated. Proposed featureType

Status: Stereotypes:

Attribute: airRouteLinkClass Value type: AirRouteLinkClassValue Definition: The class or type of an AirRouteLink. Multiplicity: 1 Stereotypes: voidable 5.7.2.1.10 AirspaceArea AirspaceArea Subtype of: Definition: Description: TransportArea A defined volume in the air, described as horizontal projection with vertical limits. SOURCE [AirspaceVolume - AIXM5.0]. NOTE 1 Definition of Airspace: A defined three dimensional region of space relevant to air traffic [AIXM5.0]. NOTE 2 Airspace regions are managed by air traffic control systems to provide a safe IFR (Instrument Flight Rules) navigation for air traffic services and aircrafts. Proposed featureType

Status: Stereotypes:

Attribute: AirspaceAreaType Value type: AirspaceAreaTypeValue Definition: A code indicating the general structure or characteristics of a particular airspace. Description: SOURCE [Airspace.type - AIXM5.0]. Multiplicity: 1 5.7.2.1.11 ApronArea ApronArea Subtype of: TransportArea

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 114

ApronArea Definition: Description: Status: Stereotypes: A defined area, on a land aerodrome/heliport, intended to accommodate aircraft/helicopters for purposes of loading and unloading passengers, mail or cargo, and for fuelling, parking or maintenance. SOURCE [Apron - AIXM5.0]. Proposed featureType

5.7.2.1.12 ConditionOfAirFacility ConditionOfAirFacility Subtype of: Definition: Status: Stereotypes: ConditionOfFacility State of an air transport network element with regards to its completion and use. Proposed featureType

Constraint: Applies only to AerodromeNode, AerodromeArea and RunwayArea Natural This property can only be associated with a spatial object that is an Aerodrome language: Node, an Aerodrome Area or a Runway Area. OCL: 5.7.2.1.13 DesignatedPoint DesignatedPoint Subtype of: Definition: Description: AirNode A geographical location not marked by the site of a radio navigation aid, used in defining an ATS route, the flight path of an aircraft or for other navigation or ATS purposes. SOURCE [AIXM5.0]. NOTE Examples of Designated points are compulsory and non-compulsory reporting points. Proposed featureType

Status: Stereotypes:

Attribute: designator Value type: CharacterString Definition: The coded designator of the point. Description: SOURCE [AIXM5.0]. Multiplicity: Stereotypes: EXAMPLE The five-letter ICAO name of the point. 1 voidable

5.7.2.1.14 ElementLength ElementLength Subtype of: Definition: Status: Stereotypes: Attribute: length Value type: Definition: TransportProperty The physical length of the element. Proposed featureType Measure The physical length of the element.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 115

ElementLength Description: NOTE 1 The value of the physical length of the runway [AIXM5.0], when applied to RunwayArea. NOTE 2 Value for the length of the taxiway [AIXM5.0], when applied to TaxiwayArea. NOTE 3 The value of the physical length of the touchdown and lift-off area [AIXM5.0], when applied to TouchDownLiftOff. 1

Multiplicity:

Constraint: Applies to RunwayArea, TaxiwayArea and TouchDownLiftOff only Natural This property can only be associated with a spatial object that is a Runway Area, language: Taxiway Area or TouchDownLiftOff. OCL: 5.7.2.1.15 ElementWidth ElementWidth Subtype of: Definition: Status: Stereotypes: Attribute: width Value type: Definition: Description: TransportProperty The physical width of the element. Proposed featureType Measure The physical width of the element. NOTE 1 The value of the physical width of the runway [AIXM5.0], when applied to RunwayArea. NOTE 2 The value of the physical width of the taxiway [AIXM5.0], when applied to TaxiwayArea. NOTE 3 The value of the physical width of the touchdown and lift-off area [AIXM5.0], when applied to TouchDownLiftOff. 1

Multiplicity:

Constraint: Applies to RunwayArea, TaxiwayArea and TouchDownLiftOff only Natural This property can only be associated with a spatial object that is a Runway Area, language: Taxiway Area or TouchDownLiftOff. OCL: 5.7.2.1.16 FieldElevation FieldElevation Subtype of: Definition: Description: TransportProperty The aerodrome elevation as the vertical distance between the highest point of the landing area of an aerodrome and mean sea level. SOURCE [AIXM5.0]. NOTE This might be different from the elevation of the Aerodrome Reference Point. Proposed featureType Measure Value of the field altitude. 1

Status: Stereotypes: Attribute: altitude Value type: Definition: Multiplicity:

Constraint: Applies to AerodromeNode and AerodromeArea only

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 116

FieldElevation Natural language: OCL: This property can only be associated with a spatial object that is an Aerodrome Node or Aerodrome Area.

5.7.2.1.17 InstrumentApproachProcedure InstrumentApproachProcedure Subtype of: Definition: ProcedureLink A series of predetermined manoeuvres by reference to flight instruments with specified protection from obstacles from the initial approach fix, or where applicable, from the beginning of a defined arrival route to a point from which a landing can be completed and thereafter, if a landing is not completed, to a position at which holding or en route obstacle clearance criteria apply. SOURCE [AIXM5.0]. NOTE 1 Acronym: IAP. NOTE 2 It corresponds to the final approach and arrival during the landing phase. NOTE 3 A specific runway of an airport/heliport usually has more than one IAP, depending on the landing direction on it. Proposed featureType

Description:

Status: Stereotypes:

5.7.2.1.18 LowerAltitudeLimit LowerAltitudeLimit Subtype of: Definition: Description: Status: Stereotypes: Attribute: altitude Value type: Definition: Multiplicity: TransportProperty Altitude that defines the lower limit of an air transport network object. NOTE When applied to an AirRouteLink it corresponds to the Lowest Safe Altitude, which is defined in order to provide safety for navigation. Proposed featureType Measure Value of the altitude limit. 1

Constraint: Applies to AirRouteLink and AirspaceArea only Natural This property can only be associated with a spatial object that is an Air Route language: Link or Airspace Area. OCL: 5.7.2.1.19 Navaid Navaid Subtype of: Definition: Description: AirNode One or more Navaid Equipments providing navigation services. DEFINITION Navaid equipment: A physical navaid equipment like VOR, DME, localizer, TACAN or etc. SOURCE [AIXM5.0]. NOTE 1 The Navaid Equipment share business rules like paired frequencies [AIXM5.0]. Proposed featureType

Status: Stereotypes:

Attribute: designator

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 117

Navaid Value type: Definition: Description: Multiplicity: Stereotypes: CharacterString The coded identifier given to the navaid system. SOURCE [AIXM5.0]. 1 voidable

Attribute: navaidType Value type: NavaidTypeValue Definition: Type of the navaid service. Description: SOURCE [AIXM5.0]. Multiplicity: Stereotypes: EXAMPLES ILS, MLS, VORTAC, VOR/DME. 1 voidable

5.7.2.1.20 ProcedureLink ProcedureLink Subtype of: Definition: Description: AirLink A series of predetermined manoeuvres with specified protection from obstacles. SOURCE [Procedure - AIXM5.0]. NOTE 1 A defined airway connector designed for channelling the flow of traffic as necessary for the provision of air traffic services during the take-off or landing phase, which links an airport/heliport to a significant point, usually connected to one or more air routes. NOTE 2 When a airport/heliport is not connected with a standardized airway connector to the rest of the air network, this object can be used as a fictitious connector between the airport/heliport and a significant point on one or more ATS routes - for example for VFR (Visual Flight Rules) flights. NOTE 3 Nevertheless, three main types of standardized Procedures are usually defined for IFR (Instrument Flight Rules) flights: - Standard Instrument Departure (SID), corresponding to the take-off phase. - Standard Instrument Arrival (STAR), corresponding to the initial approach during the landing phase. - Instrument Approach Procedure (IAP), corresponding to the final approach and arrival during the landing phase. Proposed featureType

Status: Stereotypes:

5.7.2.1.21 RunwayArea RunwayArea Subtype of: Definition: Description: TransportArea A defined rectangular area on a land aerodrome/heliport prepared for the landing and take-off of aircraft. SOURCE [Runway - AIXM5.0]. NOTE 1 This includes the concept of Final Approach and Take-Off Area (FATO) for helicopters [Runway - AIXM5.0]. NOTE 2 The runway strip is a defined area including the runway and stopway, if provided, intended : a) to reduce the risk of damage to aircraft running off a runway; and b) to protect aircraft flying over it during take-off or landing operations [ICAO]. Proposed featureType

Status: Stereotypes:

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 118

RunwayArea Attribute: designator Value type: CharacterString Definition: The full textual designator of the runway, used to uniquely identify it at an aerodrome/heliport which has more than one. Description: SOURCE [AIXM5.0]. Multiplicity: 1 Stereotypes: voidable Attribute: runwayType Value type: RunwayTypeValue Definition: The type of runway, either runway for airplanes or final approach and take off area (FATO) for helicopters. Description: SOURCE Adapted from [AIXM5.0]. Multiplicity: 1 Stereotypes: voidable 5.7.2.1.22 RunwayCentrelinePoint RunwayCentrelinePoint Subtype of: Definition: Description: AirNode An operationally significant position on the center line of a runway direction. SOURCE [AIXM5.0]. NOTE 1 The role of the point along the runway direction centreline is indicated within the pointRole attribute. NOTE 2 Runway centreline points are used to connect the Procedure Links that connect an airport/heliport to the rest of the air network. Status: Stereotypes: EXAMPLE A typical example is the runway threshold [AIXM5.0]. Proposed featureType

Attribute: pointRole Value type: PointRoleValue Definition: The role of the point along the runway direction centreline. Description: SOURCE [AIXM5.0]. Multiplicity: 1 5.7.2.1.23 StandardInstrumentArrival StandardInstrumentArrival Subtype of: Definition: Description: ProcedureLink A designated instrument flight rule (IFR) arrival route linking a significant point, normally on an ATS route, with a point from which a published instrument approach procedure can be commenced. SOURCE [AIXM5.0]. NOTE 1 Acronym: STAR. NOTE 2 It corresponds to the initial approach during the landing phase. Each airport/heliport could have various STAR linking significant points (usually connected to air routes) to the points designated to start the landing on a specific runway. Proposed featureType

Status: Stereotypes:

Attribute: designator Value type: CharacterString

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 119

StandardInstrumentArrival Definition: Description: Multiplicity: Stereotypes: The textual designator of the STAR. SOURCE [AIXM5.0]. 1 voidable

5.7.2.1.24 StandardInstrumentDeparture StandardInstrumentDeparture Subtype of: Definition: Description: ProcedureLink A designated instrument flight rule (IFR) departure route linking the aerodrome or a specific runway of the aerodrome with a specified significant point, normally on a designated ATS route, at which the en-route phase of a flight commences. SOURCE [AIXM5.0]. NOTE 1 Acronym: SID. NOTE 2 It corresponds to the take-off phase. Each airport/heliport could have various SID linking the different runways to one or various significant points, usually connected to air routes. Proposed featureType

Status: Stereotypes:

Attribute: designator Value type: CharacterString Definition: The full textual designator of the SID. Description: SOURCE [AIXM5.0]. Multiplicity: 1 Stereotypes: voidable 5.7.2.1.25 SurfaceComposition SurfaceComposition Subtype of: Definition: Status: Stereotypes: TransportProperty The composition of an aerodrome/heliport related surface. Proposed featureType

Attribute: surfaceComposition Value type: SurfaceCompositionValue Definition: A code indicating the composition of an aerodrome/heliport related surface. Description: SOURCE [SurfaceCharacteristics.composition - AIXM5.0]. Multiplicity: EXAMPLES Asphalt, concrete. 1

Constraint: Applies to RunwayArea, TaxiwayArea, ApronArea and TouchDowhLiftOff only Natural This property can only be associated with a spatial object that is a Runway Area, language: Taxiway Area, Apron Area or TouchDowhLiftOff. OCL: 5.7.2.1.26 TaxiwayArea TaxiwayArea Subtype of: Definition: TransportArea A defined path at an aerodrome/heliport established for the taxiing of aircraft/helicopters and intended to provide a link between one part of the aerodrome and another.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 120

TaxiwayArea Description: SOURCE [Taxiway - AIXM5.0]. NOTE This includes aircraft/helicopter stand taxilines, apron taxiways, rapid exit taxiways, air taxiways etc. Proposed featureType

Status: Stereotypes:

Attribute: designator Value type: CharacterString Definition: The textual designator of the taxiway. Description: SOURCE [AIXM5.0]. Multiplicity: 1 Stereotypes: voidable 5.7.2.1.27 TouchDownLiftOff TouchDownLiftOff Subtype of: Definition: Description: Status: Stereotypes: AirNode A load bearing area on which a helicopter may touch down or lift-off. SOURCE [AIXM5.0]. Proposed featureType

Attribute: designator Value type: CharacterString Definition: The textual designator of the touch down and lift-off area. Description: SOURCE [AIXM5.0]. Multiplicity: 1 Stereotypes: voidable 5.7.2.1.28 UpperAltitudeLimit UpperAltitudeLimit Subtype of: Definition: Status: Stereotypes: Attribute: altitude Value type: Definition: Multiplicity: TransportProperty Altitude that defines the upper limit of an air transport network object. Proposed featureType Measure Value of the altitude limit. 1

Constraint: Applies to AirRouteLink and AirspaceArea only Natural This property can only be associated with a spatial object that is an Air Route language: Link or Airspace Area. OCL: 5.7.2.1.29 useRestriction useRestriction Subtype of: Definition: Status: Stereotypes: TransportProperty The restrictions to the use of an air network object. Proposed featureType

Attribute: restriction Value type: AirUseRestrictionValue Definition: The type of use restriction for the air network object. Multiplicity: 1

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 121

useRestriction Constraint: Applies to AirRoute, AirLinks, AirNodes and AerodromeArea only Natural This property can only be associated with a spatial object that is an Air Route, Air language: Link (or specialized Air Link), Air Node (or specialized Air Node) or Aerodrome Area. OCL:

5.7.2.2 Enumerations and code lists

class Air Transport Netw ork: Enumerations and Code lists codeList AerodromeTypeValue + + + + aerodrom eHeliport aerodrom eOnly heliportOnly landingSite + + + codeList AirRouteLinkClassValue conventional RNAV T ACAN + + + + codeList PointRoleValue end m id start threshold

codeList AerodromeCategoryValue + + + dom esticNational dom esticRegional international + + AT S NAT

codeList AirRouteTypeValue + +

codeList Runw ayTypeValue FAT O runway

codeList AirUseRestrictionValue + + reservedForM ilitary tem poralRestrictions + + + + + + + + + + + + + + + +

codeList Nav aidTypeValue DM E ILS ILS-DM E LOC LOC-DM E M KR M LS M LS-DM E NDB NDB-DM E NDB-M KR T ACAN T LS VOR VOR-DM E VORT AC codeList SurfaceCompositionValue + + + asphalt concrete grass

codeList AirspaceAreaTypeValue + + + + + + + + + AT Z CT A CT R D FIR P R TMA UIR

Figure 40 UML class diagram: Air Transport Networks Enumerations and code lists

5.7.2.2.1 AerodromeCategoryValue AerodromeCategoryValue Definition: Status: Stereotypes: Governance: Aerodrome possible categories concerning the scope and importance of the air traffic services offered from and to it. Proposed codeList Centrally managed in INSPIRE code list register. URN: urn:xinspire:def:codeList:INSPIRE:AerodromeCategoryValue

Value: domesticNational Definition: Aerodrome serving domestic national air traffic services. Value: domesticRegional

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 122

AerodromeCategoryValue Definition: Aerodrome serving domestic regional air traffic services. Value: international Definition: Aerodrome serving international air traffic services. 5.7.2.2.2 AerodromeTypeValue AerodromeTypeValue Definition: Description: Status: Stereotypes: Governance: A code specifying whether a particular entity occurrence is an Aerodrome or a Heliport. SOURCE [CodeAirportHeliportType - AIXM5.0]. Proposed codeList Centrally managed in INSPIRE code list register. URN: urn:xinspire:def:codeList:INSPIRE:AerodromeTypeValue

Value: aerodromeHeliport Definition: Aerodrome with heliport landing area. Description: SOURCE [AIXM5.0]. Value: aerodromeOnly Definition: Aerodrome only. Description: SOURCE [AIXM5.0]. Value: heliportOnly Definition: Heliport only. Description: SOURCE [AIXM5.0]. Value: landingSite Definition: Landing site. Description: SOURCE [AIXM5.0]. 5.7.2.2.3 AirRouteLinkClassValue AirRouteLinkClassValue Definition: Description: The type of the route from the navigation point of view. SOURCE [CodeRouteNavigationType - AIXM5.0]. NOTE These values enumerate the possible usages of a AirRouteLink. Status: Stereotypes: Governance: EXAMPLES Conventional, RNAV. Proposed codeList Centrally managed in INSPIRE code list register. inspire:def:codeList:INSPIRE:AirRouteLinkClassValue

URN:

urn:x-

Value: conventional Definition: Conventional navigation route: An air route which does neither use Area Navigation (RNAV) nor TACAN navigation for air traffic services. DEFINITION Definition of Area Navigation (RNAV): A method of navigation which permits aircraft operation on any desired flight path within the coverage of stationreferenced navigation aids or within the limits of the capability of selfcontained aids, or a combination of both [ICAO]. Description: SOURCE [AIXM5.0]. Value: RNAV Definition: Area navigation route: An air route which uses Area Navigation (RNAV) for air traffic services. DEFINTION Area Navigation (RNAV): A method of navigation which permits aircraft operation on any desired flight path within the coverage of station-referenced navigation aids or within the limits of the capability of selfcontained aids, or a combination of both [ICAO]. SOURCE [AIXM5.0].

Description:

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 123

AirRouteLinkClassValue Value: TACAN Definition: TACAN route: An air route which uses TACAN Navigation for air traffic services. DEFINITION TACAN Navigation: A method of navigation which permits aircraft operation on any desired flight path within the coverage of station-referenced Tactical Air Navigation Beacon (TACAN) navigation aids. Description: SOURCE [AIXM5.0]. 5.7.2.2.4 AirRouteTypeValue AirRouteTypeValue Definition: Description: Status: Stereotypes: Governance: Value: ATS Definition: Description: Value: NAT Definition: Description: The route classification as ATS route or North Atlantic Tracks. SOURCE [CodeRouteType - AIXM5.0]. Proposed codeList Centrally managed in INSPIRE code list register. inspire:def:codeList:INSPIRE:AirRouteTypeValue ATS Route as described in ICAO Annex 11. SOURCE [AIXM5.0]. North Atlantic Track (part of Organized Track System). SOURCE [AIXM5.0].

URN:

urn:x-

5.7.2.2.5 AirspaceAreaTypeValue AirspaceAreaTypeValue Definition: Description: Status: Stereotypes: Governance: Value: ATZ Definition: Description: Recognised types of Airspace. SOURCE [CodeAirspaceType - AIXM5.0]. Proposed codeList Centrally managed in INSPIRE code list register. inspire:def:codeList:INSPIRE:AirspaceAreaTypeValue

URN:

urn:x-

Airport Traffic Zone. Airspace of defined dimensions established around an airport for the protection of airport traffic. Description: ICAO Recognized. SOURCE [AIXM5.0]. NOTE An ATZ usually is set up from the lower limit of a Control Zone (CTR) to the surface.

Value: CTA Definition: Description:

Control area. A controlled airspace extending upwards from a specified limit above the earth. Description: ICAO Recognized. SOURCE [AIXM5.0]. NOTE 1 A CTA could exist in the vicinity of a single airport to manage a busy air traffic area in order to provide protection to aircraft climbing out from the airport. As such it is a smaller version of a Terminal Maneuvering Area or Terminal Control Area (TMA), equivalent to it but serving only to one airport. NOTE 2 Standard Intrument Departure (SID) routes usually ends at the upper limit of a TMA or CTA, where the air route phase starts.

Value: CTR Definition:

Control zone. A controlled airspace extending upwards from the surface of the earth to a specified upper limit. Description: ICAO Recognized.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 124

AirspaceAreaTypeValue Description: SOURCE [AIXM5.0]. NOTE It is normally extended from the surface to a specified upper limit, set up to protect air traffic operating to and from that airport. A CTR usually is set up from the upper limit of an Aerodrome Traffic Zone (ATZ). Value: D Definition: Description: Danger area. Airspace of defined dimensions within which activities dangerous to the flight of aircraft may exist at specified times. Description: ICAO Recognized. SOURCE [AIXM5.0]. NOTE It is defined as a constraint airspace area to be avoided if possible, which could be dangerous for navigation of air traffic services and could be crossed only by specific routes and specific flight levels defined by the Defence Authority. Value: FIR Definition: Flight information region. Airspace of defined dimensions within which flight information service and alerting service are provided. Description: ICAO Recognized. Might, for example, be used if service provided by more than one unit. SOURCE [AIXM5.0]. NOTE 1 A FIR is an airspace region in which information, management and search-and-rescue services are provided by an air navigation service provider. NOTE 2 Any portion of the atmosphere belongs to some specific FIR, except from some cases. Small countries could have only a single FIR; bigger ones could have some regional FIRs. The division among different countries is done by international agreement through ICAO. Value: P Definition: Description: Prohibited area. Airspace of defined dimensions, above the land areas or territorial waters of a State, within which the flight of aircraft is prohibited. Description: ICAO Recognized. SOURCE [AIXM5.0]. NOTE It is defined as a constraint airspace area to be avoided, in which navigation of air traffic services is forbidden for high security reasons. Value: R Definition: Description: Restricted area. Airspace of defined dimensions, above the land areas or territorial waters of a State, within which the flight of aircraft is restricted in accordance with certain specified conditions. Description: ICAO Recognized. SOURCE [AIXM5.0]. NOTE It is defined as a constraint airspace area in which navigation of air traffic services is restricted and could only be crossed temporarily with authorisation and at specific flight levels. Value: TMA Definition: Terminal control area. Control area normally established at the confluence of ATS routes in the vicinity of one or more major aerodromes. Description: NonICAO Recognized. Mainly used in Europe under the Flexible Use of Airspace concept.

Description:

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 125

AirspaceAreaTypeValue Description: SOURCE [AIXM5.0]. NOTE 1 It is normally extended from a lower to an upper limit, set up at an area of confluence of busy airways in the vicinity of one or more major airports to protect traffic climbing out from and descending into the airports. NOTE 2 As such it is a larger version of a Control Area (CTA). Standard Intrument Departure (SID) routes usually ends at the upper limit of a TMA or CTA, where the air route phase starts. Value: UIR Definition: Upper flight information region (UIR). An upper airspace of defined dimensions within which flight information service and alerting service are provided. Description: Non-ICAO Recognized. Each state determines its definition for upper airspace. SOURCE [AIXM5.0].

Description:

5.7.2.2.6 AirUseRestrictionValue AirUseRestrictionValue Definition: Status: Stereotypes: Governance: The use restrictions for an air network object. Proposed codeList Centrally managed in INSPIRE code list inspire:def:codeList:INSPIRE:AirUseRestrictionValue

register.

URN:

urn:x-

Value: reservedForMilitary Definition: The air network object is exclusively for military use. Value: temporalRestrictions Definition: The temporal restrictions apply to the use of the air network object. 5.7.2.2.7 NavaidTypeValue NavaidTypeValue Definition: Description: Status: Stereotypes: Governance: Value: DME Definition: Description: Value: ILS Definition: Description: Value: ILS-DME Definition: Description: Value: LOC Definition: Description: Value: LOC-DME Definition: Description: Value: MKR Definition: Types of Navaid Services. SOURCE [AIXM5.0]. Proposed codeList Centrally managed in INSPIRE code list inspire:def:codeList:INSPIRE:NavaidTypeValue Distance Measuring Equipment. SOURCE [AIXM5.0]. Instrument Landing System. SOURCE [AIXM5.0]. ILS with collocated DME. SOURCE [AIXM5.0]. Localizer. SOURCE [AIXM5.0]. LOC and DME collocated. SOURCE [AIXM5.0]. Marker Beacon.

register.

URN:

urn:x-

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 126

NavaidTypeValue Description: Value: MLS Definition: Description: Value: MLS-DME Definition: Description: Value: NDB Definition: Description: Value: NDB-DME Definition: Description: Value: NDB-MKR Definition: Description: Value: TACAN Definition: Description: Value: TLS Definition: Description: Value: VOR Definition: Description: Value: VOR-DME Definition: Description: Value: VORTAC Definition: Description: SOURCE [AIXM5.0]. Microwave Landing System. SOURCE [AIXM5.0]. MLS with collocated DME. SOURCE [AIXM5.0]. Non-Directional Radio Beacon. SOURCE [AIXM5.0]. NDB and DME collocated. SOURCE [AIXM5.0]. Non-Directional Radio Beacon and Marker Beacon. SOURCE [AIXM5.0]. Tactical Air Navigation Beacon. SOURCE [AIXM5.0]. Transponder Landing System. SOURCE [AIXM5.0]. VHF Omnidirectional Radio Range. SOURCE [AIXM5.0]. VOR and DME collocated. SOURCE [AIXM5.0]. VOR and TACAN collocated. SOURCE [AIXM5.0].

5.7.2.2.8 PointRoleValue PointRoleValue Definition: Description: Status: Stereotypes: Governance: Value: end Definition: Description: Value: mid Definition: Description: Value: start Definition: Description: Value: threshold Definition: Role of the Runway Centreline Point. SOURCE [AIXM5.0]. Proposed codeList Centrally managed in INSPIRE code inspire:def:codeList:INSPIRE:PointRoleValue Physical end of a runway direction. SOURCE [AIXM5.0]. The mid point of the runway. SOURCE [AIXM5.0]. Physical start of a runway direction. SOURCE [AIXM5.0]. Threshold.

list

register.

URN:

urn:x-

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 127

PointRoleValue Description: SOURCE [AIXM5.0].

5.7.2.2.9 RunwayTypeValue RunwayTypeValue Definition: Description: Status: Stereotypes: Governance: Value: FATO Definition: Description: Value: runway Definition: Description: A code that makes a distinction between runways for airplanes and FATO for helicopters. SOURCE [CodeRunwayType - AIXM5.0]. Proposed codeList Centrally managed in INSPIRE code list register. URN: urn:xinspire:def:codeList:INSPIRE:RunwayTypeValue Final Approach and Take Off Area for helicopters. SOURCE [AIXM5.0]. Runway for airplanes. SOURCE [AIXM5.0].

5.7.2.2.10 SurfaceCompositionValue SurfaceCompositionValue Definition: Description: Status: Stereotypes: Governance: Value: asphalt Definition: Value: concrete Definition: Value: grass Definition: A code indicating the composition of a surface. SOURCE [CodeSurfaceCompositionType - AIXM5.0]. EXAMPLES Asphalt, concrete. Proposed codeList Centrally managed in INSPIRE code list register. inspire:def:codeList:INSPIRE:SurfaceCompositionValue Surface made of an asphalt layer. Surface made of a concrete layer. Surface consisting on a grass layer.

URN:

urn:x-

5.7.2.3 Candidate types and placeholders

5.7.2.3.1 ControlTower ControlTower Package: Definition: Description: Buildings [Placeholder to be fully specified in Annex II/III INSPIRE data specification] Aerodrome control tower [Unit.Type='TWR' - AIXM5.0]. NOTE Point representing the situation of a Control Tower belonging to an aerodrome (airport/heliport), used to manage aircraft traffic in the runways and nearest airspace to the aerodrome.

5.7.2.4 Imported types (informative)

This section lists definitions for feature types, data types and enumerations and code lists that are defined in other application schemas. The section is purely informative and should help the reader understand the feature catalogue presented in the previous sections. For the normative documentation of these types, see the given references.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 128

5.7.2.4.1 TransportLinkSequence TransportLinkSequence (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] A linear spatial object, composed of an ordered collection of transport links, which represents a continuous path in the transport network without any branches. The element has a defined beginning and end and every position on the transport link sequence is identifiable with one single parameter such as length. It describes an element of the transport network, characterized by one or more thematical identifiers and/or properties.

5.7.2.4.2 ConditionOfFacility ConditionOfFacility Package: Definition: Common Transport Elements [see section 5.2.2] State of a transport network element with regards to its completion and use.

5.7.2.4.3 TransportLink TransportLink (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] A linear spatial object that describes the geometry and connectivity of a transport network between two points in the network.

5.7.2.4.4 TransportArea TransportArea (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] Surface that represents the spatial extent of an element of a transport network.

5.7.2.4.5 TransportNode TransportNode (abstract) Package: Definition: Description: Common Transport Elements [see section 5.2.2] A point spatial object which is used for connectivity. Nodes are found at either end of the TransportLink.

5.7.2.4.6 TransportProperty TransportProperty (abstract) Package: Definition: Common Transport Elements [see section 5.2.2] A reference to a property that falls upon the network. This property can apply to the whole of the network element it is associated with or - for linear spatial objects - be described using linear referencing.

5.7.2.4.7 TransportLinkSet TransportLinkSet (abstract) Package: Definition: Description: Common Transport Elements [see section 5.2.2] A collection of transport link sequences and or individual transport links that has a specific function or siginificance in a transport network. NOTE This spatial object type supports the aggregation of links to form objects with branches, loops, parallel sequences of links, gaps, etc. EXAMPLE A dual carriageway road, as a collection of the two link sequences that represent each carriageway.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 129

6 Reference systems
6.1 Coordinate reference systems
6.1.1 Datum
Requirement 13 For the coordinate reference systems used for making available the INSPIRE spatial data sets, the datum shall be the datum of the European Terrestrial Reference System 1989 (ETRS89) in areas within its geographical scope, and the datum of the International Terrestrial Reference System (ITRS) or other geodetic coordinate reference systems compliant with ITRS in areas that are outside the geographical scope of ETRS89. Compliant with the ITRS means that the system definition is based on the definition of the ITRS and there is a well established and described relationship between both systems, according to EN ISO 19111.

6.1.2 Coordinate reference systems

Requirement 14 INSPIRE spatial data sets shall be made available using one of the threedimensional, two-dimensional or compound coordinate reference systems specified in the list below. Other coordinate reference systems than those listed below may only be used for regions outside of continental Europe. The geodetic codes and parameters for these coordinate reference systems shall be documented, and an identifier shall be created, according to EN ISO 19111 and ISO 19127. 1. Three-dimensional Coordinate Reference Systems Three-dimensional Cartesian coordinates Three-dimensional geodetic coordinates (latitude, longitude and ellipsoidal height), using the parameters of the GRS80 ellipsoid 2. Two-dimensional Coordinate Reference Systems Two-dimensional geodetic coordinates, using the parameters of the GRS80 ellipsoid Plane coordinates using the Lambert Azimuthal Equal Area projection and the parameters of the GRS80 ellipsoid Plane coordinates using the Lambert Conformal Conic projection and the parameters of the GRS80 ellipsoid Plane coordinates using the Transverse Mercator projection and the parameters of the GRS80 ellipsoid

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 130

3. Compound Coordinate Reference Systems For the horizontal component of the compound coordinate reference system, one of the twodimensional coordinate reference systems specified above shall be used For the vertical component on land, the European Vertical Reference System (EVRS) shall be used to express gravity-related heights within its geographical scope Other vertical reference systems related to the Earth gravity field shall be used to express gravity-related heights in areas that are outside the geographical scope of EVRS. The geodetic codes and parameters for these vertical reference systems shall be documented and an identifier shall be created, according to EN ISO 19111 and ISO 19127 For the vertical component measuring the depth of the sea floor, where there is an appreciable tidal range, the Lowest Astronomical Tide shall be used as reference surface. In marine areas without an appreciable tidal range, in open oceans and effectively in waters that are deeper than 200 m, the depth of the sea floor shall be referenced to the Mean Sea Level For the vertical component measuring depths above the sea floor in the free ocean, barometric pressure shall be used For the vertical component in the free atmosphere, barometric pressure, converted to height using ISO 2533:1975 International Standard Atmosphere shall be used

6.1.3 Display
Requirement 15 For the display of the INSPIRE spatial data sets with the View Service specified in D003152/02 Draft Commission Regulation implementing Directive 2007/2/EC of the European Parliament and of the Council as regards Network Services, at least the two dimensional geodetic coordinate system shall be made available.

6.1.4 Identifiers for coordinate reference systems

Requirement 16 For referring to the non-compound coordinate reference systems listed in this Section, the identifiers listed below shall be used. For referring to a compound coordinate reference system, an identifier composed of the identifier of the horizontal component, followed by a slash (/), followed by the identifier of the vertical component, shall be used. ETRS89-XYZ for Cartesian coordinates in ETRS89 ETRS89-GRS80h for three-dimensional geodetic coordinates in ETRS89 on the GRS80 ellipsoid ETRS89-GRS80 for two-dimensional geodetic coordinates in ETRS89 on the GRS80 EVRS for height in EVRS LAT for depth of the sea floor, where there is an appreciable tidal range MSL for depth of the sea floor, in marine areas without an appreciable tidal range, in open oceans and effectively in waters that are deeper than 200m ISA for pressure coordinate in the free atmosphere PFO for Pressure coordinate in the free ocean ETRS89-LAEA for ETRS89 coordinates projected into plane coordinates by the Lambert Azimuthal Equal Area projection ETRS89-LCC for ETRS89 coordinates projected into plane coordinates by the Lambert Conformal Conic projection ETRS89-TMzn for ETRS89 coordinates projected into plane coordinates by the Transverse Mercator projection

6.2 Temporal reference system

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 131

Requirement 17

The Gregorian Calendar shall be used for as a reference system for date values, and the Universal Time Coordinated (UTC) or the local time including the time zone as an offset from UTC shall be used as a reference system for time values.

7 Data quality
This section includes a description of data quality elements and sub-elements as well as the associated basic data quality measures to be used to describe data related to the spatial data theme Transport networks (see 13). NOTE Additional guidance documents on procedures and methods that can be used to implement the basic data quality measures introduced in this section will be provided at a later stage. For Transport networks theme, the provision of data quality information is necessary to cover the following specific purposes: Check that the different data providers supply a minimum set of data quality elements and sub-elements in order to evaluate and quantify the quality of datasets for specific purposes in the context of INSPIRE. Guarantee that a continuous transport network can be built from the elements provided in the transport network datasets, by assessing their conformance to some basic topological consistency rules aimed at ensure at least clean connections between features.

This specification is compliant with ISO 19113 and ISO 19114, but it does not fix any concrete conformance criteria for the data quality information proposed, since it should be valid for a wide range of European transport network datasets, with very different levels of detail and quality requirements. In addition, recommendations on minimum data quality are included for specific elements However, for the topological consistency rules mentioned above, a minimum set of measures are needed in order to make it possible the creation of a well-connected transport network. Data quality information can be described at level of spatial object (feature), spatial object type (feature type), dataset or dataset series. Data quality information at spatial object level is modelled directly in the application schema (Chapter 5). Chapter 8 describes the corresponding metadata elements to report about this data quality information. The table below describes the usage (feature-level or dataset-level) and the main purpose (evaluation or network) for the data quality elements and sub-elements proposed in this specification. Table 13 Data quality (sub-)elements and measures used in the theme Transport Networks INSPIRE Data Specification Transport Networks Section 7.1.1.1 7.1.1.2 7.1.2.1 Data quality element Data quality sub-element Quality purpose

Data quality measures Rate of Excess items Number of duplicate feature instances Rate of missing items

Usage

Completeness Completeness Completeness

Commission Commission Omission

dataset-level dataset-level dataset level

evaluation evaluation evaluation

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 132

7.2.1.1 7.2.2.1 7.2.3.1 7.2.4.1 7.2.4.2 7.2.4.3 7.2.4.4 7.2.4.5 7.2.4.6 7.3.1.1 7.4.1.1 7.4.2.1

Logical consistency Logical consistency Logical consistency Logical consistency Logical consistency Logical consistency Logical consistency Logical consistency Logical consistency Positional accuracy Thematic accuracy Thematic accuracy

Conceptual consistency Domain consistency Format consistency Topological consistency Topological consistency Topological consistency Topological consistency Topological consistency Topological consistency Absolute or external accuracy Classification correctness Nonquantitative attribute correctness

Conceptual schema compliance Value domain non conformance rate Physical structure conflict rate Number of invalid overlaps of surfaces Number of missing connections due to undershoots Number of missing connections due to overshoots Number of invalid slivers Number of invalid selfintersect errors Number of invalid selfoverlap errors Mean value of positional uncertainties Misclassification rate Rate of incorrect classification for national identifier

dataset level dataset level dataset-level dataset-level dataset-level dataset-level dataset-level dataset-level dataset-level dataset-level dataset-level dataset-level

evaluation evaluation evaluation network network network network network network evaluation evaluation evaluation

7.1 Completeness
These data quality elements enable the assessment of presence / absence of features in the dataset, their attributes and relationships

7.1.1 Commission
The assessment of these quality sub-elements should be included in the metadata element DQ_CompletenessCommission, described in section 8.

7.1.1.1 Rate of Excess items

This quality sub-element shows excess data present in a dataset. Name Alternative name Data quality element Data quality subelement Data quality basic measure Definition Description Parameter Data quality value type Data quality value structure Source reference Example Rate of excess items Completeness Commission Error rate Number of excess items in the dataset in relation to the number of items that should have been present. Real, percentage, ratio -

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 133

Measure identifier

3 (ISO 19138)

7.1.1.2 Number of duplicate feature instances

This quality sub-element shows duplicate features present in a dataset Name Alternative name Data quality element Data quality subelement Data quality basic measure Definition Description Parameter Data quality value type Data quality value structure Source reference Example Number of duplicate feature instances Completeness Commission Error count Total number of exact duplications of feature instances within the data Count of all items in the data that are incorrectly extracted with duplicate geometries. Integer Features with identical attribution and identical coordinates: two (or more) points collected on top of each other; two (or more) curves collected on top of each other; two (or more) surfaces collected on top of each other. 4 (ISO 19138)

Measure identifier

7.1.2 Omission
The assessment of this quality sub-element should be included in the metadata element DQ_CompletenessOmission, described in section 8.

7.1.2.1 Rate of missing items

This data quality sub element shows the number of missing items present in the data. Name Alternative name Data quality element Data quality subelement Data quality basic measure Definition Description Parameter Data quality value type Data quality value structure Source reference Example Measure identifier Rate of missing items Completeness Omission Error rate Number of items missing from the data. Real, percentage, ratio 5 (ISO 19138)

7.2 Logical consistency

Logical consistency elements enable the assessment of the degree of adherence to logical rules of data structure, attribution and relationships

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 134

7.2.1 Conceptual consistency

7.2.1.1 Conceptual schema compliance
This data quality sub-element should be assessed at feature level and the results should be stored in the metadata element: DQ_ConceptualConsistency. Name Alternative name Data quality element Data quality subelement Data quality basic measure Definition Description Parameter Data quality value type Data quality value structure Source reference Example Measure identifier Conceptual schema compliance Logical consistency Conceptual consistency Rate of correct items Number of items in the dataset in compliance with the rules of the conceptual schema in relation to the total number of items. No mandatory components or attributes are missing and no constraints are violated for any transport objects. Real, percentage, ratio The 95% of the mandatory components or attributes exist and no constraints are violated within the dataset. 13 (ISO 19138)

7.2.2 Domain consistency

7.2.2.1 Value domain non conformance rate
This quality sub-element shows the global adherence of values in the dataset to the predefined value domains. The assessment of this quality sub-element should be included in the metadata element DQ_DomainConsistency. Name Alternative name Data quality element Data quality subelement Data quality basic measure Definition Description Parameter Data quality value type Data quality value structure Source reference Example Value domain non conformance rate Logical consistency Domain consistency Incorrect items rate Number of items in the dataset that are not in conformance with their value domain in relation to the total number of items in the dataset. Number of transport objects in the dataset that are not in conformance with their value domains in relation to the total number of objects in the transport dataset. Percentage, ratio 95% of transport features consist of components whose values are within the domains stated in the application schema (i.e. giving an example for a specific feature type Railway Link, the values for Railway Type should be any of 8 values defined in RailwayTypeValues, etc.). 17 (ISO 19138)

Measure identifier

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 135

7.2.3 Format consistency

7.2.3.1 Physical structure conflict rate
This quality sub-element shows the percentage of items stored in conflict with the physical structure of the dataset. The assessment of this quality sub-element should be included in the metadata element: DQ_FormatConsistency. Name Alternative name Data quality element Data quality subelement Data quality basic measure Definition Description Parameter Data quality value type Data quality value structure Source reference Example Measure identifier Physical structure conflict rate Logical consistency Format consistency Error rate Number of items in the dataset that are stored in conflict with the physical structure of the dataset divided by the total number of items Real, percentage, ratio 20 (ISO 19138)

7.2.4 Topological consistency

The assessment of the following data quality sub-elements should be included in the metadata element DQ_TopologicalConsistency.

7.2.4.1 Number of invalid overlaps of surfaces

Name Alternative name Data quality element Data quality subelement Data quality basic measure Definition Description Number of invalid overlaps of surfaces Overlapping surfaces Logical consistency Conceptual consistency Error count Total number of erroneous overlaps within the data. Which surfaces may overlap and which shall not is application dependent. Not all overlapping surfaces are necessarily erroneous. When reporting this data quality measure, the types of feature classes corresponding to the illegal overlapping surfaces shall be reported as well. Integer -

Parameter Data quality value type Data quality value structure Source reference Example: Figure 29

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 136

Key 1 Surface 1 2 Surface 2 3 Overlapping Area Note: Some types of area features related to air transport (e.g. AirspaceArea types FIR and CTR) represent the horizontal projections of 3D volumes in the air space which may overlap. 11 (ISO 19138)

Measure identifier

7.2.4.2 Number of missing connections due to undershoots

The following topological consistency quality sub-element is required in order to ensure building a clean and connected transport network. See also Section 10.2 Ensuring Network Connectivity. Name Alternative name Data quality element Data quality subelement Data quality basic measure Definition Description Parameter Number of missing connections due to undershoots Undershoots Logical consistency Topological consistency Error count Count of items in the dataset that are mismatched due to undershoots, given the parameter Connectivity tolerance. Lacks of connectivity exceeding the Connectivity tolerance are considered as errors if the real features are connected in the transport network. Name: Connectivity tolerance Definition: Search distance from the end of a dangling line. Description: This parameter is specific for each data providers dataset and must be reported as metadata in order to ensure automatic and unambiguous creation of centreline topology connectivity - for the transport network (See Section 10.2 Ensuring Network Connectivity). Connectivity tolerance must be specified by the data provider using the following elements of the DQ_TopologicalConsistency metadata element for the current measure: 102. measureDescription (type: free text): Defined as Description of the measure. 107. Result (type DQ_Result): Defined as Value (or set of values) obtained from applying a data quality measure or the outcome of evaluating the obtained value (or set of values) against a specified acceptable conformance quality level. Specifically, the tolerance must be defined within the two elements: - 130. specification - 131. explanation from DQ_Result class. Data quality value type Data quality value structure Source reference Note: Metadata elements defined in ISO 19115. Integer -

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 137

Example Figure 30

Measure identifier

Key 1 Connectivity tolerance = 3 m 23 (ISO 19138)

7.2.4.3 Number of missing connections due to overshoots

The following topological consistency quality sub-element is required in order to ensure building a clean and connected transport network. See also Data Capture (10.2) Name Alternative name Data quality element Data quality subelement Data quality basic measure Definition Description Parameter Number of missing connections due to overshoots Overshoots Logical consistency Topological consistency Error count Count of items in the dataset that are mismatched due to overshoots, given the parameter Connectivity tolerance. Lacks of connectivity exceeding the Connectivity tolerance are considered as errors if the real features are connected in the transport network. Name: Connectivity tolerance Definition: Search distance from the end of a dangling line. Description: This parameter is specific for each data providers dataset and must be reported as metadata in order to ensure automatic and unambiguous creation of centreline topology connectivity - for the transport network (See Section 10.2 Ensuring Network Connectivity). Connectivity tolerance must be specified by the data provider using the following elements of the DQ_TopologicalConsistency metadata element for the current measure: 102. measureDescription (type: free text): Defined as Description of the measure. 107. Result (type DQ_Result): Defined as Value (or set of values) obtained from applying a data quality measure or the outcome of evaluating the obtained value (or set of values) against a specified acceptable conformance quality level. Specifically, the tolerance must be defined within the two elements: - 130. specification - 131. explanation from DQ_Result class. Data quality value type Note: Metadata elements defined in ISO 19115. Integer

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 138

Data quality value structure Source reference Example Figure 31

Measure identifier

Key 1 Connectivity tolerance = 3 m 24 (ISO 19138)

7.2.4.4 Number of invalid slivers

Name Alternative name Data quality element Data quality subelement Data quality basic measure Definition Description Number of invalid slivers Slivers Logical consistency Topological consistency Error count Count of all items in the dataset that are invalid sliver surfaces. A sliver is an unintended area that occurs when adjacent surfaces are not digitized properly. The borders of the adjacent surfaces may unintentionally gap or overlap by small amounts to cause a topological error. This data quality measure has 2 parameters: maximum sliver area size thickness quotient The thickness quotient shall be a real number between 0 and 1. This quotient is determined by the following formula: T is the thickness quotient T = 4 [area]/[perimeter]2 T = 1 value corresponds to a circle that has the largest area/perimeter2 value. T = 0 value corresponds to a line that has the smallest area/perimeter2 value. The thickness quotient is independent of the size of the surface, and the closer the value is to 0, the thinner the selected sliver surfaces shall be. The maximum area determines the upper limit of a sliver. This is to prevent surfaces with sinuous perimeters and large areas from being mistaken as slivers. Integer Environmental Systems Research Institute, Inc. (ESRI) GIS Data ReViewer 4.2 User Guide

Parameter

Data quality value type Data quality value structure Source reference

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 139

Example Figure 32

Key 1 Single line rail 2 Double line rail a) Maximum area parameter prevents correct double line rail portrayal from being flagged as an error

Measure identifier

Key 1 Railway station area 2 Sliver 3 Railway yard area b) Sliver is less than the maximum parameter and is flagged for evaluation of possible error 25 (ISO 19138)

7.2.4.5 Number of invalid self-intersect errors

Name Alternative name Data quality element Data quality subelement Data quality basic measure Definition Description Parameter Data quality value type Number of invalid self-intersect errors Loops Logical consistency Topological consistency Error count Count of all items in the data that illegally intersect with themselves. Integer

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 140

Data quality value structure Source reference Example Figure 33

Measure identifier

Key 1 Enclosed Traffic Area 2 Illegal intersection (loop) 26 (ISO 19138)

7.2.4.6 Number of invalid self-overlap errors

Name Alternative name Data quality element Data quality subelement Data quality basic measure Definition Description Parameter Data quality value type Data quality value structure Source reference Example Figure 34 Number of invalid self-overlap errors Kickbacks Logical consistency Topological consistency Error count Count of all items in the data that illegally self overlap. Integer -

Measure identifier

Vertices. 27 (ISO 19138)

7.3 Positional accuracy

7.3.1 Absolute or external accuracy
7.3.1.1 Mean value of positional uncertainties
This quality sub-element shows the closeness of reported coordinate values to values accepted as or being true. The assessment of this quality sub-element should be stored in the metadata element DQ_AbsoluteExternalPositionalAccuracy. Name Alternative name Data quality element Data quality subelement Data quality basic measure Definition Mean value of positional uncertainties Mean value of positional uncertainties (1D, 2D and 3D) Positional accuracy Absolute or external accuracy Not applicable Mean value of the positional uncertainties for a set of positions where

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 141

Description

the positional uncertainties are defined as the distance between a measured position and what is considered as the corresponding true position. For a number of points (N), the measured positions are given as xmi, ymi and zmi coordinates depending on the dimension in which the position of the point is measured. A corresponding set of coordinates, xti, yti and zti, are considered to represent the true positions. The errors are calculated as 1D: ei=|xmixti| 2D: ei=[(xmixti)2+(ymiyti)2] 3D: ei=[(xmixti)2+(ymiyti)2+(zmizti)2] The mean positional uncertainties of the horizontal absolute or external positions are then calculated as

Parameter Data quality value type Data quality value structure Source reference Example Measure identifier

A criterion for the establishing of correspondence should also be stated (e.g. allowing for correspondence to the closest position, correspondence on vertices or along lines). The criterion/criteria for finding the corresponding points shall be reported with the data quality evaluation result. This data quality measure is different from the standard deviation. Measure 28 (ISO 19138)

7.4 Thematic accuracy

7.4.1 Classification correctness
7.4.1.1 Misclassification rate
This quality sub-element shows the comparison of the classes assigned to features or their attributes to a universe of discourse. The assessment of this quality sub-element should be stored in the metadata element DQ_ThematicClassificationCorrectness. Name Alternative name Data quality element Data quality subelement Data quality basic measure Definition Description Parameter Data quality value type Data quality value structure Source reference Example Measure identifier Misclassification rate Thematic accuracy Classification correctness Error rate Average number of incorrectly classified features in relation to the number of features that are supposed to be within the dataset. To be provided globally as an average value for the whole dataset. Real, percentage, ratio 61 (ISO 19138)

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 142

7.4.2 Non-quantitative attribute correctness

7.4.2.1 Rate of incorrect classification for national identifier
This quality sub-element shows the data absent or incorrect in a dataset. The assessment of this quality sub-element should be stored in the metadata element DQ_ NonQuantitativeAttributeAccuracy, described in section 8. Name Alternative name Data quality element Data quality subelement Data quality basic measure Definition Description Parameter Data quality value type Data quality value structure Source reference Example Measure identifier Rate of incorrect classification for national identifier Thematic accuracy Non-quantitative attribute correctness Error rate Number of incorrect or missing national identifiers in the data set in relation to the number of items in the data set. Real, percentage, ratio 62 (ISO 19138)

Recommendation 14 Where metadata is not supplied at the object level data providers should supply the dataset metadata described section 7.

8 Dataset-level metadata
Metadata can be reported for each individual spatial object (spatial object-level metadata) or once for a complete dataset or dataset series (dataset-level metadata). Spatial object-level metadata is fully described in the application schema (section 5). If data quality elements are used at spatial object level, the documentation shall refer to the appropriate definition in section 7. This section only specifies dataset-level metadata elements. For some dataset-level metadata elements, in particular on data quality and maintenance, a more specific scope can be specified. This allows the definition of metadata at sub-dataset level, e.g. separately for each spatial object type. When using ISO 19115/19139 to encode the metadata, the following rules should be followed: The scope element (of type DQ_Scope) of the DQ_DataQuality subtype should be used to encode the scope. Only the following values should be used for the level element of DQ_Scope: Series, Dataset, featureType. If the level is featureType the levelDescription/MDScopeDescription/features element (of type Set< GF_FeatureType>) shall be used to list the feature type names. NOTE The value featureType is used to denote spatial object type.

Mandatory or conditional metadata elements are specified in Section 8.1. Optional metadata elements are specified in Section 8.2. The tables describing the metadata elements contain the following information: The first column provides a reference to a more detailed description.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 143

The second column specifies the name of the metadata element. The third column specifies the multiplicity. The fourth column specifies the condition, under which the given element becomes mandatory (only for Table 15 and Table 16).

8.1 Mandatory and conditional metadata elements

Requirement 18 The metadata describing a spatial data set or a spatial data set series related to the theme Transport Networks shall comprise the metadata elements required by Regulation 1205/2008/EC (implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata) for spatial datasets and spatial dataset series (Table 15) as well as the metadata elements specified in Table 16.

Table 15 Metadata for spatial datasets and spatial dataset series specified in Regulation 1205/2008/EC (implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata) Metadata Regulation Section 1.1 1.2 1.3 1.4 Metadata element Resource title Resource abstract Resource type Resource locator Multiplicity 1 1 1 0..* Mandatory if a URL is available to obtain more information on the resource, and/or access related services. Condition

1.5 1.7 2.1 3 4.1 5 6.1 6.2

Unique resource identifier Resource language Topic category Keyword Geographic bounding box Temporal reference Lineage Spatial resolution

1..* 0..* 1..* 1..* 1..* 1..* 1 0..* Mandatory for data sets and data set series if an equivalent scale or a resolution distance can be specified. Mandatory if the resource includes textual information.

7 8.1 8.2

Conformity Conditions for access and use Limitations on public access

1..* 1..* 1..*

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 144

9 10.1 10.2 10.3

Responsible organisation Metadata point of contact Metadata date Metadata language

1..* 1..* 1 1

Table 16 Mandatory and conditional theme-specific metadata for the theme Transport Networks INSPIRE Data Specification Metadata element Transport Networks Section 8.1.1 8.1.2 Coordinate Reference System Temporal Reference System

Multiplicity

Condition

1 0..* Mandatory, if the spatial data set or one of its feature types contains temporal information that does not refer to the Gregorian Calendar or the Coordinated Universal Time.

8.1.3 8.1.4

Encoding Character Encoding

1..* 0..* Mandatory, if a non-XML-based encoding is used that does not support UTF-8 Mandatory if the data set do not assure centreline topology (connectivity of centrelines) for the transport network.

8.1.5

Data Quality Logical Consistency Topological Consistency

0..*

8.1.1 Coordinate Reference System

Metadata element name Definition ISO 19115 number and name ISO/TS 19139 path INSPIRE obligation / condition INSPIRE multiplicity Data type(and ISO 19115 no.) Domain Implementing instructions Example Example XML encoding Comments Coordinate Reference System Description of the coordinate reference system used in the dataset. 13. referenceSystemInfo referenceSystemInfo mandatory 1 189. MD_CRS Either the referenceSystemIdentifier (RS_Identifier) or the projection (RS_Identifier), ellipsoid (RS_Identifier) and datum (RS_Identifier) properties shall be provided. referenceSystemIdentifier: code: ETRS_89 codeSpace: INSPIRE RS registry -

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 145

8.1.2 Temporal Reference System

Metadata element name Definition ISO 19115 number and name ISO/TS 19139 path INSPIRE obligation / condition INSPIRE multiplicity Data type(and ISO 19115 no.) Domain Implementing instructions Example Example XML encoding Comments Temporal Reference System Description of the temporal reference systems used in the dataset. 13. referenceSystemInfo referenceSystemInfo Mandatory, if the spatial data set or one of its feature types contains temporal information that does not refer to the Gregorian Calendar or the Coordinated Universal Time. 0..* 186. MD_ReferenceSystem No specific type is defined in ISO 19115 for temporal reference systems. Thus, the generic MD_ReferenceSystem element and its reference SystemIdentifier (RS_Identifier) property shall be provided. referenceSystemIdentifier: code: GregorianCalendar codeSpace: INSPIRE RS registry -

8.1.3 Encoding
Metadata element name Definition ISO 19115 number and name ISO/TS 19139 path INSPIRE obligation / condition INSPIRE multiplicity Data type (and ISO 19115 no.) Encoding Description of the computer language construct that specifies the representation of data objects in a record, file, message, storage device or transmission channel 271. distributionFormat distributionInfo/MD_Distribution/distributionFormat mandatory 1 284. MD_Format See B.2.10.4. The following property values shall be used for default and alternative encodings specified in section 9.2: Default Encoding Common Transport Elements name: Common Transport Elements GML application schema version: version 3.0.1; GML, version 3.2.1 specification: D2.8.I.7 Data Specification on Transport Networks Draft Guidelines Domain Road Transport Networks name: Road Transport Networks GML application schema version: version 3.0; GML, version 3.2.1 specification: D2.8.I.7 Data Specification on Transport Networks Draft Guidelines Rail Transport Networks name: Rail Transport Networks GML application schema version: version 3.0; GML, version 3.2.1 specification: D2.8.I.7 Data Specification on Transport Networks Draft Guidelines

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 146

Cable Transport Networks name: Cable Transport Networks GML application schema version: version 3.0; GML, version 3.2.1 specification: D2.8.I.7 Data Specification on Transport Networks Draft Guidelines Water Transport Networks name: Water Transport Networks GML application schema version: version 3.0; GML, version 3.2.1 specification: D2.8.I.7 Data Specification on Transport Networks Draft Guidelines Air Transport Networks name: Air Transport Networks GML application schema version: version 3.0; GML, version 3.2.1 specification: D2.8.I.7 Data Specification on Transport Networks Draft Guidelines Implementing instructions Example Example XML encoding Comments name: Road Transport Network GML application schema version: version 3.0, GML, version 3.2.1 specification: D2.8.I.7 Data Specification on Transport Networks Draft Guidelines -

8.1.4 Character Encoding

Metadata element name Definition ISO 19115 number and name ISO/TS 19139 path INSPIRE obligation / condition INSPIRE multiplicity Data type(and ISO 19115 no.) Domain Implementing instructions Example Example XML encoding Comments Metadata dataset character set Full name of the character coding standard used for the dataset. 4. characterSet IdentificationInfo/*/characterSet Mandatory, if a non-XML-based encoding is used that does not support UTF-8 0..* 40. MD_CharacterSetCode Codelist (See B.5.10 of ISO 19115)

8.1.5 Data Quality Logical Consistency Topological Consistency

Metadata element name Definition ISO 19115 number and name ISO/TS 19139 path INSPIRE obligation / condition Data Quality Logical Consistency Topological Consistency Correctness of the explicitly encoded topological characteristics of the dataset as described by the scope (*).
Note *: 138. DQ_Scope

18. dataQualityInfo dataQualityInfo Optional

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 147

INSPIRE multiplicity Data type (and ISO 19115 no.) Domain Implementing instructions Example Example XML encoding

Comments

0..* 115. DQ_TopologicalConsistency Lines 100-107 from ISO 19115 This metadata should be filled, at least, with these elements: - valueUnit: UnitOfMeasure - value: Record See clauses 7.2.4.2 and 7.2.4.3 in 7.2.4 in Chapter 7 related to missing connections due to undershoots and overshoots for detailed information. This metadata element is mandatory if connectivity is not assured for transport network centrelines in the dataset. In this case the Connectivity tolerance parameter as described in 7.2.4.2 and 7.2.4.3 must be provided in order to ensure automatic and unambiguous creation of centreline topology in post-process.

8.2 Optional metadata elements

Recommendation 15 The metadata describing a spatial data set or a spatial data set series related to the theme Transport Networks should comprise the theme-specific metadata elements specified in Table 17. Table 17 Optional theme-specific metadata for the theme Transport Networks INSPIRE Data Specification Transport Networks Section 8.2.1 8.2.2 8.2.3 8.2.4 8.2.5 8.2.6 8.2.7 8.2.8 8.2.9 8.2.10

Metadata element

Multiplicity

Maintenance Information Data Quality Completeness Commission Data Quality Completeness Omission Data Quality Logical Consistency Topological Consistency Data Quality Positional Accuracy Absolute or external accuracy Data Quality Logical Consistency Conceptual Consistency Data Quality Logical Consistency Domain Consistency Data Quality Logical Consistency - Format Consistency Data Quality Thematic Accuracy Thematic Classification Correctness Data Quality Thematic accuracy Non-quantitative correctness

0..1 0..* 0..* 0..* 0..* 0..* 0..* 0..* 0..* 0..*

8.2.1 Maintenance Information

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 148

Metadata element name Definition ISO 19115 number and name ISO/TS 19139 path INSPIRE obligation / condition INSPIRE multiplicity Data type(and ISO 19115 no.)

Domain

Implementing instructions Example Example XML encoding Comments

Maintenance information Information about the scope and frequency of updating. 30. resourceMaintenance identificationInfo/MD_Identification/resourceMaintenance Optional 0..1 142. MD_MaintenanceInformation This is a complex type (lines 143-148 from ISO 19115). At least the following elements should be used (the multiplicity according to ISO 19115 is shown in parentheses): maintenanceAndUpdateFrequency [1]: frequency with which changes and additions are made to the resource after the initial resource is completed / domain value: MD_MaintenanceFrequencyCode: updateScope [0..*]: scope of data to which maintenance is applied / domain value: MD_ScopeCode maintenanceNote [0..*]: information regarding specific requirements for maintaining the resource / domain value: free text maintenanceAndUpdateFrecuency: annually -

8.2.2 Data Quality Completeness Commission

Metadata element name Data Quality Completeness Commission DQ Completeness: presence and absence of features, their attributes and their relationships; Commission: excess data present in the dataset, as described by the scope (*).
Note *: 138. DQ_Scope

Definition

ISO 19115 number and name ISO/TS 19139 path INSPIRE obligation / condition INSPIRE multiplicity Data type (and ISO 19115 no.) Domain Implementing instructions Example Example XML encoding Comments

18. dataQualityInfo dataQualityInfo Optional 0..* 109. DQ_CompletenessCommission Lines 100-107 from ISO 19115 This metadata should be filled, at least, with these elements: - valueUnit: UnitOfMeasure - value: Record See clause 7.1.1 in Chapter 7 for detailed information.

8.2.3 Data Quality Completeness Omission

Metadata element name Data Quality Completeness Omission DQ Completeness: presence and absence of features, their attributes and their relationships; Omission: data absent from the dataset, as described by the scope (*).
Note *: 138. DQ_Scope

Definition

ISO 19115 number and name

18. dataQualityInfo

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 149

ISO/TS 19139 path INSPIRE obligation / condition INSPIRE multiplicity Data type (and ISO 19115 no.) Domain Implementing instructions Example Example XML encoding Comments

dataQualityInfo Optional 0..* 110. DQ_CompletenessOmission Lines 100-107 from ISO 19115 This metadata should be filled, at least, with these elements: - valueUnit: UnitOfMeasure - value: Record See clause 7.1.2 in Chapter 7 for detailed information.

8.2.4 Data Quality Logical Consistency Topological Consistency

Metadata element name Definition ISO 19115 number and name ISO/TS 19139 path INSPIRE obligation / condition INSPIRE multiplicity Data type (and ISO 19115 no.) Domain Implementing instructions Example Example XML encoding Comments Data Quality Logical Consistency Topological Consistency Correctness of the explicitly encoded topological characteristics of the dataset as described by the scope (*).
Note *: 138. DQ_Scope

18. dataQualityInfo dataQualityInfo Optional 0..* 115. DQ_TopologicalConsistency Lines 100-107 from ISO 19115 This metadata should be filled, at least, with these elements: - valueUnit: UnitOfMeasure - value: Record See clause 7.2.4 in Chapter 7 for detailed information.

8.2.5 Data Quality Positional Accuracy Absolute or external accuracy

Metadata element name Definition ISO 19115 number and name ISO/TS 19139 path INSPIRE obligation / condition INSPIRE multiplicity Data type (and ISO 19115 no.) Domain Implementing instructions Example Example XML encoding Comments Data Quality - Positional accuracy - Absolute or external accuracy Closeness of reported coordinate values to values accepted as or being true. 18. dataQualityInfo dataQualityInfo Optional 0..* 117. DQ_AbsoluteExternalPositionalAccuracy Lines 100-107 from ISO 19115 This metadata should be filled, at least, with these elements: - valueUnit: UnitOfMeasure - value: Record See clause 7.3.1 in Chapter 7 for detailed information.

8.2.6 Data Quality Logical Consistency Conceptual Consistency

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 150

Metadata element name Definition ISO 19115 number and name ISO/TS 19139 path INSPIRE obligation / condition INSPIRE multiplicity Data type (and ISO 19115 no.) Domain Implementing instructions Example Example XML encoding Comments

Data Quality Logical Consistency Conceptual Consistency Adherence to rules of the conceptual schema. 18. dataQualityInfo dataQualityInfo Optional 0..* 112. DQ_ConceptualConsistency Lines 100-107 from ISO 19115 This metadata should be filled, at least, with these elements: - valueUnit: UnitOfMeasure - value: Record See clause 7.2.1 in Chapter 7 for detailed information.

8.2.7 Data Quality Logical Consistency Domain Consistency

Metadata element name Definition ISO 19115 number and name ISO/TS 19139 path INSPIRE obligation / condition INSPIRE multiplicity Data type (and ISO 19115 no.) Domain Implementing instructions Example Example XML encoding Comments Data Quality Logical Consistency Domain Consistency Adherence of values to the value domains. 18. dataQualityInfo dataQualityInfo Optional 0..* 113. DQ_DomainConsistency Lines 100-107 from ISO 19115 This metadata should be filled, at least, with these elements: - valueUnit: UnitOfMeasure - value: Record See clause 7.2.2 in Chapter 7 for detailed information.

8.2.8 Data Quality Logical Consistency - Format Consistency

Metadata element name Definition ISO 19115 number and name ISO/TS 19139 path INSPIRE obligation / condition INSPIRE multiplicity Data type (and ISO 19115 no.) Domain Implementing instructions Example Example XML encoding Comments Data Quality Logical Consistency Format Consistency Degree to which data is stored in accordance with the physical structure of the dataset, as described by the scope (*).
Note *: 138. DQ_Scope

18. dataQualityInfo dataQualityInfo Optional 0..* 114. DQ_FormatConsistency Lines 100-107 from ISO 19115 This metadata should be filled, at least, with these elements: - valueUnit: UnitOfMeasure - value: Record See clause 7.2.3 in Chapter 7 for detailed information.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 151

8.2.9 Data Quality Thematic Accuracy Thematic Classification Correctness

Metadata element name Definition ISO 19115 number and name ISO/TS 19139 path INSPIRE obligation / condition INSPIRE multiplicity Data type (and ISO 19115 no.) Domain Implementing instructions Example Example XML encoding Comments Data Quality Thematic Accuracy Thematic Classification Correctness Comparison of the classes assigned to features or their attributes to a universe of discourse. 18. dataQualityInfo dataQualityInfo Optional 0..* 125. DQ_ThematicClassificationCorrectness. Lines 100-107 from ISO 19115 This metadata should be filled, at least, with these elements: - valueUnit: UnitOfMeasure - value: Record See clause 7.4.1 in Chapter 7 for detailed information.

8.2.10 Data Quality Thematic accuracy Non-quantitative correctness

Metadata element name Definition ISO 19115 number and name ISO/TS 19139 path INSPIRE obligation / condition INSPIRE multiplicity Data type (and ISO 19115 no.) Domain Implementing instructions Example Example XML encoding Comments Data Quality Thematic accuracy- Non-quantitative attribute correctness Accuracy of non-quantitative attributes. 18. dataQualityInfo dataQualityInfo Optional 0..* 126. DQ_NonQuantitativeAttributeAccuracy Lines 100-107 from ISO 19115 This metadata should be filled, at least, with these elements: - valueUnit: UnitOfMeasure - value: Record See clause 7.4.2 in Chapter 7 for detailed information.

8.3 Guidelines on using metadata elements defined in Regulation 1205/2008/EC

8.3.1 Conformity
The Conformity metadata element defined in Regulation 1205/2008/EC allows to report the conformance with the Implementing Rule for interoperability of spatial data sets and services or another specification. The degree of conformity of the dataset can be Conformant (if the dataset is fully conformant with the cited specification), Not Conformant (if the dataset does not conform to the cited specification) or Not evaluated (if the conformance has not been evaluated).

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 152

Recommendation 16 The Conformity metadata element should be used to report conceptual consistency with this INSPIRE data specification. The value of Conformant should be used for the Degree element only if the dataset passes all the requirements described in the abstract test suite presented in Annex A. The Specification element should be given as follows: - title: INSPIRE Data Specification on Transport Networks Draft Guidelines - date: - dateType: publication - date: 2009-10-02

8.3.2 Lineage
Following the ISO 19113 Quality principles, if a data provider has a procedure for quality validation of their spatial data sets then the data quality elements listed in the Chapter 8 should be used. If not, the Lineage metadata element (defined in Regulation 1205/2008/EC) should be used to describe the overall quality of a spatial data set. According to Regulation 1205/2008/EC, lineage is a statement on process history and/or overall quality of the spatial data set. Where appropriate it may include a statement whether the data set has been validated or quality assured, whether it is the official version (if multiple versions exist), and whether it has legal validity. The value domain of this metadata element is free text. Recommendation 17 Apart from describing the process history, if feasible within a free text, the overall quality of the dataset (series) should be included in the Lineage metadata element. This statement should contain any quality information required for interoperability and/or valuable for use and evaluation of the data set (series).

8.3.3 Temporal reference

According to Regulation 1205/2008/EC, at least one of the following temporal reference metadata elements shall be provided: temporal extent, date of publication, date of last revision, date of creation. Recommendation 18 If feasible, the date of the last revision of a spatial data set should be reported using the Date of last revision metadata element.

9 Delivery
9.1 Delivery medium
Requirement 19 Data conformant to this INSPIRE data specification shall be made available through an INSPIRE network service.

Requirement 20

All information that is required by a calling application to be able to retrieve the data through the used network service shall be made available in accordance with the requirements defined in the Implementing Rules on Network Services.

EXAMPLE 1 Through the Get Spatial Objects function, a download service can either download a pre-defined data set or pre-defined part of a data set (non-direct access download service), or give

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 153

direct access to the spatial objects contained in the data set, and download selections of spatial objects based upon a query (direct access download service). To execute such a request, some of the following information might be required: The list of spatial object types and/or predefined data sets that are offered by the download service (to be provided through the Get Download Service Metadata operation), And the query capabilities section advertising the types of predicates that may be used to form a query expression (to be provided through the Get Download Service Metadata operation, where applicable), A description of spatial object types offered by a download service instance (to be provided through the Describe Spatial Object Types operation). EXAMPLE 2 Through the Transform function, a transformation service carries out data content transformations from native data forms to the INSPIRE-compliant form and vice versa. If this operation is directly called by an application to transform source data (e.g. obtained through a download service) that is not yet conformant with this data specification, the following parameters are required: Input data (mandatory). The data set to be transformed. Source model (mandatory, if cannot be determined from the input data). The model in which the input data is provided. Target model (mandatory). The model in which the results are expected. Model mapping (mandatory, unless a default exists). Detailed description of how the transformation is to be carried out.

9.2 Encodings
9.2.1 Encoding for application schema Common Transport Elements
Requirement 21 Data conformant to the application schema Common Transport elements shall be encoded using the encoding specified in section 9.2.1.1.

9.2.1.1 Default Encoding: GML Application Schema

Format name: Common Transport Elements GML Application Schema Version of the format: 3.0.1, GML, version 3.2.1 Reference to the specification of the format: ISO 19136:2007 Character set: UTF-8 The GML Application Schema is distributed in a zip-file separately from the data specification document.

9.2.2 Encoding for application schema of Road transport networks

Requirement 22 Data conformant to the application schema of Road transport networks shall be encoded using the encoding specified in section 9.2.2.1.

9.2.2.1 Default Encoding: GML Application Schema

Format name: Road Transport Networks GML Application Schema Version of the format: 3.0, GML, version 3.2.1 Reference to the specification of the format: ISO 19136:2007 Character set: UTF-8

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 154

The GML Application Schema is distributed in a zip-file separately from the data specification document.

9.2.3 Encoding for application schema of Rail transport networks

Requirement 23 Data conformant to the application schema of Rail transport networks shall be encoded using the encoding specified in section 9.2.3.1.

9.2.3.1 Default Encoding: GML Application Schema

Format name: Rail Transport Networks GML Application Schema Version of the format: 3.0, GML, version 3.2.1 Reference to the specification of the format: ISO 19136:2007 Character set: UTF-8 The GML Application Schema is distributed in a zip-file separately from the data specification document.

9.2.4 Encoding for application schema of Cable transport networks

Requirement 24 Data conformant to the application schema of Cable transport networks shall be encoded using the encoding specified in section 9.2.4.1.

9.2.4.1 Default Encoding: GML Application Schema

Format name: Cable Transport Networks GML Application Schema Version of the format: 3.0, GML, version 3.2.1 Reference to the specification of the format: ISO 19136:2007 Character set: UTF-8 The GML Application Schema is distributed in a zip-file separately from the data specification document.

9.2.5 Encoding for application schema of Water transport networks

Requirement 25 Data conformant to the application schema of Water transport networks shall be encoded using the encoding specified in section 9.2.5.1.

9.2.5.1 Default Encoding: GML Application Schema

Format name: Water Transport Networks GML Application Schema Version of the format: 3.0, GML, version 3.2.1 Reference to the specification of the format: ISO 19136:2007 Character set: UTF-8 The GML Application Schema is distributed in a zip-file separately from the data specification document.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 155

9.2.6 Encoding for application schema of Air transport networks

Requirement 26 Data conformant to the application schema of Air transport networks shall be encoded using the encoding specified in section 9.2.6.1.

9.2.6.1 Default Encoding: GML Application Schema

Format name: Air Transport Networks GML Application Schema Version of the format: 3.0, GML, version 3.2.1 Reference to the specification of the format: ISO 19136:2007 Character set: UTF-8 The GML Application Schema is distributed in a zip-file separately from the data specification document.

10 Data Capture
The topics in this chapter highlight specific cases that require specific attention in collecting and assembling data and information that constitutes the components of Transport networks (Road, Rail, Cable, Water and Air).

10.1 Centrelines
The primary way of representing a network is by a centreline (ie a line that approximates the centre of the real world object. It would be prohibitively expensive and impracticable to faithfully record the true centreline since this would result in an irregular line and far too many data points. Therefore a pragmatic approach is often taken which results in a much smoother line requiring the minimum number of data points to represent the object. However problems can arise when too few points are used and the line will no longer be smooth or useful in most applications. Equally the centreline may often be combined with (topographic) area objects e.g. the paved or metalled surface, or track. It may also be combined with other themes (e.g. run closely adjacent to a river or another form of transport (railway and road in a narrow gorge for example). It is therefore important that the centreline falls within the physical boundary of the object it represents. Requirement 27 The centrelines of Road and Rail objects shall fall within the extent of the physical real world object that they represent (as illustrated in Figure 41).

Not acceptable The centreline falls outside the real world object

Acceptable The centreline falls inside the real world object

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 156

Not acceptable The centreline falls outside the real world object

Not acceptable The centreline falls inside the real world object but does not follow the shape faithfully.

Acceptable The centreline falls inside the real world object and while it does not follow the exact centreline it is acceptable

Figure 41 Acceptable and non acceptable forms of centreline representation.

10.2 Ensuring Network Connectivity

This data specification does not incorporate a topological model for the reasons given in Chapters 4 and 5.1.1.1. Since a users system will build the topology for an application it is essential that the data is captured in such a way that this topology build can be undertaken automatically, repeatedly and faultlessly each time. Therefore the data has to be supplied to the user with topology implicit in the structure (ie it must be clean). This implicit topology is based on coincidence which does not have to be absolute but relies on a connectivity tolerance. This connectivity tolerance will be supplied as metadata with the transport data. (see Section 8.1.5) When automatically constructing topological relationships: All points, nodes, vertices and link ends that are located at a distance of less than the connectivity tolerance of each other are considered to coincide, All points, nodes, vertices and link ends that are located at a distance of more than the connectivity tolerance of each other are considered not to coincide. To ensure automatic and unambiguous creation of centreline topology: All link ends and the optional node that take part in a connection have to be positioned at a distance of less than the connectivity tolerance from each other, Link ends and nodes that are not connected shall always be separated by a distance that is greater than the connectivity tolerance. This will ensure the correct connectivity between links and the nodes in the system. Supporting quality criteria will be found in Section 7.2.4

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 157

Requirement 28

Wherever a connection exists in a transport network, all connected link ends and the optional node that take part in this connection have to be positioned at a distance of less than the connectivity tolerance from each other.

Requirement 29

Link ends and nodes that are not connected shall always be separated by a distance that is greater than the connectivity tolerance.

Requirement 30

In datasets where both transport links and nodes are present, the relative position of nodes and link ends in relation to the specified connectivity tolerance shall correspond to the associations that exist between them in the dataset. Acceptable The perfect case where the node and all link ends share the same coordinates.

Acceptable The three link ends (a, b and c) and the node are all within a distance of less than the connectivity tolerance (indicated by the blue circle). All of these elements will be assumed connected during an automatic topology build.

Not acceptable The three link ends (a, b and c) and the node are all within a distance of less than the connectivity tolerance. Link end (d) lies within a distance of less than the connectivity tolerance from link end (c), but at a distance greater than the tolerance from link ends (a) and (b) and the transport node. The connectivity is ambiguous and the topology building would fail. Acceptable (but possible error) The three link ends (a, b and c) and the node are all within a distance of less than the connectivity tolerance and will be assumed connected during an automatic topology build. Link end (d) is at a distance greater than the tolerance from all three link ends and the node. It will be considered not connected (dangle). Note: while this is an acceptable situation for automatic topology build, it can constitute an error in the data: if, in reality, (d) is connected to (a), (b) and (c) it should be moved to within the tolerance distance from all three link ends and the node.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 158

Figure 42 Acceptable and unacceptable positioning of link ends and nodes.

10.3 Linear Referencing

Linear referencing as defined in the draft ISO 19148 will be adopted and aligned with the GNM (and hence this data specification) with after it reaches DIS status, The adoption in the Transport networks data specification is limited to a simple model at this stage. In general it is expected that linear referencing will be used to model the relationships of objects that are associated with an network, but where the position of those associated objects is not known (or required) to a very high level of absolute accuracy ~ better than 1-3m at local level (e.g. traffic accidents, planned works, restrictions). The position of centrelines and nodes in a network in many cases will vary from the true position (since the centreline is rarely that and the node is not a tangible physical feature or location (see 10.1 above). Where absolute accuracy is required (e.g. the location of drain covers, excavations, line side signalling equipment, masts etc) such objects should be reused, and referenced, if they already exist e.g. as topographic features.

10.4 Alternative and Multiple Representations

Alternative and multiple representations are discussed further in Annex B.1. Alternative Representations Where centreline and topographic area objects coexist it is important that users holding information on one of these forms can share information with another e.g. details of a planned excavation at the topographic level with the corresponding centreline representation to plan diversions during the time of the works. It is important therefore that these alternative representations are well synchronised and follow the requirement in 10.1. Cross referencing them will support easy and unambiguous data exchange and support synchronised maintenance (see Annex B.1) which ever organisation is responsible for the alternative forms. Recommendation 16 Alternative representations should be cross referenced to support data sharing and synchronised maintenance. Multiple Representations In this sense the different resolutions may extend from the local to European level in a number of steps (levels of detail). An ideal model is described in D2.6 A.19 but has yet to be fully developed and realised. At the moment transforming existing vector datasets, at different levels of detail, beyond the local level to this data specification will not necessarily result in a set of harmonised transport networks for each of the themes Road, Rail, Water (this will be dependent on the Hydrography specification) and Air (where there are probably fewer levels of detail). Nevertheless as a step towards a more harmonised model users should aim to collect their own application data and hold that once and reference it to each corresponding level of detail (rather than embed the application data in the local or intermediate level). This will promote reuse, easier data sharing and make national and European reporting (through aggregation) easier. Recommendation 17 As a step towards a more harmonised set of levels of detail, users should hold their application data once and simply reference this to each level of detail in a network.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 159

11 Portrayal
This clause defines the rules for layers and styles to be used for portrayal of the spatial object types defined for this theme. In section 11.1, the types of layers are defined that are to be used for the portrayal of the spatial object types defined in this specification. A view service may offer several layers of the same type, one for each dataset that it offers on a specific topic. Section 11.2 specifies the default styles to be used for each of these layer types, while section 11.3 specifies other well-defined styles. The XML fragments in these sections use the following namespace prefixes: sld="http://www.opengis.net/sld" (WMS/SLD 1.1) se="http://www.opengis.net/se" (SE 1.1) ogc="http://www.opengis.net/ogc" (FE 1.1) Transport Networks can be styled using basic geometry types expressed below in section 11.1. These styles can be broken down further by organizations based upon furthering requirements as necessary. Below are some recommended stylings to allow basic visualisation.

11.1 Layer Types

If an INSPIRE view services supports the portrayal of data related to the theme Transport Networks, it shall provide layers of the types specified in this section.

Requirement 31

Table 18: Layer types for the spatial data theme Transport Networks Layer Type TN.CommonTransport Elements.TransportNo de TN.CommonTransport Elements.TransportLin k TN.CommonTransport Elements.TransportAre a TN.RoadTransportNet work.RoadLink TN.RoadTransportNet work.VehicleTrafficAre a TN.RoadTransportNet work.RoadServiceArea TN.RoadTransportNet work.RoadArea TN.RailTransportNetwo Layer Title Generic Transport Node Default Style Generic Transport Link Default Style Generic Transport Area Default Style RoadLink default Style Vehicle traffic Area Default Style Spatial object type(s) Transport Node Transport Link Area RoadLink VehicleTrafficArea Keywords Generic Transport Node, default style, Transport Networks. Generic Transport Node, default style, Transport Networks. Generic Transport Area, default style, Transport Networks. Transport Networks, RoadLink, Default Style Transport Network, Road Transport Network, Vehicle Traffic Area, Default Style Transport Network, Road Transport Network,Road Service Area, Default Style Transport Network, Road Transport Network, Road Area, Default Style Transport Network, Rail

Road Service Area Default Style Road Area Default Style Railway Link Default

RoadServiceArea

RoadArea

RailwayLink

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 160

rk.RailwayLink TN.RailTransportNetwo rk.RailwayStationArea TN.RailTransportNetwo rk.RailwayYardArea TN.RailTransportNetwo rk.RailwayArea TN.WaterTransportNet work.WaterwayLink TN.WaterTransportNet work.FairwayArea TN.WaterTransportNet work.PortArea TN.AirTransportNetwor k.AirLink TN.AirTransportNetwor k.AerodromeArea TN.AirTransportNetwor k.RunwayArea TN.AirTransportNetwor k.AirSpaceArea TN.AirTransportNetwor k.ApronArea TN.AirTransportNetwor k.TaxiwayArea TN.CableTransportNet work.CablewayLink

Style Railway Station Area Default Style Railway Yard Area Default Style RailwayArea RailwayStationArea

RailwayYardAreaDefau ltStyle RailwayAreaDefaultStyl e WaterwayLinkDefaultSt yle FairwayAreaDefaultStyl e PortAreaDefaultStyle

Waterway Link Default Style Fairway Area Default Style Port Area Default Style

Air Link Default Style Aerodrome Area Default Style Runway Area Default Style Air Space Area Default Style Apron Area Default Style Taxiway Area Default Style Cableway Link Default Style

AirLinkDefaultStyle AerodromeAreaDefault Style RunwayAreaDefaultSty le AirSpaceAreaDefaultSt yle ApronAreaDefaultStyle

TaxiwayAreaDefaultSty le CableLinkDefaultStyle

Transport Network, Railway Link, Default Style Transport Network, Rail Transport Network, Railway Station Area, Default Style Transport Network, Rail Transport Network, Railway Yard Area, Default Style Transport Network, Rail Transport Network, Railway Area, Default Style Transport Network, Water Transport Network, Waterway Link, Default Style Transport Network, Water Transport Network, Fairway Area, Default Style Transport Network, Water Transport Network, Port Area, Default Style Transport Network, Air Transport Network, Air Link, Default Style Transport Network, Air Transport Network, Aerodrome Area, Default Style Transport Network, Air Transport Network, Runway Area, Default Style Transport Network, Air Transport Network, Air Space Area, Default Style Transport Network, Air Transport Network, Apron Area, Default Style Transport Network, Air Transport Network, Taxi Runway Area, Default Style Transport Network, Cable Transport Network, Cable Link, Default Style

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 161

11.2 Default Styles

Requirement 32 If an INSPIRE view network service supports the portrayal of spatial data sets corresponding to the spatial data theme Transport Networks, it shall support the default styles specified in the tables in this section. If no user-defined style is specified in a portrayal request for a specific layer to an INSPIRE view service, the default style specified in this section for that layer shall be used.

Table 19: Default styles for the spatial data theme Transport Networks Layer Name Style Name Style Title Style Description Symbology TN.CommonTransportElements.TransportNode TN.CommonTransportElements.TransportNode.Default Generic Transport Node Default Style The geometry is rendered as a circle with a size of 3 pixels, with a red (#FF0000) fill and a black outline (#000000).
<sld:NamedLayer> <se:Name>TN.CommonTransportElements.TransportNode</se:Name> <sld:UserStyle> <se:Name> TN.CommonTransportElements.TransportNode.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Generic Node Default Style</se:Title> <se:Abstract>The geometry is rendered as a circle with a size of 3 pixels, with a red (#FF0000) fill and a black outline (#000000).</se:Abstract> </se:Description> <se:FeatureTypeName>Network:Node</se:FeatureTypeName> <se:Rule> <se:PointSymbolizer> <se:Geometry> <ogc:PropertyName>Network:geometry </ogc:PropertyName> </se:Geometry> <se:Graphic/> </se:PointSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description

TN.CommonTransportElements.TransportLink TN.CommonTransportElements.TransportLink.Default Generic Transport Link Default Style The geometry is rendered as a solid Black line with a stroke width of 3 pixel (#000000). Ends are rounded and have a 2 pixel black casing (#000000).

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 162

Symbology

<sld:NamedLayer> <se:Name>TN.CommonTransportElements.TransportLink</se:Name> <sld:UserStyle> <se:Name> TN.CommonTransportElements.TransportLink.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Generic Link Default Style</se:Title> <se:Abstract> The geometry is rendered as a solid Black line with a stroke width of 3 pixel (#000000). Ends are rounded and have a 2 pixel black casing (#000000).</se:Abstract> </se:Description> <se:FeatureTypeName>Network:Link</se:FeatureTypeName> <se:Rule> <se:LineSymbolizer> <se:Geometry> <ogc:PropertyName>Network:centerlineGeometry </se:Geometry> <se:Stroke/> </se:LineSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description Symbology

TN.CommonTransportElements.TransportArea TN.CommonTransportElements.TransportArea.Default Generic Transport Area Default Style The geometry is rendered using a grey (#A9A9A9) fill and a solid black (#000000) outline with a stroke width of 1 pixel.
<sld:NamedLayer> <se:Name>TN.CommonTransportElements.TransportArea</se:Name> <sld:UserStyle> <se:Name> TN.CommonTransportElements.TransportArea.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Generic Area Default Style</se:Title> <se:Abstract>The geometry is rendered using a grey (#A9A9A9) fill and a solid black (#000000) outline with a stroke width of 1 pixel.</se:Abstract> </se:Description> <se:FeatureTypeName>Network:Area</se:FeatureTypeName> <se:Rule> <se:PolygonSymbolizer> <se:Geometry> <ogc:PropertyName>Network:geometry</ogc:PropertyName> </se:Geometry> <se:Fill/> <se:Stroke/> </se:PolygonSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description

TN.RoadTransportNetwork.RoadLink TN.RoadTransportNetwork.RoadLink.Default RoadLink Default Style The geometry is rendered as a solid green line with a stroke width of 3 pixel (#008000). Ends are rounded and have a 2 pixel black casing (#000000).

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 163

Symbology

<sld:NamedLayer> <se:Name>TN.RoadTransportNetwork.RoadLink</se:Name> <sld:UserStyle> <se:Name> TN.RoadTransportNetwork.RoadLink.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>RoadLink Default Style</se:Title> <se:Abstract> The geometry is rendered as a solid Green line with a stroke width of 3 pixel (#008000). Ends are rounded and have a 2 pixel black casing (#000000).</se:Abstract> </se:Description> <se:FeatureTypeName>TN:RoadLink</se:FeatureTypeName> <se:Rule> <se:LineSymbolizer> <se:Geometry> <ogc:PropertyName>Network:centrelineGeometry </ogc:PropertyName> </se:Geometry> <se:Stroke/> </se:LineSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description Symbology

TN.RoadTransportNetwork.RoadServiceArea TN.RoadTransportNetwork.RoadServiceArea.Default Road Service Area Default Style The geometry is rendered using a grey (#A9A9A9) fill and a solid black (#000000) outline with a stroke width of 1 pixel.
<sld:NamedLayer> <se:Name>TN.RoadTransportNetwork.RoadServiceArea</se:Name> <sld:UserStyle> <se:Name> TN.RoadTransportNetwork.RoadServiceArea.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Road Service Area Default Style</se:Title> <se:Abstract>The geometry is rendered using a grey (#A9A9A9) fill and a solid black (#000000) outline with a stroke width of 1 pixel.</se:Abstract> </se:Description> <se:FeatureTypeName>TN:RoadServiceArea</se:FeatureTypeName> <se:Rule> <se:PolygonSymbolizer> <se:Geometry> <ogc:PropertyName>Network:geometry</ogc:PropertyName> </se:Geometry> <se:Fill/> <se:Stroke/> </se:PolygonSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description

TN.RoadTransportNetwork.RoadArea TN.RoadTransportNetwork.RoadArea.Default Road Area Default Style The geometry is rendered using a grey (#A9A9A9) fill and a solid black (#000000) outline with a stroke width of 1 pixel.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 164

Symbology

<sld:NamedLayer> <se:Name>TN.RoadTransportNetwork.RoadArea</se:Name> <sld:UserStyle> <se:Name> TN.RoadTransportNetwork.RoadArea.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Road Area Default Style</se:Title> <se:Abstract>The geometry is rendered using a grey (#A9A9A9) fill and a solid black (#000000) outline with a stroke width of 1 pixel.</se:Abstract> </se:Description> <se:FeatureTypeName>TN:RoadArea</se:FeatureTypeName> <se:Rule> <se:PolygonSymbolizer> <se:Geometry> <ogc:PropertyName>Network:geometry</ogc:PropertyName> </se:Geometry> <se:Fill/> <se:Stroke/> </se:PolygonSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description Symbology

TN.RoadTransportNetwork.VehicleTrafficArea TN.RoadTransportNetwork.VehicleTrafficArea.Default Vehicle Traffic Area Default Style The geometry is rendered using a grey (#A9A9A9) fill and a solid black (#000000) outline with a stroke width of 1 pixel.
<sld:NamedLayer> <se:Name>TN.RoadTransportNetwork.VehicleTrafficArea</se:Name> <sld:UserStyle> <se:Name> TN.RoadTransportNetwork.VehicleTrafficArea.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Vehicle Traffic Area Default Style</se:Title> <se:Abstract>The geometry is rendered using a grey (#A9A9A9) fill and a solid black (#000000) outline with a stroke width of 1 pixel.</se:Abstract> </se:Description> <se:FeatureTypeName>TN:VehicleTrafficArea</se:FeatureTypeName> <se:Rule> <se:PolygonSymbolizer> <se:Geometry> <ogc:PropertyName>Network:geometry</ogc:PropertyName> </se:Geometry> <se:Fill/> <se:Stroke/> </se:PolygonSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description

TN.RailTransportNetwork.RailwayLink TN.RailTransportNetwork.RailwayLink.Default Railway Link Default Style The geometry is rendered as a solid Black line with a stroke width of 3 pixel (#000000). Ends are rounded and have a 2 pixel black casing (#000000).

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 165

Symbology

<sld:NamedLayer> <se:Name>TN.RailTransportNetwork.RailwayLink</se:Name> <sld:UserStyle> <se:Name> TN.RailTransportNetwork.RailwayLink.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Railway Link Default Style</se:Title> <se:Abstract> The geometry is rendered as a solid Black line with a stroke width of 3 pixel (#000000). Ends are rounded and have a 2 pixel black casing (#000000).</se:Abstract> </se:Description> <se:FeatureTypeName>TN:RailwayLink</se:FeatureTypeName> <se:Rule> <se:LineSymbolizer> <se:Geometry> <ogc:PropertyName>Network:centerlineGeometry </ogc:PropertyName> </se:Geometry> <se:Stroke/> </se:LineSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description Symbology

TN.RailTransportNetwork.RailwayStationArea TN.RailTransportNetwork.RailwayStationArea.Default Railway Station Area Default Style The geometry is rendered using a Brown (#8B4513) fill and a solid black (#000000) outline with a stroke width of 1 pixel.
<sld:NamedLayer> <se:Name>TN.RailTransportNetwork.RailwayStationArea</se:Name> <sld:UserStyle> <se:Name> TN.RailTransportNetwork.RailwayStationArea.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Railway Station Area</se:Title> <se:Abstract> The geometry is rendered using a Brown (#8B4513) fill and a solid black (#000000) outline with a stroke width of 1 pixel.</se:Abstract> </se:Description> <se:FeatureTypeName>TN:RailwayStationArea</se:FeatureTypeName> <se:Rule> <se:PolygonSymbolizer> <se:Geometry> <ogc:PropertyName>Network:geometry</ogc:PropertyName> </se:Geometry> <se:Fill/> <se:Stroke/> </se:PolygonSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description

TN.RailTransportNetwork.RailwayYardArea TN.RailTransportNetwork.RailwayYardArea.Default Railway Yard Area Default Style The geometry is rendered using a Brown (#8B4513) fill and a solid black (#000000) outline with a stroke width of 1 pixel.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 166

Symbology

<sld:NamedLayer> <se:Name>TN.RailTransportNetwork.RailwayYardArea</se:Name> <sld:UserStyle> <se:Name> TN.RailTransportNetwork.RailwayYardArea.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Railway Yard Area Default Style</se:Title> <se:Abstract>The geometry is rendered using a Brown (#8B4513) fill and a solid black (#000000) outline with a stroke width of 1 pixel.</se:Abstract> </se:Description> <se:FeatureTypeName>TN:RailwayYardArea</se:FeatureTypeName> <se:Rule> <se:PolygonSymbolizer> <se:Geometry> <ogc:PropertyName>Network:geometry</ogc:PropertyName> </se:Geometry> <se:Fill/> <se:Stroke/> </se:PolygonSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description Symbology

TN.RailTransportNetwork.RailwayArea TN.RailTransportNetwork.RailwayArea.Default Railway Area Default Style The geometry is rendered using a Brown (#8B4513) fill and a solid black (#000000) outline with a stroke width of 1 pixel.
<sld:NamedLayer> <se:Name>TN.RailTransportNetwork.RailwayArea</se:Name> <sld:UserStyle> <se:Name> TN.RailTransportNetwork.RailwayArea.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Railway Yard Area Default Style</se:Title> <se:Abstract>The geometry is rendered using a Brown (#8B4513) fill and a solid black (#000000) outline with a stroke width of 1 pixel.</se:Abstract> </se:Description> <se:FeatureTypeName>TN:RailwayYardArea</se:FeatureTypeName> <se:Rule> <se:PolygonSymbolizer> <se:Geometry> <ogc:PropertyName>Network:geometry</ogc:PropertyName> </se:Geometry> <se:Fill/> <se:Stroke/> </se:PolygonSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description

TN.WaterTransportNetwork.WaterwayLink TN.WaterTransportNetwork.WaterwayLink.Default Waterway Link Default Style The geometry is rendered as a solid Violet line with a stroke width of 3 pixel (#EE82EE). Ends are rounded and have a 2 pixel black casing (#000000).

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 167

Symbology

<sld:NamedLayer> <se:Name>TN.WaterTransportNetwork.WaterwayLink</se:Name> <sld:UserStyle> <se:Name> TN.WaterTransportNetwork.WaterwayLink.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Waterway Link Default Style</se:Title> <se:Abstract>The geometry is rendered as a solid violet line with a stroke width of 3 pixel (#EE82EE). Ends are rounded and have a 2 pixel black casing (#000000).</se:Abstract> </se:Description> <se:FeatureTypeName>TN:WaterwayLink</se:FeatureTypeName> <se:Rule> <se:LineSymbolizer> <se:Geometry> <ogc:PropertyName>Network:centerlineGeometry</ogc:PropertyName> </se:Geometry> <se:Stroke/> </se:LineSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description Symbology

TN.WaterTransportNetwork.FairwayArea TN.WaterTransportNetwork.FairwayArea.Default Fairway Area default style The geometry is rendered using a Blue (#4169E1) fill and a solid black (#000000) outline with a stroke width of 1 pixel.
<sld:NamedLayer> <se:Name>TN.WaterTransportNetwork.FairwayArea</se:Name> <sld:UserStyle> <se:Name> TN.WaterTransportNetwork.FairwayArea.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Fairway Area Default Style</se:Title> <se:Abstract>The geometry is rendered using a Blue (#4169E1) fill and a solid black (#000000) outline with a stroke width of 1 pixel.</se:Abstract> </se:Description> <se:FeatureTypeName>TN:FairwayArea</se:FeatureTypeName> <se:Rule> <se:PolygonSymbolizer> <se:Geometry> <ogc:PropertyName>Network:geometry</ogc:PropertyName> </se:Geometry> <se:Fill/> <se:Stroke/> </se:PolygonSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description

TN.WaterTransportNetwork.PortArea TN.WaterTransportNetwork.PortArea.Default Port Area default style The geometry is rendered using a Grey (#696969) fill and a solid black (#000000) outline with a stroke width of 1 pixel.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 168

Symbology

<sld:NamedLayer> <se:Name>TN.WaterTransportNetwork.PortArea</se:Name> <sld:UserStyle> <se:Name> TN.WaterTransportNetwork.PortArea.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Port Area Default Style</se:Title> <se:Abstract>The geometry is rendered using a Grey (#696969) fill and a solid black (#000000) outline with a stroke width of 1 pixel.</se:Abstract> </se:Description> <se:FeatureTypeName>TN:PortArea</se:FeatureTypeName> <se:Rule> <se:PolygonSymbolizer> <se:Geometry> <ogc:PropertyName>Network:geometry</ogc:PropertyName> </se:Geometry> <se:Fill/> <se:Stroke/> </se:PolygonSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description Symbology

TN.AirTransportNetwork.AirLink TN.AirTransportNetwork.AirLink.Default Air Link default style The geometry is rendered as a solid Maroon line with a stroke width of 3 pixel (#800000). Ends are rounded and have a 2 pixel black casing (#000000).
<sld:NamedLayer> <se:Name>TN.AirTransportNetwork.AirLink</se:Name> <sld:UserStyle> <se:Name> TN.AirTransportNetwork.AirLink.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>AirAir Link Default Style</se:Title> <se:Abstract> The geometry is rendered as a solid Maroon line with a stroke width of 3 pixel (#800000). Ends are rounded and have a 2 pixel black casing (#000000).</se:Abstract> </se:Description> <se:FeatureTypeName>TN:AirLink</se:FeatureTypeName> <se:Rule> <se:LineSymbolizer> <se:Geometry> <ogc:PropertyName>Network:centerlineGeometry</ogc:PropertyName> </se:Geometry> <se:Stroke/> </se:LineSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description

TN.AirTransportNetwork.AerodromeArea TN.AirTransportNetwork.AerodromeArea.Default Aerodrome Area default style The geometry is rendered using a 50% Blue (#0000CD) fill and a solid Blue (#0000CD)outline with a stroke width of 1 pixel.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 169
<sld:NamedLayer> <se:Name>TN.AirTransportNetwork.AerodromeArea</se:Name> <sld:UserStyle> <se:Name> TN.AirTransportNetwork.AerodromeArea.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Aerodrome Area Default Style</se:Title> <se:Abstract>The geometry is rendered using a 50% Blue (#0000CD) fill and a solid Blue (#0000CD)outline with a stroke width of 1 pixel.</se:Abstract> </se:Description> <se:FeatureTypeName>TN:AerodromeArea</se:FeatureTypeName> <se:Rule> <se:PolygonSymbolizer> <se:Geometry> <ogc:PropertyName>Network:geometry</ogc:PropertyName> </se:Geometry> <se:Fill/> <se:Stroke/> </se:PolygonSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Symbology

Layer Name Style Name Style Title Style Description Symbology

TN.AirTransportNetwork.RunwayArea TN.AirTransportNetwork.RunwayArea.Default Runway Area default style The geometry is rendered using a White (#FFFFFF) fill and a solid Blue (#0000CD)outline with a stroke width of 2 pixel.
<sld:NamedLayer> <se:Name>TN.AirTransportNetwork.RunwayArea</se:Name> <sld:UserStyle> <se:Name> TN.AirTransportNetwork.RunwayArea.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Runway Area Default Style</se:Title> <se:Abstract>The geometry is rendered using a White (#FFFFFF) fill and a solid Blue (#0000CD)outline with a stroke width of 2 pixel.</se:Abstract> </se:Description> <se:FeatureTypeName>TN:RunwayArea</se:FeatureTypeName> <se:Rule> <se:PolygonSymbolizer> <se:Geometry> <ogc:PropertyName>Network:geometry</ogc:PropertyName> </se:Geometry> <se:Fill/> <se:Stroke/> </se:PolygonSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description

TN.AirTransportNetwork.AirSpaceArea TN.AirTransportNetwork.AirSpaceArea.Default Air Space Area Default Style The geometry is rendered using a 25% Megenta (#8B008B) fill and a solid Megenta (#8B008B) outline with a stroke width of 2 pixel.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 170
<sld:NamedLayer> <se:Name>TN.AirTransportNetwork.AirspaceArea</se:Name> <sld:UserStyle> <se:Name> TN.AirTransportNetwork.AirSpaceArea.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Airspace Area Default Style</se:Title> <se:Abstract>The geometry is rendered using a 25% Megenta (#8B008B) fill and a solid Megenta (#8B008B) outline with a stroke width of 2 pixel.</se:Abstract> </se:Description> <se:FeatureTypeName>TN:AirspaceArea</se:FeatureTypeName> <se:Rule> <se:PolygonSymbolizer> <se:Geometry> <ogc:PropertyName>Network:geometry</ogc:PropertyName> </se:Geometry> <se:Fill/> <se:Stroke/> </se:PolygonSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Symbology

Layer Name Style Name Style Title Style Description Symbology

TN.AirTransportNetwork.ApronArea TN.AirTransportNetwork.ApronArea.Default Apron Area Default Style The geometry is rendered using a 50% grey (#808080) fill and a solid black outline with a stroke width of 1 pixel.
<sld:NamedLayer> <se:Name>TN.AirTransportNetwork.ApronArea</se:Name> <sld:UserStyle> <se:Name> TN.AirTransportNetwork.ApronArea.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Apron Area Default Style</se:Title> <se:Abstract>The geometry is rendered using a 50% grey (#808080) fill and a solid black outline with a stroke width of 1 pixel.</se:Abstract> </se:Description> <se:FeatureTypeName>TN:ApronArea</se:FeatureTypeName> <se:Rule> <se:PolygonSymbolizer> <se:Geometry> <ogc:PropertyName>Network:geometry</ogc:PropertyName> </se:Geometry> <se:Fill/> <se:Stroke/> </se:PolygonSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description

TN.AirTransportNetwork.TaxiwayArea TN.AirTransportNetwork.TaxiwayArea.Default Taxiway Area Default Style The geometry is rendered using a Blue (#B0E0E6) fill and a solid black outline with a stroke width of 1 pixel.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 171

Symbology

<sld:NamedLayer> <se:Name>TN.AirTransportNetwork.TaxiwayArea</se:Name> <sld:UserStyle> <se:Name> TN.AirTransportNetwork.TaxiwayArea.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>Taxiway Area Default Style</se:Title> <se:Abstract>The geometry is rendered using a Blue (#B0E0E6) fill and a solid black outline with a stroke width of 1 pixel.</se:Abstract> </se:Description> <se:FeatureTypeName>TN:TaxiwayArea</se:FeatureTypeName> <se:Rule> <se:PolygonSymbolizer> <se:Geometry> <ogc:PropertyName>Network:geometry</ogc:PropertyName> </se:Geometry> <se:Fill/> <se:Stroke/> </se:PolygonSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

Layer Name Style Name Style Title Style Description Symbology

TN.CableTransportNetwork.CablewayLink TN.CableTransportNetwork.CablewayLink.Default Cable Transport Network default style The geometry is rendered as a solid Black line with a stroke width of 3 pixel (#B10787). Ends are rounded and have a 2 pixel black casing (#000000).
<sld:NamedLayer> <se:Name>TN.CableTransportNetwork.CablewayLink</se:Name> <sld:UserStyle> <se:Name> TN.CableTransportNetwork.CablewayLink.Default</se:Name> <sld:IsDefault>1</sld:IsDefault> <se:FeatureTypeStyle version="1.1.0"> <se:Description> <se:Title>CableTransportNetworkDefaultStyle</se:Title> <se:Abstract> The geometry is rendered as a solid Black line with a stroke width of 3 pixel (#B10787). Ends are rounded and have a 2 pixel black casing (#000000).</se:Abstract> </se:Description> <se:FeatureTypeName>CablewayLink</se:FeatureTypeName> <se:Rule> <se:LineSymbolizer> <se:Geometry> <ogc:PropertyName>Network:centerlineGeometry</ogc:PropertyName> </se:Geometry> <se:Stroke/> </se:LineSymbolizer> </se:Rule> </se:FeatureTypeStyle> </sld:UserStyle> </sld:NamedLayer>

11.3 Other Well-defined Styles

Requirement 33 If an INSPIRE view service supports the portrayal of spatial data sets corresponding to the spatial data themes Transport Networks, apart from the

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 172

default styles specified in Section 11.2, it shall also support the well-defined styles specified in this section. There are no Well-defined Styles specified at this time

11.4 Layers organization

There are no Layers organisation are specified at this time

12 Bibliography
The following documents were used in the analysis and formation of this data specification. Not all these are publically available. However they all provided valuable source material for reference. Where available and known, web-links are provided. Alternatively initial reference locations are provided. Where these are not available it is suggested that the reader consults the member state coordinating body concerned - should they require access to the material. 1n1005 - DBPrior10k Intesa GIS, Italy http://www.centrointerregionale-gis.it/script/scrp.asp?Pagecode=002 1n1007_1 - Specifications for producing general Topographic Data Base - Layers, Themes, Classes Intesa GIS, Italy http://www.centrointerregionale-gis.it/script/scrp.asp?Pagecode=002 1n1007_3 - Specifiche per la realizzazione dei Database Topografici di interesse generale, Specifiche di contenuto: La presentazione cartografica. Intesa GIS, Italy http://www.centrointerregionale-gis.it/script/scrp.asp?Pagecode=002 Additional Military Layers NATO http://defence.ukho.gov.uk/content/addAttachments/AML/Product%20Specs/AML_PS_Corrigenda_ 1.pdf Aeronautical Information Exchange Federal Aviation Authority http://www.faa.gov/AIXM/ Airspace: Email exchange with the Civil Aviation Authority for the UK TWG TN Records [not publically available]

AIXM3.3ConceptualModel http://www.aixm.aero AIXM5.0ConceptualModel http://www.aixm.aero

ATKIS Feature catalogue chapter D3 : DLM250 Working Committee of the State Survey Offices of the Federal Republic of Germany AdV, Germany http://www.geodatenzentrum.de/geodaten/gdz_rahmen.gdz_div?gdz_spr=eng&gdz_akt_zeile=2&g dz_anz_zeile=3&gdz_user_id=0

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 173

ATKIS Feature catalogue chapter D4 : DLM1000 Working Committee of the State Survey Offices of the Federal Republic of Germany AdV, Germany http://www.geodatenzentrum.de/geodaten/gdz_rahmen.gdz_div?gdz_spr=eng&gdz_akt_zeile=2&g dz_anz_zeile=3&gdz_user_id=0 BD Carto Descriptif technique IGN France www.ign.france BD TOPO v2.0 - Content description - IGN France (May 2008) www.ign.france BD Topo version 3.1 descriptif technique IGN France www.ign.france BTN25 Concise Technical Specification National Geographic Institute (Spain) www.ign.es Candidate OpenGIS CityGML Implementation Specification Open Geospatial Consortium, Inc. www.opengeospatial.org

CEMTResolutionNo.92/2onNewClassificationofInlandWaterways http://www.internationaltransportforum.org/europe/acquis/wat19922e.pdf
COUNCIL DIRECTIVE of 27 June 1985 on the assessment of the effects of certain public and private projects on the environment (85/337/EEC) (OJ L 175, 5.7.1985, p. 40)

http://ec.europa.eu/environment/eia/full-legal-text/85337.htm Data Base Topografico alle grandi scale (1:1.000 - 1:2.000 - 1:5.000) Regione Emilia-Romagna, Italy
DECISION No 884/2004/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 29 April 2004 amending Decision No 1692/96/EC on Community guidelines for the development of the trans-European transport network

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2004:167:0001:0038:EN:PDF Document de doctrine sur la notion de rfrentiel CNIG, France www.cnig.gouv.fr Draft EuroSpec Feature Catalogue for topographic data Transport EuroGeographics www.eurogeographics.org EC DS-D2.3 INSPIRE DS-D2.3, Definition of Annex Themes and Scope, v3.0, http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.3_Definition_of_An nex_Themes_and_scope_v3.0.pdf EC DS-D2.5 INSPIRE DS-D2.5, Generic Conceptual Model, v3.1, http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.5_v3.1.pdf EC DS-D2.6 INSPIRE DS-D2.6, Methodology for the development of data specifications, v3.0, http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.6_v3

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 174

.0.pdf EC DS-D2.7 INSPIRE DS-D2.7, Guidelines for the encoding of spatial data, v3.0, http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.7_v3 .0.pdf EC DS-D2.8.I.3 INSPIRE DS-D2.8.I.3, INSPIRE Data Specifiications on Geographical Names Guidelines, v3.0 EDC-11031 EuroRegioMap EuroRegionalMap: Incremental Development of a Pan-European Database at Medium Scale EuroGeographics ftp://ftp.ign.fr/ign/INSPIRE/ERM_Updating_report.doc EGM Specifications EuroGeographics, www.eurogeographics.org ERM Data Model EuroGeographics www.eurogeographics.org ERM Specifications and data catalogue http://www.ngi.be/ ERM Technical Guide EuroGeographics www.eurogeographics.org Especificaciones de la Base Topogrfica Armonizada 1:5000 (BTA) v1.0 National Geographic High Council Cartociudad specifications Instituto Geogrfico Nacional (Spain) www.ign.es Especificaciones tcnicas de la Base topogrfica de Catalunya 1:25000 (BT25M) v1.0 Institut Cartogrfic de Catalunya, Spain http://www.icc.es/web/content/ca/index.html EUROCONTROL: Traffic flow and management www.eurocontrol.int European Commission STAFF WORKING DOCUMENT Accompanying document to the COMMUNICATION FROM THE COMMISSION Trans-European Networks : Toward and integrated approach {COM(2007) 135 final} Brussels, 21.3.2007 SEC(2007) 374 http://europa.eu/legislation_summaries/transport/intermodality_transeuropean_networks/l24481_en .htm European Commission: DRAFT Guidelines INSPIRE Data Specification Addresses http://inspire.jrc.ec.europa.eu/implementingRulesDocs_ds.cfm European Commission: DRAFT Guidelines INSPIRE Data Specification Hydrography http://inspire.jrc.ec.europa.eu/implementingRulesDocs_ds.cfm EuroRegionalMap Specification and Data Catalogue IGN Belgium, other contributors: BKG Germany, IGN France http://www.ngi.be/

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 175

EuroRegionalMap: Incremental Development of a Pan-European Database at Medium Scale IGN France www.ign.fr EuroRoadS Documents (Final Specification of Road Network Exchange Model, Final Specification of Road Network Exchange Format, Final terminology Catalogue, Final Specifications of Core European Road Data,Metadata Catalogue & Final Specification of Road Network Information Model) www.euroroads.org Evaluation des produits publics d'information gographique en regard des critres definissant un rfrentiel CNIG, France www.cnig.gouv.fr Geographic Data Files http://www.ertico.com/en/links/links/gdf_-_geographic_data_files.htm GiMoDig, Global Schema specification GiMoDig consortium http://gimodig.fgi.fi/ Highway Agency (England and Wales) EnvIS methodology (TWG TN Reference Material on Circa) www.highways.gov.uk

IHOHydrographicRegistry http://www.ihowms.net:8080/iho_registry/home.php
Implementation report on the TEN-T guidelines TINA Vienna - Transport strategies Gmbh, Austria http://www.tinavienna.at/index.php?l_id=en INSPIRE Feature Concept Dictionary, INSPIRE Registry, European Commission INSPIRE UML Repository, INSPIRE Registry, European Commission ISO 19101 ISO 19103 ISO 19107 ISO 19111 ISO 19115 ISO 19118 ISO 19135 ISO 19139 EN ISO 19101:2005 Geographic information Reference model (ISO 19101:2002) ISO/TS 19103:2005, Geographic information Conceptual schema language EN ISO 19107:2005, Geographic information Spatial schema (ISO 19107:2003) EN ISO 19111:2007 Geographic information - Spatial referencing by coordinates (ISO 19111:2007) EN ISO 19115:2005, Geographic information Metadata (ISO 19115:2003) EN ISO 19118:2006, Geographic information Encoding (ISO 19118:2005) EN ISO 19135:2007 Geographic information Procedures for item registration (ISO 19135:2005) ISO/TS 19139:2007, Geographic information Metadata XML schema implementation Geographic information -- Location based services -- Linear referencing

ISO/AWI 19148 system

ITS Vienna Region - platform to integrate graphs

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 176

ITS Vienna Region im Verkehrsverbund Ostregion National Land and Property Gazetteer Local Government Information House (LGIH) www.idea.gov.uk/idk/core/page.do?pageId=8021533 National Street Gazetteer Local Government Information House (LGIH) www.idea.gov.uk/idk/core/page.do?pageId=8021533 NEN3610 - Basic scheme for geo-information NEN, Netherlands http://www2.nen.nl/nen/servlet/dispatcher.Dispatcher?id=253335 Network Rail Corporate Model (graphic), Not publically available, Network Rail, UK www.networkrail.co.uk Network statement - Common structure and implementation guide Rail Net Europe www.railneteurope.com Norwegian feature catalogue and standards, Digital Norway http://www.statkart.no/Norge_digitalt/Engelsk/About_Norway_Digital/ Nuova base dati cartografica del Reticolo Stradale Regione Emilia-Romagna, Italy Objekt katalog fr das Straen- und Verkehrswesen Bundesanstalt fr Strassenwesen, Germany OGC 06-103r3 Implementation Specification for Geographic Information - Simple feature access Part 1: Common Architecture v1.2.0

OJEC L228, 09/09/1996 Community Guidelines for the development of the trans-European transport network. As referenced in Annex I of the INSPIRE Directive: http://europa.eu/legislation_summaries/regional_policy/management/transeuropean_networks/l240 94_en.htm OS MasterMap Integrated Transport Network Layer - user guide Ordnance Survey, UK
http://www.ordnancesurvey.co.uk/oswebsite/products/osmastermap/userguides/docs/OSMM_ITN_userguide_v1.0.pdf

OS MasterMap Topography Layer - user guide and technical specification Ordnance Survey, UK http://www.ordnancesurvey.co.uk/oswebsite/products/osmastermap/userguides/docs/OSMMTopoL ayerUserGuide.pdf OS MasterMap Integrated Transport Network - GML Data Examples Ordnance Survey, UK http://www.ordnancesurvey.co.uk Productspecification TOP10NL Kadaster, Geonovum, Netherlands www.geonovum.nl Productspecification TOP10NL - UML schema Kadaster, Geonovum, Netherlands

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 177

www.geonovum.nl Reference data model for public transport CEN TC278 www2.nen.nl/nen/servlet/dispatcher.Dispatcher?id=204514 Reference Model and the Objective and Scope of River Information Services COMPRIS http://www.euro-compris.org/index2.asp Report on Global Schema for GiMoDig GiMoDig consortium http://gimodig.fgi.fi/ Report on Reference Data Sets and Feature types in Europe. EuroGeographics www.eurogeographics.org Route 120 descriptif de contenu IGN France ftp://ftp.ign.fr/ign/INSPIRE/DC_ROUTE120.pdf Route 500 descriptif technique IGN France www.ign.fr

S100(IHOHydrographicGeospatialStandardforMarineDataandInformation) (onlydraftversionavailablenotyetastandard) http://www.ihoohi.net/english/home/ S32(IHOInternationalHydrographicDictionary) http://www.iho.shom.fr/Dhydro/Html/site_edition/disclaimer.html

S-57 Electronic Navigational Chart Product Specification IHO http://www.iho-ohi.net/english/home/ Single European Sky http://ec.europa.eu/transport/air_portal/sesame/index_en.htm SIS/TK 320 Road and railway information Stanli, Sweden www.stanli.se Skyguide Glossary, Switzerland http://www.skyguide.ch/en/Tools/Glossary/glossary.xml Specification Georoute IGN France www.ign.fr Spcifications BD Uni v0.1 IGN France www.ign.fr Spcifications des donnes de rference et Avis du CNIG CNIG, France www.cnig.gouv.fr

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 178

Specifikation for flles objekt typer (Common object types specification) National Survey and Cadastre, Denmark www.kms.dk SS 63 70 04-1 (draft) Geographic information Road and railway network Part 1: Concept model and application schema SIS, Swedish Standards Institute www.stanli.se SS 63 70 04-1:2006 Geographic information Road and Railway networks - Part 1: Concept model and application schema SIS, Swedish Standards Institute www.stanli.se

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 179

Annex A (normative) Abstract Test Suite

Any dataset conforming to this INSPIRE data specification shall meet all requirements specified in this document. NOTE: A common abstract test suite including detailed instructions on how to test each requirement will be added at a later stage. This should also cover additional requirements.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 180

Annex B (informative) Imported Types

This annex lists definitions for feature types, data types, enumerations and code lists that are defined in other documents. The annex is purely informative and should help the reader understand the feature catalogues presented in sections 5.2.2, 5.3.2, 5.4.2, 5.5.2, 5.6.2 and 5.7.2. For the normative documentation of these types, see the references in sections 5.x.2.1 to 5.x.2.3.

B.1

Spatial object types

B.1.1 CrossReference
CrossReference Definition: Description: Status: Stereotypes: Represents a reference between two elements in the same network. The cross reference may represent the case where two elements are different representations of the same spatial object. Proposed featureType

Association role: element Value type: NetworkElement Definition: The cross referenced elements Multiplicity: 2

B.1.2 GeneralisedLink
GeneralisedLink (abstract) Subtype of: Definition: Status: Stereotypes: NetworkElement Abstract base type representing a linear network element that may be used as a target in linear referencing. Proposed featureType

B.1.3 GradeSeparatedCrossing
GradeSeparatedCrossing Subtype of: Definition: Description: NetworkElement Indicator which of two or more intersecting elements is/are above and which is/are below, to be used if elevation coordinates are not present or cannot be trusted. NOTE 1 In most cases, the number of elements will be two. NOTE 2 In the normal case this is when elements intersect in the x/y-plane when the z coordinate is not present or is not accurate enough. Proposed featureType

Status: Stereotypes:

Association role: element Value type: Link Definition: Multiplicity: 2..*

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 181

B.1.4 Link
Link (abstract) Subtype of: Definition: Status: Stereotypes: GeneralisedLink Curvilinear network element that connects two positions and represents a homogeneous path in the network. The connected positions may be represented as nodes. Proposed featureType

Attribute: centrelineGeometry Value type: GM_Curve Definition: The geometry that represents the centreline of the link. Multiplicity: 1 Attribute: fictitious Value type: Boolean Definition: Indicator that the centreline geometry of the link is a straight line with no intermediate control points unless the straight line represents the geography in the resolution of the dataset appropriately. Multiplicity: 1 Association role: endNode Value type: Node Definition: The optional end node for this link. The end node may be the same instance as the start node. Multiplicity: 0..1 Association role: startNode Value type: Node Definition: The optional start node for this link. Multiplicity: 0..1

B.1.5 LinkSequence
LinkSequence (abstract) Subtype of: Definition: Description: Status: Stereotypes: Attribute: link Value type: Definition: Multiplicity: Collection Constraints: GeneralisedLink A network element which represents a continuous path in the network without any branches. The element has a defined beginning and end and every position on the link sequence is identifiable with one single parameter such as length. EXAMPLE A link sequence may represent a route. Proposed featureType DirectedLink The ordered collection of directed links that constitute the link sequence. 1..* ordered

B.1.6 LinkSet
LinkSet (abstract) Subtype of: Definition: NetworkElement A collection of link sequences and/or individual links that has a specific function or significance in a network.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 182

LinkSet (abstract) Description: NOTE This spatial object type supports the aggregation of links to form objects with branches, loops, parallel sequences of links, gaps, etc. EXAMPLE A dual carriageway road, as a collection of the two link sequences that represent each carriageway. Proposed featureType

Status: Stereotypes:

Association role: link Value type: GeneralisedLink Definition: Multiplicity: 1..*

B.1.7 Network
Network Definition: Description: Status: Stereotypes: A network is a collection of network elements. The reason for collecting certain elements in a certain network may vary (e.g. connected elements for the same mode of transport) Proposed featureType

Attribute: geographicalName Value type: GeographicalName Definition: Geographical name for this network. Multiplicity: 0..* Stereotypes: voidable Association role: elements Value type: NetworkElement Definition: The collection of elements that constitutres the network. Multiplicity: 0..*

B.1.8 NetworkArea
NetworkArea (abstract) Subtype of: Definition: Status: Stereotypes: NetworkElement A 2-dimensional element in a network. Proposed featureType

Attribute: geometry Value type: GM_Surface Definition: Represents the geometric properties of the area Multiplicity: 1

B.1.9 NetworkConnection
NetworkConnection Subtype of: Definition: Description: Status: Stereotypes: Attribute: type NetworkElement Represents a logical connection between two or more network elements in different networks. In the case where the networks are in different spatial data sets, a network connection object may exist in both data sets. Proposed featureType

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 183

NetworkConnection Value type: Definition: Multiplicity: Stereotypes: ConnectionTypeValue Categorisation of the network connection. 1 voidable

Association role: element Value type: NetworkElement Definition: Network elements in different networks Multiplicity: 2..* Constraint: Elements in different networks Natural All elements have to be in different networks language: OCL: inv: element->forAll( e1, e2 | e1<>e2 >excludesAll(e2.inNetwork) )

implies

e1.inNetwork-

B.1.10 NetworkElement
NetworkElement (abstract) Definition: Status: Stereotypes: Abstract base type representing an element in a network. Every element in a network provides some function that is of interest in the network. Proposed featureType

Attribute: beginLifespanVersion Value type: DateTime Definition: Date and time at which this version of the network element was inserted or changed in the spatial data set. Multiplicity: 1 Stereotypes: lifeCycleInfo,voidable Attribute: inspireId Value type: Identifier Definition: External object identifier of the network element. Description: NOTE An external object identifier is a unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object. The identifier is an identifier of the spatial object, not an identifier of the real-world phenomenon. Multiplicity: 0..1 Attribute: endLifespanVersion Value type: DateTime Definition: Date and time at which this version of the network element was superseded or retired in the spatial data set. Multiplicity: 0..1 Stereotypes: lifeCycleInfo,voidable Association role: inNetwork Value type: Network Definition: The networks in which a network element is a member. Multiplicity: 1..* Stereotypes: voidable

B.1.11 NetworkProperty
NetworkProperty (abstract) Definition: Abstract base type representing phenomena located at or along a network element. This base type provides general properties to associate the networkrelated phenomena (network properties) with the network elements.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 184

NetworkProperty (abstract) Description: In the simplest case (NetworkReference), the network property applies to the whole network element. In the case of a Link, the spatial reference may be restricted to part of the Link by using a linear reference. ISO/TC 211 is currently in the early stages of developing a standard for Linear Referencing (ISO 19148). A simple mechanism to express linear references is provided in this version of the network model; it is expected that the model will be extended once ISO 19148 is stable. The current simple model requires for all linear references two expressions representing a distance from the start of the Link along its curve geometry. The network property applies to the part of the Link between fromPosition and toPosition. Proposed featureType

Status: Stereotypes:

Attribute: networkRef Value type: NetworkReference Definition: Spatial reference of the network-related property. Description: This attribute provides an indirect spatial reference based on a reference to an element of an underlying network. See the chapter on Object Referencing in the Generic Conceptual Model for a discussion on modelling object references. Multiplicity: 1..* Stereotypes: voidable Attribute: inspireId Value type: Identifier Definition: External object identifier of the network property. Description: NOTE An external object identifier is a unique object identifier published by the responsible body, which may be used by external applications to reference the spatial object. The identifier is an identifier of the spatial object, not an identifier of the real-world phenomenon. Multiplicity: 0..1 Attribute: beginLifespanVersion Value type: DateTime Definition: Date and time at which this version of the network element was inserted or changed in the spatial data set. Multiplicity: 1 Stereotypes: voidable,lifeCycleInfo Attribute: endLifespanVersion Value type: DateTime Definition: Date and time at which this version of the network element was superseded or retired in the spatial data set. Multiplicity: 0..1 Stereotypes: voidable,lifeCycleInfo

B.1.12 Node
Node (abstract) Subtype of: Definition: Description: NetworkElement Represents a significant position in the network that always occurs at the beginning or the end of a link. NOTE if a topological representation of the network is used the road node is either a topological connection between two or more links or the termination of a ink. If a geometric representation of the network is used road nodes are represented by points or alternatively another geometric shape. [EuroRoadS] Proposed featureType

Status: Stereotypes: Attribute: geometry

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 185

Node (abstract) Value type: Definition: Multiplicity: GM_Point The location of the node. 1

Association role: spokeEnd Value type: Link Definition: The links that enter the node. Description: NOTE In the INSPIRE context, this spoke property is to be published when this information is published in current exchange formats of the data set. Multiplicity: 0..* Stereotypes: voidable Association role: spokeStart Value type: Link Definition: The links that leave the node. Description: NOTE In the INSPIRE context, this spoke property is to be published when this information is published in current exchange formats of the data set. Multiplicity: 0..* Stereotypes: voidable

B.2 Data types

B.2.1 DirectedLink
DirectedLink Definition: Status: Stereotypes: A link either in its positive or negative direction. Proposed dataType

Attribute: direction Value type: Sign Definition: Indicates if the directed link agrees (positive) or disagrees (negative) with the positive direction of the link. Multiplicity: 1 Association role: link Value type: Link Definition: The link Multiplicity: 1

B.2.2 LinkReference
LinkReference Subtype of: Definition: Status: Stereotypes: NetworkReference A network reference to a linear network element. Proposed dataType

Attribute: applicableDirection Value type: LinkDirectionValue Definition: The directions of the generalised link to which the reference applies. In cases where a property does not apply to a direction along a link, but represents a phenomenon along a link, inDirection refers to the right side in the of the link. Description: EXAMPLE A speed limit is a property that applies to a direction of the link (or both directions) while a house number is a phenomenon along a link. Multiplicity: 1 Stereotypes: voidable

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 186

LinkReference Constraint: Linear reference targets must be linear network elements Natural Linear reference targets must be linear network elements. I.e., if linear language: referencing is used or direction is relevant, the target of the network reference shall be a link or a link sequence. OCL: inv: element.oclIsKindOf(GeneralisedLink)

B.2.3 NetworkReference
NetworkReference Definition: Status: Stereotypes: A network reference to a network element. Proposed dataType

Association role: element Value type: NetworkElement Definition: Multiplicity: Stereotypes: 1 version

B.2.4 SimpleLinearReference
SimpleLinearReference Subtype of: Definition: Status: Stereotypes: LinkReference A network reference that is restricted to part of a linear network element. The part is the part of the network element between the position along the network element between fromPosition and toPosition. Proposed dataType

Attribute: fromPosition Value type: Length Definition: The start position of the linear element, expressed as the distance from the start of the linear network element along its curve geometry. Multiplicity: 1 Attribute: toPosition Value type: Length Definition: The end position of the linear element, expressed as the distance from the start of the linear network element along its curve geometry. Multiplicity: 1 Attribute: offset Value type: Definition: Multiplicity: Stereotypes: Length An offset from the centerline geometry of the generalised link, where applicable; a positive offset is to the right in the direction of the link, a negative offset is to the left. 0..1 voidable

B.2.5 SimplePointReference
SimplePointReference Subtype of: Definition: Status: Stereotypes: LinkReference A network reference that is restricted to a point on a linear network element. The point is the location on the network element at the position atPosition along the network. Proposed dataType

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 187

SimplePointReference Attribute: atPosition Value type: Length Definition: Position of the point, expressed as the distance from the start of the linear network element along its curve geometry. Multiplicity: 1 Attribute: offset Value type: Definition: Multiplicity: Stereotypes: Length An offset from the centerline geometry of the generalised link, where applicable; a positive offset is to the right in the direction of the link, a negative offset is to the left. 0..1 voidable

B.3 Enumerations and code lists

B.3.1 ConnectionTypeValue
ConnectionTypeValue Definition: Status: Stereotypes: Governance: Types of connections between different networks. Proposed codeList Centrally managed in INSPIRE code list inspire:def:codeList:INSPIRE:ConnectionTypeValue

register.

URN:

urn:x-

Value: crossBorderConnected Definition: Connection between two network elements in different networks of the same type, but in adjacent areas. The referenced network elements represent the different, but spatially connected real-world phenomena. Value: intermodal Definition: Connection between two network elements in different transport networks that use a different transport mode. The connection represents a possibility for the transported media (people, goods, etc) to change from one transport mode to another. Value: crossBorderIdentical Definition: Connection between two network elements in different networks of the same type, but in adjacent areas. The referenced network elements represent the same real-world phenomena.

B.3.2 LinkDirectionValue
LinkDirectionValue Definition: Status: Stereotypes: Governance: List of values for directions relative to a link Proposed codeList Centrally managed in INSPIRE code list inspire:def:codeList:INSPIRE:LinkDirectionValue

register.

URN:

urn:x-

Value: bothDirections Definition: In both directions. Value: inDirection Definition: In direction of the link. Value: inOppositeDirection Definition: In the opposite direction of the link.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 188

Annex C (informative) Supplementary Information regarding alternative representations of network objects

C.1

Alternative Representations

This section describes the three main forms of road, rail and water transport network representation. The model supports Physical (topographic) and centreline representations.

Figure C1-1. Alternative transport network Representations In the above Figure B1-1 the road is represented in three forms: a) Physical (topographic) extents. The lines shown in red above (ie edges of area objects) normally represent the extent of the surface of the highway, (or banks of the river at a given time of year e.g. winter water level). The area is normally segmented into several sub units (not shown on this sketch) where their aggregation will define the full extent of the road or river. Narrow sections will often be represented by a single line. This network can only be inferred since there is no knowledge of which objects connect in any ordered sequence or state (though this could be achieved if required it is not covered on this version of the specification. Similar approaches are applicable to road, air and some aspects of cable and rail networks. b) Centreline model (the green dashed line above) is a set of (or aggregation of) lines that represent the centre of the physical object e.g. a road or river this usually the approximate centre (sometimes known as a reference line instead because of this). Nodes (red disks) are also shown in the figure above. Generally this approach will support topology and specific forms of network analysis. Therefore the sequence and relationships between the lines is understood and in some cases ordered. Nodes may be implied or explicit. All spatial objects will be described by coordinates. Centrelines are often linked to the underlying physical (topographic) extents see Figure B12 below.

INSPIRE TWG-TN

Reference: INSPIRE_DataSpecification_TN_v3.0.1.pdf INSPIRE Data Specification on Transport Networks 2009-10-02 Page 189

Figure C1-2: Linking centrelines and physical (topographic) extents c) Logical model (the blue dashed line in Figure B1-1 above) is a set of lines linking all the nodes of the network (chosen to be junctions & ends). The spatial content is therefore limited or non-existent (spatial coordinates of the nodes are not always included) and the logical model has limited value to a spatial data infrastructure but it is used in some transport operations. The approach can be modelled in this specification by simply inserting a single link between nodes. d) Aligning Logical and Centreline Models: users may if they wish align a logical model with the centreline/physical models to share information between them within a set of applications. This can be achieved by relating (e.g. cross referencing all those nodes that are common in each system). The logical model can then inherit the spatial location of the centreline nodes which will provide a level of spatial positioning and interoperability.