Specification of Road Network Information · PDF fileSpecification of Road Network Information...

Deliverable D6.3 Specification of Road Network

Information Model

Project acronym: EDC-11145 EUROROADS/28646 Deliverable: D6.3 Nature: Public Author: Lars Wikström Date: 01/06/2005 Version: 1.01 Status: Final draft

EuroRoadS WP 6 Date Status Version Page D6.3 01/06/2005 Final Draft 1.01 2 (109)

Document control: Version Date Editor Comment 0.1 12/02/2005 Håkan B Created from draft version D6.2

0.2 18/04/2005 Lars W Edited according to received comments

0.9 13/05/2005 Lars W “

0.91 20/05/2005 Lars W Taken care of additional comments LWi 24-26

1.0 23/05/2005 Lars W Added text to the requirements chapter

1.01 01/06/2005 Lars W Added the ER_BorderNodeInfoFeature class


Table of contents

1 SCOPE .............................................................................................................................. 6

2 INTRODUCTION............................................................................................................ 7

2.1 The EuroRoadS project..................................................................................................................... 7

2.2 The handling of road data ................................................................................................................. 7 2.2.1 Data provider................................................................................................................................... 9 2.2.2 Content provider.............................................................................................................................. 9 2.2.3 Information provider ....................................................................................................................... 9 2.2.4 Service provider .............................................................................................................................. 9

2.3 Baseline and results from WP6......................................................................................................... 9

2.4 Deliverables from WP6.................................................................................................................... 10 2.4.1 Report of preliminary findings and directions for the specification work..................................... 10 2.4.2 Specification of Road Network Information model (this document) ............................................ 10 2.4.3 Specification of core European road data (this document)............................................................ 10 2.4.4 Specification of road network exchange model and Specification of road

network exchange format .............................................................................................................. 10 2.4.5 Meta-data catalogue ...................................................................................................................... 11 2.4.6 Terminology catalogue.................................................................................................................. 11

3 REFERENCES............................................................................................................... 11

4 TERMS, DEFINITIONS AND ABBREVIATED TERMS........................................ 13

5 SYMBOLS AND NOTATION...................................................................................... 15

5.1 UML Notation .................................................................................................................................. 15 5.1.1 UML Packages .............................................................................................................................. 15 5.1.2 UML Classes................................................................................................................................. 16 5.1.3 Relationships ................................................................................................................................. 17 5.1.4 Attributes and associations............................................................................................................ 18 5.1.5 Stereotypes .................................................................................................................................... 18 5.1.6 Other UML modeling rules used in this document ....................................................................... 19

6 ROAD NETWORK INFORMATION MODEL......................................................... 20

6.1 Model architecture and rationale ................................................................................................... 20 6.1.1 Requirements................................................................................................................................. 21


6.1.2 EuroRoadS and GDF..................................................................................................................... 23 6.1.3 EuroRoadS and ActMap................................................................................................................ 24 6.1.4 EuroRoadS and other standardization efforts................................................................................ 26 6.1.5 A use case view of EuroRoadS ..................................................................................................... 28 6.1.6 Package structure .......................................................................................................................... 28

6.2 ISO Profiles ...................................................................................................................................... 32 6.2.1 ISO 19107 Profile – Spatial schema.............................................................................................. 32 6.2.2 ISO 19108 Profile – Temporal schema ......................................................................................... 37 6.2.3 Metadata........................................................................................................................................ 37 6.2.4 ISO 19133 Profile – Linear Referencing....................................................................................... 38

6.3 Basic types package.......................................................................................................................... 42 6.3.1 ER_ObjectId.................................................................................................................................. 42 6.3.2 ER_IdentifiableObject................................................................................................................... 42 6.3.3 ER_RoadFeature ........................................................................................................................... 43 6.3.4 Permanent identities ...................................................................................................................... 44

6.4 Network package.............................................................................................................................. 49 6.4.1 Overview....................................................................................................................................... 49 6.4.2 Road network base ........................................................................................................................ 51 6.4.3 Geometric representation option ................................................................................................... 59 6.4.4 Topological representation option................................................................................................. 60 6.4.5 Optional constructs........................................................................................................................ 61

6.5 Network referencing ........................................................................................................................ 68 6.5.1 Introduction................................................................................................................................... 68 6.5.2 Linear elements ............................................................................................................................. 68 6.5.3 Location Expressions .................................................................................................................... 69

6.6 Attributes and features related to the road network. ................................................................... 78 6.6.1 Introduction................................................................................................................................... 78 6.6.2 Attribute base package .................................................................................................................. 80 6.6.3 Conditional and optional attributes and features (Example) ......................................................... 83 6.6.4 Attaching attributes directly to the road network .......................................................................... 86 6.6.5 Attaching road related features using network referencing........................................................... 88 6.6.6 User defined attributes and features .............................................................................................. 90

6.7 Edge matching at borders ............................................................................................................... 92 6.7.1 EuroBoundaries............................................................................................................................. 92 6.7.2 Border nodes package ................................................................................................................... 93 6.7.3 ER_BorderNodeInfo ..................................................................................................................... 93


6.7.4 ER_BorderNodeInfoFeature ......................................................................................................... 94

6.8 Grade separated crossings............................................................................................................... 95 6.8.1 Grade separated crossings package ............................................................................................... 96

6.9 Updates ............................................................................................................................................. 98 6.9.1 Transactions and updates .............................................................................................................. 98

7 APPENDIX A – MAPPING SPECIFICATION FOR GDF .................................... 107

7.1 Road element .................................................................................................................................. 107

7.2 Ferry connection ............................................................................................................................ 107

7.3 Junction........................................................................................................................................... 107

7.4 Road ................................................................................................................................................ 107

7.5 Ferry................................................................................................................................................ 107

7.6 Intersection ..................................................................................................................................... 108

7.7 Enclosed traffic area ...................................................................................................................... 108

7.8 Roundabout .................................................................................................................................... 108

7.9 Aggregated Way............................................................................................................................. 109

7.10 Interchange..................................................................................................................................... 109

7.11 Edge levels and grade separated crossing .................................................................................... 109


1 Scope This document defines a draft version of the final application schema for core European road data as specified by the EuroRoadS project. The primary use for this document is to serve as basis for the definition of a data exchange specification within EuroRoadS. The EuroRoadS application schema is based on the ISO 19100 suite of international standards for geographical information which was produced by ISO/TC 211.

Still, there is work going on regarding requirements analysis. The schema in this document will have to be refined and redefined to meet the various requirements not yet taken into consideration.

Parts that are covered by this document are:

• The road network structure and some basic mandatory attributes and a mechanism to attach additional attributes directly to the road network elements.

• A network referencing structure to attach attributes and features to the road network elements.

• An incremental update structure and definitions for permanent identities.

• A mechanism to make it easier to join data at borders.

• A core set of attributes for a couple of applications pointed out by the project

The following parts will have to be developed further before the final version of this document:

• A clear definition of the requirements that has been regarded for this document.

• Definitions of additional attributes and features to cover the scope “Core European road data” according to the final results from WP5 – Requirements.

• Definitions for a comprehensive list of linear referencing methods.

• Mapping definition for GDF.

• Any other definition that will be pointed out as required that is not yet specified.

The following areas are intentionally left out:

• Metadata is described in D6.8 which is based on ISO 19115 – Metadata. A quality model for EuroRoadS has been defined in D2.2. Note: The quality model described in D2.2 and the one in ISO 19115 differs in some aspects. The metadata schema of EuroRoadS takes both models into consideration.

• The data exchange model and schema will be defined in separate deliverables.


2 Introduction

2.1 The EuroRoadS project EuroRoadS will lay the ground for a pan-European road data infrastructure built on identified user requirements. It will be a key for opening up public sector road information, for promoting public-private partnership and for establishment of important applications. The main objective for the project is to build a platform for a European road data solution through a specification framework. The framework will consist of specifications for data content and data exchange. The European road information solution will be built and maintained taking full advantage of national road data solutions as well as existing standards. It will make national data available to the market in a harmonised, interoperable and quality assured way.

Core European road data is characterised by having an infrastructural role by:

• functioning as reference data, which means that other kinds of information can and will be linked to the core data

• being of interest for many different kinds of applications (and being a common denominator and integrator between different data suppliers and product and service providers)

• containing information of specific interest for the public sector in its role to support efficient transportation, traffic safety, to handle environmental and social planning, etc

• being a part of the European Spatial Data Infrastructure and thereby, for example, being easily linked to other kinds of reference information, such as geographical names, administrative units, and addresses

• covering (the entire) Europe

• having a structure that is stable over time (even if parts of the data content frequently changes)

• having specific interest for cross boarder (pan-European) applications.

2.2 The handling of road data The handling of road data can be described as a business refinement process with four steps (se figure 2.1). The EuroRoadS project will focus on step two, the ”Content provider”, but will also cover the other three steps in order to guarantee that the specifications and technical solutions being chosen for EuroRoadS will be efficient for the compilation of raw data as well as for the following steps in the refinement process.


Figure 2.1 Business and data refinement process

Figure 2.1 describes the business and data refinement process, where the end user of data and services is placed to the far right in the figure. Different content providers ideally shall be viewed as keepers of data of a certain domain or possibly also competing providers of data for the same domain. EuroRoadS shall primarily focus on specifications for Content providers for road data.

From a specification development perspective, the business refinement chain can be viewed in the opposite direction (from right to left). In the end, the service users are the ultimate owners of requirements that propagate back all the way to the Data providers.

The business refinement view of EuroRoadS points out that:

• End users will need services that make use of data from different domains.

• Every Content provider can not (or very seldom) be the one and only provider of data for a certain end user service.

• EuroRoadS – will have to be very specific on the question of what is part of the road data domain, and what is not.

Here follows a more in depth description of each step in the information chain.

Focus for EuroRoadS

Road Data

Data X

Data Y

Road Data

EuroRoadS content

Content Y

Content X

Information provider

Information X

Information Y Service Y

Content provider Data provider

Service provider


2.2.1 Data provider Step one in the information chain includes data capture of different kinds of ”raw” data, e.g. existing databases with road networks, geocoded addresses, and information on road technical descriptions, traffic regulations, administrative details, etc. This kind of information is available from national mapping agencies, national road administrations, municipalities and the private mapping industry.

2.2.2 Content provider Step two is about production – or compilation – of basic data (reference data) needed for many applications, such as intelligent transport systems, mobility management, traffic management, road maintenance, traffic safety, environmental and society planning. This compilation will make use of existing databases with road information, but it is also foreseen that the specification for reference data will have an impact on the future structure of national or regional databases with road data.

2.2.3 Information provider Step three includes data which are adjusted and ”wrapped up” in order to suit a specific application, for example a road map on a CD for a vehicle navigation system.

2.2.4 Service provider Step four is about more advanced services with different kinds of functions, e.g. to develop a fleet management system due to specific user requirements.

2.3 Baseline and results from WP6 By the end of this project, EuroRoadS will have developed a specification framework built on identified user requirements and developed quality model. The project will also have taken into account existing standards and solutions within the area. EuroRoadS will develop a framework, prepared for a European standard (a profile based on ISO 19 100 components). The framework will consist of:

• A road network information model that defines road network objects and a method for how road related objects (attributes) can associate to the network. This common and agreed structure can be the road data “language” of Europe, a harmonised and unified view of how to describe a digital road network.

• A definition of core European road data within the proposed structure. This will point out a basic level of data content proposed to be the data set that in the future might be provided to the European market. The European data set should be built on national road database solutions. The future goal is not to establish a European road database. The goal is to be able to, through national contributions of data, transform data and provide it to the market through a uniform data exchange. In many cases existing data, mainly from the public sector (road administrations, mapping agencies, municipalities etc.), will become easily available in this way.


• A specification of a data exchange model and format together with a meta-data catalogue, showing the characteristics of the accessible information. These specifications can be adopted as the basis of an interface solution, supporting an easy access to European road data defined as above. The data exchange model and format will support exchange of complete data sets and just changes.

2.4 Deliverables from WP6 WP6 will deliver seven official documents, as described below.

2.4.1 Report of preliminary findings and directions for the specification work

The aim of this document was to give recommendations and directions for the work in WP6, especially in the area of road data model, core road data and exchange formats. The recommendations were based on user requirements, existing road data solutions in Europe and standards within the area.

The document will have one version: D6.1

2.4.2 Specification of Road Network Information model (this document) The document includes a definition of the data structure of the road network, and a definition of levels of details and a reference system (e.g. how to reference objects to the road network).

The draft version of this document is D6.2 and the final version is D6.3

2.4.3 Specification of core European road data (this document) The document will include a definition of referred road network and specification of common features (feature types, attribute types and attribute values). It also should contain specified quality levels for the content, generalisation rules for the road network, geodetic reference system to be used and rules for edge-matching at nation boarders.

The draft version of this document is D6.4 and the final version is D6.5

2.4.4 Specification of road network exchange model and Specification of road network exchange format

These two documents will describe the exchange model respective the exchange format.

Data exchange should be specified as a road network exchange model (corresponding to the information model), and a road data exchange format that can communicate road data (both the whole data set and incremental updates) structured as specified in the exchange model.

This interface also should contain a meta-data catalogue showing the characteristics of the accessible information.

The draft version of “exchange model” document will be D6.6 and the final version will be D6.7


The draft version of “exchange format” document will be D6.10 and the final version will be D6.11

2.4.5 Meta-data catalogue This deliverable is pointed out in the EuroRoadS project specification but not specified in detail. WP6 suggests that the document will be structured as follows: First existing metadata specifications will be investigated. Therefore standards like FGDC, ISO 19110, ISO 19115, GDF as well as catalogues from EuroRoadS partners will be investigated.

Based on this comparison of existing standards and on the road network (document described in chapter 2.4.1) and core road data (document described in chapter 2.4.3) a core metadata specification will be developed. This will include the description as well as the modelling of the metadata elements in UML. The specification will also define the structure for a feature catalogue (which can be viewed as part of the metadata model). The structure of the feature catalogue will be based on ISO 19110 – Feature Cataloguing Methodology or a profile thereof. The actual EuroRoadS feature catalogue (where all EuroRoadS features and attributes are catalogued) will be a part of the Road Network Information model (see 2.4.2) or perhaps the data content specification (see 2.4.3). There will also be a part in the road network exchange format (2.4.4) which will enable the exchange of metadata, including quality data and the feature catalogue.

Furthermore the main results will be concluded and an outlook will be given.

The document will have one version: D6.8

2.4.6 Terminology catalogue The terminology catalogue will include definitions of road data related terms used in the EuroRoadS project.

The draft version of this document will be D6.9 and the final version will be D6.12

3 References [1] ISO/TS 19103 Geographic information – Conceptual schema language

[2] ISO/DIS 19106 Geographic information - Profiles

[3] ISO/IS 19107 Geographic information – Spatial schema

[4] ISO/IS 19108 Geographic information – Temporal schema

[5] ISO/IS 19109 Geographic information – Rules for application schema

[6] ISO/IS 19115 Geographic information – Metadata

[7] ISO/DIS 19133 Geographic information – Location based services tracking and navigation

[8] EuroRoadS report D6.1 (Report on preliminary findings and directions for the specification work)

[9] ISO/FDIS 14825 – Intelligent transport systems - Geographic data files (GDF) – Overall data specification


[10] SS 637006 – Geographic information – Generic representation of geographic features

[11] ActMap specification, Version 1.0 (http://www.ertico.com/en/subprojects/actmap)

[12] OGC – Web Feature Services Implementation Specification (http://www.opengeospatial.org)

[13] EuroRoadS report D6.5 (Specification of core European road data)


4 Terms, definitions and abbreviated terms 2D 2-dimensional

3D 3-dimensional

application schema conceptual schema for data required by one or more applications [ISO 19101]

attribute characteristic of a feature

conceptual model model that defines the concepts of a universe of discourse [ISO 19101]

conceptual schema formal description of a conceptual model [ISO 19101]

dataset identifiable collection of data [ISO 19115]

domain well-defined set

feature abstraction of real world phenomena NOTE The term feature is frequently used in GI-systems for classes/relational tables that have an attribute/column which consists of geometry. Sometimes this is confusing as the term in English often actually refers to an attribute or a property (which perhaps would be ok if features are always considered properties of the earth). In EuroRoadS we use the term feature in a wider sense that covers objects or other “abstractions of real world phenomena” that are uniquely identifiable, has a set of characteristics and an independent lifetime.

geographic data data with implicit or explicit reference to a location relative to the Earth NOTE Geographic information is also used as a term for information concerning phenomena implicitly or explicitly associated with a location relative to the Earth.

GML Geography Markup Language. This is the proposed standard for data transfer for EuroRoadS.

metadata data about data [ISO 19115]


MD5 Message-Digest algorithm 5

model abstraction of some aspects of reality

OCL Object Constraint Language

quality totality of characteristics of a product that bear on its ability to satisfy stated or implied needs [ISO 19101]

degree to which a set of inherent characteristics fulfils requirements [ISO 9000]

UML Unified Modeling Language

universe of discourse view of the real or hypothetical world that includes everything of interest [ISO 19101]

UUID Universally unique identifier


5 Symbols and notation

5.1 UML Notation The conceptual schemas in this document use UML (Unified Modelling Language) according to ISO/TS 19103 – Conceptual schema language. The UML specification can be downloaded from www.omg.org. ISO/TS 19103 – Conceptual Schema Language further refines the use of UML in the domain of geographic information modelling.

Below is a compressed description of the UML concepts from ISO 19103 that are used in this document.

5.1.1 UML Packages The EuroRoadS schema is hierarchically subdivided into packages. A package is a container of other coherent modelling elements and packages. Diagrams showing only packages primarily serve the purpose of giving an overview of the different logical parts in the model and the interdependencies between those parts.

Package1

Package2

Figure 5-1 - Example of package structure

The figure above shows two packages where Package2 is dependent of Package1. In practice that means that Package2 has definitions (for example classes) that are dependant on definitions in Package1.


5.1.2 UML Classes A UML class is a description of a set of objects that share the same attributes, relationships and semantics.

«Abstract»Package1::Class1

+attribute1 : CharacterStringPackage2::Class2 Package2::Class3

Figure 5-2 – UML class diagram example

The figure above shows three classes, Class1 from Package1 and Class2 and Class3 from Package2. The arrow pointing from Class2 and Class3 to Class1 defines an inheritance relationship. Inheritance in conceptual modeling should primarily be used to denote an IsA-relationship which in the figure above means that Class2 and Class3 are subtypes of Class1. This also means that everywhere when we refer to instances of Class1, those instances can be substituted by any of the subtypes of Class1. If the base-class, in this case Class1, is abstract, that means that no instances of Class1 can occur. This also implies that whenever we refer to Class1, which is still possible, we always mean one or all of its subclasses.

UML does not require all relationships or attributes to be displayed in all diagrams. When attributes intentionally have been left out, the attribute compartment in the class is not displayed at all in the diagram. That means that a class where the attribute compartment is displayed but empty actually has no attributes. In the figure above, Class1 may have attributes which are not shown in the diagram. Class2 has one attribute (attribute1) and Class3 has no attributes.

In the figure above, Class1 is abstract which actually is shown in two ways:

• by the stereotype <<Abstract>>. More about stereotypes in section below.

• The classname “Class1” is written in italics.


5.1.3 Relationships Besides from the inheritance relationship described above, three more kinds of relationships are used: Association, Aggregation and Composition. These are further explained below. In all cases a name and a multiplicity can be drawn at each end of the relationship. The name is a role name which should explain the role of the class in the relationship. The multiplicity of an association-end can be one of exactly-one (1), zero-or-one (0..1), one-or-more(1..*), zero-or-more (0..*) or an interval (n..m).

5.1.3.1 Association An association is a semantic relationship between two or more classes. Example (in figure below): A person can own cars and a car can have many owners.

CarPerson+owners

0..*

+cars

0..* Figure 5-3 – Association

5.1.3.2 Aggregation An aggregation association is a relationship between two classes, in which one of the classes plays the role of container and the other plays the role of a containee. The diamond is drawn at the container end of the aggregation.

Example (in figure below): A car contains an engine.

Figure 5-4 – Aggregation

5.1.3.3 Composition A composition association is a strong aggregation. This means that lifetime is shared by the container - and containee - instances.

Example (in figure below): A polyline consists of an ordered set of vertices.

Polyline Vertex

1

+vertices

0..*{ordered}

Figure 5-5 – Composition


5.1.4 Attributes and associations Attributes are presented in the UML diagrams in compliance with the UML Notation Guide [18].

UML notation for an attribute has the form: Attribute-declaration :==

“«” stereotype “»” visibility name multiplicity “ : ”

type = initial-value {property, …}

multiplicity :== “[” cardinality-range,… “]”

cardinality-range :== begin-value {“..” end-value}

where the various parts of the above syntax are as follows:

a) stereotype — use tag for the attribute being defined (see below)

b) visibility — public (+), private (–) or protected (#) indicating the visibility of this attribute or operation from outside the object. If the visibility includes “/”, then the attribute is derived from some other part of the model. Since the EuroRoadS model serves the purpose of modeling information, only public attributes are used.

c) name — the name of the attribute

d) multiplicity — the number of values that this attribute can have, assumed to be organized as a set unless otherwise specified; this is an extension of and consistent with the “size” mechanism of ISO/IEC 11404, except for the use of “[..]” which is UML notation. To maintain consistency of concept, this document uses a single multiplicity syntax (from UML) even when using it in conjunction with the “size” sub-typing of ISO/IEC 11404.

e) begin-value — any integer, a valid multiplicity; if no end-value follows, then only the begin-value is added as a possible multiplicity.

f) end-value — any integer bigger than the preceding begin-value, or “*” meaning infinity or an unbounded cardinality-range, the meaning of “a..b” is any integer j such that a <= j <= b; [a..a] is assumed to mean the same as [a].

g) type — the type, either object or value of the preceding attribute.

h) property — additional information about the attribute, such as NOT NULL or UNIQUE. Can be structured as a property name followed by a value, such as “{size = [0..*]}”. (See ISO/IEC 11404 for some interpretations of properties as subtypes.)

i) ... — the preceding can be repeated any number of times.

o) initial-value — default value of the attribute, used when a new object is constructed.

In the text, notation from the Object Constraint Language (OCL) is used. The OCL specification is downloadable from http://www.omg.org.

5.1.5 Stereotypes Most entities in a UML model can be described by a “stereotype” which is included near the name of the object and enclosed in guillemets “«” and “»”. The stereotype allows the model


to extend UML to include descriptions of elements of the model. In this document the following stereotypes are used:

a) «Abstract» – (also represented in UML by the class name being in an italics font) the class can not be instantiated.

b) «DataType» – the class is directly instantiable and its primary purpose is the encapsulation of data. «DataTypes» do not have an identity of their own and must be strongly aggregated into some sort of container such as being an attribute in another class, or being the target class of a strong aggregation. «DataType» types cannot be used as the target of weak aggregations, nor can they be used in the Reference< > parameterized class.

c) «Union» – a type consisting of one and only one of several alternatives (listed as member attributes).

d) «Enumeration» A type that defines a list of valid identifiers of mnemonic words. Attributes of an enumerated type can only take values from this list.

d) «CodeList» – similar to an enumeration, in that one of a number of values is possible, but differs in intent, in that a code list may be expanded over time.

5.1.6 Other UML modeling rules used in this document 1. Since multiple inheritance is not allowed in GML (upon which the transfer schema is

proposed to be based), the EuroRoadS models are not allowed to use multiple inheritance either.

2. Typically navigability arrows on associations are used to denote the possible navigation directions of the association. In this schema, very few navigability arrows are drawn since in principle every association is bidirectional. However, a decision has to be made when transfer schemas are defined and associations have to be instantiated. The basic principle in that case must be to avoid redundancies and ambiguities in the dataset.


6 Road Network Information Model

6.1 Model architecture and rationale The EuroRoadS specification shall enable existing content providers (public and private) in Europe to provide road data in a uniform way. Therefore, EuroRoadS does not invent any new concepts. Instead different definitions of the same basic concepts are harmonized and brought into a common terminology and structure. The international standards suite from ISO/TC211 is used as a framework since it has been explicitly pointed out by the EuroRoadS project specification.

Different content providers use different approaches within existing solutions as pointed out in D6.1 [8]. In order to enable as many as possible to use EuroRoadS, a flexible modelling approach is needed. In the survey performed during the writing of D6.1 a number of differences were discovered:

• Some use explicit topology (stored topological relationships) and some use purely geometric representations of the network (where topology can be derived providing that certain topological rules are followed regarding the geometry).

• The way attributes are handled and related to the road network differ:

- The road network is modelled using linear elements with attributes directly attached to the linear elements (like columns in a relational table). The segmentation of the road network is affected by the attribution.

- Some of the attributes are more loosely coupled (related relational tables). The road network segmentation is still dependant on the attributes.

- Attributes are related to the road network using referencing mechanisms. In this case the network segmentation is not dependant on the occurrence of attributes.

• There are differences in the existence and semantics of attributes.

• There are differences in if and how objects are identified.

There are also similarities between the surveyed solutions:

• Roads are represented with their centre lines

• Some attributes are the same or similar

• Geometry is mostly the same – simple points and lines.

• There are similar generalization rules for different road situations

The EuroRoadS specification must adapt to the existing solutions, both simpler and more complex, to ensure maximum benefit. The model can’t be restricted to the lowest common


denominator since that would disqualify available information that possibly is or will become of interest.

Ideally, from the data client’s point of view, the application schema should offer only one way to represent road data. The approach used in the EuroRoadS application schema is however quite open and flexible in that it defines a number of alternative options. This will enable a high number of content providers to adapt to the schema. It will however require more work from the users (data clients) if all options will be supported.

6.1.1 Requirements To conclude the above, the following requirements are valid for the EuroRoadS model:

• Fulfil the requirements stated for the EuroRoadS project to ensure maximum usability and interoperability.

• The model needs widespread acceptance among content providers who are going to implement support for data delivery without having to spend too much on implementation. The mapping between existing data and the EuroRoadS interface must be theoretically and practically possible and not too difficult.

• The model needs widespread acceptance among information providers who are to integrate road data with other data to enable usable end user services.

• The EuroRoadS interface can’t be too simple so its use becomes too restricted.

6.1.1.1 Project specification

6.1.1.1.1 ISO/TC211

The EuroRoadS specifications are to be defined as ”profiles on the ISO/TC 211 standards”. For this document this has been interpreted as described below:

- UML according to ISO 19103 is used as conceptual schema language.

- A number of specifications are profiled for use in EuroRoadS

ISO 19107 – Spatial schema for spatial characteristics

ISO 19108 – Temporal schema for temporal characteristics

ISO 19109 – Rules for application schema for overall rules on how to define application schemas. The EuroRoadS schema is viewed as an application schema in the context of ISO 19100.

ISO 19133 – Location based services tracking and navigation. The part about linear referencing is profiled and reused.

- Furthermore it has been suggested to use ISO 19136 – Geography markup language (GML) as basis for the data exchange structure. This implies certain rules on how UML is used.

6.1.1.2 Core model

The core model for EuroRoadS is derived from the results of the investigation in D6.1 [8]. An important task when creating this conceptual model has been to allow for various existing


implementations. Also GDF (the roads and ferries theme), see chapter 6.1.2 below, has been considered as an important source of requirements. Various views and aspects can be used when developing a schema for road data. The view used in EuroRoadS is that the road network essentially is represented as a linear network where the various network elements carry characterizing attributes usable for certain applications.

The model has been designed so it allows for:

- A geometric representation of the network, where the roads are represented by linear geometry.

- A topological representation of the network which adds explicit connectivity between roads.

- Both planar and non-planar graphs. The planar case requires certain extra constructs for the representation of grade separated crossings.

- The model allows for different levels of generalization and also mappings between the different levels. The GDF concepts for this has been reused and adapted to the EuroRoadS schema.

- Stable entities with globally unique identifiers to allow network referencing and updates.

- Flexibility in the way the road network elements are classified to allow for extensions of the core model.

- Flexibility in the way attributes are handled to allow for various extensions of the core model. To allow for simple mappings with various existing solutions for attributes can be attached in two ways:

Directly to the road network elements

By the use of linear referencing

6.1.1.2.1 Data exchange

It is anticipated that the data exchange solution in EuroRoadS will be file based. This means that whenever data is transferred from a EuroRoadS content provider to a data user, files are transferred. By the use of ISO 19136, there will be a clear mapping between the conceptual model in this document and the data exchange structure which is necessary for a successful data exchange (which involves the process of creating information from data). The transferred data represent instantiations of the concepts defined in this document.

It is required that the EuroRoadS specification support the exchange of incremental updates to a dataset. This specification therefore defines a package with a number of classes to represent object and attribute updates (insert, modify, delete, split, merge). Input to this model is the ActMap model [11], see also chapter 6.1.3 below, and also requirements from the EuroRoadS project members. The model is created from a data representation point of view and does not include anything that has to do with how such data are created or represented in a specific implementation database.


6.1.2 EuroRoadS and GDF On a technical level the GDF specification from ISO/TC204 [9] is currently not harmonized with ISO/TC211 regarding conceptual schema language or any of the other areas needed for this specification (spatial, temporal, metadata, exchange structure). On a conceptual level however, GDF is used as an important input for this document.

The EuroRoadS road network information model is required to include a mechanism for exchange of incremental updates. To be able to provide such a mechanism, the exchangeable road data defined in this specification can’t deviate much from the ones used in the previously investigated existing solutions (see EuroRoadS report D6.1 [8]). GDF and some of the investigated solutions differ quite a lot. The most important issue in this context is how attributes are connected to the road network and updated:

- There are existing solutions that use variations of linear referencing mechanisms where attributes are updateable and identifiable separately from the road network. If these content providers shall provide road segments where all attributes are treated as attributes identifiable only thru road segments, they have to perform some kind of a dynamic segmentation process where new objects have to be created. In this case it will become very difficult (close to impossible) to have a system that can also exchange updates of these segments that didn’t exist in their database in the first place.

- There are also existing solutions that store homogeneous road segments with a set of attributes for each road segment (the attributes are valid for the entire segment). These content providers can’t be required to invent identities for each and every attribute value to be able to exchange updates for attributes separated from the road network.

The GDF specification does not allow for the notion of separately identifiable and updateable attributes, which will have to be supported by EuroRoadS.

The EuroRoadS specification tries to use GDF to the maximum possible extent:

- A clear mapping with and/or reuse of the concepts in the GDF roads and ferries theme.

o Road element, Road

o Ferry, Ferry connection

o Junction, Intersection

o Interchange, Roundabout, Enclosed traffic area

o Grade separated crossing and edge levels

o Various attributes (yet to be defined in this document)

- The upcoming EuroRoadS specification for an exchange model will have to assess the GDF specification of the various concepts related to data exchange such as albums, volumes etc.

The EuroRoadS information model differs from GDF conceptual model in the following aspects:

- UML is used as the preferred conceptual modelling language since that is used within ISO/TC211.

- Basic spatial characteristics (geometry and topology) are reused from ISO 19107.


o As far as topology is concerned, EuroRoadS makes no conceptual difference between simple and complex features when it comes to topology (i.e. the topology is not redefined at complex level). This means that, from a topological point of view, edges and nodes are used, regardless if objects represent roads/intersections or road elements/junctions. Basically, any road network represented with the EuroRoadS schema consists of 0d and 1d objects using the same classes.

- Basic temporal characteristics are reused from ISO 19108

- Metadata (described in the EuroRoadS deliverable D6.8) is partly defined within EuroRoadS and partly reused from ISO 19115.

- To be able to support some of the investigated existing solutions, EuroRoadS supports a model where attributes can be handled separated from the road network features themselves using various network referencing mechanisms.

6.1.3 EuroRoadS and ActMap The aim of the ActMap project is to investigate and develop strategies for the dynamic actualization of digital map databases. Actualized map components should be integrated and/or attached to the in-vehicle digital map. This mechanism represents an important milestone for the ubiquitous availability of future location-based information and the quality of the map databases for future in-vehicle applications.

The project has built test environments to validate the mechanisms primarily for advanced navigation and ADAS (curve speed control and predictive cruise control with speed adaptation) applications. The figure below shows an overview of the context of ActMap.

Figure 6-1 - Overview ActMap


The data model of ActMap updates is shown in the figure below:

Figure 6-2 - Data model of ActMap updates

The principle of this model is that the digital map should be updated according to the current location of the bearer of the map (the vehicle). The map is divided in partitions where each partition refers to a number of update collections. An update collection contains all changes to a partition since the previous version. The update operations in an update collection can be split into several update transactions where each transaction consists of related updates


(updates needed to produce a consistent database state). Each transaction can be related to an event which usually corresponds to a real world event which has a dynamic behavior.

When considering the business and data refinement process (see chapter Fel! Hittar inte referenskälla.), EuroRoadS is positioned between content- and information provider. ActMap, on the other hand, is positioned between information- and service providers, or even between service provider and end user. One important focus for ActMap has been to provide a model which is suitable for use in light equipments with limited computation power and therefore designed an update model suitable for serial processing according to the Simple API for XML (SAX) model.

On a technical level, the ActMap schema is designed to wrap the GDF conceptual model with simple point-, line- and area features, complex features and relationships. As long as the EuroRoadS model relies on modeling according to ISO/TC 211, reuse of ActMap will be limited to a conceptual level (like the reuse of GDF).

The concepts of a transaction and update (add, change, delete, merge and split) will be reused in EuroRoadS. The concept of update collections and dependencies seem to have to do mostly with the fact that a map resides in a moving vehicle which needs local consistent updates according to the current location. This requirement is not seen as valid for EuroRoadS. Also events are considered to be out of scope for EuroRoadS for the time being.

6.1.4 EuroRoadS and other standardization efforts 6.1.4.1 OGC

From the OGC homepage (http://www.opengeospatial.org), the following description of the organization can be found:

“The Open Geospatial Consortium, Inc. (OGC) is a non-profit, international, voluntary consensus standards organization that is leading the development of standards for geospatial and location based services. Through our member-driven consensus programs, OGC works with government, private industry, and academia to create open and extensible software application programming interfaces for geographic information systems (GIS) and other mainstream technologies. Adopted specifications are available for the public's use at no cost.”

OGC as an organization is heavily involved in ISO/TC211 as a liaison. Some of the ISO specifications actually have their origin in OGC. One example of that is GML 3.1 which is currently being standardized in ISO/TC 211 as ISO 19136. This is carried out by a joint OGC/ISO editing committee. GML 3.1 is pointed out by the EuroRoadS deliverable 6.1 [8] to be used as basis for the definition of an exchange format.

Another specification that could be interesting from a EuroRoadS perspective is the Web Feature Service Implementation Specification (WFS). The aim for WFS is to provide a specification for the retrieval and update of feature data over http. The specification relies heavily on GML for the transfer of schemas and data. The WFS specification contains a model for transactions where a transaction can consist of insert, update and delete operations according to the following model:


Transaction

Insert+typename

Update+typename

Delete

UpdateOperation

1

0..*

gml:_Feature

1

1

ogc:Filter+name+value

wfs:Property

1

1

1

1

1

1

Figure 6-3 - OGC WFS update model

The WFS model is primarily designed for online “SQL-like” feature updates over http which is not the primary aim for EuroRoadS at the moment. Still, it is interesting to note that it “wraps” gml features and can be used to update any gml based data. According to the proposal in D6.1 [8] the EuroRoadS transfer schema will be based on GML and could therefore be used in a WFS context.


6.1.5 A use case view of EuroRoadS

Data supplier Data user

search Metadata cataloguesupply Metadata catalogue

EuroRoads

arrangement of supply

data supply according to EuroRoads Spec.

Administration of Meta-database

EuroRoads Operator

Figure 6-4 - Use-case view

The figure above indicates a centralized meta-database to which data suppliers (content providers) provide metadata that is viewable by data users. The metadata storage or interface provides information about available data, quality etc. When a data user receives data from a data supplier, the data is formatted according to the EuroRoadS specification.

The aim for the application schema defined in this document is to provide the basis for a harmonized definition of the structure and possible content of datasets transferred between content providers and users.

This specification is concerned with the definition of data structures for core road data and therefore does NOT include procedural or algorithmic matters such as:

• How are unique and permanent identifiers generated?

• How are updates tracked or calculated in a road database?

• How is explicit topology derived from a geometric representation?

Though the specification can be used as basis for a road network structure in a database, it is not the aim for EuroRoadS to build a European roads database. The aim is to enable successful data transfer between content providers and users of road data.

6.1.6 Package structure The application schema is subdivided in a couple of coherent packages. The package structure is shown in the figure below. The individual packages are defined in chapter 6.3-6.8.


Figure 6-5 - Package structure


Package Described in chapter

Description

ISO 19107 Profile

6.2.1 A pure subset of the ISO 19107 standard to describe the geometry and the topology of geographic information.

In EuroRoadS geometry can be represented up to 1,5D objects (surfaces represented by their boundary) in a 3D coordinate space, while topology can be used to represent the connectivity of the 1-dimensional road network graph.

ISO 19108 Profile

6.2.2 A pure subset the ISO 19108 standard to describe temporal aspects of geographic information. ISO 19108 is not a standalone standard, but an addition to ISO05 (1992). Standardizing temporal characteristics. This standard deals with time related to physical reality. It distinguishes between the geometry of time and topology of time.

EuroRoadS uses time instants and periods from this standard.

ISO 19133 Profile

6.2.4 This profile defines a schema which is a subset of ISO 19133 together with a couple of modifications. The standard is part of Location Based Services (ISO 19132-19134). ISO 19133 is used for tracking and navigation. Tracking can be the process of following and reporting the position of a vehicle, while navigation is the combination of route, route transversal and tracking.

EuroRoadS use the part “Linear referencing system” from this standard. Linear referencing allows for specification of positions along the network using measured distances from known positions.

In EuroRoadS, this is one way of attaching features and attributes, other than those specified directly for the classes in the road network package, to the road network.

Basic types 6.3 Defines some basic classes used in other EuroRoadS packages.

Network 6.4 Defines classes for the representation of a road network (spatially represented either geometrically or topologically) together with a minimum set of mandatory attributes.

Network referencing

6.5 Extension to the ISO 19133 profile that adds more capabilities to attach data to the network. ISO 19133 allows for linear positions. This package adds:


- Segments (subsets) of linear elements

- References to nodes

- Turns and manoeuvres

- A possibility to record side of the road (left/right) and direction (same/opposite).

Attribute base

6.6.2 Defines base classes for all attributes that are conditional and can be attached to the road network, either directly or using linear referencing mechanisms.

Example attributes

6.6.3 A package that thru some examples shows how attributes can be defined and attached to the road network.

Border nodes 6.7 Defines a class for the extra information that can be provided for nodes at National or other Administrative borders.

Grade separated crossings

6.8 Defines classes for the representation of grade separated crossings in the road network.

Updates 6.9 This package defines classes that handle updates within EuroRoadS. The different types of updates are insertion, modification and deletions of objects. All updates are handled within transactions to ensure that all or none of the updates are completed within the dataset.


6.2 ISO Profiles

6.2.1 ISO 19107 Profile – Spatial schema The ISO 19107 Profile for EuroRoadS defines the classes that are used to define the spatial aspects of the road data model. The profile is defined according to conformance level 1 which means that it contains only restrictions on the standard schema.

6.2.1.1 Geometry Geometry provides the means for the quantitative description, by means of coordinates and mathematical functions, of the spatial characteristics of features, including dimension, position, size, shape, and orientation. The mathematical functions used for describing the geometry of an object depend on the type of coordinate reference system used to define the spatial position. Geometry is the only aspect of geographic information that changes when the information is transformed from one geodetic reference system or coordinate system to another.

The EuroRoadS profile of ISO 19107 uses the following geometric objects to allow for the representation of up to 1,5 d objects (surface represented with it’s boundary) in a 3d coordinate space.:

Class name Remark

GM_Point Used as is in ISO 19107.

GM_Curve Multiplicity at GM_CurveSegment end of Segmentation relation changed from 1..* to 1. Only one curve segment is allowed for a curve.

OCL: GM_Curve: segment->size() = 1

GM_LineString Used as is in ISO 19107.

GM_Surface Multiplicity at GM_SurfacePatch end of Segmentation relation changed from 1..* to 1. Only one surface patch is allowed for a surface.

Multiplicity at GM_Surface end of Segmentation relation changed from 0..1 to 1. A surface patch must belong to a surface.

OCL: GM_Surface:

patch->size() = 1

GM_SurfacePatch:


surface->size() = 1

GM_Polygon No spanningSurface is used (i.e. no internal “topography”). Only boundaries are handled:

OCL: GM_Polygon:

spanningSurface->size() = 0

GM_Ring Used as in ISO 19107

GM_SurfaceBoundary Exterior boundary is required.

OCL: GM_SurfaceBoundary:

exterior->size() = 1

GM_Complex Used as is in ISO 19107. Geometric complexes are used to define the topological configuration for the geometric objects. Since all geometric primitives in a complex are topologically integrated (i.e. no overlaps, intersections etc), the following principle is valid:

• All geometric primitives in one complex mean that no geometric primitive overlap or intersect itself or other primitives.

• Every primitive is contained in a complex of its own mean that no primitive overlap or intersect itself but can intersect other geometry.

• If complexes are not used, no assumptions can be made regarding overlaps and intersections.

The GM_Complex does not offer anything in particular to ensure planar networks when 3d-coordinates are used.


GM_Object

GM_Primitive

GM_Point GM_OrientablePrimitive

GM_Curve GM_SurfaceGM_CurveSegment

GM_LineString

+curve

1

+segment

1

GM_SurfacePatch+surface

1

+patch

1

GM_OrientableCurve GM_OrientableSurface

GM_Polygon

GM_Complex

+element

1..*

+complex

0..*

+subComplex0..*

+superComplex0..*

GM_SurfaceBoundary

1

+boundary1

Figure 6-6 - Geometry

GM_SurfaceBoundary GM_Ring

1 +interior0..*

1 +exterior 0..1

GM_Complex

GM_CompositeCurve

GM_CompositeGM_Boundary

GM_PrimitiveBoundary

Figure 6-7 - GM_SurfaceBoundary

6.2.1.2 Topology Topology deals with the characteristics of geometric figures that remain invariant if the space is deformed elastically and continuously — for example, when geographic data is transformed from one coordinate system to another. Within the context of geographic information, topology is commonly used to describe the connectivity of an n-dimensional graph, a property


that is invariant under continuous transformation of the graph. Within EuroRoadS, topology can be used to represent the connectivity of the 1-dimensional road network graph.

The EuroRoadS profile of ISO 19107 uses the following topological objects:

Class name Remark

TP_Primitive Changed cardinality at the GM_Primitive end to 1 to require a geometric realization for every topological primitive.

OCL: TP_Primitive:

geometry->size() = 1

TP_Node The multiplicity at the spoke end of the CoBoundary association is changed from 0..* to 0 since that information is redundant and can be derived from the Boundary association between TP_Edge and TP_Node.

OCL: TP_Node:

spoke->size() = 0

TP_DirectedNode Used as in ISO 19107.

The boundary of an edge consists of to directed nodes where the positive node is the starting node and the negative node is the end node.

TP_Edge The multiplicity at the spoke end of the CoBoundary association is changed from 0..* to 0 since TP_Face isn’t part of this profile.

OCL: TP_Edge:

spoke->size() = 0

TP_DirectedEdge The directed edge is only used as baseclass of the edge. The primitive role of the relationship to TP_Face (Boundary) has multiplicity 0.

OCL: TP_DirectedEdge:

primitive->size() = 0

TP_Complex Used as is in ISO 19107. If realized by a geometric primitive, applies topological rules to the topological elements (see GM_Complex).


TP_DirectedTopo

TP_DirectedEdge TP_DirectedNode

TP_Edge TP_Node+primitive

0..*

+boundary

2

TP_Primitive TP_Complex+element

1..*

+complex

1..*

Figure 6-8 - Topology

The topological profile defines the classes used for the representation of explicit linear network topology.

In ISO 19107 every topological primitive can, but is not required to, have a geometric primitive as its realization. In EuroRoadS, a geometric realization for all topological primitives is required. The geometric realization is required to be of the same dimension as the topological primitive:

• TP_Node is realized by a GM_Point

• TP_Edge is realized by a GM_Curve

Figure 6-9 - Relationship between geometry and topology


6.2.2 ISO 19108 Profile – Temporal schema The EuroRoadS profile of ISO 19108 defines the classes that are used to define the temporal aspects of the road data model. The profile is defined according to conformance level 1 which means that it contains only restrictions on the standard schema.

Figure 6-10 - Temporal profile

The temporal profile defines the classes needed to represent points and periods in time analogously to 0D and 1D geometry in the spatial schema.

The EuroRoadS profile of ISO 19108 uses the following classes:

Class name Remark

TM_Instant Used as is in ISO 19108.

TM_Period Used as is in ISO 19108.

TM_Position Used as is in ISO 19108.

6.2.3 Metadata Metadata is intentionally left out in this document. The deliverable D6.8 – Metadata catalogue will define a metadata profile for EuroRoadS. However, some metadata will be required because this specification contains some degrees of freedom. Some things must be specified by content providers regarding the type of support for EuroRoadS in their implementation. These extra requirements are listed below

• Geometric or topological representation of the road network (chapter 6.4.3/6.4.4)

• Support for optional road network constructs (chapter 6.4.5):

- Different detail levels such as Road element, Road, Junction, Intersection, Roundabout etc

- Routes


• Definitions on which optional/conditional attributes and features that are supported (chapter 6.6.3).

• Road network attribution using network referencing or as attributes on homogeneous road elements (chapter 6.6.5/6.6.4).

• Definition on user defined (content provider defined) attributes and features that are supported (chapter 6.6.6).

- The definition and the semantic meaning of the types

- Rules on how and when to use the types.

• Statement on if updates are supported (chapter 6.8)

6.2.4 ISO 19133 Profile – Linear Referencing

6.2.4.1 Introduction The ISO 19133 Profile package in the EuroRoadS model is not a profile according to ISO 19106 because of the modifications done in this package. The part used from ISO 19133 is the linear referencing package which defines a harmonized way of relating information to linear objects.

The ISO19133 package “Linear Reference Systems” supplies classes and types to the definition of linear reference systems. Linear reference systems are in wide use in transportation. They allow for the specification of positions along curvilinear features by using measured distances from known positions, usually represented by physical markers along the right-of-way of the transportation feature.

In EuroRoadS, linear referencing is one way of attaching features and attributes, other than those specified directly for the classes in the road network package, to the road network.

Figure 6-11 - Location based services profile for linear referencing


The method of linear referencing is extensively used in the realm of road network modelling. Besides supporting existing implementations, there are a couple of benefits associated with the use of linear referencing:

1. It shall be possible for content providers to provide attributes only. If all attributes where modelled as attributes on the road network elements a content provider would have to know “the whole truth”, i.e. own both network and all attributes.

2. If attributes are loosely coupled to the network through linear referencing, it is possible to attach new attributes without affecting the segmentation of the network. The network elements and attributes become independent to some degree.

6.2.4.2 Reused definitions from ISO 19133 The following classes (prefixed “LR_”) are reused from ISO 19133.

Class name Remark

LR_Element Used as is in ISO 19133 but in EuroRoadS the association datumMarkers from LR_Element to LR_ReferenceMarkers is replaced by the association element from LR_ReferenceMarkers to LR_Element. Se figure 6-8 in this document and figure 30 in ISO 19133.

This class is sub-classed in EuroRoadS.

LR_LinearReferencingMethod Used as in ISO 19133 but in EuroRoadS the two outgoing associations marker and referenceElement is removed.

A future version of this document or the final version of “Specification of core European road data” will have to specify the different types of linear referencing methods that actually can be used within EuroRoadS.

LR_PositionExpression Used as is in ISO 19133 but in EuroRoadS exactly one of referent or referenceDomain should be given. The usage of this class in EuroRoadS is further explained below.

LR_OffsetExpression Used as is in ISO 19133.

LR_ReferenceMarker Used as is in ISO 19133 but in EuroRoadS the association datumMarkers from LR_Element to LR_ReferenceMarkers is replaced by the association element from LR_ReferenceMarkers to LR_Element. Se figure 6-8 in this document and figure 30 in ISO 19133.

LR_OffsetDirection Used as is in ISO 19133.

LR_OffsetReference Used as is in ISO 19133.


6.2.4.3 LR_PositionExpression

The class “LR_PositionExpression” from ISO19133 is used to describe a 0-dimensional position or locations in the reference system given by a measure value and a method of measurement (LR_LinearReferenceMethod) together with either a curvilinear element (LR_Element) or a reference marker (LR_ReferenceMarker). The measure value is usually a distance along the linear element. There is also an optional possibility to specify an offset (LR_OffsetExpression). The interpretation of the given measurement value is dependent of the method of measurement.

+measure : MeasureLR_PositionExpression

+name : CharacterString+type : CharacterString+units : UnitOfMeasure+offsetUnits : UnitOfMeasure+positiveOffsetDirection : LR_OffsetDirection = right

LR_LinearReferenceMethod

+LRM 1

+name : CharacterString+type : CharacterString+position : GM_Point+location : LR_PositionExpression

LR_ReferenceMarker

+referent

0..1

LR_Element

+referenceDomain0..1

+element

1

0..*

+offsetReference : LR_OffsetReference+offset : Measure

LR_OffsetExpression+offset

0..1

Figure 6-12 - Position expression

Constraint Definition

markerOrElement A reference to either a reference marker or an element must be set for a position expression. Both are not allowed.

OCL:

referent.size() + referenceDomain.size() = 1

A more complete description of LR_PositionExpression, LR_LinearReferenceMethod, LR_ReferenceMarker, LR_Element and LR_OffsetExpression is found in ISO19133.


PE1 : LR_PositionExpressionmeasure : 0,7

RelativeLength=0,7

LRE1 : ER_LRElement

RL1 : ER_RoadLink

link

LRM1 : LR_LinearReferenceMethodname : RelativeLengthFromStart

200m

RM1 : LR_ReferenceMarker

PE1 : LR_PositionExpressionmeasure : 200

LRM1 : LR_LinearReferenceMethodname : LengthFromMarkerPosition

referent

referenceDomain LRM

LRM

element

Figure 6-13 - Two simple examples of position expressions


6.3 Basic types package The basic types package defines three classes, ER_ObjectID, ER_IdentifiableObject and ER_RoadFeature which lay the foundation for classes with a permanent id. It is only objects derived from ER_IdentifiableObject that are possible to update thru the updating mechanisms of EuroRoadS.

Figure 6-14 - Basic types

6.3.1 ER_ObjectId This class is a data-type that defines an object id.

Attribute Definition

permanentId The identity of an object. A character string which shall be used according to the rules for identities defined in the Updates section in this document. The identity shall use the principle proposed below (in chapter 6.4.3)

versionId An optional version identification that uniquely identifies the version of an object. This can be used in updating scenarios to keep a consistent line of evolution for an object. If used, the versionId shall use the same principle as permanent id above.

alternateId An optional identity that can be used to provide the identity from the originating system.

6.3.2 ER_IdentifiableObject An abstract base-class for any object that carries a permanent id.



Id The identity of an object according to ER_ObjectId defined above.

6.3.3 ER_RoadFeature ER_RoadFeature is an abstract base-class for road features. A road feature within EuroRoadS is either an element in the road network itself or a separately identifiable and updateable object associated with the road network.

In GIS-terminology, the term feature is often used for objects that have geometry. In ISO 19100 however, the term is defined as “an abstraction of a real world phenomenon” which is a wider definition.


6.3.4 Permanent identities An important part of EuroRoadS and any other system is to have unique identities to be able to update elements and/or attributes. To be able to update a specific road element after the initial delivery to a system, one needs to know the id of that element so the update will affect the correct element. EuroRoadS requires some rules for handling of identities. These rules are:

New objects have new identities that never have been used before

Deleted objects have identities that never must be used again

Updated objects must keep their identities

These rules are defined from a database perspective. From a real world perspective the picture is a little bit more complex. In a specific implementation decisions have to be made regarding how to translate real world changes to database updates. One example is when an existing road element is split because a new road element has been connected. The reason can be either that a new real world road was opened or that the database didn’t reflect the real world in a proper way (the road exists but isn’t registered yet).

In this case some would prefer to keep road element 1 (shortened) and create one new road element. Some other would perhaps delete road element 1 and create two new elements like in the figure below.

Road element 1

Road element 2? Road element 3

Figure 6-15 - Update example

Since different existing content providers can have implemented different rules for how to handle these different situations it is not possible for EuroRoadS at this stage to specify harmonized rules for this. Instead EuroRoadS provides classes that allow certain objects to be


uniquely identified and rules (defined above) on how object updates shall be represented (see chapter 6.8 Updates). In the future it’s preferable that the entire process of updating road data is harmonized, both regarding how various real world changes and also database corrections are reflected.

6.3.4.1 Unique identifiers Using a unique identifier, each element can be properly addressed. Referencing by unique identifiers will not cause any collisions and will have 100% success rate if identities are kept unique throughout subsequent databases and within the lifetime of the object.

Unique identities can be based on several algorithms. Two that are widely used are UUID/GUID and MD5.

6.3.4.1.1 Using UUID1 or MD52

The scheme for UUIDs origins from OSF/DCE3. The UUID is designed as a 128 bit number used to uniquely identify objects on the internet. To achieve unique identifiers a solution is to concatenate the UUID version with the MAC-Address of the computer that is generating the UUID, and with the number of 100-nanonsecond intervals since the adoptions of the Gregorian calendar. In practice the algorithm is more complicated.

MD5 is a widely used cryptographic algorithm that generates a 128-bit hash value.

These methods for identities would require every content provider not already using UUID or MD5 to generate an extra id for every element supplied thru EuroRoadS.

Example:

Content provider A is using integers as a unique id within their system.

An integer is not unique within EuroRoadS as several content providers might use the same integer values within their systems as unique ids.

This will force provider A to add a column, with a unique UUID that would map their own id to EuroRoadS unique id. As shown in figure below. The UUID show below could be substituted with MD5 or any other algorithm that produces a unique id.

Id (Integer) elementName ... UUID (Unique identifier)

1 ElementName1 ... 6AD2B307-7347-44f4-8A42-21EFB7447689

1 UUID – Universally unique identifier 2 MD5 - Message-Digest algorithm 5 3 OSF – Open Software Foundation. DCE – Distributed Computing Environment


6.3.4.1.2 Using content provider identity and a unique character string

This solution is based on assigning each content-provider a unique provider-id (pid). The content-provider could then use this pid to attach it to their own id on each element as a prefix, creating a unique id for the element within EuroRoads. The id would then be a character string of a different-length from different content-providers. As each content-provider uses different unique id’s the length of the character string would be different. However the main focus is to keep the id unique, which is achieved using this method.

Example:

Content provider A is assigned the pid “1”. A is using integers as their unique id within their system. See figure below

Id (Integer) elementName (String) ...

1 ElementName1 ...

Any data delivered to EuroRoadS would have the unique id “1:XXX”. Provider A would then convert their ids into unique ids by adding pid “1” as a prefix to their ids according to example below.

UUID (Character string) elementName (String) ...

1:1 ElementName1 ...

This solution would require EuroRoadS to keep administrative records of each content-provider in their own system. Keeping track of which id each content-provider is assigned. It also requires that it is the content provider’s responsibility to keep unique identities within their own scope.

A problem could occur when a content provider is split; being that a content-provider is a country or any other organisation within a country or even within the union. This would cause problems as a new content-provider id would have to be assigned, but one of the providers would still have to maintain old elements that would have the old content-provider id assigned to them.


Example:

Content-provider A is assigned the content-provider id “1”. Provider A is then divided into two providers. One is still called A, but the new provider is called B. Provider A keeps the id “1”, but the other being assigned the content-provider id “2”.

Content provider B would then have old elements that would require the EuroRoadS id “1” as prefix to be identifiable correctly, forcing B to map any new data to an old provider-prefix.

Another potential problem could arise when several content providers have parallel representations of the same real world object. This problem can not be handled using any of the identity methods described above. To make data updating using any method above work, initial data transfers and updates must origin from the same source.

6.3.4.2 Map-based location referencing Map-based on-the-fly location referencing means that the sender creates a location reference using the senders digital map, this locations reference can be decoded relative to the receivers digital map upon arrival to the receiver. This reference is created using a certain map characteristics, e.g., geometry, connectivity, classification. It is not necessary to store additional ID’s in a digital map.

The location code is generated from the map database of the senders system, embedded in a message. The receiver can then use this location to map the object. This is done on-the-fly.

AGORA and ROSA are two new locations referencing technologies that could be used. AGORA is founded on three basic aspects of digital maps: Geometry (Shape), Topology (Connectivity) and Type (Feature Classification). AGORA specifies the encoding and format of the location reference. Decoding occurs at the discretion of the receiver.

ROSA is a location referencing method created by a car-manufacturer that are based on the method SPOT. SPOT spatial (coordinates), function (object class) and a describing reference (Identification of object). ROSA uses this technique as base of its own referencing method, but adds another dimension by allowing 3D (height) objects to be referenced.

Both AGORA and ROSA have similar test-results, being a proven hit-rate of above 95%.

Using location referencing would require that EuroRoadS also defines a model to use as standard for the algorithm to be used.

The map-based location reference solution is not possible to use at its current state, the reason is that the hit rate is not 100%, though the methods seem very promising and could very well be used in the future.


6.3.4.3 Proposed solution The proposed solution is to use UUID within EuroRoadS. This would force each content-provider to keep track of two ids within their system:

- The internal id of the object in their own system

- A EuroRoadS id that will be supplied with every delivery within EuroRoadS.

In order to perform updates, receivers of EuroRoadS data would also have to keep track of the EuroRoadS identities since update information refers to those identities.

Any other provider that is not the initial creator of an object within EuroRoadS, would have to load all previous objects with EuroRoadS id’s within an area to their system to be able to supply updates to that area.

Using UUID as a unique identifier is suggested in ISO 11578.


6.4 Network package

6.4.1 Overview To allow for different road network representations and sophistication the network package is subdivided in three levels and a couple of different parts. The reason for this way of modeling is primarily to enable the different existing solutions to map to the EuroRoadS model and also to provide compatibility with GDF [9].

On the base level there are classes for concepts such as road links and road nodes defining a road network. Regardless of the kind of spatial representation or level of detail being represented these basic classes are used. The main reason for this is that it shall be possible to over time change the spatial representation (from a geometric to an explicit topological representation or vice versa) without changing the class for the individual network elements.

Road network base

Geometric representationoption

Topological representationoption

Optional constructs (Aggregations, Routes)

Figure 6-16 - Road network overview

On the next level there are two options for the spatial representation of the road network. The road network has a spatial representation that is either geometrical or topological (where topology has a geometric realization).

On the top level, regardless if a geometric or topological representation is used, there are constructs to enable aggregations and different levels of detail of road network elements in different ways which are described below.

How the attribution of the road network is handled is described in chapter 6.6.


«Abstract»ER_RoadnetElement

+level[1] : ER_RoadLinkLevel+formOfWay[1] : ER_FormOfWay+nationalRoadClass[1] : ER_NationalRoadClass

ER_RoadLink

+level[1] : ER_RoadNodeLevel+formOfNode[0..1] : ER_FormOfNode

ER_RoadNode

+validity[0..1] : TM_PeriodER_DetailLevelMapping

+lowerLevelElement1+mapsToAtUpperLevel 0..*

+upperLevelElement 1 +mapsToAtLowerLevel0..*

+ER_MainRoad+ER_FirstClass+ER_SecondClass+ER_ThirdClass+ER_FourthClass+ER_FifthClass+ER_SixthClass+ER_SeventhClass+ER_EighthClass+ER_NinthClass+ER_UndefinedNationalRoadClass

«enumeration»ER_NationalRoadClass

ER_Route

+routeLinks

1..*

+route 1

+validity[0..1] : TM_Period+direction[1] : Sign

ER_RouteLink

+link 1

+routes0..*

Geometry::GM_Curve

1

+curve0..1Geometry::GM_Point

1

+point0..1

+roadNode

1

+node0..1

+roadnetLink

1

+edge0..1

«Abstract»Basic types::ER_IdentifiableObject

«Abstract»Attribute base::ER_RoadAttribute

+roadnetElement

0..1+attributes

0..*

Geometry::GM_Surface

1

+surface0..1

+level[1] : ER_FerryLinkLevel+formOfFerry[1] : ER_FormOfFerry

ER_FerryLink

+validity[0..1] : TM_Period

«Abstract»ER_RoadnetLink

+ER_RoadElement+ER_Road

«CodeList»ER_RoadLinkLevel

+ER_Roundabout+ER_EnclosedTrafficArea+ER_PseudoNode+ER_GradeSeparatedCrossing

«CodeList»ER_FormOfNode

+ER_FerryConnection+ER_Ferry

«CodeList»ER_FerryLinkLevel

+ER_ShipOrHovercraft+ER_Train

«CodeList»ER_FormOfFerry

«Abstract»Basic types::ER_RoadFeature

ER_Node

ER_Edge



+ER_Junction+ER_Intersection

«CodeList»ER_RoadNodeLevel

+ER_Motorway+ER_MultiCarriageway+ER_SingleCarriageway+ER_RoundaboutCircle+ER_TrafficSquare+ER_EnclosedTrafficArea+ER_SlipRoad+ER_ServiceRoad+ER_EntranceOrExitCarPark+ER_EntranceOrExitService+ER_UndefinedFormOfWay

«CodeList»ER_FormOfWay

+formOfComplexElement : ER_FormOfComplexElementER_ComplexRoadnetElement

+ER_Interchange+ER_Roundabout+ER_AggregatedWay

«CodeList»ER_FormOfComplexElement

Figure 6-17 - Road network


6.4.2 Road network base

6.4.2.1 ER_Edge The class ER_Edge derives from the ISO 19107 class TP_Edge and adds a reference to the owning ER_RoadnetLink (see below). This makes it possible to define the necessary rules for how topological elements may be connected regarding to type. The edge is a bidirectional and one dimensional topological entity in the network that connects nodes (ER_Node). The edge has a positive and negative direction. According to ISO 19107 the positive direction starts in the referenced node with a positive orientation and ends in the referenced node with a negative orientation.

Relationship Definition

roadnetLink The ER_RoadnetLink instance that references this edge instance.


OnlyAllowedTopology An ER_Edge must only be bounded by instances of ER_Node.

OCL:

boundary->forAll(n : TP_Node | n. oclIsTypeOf(ER_Node))

OnlyAllowedTypesLev1 An ER_Edge whose roadnetLink is at level ER_RoadElement or ER_FerryConnection may only be bounded by ER_Nodes whose roadNode is at level ER_Junction.

OCL:

roadnetLink.oclAsType(ER_RoadLink).level = ER_RoadElement or roadnetLink.oclAsType(ER_FerryLink).level = ER_FerryConnection implies

boundary->forAll(n : ER_Node | n.roadNode.level = ER_Junction)

OnlyAllowedTypesLev2 An ER_Edge whose roadnetLink is at level ER_Road or ER_Ferry may only be bounded by ER_Nodes whose roadNode is at level ER_Intersection

OCL:

roadnetLink.oclAsType(ER_RoadLink).level = ER_Road or roadnetLink.oclAsType(ER_FerryLink).level = ER_Ferry implies

boundary->forAll(n : ER_Node | n.roadNode.level = ER_Intersection)


6.4.2.2 ER_Node The class ER_Node derives from the ISO 19107 class TP_Node and adds a reference to the owning ER_RoadNode (see below). This makes it possible to define the necessary rules for how topological elements may be connected regarding type.


roadNode The ER_RoadNode instance that references this node instance.


OnlyAllowedTopology An ER_Node must bound only instances of ER_Edge.

OCL:

primitive->forAll(e : TP_Edge | e. oclIsTypeOf(ER_Edge))

OnlyAllowedTypesLev1 An ER_Node whose roadNode is at level ER_Junction may only bound ER_Edges whose roadLink is at level ER_RoadElement or ER_FerryConnection.

OCL:

roadNode.level = ER_Junction implies

primitive->forAll(e : ER_Edge | e.roadnetLink.oclAsType(ER_RoadLink).level = ER_RoadElement or e.roadnetLink.oclAsType(ER_FerryLink).level = ER_FerryConnection)

OnlyAllowedTypesLev2 An ER_Node whose roadNode is at level ER_Intersection may only bound ER_Edges whose roadLink is at level ER_Road or ER_Ferry.

OCL:

roadNode.level = ER_Intersection implies

primitive->forAll(e : ER_Edge | e.roadnetLink.oclAsType(ER_RoadLink).level = ER_Road or e.roadnetLink.oclAsType(ER_FerryLink).level = ER_Ferry)

6.4.2.3 ER_RoadnetElement The class ER_RoadnetElement is an abstract base-class that represents an element in a road network. The road network is considered to consist of zero- and one dimensional objects (road nodes and road links) where those objects follow certain rules for how they may be defined to represent the various parts of the network.



attributes Refers to an optional set of characterizing attributes for the road element. This mechanism is used if attributes are connected directly to the road element.

mapsToAtUpperLevel If detail level mappings are used, refers to detail level mappings that refer to road net elements at a less detailed level. This option defines a way to comply with GDF complex features. This is an optional construct. Detail level mappings are described in chapter 6.4.5.1.

mapsToAtLowerLevel If detail level mappings are used, refers to detail level mappings that refer to road net elements at a more detailed level. This option defines a way to comply with GDF complex features. This is an optional construct. Detail level mappings are described in chapter 6.4.5.1.

6.4.2.4 ER_RoadnetLink An abstract base-class of ER_RoadLink and ER_FerryLink. The class represents a 1-dimensional element in the road network.

An ER_RoadnetLink is always valid in two directions where one direction is positive and the other is negative. In case of a geometric representation, the ER_RoadnetLink uses the direction of the underlying GM_Curve as its positive direction. In case of a topological representation, the ER_RoadnetLink uses the positive direction of the underlying ER_Edge as its positive direction. Any direction related restrictions such as speed limits, vehicle movement etc must be defined using separately defined attributes or features.


validity An optional attribute specifying the time period during which the roadnet link is in service in the real world. If not specified the validity is unknown.

Every roadnet link is allowed to but required to supply a validity to represent a temporal dimension to the data. Adding a temporal dimension can be quite tricky to handle and the issue is therefore described in a separate chapter in the EuroRoadS deliverable D6.5 [13].


Curve A geometric curve specifying the position and shape of the road link. If curve is supplied, edge (see below) must be empty.


Edge A topological edge specifying the position, shape and connectivity of the road link. If edge is supplied, curve (see above) must be empty. Note that a topological edge in EuroRoadS is required to contain a geometric realization. This means that by supplying an edge, both topological (explicit connectivity) and geometric (position and shape) representations are defined.

routes An optional construct which is a set of route links specifying in which routes this road link is a part.


SpatialRepr A link must have a spatial representation of either geometric or topological type. Both at the same time are not allowed. Note that a topological representation in EuroRoadS must have a geometric realization. This means that a topological representation also indirectly contains geometry.

OCL: curve->size() + edge->size() = 1

6.4.2.5 ER_RoadNode The class ER_RoadNode is a subclass of ER_RoadnetElement that represents a 0-dimensional element in the road network, usually a junction. The road node class can be used to represent Junctions, Intersections, Roundabouts and enclosed traffic areas depending on which level of detail is represented.


level Specifies the level this road node represents. The level is equivalent to the corresponding concept in GDF. Possible values are:

ER_Junction – The road node corresponds to a GDF level 1 junction

ER_Intersection – The road node corresponds to a GDF level 2 intersection

formOfNode An optional attribute defining a physical classification of the road node if it represents something more than an ordinary junction or intersection. Possible values are:

ER_Roundabout – The node represents a roundabout.

ER_EnclosedTrafficArea – The node represents an enclosed traffic area

ER_PseudoNode – A node that exists only to get a complete topology


for example when the network is segmented where attributes change. A pseudo node can have two and only two connected links.

ER_GradeSeparatedCrossing – A node that represents a grade separated crossing case where the topology is planar (i.e. no topological connection really exists).

Note that this codelist can be extended when additional node types are required.


point A geometric point specifying the position of the road node. If point is supplied, node (see below) must be empty.

node A topological node specifying the position and connectivity of the road node. If node is supplied, point (see above) must be empty. Note that a topological node in EuroRoadS is required to contain a geometric realization. This means that by supplying a node, both topological (explicit connectivity) and geometric (position) representations are defined.

surface An optional geometric surface representation of the node. This representation is allowed regardless if a point or node representation is used.


SpatialRepr A road node must have a 0 dimensional spatial representation of either geometric or topological type. Both at the same time are not allowed. Note that a topological representation in EuroRoadS must have a geometric realization. This means that a topological representation also indirectly contains geometry.

OCL: point->size() + node->size() = 1

6.4.2.6 ER_RoadLink The class ER_RoadLink represents a 1-dimensional element in the road network.

The road link can be used to represent road elements and roads and also higher level aggregations that functionally can be represented as a one dimensional element in a road network.


level Specifies the level this road link represents. The level is equivalent to the corresponding concept in GDF. Possible values are:


ER_RoadElement – Corresponds to a GDF level 1 road element

ER_Road – Corresponds to a GDF level 2 road

Note that this codelist can be extended when additional link types are required.

formOfWay Corresponds to the GDF attribute form of way with the addition that it can be specified as unknown. The attribute is mandatory. Possible values are:

ER_Motorway – GDF definition

ER_MultipleCarriageWay – GDF definition

ER_SingleCarriageWay – GDF definition

ER_RoundaboutCircle – GDF definition

ER_TrafficSquare – GDF definition

ER_EnclosedTrafficArea – GDF definition

ER_SlipRoad – GDF definition

ER_ServiceRoad – GDF definition

ER_EntranceOrExitCarPark – GDF definition

ER_EntranceOrExitService – GDF definition

ER_Undefined – Non-GDF value that defines an undefined form of way.

Note that this codelist can be extended when additional link types are required.

nationalRoadClass Corresponds to the GDF attribute national road class. Possible values are:

ER_MainRoad – GDF definition

ER_FirstClass – GDF definition

ER_SecondClass – GDF definition

ER_ThirdClass – GDF definition

ER_FourthClass – GDF definition

ER_FifthClass – GDF definition

ER_SixthClass – GDF definition

ER_SeventhClass – GDF definition

ER_EighthClass – GDF definition

ER_NinthClass – GDF definition


ER_UndefinedNationalRoadClass – Non-GDF value that defines an undefined national road class.


6.4.2.7 ER_FerryLink The class ER_FerryLink represents a 1-dimensional element in the road network where a ferry is used as transportation.


level Specifies the level this ferry link represents. The level is equivalent to the corresponding concept in GDF. Possible values are:

ER_FerryConnection – Corresponds to a GDF level 1 ferry connection

ER_Ferry – Corresponds to a GDF level 2 ferry

Note that this codelist can be extended when additional ferry link types are required.

formOfFerry Defines the type of transport on the ferry link. Possible values are:

ER_ShipOrHovercraft – Used if ferry is operated by a ship or hovercraft.

ER_Train – Used if ferry is operated by a train.

6.4.2.8 ER_ComplexRoadnetElement Complex roadnet elements define elements in the road network which are aggregations of road nodes and/or road links. This corresponds to the complex features in GDF which have no, or do not represent, topological boundaries.


formOfComplexElement Defines the type of complex element. Possible values are:

ER_Interchange – Corresponds to a GDF Interchange.

ER_Roundabout – Corresponds to a GDF roundabout. This mechanism can be used when the roundabout is not represented as just a simple road node.

ER_AggregatedWay – Corresponds to a GDF aggregated way.


MustHaveLowerLevel This type of roadnet element must have at least one lower level element.

OCL:


mapsToAtLowerLevel->size() > 0

CorrectMapping If formOfComplexElement is ER_Interchange, ER_Roundabout or ER_AggregatedWay then the lower level elements must be road links or road nodes of types ER_RoadElement or ER_Junction. This is to conform to the GDF specification.

OCL:

formOfComplexElement = ER_Interchange or ER_Roundabout or ER_AggregatedWay implies

mapsToAtLowerLevel->forAll(m : ER_DetailLevelMapping | (m.lowerLevelElement.oclIsTypeOf(ER_RoadNode) and m.lowerLevelElement.oclAsType(ER_RoadNode).level = ER_Junction) or m.lowerLevelElement.oclIsTypeOf(ER_RoadLink) and m.lowerLevelElement.oclAsType(ER_RoadLink).level = ER_RoadElement))

6.4.3 Geometric representation option This option use geometric representation of the road network. The simplest form of a road network consists only of road links, each with a geometric representation. Road nodes are not required in this case. The only use for nodes is if there is information associated with the node. If road nodes occur, they may only occur at the position where road links begin or end.

A road element is required to have a geometric realization.

OCL: ER_RoadNode: point->size() = 1 and node->size() = 0 ER_RoadLink: curve->size() = 1 and edge->size() = 0


«Abstract»ER_RoadElement

ER_RoadLinkER_RoadNode

Geometry::GM_Point

0..1

+point0..1

Geometry::GM_Curve

0..1

+curve0..1

Figure 6-18 - Geometric representation option

6.4.4 Topological representation option This option use explicit topological representation of the road network. In this option a road link is represented by a ER_Edge and a road node is represented by a ER_Node. The network can be planar or non-planar.

A road element is required to have a topological realization.

OCL:

ER_RoadNode:

point->size() = 0 and node->size() = 1

ER_RoadLink:

curve->size() = 0 and edge->size() = 1

ISO 19107 does not require topological objects to have a geometric realization. In EuroRoadS however it is required.

OCL:

ER_RoadNode:

node.geometry->size() = 1

ER_RoadLink:

edge.geometry->size() = 1


Figure 6-19 - Topological representation option

6.4.5 Optional constructs

6.4.5.1 ER_DetailLevelMapping This is a mechanism whereby network elements at one level of detail can be mapped or aggregated to network elements at another level of detail. For example can a road node at one level be mapped to several road nodes and road links at another level. This is the available mechanism for defining elements that correspond to GDF complex features. The way this mapping is done is defined in chapter 7.


validity An optional attribute specifying the time period during which the detail level mapping is valid in the real world. If not specified the validity is unknown.


upperLevelElement Association to the net element on the upper (less detailed) level

lowerLevelElement Association to the net element on the lower (more detailed) level



NotSameElement It is not allowed to map an element to itself

OCL:

upperLevelElement <> lowerLevelElement

DIsAllowedUpperLevel The following types of roadnet elements are NOT allowed to play the role of being upperLevelElements in an aggregation:

- ER_RoadLink with level = ER_RoadElement

- ER_FerryLink with level = ER_FerryConnection

- ER_RoadNode with level = ER_Junction

OCL:

upperLevelElement.oclIsTypeOf(ER_RoadLink) implies

upperLevelElement.oclAsType(ER_RoadLink).level <> ER_RoadElement

upperLevelElement.oclIsTypeOf(ER_FerryLink) implies

upperLevelElement.oclAsType(ER_FerryLink).level <> ER_FerryConnection

upperLevelElement.oclIsTypeOf(ER_RoadNode) implies

upperLevelElement.oclAsType(ER_RoadNode).level <> ER_Junction

DisAllowedLowerLevel The following types of roadnet elements are NOT allowed to play the role of being lowerLevelElements in an aggregation:

- ER_RoadLink with level = ER_Road

- ER_FerryLink with level = ER_Ferry

- ER_RoadNode with level = ER_Intersection

- Any ER_ComplexRoadnetElement

OCL:

lowerLevelElement.oclIsTypeOf(ER_RoadLink) implies

lowerLevelElement.oclAsType(ER_RoadLink).level <> ER_Road

lowerLevelElement.oclIsTypeOf(ER_RoadNode) implies


lowerLevelElement.oclAsType(ER_RoadNode).level <> ER_Intersection

not lowerLevelElement.oclIsTypeOf(ER_ComplexRoadnetElement)

A specification on how to use ER_DetailLevelMapping when mapping with GDF concepts, is described in chapter 7.

«Abstract»ER_RoadElement +validity[0..1] : TM_Period

ER_DetailLevelMapping

+lowerLevelElement1+mapsToAtUpperLevel 0..*

+upperLevelElement 1 +mapsToLowerAtLevel0..*

+id[1] : ER_ObjectId


Figure 6-20 - Detail level mapping


6.4.5.2 ER_Route A route is kind of road feature which represents a continuous path in the network without any branches. The route has a defined beginning and end and every position on the route is identifiable with one single parameter such as length. A route is especially suitable for defining stable linear referencing entities as shown in the figure below.

The positive direction of an ER_Route starts at the beginning of the first routeLink (considering routeLink.direction) and ends at the end of the last routeLink.

ER_RoadLink, id = 1

ER_Route, id = 1

ER_RoadLink, id = 3

ER_Route, id = 1

Editing

ER_RoadLink, id = 2

Speed limit = 70 km/h, linear element = 1Start measure = 25, end measure = 70

N1 N2

N1 N2

N3

Figure 6-21 - ER_Route example

The figure above demonstrates the evolution of a route through an editing process. Initially there is one road link and one route (i.e. a 1:1 relationship). After the editing operation the road link is replaced by two new road links. If road links were used as basis for linear referencing, the speed limit would become invalid after the editing and would have to be recalculated. This would be manageable if the same system is responsible for maintaining both the network and the speed limits. But if the network and the speed limits are separated and maintained by different content providers there could be a problem. If instead the network route is used as the basis for linear referencing, the network reference is still valid as the linear referencing element (the route) is maintained together with the network and is unchanged from an external linear referencing viewpoint. So in the figure above the route remains unchanged so the speed limit continues to be valid; but the internal construction of the route has changed and is now represented by two road links instead of the former one.

A route could be viewed as a functional entity which remains unchanged when the underlying network representation changes. Examples of routes could be:


- The road section between point A and B (perhaps with a single road name or road number)

- A continuous road section with a defined start and end, opened for traffic at a certain time. Remains constant even if road network history is being used.

- Another existing linear referencing entity already used for managing linear measures along roads.


routeLinks A sequence of ER_RouteLink where each refer to an ER_LinkBase. The route links shall be shall be ordered in such a way that the network path forms a continuous linear feature with a defined start and end and no branches.


NoDuplicates No link is allowed to occur more than once for a single route.

OCL:

routeLinks->forall(r : ER_RouteLink | routeLinks->select(link = r.link)->size() = 1)

RouteOnOneLevel A route is allowed to contain links of the same level.

OCL:

routeLinks->exists(r : ER_RouteLink | r.link.oclAsType(ER_RoadLink).level = ER_RoadElement or r.link.oclAsType(ER_FerryLink).level = ER_FerryConnection) implies

routeLinks->forAll(r : ER_RouteLink | r.link.oclAsType(ER_RoadLink).level = ER_RoadElement or r.link.oclAsType(ER_FerryLink).level = ER_FerryConnection)

routeLinks->exists(r : ER_RouteLink | r.link.oclAsType(ER_RoadLink).level = ER_Road or r.link.oclAsType(ER_FerryLink).level = ER_Ferry) implies

routeLinks->forAll(r : ER_RouteLink | r.link.oclAsType(ER_RoadLink).level = ER_Road or r.link.oclAsType(ER_FerryLink).level = ER_Ferry)


ER_Route

+validity[0..1] : TM_Period+direction[1] : Sign

ER_RouteLink +routeLinks

1..*{ordered}

+route 1



+validity[0..1] : TM_Period

«Abstract»ER_RoadnetLink

+link1

+routes

0..*


Figure 6-22 - ER_Route

6.4.5.3 ER_RouteLink The only use for this class is to connect network routes with its road links.


Validity An optional attribute specifying the time period during which the route link exists in the real world. If not specified the validity is unknown.

direction A sign which direction to use the road link in the context of the network route. See figure below.


link A road link which is a member of the network route

route The route.


RL1

RL2

RL3

RL4

RL5

N1

N2

N3 N4

N5

N6

Figure 6-23 - ER_RouteLink example

In the figure above there are five road links. The forward direction of each link is shown with a black arrow next to the road link. There are two routes, shown by the red (starting at N1 and ending at N6) and the blue (starting at N5 and ending at N2) lines. To represent these routes, the following route links are needed:

route (ER_Route) roadLink (ER_RoadLink) direction

Dashed red RL1 ‘+’



Dotted blue RL4 ‘+’

Dotted blue RL3 ‘-‘

Dotted blue RL2 ‘+’


6.5 Network referencing

6.5.1 Introduction The Network referencing package in the EuroRoadS supplies classes and types used to attach features and attributes, other than those specified directly for the classes in the road network package, to the road network. The idea is to separate the road network topology and/or geometry from the data describing the network. The network referencing package serves as a harmonized definition on various ways of positioning data on the road network. The ways of relating to the network are the following:

- As a 0 dimensional position somewhere along a linear network element

- As a 0 dimensional position in a node

- As a 1 dimensional segment which is a part of a (can be the whole) linear network element

- As something related to a turn or manoeuvre. Observe that the network topology itself defines all the theoretically possible turns. The mechanism in this package defines a harmonized way of referring to a specific turn or manoeuvre for example when defining a turn restriction.

This way the network itself is viewed as some kind of a spatial reference system to which data can be located.

6.5.2 Linear elements 6.5.2.1 Overview

The class “LR_Element” describes the underlying curvilinear elements upon which the measures in the linear reference system are taken. In the EuroRoadS model the linear elements are either network paths (ER_Route) or road links (ER_RoadLink). Though not linear, there is also a mechanism whereby road nodes (ER_RoadNode) can be referenced. A description of ER_Route, ER_RoadLink and ER_RoadNode can be found in chapter 6.4.

Figure 6-24 - Linear reference system


6.5.2.2 ER_LRElement

The class ER_LRElement represents an element in a linear reference system that can be used for linear references. In EuroRoadS roadnet links or routes can be used. The class is stereotypes as a union which means that either route or link can be used in any given instance.


link An optional reference to a roadnet link

route An optional reference to a network route

6.5.3 Location Expressions 6.5.3.1 Overview

There is a need for definition of different types of locations in the reference system. The locations are used to position attributes or other features relative to the reference system (or road network). In the model we defines different types of location expressions which includes a method, an element reference and a measure value in combination with an optional reference marker and an optional offset expression.

In ISO19133 there is a type called LR_PositionExpression that can be used to describe a point-location along an LR_Element. To fulfil the requirements of EuroRoadS we have also added other kinds of location expressions in this package. Examples of other expressions are references to nodes and the definition of turns and manoeuvres.

Note that the location expressions only define the mechanisms to be used for locating positions in the linear reference system not the actual data such as attributes and/or objects.


+above+below+on

«CodeList»ER_HeightPosition

+route : ER_Route+link : ER_RoadLink

«union»ER_LRElement

+left+right+middle+crossing

«CodeList»ER_LateralPosition

+position : LR_PositionExpression+node : ER_NodeExpression

«union»ER_PointExpression+direction[0..1] : Sign

+lateralPosition[0..1] : ER_LateralPosition+heightPosition[0..1] : ER_HeightPosition+verticalOffset[0..1] : Measure

ER_PositionExpression+direction[0..1] : Sign+lateralPosition[0..1] : ER_LateralPosition+heightPosition[0..1] : ER_HeightPosition+verticalOffset[0..1] : Measure

ER_SegmentExpression

1

+fromPos1

1

+toPos

1

ISO 19133 Profile::LR_PositionExpression

ISO 19133 Profile::LR_Element

+referenceDomain

0..1

ISO 19133 Profile::LR_OffsetExpression

+offset

0..1

ISO 19133 Profile::LR_ReferenceMarker

+element1

0..*+referent0..1

+heightPosition[0..1] : ER_HeightPosition+verticalOffset[0..1] : Measure

ER_NodeExpression

Network::ER_RoadNode

0..*

+node1

ISO 19133 Profile::LR_LinearReferenceMethod

+LRM

1

Figure 6-25 - Location expressions

6.5.3.2 ER_PositionExpression

The class ER_PositionExpression represents a position (0-dimensional) on a linear element in the EuroRoadS model. It extends the class LR_PositionExpression with the possibility to specify a direction, a lateral position, a height position and/or a vertical offset.


direction A ‘+’ means the same direction and a ‘-‘ means the opposite in the context of the referenced linear element. A direction can be used to locate something for which the direction along the linear element is important. An example of usage for this class is the location for a traffic-sign that is valid for the traffic in a specific direction. This is an optional attribute and if left out means that the expression is direction


independent.

lateralPosition An optional attribute that specifies a lateral position without knowing the exact offset. An example of usage is to specify left or right side for a traffic-sign.

heightPosition An optional attribute that specifies a height position without knowing the exact offset.

verticalOffset An optional attribute that specifies a vertical offset from the element

The code list “ER_HeightPosition” enumerates the height position types used. The initial value domain included:

• above • below • on

The code list “ER_LateralPosition” enumerates the lateral position types used. The initial value domain included:

• left • right • middle • crossing


6.5.3.3 ER_SegmentExpression

The class ER_SegmentExpression represents a 1-dimensional part of a linear element defined by a from- and to-position. Both from and to postion should be references to the same linear element. An example of usage for this class is the location for a road-width attribute.


direction A ‘+’ means the same direction and a ‘-‘ means the opposite in the context of the referenced linear element. A direction can be used to locate something for which the direction along the linear element is important. An example of usage for this class is the location for a speed-limit that is valid for the traffic in a specific direction. This is an optional attribute and if left out means that the expression is direction independent.

lateralPosition An optional attribute that specifies a a lateral position without knowing the exact offset. An example of usage is to specify left or right side for a fence.


verticalOffset An optional attribute that specifies a vertical offset from the element.


fromPos The position specifying the beginning of the segment.

endPos The position specifying the end of the segment.

referenceDomain The linear element.

LRM The linear reference method.


sameElement -- must be same LR_Element used for fromPos and toPos

-- A OCL – expression to be written …

positiveLength --fromPos is always located before toPos according to the direction of the referenced linear element.

-- A OCL – expression to be written …


SE1 : ER_SegmentExpression

RelativeLength=0,8

LP1 : ER_LRElement

RL1 : ER_RoadLink

link

RelativeLength=0,5

P1 : LR_PositionExpressionmeasure : 0,5

P2 : LR_PositionExpressionmeasure : 0,8

fromPos toPos

referenceDomain

LRM1 : LR_LinearReferenceMethodname : RelativeLengthSegment

LRM

Figure 6-26 - An example of a simple segment expression


6.5.3.4 ER_NodeExpression

The class ER_NodeExpression represents a location in the reference system defined by a node. There is no linear reference method (LRM) association for ER_NodeExpression.


Node The reference to a node


verticalOffset An optional attribute that specifies a vertical offset from the node.

6.5.3.5 ER_PointExpression

The class ER_PointExpression represents a point location in the reference system defined by a node expression or a position expression. An example of usage for this class is the location for an accident which can occur on a point on a linear reference element or in a node.


Position A position expression

Node A node

6.5.3.6 ER_TurnExpression and ER_ManoeuvreExpression

The class ER_TurnExpression represents a mechanism for traversing the network in a node. Each turn will be located at a node and will have specific from element for entering the node and a specific to element for leaving the node. There is no linear reference method (LRM) association for ER_TurnExpression. An example of usage for this class is the location for a turn restriction.


Figure 6-27 - Turn and manoeuvre expressions


fromDirection An optional attribute specifying the turn direction relative to the positive direction of the fromElement. The attribute is required if the ER_LRElement refers to an ER_Route.

toDirection An optional attribute specifying the turn direction relative to the positive direction of the toElement. The attribute is required if the ER_LRElement refers to an ER_Route.

Association Definition

Node The node for the turn

fromElement The element for entering the node

toElement The element for leaving the node


RN1 : ER_RoadNode

TE1 : ER_TurnExpression

node

toElement

fromElement

Figure 6-28 - An example of a turn expression


RN1 : ER_RoadNode


nodetoElement

fromElement

Route 1

Route 2

fromDirection = ”-”toDirection = ”+”

Figure 6-29 - An example of a turn expression using routes and directions


The class ER_ ManoeuvreExpression is used to describe manoeuvres. A manoeuvre is a sequence of turns, each of which terminates on the element that is the start of the next turn. Most manoeuvres are single turns. There is no linear reference method (LRM) association for ER_ ManoeuvreExpression. An example of usage for this class is the location for a manoeuvre restriction.

Association Definition

turns The sequence of turns



turns[0]

ME1 : ER_ManoeuvreExpression

turns[1]

Figure 6-30 - An example of a manoeuvre expression

6.6 Attributes and features related to the road network.

6.6.1 Introduction The heading to this section uses the terms attributes and features. Normally, when we use the term attribute, we refer to a characterizing property of an object. Feature is a term used in the geographical information domain used for an independent class or object which has a position relative to the earth. In EuroRoadS, these concepts have the same meaning with the exception


that attributes are also allowed to be modelled as features since that offer compatibility with existing solutions that use linear referencing mechanisms for the attachment of attributes to the road network. Sometimes this is referred to as “events”. In EuroRoads the are two optional mechanisms for attribute handling in the model

The first optional mechanism for attributes is suitable for existing solutions where statically segmented road segments carry a number of attributes (e.g. a road segment table with a number of attribute columns). In the network package it is stated that an object of class ER_RoadnetElement carries a collection of road attributes thru the relationship with class ER_RoadAttribute. This is a way of adding flexibility to the model since subclasses of ER_RoadAttribute can be added without affecting the existing model. Any piece of information that can be used to characterize an element in the road network is modelled as a class derived from ER_RoadAttribute and therefore attachable to elements in the road network. OCL rules can be used to define restrictions on the usage of the attribute. Examples of such restructions are “can only be attached to instances of ER_RoadNode with level = ER_Junction” or “can only be attached to instances of ER_RoadLink with nationalRoadClass = ER_MainRoad”. Examples of a class derived from ER_RoadAttribute can be “Speed limit” or “Road width”.

The second optional mechanism is to describe attributes as features. In this scenario a class is derived from ER_RoadFeature (thus having a permanent identifier) which is given one or more attributes of types defined in the “Network referencing” package, for example an attribute of type ER_SegmentExpression defining the ability to specify the position for the feature. A class derived from ER_RoadAttribute as described above can be used to define the thematic attribute part of the feature (for example “Speed limit”). This feature has an identity (and is therefore separately identifiable and possible to update separately), a geographic position relative to the network thru the segment expression and thematic attributes defined by the attribute class. This is a mechanism for attributes that is suitable for existing solutions where attributes does not affect the segmentation of the basic network. The mechanism is often referred to as “Events” in various GIS-solutions. Observe that it is also possible to define additional spatial, temporal or other attributes as long as classes of the EuroRoadS profiles of the ISO 19100 standards are used. It is therefore possible to, as an example, define a feature that has both an attribute of type ER_SegmentExpression which defines a position relative to the network and another attribute of type GM_Surface which defines a geographic position and shape for the same feature.

It is important to understand that the two mechanisms described above do not imply any difference in semantics. The same real world situation can be equally represented using any of the options. There are however differences in implementation and each option has its advantages and disadvantages.

The ER_RoadFeature option MUST be used when a certain attribute involve several elements in the network. One such example is a turn restriction where incoming and outgoing road elements must be specified as well as road node (i.e. an ER_TurnExpression).

The ER_RoadFeature option is very suitable to represent things that are objects of their own right for which identity is central.

Where possible, attributes in EuroRoadS shall be modelled using both mechanisms to enable existing solutions of both types to easily map their data to EuroRoadS.

The attributes and features in EuroRoadS are subdivided into four types:


1. Mandatory attributes. These are the attributes defined in the classes in the network package. These attributes have to be specified when publishing a road dataset according to EuroRoadS. Since these attributes are defined statically as attributes for the network classes they are statically referable for example when defining OCL rules. Observe that the road network elements have to be statically segmented based on these attributes since only one value can occur for the entire element.

2. Conditional attributes and features. Predefined attributes and road related features that have to be supplied under certain conditions. These attributes and features are modelled as UML classes separated from the network package. Examples on conditions can be:

• When phenomenon exists in the real world

• For all main roads (i.e. when nationalRoadClass = ER_MainRoad) 3. Optional attributes and features. Predefined attributes and road related features that

are not mandatory, but if data of these types is transmitted, the EuroRoadS definitions shall be used. These attributes and features are modelled as UML classes separated from the network package.

4. User defined attributes and features. These are attributes and features are not defined within EuroRoadS. There may still be a need for publishing them. This draft suggests a way to handle these kinds of attributes and features in chapter 6.6.6.

For attributes of the latter three types above the two methods described above can be used:

1. Attaching the attributes directly through the attributes relationship in the ER_RoadnetElement class. In this case the attributes need no identity of their own (the road element has an id). This method is suitable for those who typically store their road elements in a relational table where the attributes are stored in columns without any separate identity.

2. Encapsulating the attributes in separate features and attaching them to the road network by using network referencing methods according to the ISO 19133 profile together with the EuroRoadS Network referencing package. When using this method the attributes are treated as objects with their own identity independent of the road element. This method shall also be used for features that have a logical relationship with the road network.

Attributes and features that relate to more than one road element (e.g. a turn restriction) must use the second method and relate the data through the mechanism in the ISO 19133 profile.

6.6.2 Attribute base package This package defines the basic structure for attributes and road related features. It defines a couple of abstract classes that must be inherited by concrete attribute and feature classes.


Figure 6-31 - ER_RoadAttribute

A concrete attribute shall be inherited from any of the classes ER_RoadNodeAttribute, ER_LinkAttribute, ER_RoadLinkAttribute, ER_FerryLinkAttribute, ER_RoadnetElementAttribute or ER_RoadnetElementAttribute depending on which type of road net element the attribute can be attached to. OCL rules in the classes in the network package allows and prohibits certain combinations. Observe that additional rules may be defined on specific concrete attribute classes. An example of an OCL rule for a class derived from ER_RoadLinkAttribute could be roadnetElement.oclAsType(ER_RoadLink).nationalRoadClass = ER_MainRoad. This asserts that instances of this class can only be attached to main roads.

It is possible to define classes that encapsulate one or more attributes and that use linear referencing mechanisms. Instances of that class are handled as separately identifiable objects and must therefore be derived from ER_RoadFeature.

The reason for defining the model this way is primarily to allow for flexibility in the way attributes and road related features are defined. It shall be possible to add new attributes and features without breaking the existing model when new requirements arise.

6.6.2.1 ER_RoadAttribute An abstract base-class that shall never be inherited from a concrete attribute class.


validity An optional attribute specifying the time period during which the attribute is valid. If not specified the validity is unknown.


6.6.2.2 ER_RoadNodeAttribute An abstract base-class for attributes that are valid for instances of class ER_RoadNode.


validType An attribute of this type can only be connected to an instance of a ER_RoadNode.

OCL:

roadnetElement.oclIsKindOf(ER_RoadNode)

Note: A subtype of ER_RoadNodeAttribute could refine the constraint to for example certain attribute values of the ER_RoadNode or the occurrence of other kinds of attributes.

Example:

roadnetElement.oclAsType(ER_RoadNode).nodeType = ER_Junction

roadnetElement.attributes->select(a | a.oclIsKindOf(xxx))->notEmpty()

6.6.2.3 ER_LinkAttribute An abstract base-class for attributes that are valid for instances of all classes derived from ER_RoadnetLink (ER_RoadLink or ER_FerryLink).


validType An attribute of this type can only be connected to an instance of a ER_RoadnetLink.

OCL:

roadnetElement.oclIsKindOf(ER_RoadnetLink)

6.6.2.4 ER_RoadLinkAttribute An abstract base-class for attributes that are valid for instances of class ER_RoadLink.


validType An attribute of this type can only be connected to an instance of a ER_RoadLink.

OCL:

roadnetElement.oclIsKindOf(ER_RoadLink)

Note: A subtype of ER_RoadLinkAttribute could refine the constraint to for example certain attribute values of the ER_RoadLink or the occurrence of other attributes.


Example:

roadnetElement.oclAsType(ER_RoadLink).linkType = ER_RoadElement


6.6.2.5 ER_FerryLinkAttribute An abstract base-class for attributes that are valid for instances of class ER_FerryLink.


validType An attribute of this type can only be connected to an instance of a ER_FerryLink.

OCL:

roadnetElement.oclIsKindOf(ER_FerryLink)

Note: A subtype of ER_FerryLinkAttribute could refine the constraint to for example certain attribute values of the ER_FerryLink or the occurrence of other attributes.

Example:

roadnetElement.oclAsType(ER_FerryLink).ferryType = ER_FerryConnection


6.6.2.6 ER_RoadnetElementAttribute An abstract base-class for attributes that are valid for instances of all classes derived from ER_RoadnetElement.

6.6.2.7 ER_ComplexRoadnetElementAttribute An abstract base-class for attributes that are valid for instances of all classes derived from ER_ComplexRoadnetElement.


validType An attribute of this type can only be connected to an instance of a ER_ComplexRoadnetElement.

OCL:

roadnetElement.oclIsKindOf(ER_ComplexRoadnetElement)

6.6.3 Conditional and optional attributes and features (Example) In this final draft version of the EuroRoadS model, the optional attributes and road related features have not been defined. The definitions below have been created to illustrate the


mechanisms and how attributes can be defined once and still allow both ways of attachment to the road network. This section will, in the final version of the document, define the conditional and optional attributes and road related features in EuroRoadS. The conditional and optional attributes and features are not always required in a EuroRoadS dataset but as concepts they are mandatory. This means that whenever they are used in a EuroRoadS context, the EuroRoadS definition is mandatory.

This version of the document only defines a couple of example packages to give a general understanding of the principle.

The previous work within EuroRoadS has recognized a couple of different application areas which are of particular interest. When attributes differ between the various application areas, they should preferably be modelled in separate UML packages. Since the sets of attributes in various application packages can intersect, there is probably a need for a hierarchical package structure where different application specific packages can share some definitions. One possibility for EuroRoadS would be to use the package structure in such a way that mechanisms are created whereby a content provider can claim conformance for certain application packages and must therefore support all the definitions for those packages as a whole.

In the figure below a couple of packages are shown and their dependencies with the rest of the EuroRoadS application schema.

Figure 6-32 - Example of attribute packages

The way attributes are modelled is shown in the figure below. For every attribute a separate class is defined which is a subclass of one of the attribute classes defined in the Attribute base package.


In the figure below the example classes are:

• ER_SpeedLimit. A class derived from ER_RoadLinkAttribute that is used to define the speed limit for a road link.

• ER_RoadWidth. A class derived from ER_RoadLinkAttribute that is used to define the width for a road link.

To enable the same attributes to be attached also thru linear referencing, the corresponding classes are derived from ER_RoadFeature. In the example below, these classes are:

• ER_SpeedLimitFeature and ER_SpeedLimitVersion for a separately identified speed limit feature which is attached to the road network thru linear referencing.

• ER_RoadWidthFeature and ER_RoadWidthVersion for a separately identified road width feature which is attached to the road network thru linear referencing.

The classes ER_TurnRestrictionFeature and ER_TurnRestrictionVersion are modelled only using linear referencing since several road elements are involved.

The reason for modelling some classes with a *Feature and *Version class is to allow for the representation of the real world change history for the object. One object can have changed over time and every version records the state for that object during a certain time period.


Figure 6-33 - Example road attributes and road features

6.6.4 Attaching attributes directly to the road network Instances of classes derived from the classes ER_RoadNodeAttribute, ER_LinkAttribute, ER_RoadLinkAttribute, ER_FerryLinkAttribute or ER_RoadnetElementAttribute are possible to attach to road elements using the ER_RoadnetElement.attributes association. The figure below shows a schematic figure on how attributes are attached to road elements.


ER_RoadLinkId = 1Attributes={SpeedLimit=50,RoadWidth=13}

ER_RoadLinkId = 2Attributes={SpeedLimit=70,RoadWidth=13}

ER_RoadLinkId = 3Attributes={SpeedLimit=70,RoadWidth=7,5}

Figure 6-34 - Example of road links with attached road attributes

The above figure could be represented the following way using an imaginary xml-like syntax for the defined EuroRoadS concepts: <ER_RoadLink permanentId=”1”>

<edge>…</edge>

<linkType>…</linkType>

<nationalRoadClass>…</nationalRoadClass>

<qualityClass>…</qualityClass>

<attributes>

<ER_SpeedLimit speed=50/>

<ER_RoadWidth width=13/>

</attributes>

</ER_RoadLink>

<ER_RoadLink permanentId=”2”>

<edge>…</edge>




<attributes>

<ER_SpeedLimit speed=70/>

<ER_RoadWidth width=13/>

</attributes>


</ER_RoadLink>

And so on…

It is important to understand that:

• The attributes have no identity of their own. They are identified thru their class and the identity of the road element.

• The road elements must be homogeneous, i.e. the same value is valid for the entire road element. It could be possible to allow for link attributes to specify measures analogously to the linear referencing mechanisms. In this draft however, it is decided to not allow that to keep the model simpler.

6.6.5 Attaching road related features using network referencing When features are attached to the road network using linear referencing, the feature is required to have an identity independently of the road net element and each other. The identity is a unique identity of the feature and not a combination or generation of the values that the feature might have.

The basic principle is to treat the road net element and the feature as separate entities and also keep the road network “unaware” of the attached features. See figure below:

RoadElementId = 1

SpeedLimitFeatureId = 333Speed limit = 50From=0, To=0,25

SpeedLimitFeatureId = 444Speed limit = 70From=0,25, To=1

RoadWidthfeatureId = 111Width = 13From=0, To=0,75

RoadWidthFeatureId = 222Width = 7,5From=0,75, To=1

Figure 6-35 - Example of road features attached thru use of linear referencing


The above figure could be represented the following way using an imaginary xml-like syntax for the defined EuroRoadS concepts: <ER_RoadLink permanentId=”1”>

<edge>…</edge>




</ER_RoadLink>

<ER_SpeedLimitObj permanentId=”333”>

<versions>

<ER_SpeedLimitVersion>

<location>

<ER_SegmentExpression>

<LRM>…</LRM>

<referenceDomain>

<ER_LRElement><link uuidref=”1”/></ER_LRElement>

</referenceDomain>

<fromPos>

<ER_LRPosition><measure>0</measure><ER_LRPosition>

</fromPos>

<toPos>

<ER_LRPosition><measure>0,25</measure><ER_LRPosition>

</toPos>

</ER_SegmentExpression>

</location>

<speed>

<ER_SpeedLimit speed = 50/>

</speed>

</ER_SpeedLimitVersion>

</versions>

<ER_SpeedLimitObj>

<ER_RoadWidthObj permanentId=”111”>

…and so on…

</ER_RoadWidthObj>

In this case it is important to understand that:

• Every attribute have identity of its own, independently of the road element to which they are attached.


• The road elements do not need to be homogeneous. For example it is possible for a speed limit or a road width to vary along a road link.

6.6.6 User defined attributes and features For situations when content providers have data which is not covered by any of the predefined attributes within the EuroRoadS specification a solution must be developed to extend the EuroRoadS model in a controlled fashion. Two ways of doing this have been discussed:

1. Attributes and features are defined the same way as the optional attributes and features in this document, i.e. they are defined as classes derived from any of the base classes defined here.

2. A type independent schema is developed, which can be used as basis for transfer of both user defined types and instances of those types.

6.6.6.1 User defined attributes and features defined the same way as predefined optional attributes and features

This solution has the advantage that no extra schema has to be developed to enable definition of such types. The disadvantage is that a separate mechanism to publish the schemas (both application schemas and data transfer schemas) must be developed. Somehow metadata must exist and be published so that a data user is made aware of:

• That the types exist

• The definition and the semantic meaning of the types

• Rules on how and when to use the types.

There must also be standardized rules on how the UML class definitions are transferred to the transfer schema. The suggested data transfer scheme for EuroRoadS is GML which contains such rules. A metadata schema must be developed in which the various user defined types can be defined and published. In this case a schema based on ISO 19110 – Feature Cataloguing methodology shall be used.


The figure below shows how a user defined attribute could be defined.

Figure 6-36 - Example of a user defined road attribute and road feature

6.6.6.2 User defined attributes using a type independent schema approach

An approach like this uses (much like GDF) a scheme where very generic features and attributes (types and instances) are modelled to create a generic and type independent schema. Using this schema, types of data can be defined dynamically, because new types are just new instances of the very generic type classes. The requirements on semantics are not less when defining these types than for the predefined types defined in the EuroRoadS schema. A type independent schema therefore has to be quite extensive. The proposal for a Swedish type independent feature model standard SS 637006 fulfils the requirements that are valid also for EuroRoadS. This standard proposal is based on ISO 19110 - Feature Cataloguing methodology. The specification has to be profiled for EuroRoadS in order to allow the generic features to be added as attributes to EuroRoadS road elements. It must also be possible to use


the EuroRoadS linear referencing mechanism from the generic features. The advantage of this approach is that the schema for user defined types can be distributed once together with the rest of the EuroRoadS application schema. The user defined types are just different instances of the same application schema type. The disadvantage is primarily that the type independent schema is quite extensive and not easy to adapt.

6.6.6.3 Solution for EuroRoadS EuroRoadS shall use the approach where user defined attributes and features are defined the same way as the predefined optional ones. The details on how to publish the type definitions (both predefined and user defined) will have to be developed as a part of the EuroRoadS metadata schema. There also has to be mechanisms where the user defined extensions can easily be added to the EuroRoadS transfer schemas. The reason for this decision is that it seems easier to use one mechanism regardless of who defines the various types. It remains to be seen if there is an easy way to define and publish the necessary definitions to those who need them. The type independent approach is an approach which has been proven to work for practical use and is possible to use if the proposed way proves to be impossible or unpractical.

6.7 Edge matching at borders This subject is explicitly pointed out for the EuroRoadS project to handle. The reason for this issue is that every road database has a finite extent and there may be another neighbouring road database that is more or less connected. On a European level it is vital that it is possible to connect the data from different databases smoothly. To the authors of this document there are no “silver bullets” that automatically solves the problem. The problem can be handled at a couple of different levels:

• Organisation and information. Different content providers can agree on digital representations of borders and position common road nodes at the borderline. If this is the case, content providers are able to provide enough information so data can be properly connected. The EuroBoundaries project is an example of such an initiative. The authors of this document are not fully aware of the current status of EuroBoundaries, but the project should be mentioned in this context.

• Procedures and algorithms. Information systems or information system users can try to match different networks and perform the necessary editing to match data from different sources.

6.7.1 EuroBoundaries The EuroBoundaries project has just been launched by EuroGeographics. Its rationale is the following:

“The EuroBoundaries project offers a solution to the issues related to cross border geometric and topologic integration by aiming at providing a net of agreed lines and points, to which individual dataset can be plugged in, in order to create a seamless whole.

Therefore the main project’s objective is to create a ‘EuroBoundaries’ dataset, the Definitive European National Boundaries, on the base of a common data model and a data network in Europe. This would cover at least the


EU, ideally the whole European continent (40+ countries). The EuroBoundaries dataset should represent the boundaries, either on sea, on land or on shore.

The EuroBoundaries data (EBD) would be of the highest available accuracy, the target being an accuracy of 1 meter or better. However, resolution requirements must be flexible in terms of accuracy, in order to be consistent with actual data availability. Completeness, coverage, and date of release are important criteria. Thus the construction of the ‘EuroBoundaries’ DB will be incremental, as the first version will start with available data, and be improved by upgrading the original accuracy, and adding topographic nodes.

The boundary data model (EBDM) shall include the boundary marks, the boundary line and topographic features associated with or intersecting the boundary. Each point or segment would be attributed (‘metadata’), in terms of providing information about the source of the data, the estimated accuracy, the time-stamp, a unique identifier, status (disputed, jointly defined, …), reliability …,. All features and objects will be given ETRS89 co-ordinates. The EBDM will represent the minimum requirement that each country has to achieve; they will be free to extend this EBDM for their own requirements.”

The mention of topographic features above shows the possible technical use of EuroBoundaries by EuroRoads.

The organisational connection between the two projects can be made by BEV, IGNF and Lantmäteriet which participate in both projects.

6.7.2 Border nodes package The EuroRoadS application schema defines a package with classes that can be attached to border nodes to support edge matching at national borders according to the first case (organisation and information) above. The second case (procedures and algorithms) is not supported in any way in the EuroRoadS application schema.

+borderNodeType[1] : ER_BorderNodeType+areaCode[1] : CharacterString+neighbourAreaCode[0..1] : CharacterString+neighbourId[0..1] : ER_ObjectId

ER_BorderNodeInfo

«Abstract»Attribute base::ER_RoadNodeAttribute

+ER_NationalBorderNodeType+ER_AdministrativeAreaBorderNodeType

«enumeration»ER_BorderNodeType

+info[1] : ER_BorderNodeInfo+location[1] : ER_NodeExpression

ER_BorderNodeInfoFeature


Figure 6-37 - Border node info

6.7.3 ER_BorderNodeInfo The class defines a couple of attributes that can be attached to nodes at borders using the ordinary mechanism to attach attributes to road elements.

The occurrence of this attribute indicates that the node exists because a road crosses a border.



borderNodeType Identifies the kind of border that is the reason for the road node:

• ER_NationalBorderNodeType. The road node is positioned on a national border.

• ER_AdministrativeAreaBorderNodeType. The road node is positioned on an administrative area border other than a national border, when the edge of the dataset is not a national border.

areaCode A code that identifies the area to which the road node belongs. If the border is a national border, the code shall be a country code according to ISO 3166.

neighbourAreaCode An optional code that, if known, identifies the neighbouring area. If the border is a national border, the code shall be a country code according to ISO 3166.

neighbourId An optional identity that, if known, specifies the id assigned to the road node in the neighbouring area.

6.7.4 ER_BorderNodeInfoFeature The class defines a feature version of the border node info class.


info The border node information.

location A node expression that specifies the location for the border node info.


6.7.4.1 Example

NOR SWE

Road node Id=”123”Attributes={ER_BorderNodeInfo(ER_NationalBorderNodeType,”NOR”,”SWE”,”abc”)}

Road node Id=”abc”Attributes={ER_BorderNodeInfo(ER_NationalBorderNodeType,”SWE”,”NOR”,”123”)}

Figure 6-38 - Border nodes example

In the example above, there exist two road nodes, one in Norway (id=”123”) and one in Sweden (id=”abc”), which represents the point where the road crosses the national border. Sweden and Norway have information about each others nodes and can therefore publish that information.

6.8 Grade separated crossings Since the network model allows for planar topology and there can theoretically exist errors in z (z may also be missing), the EuroRoadS schema defines a couple of constructs to represent grade separations very much influenced by the way this is handled in GDF. There are three ways to handle grade separations:

- The first and most obvious way is that no extra information is needed at all, i.e. the grade separations are handled thru interpretations of geometry with correct z-values.

- The second way is by attaching a level attribute (defined below) on the involved road links. This corresponds to the edge levels in GDF.

- The third way is by the definition of a road related feature which connects to an upper and a lower road element. This corresponds to the Grade separated crossing relation in GDF.

Definitions for representing the two latter cases are defined in the grade separated crossings package below.


6.8.1 Grade separated crossings package This package defines the classes needed for the second and third cases above.

Figure 6-39 - Grade separated crossings

6.8.1.1 ER_LinkLevel

Defines three possible levels for a road link the same way as edge levels in GDF.


startLevel Used when the road link is connected to a start node which in the planar topology case represents a grade separated crossing.

The level shall be an integer number between -9 and +9 where the lowest number indicates lowest level.

endLevel Used when the road link is connected to a end node which in the planar topology case represents a grade separated crossing.


intermediateLevel Used in the non-planar topology case where z values either are missing or are unreliable to indicate the level for the link.



correctIntermediateLevel If intermediateLevel is set, neither startLevel nor endLevel shall be set. This implies that startLevel or endLevel can not be set at the same time that intermediateLevel is set.

OCL:

intermediateLevel->size() = 1 implies


startLevel->size() + endLevel->size() = 0

correctStartLevelNode If startLevel is used, the road node at the start of the road link must have a nodeType = ER_GradeSeparatedCrossing. This is only possible to formally describe in the topological network representation case using OCL.

startLevel->size() = 1 and roadnetElement.oclAsType(ER_RoadnetLink).edge->size() = 1 implies

roadnetElement.oclAsType(ER_RoadnetLink).edge.boundary->select(n : ER_Node | n.orientation = “+” and n.roadNode.nodeType = ER_GradeSeparatedCrossing)->size() = 1

correctEndLevelNode If endLevel is used, the road node at the end of the road link must have a nodeType = ER_GradeSeparatedCrossing. This is only possible to formally describe in the topological network representation case using OCL.

endLevel.size() = 1 and roadnetElement.oclAsType(ER_RoadnetLink).edge->size() = 1 implies

roadnetElement.oclAsType(ER_RoadnetLink).edge.boundary->select(n : ER_Node | n.orientation = “-” and n.roadNode.nodeType = ER_GradeSeparatedCrossing)->size() = 1

6.8.1.2 ER_GradeSeparatedCrossing

Defines a grade separated crossing as a separate feature the same way as the grade separated crossing relation in GDF. The feature relates exactly two road segments (one upper and one lower). If there are more road segments involved, more features of this type will have to be created. Using a segment expression allows for (but does not require) to define the segment actually intersecting (in the plane).


upperLevelElement Refers to the upper level road segment in a grade separated crossing. Can refer to a complete linear element (link or route) or the intersecting segment. The referred segment plays the role of being upper level in relation to the segment referred by lowerLevelElement.

lowerLevelElement Refers to the lower level road segment in a grade separated crossing. Can refer to a complete linear element (link or route) or the intersecting segment. The referred segment plays the role of being lower level in relation to the segment referred by


upperLevelElement.

6.9 Updates

6.9.1 Transactions and updates According to EuroRoadS requirements, it must be possible to exchange both complete datasets and updates represented in a dataset. Updates to a given dataset are considered to occur sequentially along a timeline. A EuroRoadS representation of updates must therefore be capable of representing a sequence of updates that occurred since a point in time.

The transactions and updates model assumes that it is possible to query a dataset for all changes that occurred since a specified point in time. It is not required that changes are available continuously. Whether changes are available continuously, daily, monthly or yearly has to do with the resolution of the timeline. A measure for this resolution could be considered for the metadata catalogue.

The EuroRoadS model does not include a query model (i.e. a model to define something like an SQL WHERE-clause). It assumes that such conditions are included in the agreement between a content provider and a user. Different implementations can, and are allowed to, have different capabilities.

One important aspect of updates is to verify that the complete update sequence is completed. If only part of the update sequence is completed, this could leave the receiving database in a corrupt state. To prevent this from happening, EuroRoadS uses transactions to represent updates that are dependant and should either be completed fully or, if an error occurs during the update, rolled back to ensure that the previous versions of the objects are preserved.

6.9.1.1 Updates An update in EuroRoadS can be of any of the following basic types:

- Insert – a new road feature has been created

- ModifyObject – a road feature has been modified

- Delete – a road feature as been deleted

The above types of updates are required, i.e. they must be supported by content providers.

To add more semantics to the update model, the following optional types of updates are also provided by EuroRoadS:

- Split – A road feature has been split into (replaced by) new road features in a 1 to n fashion

- Merge – Several road features have been merged (replaced by) one new road feature in a n to 1 fashion

- Replace – Several road features have been replaced by several new road features in a n to m fashion

- ModifyAttribute – One or more attributes have been updated for a roadnet element.


Updating, requires that the initial load of database, and that all previous as well as all subsequent updates are delivered from the same provider, or at least a provider that has the same set of road features (with the same identities) as the original provider.

This is to make sure that no object within the same area can occur twice but with different identities.

Example:

Provider A delivers an initial dataset to Company X. This is the initial dataset that X uses for their first map. Next month company X orders an update from provider B within the same geographical area that does not contain the id’s from provider A. This update would fail, as no objects from provider B would be represented within Company X’s map.

Instead, Company X needs to order the updates from provider A to ensure that the objects gets correctly updated if not provider B can deliver correct id’s for the already existing objects.

In order for provider B to be able to deliver updates to Company X, they need to use provider A EuroRoadS id’s within the dataset with the updates to Company X.

6.9.1.2 Transactions EuroRoadS shall use transactions to ensure uncorrupted data. Within one transaction updates of the above listed types can occur.

6.9.1.3 Transaction and update model. Below is shown the transaction model that might be used to enable incremental updates within EuroRoadS.


+transactionInfo[0..1] : RecordER_UpdateTransaction

+updateInfo[0..1] : Record«Abstract»ER_Update

ER_Insert

+oldVersionId[0..1] : CharacterStringER_ModifyObject

+classId[1] : CharacterStringER_Delete

1

+updates1..*



0..1

+insertedObject

1

0..1

+modifiedObject1

+permanentId[1] : CharacterString+versionId[0..1] : CharacterString

«Datatype»Basic types::ER_ObjectId

0..1

+deletedObjectId1

+timestamp[1] : TM_Instant+datasetId[1] : ER_ObjectId

ER_UpdateDataset

1

+transactions0..*

+segmentMappings[0..*] : ER_SegmentMapping

«Abstract»ER_CompositeUpdate

0..1

+subUpdates

2..*

ER_Split ER_Merge ER_Replace

ER_ModifyAttribute

0..1

+roadnetElementId

1

«Abstract»ER_Modify

«Abstract»Attribute base::ER_RoadAttribute

0..1

+newValues1..*

«Abstract»ER_SimpleUpdate

Figure 6-40 - Updates and transactions

Figure 6-41 - Segment mapping


6.9.1.4 ER_UpdateDataset A sequence of update transactions needed to bring a dataset into a fully synchronized state. This class will be developed further in the EuroRoadS specification of an exchange model (D6.6/D6.10). The reason for adding it to this conceptual model is to bring forward the fact that every data transfer needs to be marked by a timestamp. That timestamp marks the state of the content provider dataset at the point when the exchange dataset was produced. The next time updates are requested the previous timestamp must be used as the time from which updates shall be exchanged. There may also be a need for a dataset entity when exchanging a non-update dataset. This will be defined in the exchange model specification. There will also be a need for exchange metadata which will be defined in the exchange model.


timestamp The time when the dataset was produced. This time shall be a time when the original database and the exchanged dataset are in complete sync.

It must be possible to use this timestamp as the time from which to order updates the next time updates are exchanged.

datasetId A globally unique identifier that uniquely identifies the dataset.


transactions The sequence of transactions needed to be executed to bring the receiving dataset into an up-to-date state.

6.9.1.5 ER_UpdateTransaction A set of updates within a dataset that shall be completed and committed as one atomic update.

If one of the updates fails, no other updates shall be completed either. This will prevent any inconsistent data from being inserted into the database. Any data update delivery using EuroRoadS shall use transactions for dependant update operations. The easiest way of accomplishing this is to collect all updates in a delivery in one single transaction.


transactionInfo Transaction metadata.

Record that contain information about the transaction. Not mandatory. The structure of this record remains to be defined.



Updates The list of updates that are part of one transaction.

6.9.1.6 ER_Update An abstract base class for simple and composite updates. A transaction can have one or many updates.


updateInfo Update metadata.

Record with information about the update. Not Mandatory. The structure of this record remains to be defined.

6.9.1.7 ER_SimpleUpdate An abstract base class for simple updates representing insert, delete or modify for a single object. A composite update is built up of two or more simple updates.

6.9.1.8 ER_Insert Indicates that a new object shall be inserted.


insertedObject The object being inserted.

6.9.1.9 ER_ModifyObject Indicates a modification of an object. The object itself is preserved but gets a new state. The object must exist within the receiving system.


oldVersion The previous version of the object being modified. This can help the receiver of the data, to validate the object that is being modified, is modified with the correct version as the starting point. Not mandatory.



modifiedObject The object being modified.

6.9.1.10 ER_ModifyAttribute Indicates that a certain attribute have got new attribute values. If attribute values of the same type already exist for the referred roadnet element they shall be replaced. This class offers a mechanism to transfer less than an entire object when an update occurred. The roadnet element which is referred by id must exist in the receiving system. It is not required that a content provider use this class.


roadnetElementId The identitiy of the object whose attributes have changed.

newValues The new attribute values. If values of the same type already exist in the receiving system they shall be replaced.

6.9.1.11 ER_Delete Indicates a deletion of an object. The object must exist within the receiving system.


classId The name of the class (in EuroRoadS schema terms) of the deleted object.


deletedObjectId The identity of the object that shall be deleted.

6.9.1.12 ER_CompositeUpdate An abstract baseclass for composite updates that is built up of two or more simple updates.


segmentMappings The mapping from deleted or modified segments to inserted segments. It is not required that a content provider support segmentMappings.



subUpdates A collection of simple updates

6.9.1.13 ER_Split A type of composite update that indicates that an object has been split into several new objects in a 1 to n fashion. The original object must exist within the receiving system. It is not required that a content provider use this class.

The sub updates must contain only one modify or delete update (for the replaced object) and two or more insert updates (for the replacements).

A modification of the replaced object occurs when the road network is represented with a temporal dimension (validity). In this case the validity shall have its end date set.


OneSplit In a split there exists exactly one modify or delete update.

OCL:

subUpdates->select(oclIsKindOf(ER_Modify) or oclIsTypeOf(ER_Delete))->size = 1

TwoOrMoreInserted In a split there exists two or more insert updates.

OCL:

subUpdates->select(oclIsTypeOf(ER_Insert))->size >= 2

6.9.1.14 ER_Merge Indicates that a number of objects have been merged into one new object in a n to 1 fashion. The original objects must exist within the receiving system. It is not required that a content provider use this class.

The sub updates must contain two or more modify or delete updates (for the replaced object) and one insert updates (for the replacements).

A modification of the replaced objects occurs when the road network is represented with a temporal dimension (validity). In this case the validity shall have its end date set.


TwoOrMoreMerged In a merge there exists two or more modify or delete updates.


OCL:

subUpdates->select(oclIsKindOf(ER_Modify) or oclIsTypeOf(ER_Delete))->size >= 2

OneInserted In a merge there exists exactly one insert update.

OCL:

subUpdates->select(oclIsTypeOf(ER_Insert))->size = 1

6.9.1.15 ER_Replace Indicates that a number of objects have replaced a number of other objects in a m to n fashion. It is not required that a content provider use this class.

The sub updates contains one or more modify or delete updates (for the replaced objects) and one or more insert updates (for the replacements).

A modification of the replaced objects occurs when the road network is represented with a temporal dimension (validity). In this case the validity shall have its end date set.


OneOrMoreReplaced In a replace there exists one or more modify or delete updates.

OCL:

subUpdates->select(oclIsKindOf(ER_Modify) or oclIsTypeOf(ER_Delete))->size >= 1

OneOrMoreInserted In a replace there exists one or more insert update.

OCL:

subUpdates->select(oclIsTypeOf(ER_Insert))->size >= 1

6.9.1.16 ER_SegmentMapping The class represents in a context that a part of a linear element corresponds to a part of another linear element.

The from segment is mapped on the to segment. A direction should always be given for the toSegment to specify if the referred linear element has the same (‘+’) or opposite (‘-‘) direction.



fromSegment The from segment in the mapping.

toSegment The to segment in the mapping.


OnlyToDirection Specify direction only for the toSegment.

OCL:

fromSegment.direction.size = 0 and toSegment.direction.size = 1

NoLateralPosition No lateral position should be given.

OCL:

fromSegment.lateralPosition.size = 0 and toSegment.lateralPosition.size = 0

NoHeightPosition No height position should be given.

OCL:

fromSegment.heightPosition.size = 0 and toSegment.height.Position.size = 0

NoHeightPosition No verticalOffset should be given.

OCL:

fromSegment.verticalOffset.size = 0 and toSegment.verticalOffset.Position.size = 0


7 Appendix A – Mapping specification for GDF This section of the document describes the mappings between GDF and EuroRoadS. They are mostly quite obvious since most of the concepts and definitions are borrowed from GDF.

7.1 Road element A road element shall be represented as an ER_RoadLink with the level attribute set to ER_RoadElement. If a topological representation is used the underlying edge must be bounded by two nodes that is the topological representation for two ER_RoadNode instances represented as junctions (see below).

7.2 Ferry connection A ferry connection shall be represented as an ER_FerryLink with the level attribute set to ER_FerryConnection. If a topological representation is used the underlying edge must be bounded by two nodes that is the topological representation for two ER_RoadNode instances represented as junctions (see below).

7.3 Junction A junction shall be represented as an ER_RoadNode with the level attribute set to ER_Junction. If a topological representation is used the underlying node must bound at least one edge that is the topological representation for an ER_RoadLink instance represented as road element or ferry connection (see above).

7.4 Road A GDF Road is represented with an ER_RoadLink. A number of ER_DetailLevelMapping instances is used to map to the underlying road elements and junctions the same way as in GDF. Note that if topological representation is used, the ER_RoadLink must be topologically bounded by two ER_RoadNode instances representing the intersections. The ER_RoadLink shall have its attribute level set to ER_Road.

7.5 Ferry A GDF Ferry is represented with an ER_FerryLink. A number of ER_DetailLevelMapping instances is used to map to the underlying ferry connections and junctions the same way as in GDF. Note that if topological representation is used, the ER_FerryLink must be topologically bounded by two ER_RoadNode instances representing the intersections. The ER_FerryLink shall have its attribute level set to ER_Ferry.


7.6 Intersection A GDF Intersection is represented with an ER_RoadNode. A number of ER_DetailLevelMapping instances is used to map to the underlying road elements and junctions the same way as in GDF. Note that if topological representation is used, the ER_RoadNode must be topologically connected to at least one ER_RoadLink instance representing the road (see chapter 6.5.5.2). The ER_RoadNode shall have its attribute level set to ER_Intersection.

7.7 Enclosed traffic area An enclosed traffic area shall be represented as a fictive instance of an ER_RoadNode with the level attribute set to ER_Junction and the formOfNode attribute set to ER_EnclosedTrafficArea. A number of fictive instances of ER_RoadLink shall be created to connect the junctions that bound the enclosed traffic area with the fictive junction. These road links shall have their level attribute set to ER_RoadElement and the formOfWay attribute set to ER_EnclosedTrafficArea.

An optional geometric surface in the fictive road node can be used to define the boundary of the enclosed traffic area.

Fictive nodes and links

Optional boundary

7.8 Roundabout A Roundabout can be represented as a simple ER_RoadNode with attribute formOfNode set to ER_Roundabout. The EuroRoadS representation of the GDF complex feature Roundabout is an ER_ComplexRoadnetElement with formOfComplexElement set to ER_Roundabout. A number of ER_DetailLevelMapping instances are used to map to the underlying ER_RoadLink and ER_RoadNode instances.


7.9 Aggregated Way An aggregated way can be represented as a ER_ComplexRoadnetElement with attribute formOfComplexElement set to ER_AggregatedWay. A number of ER_DetailLevelMapping instances are used to map to the underlying ER_RoadLink and ER_RoadNode instances.

7.10 Interchange An interchange can be represented as a ER_ComplexRoadnetElement with attribute formOfComplexElement set to ER_Interchange. A number of ER_DetailLevelMapping instances are used to map to the underlying ER_RoadLink and ER_RoadNode instances.

7.11 Edge levels and grade separated crossing Edge levels are represented using the road attribute ER_LinkLevel where startLevel, intermediateLevel and endLevel correspond to the GDF edge levels. A GDF Grade separated crossing is represented using the ER_GradeSeparatedCrossing road feature where upperLevelElement and lowerLevelElement are used as in GDF.

Specification of Road Network Information · PDF fileSpecification of Road Network Information...

Documents

Transcript of Specification of Road Network Information · PDF fileSpecification of Road Network Information...