SWEDISH STANDARD SS 63 70 04-1:2006 Approved 2006-03-08 Edition 1 Geografisk information Väg- och järnvägsnät Del 1: Begreppsmodell och applikationsschema Geographic information Road and railway networks Part 1: Concept model and application schema ICS 07.040; 29.020; 35.240.50; 35.240.60; 55.180.01 Language: English Published: May 2007 Copyright SIS. Reproduction in any form without permission is prohibited.
The Swedish Standard SS 63 70 04-1:2006 was 2006-03-08 approved and published in Swedish. This document contains an English language version of SS 63 70 04-1:2006. The two versions are valid in parallel. This standard replaces the Swedish Standard SS 63 70 04, edition 1. Upplysningar om sakinnehållet i standarden lämnas av SIS, Swedish Standards Institute, telefon 08-555 520 00. Standarder kan beställas hos SIS Förlag AB som även lämnar allmänna upplysningar om svensk och utländsk standard. Postadress: SIS Förlag AB, 118 80 STOCKHOLM Telefon: 08-555 523 10. Telefax: 08-555 523 11 E-post: sis.sales@sis.se. Internet: www.sis.se
Contents Foreword... 5 Introduction... 6 Types of networks... 7 Levels of complexity... 7 The contents of the standard... 8 1 Scope... 9 2 Normative references... 10 3 Terms, definitions and abbreviations... 11 3.1 Terms and definitions... 11 3.2 Abbreviations... 12 4 Concept model... 13 4.1 Introduction... 13 4.2 Traffic networks and their spatial representation... 13 4.3 Handling several traffic networks and network traffic... 14 4.3.1 Traffic elements and traffic types... 14 4.3.2 Connection between traffic networks... 15 4.3.3 Change between traffic types... 16 4.4 Levels of detail... 17 4.4.1 Model... 17 4.4.2 Use of network systems in road networks... 19 4.4.3 Use of network systems in railway networks... 23 4.5 Network-related phenomena... 24 4.6 Change over time of traffic networks and network-related phenomena... 25 4.7 Quality reporting for traffic networks and network-related phenomena... 26 5 Application schema... 28 5.1 Introduction... 28 5.2 Principles... 29 5.2.1 Identification management... 29 5.2.2 Data quality reporting... 29 5.2.3 Geometry... 29 5.2.4 Topological levels of complexity... 29 5.3 Comparisons between link/node topology and the port concept... 30 5.4 Structure and dependence of the application schema... 31 5.5 The Road and Railway Network package... 33 5.5.1 Overview of the network model... 33 5.5.2 NW_NetElement... 34 5.5.3 NW_Node... 34 5.5.4 NW_Edge... 35 5.5.5 The relationships between TP_Node and TP_Edge in ISO 19107... 37 5.5.6 Port concept overview... 40 5.5.7 NW_Port... 40 5.5.8 NW_RefNode... 43 5.5.9 NW_RefNodePort... 44 5.5.10 NW_RefLink... 44 5.5.11 NW_RefLinkPart... 47 5.5.12 NW_RefLinkPort... 48 5.5.13 NW_LocationInstance... 49 5.5.14 NW_Net... 49 5.5.15 NW_NetBelonging... 50 Page 1
5.5.16 NW_DetailLevel... 50 5.5.17 NW_DetailLevelBelonging... 51 5.5.18 NW_System... 52 5.5.19 NW_Correspondence... 53 5.5.20 NW_TrafficCategory... 55 5.5.21 Core Temporal... 56 5.5.22 NW_ValidEdge... 56 5.5.23 NW_ValidNetBelonging... 56 5.5.24 NW_ValidDetailLevelBelonging... 57 5.5.25 NW_ValidCorrespondence... 57 5.5.26 NW_Period... 57 5.5.27 NW_Direction (data type)... 58 5.5.28 NW_Length (data type)... 59 5.5.29 NW_RelativeDistance (data type)... 59 5.6 The Net Extents package... 59 5.6.1 NW_Extent... 59 5.6.2 NW_LinkPosition... 60 5.6.3 NW_LinkPositionRelDist... 60 5.6.4 NW_LinkPositionDist... 61 5.6.5 NW_LinkPositionStart... 61 5.6.6 NW_LinkPositionEnd... 61 5.6.7 NW_LinkPositionPoint... 62 5.6.8 NW_LinkExtent... 62 5.6.9 NW_PointExtent... 64 5.6.10 NW_LineExtent... 65 5.6.11 NW_NodeExtent... 66 5.6.12 NW_NodeExtentAttr... 66 5.6.13 NW_RoadExtent... 67 5.6.14 NW_TurnExtent... 68 5.6.15 NW_SystemExtent... 70 5.6.16 NW_HeightPosition (data type)... 70 5.6.17 NW_LateralPosition (data type)... 70 5.6.18 NW_LocDirection (data type)... 71 5.6.19 NW_LaneCode (data type)... 72 5.6.20 NW_LinkRole (data type)... 72 5.7 The Generic Feature Connections package... 73 5.7.1 NW_ExtentValueDomain... 74 5.7.2 NW_LinkExtentValueDomain... 74 5.7.3 NW_NodeExtentValueDomain... 75 5.7.4 NW_ExtentAttributeValue... 76 5.8 The Traffic Connectivity package... 76 5.8.1 NW_Netconnector... 76 5.8.2 NW_Terminal... 77 5.8.3 NW_ExchangePoint... 78 5.8.4 NW_ValidNetconnector... 79 5.8.5 NW_ValidTerminal... 79 5.8.6 NW_ValidExchangePoint... 79 5.9 The General Update Model Connections package... 80 5.9.1 NW_Object... 80 5.10 Quality model (informative)... 80 5.11 Used definitions from ISO 19115... 82 5.11.1 metadata... 83 5.11.2 MD_Identification... 86 5.11.3 MD_ProgressCode (code list)... 87 5.11.4 MD_CharacterSetCode (code list)... 87 5.11.5 MD_DataIdentification... 87 5.11.6 MD_SpatialRepresentationTypeCode (code list)... 88 5.11.7 MD_Resolution... 88 5.11.8 MD_RepresentativeFraction... 89 5.11.9 CI_Citation... 90 5.11.10 CI_ResponsibleParty... 92 2
5.11.11 CI_Contact... 93 5.11.12 CI_RoleCode (code list)... 94 5.11.13 CI_Telephone... 94 5.11.14 CI_Address... 95 5.11.15 CI_OnlineResource... 95 5.11.16 URL... 96 5.11.17 See bibliography in Annex H.CI_OnLineFunctionCode (code list)... 96 5.11.18 CI_Date... 96 5.11.19 CI_DateTypeCode (code list)... 97 5.11.20 CI_PresentationFormCode (code list)... 97 5.11.21 CI_Series (data type)... 97 5.11.22 MD_TopicCategoryCode (code list)... 98 5.11.23 MD_Usage... 98 5.11.24 DQ_DataQuality... 99 5.11.25 DQ_Scope... 100 5.11.26 MD_ScopeCode (code list)... 100 5.11.27 MD_ScopeDescription (union class)... 101 5.11.28 EX_Extent... 101 5.11.29 EX_GeographicExtent... 102 5.11.30 EX_GeographicBoundingBox... 103 5.11.31 EX_BoundingPolygon... 103 5.11.32 EX_GeographicDescription... 103 5.11.33 EX_TemporalExtent... 104 5.11.34 EX_SpatialTemporalExtent... 104 5.11.35 EX_VerticalExtent... 104 5.11.36 SC_VerticalDatum... 104 5.11.37 MD_Identifier... 104 5.11.38 GM_Object... 105 5.11.39 TM_Primitive... 105 5.11.40 GF_FeatureType... 105 5.11.41 GF_AttributeType... 105 5.11.42 DQ_Element... 105 5.11.43 DQ_EvaluationMethodTypeCode (code list)... 107 5.11.44 DQ_Completeness... 107 5.11.45 DQ_CompletenessCommission... 107 5.11.46 DQ_CompletenessOmission... 108 5.11.47 DQ_LogicalConsistency... 108 5.11.48 DQ_ConceptualConsistency... 108 5.11.49 DQ_DomainConsistency... 108 5.11.50 DQ_FormatConsistency... 108 5.11.51 DQ_TopologicalConsistency... 108 5.11.52 DQ_PositionalAccuracy... 108 5.11.53 DQ_AbsoluteExternalPositionalAccuracy... 109 5.11.54 DQ_GriddedDataPositionalAccuracy... 109 5.11.55 DQ_RelativeInternalPositionalAccuracy... 109 5.11.56 DQ_TemporalAccuracy... 109 5.11.57 DQ_AccuracyOfATimeMeasurement... 110 5.11.58 DQ_TemporalConsistency... 110 5.11.59 DQ_TemporalValidity... 110 5.11.60 DQ_ThematicAccuracy... 110 5.11.61 DQ_ThematicClassificationCorrectness... 111 5.11.62 DQ_NonQuantitativeAttributeAccuracy... 111 5.11.63 DQ_QuantitativeAttributeAccuracy... 111 5.11.64 DQ_Result... 111 5.11.65 DQ_QuantitativeResult... 112 5.11.66 DQ_ConformanceResult... 112 5.11.67 LI_Lineage... 113 5.11.68 LI_Source... 114 5.11.69 LI_ProcessStep... 114 5.11.70 MD_ReferenceSystem... 115 3
5.12 The Extended Data Quality package... 115 5.12.1 EQ_AbsoluteExternalPositionalAccuracy... 116 5.12.2 EQ_RelativeInternalPositionalAccuracy... 116 5.12.3 EQ_GriddedDataPositionalAccuracy... 116 5.12.4 EQ_AccuracyOfATimeMeasurement... 117 5.12.5 EQ_TemporalConsistency... 117 5.12.6 EQ_TemporalValidity... 117 5.12.7 EQ_ConceptualConsistency... 118 5.12.8 EQ_DomainConsistency... 118 5.12.9 EQ_FormatConsistency... 118 5.12.10 EQ_TopologicalConsistency... 119 5.12.11 EQ_ThematicClassificationCorrectness... 119 5.12.12 EQ_NonQuantitativeAttributeAccuracy... 119 5.12.13 EQ_QuantitativeAttributeAccuracy... 120 5.12.14 EQ_CompletenessCommission... 120 5.12.15 EQ_CompletenessOmission... 120 5.12.16 EQ_AggregatedQuality... 121 5.12.17 EQ_ScopeDescription... 121 5.12.18 EQ_ScopeCode (code list)... 122 5.12.19 EQ_UserSatisfaction... 123 5.12.20 EQ_SpecificationConformance... 123 5.12.21 NW_NonConformityResult... 123 5.13 The Meta Quality Information package... 125 5.13.1 MQ_MetaQualityElement... 125 5.13.2 MQ_Confidence... 126 5.13.3 MQ_Representativity... 127 5.13.4 MQ_IntervalSpecification... 127 5.13.5 MQ_SymmetricRange... 127 5.13.6 MQ_AsymmetricRange... 128 5.14 The Data Quality Information package... 128 5.14.1 NW_ScopeCode (code list)... 130 5.14.2 NW_ScopeDescription... 130 5.15 Table for translating between application schema and concept model l... 131 Annex A (informative) The Concept Model... 135 Annex B (informative) Levels of detail for road networks... 140 Annex C (informative) Levels of detail in railway networks... 144 Annex D (informative) Road traffic regulations... 146 Annex E (informative) More detailed interpretation of some road and road part concepts... 147 Annex F (informative) File package... 148 Annex G (informative) Register of classes in the application schema... 159 Annex H (informative) References... 422H162 4
Foreword Swedish standard SS 63 70 04-1, version 1, was developed by the SIS/TK 320 Road and Railway Information technical committee. TK 320 is part of the project area geographic information (Stanli) within SIS, Swedish Standards Institute. The earlier version of this standard was approved in December 1998 and was named SS 63 70 04-1, version 1. At www.sis.se/stanli, under the heading User Support, materials including the XML schema may be downloaded. It is also possible to put forward questions, deliver problem reports and recommend improvements. The technical committee is responsible for further development of the standard. 5
Introduction The purpose of this standard is to facilitate the exchange of information between operators. A prerequisite for this is a common way of looking at the networks formed by roads and railways. Road and railway networks are, by their nature, continuous, and this is the basis of this standard. The network model described by this standard contains object-specific information (the road between X-town and Y-city) but it also constitutes a basis for how other information should be related to it (Seaview, the rest area Seaview, i.e. a reference system for other information. This standard supports use in different ways and by different user categories, ranging from activity requirements to developers need for a set file format for data transfer. The standard supports transfer of datasets. There are functions in the standard which make the handling of networks on different levels possible regarding their functional level of detail. It is also possible to describe a network with different levels of topological complexity. Resources for managing the updating of parts of a network and for handling reality changes over time are also included. To meet these different requirements the standard contains a number of models, see figure 1. Concept model ---------------- Stanli notation normative basis for Application schema ---------------- UML implemented in complementing resources Dataöverförings- transfer modell -------------- -------------- e.g. t.ex t.ex XML-schema outside validated against Sending Sending system system creates Dataset Överförings-dataset Överförings-dataset --------------- --------------- --------------- e.g. XML XML XML used in Receiving Receiving system system Figure 1 The role and use of this standard 6
Types of networks It is anticipated that some definitions of concepts in the basic network model will be usable for networks other than road and railway networks. However, this standard and its concept definitions only cover road and railway networks. See figure 2. infrastructure basic structure supporting public functions network intended for traffic physical transportation of people, materials or vehicles infrastructure network network for infrastructure -------------------------------- network name: Name 1:1 description: Text 0:1 network owner: Name 0:1 hydrological flow network nnn Ex.: national road net cycle path network railway network underground network tram network local train network individual line intended for traffic network infrastructure net for traffic purposes ----------------------------- plumbing network utility network nnn fairway network airway network nnn road network traffic network for road traffic purposes SS637004 railway network traffic network for rail bound traffic purposes telephone network power network nnn Figure 2 Concept schema - specialization of networks Infrastructure networks can be specialized into traffic networks. A specific traffic network can include both roads and railways (e.g. public transportation networks). Other traffic networks can be specialized into road networks and railway networks. NOTE It is possible to extend the specialisation to include fairway networks, airway networks and more. This specialisation refers to a very general level of categorisation of the network. The specific character of the network can be seen from the name and description of the network. Levels of complexity This standard can be used for different levels of complexity depending on the requirements and model characteristic that the different applications have. For example, an application using a network model on the port concept level can transfer information on this level on a lower complexity level. 7
Complexity level: Content Low complexity ISO 19107 Node/link in conformance with ISO 19107 Core Basic Also ID, updating, levels, managing of different traffic types and connections between different networks Core Temporal Also period of validity High complexity Port Concept Port concept Figure 3 The different complexity levels of the model The aim that this standard should support data exchange has influences the application schema and, to a certain extent, also in some features of the concept model. The construction of a transfer model could be followed by corresponding implementation for interfaces between applications and databases. The contents of the standard Business Business model model Normative content of the standard Concept Concept model model model explaining concepts and indicating their mutual relations Complementary resources Data Data transfer transfer model model Application Application schema schema Service Service interface interface formal description of data structure, rules and contents for information within a specific application domain Database Database schema schema various ways of implementing an application schema Figure 4 The contents of the standard A data transfer model (see figure 4) is a model that technically specifies data transfer including file format. The application schema can be implemented for data transfer in a data transfer model in different ways. Examples include XML schemas, EXPRESS or GML. 8
1 Scope This standard defines models for information describing road and railway networks. It also defines how other information is attached to these networks. The focus is on the transfer of this kind of information between different systems. The standard supports handling of metadata including quality reporting. The standard does not include: Definitions of network-related phenomena. Rules regulating how reality-related phenomena are represented as data. 9
2 Normative references The following documents are necessary for the use of this standard. For dated references, only the cited version is valid. For undated references, the latest version (including eventual additions) is valid. Most ISO standards have also been approved as European standards (EN) and thereby recognised as Swedish standards (SS). ISO 3166-3 Codes for the representation of names of countries and their subdivisions Part 3: Code for formerly used names of countries ISO 8601 ISO 9000:2005 Data elements and interchange formats Information interchange Representation of dates and times Quality management systems Principles and terminology ISO 11180:withdrawn 2004 Postal addressing (Annex A) ISO/TS 19103 ISO 19107 ISO 19108 ISO 19109 ISO 19111 ISO 19113 ISO 19114 ISO 19115 ISO 19118 SS 63 70 06 SS 63 70 07 Geographic information Conceptual Schema Language Geographic information Model for describing spatial aspects Geographic information Model for describing temporal aspects Geographic information Rules for application schema Geographic information Spatial referencing by coordinates Geographic information Quality principles Geographic information Methods for quality evaluation Geographic information Metadata Geographic information Encoding Geographic information Type-independent representation of geographic phenomena Geographic Information Representation of changes in datasets 10
3 Terms, definitions and abbreviations Terms and definitions of the concept model can be found in Section 4 and Annex A. Explanations of the terms used in the application schema can be found in Section 5. 3.1 Terms and definitions The following terms and definitions are applicable in this standard. application schema a formal description of data structure, rules, and contents for information within a specific area of application. [Samverkande GIS med ISO 19100:1994], a handbook for collaborating GIS using ISO 19100 attribute a property which describes the characteristic of an entity attribute type a type of characteristic or description of a feature type [Samverkande GIS med ISO 19100] concept model a model that defines the concepts of a universe of discourse (ISO) NOTE 1 The concept model is used to describe phenomena and characteristics within a limited area of application. NOTE 2 The concept model can be shown either as concept schema or concept table. [Samverkande GIS med ISO 19100:2004] metadata data about data. [SS-ISO 19115:2003] NOTE Information about a dataset. [Samverkande GIS med ISO 19100] feature a separate occurrence of a feature type [Samverkande GIS med ISO 19100] NOTE Feature (UML): separate occurrence of a class. feature type a category of phenomena with common properties [Samverkande GIS med ISO 19100] association aspect type a relationship type seen from the perspective of one of the two feature types involved [STG Hb 167:1996, GIS dictionary] association type a type of semantically corresponding relationship which, in a concept model, is established between two feature types [STG Hb 167:1996, GIS dictionary] 11
3.2 Abbreviations EXPRESS GML NVDB OMG Stanli Stanli-notation UML UUID VU94 XML XML schema Modelling language standardised in ISO 10303-11 Industrial Automation Systems and Integration Product data representation and exchange Part 11: Description methods The EXPRESS Language Reference Manual. Geography Mark-up Language an XML-based method for representing geographic data. The National Road Database the official Swedish basic database containing public information about municipal and private roads. Object Management Group - an international organisation which develops standards for program features for object oriented applications in open networks A project area within SIS. Works with standardization of geographic information. Graphical, modelling language for concept modelling. See the manual, Samverkande GIS med ISO 19100 Unified Modelling Language - object oriented analysis and design language developed by the Object Management Group (OMG). Universal Unique Identifier - method for unique identification of digital features. The Swedish National Road Administration s rules for road design. Used as basis for the procurement and implementation of the design and planning of public roads. Extensible Mark-up Language a simplified variant of SGML adapted for use on Internet. SGML is a standard for the structuring of documents. Schema describing the possible data content of an XML file concerning structure, content and semantics. 12
4 Concept model 4.1 Introduction The concept model explains the meaning of fundamental concepts within the application area of this standard, i.e. road and railway networks. Characteristics and associations contribute to an understanding of the concepts. NOTE 1 The concept model does not define the structure of the information. Redundancy may therefore occur. The concept model is shown in a number of figures as concept schemas using Stanli notation. The schema also contain a verbal definition of the concepts which, in the concept symbols, is written directly under the name of the concept. In some cases, examples and explanations, not supported by Stanli notation, have been added to the concept schema. NOTE 2 Concept boxes with dotted lines are not included in this standard. The complete concept model, in the form of a full concept schema and a concept table, can be found in Annex A. 4.2 Traffic networks and their spatial representation traffic network coherent system of network components for traffic purposes ----------------------------------------- network name : name 1:1 description : text 0:1 network owner : name 0:1 consists of 2:M (is part of 1:1) network component network connection or network node -------------------------------- network connection section between two neighbouring network nodes in a traffic network -------------------------------------------- distance : distance measure 1:1 reference line : line geometry 1:1 connects 1:2 (ties together 1:M) network node place where it is possible to change network connection or turn --------------------------------------- reference point : position 1:1 Figure 5 Concept schema - traffic networks and their spatial representation A traffic network consists of two or more network components. A network component is either a network connection or a network node. Each network component is part of only one traffic network. (On the other hand, a network component can be used by several kinds of traffic types, see 4.3.1) A network node either connects two or more network connections or is the endpoint of one network connection. A network connection normally connects two network nodes. However, in the case of a turning loop it only connects a single network connection. 13
NOTE Coinciding traffic networks If several traffic networks partly use the same physical infrastructure, there is a possibility that network connections and network nodes in some parts may coincide. For example, it may look as though a motor road network and a cycle path network have common network connections and network nodes. However, every traffic network has its own network topology through the relations between its network components. For this reason different traffic networks cannot share network components. The coincidence of several traffic networks in some parts can be seen as they there have a common spatial representation. If the same approach is used when handling information, it is possible to retain an unambiguous network topology for the respective traffic network and avoid unnecessary double geometry. Such a situation is illustrated in figure 6. motor road network g2 nf2 nf1 cycle path network nf3 nf4 nf1 nf2 nf3 nf4 g4 g1 g3 g5 network connections g1 g2 g3 g4 g5 geometry Figure 6 Example - motor road and cycle path networks share geometry along coinciding sections 4.3 Handling several traffic networks and network traffic 4.3.1 Traffic elements and traffic types Traffic utilising the traffic network comprises traffic elements such as vehicles or pedestrians. Passengers or transported goods are, however, not considered to be traffic elements. Based on an optional division, traffic elements may be categorised as traffic types. A traffic type is a traffic category that is considered to be homogeneous. The definition of homogeneous traffic is based on activity and application requirements. NOTE A traffic type can be broadly defined, for example, all motor road traffic or, more restrictively, public transportation, bicycle traffic or traffic with heavy vehicles or, very specifically, emergency and rescue services or bus traffic on a specific route. A traffic network is utilised by one or more traffic types whereas, on the other hand, the traffic types may utilise one or more traffic networks. From this relationship it is possible to determine the types of traffic that utilise the combined traffic networks. The demands associated with the application will determine whether or not separated traffic networks are created for different traffic types. Traffic types can also operate on network components. This relationship shows which traffic types operate on different parts of the network. 14
Ex. national road network cycle path network railway net underground net tram net local train net individual line network component network connection or network node consists of 1:M (is part of 1:1) ------------------------------------------------------------------------- traffic network coherent system of network components for traffic purposes ------------------------------------------------------------------- network name : name 1:1 description : text 0:1 owner : name 0:1 is used by 1:M (uses 1:M) uses 1:M (facilitates use of 0:M) Ex. vehicle pedestrian traffic element user of a traffic network ------------------------------ operates on 0:M (is operated on by 0:M) traffic type category of traffic that is regarded as similar ---------------------------------------------------------------------------- traffic type : name 1:1 description : text 0:1 is categorised as 0:M (is category for 0:M) Eg. car traffic bicycle traffic public transportation bus traffic Figure 7 Concept schema - traffic type and traffic network 4.3.2 Connection between traffic networks A traffic network can be connected to one or several other traffic networks. This means that traffic elements of a certain traffic type in a traffic network, such as a bicycle on the cycle path network, can be accepted i.e may continue in another traffic network such as a motor road network. See figure 8. Two traffic networks are connected through transfer points motor road network cycle path network transfer point Figure 8 Example of transfer between traffic networks Figure 8 shows that traffic elements of a given traffic type can change traffic networks at network connectors. Inversely, network connectors permit a change of traffic network for traffic elements of a given traffic type Network transfer points connect the traffic networks by connecting a network component in each traffic network. A network connector can be placed anywhere on the network components and can, for example, be located in the middle of a network connection. NOTE Network connectors make it possible for traffic to change network connection without there being a network node. At a network connector, the traffic leaves one traffic network and continues in another. A network node can, on the other hand, be defined as a place where it is possible to change network connection within the traffic network or to turn around". 15
may transfer to 0:M (may receive 0:M) network component network connection or network node ------------------------------------------------------------------------- consists of 1:M (is part of 1:1) traffic network coherent system of network components ------------------------------------------------------------------- network name : name 1:1 description : text 0:1 owner : name 0:1 is operated on by 1:M (operates on 1:M) is connected to 0:M (is connected to 0:M) uses i 1:M (facilitates use of 0:M) traffic element user of a traffic network (vehicle or pedestrian) operates on 0:M (is operated on by 0:M) traffic type category of traffic that is regarded as similar ------------------------------------------------------------------------- *traffic type: name 1:1 description: Text 0:1 is categorised as 0:M (is category for 0:M) connects 2:M (is connected by 0:M) intended for change of 1:M (changes traffic net in 0:M) facilitates change of network for 1:M (changes network in 0:M) network connector place where traffic elements may change traffic network ------------------------------------------------------------------------ Figure 9 Concept schema - connections between traffic networks 4.3.3 Change between traffic types Passenger or goods onboard a traffic element can change traffic element and thereby transfer to another traffic type. A passenger can, for example, leave a bus and continue on the local train. The traffic types can use the same or separate traffic networks. Change of traffic element can also be made within the same traffic type, for example from one bus to another. network component network connection or network node ------------------------------------------------------------------------- operates on 0:M (is used by 0:M) traffic type category of traffic that is regarded as uniform ------------------------------------------------------------------- *traffic type: name 1:1 description: text 0:1 Ex. Car traffic Bicycle traffic Public transport belongs to 1:1 (is connected by 0:M) connects 1:M (is connected by 0:M) exchange point arranged place for road-users or goods to change traffic element --------------------------------------------------------------------------------------- designation: text 0:1 connects 2:M (is connected by 0:1) terminal function connecting traffic stops ------------------------------------------------------------------------------------------- popular name: name 0:1 suitable for disabled persons: yes/no 0:1 Figure 10 Concept schema - change of traffic type NOTE The attribute types for exchange point and terminal are not checked against the actual information requirements of separate operators and should only be regarded as examples of characteristics that may be needed. 16
Terminal: Connect two or more exchange points Exchange point Provides change possibilities railtraffic road traffic Figure 11 Illustration of exchange point and terminal NOTE Terminal and exchange point differ from network connector (see 5.5.2) as follows: the terminal and exchange point makes it possible for passengers and goods to change to another traffic element which may be located in another network or be of a different traffic type. A network connector is a physical connection between two networks that makes it possible for traffic elements to change traffic networks. 4.4 Levels of detail Traffic networks may be described with different resolution. At a low level, a network can be described as connections between places and on a more detailed level as roadways, traffic lanes or railway tracks. 4.4.1 Model The level of detail indicates the resolution of a specific description of a traffic network and its components. Network systems group together a number of network components. At a lower resolution a network system is represented by a network component. This makes it possible to label individual parts of a traffic network to show the levels of detail they are meant to represent, for example, in order to indicate that a network connection represents a traffic lane or a railway track. This approach also makes it possible to simultaneously represent a traffic network on both a lower and a more detailed level and, when moving through the network, to be able to choose the level of detail without losing relative position in the network at the other level of detail. 17