trident - URBA 2000

Transcription

trident - URBA 2000

IST-1999-11076 - TRIDENT
D3.7
Programme name:
Information Society Technologies (IST)
Sector:
Road transport
Project ID:
IST-1999-10076
Project acronym:
TRIDENT
Project name:
TRansport Intermodality Data sharing and
Exchange NeTworks
Working document:
Working document number:
D3.7 (v2.0)
Contractual date of delivery:
31.07.2001
Actual date of delivery:
v2.0: 25.11.2002
Title of working document:
Final Specifications for the Object
Oriented Approach
Work package:
WP 3
Nature of the working document:
Final
Author(s):
Michele Manzato
Jonathan Booth
Michèle Blachère
Jonas Jäderberg
Christophe Duquesne
Michel Liger
Jason Kelland
Project manager:
P. Kompfner (ERTICO)
Tel: +32 2 400 07 32, fax: +32 2 400 07 01
E-mail: tridentertico@mail.ertico.com
Abstract: The documents in this set are the draft specifications for the Object Oriented
approach in Traffic and Travel Data exchange as proposed by the TRIDENT project.
These specifications must be validated by the project Test Site.
Keyword list: TRIDENT, UML, XML, Specifications, Object Oriented approach
November 2002
D3.7 – page 1
Copyright © Reserved to the TRIDENT Project Consortium
Version 2.0
D3.7
Final Specifications for the Object
Oriented Approach
Version 2.0
25/11/2002
Produced by:
TRIDENT Consortium
November 2002
D3.7 – page 2
Version 2.0
D3.7
Document Control Sheet
Activity name:
TRIDENT
Work area:
WP 3
Document title:
Draft specifications for the Object Oriented
approach
Document number:
D3.7
Electronic reference:
G:\PERSONAL\Tuomo\Johan\Merge\TRIDENT Specs\D3.3.doc
Main author(s) or editor(s):
Michele Manzato
Other author(s):
Jonathan Booth
Michèle Blachère
Jonas Jäderberg
Christophe Duquesne
Michel Liger
Jason Kelland
Dissemination level1:
Public
Version history
Version
1.0
1.1
1.2
1.3i
1.3
2.0
Date
20/08/2001
28/09/2001
12/10/2001
25/01/2002
23/05/2002
25/11/2002
Main author
Michele Manzato
Michele Manzato
Michele Manzato
Michele Manzato
Michele Manzato
Michele Manzato
Summary of changes
First complete
Updated D3.3/1, D3.3/2 and D3.3/Annex C
Consistency check between subdocuments
Internal version of improved draft
Last version of draft specifications
Final Specifications based on site input
(document number changed to D3.7)
Approval
Prepared
Approved
Reviewed
Name
Michele Manzato
Paul Kompfner
Tuomo Eloranta
Date
01/11/2002
25/11/2002
25/11/2002
Circulation:
Recipient
EC+Consortium (v2.0)
1
Date of submission
26/11/2002
This is either: Restricted (to the programme, to the activity partners) or for Public usage
November 2002
D3.7 – page 3
Version 2.0
November 2002
D3.7 – page 4
D3.7
Version 2.0
IST-1999-11076 – TRIDENT
D3.7
Final specifications for the Object Oriented Approach
D3.7/1 Introduction
TRIDENT
Final specifications for the Object Oriented approach
D3.7/1 Introduction
Version 2.0
7 November 2002
Produced by:
TRIDENT Consortium
November 2002
D3.7/1 – page 1/18
Copyright © reserved to the TRIDENT project consortium members
Version 2.0
D3.7
D3.7/1 Introduction
Activity name:
TRIDENT
Work area:
WP 3
Document title:
Introduction
Document number:
D3.7/1
I:\Contratti\TRIDENT\Deliverables\D3.7 v1.3\D3-3-1 v1.3.doc
Michele Manzato
Other author(s):
Version history
Version
0.1
0.2
1.0
1.1
1.2
1.3
Date
07/12/00
23/07/01
02/08/2001
26/09/2001
10/10/2001
8/11/2001
Main author
Michele Manzato
Michele Manzato
Michele Manzato
Michele Manzato
Michele Manzato
Michele Manzato
2.0
Nov 2002
Michele Manzato
Summary of changes
-Chapters written over the first initial blank document.
Updates following the meeting.
Minor editorial corrections
Minor editorial corrections
Revision of Chapters 1 and 2. Better explanation of
what TRIDENT is for, who needs it, what it allows,
…
Final version
November 2002
D3.7/1 – page 2/18
Version 2.0
D3.7
D3.7/1 Introduction
Foreword
The TRIDENT Specifications suite
This document is part of the TRIDENT Object Oriented Specifications, which are composed by the
following seven documents:
D3.7/1. Introduction and scope
D3.7/2. System functions and system architecture
D3.7/3. Logical Data Model
D3.7/4. XML Schema
Annex A. Data dictionary
Annex B. The ILOC+ location referencing system
Annex C. Appendices
These documents were produced by the TRIDENT Task Force for the Object Oriented approach,
between December 2001 and November 2002. These specifications supersede the corresponding
documents of all versions of deliverable D3.7.
Purpose of the specifications
The specifications described in these documents aim to establish a new data exchange mechanism
for inter-modal traffic and travel information. They can be used by Traffic Information Centres
(TIC), Traffic Control Centres (TCC), Public Transport Operators, Public Transport Authorities and
Service Providers to exchange information on public transport, road traffic and modal shifts. This
specifications suite is denoted as TRIDENT.
Purpose of this document
This document aims to provide an overall description of the TRIDENT project and in paticular of
the Object Oriented approach followed within the project.
The depth, style and content of this document were chosen to ensure that non-technical readers
would understand them.
November 2002
D3.7/1 – page 3/18
Version 2.0
D3.7
D3.7/1 Introduction
Table of Contents
Foreword...........................................................................................................................................3
The TRIDENT Specifications suite ...............................................................................................3
Purpose of the specifications .........................................................................................................3
Purpose of this document...............................................................................................................3
Table of Contents .............................................................................................................................4
1
The TRIDENT project and specifications .............................................................................6
1.1 What is TRIDENT .................................................................................................................6
1.2 Why is TRIDENT needed......................................................................................................6
1.3 Who needs TRIDENT?..........................................................................................................7
1.3.1 Audience of the TRIDENT specifications .....................................................................7
1.3.2 Do end-users need TRIDENT? ......................................................................................7
1.4 Scope of the TRIDENT specifications ..................................................................................8
1.4.1 Architecture....................................................................................................................8
1.4.2 Security ..........................................................................................................................8
1.4.3 Scope of information that can be exchanged .................................................................8
1.4.4 Ways of accessing information ......................................................................................9
2
Content of the specifications .................................................................................................10
2.1 Summary ..............................................................................................................................10
2.1.1 D3.7/1 – Introduction...................................................................................................10
2.1.2 D3.7/2 - System specifications and system architecture..............................................10
2.1.3 D3.7/3 – Logical Data Model ......................................................................................11
2.1.4 D3.7/4 – XML Schema ................................................................................................11
2.1.5 D3.7 Annex A – Data dictionary .................................................................................11
2.1.6 D3.7 Annex B – Location referencing .........................................................................12
2.1.7 D3.7 Annex C – Appendices........................................................................................12
2.2 Testing of the specifications ................................................Error! Bookmark not defined.
3
Summary of Object Oriented technologies adopted in TRIDENT ...................................13
3.1 Summary ..............................................................................................................................13
3.2 The Unified Modelling Language (UML) ...........................................................................13
3.2.1 The importance of modelling.......................................................................................14
November 2002
D3.7/1 – page 4/18
Version 2.0
D3.7
D3.7/1 Introduction
3.2.2 Goals of the UML ........................................................................................................14
3.2.3 UML Present and Future..............................................................................................15
3.3 The Extensible Mark-up Language (XML) .........................................................................16
3.3.1 Typical applications .....................................................................................................16
November 2002
D3.7/1 – page 5/18
Version 2.0
D3.7
D3.7/1 Introduction
1 The TRIDENT project and specifications
1.1 What is TRIDENT
TRIDENT is a 5th Framework Programme EU project that focuses on the exchange and sharing of
multi-modal Travel and Traffic information.
As for past experiences in single mode developments, the project expectation is to favour and/or
accelerate the development of telematic networks and to enable a more rapid diffusion of ITS
services. A major output of the project will be the preparation of specifications for systems
architectures in the multimodal travel domain.
TRIDENT is now in the process of developing specifications in two approaches following two
parallel streams: the EDI approach and the Object-oriented approach.
EDI approach. The EDI approach aims to extend the DATEX specifications with new messages
that allows the exchange of some public transport data: public transport timetables, public transport
delays and cancellations, trip times. The current version of the TRIDENT EDI approach
specifications are described in TRIDENT deliverable D3.1.
Object-oriented approach. The Object-oriented approach aims to design a new data exchange
mechanism which supports multimodality, state-of-the-art technologies and more open architectures
and networks. The Object-oriented approach is described in this suite of documents, and unless
otherwise stated is the approach intended everywhere from here on.
1.2 Why is TRIDENT needed
Many systems designed for the exchange of data related to travel and traffic have already been
developed in the past, both as proprietary solutions or as national or international standards.
Among the international standards is DATEX, of which TRIDENT can be considered the
conceptual and technological evolution. In fact, inspiration for TRIDENT came principally by those
problems recognised in the deployment process of DATEX, and by the acknowledgement of the
growing needs in the market of traffic and travel data.
System Architecture. A first issue that made evident in the implementation of DATEX systems
was that connections between different parties and organisations were hard to set up, maintain and
operate – and thus very expensive and time-consuming with respect to the rest of the system.
TRIDENT addresses this issue by leaning on the Internet, that nowadays connect almost every
computer on Earth with rather inexpensive links.
System functions. In DATEX basic system functions were implemented in a “messaging”
approach. DATEX, in fact, makes use of EDIFACT for packaging information and FTP as transport
layer. These technologies are well consolidated and have been around for a long time, but they
suffer of a number of known problems and limitations. For many applications a client/server
paradigm would be more flexible and more practical.
November 2002
D3.7/1 – page 6/18
Version 2.0
D3.7
D3.7/1 Introduction
Multimodality. Most of the existing developments are specific to one transport mode – DATEX,
for example, was specially conceived for Road Traffic data exchange between TICs/TCCs1 either
for internal management purposes and/or to provide information to end users. For the same reasons,
nowadays Public Transport Operators also need to exchange information on the Public Transport
Service, at least as much as TICs do. Some solutions were developed in the past few years (see, as
an example, the TransXchange UK standard, which is specifically designed for bus registrations)
however all are application-specific.
New state-of-the art technologies. Several distributed data exchange technologies have been
designed and developed during the past few years and have been effectively applied to many
different IT fields. Many of these technologies have reached the status of a standard: notably, Java
and CORBA. Both of them embed the principles of object-oriented programming. Ten years ago,
when the development with DATEX started, these technologies were yet to came. When we
reconsidered the design of a new data exchange system we recognised the benefits that the adoption
of these technologies would bring.
1.3 Who needs TRIDENT?
1.3.1 Audience of the TRIDENT specifications
TRIDENT is targeted to Authorities, Operators and Service Providers, that is public bodies or
private companies that need to exchange rather large amounts of travel and traffic data, either for
internal management purposes or in order to provide information or services to third bodies.
With regard to the basic information chain to convey information and other transportation related
services to the end users is more and more frequent the distinction between data, content and
service providers. In the transportation domain (either one or multi-modal) sometimes the three
roles are played within/by the same organisation/transport operator. Nevertheless, the practice of
ITS services operation has developed recently towards new organisational arrangements where one
or more of the above tasks are performed by other companies/organisations2.
TRIDENT enables the publication and the access to a wide scope of different information with
similar, homogeneous functions and techniques. This save time and money: a new system shall not
be designed anew each time a different provider has to be accessed or a new kind of information
has to be published!
1.3.2 Do end-users need TRIDENT?
The end-users – that is, the travellers – do not need TRIDENT directly and, in most cases, will not
perceive whether TRIDENT is at work in the background or not. However, the presence of
1
Traffic Information Centre (TIC), Traffic Control Centre (TCC)
2
Sometimes these organisations acting as service and/or content providers are linked to a public sector transport
operator through PPP (Public Private Partnerships) to favour the necessary tight co-operation on the
technical/technological choices.
November 2002
D3.7/1 – page 7/18
Version 2.0
D3.7
D3.7/1 Introduction
TRIDENT will greatly increase the amount and accuracy of information that is available to endusers.
On the other side, Authorities, Operators and Service Providers will take great benefits from the
usage of TRIDENT in delivering information to end-users: the development of new end-user
services will be easier since with TRIDENT information is made accessible in a homogeneous way.
1.4 Scope of the TRIDENT specifications
TRIDENT users shall establish TRIDENT-conforming systems in order to share and exchange
traffic and travel information. This section resumes briefly the characteristics of these systems and
the main functionalities that they shall provide.
1.4.1 Architecture
TRIDENT defines a distributed object-oriented architecture in order to allow TRIDENT systems to
communicate. The architecture enables ‘client-server’ style interaction, which is someway more
interactive than the “messaging” approaches (such as EDI). Any TRIDENT system can act as a
“client”, a “supplier” or both “client” and “supplier”.
1.4.2 Security
Every client system must be assigned appropriate security credentials in order to access information
on a supplier system. Basically, the operator of a TRIDENT Supplier system will assign separate
usernames and passwords to each client. Each time a client connects it will communicate both
username and password. This way the suppliers will be able to:
•
reject requests coming from nonauthorised clients;
•
selectively limit the scope of the accessible information by different providers. I.e., a trusted
client can be given full access to information, while an almost anonymous client will be able
to access only part of it.
•
track information requests and downloads from authorised clients;
1.4.3 Scope of information that can be exchanged
The following families of information can be exchanged (within the current version of the
TRIDENT specifications):
•
Road traffic data (traffic measurements)
•
Situations and events, in the road traffic and public transport domain
•
Trip times
•
Itineraries
•
Public transport network descriptions
November 2002
D3.7/1 – page 8/18
Version 2.0
D3.7
•
Public transport static timetables
•
Public transport status
D3.7/1 Introduction
1.4.4 Ways of accessing information
Information can be exchanged either “on demand” or “on occurrence”.
When exchanged on-demand, the client explicitly asks for information to the supplier: if the
supplier has it, then the requested information is returned immediately. A typical request ondemand is the request of a specific Public Transport network: a response with the structure of the
network is delivered at once, just after the request is submitted.
When exchanged on occurrence, the client initially establishes a “subscription” on the supplier that
states which information is requested and when it should be delivered. Then, when the conditions
expressed in the request are met, the supplier delivers the information to the supplier. A typical
example of this are Road Traffic events: normally a client will tell the supplier which events are of
interest to him and which roads/areas they will affect; then, when matching events are detected,
they are delivered to the client.
November 2002
D3.7/1 – page 9/18
Version 2.0
D3.7
D3.7/1 Introduction
2 Content of the specifications
2.1 Summary
The TRIDENT Object-oriented specifications are a single, closed set of specifications. However,
they have been divided into several different documents in order to:
•
ease the readability of the different parts;
•
provide an easy way to extend single documents without having to update the others;
•
make it easy to pick only what is needed out of the specifications.
The specifications are divided into the following parts:
•
D3.7/1 – Introduction
•
D3.7/2 – System Specifications and System Architecture
•
D3.7/3 – Logical Data Model
•
D3.7/4 – XML Schema
•
D3.7/Annex A – Data Dictionary (*)
•
D3.7/Annex B – Location Referencing (*)
•
D3.7/Annex C – Appendices
Those parts marked (*) are common with the EDI and Object-oriented specifications
2.1.1 D3.7/1 – Introduction
You are reading it. It gives:
•
an overall introduction to the TRIDENT project;
•
an overview of the TRIDENT Object Oriented specifications suite;
•
a brief introduction to the Object Oriented technologies that have been used in the
specifications.
2.1.2 D3.7/2 - System specifications and system architecture
This section defines the TRIDENT system specifications. It is divided into several parts:
•
describes the different “use-cases” that are allowed by the TRIDENT OBJECT-ORIENTED
specifications are described. An Use-case is an UML modelling paradigm which describes
an operative scenario where a number of “actors” are at work and can perform only a set of
well-defined operations.
November 2002
D3.7/1 – page 10/18
Version 2.0
D3.7
D3.7/1 Introduction
•
defines the system interfaces that ‘peers’ can implement in order to exchange information,
using UML class diagrams. These interfaces are very generic and are not explicitly limited
to exchange Travel and Traffic information only. Generic “requests” and “responses” are
taken into account. The interfaces support both single requests (“pull” functions) and
registered requests (“push” functions);
•
describe the inner behaviour of the basic operations of system interfaces in term of UML
sequence diagrams.
•
describe the structures that allow the exchange of Travel and Traffic information. These
structures are intended to incapsulate objects that are instances of the classes defined in the
Logical Data Model in order for them to be delivered ‘over the wire’.
2.1.3 D3.7/3 – Logical Data Model
This document provides an Object Oriented Data Model that defines how a set of Travel and Traffic
Information can be organised into a well-defined logical structure. The Data Model aims to be
coherent in integrating Road Traffic, Public Transport and some inter-modal facilities in a common,
integrated approach. As far as we know, this is the first attempt in this direction.
The Logical Data Model is described as a set of UML diagrams. The structure of the Logical Data
Model is the result of coherent union of existing data models in the Road Traffic domain (mainly
DATEX) and in Public Transport domain (TRANSMODEL). Also, a large part of the data model is
the result of original work within the TRIDENT task force.
A lot of effort was put in making the Object Oriented Data Model a self-contained model that can
be easily drawn out of the specifications. Implementers are encouraged to keep this Data Model as a
reference model for the representation of Travel and Traffic information.
2.1.4 D3.7/4 – XML Schema
TRIDENT recognises the importance of XML since it is rapidly becoming the de-facto standard for
sharing and exchanging structured data. Thus, this document contains the reference implementation
of the OBJECT-ORIENTED Logical Data Model for XML, described in term of an XML schema.
Also, as XML is a real software language, this document proposes an implementation of the logical
data model described in D3.7/3 in a real programming language. Thus it addresses most of the
issues that may arise in the implementation of the specifications in any other programming
language.
2.1.5 D3.7 Annex A – Data dictionary
Annex A describes the classes, class attributes and enumerated values used through the whole
specifications. At the current state of development, a single data dictionary was produced for both
the EDI and the Object Oriented approach. The data dictionary is thereby a mix of the two
approaches.
November 2002
D3.7/1 – page 11/18
Version 2.0
D3.7
D3.7/1 Introduction
As for the Logical Data Model, the content and the organisation of the data dictionary owes much
to DATEX and to TRANSMODEL. Since many objects in the Data Model are brand new
appropriate new definitions are supplied.
2.1.6 D3.7 Annex B – Location referencing
A key issue in the exchange of Travel and Traffic information is the actual way geographic
locations are described and coded, that is Location Referencing. Due to the variety of location
referencing methods developed and currently in use, especially in the ITS domain (text names,
ALERT-C codes, proprietary codes, coordinates, …) and to the different requisites that these
methods have in different contexts (e.g. Road Traffic and Public Transport) this issue proved to be
one of the most challenging in TRIDENT.
Annex B, also a common document between the EDI and the Object-oriented approach, describes
the TRIDENT proposal for location referencing. In order to guarantee compatibility with existing
systems a wide number of commonly used location referencing methods have been retained and
will be supported by TRIDENT. Besides, an extended ILOC referencing method, ILOC+, has been
devised in order to provide a means of coding another wide range of locations: PT points (stops,
access points, …), addresses, areas, proprietary codes, …
2.1.7 D3.7 Annex C – Appendices
Annex C contains the complete bibliography and glossary of D3.7.
November 2002
D3.7/1 – page 12/18
Version 2.0
D3.7
D3.7/1 Introduction
3 Summary of Object Oriented technologies
adopted in TRIDENT
3.1 Summary
This section gives an overview of the principal Object Oriented technologies that have been
adopted into the TRIDENT developments: UML and XML.
This Chapter is neither a tutorial for these technologies nor a complete description to their scope. Its
sole aim is to introduce these technologies and focuses on their importance with respect to
suitability for software research and development and diffusion among software professionals. For
further information please refer to the books cited in the bibliography or to the huge amount of
information widely available on the Internet.
Most of the material reported in this Chapter is derived from introductory and tutorial material
found on the Internet.
3.2 The Unified Modelling Language (UML)3
As the strategic value of software increases for many companies, the industry looks for techniques
to automate the production of software and to improve quality and reduce cost and time-to-market.
These techniques include component technology, visual programming, patterns and frameworks.
Businesses also seek techniques to manage the complexity of systems as they increase in scope and
scale. In particular, they recognise the need to solve recurring architectural problems, such as
physical distribution, concurrency, replication, security, load balancing and fault tolerance.
Additionally, the development for the World Wide Web, while making some things simpler, has
exacerbated these architectural problems. The Unified Modeling Language (UML) was designed to
respond to these needs.
UML is a language for specifying, visualising, constructing, and documenting the artifacts of
software systems, as well as for business modelling and other non-software systems. The UML
represents a collection of best engineering practices that have proven successful in the modelling of
large and complex systems. Many companies are incorporating the UML as a standard into their
development processes and products, which cover disciplines such as business modelling,
requirements management, analysis & design, programming and testing.
3
This section is largely based on an UML introduction found on the OMG website, www.omg.org.
November 2002
D3.7/1 – page 13/18
Version 2.0
D3.7
D3.7/1 Introduction
3.2.1 The importance of modelling
Developing a model for an industrial-strength software system prior to its construction or
renovation is as essential as having a blueprint for a building. Good models are essential for
communication among project teams and to assure architectural soundness. As the complexity of
systems increases, so does the importance of good modelling techniques. There are many additional
factors of a project’s success, but having a rigorous modelling language standard is essential.
A modelling language must include:
•
Model elements, fundamental modelling concepts and semantics.
•
Notation, visual rendering of model elements.
•
Guidelines, idioms of usage within the trade.
In the face of increasingly complex systems, visualisation and modelling become essential. The
UML is a well-defined and widely accepted response to that need. It is the visual modelling
language of choice for building object-oriented and component-based systems.
3.2.2 Goals of the UML
The primary goals in the design of the UML were as follows:
•
Provide users with a ready-to-use, expressive visual modelling language so they can develop
and exchange meaningful models.
•
Provide extensibility and specialisation mechanisms to extend the core concepts.
•
Be independent of particular programming languages and development processes.
•
Provide a formal basis for understanding the modelling language.
•
Encourage the growth of the Object-oriented tools market.
•
Support higher-level development concepts such as collaborations, frameworks, patterns
and components.
•
Integrate best practices.
3.2.2.1 Scope of the OMG-UML
First and foremost, the Unified Modelling Language fuses the concepts of Booch, OMT and OOSE.
The result is a single, common, and widely usable modelling language for users of these and other
methods.
Second, the Unified Modelling Language pushes the envelope of what can be done with existing
methods. As an example, the UML authors targeted the modelling of concurrent, distributed
systems to assure that the UML adequately addresses these domains.
Third, the Unified Modelling Language focuses on a standard modelling language, not a standard
process. Although the UML must be applied in the context of a process, experience has shown that
different organisations and problem domains require different processes. (For example, the
development process for shrink-wrapped software is an interesting one, but building shrinkwrapped software is vastly different from building hard-real-time avionics systems upon which
November 2002
D3.7/1 – page 14/18
Version 2.0
D3.7
D3.7/1 Introduction
lives depend.) Therefore, the efforts concentrated first on a common meta-model (which unifies
semantics) and second on a common notation (which provides a human rendering of these
semantics). The UML authors promote a development process that is use-case driven, architecture
centric, and iterative and incremental.
3.2.2.2 Outside The Scope of the UML
While the UML aims to simplify and standardise modelling it is not an all encompassing language.
This gives it the flexibility to be used to design a variety of systems over a wide spectrum of
industries. Some major areas outside of the scope of the UML include:
Programming Languages
The UML, a visual modelling language, is not intended to be a visual programming language, in the
sense of having all the necessary visual and semantic support to replace programming languages.
The UML is a language for visualising, specifying, constructing, and documenting the artifacts of a
software-intensive system, but it does draw the line as you move toward code. The UML does have
a tight mapping to a family of Object-oriented languages, so that you can get the best of both
worlds.
Tools
Standardising a language is necessarily the foundation for tools and process. The primary goal of
the OMG RFP was to enable tool interoperability. However, tools and their interoperability are very
dependent on a solid semantic and notation definition, such as the UML provides. The UML defines
a semantic meta-model, not a tool interface, storage, or run-time model, although these should be
fairly close to one another.
Process
Many organisations will use the UML as a common language for their project artifacts, but they
will use the same UML diagram types in the context of different processes. The UML is
intentionally process independent, and defining a standard process was not a goal of the UML or
OMG’s RFP.
3.2.3 UML Present and Future
The UML is non-proprietary and open to all. It addresses the needs of user and scientific
communities, as established by experience with the underlying methods on which it is based. Many
methodologists, organisations , and tool vendors have committed to use it. Since the UML builds
upon similar semantics and notation from Booch, OMT, OOSE, and other leading methods and has
incorporated input from the UML partners and feedback from the general public, widespread
adoption of the UML should be straightforward.
There are two aspects of "unified" that the UML achieves: First, it effectively ends many of the
differences, often inconsequential, between the modelling languages of previous methods.
Secondly, and perhaps more importantly, it unifies the perspectives among many different kinds of
systems (business versus software), development phases (requirements analysis, design and
implementation), and internal concepts.
Although the UML defines a precise language, it is not a barrier to future improvements in
modelling concepts. We have addressed many leading-edge techniques, but expect additional
November 2002
D3.7/1 – page 15/18
Version 2.0
D3.7
D3.7/1 Introduction
techniques to influence future versions of the UML. Many advanced techniques can be defined
using UML as a base. The UML can be extended without redefining the UML core.
The UML, in its current form, is expected to be the basis for many tools, including those for visual
modelling, simulation and development environments. As interesting tool integrations are
developed, implementation standards based on the UML will become increasingly available.
The TRIDENT Object Oriented Specification is among these.
3.3 The Extensible Mark-up Language (XML)
The Extensible Mark-up Language (XML) is a W3C Standard for marking up data into text
streams. XML has been widely adopted as a means of interchanging information between computer
programs.
XML is an extremely simple dialect of the Standard Generalised Mark-up Language (SGML)
defined in ISO Standard 8879:1986. SGML was designed in the 1980's as a tool to enable technical
documentation and other forms of publishable data to be interchanged between authors, publishers
and those responsible for the production of printed copies of data sets. By providing a formal
definition of the component parts of a publishable information set, SGML made it possible to verify
the correct transmission and receipt of interchanged data sets. It was soon found that these
techniques are applicable in areas other than those directly related to publications. For example,
SGML is often used as a neutral data format when moving data between databases as part of
multinational projects.
The goal of XML is to enable SGML-coded data to be served, received, and processed on the Web
in the way that is as easy as that currently made possible by use of the fixed SGML tag set provided
by HTML. XML has been designed for ease of implementation and for interoperability with both
SGML and HTML.
XML was not designed to be a standardised way of coding text: in fact it is impossible to devise a
single coding scheme that would be suit all languages and all applications. Instead XML is formal
language that can be used to pass information about the component parts of a document to another
computer system. XML is flexible enough to be able to describe any logical text structure, whether
it be a form, memo, letter, report, book, encyclopædia, dictionary or database.
3.3.1 Typical applications
XML was originally developed to allow structured documents of the type typically encoded in
SGML to be delivered over the Internet as an integrated part of the World Wide Web of documents.
Typically these documents require the specification of element types over and above those
permitted in HTML (e.g. specific elements for parts number and other forms of article
identification, prices and other forms of calculable measurements, and special classes of displayable
text such as health warnings and controlled task lists). XML allows users to define their own sets of
document elements and describe how each of these elements should be displayed on a screen in
conformance with the supplier's house style.
Early in its development cycle XML was identified as a natural encoding format by those
attempting to work out how to exchange meta-data about stored objects. After a number of supplierspecific proposed solutions had been considered, one solution, the Resource Description
November 2002
D3.7/1 – page 16/18
Version 2.0
D3.7
D3.7/1 Introduction
Framework (RDF), became the clear favourite. RDF is used to provide an XML-coded definition of
meta-data languages which can be used to exchange sets of meta-data.
One can use the simple XML syntax to support a wide variety of applications. This idea is put
across in a simplistic way in the diagram below, which shows how XML now underpins a number
of Web markup languages and applications.
Many groups (and TRIDENT is among these) are already defining new formats for information
interchange. The number of XML applications is growing rapidly, and the growth appears likely to
continue. There are many areas, for example, the health-care industry, the Inland Revenue,
government and finance, where XML applications are used to store and process data. XML as a
simple method for data representation and organization will mean that problems of data
incompatibility and tedious manual re-keying will become more manageable.
3.3.1.1 XML Schema
XML Schema is a new language, currently a Recommendation of the World Wide Web Consortium
(W3C), to describe the content and structure of document types in XML. It serves the same purpose
as the DTD language, but it provides more powerful and flexible means to specify document
constraints.
Although DTD will continue to exist, XML Schema will prove more useful in satisfying the needs
of the wide range of applications that will use XML. The XML Schema address mainly the
following issues:
•
adding primitive data typing to XML,
•
integrating the schema language with the Namespaces specification,
•
allowing for incomplete constraints on the content of an element type, and
•
including inheritance mechanisms for element types.
November 2002
D3.7/1 – page 17/18
Version 2.0
D3.7
D3.7/1 Introduction
For all of these reasons, the TRIDENT Object-oriented task force chose XML Schema to define the
XML structure instead of DTD.
November 2002
D3.7/1 – page 18/18
Version 2.0
D3.7
D3.7/2 - System functions and system architecture
TRIDENT
D3.7/2 - System functions and system
architecture
Version 2.0
7 November 2002
Produced by:
TRIDENT Consortium
November 2002
D3.7/2 – page 1/63
Copyright © reserved to the members of the TRIDENT Consortium
Version 2.0
D3.7
Activity name:
TRIDENT
Work area:
WP 3
Document title:
System functions and system architecture
Document number:
D3.3/2
\\Napoli\ISO9000\Contratti\TRIDENT\Deliverables\D3.7\D3.7v2.0\D3-72_v2.0.doc
Michele Manzato
Other author(s):
Jonas Jäderberg
Version history
Version
1.9
2.0
Date
August 2002
November
2002
Main author
Michele Manzato
Michele Manzato
Summary of changes
First version of the final specifications.
Amended version with enhanced model.
November 2002
D3.7/2 – page 2/63
Version 2.0
D3.7
Foreword
D3.7/4. XML Schema
Annex C. Appendices
The specifications described in these documents aim to establish a new standard data exchange
mechanism for inter-modal traffic and travel information encompassing public transports, road
traffic and modal shift, which is to be used for the communication between Traffic Information
Centres (TIC), Public Transport operator centres and Service Providers. This standard is denoted as
TRIDENT.
This document aims to provide an in-depth descriptions of the environment supporting the
exchange of travel and traffic information.
The level, style and content of this documents were chosen in order to be readily understood by
technical readers skilled in Data Modelling and UML. A comprehensive knowledge of the UML
notation syntax is required in order to correctly understand the UML diagrams presented. A fair
background on the issues that are typical in the ITS domain is welcome.
Note on document update from version 1.3
Test sites experience showed that most TRIDENT v1.3 implementation were adapted according to a
site-specific kind of “full XML approach”. That is, the whole request was made through a XML file
and the whole response was given through a single XML file. Thus, peers communicated by means
November 2002
D3.7/2 – page 3/63
Version 2.0
D3.7
of “XML messages” and the only basic functions they implemented were something like “post
message” and “receive message”.
In order to formalise these informal implementations this final document presents a proposed
common definition of such Trident “XML messages”.
Two solutions were examined at this stage:
a) produce a XML version of the call/responses paradigm proposed in D3.3/2 v1.3,
implementing a kind of remote operation call through XML. This would have resulted in an
XML version of the OO prototypes/C.A.M.s (to be reported in D3.5), totally equivalent to
the other technological implementations in Java, CORBA and COM. There would be
basically no change to D3.3/2, and the remote operation calls could be implemented in
SOAP or something similar rather than developed anew.
b) Rewrite the Trident Request/Response schema in order to build so-called “TRIDENT
messages” that would be well self-contained.
It seemed that solution a) would be too complex since no-one really wanted to implement SOAP on
the given interface definition. However, the difference between the two different “levels” (SOAP
and TRIDENT) would be very striking, and would make the XML stream not very easy to
understand to non SOAP-skilled people. Moreover, static XML files/documents do not fit naturally
into this solution. If the aim was to maintain the XML file/document/stream simple and selfcontained, this was not the right approach.
On the other hand, solution b) seemed better to follow the XML philosophy. The TRIDENT
specifications would fully define the structure and content of the XML stream. Moreover, “static”
TRIDENT XML files would simply be a different flavour of a TRIDENT message.
Another issue was whether to leave or to remove “old style” interface and implementations. I
decided to remove them, considering them as a “interim” solution and not the final one developed
by the Project.
Please note that the content of this chapter is totally new to the original Draft Object-Oriented
specifications, and as such it was not actually tested by any site – at least not in this form. Future
European Union initiatives should take care of enhancing, testing and validating the contents of this
document and of its D3.7 brothers.
November 2002
D3.7/2 – page 4/63
Version 2.0
D3.7
Table of Contents
Foreword...........................................................................................................................................3
The TRIDENT Specifications suite ..........................................................................................3
Purpose of the specifications.....................................................................................................3
Purpose of this document..........................................................................................................3
Note on document update from version 1.3..............................................................................3
1
Basic concepts and definitions ...............................................................................................8
1.1
Chapter abstract.............................................................................................................8
1.2
Basic concepts...............................................................................................................8
1.2.1 Marketplace and Information............................................................................8
1.2.2 Peers ..................................................................................................................8
1.2.3 Marketplace functions.......................................................................................8
1.2.4 Exchange network architecture.........................................................................9
2
1.3
Agreement and privacy issues.......................................................................................9
1.4
No central directory ....................................................................................................10
Use cases.................................................................................................................................11
2.1
Chapter abstract...........................................................................................................11
2.2
Actors ..........................................................................................................................11
2.3
Use cases .....................................................................................................................12
2.3.1 Use case Get Information................................................................................12
2.3.2 Use case Handle subscriptions........................................................................13
2.3.3 Use case Send notification and information ...................................................14
2.3.4 Use case Produce Off-line Data ......................................................................15
2.3.5 Use case Import Off-line Data ........................................................................15
2.3.6 Use case Handle Subscriptions Off-line .........................................................16
3
System Architecture..............................................................................................................17
3.1
3.2
On-line and off-line data exchange.............................................................................17
3.2.1 Off-line data exchange ....................................................................................17
3.2.2 On-line data exchange.....................................................................................17
3.3
System Architecture Layers ........................................................................................17
November 2002
D3.7/2 – page 5/63
Version 2.0
D3.7
3.3.1 Network layer..................................................................................................18
3.3.2 Transport Layer...............................................................................................19
3.3.3 Operation Layer ..............................................................................................19
3.3.4 Data Layer.......................................................................................................19
4
Network Layer ......................................................................................................................20
4.1
4.2
Network layer requirements........................................................................................20
4.2.1 Implementation of TRIDENT peers ...............................................................21
5
Transport Layer....................................................................................................................25
5.1
Chapter Abstract .........................................................................................................25
5.2
UML definition of the Peer Interface..........................................................................25
5.2.1 Interface definition..........................................................................................25
5.2.2 Interface method documentation.....................................................................25
5.2.3 Operation sequence .........................................................................................26
5.2.4 Error conditions...............................................................................................26
5.3
Implementation of the Peer Interface..........................................................................27
5.3.1 Java RMI implementation...............................................................................27
5.3.2 CORBA implementation.................................................................................28
5.3.3 COM/D-COM implementation .......................................................................28
5.3.4 HTTP/1.1 implementation ..............................................................................28
5.4
6
Interfacing TRIDENT-enabled systems developed in different technologies ............29
Operation Layer....................................................................................................................31
6.1
6.2
Operation Layer Functions..........................................................................................31
6.3
Usage scenarios...........................................................................................................32
6.3.1 On-line scenario ..............................................................................................32
6.3.2 Off-line scenario .............................................................................................33
6.4
Message structure........................................................................................................33
6.4.1 Prerequisites ....................................................................................................33
6.4.2 Building blocks ...............................................................................................34
6.5
Messages .....................................................................................................................38
6.5.1 On-line, client-originated communication ......................................................38
6.5.2 On-line, supplier-originated communication ..................................................40
6.5.3 Off-line, delivery message ..............................................................................41
6.6
Implementation of Operation Layer Functions...........................................................42
November 2002
D3.7/2 – page 6/63
Version 2.0
D3.7
6.6.1 Get information (A1) ......................................................................................42
6.6.2 Register subscription (A2) ..............................................................................42
6.6.3 List active subscriptions (A3) .........................................................................42
6.6.4 Get a subscription (A4) ...................................................................................43
6.6.5 Drop a subscription (A5).................................................................................43
6.6.6 Notify that a subscription was dropped by the supplier (B1) .........................43
6.6.7 Deliver information related to a subscription (B2) .........................................44
6.6.8 Generate off-line delivery (B3/A6).................................................................44
7
Data Layer .............................................................................................................................45
7.1
7.2
Handling Data Model objects .....................................................................................45
7.2.1 Root class for persistent data model objects ...................................................45
7.2.2 Operational behaviour.....................................................................................47
7.3
Requests and Deliveries ..............................................................................................48
7.3.1 Specific object.................................................................................................51
7.3.2 Children of an object.......................................................................................52
7.3.3 Itinerary calculation ........................................................................................54
7.3.4 Situation and Situation elements.....................................................................56
7.3.5 Network list.....................................................................................................58
7.3.6 List of Traffic Data Measurement Points........................................................59
7.3.7 Road Traffic Data............................................................................................60
7.3.8 Stop points ......................................................................................................61
7.3.9 Timetable ........................................................................................................62
7.3.10 Public Transport Status ...................................................................................63
November 2002
D3.7/2 – page 7/63
Version 2.0
D3.7
1
Basic concepts and definitions
1.1
Chapter abstract
This Chapter introduces the main set of concepts that are explored in the rest of the document by
defining the basic terminology. Concepts are given an official name and then the scope they apply
is described. Also, concepts and issues that are not within the scope of this document are pointed
out at the end of the Chapter.
1.2
Basic concepts
1.2.1
Marketplace and Information
The Marketplace is the logic environment which allows and sustains the exchange of (traffic and
travel) Information.
Information is normally exchanged under the form of Objects. Information can also be exchanged
as XML streams which are usually encapsulated into Objects.
1.2.2
Peers
A Peer is an actor which implements or is entitled to access one or more of the Functions of the
Marketplace.
The Marketplace can host any number of Peers and Information could, in principle, be reached by
any of of the Peers. However, at the most basic level Information is transferred on ‘one-directional’
communication channels which are established between two Peers only.
Here, ‘one-directional’ refers to the direction of Information only. Control information, handshake,
and every synchronisation mechanism required by communication equipments at lower levels of
the ISO/OSI model can of course travel in both directions.
With reference to the ‘direction’ of the flow of information between two communicating Peers, a
Peer can be either qualified as a Supplier when it gives information out or a Client when it takes
information in. Each Peer can be a Client, a Supplier or both (an Hybrid Peer).
1.2.3
Marketplace functions
A Function is one of the operations that are allowed and put into operation on the Marketplace and
that can be accessed by the Peers.
A Request is a well-formed demand for Information that is forwarded by a Client to a Supplier.
Clients expect that each Request is answered by one or more Responses containing the requested
Information1.
1
Unless an error is detected into the Request, or if the communication channel fails.
November 2002
D3.7/2 – page 8/63
Version 2.0
D3.7
1.2.3.1
Pull functions
A Pull Function is activated by a Client when placing to a Supplier a Request which is supposed to
be answered immediately. The Supplier shall collecting the relevant Information available at the
moment and shall pack it up into a Response which gets delivered to the Client.
The time Requested for the completion of a Pull Function is always limited.
Pull Functions are also known as ‘on-demand information delivery’.
1.2.3.2
Push functions
Suppliers can support Push Functions. A Push Function is activated by a Client when placing a
Request that is supposed to be stored on the Supplier’s. Requests that are registered are called
Subscriptions. A Subscription lists a set of different Information types and a set of conditions that
trigger the delivery of that Information. Suppliers should keep monitoring all the registered
Subscriptions and, when the conditions specified by the Subscription are met, collect the relevant
information, pack it up into a suitable Response and perform the information delivery to the Client
that placed the Subscription.
The lifetime of a Push Function coincide with the lifetime of the correspondent Subscription and, in
principle, is not limited. Clients can drop their Subscription at any time.
Push Functions are also known as ‘on-event information delivery’.
1.2.4
Exchange network architecture
The Exchange Network is the hardware and software infrastructure – network equipment, software
communication subsystem, etc. – that supports the communication between Peers.
A Node is the hardware equipment hosting the communication software of a Peer. The Exchange
Network connects Nodes.
An Access Module is a piece of software implementing one of the interfaces towards the services
implemented by the Peer.
1.3
Agreement and privacy issues
Due to its nature, Information owned by Supplier Peers and delivered to Client Peers can be
subjected to a number of restrictions, i.e. for privacy or commercial reasons. It is thereby assumed
that each Peer is able to qualify its identity whenever connecting to other Peers, and that Suppliers
can maintain a database of authorised Clients together with the scope of Information that can be
accessed by each Client.
By default, each Supplier can allow access to a (possibly limited) scope of the available Information
to ‘guest’, previously non-authorised Clients. The scope of information that can be accessed can be
broadened by bi-lateral agreements between Peers.
The activation of Push Functions can be preceded by a bi-lateral agreement between Client and
Supplier. However, the possibility of ‘guest’ access to (possibly limited) Pull Functions by nonpreviously authorised Clients is guaranteed.
These specifications are not concerned with:
November 2002
D3.7/2 – page 9/63
Version 2.0
D3.7
•
the nature of exchange agreements;
•
the way agreements are established;
•
any other legal or contractual issue involved in the agreement.
No limit is imposed on the number of Peers that can exchange information on the Marketplace.
1.4
No central directory
It is not part of these specifications to define how the Peers make known to each other. It is assumed
that Peers willing to communicate know which is the right Peer to ask to.
At this stage of the development of the specifications the issue of a CENTRAL DIRECTORY – i.e.
an authority saying which Supplier is in charge for providing a particular kind of Information – was
raised but not explored further. It is believed that such an issue is not fully within the scope of the
TRIDENT project and is left for future developments and extensions.
November 2002
D3.7/2 – page 10/63
Version 2.0
D3.7
2
Use cases
2.1
Chapter abstract
This Chapter enhances the concepts defined in Chapter 1 by formally defining the ‘actors’ and the
relations between them. The scenarios in which the actors are involved are then defined by means
of UML use-case diagrams.
2.2
Actors
The following Use-Case diagram shows all the involved actors.
Peer
Client
Off-line Client
Supplier
Off-line Supplier
Operator
Figure 1. Actors in the marketplace (UML use-case diagram)
The diagram shows that both a Supplier and a Client is a Peer. But a Peer do not have to be both a
Client and a Supplier
Actor: Peer
A Peer is a node exchanging information with other Peers.
Actor: Supplier
A Supplier is a Peer that gives information to other Peers.
Actor: Client
A Client is a Peer that Connects and gets information from other Peers.
Actor: Off-line Client
Is a Client that is not online connected. Or at least is not connected to Trident systems via the
Trident interfaces.
November 2002
D3.7/2 – page 11/63
Version 2.0
D3.7
Actor: Off-line Supplier
Is a Supplier that is not online connected. Or at least is not connected to Trident systems via the
Trident interfaces.
Actor: Operator
Is a human person that could interact with the system.
2.3
Use cases
The following sections give some high level diagrams describing the Use-cases involved in the
communication between Peers.
The following diagram shows a complete view of the most important use-cases. Afterwards all the
use-cases in the diagram are described in detail.
TRIDENT
Get information
Handle
Subscriptions
Client
Send notification
and information
Supplier
Import Bulk
Static data
Off-line Supplier
Handle off-line
subscriptions
Operator
Produce Bulk
Static Data
Off-line Client
Figure 2. Summary of use cases (UML use-case diagram)
2.3.1
Use case Get Information
Occurs when a Client want to request or query information from another Supplier.
November 2002
D3.7/2 – page 12/63
Version 2.0
D3.7
Get Information
Client
Supplier
Figure 3. Use case Request for Traffic/public transport information (UML use-case diagram)
Basic flow of events:
1. The use case starts when the Client want to request information from a Supplier.
2. The Client must provide his authorisation credentials (identity).
3. The Client requests for Traffic/ Public Transport information. The information could be of the
following types:
•
Public Transport timetables;
•
Public Transport delays;
•
Public Transport cancellations;
•
Public Transport status;
•
Public Transport events;
•
Public Transport network description and characterisation;
•
Public Transport connection times;
•
Road Traffic events;
•
Road Traffic data;
•
Road Traffic travel times;
•
Itineraries;
4. The Client can request that the available information is filtered on some criteria. The filtering
criteria may differ depending on the type of information requested, and possibly on the time
when the information made available.
5. The Supplier returns the filtered information to the Client.
2.3.2
Use case Handle subscriptions
When a Client wants to be notified when certain things happens at the Supplier, the Client should
register a subscription on Traffic/ Public Transport information at the Supplier’s.
November 2002
D3.7/2 – page 13/63
Version 2.0
D3.7
Handle
Subscriptions
Client
Supplier
Figure 4. Use case Handle subscriptions (UML use-case diagram)
1. The use case starts when the Client want to register, update or delete a subscription at the
Supplier.
2. The Client must provide his authorisation credentials (identity).
3. The Client tells if it’s a new subscription or if it’s an update or delete of an existing
subscription.
4. The Traffic/ Public Transport information could be of the following types:
•
Public Transport timetables;
•
Public Transport delays;
•
Public Transport cancellations;
•
Public Transport status;
•
Public Transport events;
•
Public Transport network description and characterisation;
•
Public Transport connection times;
•
Road Traffic events;
•
Road Traffic status;
•
Road Traffic travel times;
•
Weather;
6. The Client can request that the available information is filtered on some criteria. The filtering
criteria may differ depending on the type of information requested, and possibly on the time
when the information made available.
5. The Supplier stores the request made by the Client.
2.3.3
Use case Send notification and information
When something happens on the data at the Supplier’s and there are Clients that have subscriptions
on that specific information, the Client(s) should be notified and the new data should be sent to the
Client.
November 2002
D3.7/2 – page 14/63
Version 2.0
D3.7
Send notification
and information
Supplier
Client
Figure 5. Use case Send notification and information (UML use-case diagram)
1. When something has changed at the Supplier, the Supplier checks if there is Clients that wants
to be notified about that.
2. If so the Supplier sends a notification and the information to the Client.
2.3.4
Use case Produce Off-line Data
Suppliers can produce off-line data, that is a static image of (part of) the available information for
other Off-line Clients.
Off-line data is produced under the form of XML files/streams which are stored by the supplier on
the media which is intended for distribution (e.g. FTP, floppy disk, CD-ROM, or any other digital
or non-digital mechanism).
Off-line data will then be imported by “Off-line Clients”. This is described in the next Use Case.
Produce
off-line data
Operator
Off-line Client
Figure 6. Use case Produce bulk static data (UML use-case diagram)
1. The use case starts when the Operator wants to generate an XML stream for (one or more) offline Clients.
2. The Operator must choose what information to generate.
3. A XML tree is generated and returned as a stream. The XML stream can be stored on temporary
storage, e.g. on a file.
4. The Operator can then make the file available to off-line Clients on the media intended for
distribution.
2.3.5
Use case Import Off-line Data
Clients can import off-line data previously produced by Clients. This may occur e.g. when an offline Client retrieves a timetable produced by a Off-line Supplier.
November 2002
D3.7/2 – page 15/63
Version 2.0
D3.7
Import
off-line data
Operator
Off-line Supplier
Figure 7. Use case Import bulk static data (UML use-case diagram)
1. The use case starts when the Operator has received a Off-line data image from an Off-line
Supplier, under the form of an XML stream.
2. The Operator chooses to import the XML stream into the system.
3. The data is imported.
2.3.6
Use case Handle Subscriptions Off-line
It should be possible to handle subscriptions off-line. This could occur when an Operator or a Offline Client want to change one of the subscriptions.
Handle off-line
subscriptions
Operator
Off-line Client
Figure 8. Use case Handle off-line subscriptions(UML use-case diagram)
1. The use case starts when either the Operator or the Off-line Client want to add, alter or remove
one or more subscriptions for a Client.
2. For the Operator, this could occur when the Operator changes the subscription on behalf of a
Client. The Operator can act in a number of ways, e.g. via a local interface, directly in the
system database, etc.
3. The Off-line Client, which in this case will be a Client that may not support adding or removing
is own subscriptions via the TRIDENT interfaces, could do this via a proprietary interface (i.e. a
Supplier service accessible by a Web interface). This way, also, the Supplier may allow Clients
to fine-tune requests with more options and/or filtering parameters than those supported by online interfaces,.
4. On the supplier’s service the client may be presented with a ‘catalogue’ of the available
information. By selecting the appropriate information types and confirming the registration, a
subscription is stored on the supplier’s system. This ensures compatibility with DATEX
systems, which provide off-line data catalogues accessible by Clients.
November 2002
D3.7/2 – page 16/63
Version 2.0
D3.7
3
System Architecture
3.1
Chapter abstract
This Chapter describes the system architecture of the “virtual marketplace” defined in Chapter 1.
A layered approach is adopted, such as the one defined in the ISO OSI model. This approach allows
to separate functionally the various system functions that are activated at each layer.
3.2
On-line and off-line data exchange
TRIDENT implements Travel and Traffic Data Exchange by allowing Peers to exchange data under
the form of XML streams. As it was described in the use cases of Chapter 2, two types of XML data
exchange are needed: “off-line” and “on-line”.
3.2.1
Off-line data exchange
Off-line data can be exchanged, by means of:
•
standard transfer protocols (FTP, HTTP, e-mail, …);
•
electronic media (CD, Floppy Disk, …);
•
non-electronic media (paper, …);
The listed media are mere examples: off-line data exchange is of course not restricted to these
media. For the sake of simplicity, each instance of off-line data will be called a “delivery message”.
3.2.2
On-line data exchange
On-line data exchange implies that each peer is able to connect and maintain a live connection to
another peers the time required to send a “request message” and receive a “response message”.
3.3
System Architecture Layers
Various aspects of data exhange in TRIDENT can be analysed by referring to the following
diagram:
November 2002
D3.7/2 – page 17/63
Version 2.0
D3.7
Data layer
Operation layer
Transport layer
Network layer
Figure 9. System Architecture Layers
The picture is analogous to the ISO/OSI reference model for network communications. It displays
four different layers involved in TRIDENT data exchange piled one over the other in a kind of
hierarchical structure. Layers towards the bottom of the pile are the most physical-oriented, while
layers towards the top of the pile are the most application-oriented.
The layered approach enhances conceptual categorisation of system functions and improves
system extendibility. It is in fact a good engineering practice that “layered systems” be developed in
a way that changes occurring at a given layer do not affect the definitions of the underlying layers.
The following table describes briefly each of the layers:
Layer name
Description
Implementation
Data Layer
The actual traffic/travel information
transferred.
XML
Operation Layer
Allow a remote operation to be invoked
and its result returned, or a data
delivery to be produced.
XML
Transport layer
Allow request messages to be posted
and response messages to be returned.
Distributed Object Oriented
Technology
Network layer
Underlying network, allowing physical
connections between peers.
Internet (IP networks)
Further details will come in the rest of this Section.
The Network Layer and the Transport Layer are essential for on-line data exchange. However, they
are not at all needed for off-line data provision, which can even prescind from any type of network
interconnection between the peers. Readers interested in off-line data provision only can focus on
Chapters 6 and 7 where the format of XML delivery messages is described.
3.3.1
Network layer
The Network Layer is the most “physical” of the conceptual layers in the TRIDENT system
architecture. It concentrates on how TRIDENT nodes can be interconnected and on how Nodes
based on TRIDENT should be implemented, depending whether they are Clients, Suppliers or both.
See Chapter 4 in this same document for further details on the Network Layer.
November 2002
D3.7/2 – page 18/63
Version 2.0
D3.7
3.3.2
Transport Layer
TRIDENT Peers communicate mainly at the Transport Layer, which is the layer that allows the
exchange of XML messages. In order to enable such a message exchange, however, a Peer Interface
must be defined – and this is the role of the Transport Layer.
See Chapter 5 in this same document for further details on Transport Layer Functions.
3.3.3
Operation Layer
The Operation Layer defines the functions that can be activated by Clients and Supplier in order to:
request information, manage subscriptions, produce and handle off-line data deliveries.
See Chapter 6 in this same document for further details on Operation Layer Functions.
3.3.4
Data Layer
The Data Layer defines the actual traffic and travel information requests produced by Clients and
information deliveries produced by Suppliers. Data Layer Functions are implemented directly
within the XML message, as well as the Operation Layer Functions.
Once more, this layer presents a separation between the “envelope” of information requests and
information deliveries and the actual travel and traffic data representation. This document focuses
on the former, while the latter is described in the TRIDENT Data Model, Data Dictionary and XML
Schema.
See Chapter 7 in this same document for further details on Data Layer Functions.
November 2002
D3.7/2 – page 19/63
Version 2.0
D3.7
4
Network Layer
4.1
Chapter abstract
The Network Layer is the most “physical” of the conceptual layers in the TRIDENT system
architecture. It concentrates on how TRIDENT nodes can be interconnected and on how Nodes
based on TRIDENT should be implemented, depending whether they are Clients, Suppliers or both.
4.2
Network layer requirements
As shown in the description of the previous layers, for the purpose of on-line data exchange of
(travel and traffic) information the requirements imposed on the network architecture are:
•
to support a ‘client-server’ communication paradigm;
•
not to constrain the number of connecting Nodes;
•
to support the distributed object oriented technology chosen for implementation;
•
to support the exchange of XML streams.
A widely available network satisfying these requirement is the Internet and, in general, any IPbased network.
NodeInstance3
: TridentNode
NodeInstance1
: TridentNode
TridentNode
NodeInstance6
: TridentNode
This classifier represents a
generic node of the TRIDENT
network.
NodeInstance4
: TridentNode
NodeInstance2
: TridentNode
NodeInstance5
: TridentNode
Figure 10. Network architecture (UML Deployment diagram).
November 2002
D3.7/2 – page 20/63
Version 2.0
D3.7
Each Node has a ‘network address’ which is unique upon the Network. Peers willing to provide
information will publish the address of their Node. Other nodes will use the Node address when
establishing the connection.
4.2.1
Implementation of TRIDENT peers
Every node willing to allow other Peers to connect shall run a software module that implements the
ITridentPeer interface described in Chapter 5.
How the communicating systems are internally constructed or working is not important for the
TRIDENT communication. As long as the interfaces are correctly implemented, successful
communication can be performed.
4.2.1.1
Deployment on the Supplier side
Supplier Peers allows information to be Requested by the Client Peers and delivered to them in one
of two ways:
•
“on demand” (the “get information” use-case);
•
“on event” (the “register subscription” use-case);
The Supplier shall ensure that any potential number of Clients can be handled.
ClientNode1 :
TridentNode
SupplierNode : TridentNode
ClientNode2 :
TridentNode
ITridentPeer
SupplierModule
ClientNode3 :
TridentNode
Figure 11. Deployment on the Supplier side (UML Deployment diagram).
4.2.1.2
Deployment on the Client side
Three main basic situations can be distinguished on how the Client Peers are organised and on
which system functions are Requested. They are summarised here and are then described in further
detail.
•
Single/multiple Client applications, no registration;
•
Single Client application, with registration;
•
Multiple Client applications, with registration.
November 2002
D3.7/2 – page 21/63
Version 2.0
D3.7
Please note that, from the point of view of a Supplier Peer, the internal organisation of the Client’s
software makes no difference at all. Request messages are posted and message replaced and
Responses are delivered always in the same way since any complexity that goes beyond the
interfaces as they are defined in Chapter 3 has to be handled internally by the Client Peer.
4.2.1.2.1 Single/multiple Client applications, no registration
The Client node hosts either a single Client application or multiple Client applications. However
none of these need to have registered Requests, that is information is always get on demand.
This is the simplest situation, summarised in the UML deployment diagram sketched in Figure 12.
ClientNode/1 : TridentNode
SupplierNode/1 : TridentNode
Client Application 1
ITridentPeer
Supplier Access Module
Client Application 2
Figure 12. Single/multiple Client applications, no registration (UML Deployment diagram).
4.2.1.2.2 Single Client application, with registration
The Client node hosts a single Client application. Registered Requests are needed, that is
information is delivered either on demand or on event. Information can be delivered to the Client
either as the output of the “Request” operation, or periodically or on occurrence by means of
registered Requests placed with the “register” operation.
This is the intermediate complexity case: the Client application needs to implement the
ITridentPeer interface, but it knows that all the information delivered by the Supplier is
directed to itself and can thus be directly managed.
This situation is summarised in the UML deployment diagram sketched in Figure 13.
November 2002
D3.7/2 – page 22/63
Version 2.0
D3.7
Client Application
ITridentPeer
ITridentPeer
Supplier Access Mod
Figure 13. Single Client application, with registration.
4.2.1.2.3 Multiple Client applications, with registration
The Client node hosts many Client applications. Registered Requests are needed, that is information
is delivered either on demand or on event. Information can be delivered to the Client applications
either as the output of the “Request” operation, or periodically or on occurrence by means of
registered Requests placed with the “register” operation. When information is delivered on
occurrence it needs to be transferred to the right Client application, that is the one that placed the
Request.
This is the most complex case: a “Client proxy” needs to be implemented as an interface between
the Client applications and the Supplier system. The Client proxy implements the ITridentPeer
‘external’ interface as an interface towards the Supplier Peer, and the IApplicationAccess
‘internal’ interface as an interface towards the Client applications. The Client applications, in turn,
shall implement the IApplication ‘internal’ interface towards the Client proxy. This way the
Client applications never interact directly with the Supplier, but place their Requests and get their
Responses via the Client proxy. The Client proxy actually works as a ‘multiplexer’ for Requests
coming from the application and as a ‘demultiplexer’ for Responses delivered by the Supplier(s).
Whereas the ITridentPeer interface fall into the scope of TRIDENT – it is an ‘external’
interface between two TRIDENT systems – the IApplicationAccess and IApplication
interface do not as they are considered as ‘internal’ interfaces.
Actually, the internal interfaces can be implemented with a different technology rather than the one
used for the TRIDENT interface.
In order to correctly transfer to the right Client application information which is coming from
Responses to registered Requests the Client proxy will have to maintain internally a list of (id-ofRequest, application-that-placed-the-Request) couples. How this is done, however, falls again out
of the scope of these specifications.
This situation is summarised in the UML deployment diagram sketched in Figure 14.
November 2002
D3.7/2 – page 23/63
Version 2.0
D3.7
Client Access Module
ITridentPeer
IApplicationAcces
s
IApplication
Application 1
ITridentPeer
ComponentInstance1
IApplication
Application 2
Figure 14. Multiple Client applications, with registration (UML deployment diagram).
4.2.1.3
Hybrid Peers
Hybrid Peers will implement the ITridentPeer interface and will also access information on
other suppliers. They will actually be both Clients and Suppliers.
Considerations applied to only-Client and only Supplier systems shall also apply to hybrid systems.
This situation is summarised in the UML deployment diagram sketched in Figure 15, where Node2
hosts an hybrid module that implements and hybrid Peer.
Node3 :
TridentNode
Node2 : TridentNode
ITridentPeer
HybridModule
Node1 :
TridentNode
Figure 15. Hybrid peer (UML deployment diagram).
November 2002
D3.7/2 – page 24/63
Version 2.0
D3.7
5
Transport Layer
5.1
Chapter Abstract
TRIDENT Peers communicate mainly at the Transport Layer, which is the layer that allows the
exchange of XML messages. In order to enable such a message exchange, however, a Peer Interface
must be defined
First, an abstract, technology independent definition of the Peer interface is given in the UML
syntax. Then, specific implementations are given in each of the technologies that were tested in the
first phase of the TRIDENT Project. The implementation proposed here follows the
recommendation produced by the Test Sites, thereby enforcing the “full XML approach”.
5.2
UML definition of the Peer Interface
TRIDENT allow the Transport Layer to be implemented in any of the many Distributed Object
Oriented Technology available nowadays. This section describes the Peer Interface in the UML
paradigm in order to be as much as possible technology-independent. Some technology-specific
implementations will be examined in Section 5.3.
5.2.1
Interface definition
In order to allow incoming connections, a Peer shall expose an object which implements a specific
interface: ITridentPeer. Such an interface contains a single method, postMessage, that allows
the posting of a request message and the retrieval of the related response.
Figure 16 shows the UML class diagram which defines the interface that Peers must expose at the
Transport Layer.
«interface»
ITridentPeer
postMessage(in requestMessage : String, out responseMessage : String)
Figure 16. Peer interface (UML class diagram). ITridentPeer is the transport layer interface
that shall be implemented by all Peers wishing to establish a on-line communication.
5.2.2
Interface method documentation
Operation
+postMessage(in requestMessage: String, out responseMessage: String);
Description
Post a request message to the client and wait for the response message to be
produced.
Visibility
Public, Remote
November 2002
D3.7/2 – page 25/63
Version 2.0
D3.7
Input
requestMessage
The TRIDENT XML request message (created by the
local peer, the one making the request).
Output
responseMessage
The TRIDENT XML response message (produced by
the remote peer, the one answering the request).
All went ok and the XML response message is
available within the responseMessage output
parameter. Please note that this situation does only
denote a successful communication at transport level.
Normal termination
Note
5.2.3
Architecture-specific error conditions or exceptions may be raised when calling
this remote operation. See the following section for further details.
Operation sequence
The server Peer interface method can be remotely invoked by any client Peer on the network.
The following UML sequence diagram shows the interaction between peers in a on-line
communication while exchanging TRIDENT messages:
Peer A
Peer B
postMessage(request, response)
- Request message is parsed
- Client request is validated
- Requested data is retrieved
- Response message is produced
postMessage(request, response)
Figure 17. Post request message and wait for response message. (UML sequence diagram).
5.2.4
Error conditions
The correct execution the operation tells that the operation succeeded.
Please note that the successful completion of the operation, that is the correct retrieval of a response
message, does not mean that the request was successfully handled. In fact, the returned message
November 2002
D3.7/2 – page 26/63
Version 2.0
D3.7
may be an error or failure message. However, such an error is an application-level error, not a
message exchange error.
However, operations may also fail and raise exceptions that are specific to a given technology.2
Normally these exceptions are related to network connectivity problems and should in any case be
handled within the caller’s code.
5.3
Implementation of the Peer Interface
The Transport Layer Peer interface has been designed in order to be readily implemented in most of
the Distributed Systems Architectures available nowadays.3 In the following sections normative
implementations are given for some of the most common ones: Java, CORBA, COM, HTTP/1.1.
Please note that technology-specific error conditions may occur anytime during the access to the
remote service due to several reasons, among these (but not limited to):
•
connection failure;
•
nonexistence of remote peer;
•
connection link failure;
•
remote server breakdown;
•
local server malfunction;
In all of these situations that technology-specific error conditions may arise that are normally
beyond TRIDENT control. Error conditions are dealt with in each section. TRIDENT does not
indicate specific lines of conduct to follow, other than re-trying the operation.
5.3.1
Java RMI implementation
Interface
The following piece of code shows how the interface is implemented in Java RMI.
import java.rmi.*;
import java.util.*;
public interface ITridentPeerSupplier
{
public void postMessage(/*in*/ String requestMessage,
/*out*/ String responseMessage)
throws java.rmi.RemoteException;
}
Successful completion of the operation
Succesful completion of the operation is denoted by the succesful completion of the Java remote
method call.
2
For example, in the Java RMI implementation the java.rmi.RemoteException exception can be thrown by any
of the operations due to technological constraints in the way of accessing remote interfaces.
3
At present, Java and CORBA are among the most important and widespread Distributed Object Oriented architectures
in the public domain. Further details on java.sun.com and www.omg.org.
November 2002
D3.7/2 – page 27/63
Version 2.0
D3.7
Failure condition
As shown in the code the Java-specific java.rmi.RemoteException can be raised. Such an
exception should provide sufficient information in order to detect the reason why the operation
failed and to determine what to do in order to solve the problem.
5.3.2
CORBA implementation
Interface
The following piece of code shows how the interface is implemented in CORBA.
interface ITridentPeer
{
void postMessage(in string requestMessage, out string responseMessage);
};
Succesful completion of the operation is denoted by the succesful completion of the CORBA call.
Failure condition
CORBA-specific exceptions may be raised. Such exceptions should provide sufficient information
in order to detect the reason why the operation failed and to determine what to do in order to solve
the problem.
5.3.3
COM/D-COM implementation
Interface
The following piece of code shows how the interface is implemented in COM/D-COM.
HRESULT _stdcall postMessage([in] VARIANT requestMessage,
[out] VARIANT responseMessage);
Successful completion of the operation is denoted by the succesful completion of the COM/D-COM
call.
Operation failure
Specific error conditions should be identified and handled according to COM/D-COM paradigm.
5.3.4
HTTP/1.1 implementation
Interface
ITridentPeer interface can be implemented in HTTP/1.1 provided that:
•
the XML request message is delivered as the body of the HTTP request;
•
the XML response message is delivered as the body of the HTTP response.
November 2002
D3.7/2 – page 28/63
Version 2.0
D3.7
Operation result
The result of the HTTP/1.1 transfer is given by the HTTP Status-Code, a 3-digit integer. These
codes are fully defined in section 10 of RFC 26164. The first digit of the Status-Code defines the
class of response. It can be in one of the following classes:
•
1xx: Informational - Request received, continuing process
•
2xx: Success - The action was successfully received, understood, and accepted
•
3xx: Redirection - Further action must be taken in order to complete the request
•
4xx: Client Error - The request contains bad syntax or cannot be fulfilled
•
5xx: Server Error - The server failed to fulfill an apparently valid request
Successful completion of the TRIDENT operation is thus denoted by the succesful completion of
the HTTP transfer, that is when 100 <= HTTP result code <= 199.
Clients can be able to handle HTTP further actions (200 <= HTTP result code <= 299), e.g. HTTP
redirects.
Operation is to be considered failed when HTTP result code >=400.
5.4
Interfacing TRIDENT-enabled systems developed in different
technologies
The Peer interfaces have been designed in order to be easily implemented in many Object Oriented
languages and architectures. Implementers are given a large freedom when choosing the preferred
technology, and some technology implementations have been already proposed. However, problems
may arise when trying to connect two or more systems that implement peer interfaces in different
technologies. This section addresses such problems. Please note that as it is by nature intertechnological, the XML messages remain the same whichever technology is used for the peer
interfaces.
As shown in Figure 18 two peers employing the same technology can communicate without any
additional equipment, provided that each can ‘see’ the other on the network.
Peer interface
Same technology
Peer A
Peer B
Embedded XML
Figure 18. Two peers communicating, implementing the same technology.
4
Official copies of RFC 2616, as well as all other RFCs, are at www.rfc-editor.org. Being non copy-restricted
documents, however, RFCs can also be found in many other places, such as the W3C site (www.w3.org).
November 2002
D3.7/2 – page 29/63
Version 2.0
D3.7
However, as shows Figure 19, even two peers that do not employ the same technology can
communicate provided that an appropriate “technology bridge” is set up in between. Such a bridge
migrates the operation postMessage defined in ITridentPeer from technology X to
technology Y, then migrate the response and any resulting exception from technology Y back to
technology X.
Peer interface
Technology X
Peer interface
Technology Y
Bridge
Peer A
Embedded XML
Peer B
Embedded XML
Embedded XML passed
smoothly through the bridge
Figure 19. Two peers communicating, implementing different technologies.A technology bridge is
set up in between.
A third situation is depicted in Figure 20 where Peer A implements ITridentPeer in two
different technology X and Y, thus allowing Peers B and C to communicate without the need for
any bridges.
Peer interface
Technology X
Peer B
Peer A
Embedded XML
Peer C
Peer interface
Technology Y
Figure 20. Peer A offers access in both technology X and Y (no bridges needed).
November 2002
D3.7/2 – page 30/63
Version 2.0
D3.7
6
Operation Layer
6.1
Chapter abstract
The Operation Layer defines the functions that can be activated by Clients and Supplier in order to:
request information, manage subscriptions, produce and handle off-line data deliveries.
As well as the Data Layer, the Operation Layer is implemented directly within the XML message (a
“full-XML” approach, in contrast to previous versions of the TRIDENT System Architecture
specifications).
The Chapter doesn’t concern about specific traffic and travel information requests, which is a
matter of the Data Layer.
6.2
Operation Layer Functions
Here are listed the basic system functions that are currently defined in the Operation Layer.
Operation Layer Functions, activated by Clients
A1. Request information
A2. Register a subscription
A3. List all the registered subscriptions
A4. Drop an existing subscription
A5. Retrieve a copy of an existing subscription
A6. Import a off-line data delivery
Operation Layer Functions, activated by Suppliers
B1. Deliver to a Client travel/traffic information related to a registered subscription
B2. Signal to a Client that one of its registration has been dropped
B3. Produce a off-line data delivery
Functions A1…A5 and B1…B2 are related to the on-line scenario and are implemented by
exchanging XML request and response messages by means of the Transport functions defined in
Chapter 5.
Functions A6 and B3 are related to off-line data production and delivery, and as such they do not
need any TRIDENT-defined transport layer.
It should be noted that Operation Layer Functions are very generic and, in principle, are not limited
to accessing Travel and Traffic information only. Extensibility and is also guaranteed, since
modifications to the internal format of Operation Layer Functions do not affect Transport Layer
Functions and may add further capabilities to the Data Layer.
November 2002
D3.7/2 – page 31/63
Version 2.0
D3.7
6.3
Usage scenarios
As reported in the use-cases of Chapter 2, two usage scenarios can be envisaged: on-line and offline.
•
Two peers interact on-line by exchanging request/response TRIDENT messages;
•
A supplier peer produces a snapshot (static image) of its travel and traffic information and
make it available off-line (on CD, Paper, via FTP, …).
6.3.1
On-line scenario
In the on-line scenario two peers communicate on-line by exchanging TRIDENT messages.
In order to analyse the exchanged messages we must first distinguish between Client-originated and
Supplier-originated communication.
6.3.1.1
Client-originated communication
In the client-originated communication interaction is initiated by the client which sends to the
supplier a Client Request Message. The supplier responds with a single Supplier Response Message.
The XML request/response messages offer a small number of very generic system functions. Client
peers can access the following functions on the supplier:
Client Request message. It can be either:
1. a request for specific (travel/traffic) information, to be returned immediately;
2. a request for a new subscription to be registered on the supplier’s;
3. a request for the list of subscriptions stored on the supplier’s;
4. a request of a copy of a registered subscription;
5. a request of removal of a registered subscription;
Supplier Response message. The response message can contain either an error message, if
something went wrong, or:
1. the requested information;
2. acknowledgement of successful registration of the subscription;
3. the list of subscription stored;
4. a copy of the registered subscription;
5. acknowledgement that the subscription was dropped.
6.3.1.2
Supplier-originated communication
In the supplier-originated communication interaction is initiated by the supplier which sends to the
client a Supplier Request Message. The supplier responds with a single Client Response Message.
Supplier Request message. It can be either:
1. information delivery related to a client subscription;
November 2002
D3.7/2 – page 32/63
Version 2.0
D3.7
2. notification that a client subscription was dropped;
Supplier Response message. The response message can contain either an error message, if
something went wrong, or:
1. acknowledgement that the delivered information has been successfully accepted;
2. acknowledgement that the subscription was dropped
6.3.2
Off-line scenario
In the off-line case a supplier peer produces a snapshot (static image) of its travel and traffic
information and make it available off-line (on CD, Paper, via FTP, …), by using a Delivery
Message.
Delivery Message. Contains a static snapshot of travel and traffic information.
6.4
Message structure
A
TRIDENT
message
is
Trident_Message_Schema.xsd.
an
XML
file/document/stream
based
on
This schema substitutes (obsoletes) the Trident_RR_Schema.xsd for information exchange, which
is based on the previous version of the System Specifications (v1.3 of the TRIDENT Object
Oriented Specifications).
The following sections focus on the basic aspects of the message structure. Full details and
comments on the contents and structure of the XML file will be found in
Trident_Message_Schema.xsd.
6.4.1
Prerequisites
6.4.1.1
PeerId
A PeerId is a character string that uniquely identifies a Peer in the Network.
PeerIds are used, among other things, to identify which is the peer that first created an object.
Due to the absence of a central peer directory at present the uniqueness of a PeerId cannot be
guaranteed by any means on a large scale.
Each Supplier in the Network shall possess an unique PeerId. Clients are not bound to posses it (but
they can).
The PeerId is a string. It shall contain alphanumeric characters only (‘A’..‘Z’, ‘a’..‘z’, ‘0’..‘9’).
The recommendation is that PeerId’s have the following stricture5:
{ISO-3166 country code}_{organisation name}
For example:
FR_RATP
IT_ATAC
5
The ISO-3166 list of country codes is reported in D3.3/C.
November 2002
D3.7/2 – page 33/63
Version 2.0
D3.7
In large organisations many TRIDENT-enabled systems may be established, either for internal data
exchange and/or to allow access to external Clients. Each of the system’s PeerID should identify
both the organisation and the internal subsystem. In these cases, the PeerID should be formatted like
this:
{ISO-3166 country code}_{organisation name}_{subsystem name}
or:
{ISO-3166 country code}_{organisation name}_{department}_{subsystem name}
For example:
FR_RATP_SIPRE
FR_RATP_SIEL
IT_ATAC_PUBLIC
IT_ATAC_INTERNAL
6.4.2
Building blocks
Basic building blocks are present in several/all messages and in various contexts. They are
implemented by means of XML Schema complexTypes.
6.4.2.1
Message Header
Figure 21. Message header (XML diagram)
Contains management data like: peer-Id’s, message-Id’s, message times, authentication parameters
and registration data.
The usefulness of the Message Header and its compliance to user requirements has not been
thoroughly tested yet. Indeed there are far more advanced messaging tools for XML, such as
ebXML (http://www.ebxml.org/), that may prove to be more useful in this context, but that may also
unnecessarily grow the burden of the message. For these reasons the message header is made
optional in every Trident Message – with a strong recommendation to use it.
CreatorId is the PeerId identifier of the Peer that generated the message.
There is no one-to-one relationship between a PeerID and a Login. In fact, a Client can have
different login credentials on different Suppliers, or even on the same Supplier with different
authorisations.
November 2002
D3.7/2 – page 34/63
Version 2.0
D3.7
CreatorAddress is the network address or the message creator. that shall be used by the supplier to
return information to the client: this is especially needed for registered subscriptions, when it is up
to the Supplier to connect back to the Client.
There can be a one-to many relationship between PeerIDs and PeerAddresses.
On the other side, the Supplier does not have to log in into the Client when delivering information
on subcription.
MessageTime is the message creation time, in XML dateTime format. For example:
1994-11-05T08:15:30-05:00
MessageId is the message identifier, produced by the message creator. It shall be unique and have
the following syntax:
{CreatorId }-{unique alphanumeric string }
If this is a response message, RefMessageId shall be set and shall contain the message identifier of
the incoming request message.
6.4.2.2
Peer Identification
Each Client shall be able to provide its authentication credentials when connecting to a Supplier in
order to request some of the available services. Such credentials are represented by instances of the
PeerIdentityType complexType, described in the class diagram in Figure 22.
Figure 22. PeerIdentityType complexType, used for Peer identification.
Login and Password are the login credentials that the Client shows to the Supplier. They identify
which is the amount of information that the Client is entitled to access. Suppliers are supposed to
maintain internally a list of login credentials (Login, Password) associated to the scope of
information available to each of the logins.
The string ‘anonymous’ is a special Login reserved for anonymous access to any supplier, and with
specific (possibly limited) rights of information access. When accessing anonymously, the
Password field is optional. Suppliers may refuse access to anonymous clients.
November 2002
D3.7/2 – page 35/63
Version 2.0
D3.7
6.4.2.3
SubscriptionType
Figure 23. Subscription type (XML diagram)
The SubscriptionType complexType describes a subscription sent by the Client to a Supplier
and registered by the supplier. It is used especially when registering a subscription, but can also be
used for retrieving a stored subscription.
PeerIdentity is the Peer Identification that will be used to authenticate the client.
CreatorAddress is the network address or the message creator. that shall be used by the supplier to
return information to the client: this is especially needed for registered subscriptions, when it is up
to the Supplier to connect back to the Client.
There can be a one-to many relationship between PeerIDs and PeerAddresses.
On the other side, the Supplier does not have to log in into the Client when delivering information
on subcription.
SubscriptionId is the unique identifier of the subscription. When producing a proposal for a
subscription a Client peer shall generate a SubscriptionId that will be submitted to the Supplier and
will be returned back to the Client each time that subscriprion is referenced. It shall have the
following syntax:
November 2002
D3.7/2 – page 36/63
Version 2.0
D3.7
{Client Peer Id }-{unique alphanumeric string }
Example:
FR_RATP_SIEL-0044AZ599
IT_TITOS-B991342
The Client shall make sure that the generated SubscriptionId is effectively unique. The supplier
shall refuse to register a subscription with a repeated SubcriptionId.
DeliverTo is the network address that shall be used by the supplier to return information to the
client. The supplier needs to know this since is up to the Supplier to connect back to the Client.
DeliveryOnOccurrence is an empty tag tells that the information should be delivered to the client as
soon as it is available. DeliveryPeriod indicate that the information must be delivered once as soon
as the subscription is registered and then and then at constant intervals of time specified by the
RequestPeriod field. Please note that “one shot” requests are handled by a specific “get” operation
and do not require any subscription to be registered. DeliveryOnOccurrence and DeliveryPeriod
cannot be present at the same time.
RequestValidity is the time interval when the subscription remains valid. ValidityStart and
ValidityStop times are indicated in XML dateTime format. If Validity is not present, then it is
assumed that the subscription is always valid.
InformationRequest is the actual information request. Next chapter will focus on the format of this
field.
November 2002
D3.7/2 – page 37/63
Version 2.0
D3.7
6.5
Messages
6.5.1
On-line, client-originated communication
6.5.1.1
Client Request Message
Figure 24. Client request message (XML diagram)
This is the message sent by a Client to a Supplier in order to request an operation to be performed.
November 2002
D3.7/2 – page 38/63
Version 2.0
D3.7
6.5.1.2
Supplier Response Message
Figure 25. Supplier response message (XML diagram)
This is the response message to a ClientRequestMessage. It is produced by the supplier with the
results of the requested operation.
November 2002
D3.7/2 – page 39/63
Version 2.0
D3.7
6.5.2
On-line, supplier-originated communication
6.5.2.1
Supplier Request Message
Figure 26. Supplier request message (XML diagram)
This is the request message sent by a Supplier to a Client in order to request an operation to be
performed.
November 2002
D3.7/2 – page 40/63
Version 2.0
D3.7
6.5.2.2
Client Response Message
Figure 27. Client response message (XML diagram)
This is the response message to a SupplierRequestMessage. It is produced by the client with the
results of the requested operation.
6.5.3
Off-line, delivery message
Figure 28. Delivery message (XML diagram)
This is the message produced by a Supplier when generating off-line bulk data.
November 2002
D3.7/2 – page 41/63
Version 2.0
D3.7
6.6
Implementation of Operation Layer Functions
This section explains how basic system functions are produced by means of the messages
described.
6.6.1
Get information (A1)
This is the actual on-demand information. By means of this operation the client can request for
specific information to be produced and returned in the response message.
Request Message
An istance of TridentClientRequest, specifying the “Get” tag and indicating the requested
information in the “InformationRequest” tag. Further information in the contents of
InformationRequest tag will be given in the next Chapter.
Response message
An istance of TridentSupplierResponse message.
If an error resulted, the ResultError tag is filled with information about the reason of the error.
If no matching information was available then the ResultNoInfo tag is produced.
Otherwise, on success, information was available and the ResultOk tag is produced with the “Get”
tag containing the requested InformationDelivery.
6.6.2
Register subscription (A2)
By means of this operation the client can register a subscription on the supplier’s.
Request Message
An istance of TridentClientRequest, specifying the “Register” tag and indicating the parameters of
the subscription in the Subscription tag.
Please note that SubscriptionId is assigned by the Client at this stage, and should be unique for that
client in order for the subscription to be accepted.
Response message
If no matching information was available (the Supplier hasn’t that information, neither it is
supposed to have in the future) then the ResultNoInfo tag is produced.
Otherwise, on success, an empty ResultOk tag is produced.
6.6.3
List active subscriptions (A3)
By means of this operation the client can retrieve the list of its subscriptions stored on the Supplier.
Request Message
An istance of TridentClientRequest, specifying the “ListSubscriptions” tag.
November 2002
D3.7/2 – page 42/63
Version 2.0
D3.7
Response message
If no matching information was available (the Supplier hasn’t that information, neither it is
supposed to have in the future) then the ResultNoInfo tag is produced.
Otherwise, on success, a ResultOk tag with a filled ListSubscriptions tag is produced.
6.6.4
Get a subscription (A4)
By means of this operation the client can retrieve a copy of a subscription that it previously
registered on the Supplier.
Request Message
An istance of TridentClientRequest, specifying the “GetSubscription” tag which indicates the
SubscriptionId of the subscription to be retrieved.
Response message
If no matching information was available (the Supplier doesn’t have such a subscription registers)
then the ResultNoInfo tag is produced.
Otherwise, on success, a ResultOk tag with a filled GetSubscription tag is produced.
6.6.5
Drop a subscription (A5)
By means of this request a Client can request that one of its subscriptions is dropped.
Request Message
An istance of TridentClientRequest, specifying the “DropSubscription” tag which indicates the
SubscriptionId of the subscription to be dropped.
Response message
If no matching information was available (the Supplier doesn’t have such a subscription registers)
then the ResultNoInfo tag is produced.
6.6.6
Notify that a subscription was dropped by the supplier (B1)
By means of this request a Supplier can notify the client that one of its subscriptions was dropped.
Request Message
November 2002
D3.7/2 – page 43/63
Version 2.0
D3.7
An istance of TridentSupplierRequest specifying the “NotifySubscriptionDropped” tag and the
SubscriptionId of the subscription that was dropped and, optionally, the reason why it was dropped.
Response message
An istance of TridentClientResponse message.
6.6.7
Deliver information related to a subscription (B2)
By means of this request a Supplier can provide to a Client a information delivery related to one of
the registered subscriptions.
Request Message
An istance of TridentSupplierRequest specifying the “SubscriptionDelivery” tag which contains the
information delivery and the SubscriptionId to which they are related.
Response message
An istance of TridentClientResponse message.
6.6.8
Generate off-line delivery (B3/A6)
The Supplier can produce off-line bulk static data by generating a XML file/stream out of the
TridentDelivery root element.
The resulting XML will contain the produced off-line traffic/travel information within the Delivery
tag.
The Client can then import off-line the resulting XML stream.
November 2002
D3.7/2 – page 44/63
Version 2.0
D3.7
7
Data Layer
7.1
Chapter abstract
The Data Layer defines the actual information requests and deliveries related to the Traffic and
Travel domain produced by Clients and information deliveries produced by Suppliers. Data Layer
Functions are implemented directly within the XML message, as well as the Operation Layer
Functions.
This Chapter presents a detailed definition for the structure of each specific request and of the
related information delivery.
Once more, this layer presents a separation between the “envelope” of information requests and
information deliveries and the actual travel and traffic data representation. This document focuses
on the former, while the latter is described in the TRIDENT Data Model, Data Dictionary and XML
Schema.
The TRIDENT Data Model define the logical structure of the data, whereas the TRIDENT XML
schema defines its physical representation under the form of XML tags. Data model and XML
schema are parts D3.7/3 and D3.7/4 of this same deliverable.
7.2
Handling Data Model objects
XML messages encapsulate actual information: objects that are instances of classes described in the
TRIDENT Data Model. While the data model structure is in principle independent from any actual
representation, when we come to the problem of ‘sharing’ specific data model objects between
(possibly) many peers, a number of requirements have to be imposed on each object in the data
model.
7.2.1
Root class for persistent data model objects
Each persistent data model class shall be derived from the TridentObject abstract class. Figure
29 shows the UML diagram of the TridentObject class.
November 2002
D3.7/2 – page 45/63
Version 2.0
D3.7
+ObjectValidityPeriod
TridentObject
«datatype»
Data Types::TimePeriod
0..1
+CreatorID : String
+ObjectID : String
+ObjectVersion : Integer
+CreationTime : DateTime
+ExpiryTime : DateTime
{Not both}
+ObjectValidityDomain
1
«datatype»
Data Types::String
0..1
Figure 29. The TridentObject class and the ObjectValidity class (UML class diagram).
7.2.1.1
Main rules
Each data model object shall have a (TRIDENT specific) ObjectID and a progressive
ObjectVersion (a progressive integer). The (ObjectID, ObjectVersion) pair shall be generated by the
supplier in an unique way, under the sole requirements that:
•
If two objects have the same ObjectID they must be instances of the same class.
•
If two objects have the same ObjectID and ObjectVersion they must have the same content.
7.2.1.2
ObjectId
Since the ObjectId shall be unique among all peers a rule for the generation of the ID is proposed.
The rule is the following:
{PeerId}:{Class name}:{Progressive integer}
For example:
IT_ATAC:Line:9987
FR_RATP_SIEL:PTSituation:12332
7.2.1.3
Object Creator, Creation time and Expiry time
The peer that generates an object shall initialise the CreatorID attribute of the object with its own
PeerID. It shall also fill in the CreationTime and the ExpiryTime attributes.
7.2.1.4
Object version
The version of an object is reported in the ObjectVersion object attribute.
The first version of an object shall be 1, and shall be incremented by 1 for each new version.
Subsequent versions of the same object should reproduce variations in the object content, due to
new information that was made available from the instantiation of the first object.
The creation of a new instance of an object with a newer version is required only if changes occur
in the object itself, not in its children. It is to be noted, however, that the addition or the removal of
a children of the object may result in changes in the object itself.
November 2002
D3.7/2 – page 46/63
Version 2.0
D3.7
For example, if an ‘Event’ is added to a ‘Situation’ then a new version of the situation must be
generated. However if an event changes internally there is no need for a new version of the
situation.
7.2.1.5
Object validity
The object validity is the time domain when the informative content of the object can be considered
valid. An object validity can be described in either of (but not both) the following ways:
•
One ObjectValidityPeriod (a TimePeriod)
This is ok for objects that have very simple simple object validity domains, such as “from Jan 1st,
th
2002 10:00:00 to Feb 4 2002 23:59:59”.
•
One ObjectValidityDomain (a String). The syntax of the string is defined in the GDF
Specifications, “A1.1, Syntax from time domains.”
There are objects that can be active in very complex time domains, i.e. "Every day from 9am to
1pm", "From 19:30 to 22:00 every Friday in March", …. The GDF standard committee developed a
very powerful and compact language for coding such domains into text strings. For example, "Last
5 minutes before New Year 1992" is coded as “[(y1992){-m5}]”.
This richness of expression has of course a drawback, that is the much more complex algorithm
needed to determine whether a specific instant in time is within or without the time domain.
7.2.1.6
ObjectReference Class
The ObjectReference class contains the full reference to a specific object. It can be used as a
parameter in request when referring to an object that is already existing on the supplier’s side.
The ObjectVersion attribute is optional. It shall not be specified when referring to a nonspecified
version of the object.
ObjectReference
+ObjectID[1] : String
+ObjectVersion[0..1] : String
Figure 30. The ObjectReference class (UML class diagram)
7.2.2
Operational behaviour
Most Peers will store and handle information internally in a proprietary, hidden format – an
‘internal format’. These specifications are not concerned with the ‘internal format’: it is very likely
that there will be a TRIDENT-specific interface that will convert from and to the ‘internal format’
requests and responses in the ‘TRIDENT format’.
Due to the variety of ‘internal format’s actual objects may only exist at the interface level. They
may not have an immediate correspondence in the ‘internal format’. They may even exist only as
temporary objects for the time required for composing, exchanging and decoding the information.
This section discusses the requirements of the systems in order to effectively exchange information
represented under the form of objects.
November 2002
D3.7/2 – page 47/63
Version 2.0
D3.7
7.2.2.1
The Supplier side: generation of identifiers and versions
When composing responses in order to produce the information requested the supplier faces the
problem of instantiating objects. This is the time when (ObjectID, ObjectVersion) pairs, and
possibly ObjectValidity, are generated.
A supplier must remember the identifiers and the structure of all objects that it has generated, in
order to:
•
Reproduce it again with the same pair in case it is instantiated once more;
•
Be able to remember which was the object produced, if this is referred in a subsequent
request.
7.3
Requests and Deliveries
This version of the System Specifications defines specific syntaxes for the following Requests and
the related Deliveries.
Category
Request type
Code
Meaning
General
Specific object
Object
Return a specific object given its
identification parameters
Object children
ObjectChildren
Return all or part of the children
of an object.
Calculation of
itinerary
ItineraryCalculation Calculate and return an itinerary
between an origin and a
destination (and possibly via
points).
Network list
ListOfNetworks
Return the list of networks for
which the supplier has got
information.
Situations
Situations
Return events on the road
network or on the PT network.
Traffic data
measurement points
TrafficDataMeasurementPoints
Return the road traffic
measurement points
Road traffic data
(traffic measurements)
RoadTrafficData
Return the real-time road traffic
data (traffic measurements).
PTStopPoints
Return the list of PT stops near a
given location.
PT status
PTStatus
Return the current status of the
PT network.
PT timetable
PTTimetable
Return the entire timetable of the
public transport.
Road Traffic
Public Transport PT stops
November 2002
D3.7/2 – page 48/63
Version 2.0
D3.7
The names is Delivery rather than Response since information with the same structure is distributed
not only in response messages but also in delivery messages. In general, the request of code
‘XXXX’ and the related delivery are described by a couple of tags: XXXXRequest and
XXXXDelivery.
In the XML, information requests and responses are represented respectively by tag instances of
two complexTypes: InformationRequestType and InformationDeliveryType.
Figure 31. Information request (XML diagram)
November 2002
D3.7/2 – page 49/63
Version 2.0
D3.7
Figure 32. Information delivery (XML diagram)
November 2002
D3.7/2 – page 50/63
Version 2.0
D3.7
7.3.1
Specific object
7.3.1.1
Request
Figure 33. Specific object request (XML diagram)
WhichObject: a reference to the requested object
7.3.1.2
Delivery
Figure 34. Specific object delivery (XML diagram)
It contains one or more matching objects found.
November 2002
D3.7/2 – page 51/63
Version 2.0
D3.7
7.3.2
Children of an object
7.3.2.1
Request
Figure 35. Children of an object request (XML diagram)
WhichObject: a reference to the parent of the requested object(s);
ObjectChildren: a particular filter that applies to (some of) the possible children of an object and
tells which particular children of the base object are to be returned. Permissible values are:
“allchildren”
All the children of TheObject
“network_line”
TheObject references a Network object, Lines are requested.
“network_route”
TheObject references a Network object, Routes are
requested.
“network_stoparea”
TheObject references a Network object, StopAreas are
requested.
“network_ptaccesslink”
TheObject references a Network object, PTAccessLinks are
requested.
“network_nonptaccesslink”
TheObject references a Network object, NonPTAccessLinks
are requested.
“network_connectionlink”
TheObject references a Network object, ConnectionLinks
are requested.
“line_route”
TheObject references a Line object, Routes for that line are
requested.
“route_stopopoint”
TheObject references a Ruote object, StopPoints on the
Route are requested.
WholeObjectTree: tells whether to download the matching objects only (value ‘false’) or the whole
tree of objects below them (value ‘true’)
November 2002
D3.7/2 – page 52/63
Version 2.0
D3.7
7.3.2.2
Delivery
Figure 36. Children of an object delivery (XML diagram)
Contains a set of objects matching a ObjectChildrenRequest.
November 2002
D3.7/2 – page 53/63
Version 2.0
D3.7
7.3.3
Itinerary calculation
7.3.3.1
Request
Figure 37. Itinerary calculation request (XML diagram)
Origin: travel origin;
Via: possible intermediate points of the itinerary;
Destination: travel destination;
TravellerDepartureTime, TravellerArrivalTime: desired arrival or departure time. Either must be
specified, but not both;
ItineraryType: the type of itinerary requested. Permissible values are:
private_only use private car
public_only
use public transport and walking
intermodal
use both private car, walking and public transport
OptimisationType: the type of optimisation desired. Permissible values are:
min_travel_duration Minimise travel duration
min_travel_distance Minimise length of travel
min_walking_duration
Minimise walking duration
November 2002
D3.7/2 – page 54/63
Version 2.0
D3.7
min_num_of_transfers
min_travel_cost
Minimise number of switches between different vehicles
Minimise the overall cost of the travel
ItineraryDetailLever: the desired itinerary detail level for the description of the itinerary.
Permissible values are:
high_detail
Many details (long description of the itinerary)
low_detail
Few details (short description of itinerary)
The corresponding delivery will report the calculated itinerary or any error encountered in the
process of the calculation.
7.3.3.2
Delivery
Figure 38. Itinerary calculation delivery (XML diagram)
The response is an instance of the ResponseItinerary class that reports the calculated itinerary or
any error encountered in the process of the calculation.
•
ItineraryResult: tells whether the itinerary was found or not
1 : itinerary_found
The itinerary was found
100 : itinerary_not_found
The itinerary was not found
November 2002
D3.7/2 – page 55/63
Version 2.0
D3.7
7.3.4
Situation and Situation elements
7.3.4.1
Request
Figure 39. Situation request (XML diagram)
The request is an instance of the RequestSituations class it references a number of filters that
indicate the scope of events that must be supplied.
•
WhichNetwork: a reference to the specific (Road or PT) Network for which the supplier has
information about. It can be a reference to a road network or a private transport network.
•
Phrase: the list of phrases that the elements involved in the situation should match.
•
WhichLogicalLocations: references to logical locations on the network ‘where’ the situation
element are active (for example, reference to a specific Line on a public transport Network)
•
WhichLocations: references to geographical locations on the network where the situation
elements are active
The related delivery will envelop those situations containing situation elements that match one or
more of the filters in the request. In order for a situation element to satisfy one of the filters:
•
it must affect the specified Network
•
it must be ‘at’ or ‘within’ the specified physical or logical locations
•
its associated phrase must be in the list of Phrases
If more sophisticated and/or client-tailored filtering is required, consider using the ‘catalogue’
approach as described in the corresponding use-case in Chapter 2.
November 2002
D3.7/2 – page 56/63
Version 2.0
D3.7
7.3.4.2
Delivery
Figure 40. Situation (XML diagram)
A list of situations.
November 2002
D3.7/2 – page 57/63
Version 2.0
D3.7
7.3.5
Network list
7.3.5.1
Request
Figure 41. List of networks request (XML diagram)
An empty request.
7.3.5.2
Delivery
Figure 42. List of networks delivery (XML diagram)
Contains a list of references to the networks handled by the Supplier.
November 2002
D3.7/2 – page 58/63
Version 2.0
D3.7
7.3.6
List of Traffic Data Measurement Points
7.3.6.1
Request
Figure 43. List of traffic data measurement points request (XML diagram)
WhichNetwork references the specific road traffic network handled by the supplier.
Where is a set of locations in order to filter the position of the requested measurement points.
7.3.6.2
Delivery
Figure 44. List of traffic data measurement points delivery (XML diagram)
Contains a list of Traffic Data Measurement Points.
November 2002
D3.7/2 – page 59/63
Version 2.0
D3.7
7.3.7
Road Traffic Data
7.3.7.1
Request
Figure 45. Road traffic data request (XML diagram)
WhichNetwork references the specific road traffic network handled by the supplier.
WhichMeasurementPoints is a set of references to traffic data measurement points for which traffic
data is to be returned.
7.3.7.2
Delivery
Figure 46. Road traffic data delivery (XML diagram)
Contains the delivered traffic data.
November 2002
D3.7/2 – page 60/63
Version 2.0
D3.7
7.3.8
Stop points
7.3.8.1
Request
Figure 47. Stop Point request (XML diagram)
WhichNetwork references the specific PT network handled by the supplier.
Point and Radius are, respectively, the center point and the radius of a circle within which stop
points will be searched. If either is not specified then all the stop points in the network will be
returned.
7.3.8.2
Delivery
Figure 48. Stop Points delivery (XML diagram)
Contains a list of Public Transport stop points.
November 2002
D3.7/2 – page 61/63
Version 2.0
D3.7
7.3.9
Timetable
7.3.9.1
Request
Figure 49. Timetable request (XML diagram)
WhichLine and WhichStopPoints references one/some specific lines or stop points for which PT
Timetable is requested.
7.3.9.2
Delivery
Figure 50. Timetable delivery (XML diagram)
Contains the delivered timetable.
November 2002
D3.7/2 – page 62/63
Version 2.0
D3.7
7.3.10
Public Transport Status
7.3.10.1 Request
Figure 51. PT Status request (XML diagram)
WhichLine and WhichStopPoints references one/some specific lines or stop points for which PT
Status is requested.
7.3.10.2 Delivery
Figure 52. PT Status delivery (XML diagram)
Contains the delivered PT status.
November 2002
D3.7/2 – page 63/63
Version 2.0
TRIDENT DM v2.02
TRIDENT Traffic and Traveller Data Exchange Specification
TRIDENT
D3.7/3 - Logical Data Model
Version 2
11/10/2002
Produced by:
TRIDENT Consortium
October 2002
D3.3/3 – page 1
Version 2.0
TRIDENT DM v2.02
Activity name:
TRIDENT
Work area:
WP 3
Document title:
Draft specifications for the Object Oriented
approach
Document number:
D3.7/3 - Logical Data Model
E:\MVA\Projects\C30776\TRIDENT WPs\WP3 - System Specifications\3
- Specifications for the OO based approach\3 - Logical Data Model\D3.7 3 v2_0_2.doc
Jason Kelland
Other author(s):
Jonathan Booth
Version history
Version
1.0
1.2
1.3a
1.3b
1.3 final
2.0
Date
14/08/2001
12/10/2001
14/12/2001
28/12/2002
16/04/2002
11/10/2002
Main author
Jonathan Booth
Jonathan Booth
Jason Kelland
Jason Kelland
Jason Kelland
Jason Kelland
Summary of changes
Minor Consistency changes
Major Changes from Change Request Process
Changes after consortium review
Major release
Post Launch Release
Circulation:
Recipient
TRIDENT Consortium
Date of submission
14/10/2002
October 2002
D3.3/3 – page 2
Version 2.0
TRIDENT DM v2.02
Foreword
This document (TRIDENT D3.7/3) is an integral part of the TRIDENT Object Oriented
Specifications Suite, which is composed by the following seven documents:
D3.7/4. XML DTD and Schema
Annex A. Multimodal Traffic and Travel Data dictionary
Annex B. Location Referencing
Annex C. Appendices
These documents were produced by the TRIDENT Task Force on the Object Oriented approach,
established within the EU TRIDENT project, between December 2001 and November 2002.
The information contained into this document may be superseded by a corresponding document in
TRIDENT Deliverable D3.5 once the project’s Test Sites have produced their feedback, on a time
scale of one and a half years.
mechanism for inter-modal traffic and travel information encompassing public transport, road
Centres (TIC), Public Transport operator centres, Roads and Public Transport Authorities, and
Service Providers. This standard is denoted as TRIDENT.
This document aims to provide a logical data model describing an Object Oriented Data Model of
the data to be exchanged in the TRIDENT test sites. The Data Model encompasses Road Traffic,
Public Transport and inter-modal facilities.
The Data Model is described as a set of static UML diagrams. The structure of the Data Model is
the result of a coherent union of existing data models in the Road Traffic domain (mainly DATEX)
and in the Public Transport domain (TRANSMODEL). A large part of the Data Model is the result
of original work within the TRIDENT consortium.
The level, style and content of this document was chosen in order to be readily understood by
technical readers skilled in Data Modelling and UML. A comprehensive knowledge of the UML
notation syntax is required in order to correctly understand the UML diagrams presented. A fair
background on the issues that are typical in the ITS domain is welcome.
October 2002
D3.3/3 – page 3
Version 2.0
TRIDENT DM v2.02
The contents of this document have been developed from an analysis of 3 main sources:
•
list of system and user requirements developed throughout Work package 2 of the TRIDENT
project, summarised in TRIDENT deliverable D2.5;
•
a series of workshops undertaken during April and November 2000;
•
related documents and related EU and non-EU projects.
October 2002
D3.3/3 – page 4
Version 2.0
TRIDENT DM v2.02
Table of Contents
Foreword...........................................................................................................................................3
Purpose of the specifications ..........................................................................................................3
Purpose of this document ...............................................................................................................3
1
Introduction..............................................................................................................................7
1.1 Chapter abstract......................................................................................................................7
1.2 Scope of the Data Model........................................................................................................7
2
Introduction to Unified Modelling Language........................................................................8
2.1 The Language .........................................................................................................................8
2.2 Objects ...................................................................................................................................8
3
2.2.1
Packages.........................................................................................................................9
2.2.2
Object Name ..................................................................................................................9
2.2.3
Object Attributes............................................................................................................9
2.2.4
Relationships ................................................................................................................10
2.2.5
Reading the model .......................................................................................................13
The Data Model......................................................................................................................14
3.1 Overview ..............................................................................................................................14
3.2 Limitations and General Information on the Model ............................................................15
3.3 Global Package ....................................................................................................................16
3.3.1
General Objects............................................................................................................16
3.3.2
Consequence General Objects .....................................................................................17
3.3.3
TrafficData General Objects ........................................................................................18
3.4 Data Type Package ...............................................................................................................18
3.4.1
Generic Data Types......................................................................................................18
3.4.2
PT Enumerated Data Types .........................................................................................19
3.4.3
Road Traffic Data Types..............................................................................................20
3.5 Location Package .................................................................................................................21
3.5.1
Network (Road and PT) ...............................................................................................21
3.5.2
Public Transport Topology ..........................................................................................22
3.5.3
General Link ................................................................................................................23
October 2002
D3.3/3 – page 5
Version 2.0
TRIDENT DM v2.02
3.5.4
Location .......................................................................................................................23
3.5.5
Point and Point Types ..................................................................................................24
3.5.6
Alert C Locations .........................................................................................................26
3.6 PT Package ...........................................................................................................................27
3.6.1
Timetables (Point and Line).........................................................................................27
3.6.2
Registration (Generic)..................................................................................................28
3.6.3
Status – Individual Vehicles ........................................................................................29
3.6.4
Status – Multiple Vehicles ...........................................................................................30
3.7 Trip Package ........................................................................................................................31
3.7.1
Trip Time .....................................................................................................................31
3.7.2
Itinerary........................................................................................................................32
3.8 Traffic Data ..........................................................................................................................33
3.8.1
Traffic data, using the Traffic Data Measurement Point Technique ............................33
3.8.2
Traffic Data Measurement Point Definition ................................................................34
3.8.3
Traffic Data Measurement Point Values........................ Error! Bookmark not defined.
3.8.4
Traffic Data Measurement Point – Individual Vehicle Data .......................................34
3.8.5
Traffic Data Measurement Point – Calculated Travel Time........................................35
3.9 Situations ..............................................................................................................................36
4
3.9.1
Situation and Situation Element ...................................................................................36
3.9.2
Road Maintenance (DATEX – RMT)..........................................................................37
3.9.3
Incident (DATEX – INC) ............................................................................................37
3.9.4
Accident (DATEX – ACC)..........................................................................................38
3.9.5
Public Transport Incident.............................................................................................38
3.9.6
Consequence ................................................................................................................39
Examples of Usage of the Data Model..................................................................................40
4.1 Chapter abstract....................................................................................................................40
4.2 Examples ..............................................................................................................................40
4.2.1
Example: Itinerary........................................................................................................40
4.2.2
Example: Public transport point timetable...................................................................42
4.2.3
Example: Public transport line timetable .....................................................................44
October 2002
D3.3/3 – page 6
Version 2.0
TRIDENT DM v2.02
1 Introduction
1.1 Chapter abstract
This Chapter introduces a model of the data to be exchanged within the TRIDENT test sites. This
data model has been defined using UML notation, and is closely linked to the TRIDENT Data
Dictionary.
1.2 Scope of the Data Model
The TRIDENT Data Model aims to model a common set of data that will provide beneficial when
exchanged between users. The scope of potential data to be exchanged in the transport domain is
large and beyond the scope of a single data model. The TRIDENT Data Model therefore is limited
to supporting essential data exchange for specific identified applications and data sets.
The Data Model is described as a set of static UML diagrams. The structure of the Data Model is
the result of a coherent union of existing data models in the Road Traffic domain (mainly DATEX)
and in the Public Transport domain (TRANSMODEL). A large part of the Data Model is the result
of original work within the TRIDENT consortium.
Further data sets will be added at a later stage of development. The Data Model has been designed,
as much as possible, to be flexible and extensible to accommodate future extensions.
Application data sets model to date include:
•
Basic transport network modelling (logical and topological modelling for the road and public
transport network);
•
Public transport timetables;
•
Public transport status information;
•
Public transport situation/event information;
•
Itineraries;
•
A limited set of road traffic situation/event information
The initial focus of the development of this Data Model has been to provide a test set of data to
prove the approach, application and implementation. The granularity of data within the Data Model
is provided at a level suitable to support data exchange, which in turn supports end-user information
services. The requirements for internal operational and management data exchange may require a
more detailed level of granularity than can be found in this Data Model, at the present time.
October 2002
D3.3/3 – page 7
Version 2.0
TRIDENT DM v2.02
2 Introduction to Unified Modelling Language
2.1 The Language
Unified Modelling Language (UML) is the result of several leading methodologies combined. The
model has been developed using the UML v1.3, however v2.0 of the UML specification has been
released. We intend in future TRIDENT versions to update any inconsistencies between these
versions. Further information can be found at http://www.rational.com/uml or www.omg.com/uml.
Within TRIDENT, we have used the methodology best described as Static or Class Diagrams to
describe the specification. This object model is in turn described further using a reciprocal set of
XML schemas.
We do expect that this model will form the foundation for all future TRIDENT versions, and the
model may be progressed to more advanced toolsets, such as Rational or Embarcadero, for the
development of complex software systems.
The XML schemas are not mapped exactly to the model; in order to aid navigation in building the
XML messages. Where this has been done, for example between PTStatus and
VehicleJourneyAtStopRealTime, explanation has been given in the appropriate schema.
The following explanations are not intended to be a tutorial on UML or object oriented modelling,
but more an overview of how the consortium has used UML to aid in the development of the
specification.
A prior knowledge of object modelling should not be required before reading this document,
however for advanced readers, the models contained herein are descriptive and not meant for the
basis of advanced software engineering.
2.2 Naming Conventions
TRIDENT uses the well-known camel case naming convention. All objects use Upper Camel Case
(UCC), with all words capitalised and no separators between words. All attributes user Lower
Camel Case, with all words capitalised, except the first word, and no separators between words.
October 2002
D3.3/3 – page 8
Version 2.0
TRIDENT DM v2.02
2.3 Objects
The diagram below represents the building block of a UML based data model.
2.3.1 Packages
In the traditional sense, packages are used to do logical grouping, and are used in UML for a
number of code level purposes. In TRIDENT, we have used packages for a non-traditional sense,
i.e. to group objects into common business domains. There is no program level sense in the way the
objects have been packaged. The XML schemas follow the logical packaging of these objects.
2.3.2 Object Name
The name of an object is for descriptive purposes, and is unique within the package it is contained
(explained in more detail under packages). The name will describe what the object is or what its
intention is. For example, an object describing a public transport network would be named
‘PublicTransportNetwork’.
2.3.3 Object Attributes
Attributes are used to define characteristics to objects, by allowing them to hold specific
information. It is these attributes that start to define the rules about how data is structured within
any proposed system. An attribute is broken down into 3 parts, the name, multiplicity and data type.
Every attribute requires a unique name within its object. It can be the same name as an attribute in
another object, but then usually it should have the same meaning. In TRIDENT the naming
convention follows that of the Object Naming. For ease of reading, where a name is the same as
another attribute name in another object, it is assumed that these mean the same. For example the
name Direction in the object Route means the same as Direction on the object BusStopPoint. It is
unnecessary to name them RouteDirection and BusStopPointDirection, as the meaning and
intention are the same. This rule follows throughout the Data Model.
The multiplicity rule allows us to set the number of occurrences of an attribute within an instance of
that object. There are various multiplicity rules, the main ones being:
October 2002
D3.3/3 – page 9
Version 2.0
TRIDENT DM v2.02
[1] – One instance of this attribute must exist (Mandatory)
[0..1] – Zero or One instance of the attribute may exist (Optional)
[1..*] – One or more instances may exist (Mandatory)
[0..*] – Zero or more instances may exist (Optional)
The data type element of an attribute defines the rules around the structure of the data input. There
are various data type groupings which have been created in TRIDENT, all of which have been
represented upfront under the Data Types package.
The basic data types used are very general. The reason being that TRIDENT is language
independent. Various languages use different data types when describing their data, and so in order
to avoid bias or confusion, generic data types are used. These would be String, Integer and so forth.
Enumerations have been used in great depth whilst constructing the data model, and these are
supported in UML through the use of an enumeration stereotype when building a new data type.
This has allowed TRIDENT to create data types specific to the Transportation Industry, setting
rules on the permissible values. These new data types have been further broken down into PT
Enumerations and Traffic Enumerations.
The above example shows the object Line, within the package Location. The attribute
TransportModeName (which is an optional attribute of 0..1), has an enumerated data type of
TransportModeName. The permissible values for this enumeration can be found in the DataTypes
package. When looking at the TransportModeName data type, there are numeric values with
explanations on their meaning on the right hand side of the equals sign. The use of numerals in
enumerations allows industries to send small coded messages, without having the need for long,
sometimes complicated names. As long as all participants in the messaging use the same Data
Dictionary and messaging versions, there should be a common understanding.
2.3.4 Relationships
Relationships, define the rules between objects in the Data Model, and determine the fashion in
which they relate to each other. A brief outline and meaning of the relationships are given here;
however for detail please use the references given earlier. The following diagram depicts the four
relationship types, which are further described in order thereafter.
October 2002
D3.3/3 – page 10
Version 2.0
TRIDENT DM v2.02
2.3.4.1 Association
The weakest and most simple relationship type, this relationship ‘associates’ two objects to each
other, and describes the rules to that relationship. In the above example, the two objects, Company
and Person are associated. They can exist separately and in different circumstances and so the
relationship is said to be weak, and is thus an association. The relationship states that the Company
is the ‘employer’ and the Person is the ‘employee’. A company ‘being the Employer’, can employ
1or more people, ‘employees’. An ‘employee’ may have only one ‘employer’.
2.3.4.2 Composition
A composition is the strongest form of relationships, and describes a whole/part ownership between
the objects. This means that one of the objects is the whole and the other object the part. The whole
object effectively owns the part object. If the whole object were to be destroyed, the part object
would be destroyed with it. In real terms, there would be no use for the part object should the whole
object not exist.
In the above example of an order and invoice, although invoices exist on their own, there would be
no use for them, should an order not exist. In modelling terms, this relates to strong ownership of
the invoice object, by the order object. The whole object (order), being the owner is connected to
the relationship through a solid diamond. The relationship can be named (although not necessary if
the relationship is self-explanatory). In this case we have said that the invoice for an order is the
‘OrderInvoice’. Once again the relationship contains multiplicity, where one order may have 1 or
many invoices (mandatory), and an invoice may have only one order.
In advanced modelling, Navigability may be required. This proponent of UML has not been used in
TRIDENT, although this may be added in future versions to aid understanding. Navigability
displays the direction of awareness between objects. In this example, an order knows about the
Invoice but not vice versa. The arrow ‘pointing’ in the direction of the invoice depicts this.
October 2002
D3.3/3 – page 11
Version 2.0
TRIDENT DM v2.02
2.3.4.3 Aggregation
Aggregation or sharing is the weaker form of composition and the rules of this relationship are the
same, save for the level of ownership. It is also a whole/part relationship, depicted by a white/clear
diamond on the side of the owner. Being a weaker relationship, this suggests that the part may exist
even if the whole does not, but the relationship is stronger than an association. If unsure of the level
of ownership, many modellers leave this out, and just use association. Where possible all
aggregations and compositions have been modelled.
In the example, a car is shown to have an aggregated relationship with an engine. This means that a
car can have zero or one engine (optional), but the engine can exist on its own, even if the car does
not exist. As you can see this level of relationship holds plenty of ‘ifs’ and ‘buts’, and so unless
very clear of intentions, many modellers just use composition and association.
2.3.4.4 Generalisation
Generalisation or Inheritance is the most widely used and understood of the relationships, and its
use is unambiguous. A general object is modelled, and to avoid repetition, specific objects inherit
from the parent object and add their own detail.
In the above example, an animal object is shown, with very generic attributes. All animals for
example, have a name. Although this can actually be modelled differently, for the sake of this
simple system, we have two specific objects deriving details from the animal object, being the bird
and cat objects. These two objects hold details very specific to the class of animal they would like
to describe, however, without the need to both hold the attribute name. The benefits of using
inheritance are many, including, non-repetition, declare once-use many, tighter control over
changes and so forth. This relationship has been used extensively within TRIDENT.
October 2002
D3.3/3 – page 12
Version 2.0
TRIDENT DM v2.02
2.3.5 Reading the model
The Data Model has been built using the rules and constructs explained in this section. Although
there are many more rules and constructs to modelling, to avoid complication these have not been
used. The modelling starts with definitions and data types, introducing the reader to the basic
fundamentals on which TRIDENT is built. These are contained within the Global Package.
Definitions are stated upfront, and contain groups of related objects, which are used often in many
parts of the specification. This is to avoid confusion and cluttering of complex diagrams. The
strongest example of this would be the UnitisedQuantity object.
All data types are also defined upfront, and enumeration values are displayed in the appropriate
model. For full explanations of any object, attribute, data type or enumeration values the
appropriate explanation is contained in the Data Dictionary.
The first half of the DM is on Public Transport (PT), and works progressively through concepts,
introducing base models, and then adding on increasing complexity to cater for real time messages
to be constructed. Base models would include PT Topology (Public Transport Topology), Network,
Point, Location, and so forth. Abstracted/detailed models are then presented, which among others
include, Timetables, Itineraries, and Public Transport Status. It is thus necessary to become
acquainted with the basic knowledge first and to then move onto the more complicated models.
The second half of the model concentrates on the Object Oriented modelling of Road Traffic, the
primary source of which was DATEX. Core concepts are introduced upfront, and increasingly
complex models then ensue, building upon the concepts being introduced.
A reasonable level of transportation knowledge is required, specifically in interpreting the Road
Traffic models.
Furthermore, in this Data Model, all base objects inherent (generalisation relationship) from the
super class TridentObject as defined in D3.3/2.
October 2002
D3.3/3 – page 13
Version 2.0
TRIDENT DM v2.02
3 The Data Model
3.1 Overview
The Data Model has been modelled into the following packages, to aid in navigation and
readability:
•
Global {Global Package};
•
Data Types {DataTypes Package};
•
Location and Topology {Location Package};
•
Timetables, Service Registration and PT Status {PT Package};
•
Trip Time and Itinerary {Trip Package}
•
Traffic Data {TrafficData Package}; and
•
Situations {Situation Package}
Figure 1 – UML Packages Used
October 2002
D3.3/3 – page 14
Version 2.0
TRIDENT DM v2.02
3.2 Limitations and General Information on the Model
Efforts have been made to maintain consistency with the concepts of DATEX where this is
appropriate (i.e. in relation to Alert C location referencing, the provision of road traffic situations
and of traffic data).
Data exchange using DATEX has some limitations, which are imposed by the use of EDIFACT
based messages, which in some cases have demanded specific message management approaches.
With the use of Object Oriented technologies within TRIDENT some of these constraints may be
considered unnecessarily limiting and therefore will not appear in the representation provided by
this Data Model. Such limitations have been released where appropriate, but aim strongly to
maintain the overall data constructs found in DATEX.
October 2002
D3.3/3 – page 15
Version 2.0
TRIDENT DM v2.02
3.3 Global Package
The Global package incorporates models that are general utility/definition objects used throughout
the model.
3.3.1 General Objects
The following objects are used in different parts of the model.
The TridentObject is a super object that all objects inherit from as defined in the model. This allows
for all objects created within TRIDENT to contain all necessary constructs, these are:
•
•
•
•
•
•
•
objectID – to ensure message uniqueness on the network
version – to ensure all messages exchanged are of the same version
creationTime – Date and Time stamp of when message was created
expiryTime – Date and Time stamp of when message expires
creatorID – unique ID of the message creator
validityDomain
{validityPeriod:start} and {ValidityPeriod:end}
Figure 2
October 2002
D3.3/3 – page 16
Version 2.0
TRIDENT DM v2.02
3.3.2 Consequence General Objects
Consequence is an object-oriented model derived from DATEX. The following general objects
define properties of a situation element that will provide detailed granularity if required by a
message. When using the consequence object, the following general objects are available.
When VehicleSpecific is
UnitisedQuantity. These are:
used,
four
optional
•
VehicleLength (Value + Unit) e.g. 2.5 metres
•
VehicleWidth (Value + Unit) e.g. 1.2 metres
•
VehicleHeight (Value +Unit) e.g. 1.6 metres
•
VehicleWeight (Value + Unit) e.g. 2 tonne
compositions
are
made
available
through
Using the Enumeration called Unit in the object UnitisedQuantity, we have a ranging option of
permissible values we can use in conjunction with Value depending on the value we are required to
fulfil. Throughout the Data Model these relationships have been defined allowing for this Value +
Unit combination.
Permissible values for the relationship attribute are defined in the Data Dictionary.
Figure 3
October 2002
D3.3/3 – page 17
Version 2.0
TRIDENT DM v2.02
3.3.3 TrafficData General Objects
The same rules apply to this DetectionTimes object.
Figure 4
3.4 Data Type Package
The Data Type package carries models that present the data types used in this TRIDENT Data
Model.
This package contains the following models:
3.4.1 Generic Data Types
These are the default data types used by the Data Model. They are used to identify the constraints
applied to permissible attribute entry values. For specific languages such as JAVA and CORBA
these data types may change.
Figure 5
October 2002
D3.3/3 – page 18
Version 2.0
TRIDENT DM v2.02
3.4.2 PT Enumerated Data Types
These are all the enumerations in use by the PT models. For further explanations of specific
enumerations and their permissible value ranges please refer to the Data Dictionary. There are two
main classes of enumerations those, which are referenced by a number, and those, which have a
literal value. The reasoning behind this is based on backward compatibility with existing standards.
It is envisaged that future versions will be move towards all enumerations being represented by
numbers, with the literal definitions being contained within the Data Dictionary.
Where numbers have been used, the literal value has been included to ease reading.
Figure 6
October 2002
D3.3/3 – page 19
Version 2.0
TRIDENT DM v2.02
3.4.3 Road Traffic Data Types
These enumerations have been built from the DATEX data dictionary, and are now represented in
object data types. For backward compliancy, the representation has not been altered in any way. For
ease of reading, the literal values have been included in this representation.
Figure 7
October 2002
D3.3/3 – page 20
Version 2.0
TRIDENT DM v2.02
3.5 Location Package
The Location package carries models that represent the presentation location and topology. This is
an area of novel work within TRIDENT, and is strongly related to the work described in D3.3/7.
3.5.1 Network (Road and PT)
Figure 8
October 2002
D3.3/3 – page 21
Version 2.0
TRIDENT DM v2.02
3.5.2 Public Transport Topology
This is the base model for all Public Transport Topology related models. Refer back to this model
when any of these objects are referenced elsewhere.
Figure 9
October 2002
D3.3/3 – page 22
Version 2.0
TRIDENT DM v2.02
3.5.3 General Link
Figure 10
3.5.4 Location
Figure 11
October 2002
D3.3/3 – page 23
Version 2.0
TRIDENT DM v2.02
3.5.5 Point and Point Types
Figure 12 - Point
October 2002
D3.3/3 – page 24
Version 2.0
TRIDENT DM v2.02
Figure 13 – Point Types
October 2002
D3.3/3 – page 25
Version 2.0
TRIDENT DM v2.02
3.5.6 Alert C Locations
Alert C location referencing is in use by DATEX, and has been included in TRIDENT, to maintain
backward compatibility. AlertC location referencing has been merged into a common locationreferencing model in TRIDENT.
Figure 14
October 2002
D3.3/3 – page 26
Version 2.0
TRIDENT DM v2.02
3.6 PT Package
The PT Package carries all the models related to the presentation of PT information, and models
necessary to query the status and/or situation of the PT Network or specific vehicles.
3.6.1 Timetables (Point and Line)
Timetables can be presented as either point timetables (i.e. for vehicle journeys passing a specific
stop point) or as line timetables (i.e. specific vehicle journeys passing a number of stop points). The
generic Timetable object can be used for both
Figure 15
October 2002
D3.3/3 – page 27
Version 2.0
TRIDENT DM v2.02
3.6.2 Registration (Generic)
The Service Registration model represents the registration of a specific Vehicle Journey by a
Service Operator (or better known as a company within Transmodel). This model is compliant with
the more complicated and comprehensive TransXChange registration standard used in the United
Kingdom.
Figure 16
October 2002
D3.3/3 – page 28
Version 2.0
TRIDENT DM v2.02
3.6.3 Status – Individual Vehicles
The ability to query the real time status of a specific vehicle is made possible through the use of this
Status model. Specifically through VehicleJourneyAtStop an organisation is enabled to exchange
the real time status of a targeted vehicle against its scheduled timings. The status query also allows
for the following information to be relayed outside of the vehicle specific information:
-
Operator Actions;
-
Service Status operation statistics; and
-
The mobility of the required vehicle
Figure 17
October 2002
D3.3/3 – page 29
Version 2.0
TRIDENT DM v2.02
3.6.4 Status – Multiple Vehicles
This model allows an organisation to query the status of all vehicles on a specified segment of the
PT network or all vehicles on the PT network. In effect an organisation would be able to query the
status of all vehicles at:
-
A specific Stop Point e.g. Clapham Junction;
-
On a specific PT Link e.g. between London Waterloo and Vauxhall;
-
On an identified line e.g. London Kings Cross to Leeds Central; and
-
On the entire pre-defined PT Network
Figure 18
October 2002
D3.3/3 – page 30
Version 2.0
TRIDENT DM v2.02
3.7 Trip Package
The Trip package contains the models necessary to represent the presentation of specific trip times
for Public Transport journeys (rides), Road journeys (road element travel times), and various
connecting links between modes and from the origin of the journey to the destination.
Itineraries provide planned trip times and interconnections for public transport journeys (rides),
road journeys (road element travel times), and various connecting links between modes and from
the origin of the journey and to the destination.
3.7.1 Trip Time
Figure 19
October 2002
D3.3/3 – page 31
Version 2.0
TRIDENT DM v2.02
3.7.2 Itinerary
Figure 20
October 2002
D3.3/3 – page 32
Version 2.0
TRIDENT DM v2.02
3.8 Traffic Data (TRAILS EDI Message Representation)
The Traffic Data package carries models that represent the presentation of traffic data using the
measurement point concept, as developed in DATEX.
3.8.1 Traffic data, using the Traffic Data Measurement Point Technique
Figure 21
October 2002
D3.3/3 – page 33
Version 2.0
TRIDENT DM v2.02
3.8.2 Traffic Data Measurement Point Definition
Figure 22
3.8.3 Traffic Data Measurement Point – Individual Vehicle Data
Figure 24
October 2002
D3.3/3 – page 34
Version 2.0
TRIDENT DM v2.02
3.8.4 Traffic Data Measurement Point – Calculated Travel Time
Figure 25
October 2002
D3.3/3 – page 35
Version 2.0
TRIDENT DM v2.02
3.9 Situations
The Situations package carries models that represent the presentation of road traffic and public
transport situations. As stated above, this Data Model currently contains a subset of the situation
types possibly carried within DATEX. These are for road traffic situations: accident, incident, road
maintenance, weather data and PT Incident (new).
3.9.1 Situation and Situation Element
This model is the foundation for the DATEX TRAVIN message, which conveys information
relating to one traffic/travel situation such as an accident, road works, PT Delay, snowstorm, or
security alert.
Due to the time constraints on the project, only a few Data Objects were modelled, Accident
(ACC), Incident (INC), Road Maintenance (RMT) and PT Incident.
Figure 26
October 2002
D3.3/3 – page 36
Version 2.0
TRIDENT DM v2.02
3.9.2 Road Maintenance (DATEX – RMT)
Figure 27
3.9.3 Incident (DATEX – INC)
Figure 28
October 2002
D3.3/3 – page 37
Version 2.0
TRIDENT DM v2.02
3.9.4 Accident (DATEX – ACC)
Figure 29
3.9.5 Weather Data
3.9.6 Public Transport Incident
Figure 30
October 2002
D3.3/3 – page 38
Version 2.0
TRIDENT DM v2.02
3.9.7 Consequence
Figure 31
October 2002
D3.3/3 – page 39
Version 2.0
TRIDENT DM v2.02
4 Examples of Usage of the Data Model
4.1 Chapter abstract
The following examples are all based on version 1.3 of the Data Model, which was tested during the
duration of the implementation phase. The examples have therefore not been adapted to this newer
v2.0 of the Data Model.
This Chapter provides examples of usage of the TRIDENT Data Model. These examples are
provided to aid the reader in the comprehension of the orientation and use of the principles of this
experimental Data Model.
The examples are not exhaustive, in terms of the data that can be carried by applications complying
to the Data Model, or are given to indicate data constructs that are to be used in conjunction with
these applications.
4.2 Examples
The following examples have been provided:
•
Itinerary;
•
Public transport point timetable;
•
Public transport line timetable;
...
4.2.1 Example: Itinerary
This example shows an itinerary.
Itinerary for J Booth for 7 July 2001
Modes Selected: Bus/Coach, Rail, Metro, Walk
Optimised for Minimum Travel Duration
For journey from Address A to Address B (Leicester Square)
•
Walk link – Address A to Woking Railway Station, Main Entrance (Station Approach) – 6
minutes
•
Train – Depart: Woking (10:30) – Arrive: London Waterloo (10:58), operated by
SouthWest Trains, Departs from Platform 2
•
Connection link to London Underground, Northern line, Northbound – 5 minutes
•
LU, Northern Line service to Leicester Square, Ride Duration 11 minutes, Average wait time
4 minutes
October 2002
D3.3/3 – page 40
Version 2.0
TRIDENT DM v2.02
Itinerary
{StartDate} = 7July2001
{EndDate} = 7July2001
TransportModeName = 2, 3, 5, 9
OptimisationType = 1
Location:OriginPlace {abstact}
Address = Address A
TripSegment
TripSegment
{ID) = 1
{ID) = 2
Location:DestinationPlace {abstact}
Address = Address B (Leicester Square)
TripSegment
TripSegment
TripSegment
TripSegment
{ID) = 3
{ID) = 4
{ID) = 5
{ID) = 6
NonPTAccessLink
Ride
PassengerWait
NonPTAccessLinkDuration = 6 mins
TimetabledRideDuration = 28 mins
MeanPassengerWaitTime = 4 mins
ConnectionLink
...DefaultDuration = 5 mins
PTAccessLink
...DefaultDuration = 3 mins
Ride
TimetabledRideDuration = 11 mins
StopPoint1 {Abstract}
RailwayStationName = Woking
PlatformIdentifier = 2
MetroStationName = Waterloo
LineName/Number = Northern
PTDirection = Northbound
Location:PTAccessPoint {abstract}
WGS84 coordinates = Language = WordOrder = PTAccessPointName = MainEntrance
StopPoint = WokingRailway
StreetName = Station Approach
LocationType = I354
RailwayStationName = London Waterloo
Line
{ID} = NorthernLine
VehicleJourneyAtStop 1
TimetabledDepartureTime = 10:30
TimetabledArrivalTime = 10:58
VehicleJourney
{ID} = 345
TransportModeName = 2
Figure 32 – Object Model Example of an Itinerary
October 2002
D3.3/3 – page 41
Version 2.0
TRIDENT DM v2.02
4.2.2 Example: Public transport point timetable
This example shows a point timetable. A point timetable gives some or all of the services passing
the reference point.
Services at Stop A
Valid 7 July – 10 August 2001 (Not Saturdays)
Line
Destination
Service Id
09.19
No. 12
Woking
234
09:39a
09:42d
No. 11
Guildford (via Woking)
342
October 2002
D3.3/3 – page 42
Version 2.0
TRIDENT DM v2.02
Timetable
{EndDate} = 10August2001
StopPoint {Abstract}
BusStopName = "Stop A"
VehicleJourney 1
VehicleJourney 2
{ID} = 234
TransportModeName = Bus
{ID} = 342
DayType 1/2
PropertyOfDayName = "Not Saturday"
Line 1
{ID} = 12
JourneyPattern 1
Line 2
{ID} = 11
JourneyPattern 2
JourneyPatternIntermediateStop 2 {abstract}
LocationName = Woking
JourneyPatternDestination 1 {abstract}
LocationName = Woking
LocationName = Guildford
Figure 33 – Object Model Example of a Public Transport Point Timetable
October 2002
D3.3/3 – page 43
Version 2.0
TRIDENT DM v2.02
4.2.3 Example: Public transport line timetable
This example shows a public transport line timetable. A line timetable shows the progression of
specific vehicle journeys through the network.
Line 12
Valid 7 July – 10 August 2001 (Not Saturdays)
Service
222
342
Woking (d)
10:15
11:15
West End (d)
10:27
11:27
Worplesdon
-
Guildford, North Street (a)
10:40 (2 )
11:33 (1 )
11:42 (3 )
Notes
(1) For Boarding Only.
(2) Continues to Reigate.
(3) Terminates at Guildford
October 2002
D3.3/3 – page 44
Version 2.0
TRIDENT DM v2.02
Timetable
{EndDate} = 10August2001
Line
{ID} = 12
VehicleJourney 2
VehicleJourney 1
{ID} = 342
{ID} = 222
DayType 1/2
PropertyOfDayName = "Not Saturday"
StopPoint 1 {Abstract}
BusStopName = Woking
BusStopName = West End
BoardingAlightingPossibility = 2 - board only
BusStopName = Worplesdon
BusStopName = Guildford, North Street
JourneyPattern 2
JourneyPatternIntermediateStop 2 {abstract}
JourneyPattern 1
LocationName = Worplesdon
LocationName = Reigate
LocationName = Guildford, North Street
Figure 34 – Example Object Model for Public Transport Line Timetable
October 2002
D3.3/3 – page 45
Version 2.0
D3.7
D3.7/4– XML Schema
TRIDENT
D3.7/4 - XML Schema
Version 2.0
7 November 2002
Produced by:
TRIDENT Consortium
November 2002
D3.7/4 – page 1/71
Version 2.0
D3.7
Activity name:
TRIDENT
Work area:
WP 3
Document title:
Final specifications for the Object Oriented
approach
Document number:
D3.7/4 - XML Schema
D:\Work\Trident\Deliverables and key documents\WP3 (System
specifications and prototype development)\D3.7 Final OO
Specifications\To Merge\D37_4.doc
Christophe Duquesne
Other author(s):
Version history
Version
Date
Main author
Summary of changes
0.1
0.2
0.3
0.4
07/12/00
02/01/01
9/07/01
17/07/01
Michele Manzato
Michele Manzato
Christophe Duquesne
Christophe Duquesne
1.0
1.2
17/08/01
05/10/01
Christophe Duquesne
Christophe Duquesne
1.3
1.3 final
18/11/01
26/03/02
Christophe Duquesne
Christophe Duquesne
2.0
1/10/02
Christophe Duquesne
Split-up version of the suite of documents
First draft version
Second draft version
Split of the XSD file
Update to last version of XSD
First complete mapping of the DM
Update of the form of the document
Corrections on the XSD mapping
Addition of informations and example on the mapping of
inheritance
Addition of example of a finale XSD file for PT Stop Point
exchange
Update release to 1.3
Integration of the results of the consortium meeting of Aix
(21-22 march 2002)
Integration of the new 2.0 DM and DD
November 2002
D3.7/4 – page 2/71
Version 2.0
D3.7
Foreword
D3.7/4. XML Schema
Annex C. Appendices
TRIDENT.
This document aims to provide an in-depth, technical description of the XML Schema (XSD) based
on the TRIDENT Data Model for the exchange of travel and traffic information.
The level, style and content of this document were chosen in order to be readily understood by
technical readers skilled in Data Modelling and XML. A fair background on the issues that are
typical in the ITS domain is welcome.
November 2002
D3.7/4 – page 3/71
Version 2.0
D3.7
Related documents
A number of documents have been used throughout the production of the documents in this suite
and are referenced throughout. These include the following:
[1]
DATEX specifications for Travel and Traffic information exchange
[2]
DATEX Data Dictionary
[3]
TRANSMODEL Specifications (version 4.1)
[4]
DETR Traffic Area Network, TransXchange Specifications
[5]
TRIDENT Deliverable D3.1: Draft specifications for the Messaging approach
[6]
OMG Unified Modelling Language specifications, version 1.3
[7]
ISO WD 14817-1v4: Transport Information and Control Systems – Data Modelling for the
TICS Sector – Part 1v4: Requirements for the TC204 Central Data Registry and for TICS data
dictionaries v4
[8]
ISO WD 14817-4Disc.V3.2: Transport Information and Control Systems – System
Architecture – Data Registration – Part 4Disc.V3: Rules for populating data dictionaries
[9]
Highways Agency, Technical Note 298/135/TN/007: Data Dictionary and Messaging
Standards, DATEX Traffic/Travel Situation Publication Data Model, January 2000.
[10] UTMC quality…
[11] Final location referencing rules specifications, EVIDENCE Deliverable D2.2, June 1999
[12] DATEX-ASN, Version 0.10 (14827-2)
[13] Modélisation de SIOERS++ (Système d’Information Objet pour l’Exploitation des Réseaux
de Surface), RATP/BUS/MSE, 6 Juillet 1999
November 2002
D3.7/4 – page 4/71
Version 2.0
D3.7
Table of Contents
Foreword ............................................................................................................................................3
Related documents .........................................................................................................................4
Table of Contents ...............................................................................................................................5
1
XML and XML Schema ............................................................................................................6
2
TRIDENT model to XML Schema mapping .............................................................................3
2.1 Principles................................................................................................................................3
2.2 main rules...............................................................................................................................3
2.3 Schema ...................................................................................................................................8
2.3.1 Global description........................................................................................................15
2.3.2 PT description ..............................................................................................................26
2.3.3 Situation description ....................................................................................................33
2.3.4 Road description ..........................................................................................................38
2.3.5 Location description.....................................................................................................46
2.3.6 Trip description............................................................................................................55
2.3.7 Requests and Answers .................................................................................................57
2.3.8 Example of exchange schema ......................................................................................62
2.3.9 Example of a resulting XML file .................................................................................62
November 2002
D3.7/4 – page 5/71
Version 2.0
D3.7
1 XML and XML Schema
XML is rapidly establishing itself as the metalanguage for inter-organizational communication.
Mainly promoted by Web and E-Commerce applications, it is appropriate for most data exchange
providing a common syntax to exchange data under a known schema.
XML (eXtensible Markup Language) is a markup language for structured documents exchanges. It
is in the middle of the way between HTML (which is dedicated to visual presentation document, is
very simple and not well structured) and SGML (which is much older, much more complicated,
uneasy to understand, use and manipulate): XML is a subset of SGML and has been designed for
ease of implementation and for interoperability with both SGML and HTML (as a minimum!).
The following points introduce the main characteristics of XML:
•
XML describes the data in a human readable format (text format with starting and ending
tags like <SHORT_MESSAGE> ...message.... </SHORT_MESSAGE> and a
limited set of special keywords and syntactical constructs)
•
The XML specification is a product of the W3C (www.w3c.org), more information could be
found at www.w3c.org/XML
•
XML is free
•
XML is platform-independent
•
XML provides a hierarchical structure for the data
•
XML document structure may be described using a DTD (Document Type Definition) or,
more recently, XML Schema
The following example gives an idea of what XML looks like, and shows how easy it is to read it. It
defines a set of two contacts with their E-mail.
November 2002
D3.7/4 – page 6/71
Version 2.0
D3.7
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE contacts SYSTEM "contacts.dtd">
<contacts>
<person>
<name>Duquesne</name>
<first-name>Christophe</first-name>
<company>Dryade</company>
<email>christophe.duquesne@dryade.net</email>
</person>
<person>
<name>Dupont</name>
<first-name>Michele</first-name>
<company>WorldCompany</company>
<email>Michele.Dupont@ worldcompany.it</email>
</person>
</contacts>
This XML document refers to a DTD (contacts.dtd) which can look like:
<!ELEMENT contacts (person+)>
<!ELEMENT person (name, first-name, email)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT first-name (#PCDATA)>
<!ELEMENT email (#PCDATA)>
As you can see, the DTD syntax is not XML. Looking further, you would discover that the set of
type and structure constraint is quite poor (this doesn’t mean that you can’t have complex types and
very precise structures in XML, but that you can’t describe them using a DTD).
Declaration
Description
ELEMENT
Definition of a structured element (tag name,
structure and attribute)
ENTITY
Short name for an often used entity (string,
external XML file, external non XML file)
NOTATION
Code used to identify a non XML resource with
the associated software to use it.
XML declarations
November 2002
D3.7/4 – page 7/71
Version 2.0
D3.7
Type
Description
PCDATA
Parsed character data
CDATA
(Not parsed) character data
ID
Unique identifier for an element
IDREF
Reference to an ID (in the same document)
NMTOKEN
a single word
ENTITY
the value is an entity
NOTATION
the value is a notation
XML types
To be able to provide a much more precise way of describing the schema of an XML file, the W3C
has recently adopted a new specification named XML Schema. The work started in 1998, and XML
Schema was adopted as a “recommendation “ in the beginning of may 2001.
The main point about XML Schema are:
•
a XML Schema description is in XML (unlike DTD), with all the advantages of XML,
•
XML Schema provide a large set of type and allow the construction of complex types
•
XML Schema can describe the relations between the element (extension, inheritance,
relations, constraints, etc...),
•
XML Schema provides names spaces
•
A single XML document, corresponding with an XML Schema description can although be
described with a DTD: there is of course a compatibility between the two description. If a
system designer decides to use XML Schema, clients using only XML and DTD will still be
able to receive his data.
Since TRIDENT uses a Transmodel based schema, which is a quite complex model, the only way to
keep all the sharpness of this model during the exchanges is to use XML Schema.
Furthermore, it’s easier to go from XML Schema to an operational Database Schema (tools are on
their way to do it automatically) and it’s although better to go from UML to XML Schema than
from UML tot DTD (and TRIDENT uses UML) and tools like Rational Rose already provide this
mapping.
November 2002
D3.7/4 – page 8/71
Version 2.0
D3.7
List of XML Schema Datatypes
Primitive Datatypes
Derived Datatypes
boolean
token
float
language
double
IDREFS
decimal
ENTITIES
duration
NMTOKEN
dateTime
NMTOKENS
time
Name
date
NCName
gYearMonth
ID
gYear
IDREF
gMonthDay
ENTITY
gDay
integer
gMonth
nonPositiveInteger
hexBinary
negativeInteger
base64Binary
long
anyURI
int
QName
short
NOTATION
byte
nonNegativeInteger
unsignedLong
unsignedInt
unsignedShort
unsignedByte
positiveInteger
November 2002
D3.7/4 – page 1/71
Version 2.0
D3.7
Figure 1 - XML Schema : Built-in data types (figure from the W3C recommendation)
November 2002
D3.7/4 – page 2/71
Version 2.0
D3.7
2 TRIDENT model to XML Schema mapping
2.1 Principles
The trident model (UML model) to XML Schema mapping is a hand mapping. The work could
have be done by a tools such as those provided by Rational (Rose extension), but the hand way has
several advantages:
! a better presentation, and more easy to read document can be achieved
! a better optimization and use of XML-Schema
! a better interpretation of the UML data model (UML model can't describe everything, an
automatic conversion may miss some important details),
! XML-Schema is often more precise than UML (mainly speaking about data types), an
automatic conversion won't provide an optimize XML Schema description
! useful comments are added to the XML Schema description each time it is necessary: this
can't be achieved by an automatic tool.
The mapping provide a Schema very close to the original UML model. However, there is not a
single mapping between a UML model and a XML Schema description, thus some choices had to
be done. These choices were done with the aim of respecting the spirit of the UML model. Some
rules were although defined, in order to get an homogeneous Schema (an single UML template is
always mapped the same way...).
2.2 Main rules
Naming
Elements and Attributes have readable names. Each name can be built from several words, without
any character (or space...) between word, each word beginning with a uppercase character, all the
others being lowercase.
Used names for "objects" are those from the Data Model.
Type's names are the Object's names extended with "Type".
All the type names end with Type (eg: StopPointType).
For all the subtution group (see XML Schema Structure), the name of the head element starts with
an underscore (eg: _Location).
November 2002
D3.7/4 – page 3/71
Version 2.0
D3.7
Attributes and elements
XML (and XML Schema) provides attributes and elements to structure the informations. Both of
them are presented in the following example.
<person ID=12345>
<name>Duquesne</name>


</person>
Attributes are used for technical and internal purpose (ID, Version, etc.), while elements are
intended to carry the real semantics of the objects. This is true for TRIDENT, and although for most
of the xml schemas.
Attribute group
Within TRIDENT, some attributes are to be used for all the objects (ID, Version, Start and End of
validity). These attributes are gathered in an "attribute group". This group will avoid to write many
times the same declaration, and will guarantee that these attributes are exactly the same everywhere.
inheritance mapping
UML schemas often use inheritance. XML Schema provides a derivation mecanism which slightly
different (extension and restriction mecanism, no implicit membership to the "inherited family").
There are two ways to map the UML inheritance.
In the first one the mapping uses two combined solutions: derivation (by extension) and substitution
group (a set of different elements are refered using the subsitution group name: they all "belong to
the same family") to emulate the membership to the "inherited family". The followin example
shows, using this method, how to map a WGS84PointType and a AddressPointType inheriting
from PointType.
<xsd:complexType name="PointType" abstract="true">
Definition of a Point
</xsd:complexType>
<xsd:complexType name="WGS84PointType" abstract="true">
<xsd:complexContent>
<xsd:extension base="PointType">
Definition of a WGS 84 Point inheriting from point
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="AddressPointType" abstract="true">
November 2002
D3.7/4 – page 4/71
Version 2.0
D3.7
<xsd:extension base="PointType">
</xsd:extension>
</xsd:complexType>
<xsd:element name="_Point" abstract="true">
General Point
Used as a head for the Point SubstitionGroup
General Point: can be a WGS84Point, AddressPoint…
This type is an abstract type
</xsd:element>
<xsd:element name="WGS84Point" type="WGS84PointType"
substitionGroup="_Point"/>
<xsd:element name="AddressPoint" type="AddressPointType"
substitionGroup="_Point"/>
<xsd:element ref="_Point" maxOccurs="unbounded">
Instance document example:
<WGS84Point>
WGS 84 Point Definition
</WGS84Point>
<AddressPoint>
Address Point Definition
</AddressPoint>
< WGS84Point >
</WGS84Point>
The second way of mapping UML inheritance onlu uses the XML Schema extension mecanism.
But the in the instance document, the writer has to state precisely which type he is using (which is
note necessary in the previous solution as the tag name states the type: <WGS84Point> or
November 2002
D3.7/4 – page 5/71
Version 2.0
D3.7
<AddressPoint>. The following example shows this way of mapping, with an XSD definition and
an example instance document.
XSD Definition:
Definition of a Point
</xsd:complexType>
<xsd:complexType name="WGS84PointType">
<xsd:extension base="trd:PointType">
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="AddressPointType">
</xsd:extension>
</xsd:complexType>
<xsd:element name="Apoint" type "trd:PointType" maxOccurs="unbounded">
Instance document example:
<Apoint xsd:type="trd:PointType">
Point Definition
</Apoint>
<Apoint xsd:type="trd:AddressPointType">
Address Point Definition
</Apoint>
<Apoint xsd:type="trd:WGS84PointType">
</Apoint>
November 2002
D3.7/4 – page 6/71
Version 2.0
D3.7
This second solution gives a little more work to write the instance document, but although provides
a simpler mapping (particularly if the UML schema uses a lot of inheritance levels, which is the
case for TRIDENT). This second solution was selected for TRIDENT mapping.
Keys an references
XML Schema provides solutions to define unique keys ans references to keys. TRIDENT although
define a unique Identifier (cf D3.3/2). Since in a lot of cases, there will be some exchanges of only
part of a dataset, it will often happen that an "object" refer a key, but that the "object" having that
key will not be in the exchanged dataset: this shall result in a XML Schema error if the schema uses
key/reference. Therefore XML Scheme keys and references were not used in the mapping, only the
TRIDENT unique identifier format was mapped.
Validation
The XML Structure is validated using IE5 XML reader (.xsd.xml files).
The Schema is validated using automated validation tool: This tool
(http://www.w3c.org/2000/09/webdata/xsv) and XML-Spy (http://www.xmlspy.com ).
are
XSV
November 2002
D3.7/4 – page 7/71
Version 2.0
D3.7
3 Extending the TRIDENT's definitions
TRIDENT covers a very large amount of the concepts used in road trafic and public transport, static
and real time information systems. However there will surely be some local specific needs that can't
be fulfil by a generic European standard (there is no way to know about every specific need, and
adding some fields/object for each specific user would lead to a huge and unusable standard).
In order to provide a solution for these specific needs, TRIDENT uses XML Schema extension
mecanism.
This mecanism is based on the use of the XSD <any> definition tag. In the TRIDENT's XSD
mapping, this tag is added after the last field of every independant object (mapped to an XSD's
complex type definition). This tag allow the user to add anything he wants (fields or complex type)
after the last "official" field of the object (provided that these fields type or complex type or defined
somewhere as elements... see the following examples).
The following XSD definition is a very simple example o f a schema using the “any” element
extension mechansm. It defines a single complex type with one field and allowing any extension. It
the defines the root element and the extension element (the element we are going to add to the
complex type).

<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
attributeFormDefault="unqualified">
elementFormDefault="qualified"


<xsd:complexType name="Object_To_Extend_Type">
<xsd:sequence>
<xsd:element name="MyInt" type="xsd:integer"/>
<xsd:any minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>


<xsd:element name="SampleExtendedObject" type="Object_To_Extend_Type"/>

<xsd:element name="MyExtension" type="xsd:integer"/>
</xsd:schema>
November 2002
D3.7/4 – page 8/71
Version 2.0
D3.7
From this definition we ca then get an XML instance document like:
<?xml version="1.0" encoding="UTF-8"?>
<SampleExtendedObject xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="AnySimple-Test.xsd">
<MyInt>0</MyInt>

<MyExtension>123</MyExtension>
</SampleExtendedObject>
3.1 Extending TRIDENT file exchange
As explained is D3.3/2, one way of exchanging TRIDENT data is to have an off-line exchange
(generaly using XML files). In this situation, you have to create an XSD file, including TRIDENT's
XSD files, to define the elements you want to exchange. For example, if you want to exchange a
single PT stop point, you can define something like:
<xsd:schema
targetNamespace="http://www.trident.org/schema/trident"
xmlns="http://www.trident.org/schema/trident" xmlns:trd="http://www.trident.org/schema/trident" elementFormDefault="qualified"
version="1.00">
<xsd:annotation>
<xsd:documentation xml:lang="en">
TRIDENT exchange schema.
Simple sample schema for TRIDENT stop pointt exchange
Copyright (c) 2001 TRIDENT consortium, All Rights Reserved.
</xsd:documentation>
</xsd:annotation>
<xsd:include schemaLocation="trident_Global_schema.xsd"/>
<xsd:include schemaLocation="trident_Location_schema.xsd"/>
<xsd:include schemaLocation="trident_PT_schema.xsd"/>
<xsd:include schemaLocation="trident_Road_schema.xsd"/>
<xsd:include schemaLocation="trident_Situation_schema.xsd"/>
<xsd:include schemaLocation="trident_Trip_schema.xsd"/>


<xsd:element name="MyPoint" type="trd:StopPointType"/>
</xsd:schema>
November 2002
D3.7/4 – page 9/71
Version 2.0
D3.7
Please note that the examples may not be fully compliant with the las TRIDENT definitions, as the
Data Model, Data Dictionnary and XSD mapping are regularly updated. But the aim of the
examples is to explain the mechanisms.
From this definition you can get a instance document like:
<MyPoint
xmlns="http://www.trident.org/schema/trident"
xsi:schemaLocation="http://www.trident.org/schema/trident
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
My_StopPoint.xsd">
<ObjectId>RATP:StopPoint:1234</ObjectId>
<Version>2</Version>
<CreationTime>2001-09-11T09:30:47</CreationTime>
<ExpiryTime>2003-09-11T09:30:47</ExpiryTime>
<CreatorId>RATP</CreatorId>
<ValidityPeriod>
<ValidityPeriodStart>2001-09-11T09:30:47</ValidityPeriodStart>
<ValidityPeriodEnd>2002-09-11T09:30:47</ValidityPeriodEnd>
</ValidityPeriod>
<AlertCExtendedLocationTypeCoded>BusStopPoint</AlertCExtendedLocationTypeCoded>
<ReferencingMethod>1</ReferencingMethod>
<WGS84Position>
<Longitude>121.23</Longitude>
<Latitude>60.65</Latitude>
</WGS84Position>
<Name>My Stop Point</Name>
<LineIdShortcut>RATP:Line:1234</LineIdShortcut>
<PTNetworkIdShortcut>RATP:PTNetwork:5</PTNetworkIdShortcut>
<Comment>This is a sample Stop Point</Comment>
</MyPoint>
The TRIDENT definition for a PT StopPoint is (extracted from the trident_Location_schema.xsd):
<xsd:complexType name="StopPointType">
<xsd:annotation>
StopPoint on a Route of a Line of a PT Network
</xsd:annotation>
<xsd:sequence>
<xsd:element name="LanguageCode" type="xsd:string" minOccurs="0"/>
November 2002
D3.7/4 – page 10/71
Version 2.0
D3.7
<xsd:element name="Name" type="xsd:string"/>
<xsd:element name="LineIdShortcut" type="trd:TridentIdType" minOccurs="0"/>
<xsd:element name="PTNetworkIdShortcut" type="trd:TridentIdType" minOccurs="0"/>
<xsd:element name="Comment" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
This definition includes, as a last field, a <any> tag allowing the extension of the Stop Point. To do
so (adding a single integer field for the Paris' "Zone Carte Orange" for example), you can change
your previous XSD definition to:
<xsd:schema
version="1.00">
<xsd:annotation>
Sample point - Example of extension using the any tag
</xsd:annotation>



<xsd:element name="MyStopPoint" type="trd:StopPointType"/>
<xsd:element name="ZoneCarteOrange" type="xsd:string"/>
</xsd:schema>
And you can then get an extended XML instance like:
November 2002
D3.7/4 – page 11/71
Version 2.0
D3.7
<MyStopPoint
StopPoint_Extension.xsd">
<CreatorId>String</CreatorId>
<ValidityPeriod>
</ValidityPeriod>
<ProjectedPosition>
<X>2423546</X>
<Y>603211</Y>
<PojectionId>LAMBERT 1</PojectionId>
</ProjectedPosition>
<Name>MyStopPoint</Name>
<Comment>Sample stop point to illustrate the "any" extension mechanism</Comment>
<ZoneCarteOrange>Zone 2</ZoneCarteOrange>
</MyStopPoint>
We have just added our simple local extension, keeping the TRIDENT compatibility.
You can define more complex extension like:
<xsd:schema
version="1.00">
<xsd:annotation>
Sample point - Example of extension using the any tag
</xsd:annotation>


November 2002
D3.7/4 – page 12/71
Version 2.0
D3.7


<xsd:complexType name="MyComplexExtensionType">
<xsd:sequence>
<xsd:element name="ExtensionField_1" type="xsd:string"/>
<xsd:element name="ExtensionField_1" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>

<xsd:element name="MyStopPoint" type="trd:StopPointType"/>

<xsd:element name="MyStopPointExtension" type="xsd:string"/>
<xsd:element name="MyComplexExtension" type="MyComplexExtensionType"/>
</xsd:schema>
And the get an instance XML file like:
<MyStopPoint
StopPoint_Extension2.xsd">
<CreatorId>String</CreatorId>
<ValidityPeriod>
</ValidityPeriod>
<ProjectedPosition>
<X>2423546</X>
<Y>603211</Y>
<PojectionId>LAMBERT 1</PojectionId>
</ProjectedPosition>
November 2002
D3.7/4 – page 13/71
Version 2.0
D3.7
<Name>MyStopPoint</Name>
<Comment>Sample stop point to illustrate the "any" extension mechanism</Comment>
<MyStopPointExtension>This is may own specific extension for a stop point</MyStopPointExtension>
<MyComplexExtension>
<ExtensionField_1>This is the first field of the complex extension</ExtensionField_1>
<ExtensionField_1>This is the second field of the complex extension</ExtensionField_1>
</MyComplexExtension>
</MyStopPoint>
3.2 Extending TRIDENT when using system functions
When using TRIDENT's system functions there is already an XSD file describing the exchange
(TridentRequestAnswer.xsd). If you need to extend TRIDENT's definitions you probably although
need to add some elements to the TridentRequestAnswer.xsd. And the TRIDENT Supplier needs to
send this extended definitions to its Clients.
Once you get this extended schema, all is working exactly as explained above.
To get the extended schema, you just have to use the get_extended_schema() method from the
TRIDENT system interface. You although have a use_extended_schema(true/false) method to tell
the Supplier if you want, or not, to get the local specific extensions (see D3.3/2 for more details).
3.3 Schema
The Schema is divided in four files:
! Global description
! PT description
! Situation description
! Road description
! Location description
! Trip description
! Services description (mapping not yet done)
The files are presented below. The best way to use them and to navigate through the XSD is not to
read the following, but to use a tool like XMLSpy, for example, on the xsd files and samples
provided with the specification.
November 2002
D3.7/4 – page 14/71
Version 2.0
D3.7
3.3.1 Global description


<xsd:schema targetNamespace="http://www.trident.org/schema/trident" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
version="2.0">
<xsd:annotation>
Global Definition
</xsd:annotation>


<xsd:simpleType name="TridentIdType">
<xsd:annotation>
<xsd:documentation>
Defines the way an TRIDENT ID has to be built:
{PeerID}:{Class name}:{Progressive integer}
For example: RATP:Event:12332 or ATAC:Line:9987
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="(\p{L}|_)+:\p{L}+:[0-9A-Za-z]+"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="TridentIdGeneralListType">
<xsd:list itemType="TridentIdType"/>
</xsd:simpleType>
<xsd:simpleType name="TridentIdListType">
<xsd:restriction base="TridentIdGeneralListType">
<xsd:minLength value="2"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:complexType name="TridentObjectType" abstract="true">
<xsd:sequence>
<xsd:element name="objectId" type="trd:TridentIdType"/>
<xsd:element name="objectVersion" type="xsd:positiveInteger" minOccurs="0"/>
<xsd:element name="creationTime" type="xsd:dateTime" minOccurs="0"/>
<xsd:element name="expiryTime" type="xsd:dateTime" minOccurs="0"/>
<xsd:element name="creatorId" type="xsd:string" minOccurs="0"/>
<xsd:choice>
<xsd:element name="validityPeriod" type="trd:ObjectValidityType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="validityDomain" type="xsd:string" minOccurs="0"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ObjectReferenceType">
<xsd:sequence>
<xsd:element name="Id" type="trd:TridentIdType"/>
<xsd:element name="Version" type="xsd:string" minOccurs="0"/>
</xsd:sequence>

</xsd:complexType>
<xsd:complexType name="ObjectValidityType">
<xsd:sequence>
<xsd:element name="start" type="xsd:dateTime"/>
<xsd:element name="end" type="xsd:dateTime" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>

<xsd:simpleType name="LongitudeType">
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="-180"/>
<xsd:maxInclusive value="180"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="LatitudeType">
<xsd:minInclusive value="-90"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="PercentageType">
<xsd:annotation>
<xsd:documentation>
Percentage: decimal between 0 and 100
</xsd:annotation>
<xsd:minInclusive value="0"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="DayOfWeekType">
<xsd:annotation>
<xsd:documentation>
Defines the list of the days of the week (in english!)
</xsd:annotation>
<xsd:enumeration value="Monday"/>
<xsd:enumeration value="Tuesday"/>
<xsd:enumeration value="Wednsday"/>
<xsd:enumeration value="Thursday"/>
<xsd:enumeration value="Friday"/>
<xsd:enumeration value="Saturday"/>
<xsd:enumeration value="Sunday"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="UnitType">
<xsd:annotation>
<xsd:documentation>
Enumeration containing all the possible units for measurement
</xsd:annotation>
<xsd:enumeration value="DegreesCelsius"/>
<xsd:enumeration value="Centimeter"/>
<xsd:enumeration value="Degree"/>
<xsd:enumeration value="Hour"/>
<xsd:enumeration value="Hectopascals"/>
<xsd:enumeration value="KilometersPerHour"/>
November 2002
D3.7/4 – page 16/71
Version 2.0
D3.7
<xsd:enumeration value="Kilometer"/>
<xsd:enumeration value="CubicMeter"/>
<xsd:enumeration value="MillimetersPerHour"/>
<xsd:enumeration value="Millimeter"/>
<xsd:enumeration value="Meter"/>
<xsd:enumeration value="MetersPerSecond"/>
<xsd:enumeration value="Percentage"/>
<xsd:enumeration value="Second"/>
<xsd:enumeration value="Tonne"/>
<xsd:enumeration value="HrMinSec"/>
<xsd:enumeration value="PeriodOfTime"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="LocationTypeType">
<xsd:annotation>
<xsd:documentation>
Enumeration containing all the possible location Type
</xsd:annotation>
<xsd:enumeration value="BusStopPoint"/>
<xsd:enumeration value="AriportStopPoint"/>
<xsd:enumeration value="TramStopPoint"/>
<xsd:enumeration value="MetroStopPoint"/>
<xsd:enumeration value="RailwayStopPoint"/>
<xsd:enumeration value="RoadJunction"/>
<xsd:enumeration value="Mixed"/>
<xsd:enumeration value="Address"/>
<xsd:enumeration value="IntermediateRoadPoint"/>
<xsd:enumeration value="StopArea"/>
<xsd:enumeration value="PointOfInterest"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="LongLatTypeType">
<xsd:annotation>
<xsd:documentation>Type of geodesic reference</xsd:documentation>
</xsd:annotation>
<xsd:enumeration value="WGS84"/>
<xsd:enumeration value="WGS92"/>
<xsd:enumeration value="Standard"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="LocationReferencingMethodType">
<xsd:annotation>
<xsd:documentation>
Enumeration containing all the possible location referencing
methods
</xsd:annotation>
<xsd:enumeration value="1"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="WordOrderType">
<xsd:annotation>
<xsd:documentation>Order of words in a ILOC descriptor</xsd:documentation>
</xsd:annotation>
November 2002
D3.7/4 – page 17/71
Version 2.0
D3.7
<xsd:enumeration value="FromTheFirstToTheLastWord"/>
<xsd:enumeration value="FromTheLastToTheFirstWord"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="POITypeType">
<xsd:annotation>
<xsd:documentation>Different types for a point</xsd:documentation>
</xsd:annotation>
<xsd:enumeration value="AccommodationEatingAndDrinking"/>
<xsd:enumeration value="CommercialServices"/>
<xsd:enumeration value="Attraction"/>
<xsd:enumeration value="SportAndEntertainment"/>
<xsd:enumeration value="EducationAndHealth"/>
<xsd:enumeration value="PublicInfrastructure"/>
<xsd:enumeration value="ManufacturingAndProduction"/>
<xsd:enumeration value="Wholesale"/>
<xsd:enumeration value="Retail"/>
<xsd:enumeration value="Transport"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="PtAccessPointTypeType">
<xsd:annotation>
<xsd:documentation>Type of a PT acces</xsd:documentation>
</xsd:annotation>
<xsd:enumeration value="In"/>
<xsd:enumeration value="Out"/>
<xsd:enumeration value="InOut"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ConnectionLinkTypeType">
<xsd:annotation>
<xsd:documentation>Type of connection</xsd:documentation>
</xsd:annotation>
<xsd:enumeration value="Underground"/>
<xsd:enumeration value="Overground"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="RDSDirectionType">
<xsd:annotation>
<xsd:documentation>
Enumeration containing all the possible RDS Directions
</xsd:annotation>
<xsd:enumeration value="Positive"/>
<xsd:enumeration value="Negative"/>
<xsd:enumeration value="Both"/>
<xsd:enumeration value="Unknown"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="DataObjectType">
<xsd:annotation>
<xsd:documentation>
Enumeration containing all the possible Data Objects
</xsd:annotation>
<xsd:enumeration value="AMB"/>
<xsd:enumeration value="RCO"/>
<xsd:enumeration value="TRD"/>
<xsd:enumeration value="TRR"/>
<xsd:enumeration value="TTC"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="PhraseType">
November 2002
D3.7/4 – page 18/71
Version 2.0
D3.7
<xsd:annotation>
<xsd:documentation>
Coded values corresponding to all the possible Phrases
See te Data Dictionnary for the "phase" associated to the coded value
</xsd:annotation>
<xsd:restriction base="xsd:positiveInteger">
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="CompassPointDirectionType">
<xsd:annotation>
<xsd:documentation>
Enumeration containing all the possible directions
</xsd:annotation>
<xsd:enumeration value="North"/>
<xsd:enumeration value="NorthNorthEast"/>
<xsd:enumeration value="NorthEast"/>
<xsd:enumeration value="EastNorthEast"/>
<xsd:enumeration value="East"/>
<xsd:enumeration value="EastSouthEast"/>
<xsd:enumeration value="SouthEast"/>
<xsd:enumeration value="SouthSouthEast"/>
<xsd:enumeration value="South"/>
<xsd:enumeration value="SouthSouthWest"/>
<xsd:enumeration value="SouthWest"/>
<xsd:enumeration value="WestSouthWest"/>
<xsd:enumeration value="West"/>
<xsd:enumeration value="WestNorthWest"/>
<xsd:enumeration value="NorthWest"/>
<xsd:enumeration value="NorthNorthWest"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="DangerousGoodsRegulationsType">
<xsd:annotation>
<xsd:documentation>Enumeration containing regulation information for dangerous goods
transport</xsd:documentation>
</xsd:annotation>
<xsd:enumeration value="RoadRegulations"/>
<xsd:enumeration value="AirRegulations"/>
<xsd:enumeration value="OceanGoingRegulations"/>
<xsd:enumeration value="RailRegulations"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="TypeOfLoadType">
<xsd:annotation>
<xsd:documentation>
Enumeration containing all the possible load of a vehicle
</xsd:annotation>
<xsd:enumeration value="Ammunition"/>
<xsd:enumeration value="Children"/>
<xsd:enumeration value="Chemicals"/>
<xsd:enumeration value="CombustibleMaterials"/>
<xsd:enumeration value="CorrosiveMaterials"/>
<xsd:enumeration value="MaterialsDangerousForTheEnvironment"/>
<xsd:enumeration value="MaterialsDangerousForPeople"/>
<xsd:enumeration value="Debris"/>
<xsd:enumeration value="ExplosiveMaterials"/>
<xsd:enumeration value="Fuel"/>
<xsd:enumeration value="Glass"/>
<xsd:enumeration value="HazardousMaterials"/>
<xsd:enumeration value="Livestock"/>
<xsd:enumeration value="Materials"/>
<xsd:enumeration value="Oil"/>
<xsd:enumeration value="Ordinary"/>
November 2002
D3.7/4 – page 19/71
Version 2.0
D3.7
<xsd:enumeration value="PerishableProducts"/>
<xsd:enumeration value="Petrol"/>
<xsd:enumeration value="PharmaceuticalMaterials"/>
<xsd:enumeration value="Persons"/>
<xsd:enumeration value="Radioactive materials"/>
<xsd:enumeration value="Refuse"/>
<xsd:enumeration value="SickPeople"/>
<xsd:enumeration value="ToxicMaterials"/>
<xsd:enumeration value="VIP"/>
<xsd:enumeration value="ExceedsNormalDimensions"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="MobilityType">
<xsd:annotation>
<xsd:documentation>
Mobile or not !
</xsd:annotation>
<xsd:enumeration value="Stationary"/>
<xsd:enumeration value="Mobile"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="TransportModeNameType">
<xsd:annotation>
<xsd:documentation>
Enumeration containing all the possible transport modes
</xsd:annotation>
<xsd:enumeration value="Air"/>
<xsd:enumeration value="Train"/>
<xsd:enumeration value="LongDistanceTrain"/>
<xsd:enumeration value="LongDistanceTrain"/>
<xsd:enumeration value="LocalTrain"/>
<xsd:enumeration value="RapidTransit"/>
<xsd:enumeration value="Metro"/>
<xsd:enumeration value="Tramway"/>
<xsd:enumeration value="Coach"/>
<xsd:enumeration value="Bus"/>
<xsd:enumeration value="Ferry"/>
<xsd:enumeration value="Waterborne"/>
<xsd:enumeration value="PrivateVehicle"/>
<xsd:enumeration value="Walk"/>
<xsd:enumeration value="Trolleybus"/>
<xsd:enumeration value="Bicycle"/>
<xsd:enumeration value="Shuttle"/>
<xsd:enumeration value="Taxi"/>
<xsd:enumeration value="Other"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="PTDirectionType">
<xsd:annotation>
<xsd:documentation>
Enumeration containing all the possible directions on a PT Network
</xsd:annotation>
<xsd:enumeration value="North"/>
<xsd:enumeration value="NorthEast"/>
<xsd:enumeration value="East"/>
<xsd:enumeration value="SouthEast"/>
<xsd:enumeration value="South"/>
<xsd:enumeration value="SouthWest"/>
<xsd:enumeration value="West"/>
<xsd:enumeration value="NorthWest"/>
<xsd:enumeration value="ClockWise"/>
<xsd:enumeration value="CounterClockWise"/>
</xsd:restriction>
November 2002
D3.7/4 – page 20/71
Version 2.0
D3.7
</xsd:simpleType>
<xsd:simpleType name="DayTypeType">
<xsd:annotation>
<xsd:documentation>
Enumeration containing all defined Day Type
</xsd:annotation>
<xsd:enumeration value="WeekDay"/>
<xsd:enumeration value="WeekEnd"/>
<xsd:enumeration value="Monday"/>
<xsd:enumeration value="Tuesday"/>
<xsd:enumeration value="Wednsday"/>
<xsd:enumeration value="Thursday"/>
<xsd:enumeration value="Friday"/>
<xsd:enumeration value="Saturday"/>
<xsd:enumeration value="Sunday"/>
<xsd:enumeration value="SchoolHoliday"/>
<xsd:enumeration value="PublicHolliday"/>
<xsd:enumeration value="MarketDay"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="BoardingAlightingPossibilityType">
<xsd:annotation>
<xsd:documentation>
Enumeration containing all the ways to board or alight a bus
</xsd:annotation>
<xsd:enumeration value="BoardAndAlight"/>
<xsd:enumeration value="AlightOnly"/>
<xsd:enumeration value="BoardOnly"/>
<xsd:enumeration value="NeitherBoardOrAlight"/>
<xsd:enumeration value="BoardAndAlightOnRequest"/>
<xsd:enumeration value="AlightOnRequest"/>
<xsd:enumeration value="BoardOnRequest"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ServiceStatusValueType">
<xsd:annotation>
<xsd:documentation>
Enumeration containing all the possible status of a PT service
</xsd:annotation>
<xsd:enumeration value="Normal"/>
<xsd:enumeration value="Delayed"/>
<xsd:enumeration value="Cancelled"/>
<xsd:enumeration value="Disrupted"/>
<xsd:enumeration value="ReducedService"/>
<xsd:enumeration value="IncreasedService"/>
<xsd:enumeration value="Rerouted"/>
<xsd:enumeration value="NotStopping"/>
<xsd:enumeration value="Early"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="VehicleJourneyStatusValueType">
<xsd:annotation>
<xsd:documentation>
Enumeration containing all the possible status of a PT service
on a vehicle
</xsd:annotation>
<xsd:enumeration value="Delayed"/>
<xsd:enumeration value="Cancelled"/>
<xsd:enumeration value="Rerouted"/>
<xsd:enumeration value="NotStopping"/>
<xsd:enumeration value="Early"/>
November 2002
D3.7/4 – page 21/71
Version 2.0
D3.7
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="SourceTypeType">
<xsd:annotation>
<xsd:documentation>
Enumeration containing all the possible type of information
source
</xsd:annotation>
<xsd:enumeration value="AutomobileClubPatrol"/>
<xsd:enumeration value="SpotterAircraft"/>
<xsd:enumeration value="BreakdownService"/>
<xsd:enumeration value="CameraObservation"/>
<xsd:enumeration value="EmergencyServicePatrol"/>
<xsd:enumeration value="FreightVehicleOperator"/>
<xsd:enumeration value="InfraredMonitoringStation"/>
<xsd:enumeration value="InductionLoopMonitoringStation"/>
<xsd:enumeration value="MicrowaveMonitoringStation"/>
<xsd:enumeration value="MobileTelephoneCaller"/>
<xsd:enumeration value="OtherInformation"/>
<xsd:enumeration value="OtherOfficialVehicle"/>
<xsd:enumeration value="PolicePatrol"/>
<xsd:enumeration value="PublicAndPrivateUtilities"/>
<xsd:enumeration value="RoadAuthorities"/>
<xsd:enumeration value="RegisteredMotoristObserver"/>
<xsd:enumeration value="RoadsideTelephoneCaller"/>
<xsd:enumeration value="TrafficMonitoringStation"/>
<xsd:enumeration value="TransitOperator"/>
<xsd:enumeration value="VideoProcessingMonitoringStation"/>
<xsd:enumeration value="VehicleProbeMeasurement"/>
<xsd:enumeration value="PublicTransport"/>
<xsd:enumeration value="PassengerTransportCoordinatingAuthority"/>
<xsd:enumeration value="TravelInformationServiceProvider"/>
<xsd:enumeration value="TravelAgency"/>
<xsd:enumeration value="IndividualSubjectOfTravelItinerary"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="MotoringConditionsType">
<xsd:annotation>
<xsd:documentation>
Monitorin conditions: Normal/Difficult/Impossible
</xsd:annotation>
<xsd:enumeration value="Difficult"/>
<xsd:enumeration value="Impossible"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="AdviceCodeType">
<xsd:annotation>
<xsd:documentation>
Enumeration containing all the possible advice code
(from Phrases)
The value is based on EDI 3 (2) letter code
</xsd:annotation>
<xsd:enumeration value="DO"/>
<xsd:enumeration value="GP"/>
<xsd:enumeration value="SM"/>
<xsd:enumeration value="SN"/>
<xsd:enumeration value="SR"/>
<xsd:enumeration value="TM"/>
<xsd:enumeration value="TR"/>
<xsd:enumeration value="WR"/>
</xsd:restriction>
</xsd:simpleType>
November 2002
D3.7/4 – page 22/71
Version 2.0
D3.7
<xsd:simpleType name="SupplementaryAdviceType">
<xsd:annotation>
<xsd:documentation>
Defines all the possible advice supplementary code
(from Phrases)
The value is based on EDI 3 (2) letter code
Two letters between A and Z
</xsd:annotation>
<xsd:pattern value="[A-Z][A-Z]"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="CodedDurationType">
<xsd:annotation>
<xsd:documentation>
Enumeration containing all the possible duration code
</xsd:annotation>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="QualityIndexType">
<xsd:annotation>
<xsd:documentation>
Quality of a status/situation indications
</xsd:annotation>
<xsd:enumeration value="Certain"/>
<xsd:enumeration value="VeryReliable"/>
<xsd:enumeration value="Reliable"/>
<xsd:enumeration value="ProbablyReliable"/>
<xsd:enumeration value="Unconfirmed"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="SeverityType">
<xsd:annotation>
<xsd:documentation>
Severity of a status/situation
</xsd:annotation>
<xsd:enumeration value="ExtremelySevere"/>
<xsd:enumeration value="VerySevere"/>
<xsd:enumeration value="Severe"/>
<xsd:enumeration value="LowSeverity"/>
<xsd:enumeration value="LowestSeverity"/>
<xsd:enumeration value="NotProvided"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:complexType name="TimePeriodType">
<xsd:annotation>
Time and duration information
November 2002
D3.7/4 – page 23/71
Version 2.0
D3.7
</xsd:annotation>
<xsd:sequence>
<xsd:element name="DateTime" type="xsd:dateTime" minOccurs="0"/>
<xsd:element name="Duration" type="xsd:duration" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="MeasurementTimeType">
<xsd:annotation>
Informations on the time of a measurement
</xsd:annotation>
<xsd:sequence>
<xsd:element name="measurementTime" type="xsd:dateTime" minOccurs="0"/>
<xsd:element name="measurementPeriod" type="trd:TimePeriodType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="UnitisedQuantityType">
<xsd:annotation>
Value with its type
for road trafic_
</xsd:annotation>
<xsd:sequence>
<xsd:element name="value" type="xsd:decimal"/>
<xsd:element name="unit" type="trd:UnitType"/>
<xsd:element name="accuracy" type="trd:AccuracyType" minOccurs="0"/>
<xsd:element name="measurementTime" type="trd:MeasurementTimeType" minOccurs="0"/>
<xsd:element name="measurementLocation" type="trd:LocationType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="AccuracyType">
<xsd:annotation>
Accuracy of a measure
</xsd:annotation>
<xsd:sequence>
<xsd:element name="standardDeviation" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="accuracy" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="dataClass" type="xsd:string" minOccurs="0"/>
<xsd:element name="accuracyRange" type="xsd:string" minOccurs="0"/>

</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ProcessingIndicatorType">
<xsd:sequence>
<xsd:element name="areaOfInterest" type="xsd:string" minOccurs="0"/>
<xsd:element name="confidentiality" type="xsd:string" minOccurs="0"/>
<xsd:element name="forecaste" type="xsd:boolean" minOccurs="0"/>
<xsd:element name="probability" minOccurs="0">
<xsd:simpleType>
<xsd:enumeration value="DangerOf"/>
<xsd:enumeration value="Expected"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="qualityIndex" type="QualityIndexType" minOccurs="0"/>
<xsd:element name="motoringConditions" type="trd:MotoringConditionsType" minOccurs="0"/>
<xsd:element name="urgency" type="xsd:string" minOccurs="0"/>
<xsd:element name="windCompassDirection" type="trd:CompassPointDirectionType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
November 2002
D3.7/4 – page 24/71
Version 2.0
D3.7
November 2002
D3.7/4 – page 25/71
Version 2.0
D3.7
3.3.2 PT description

version="2.0">
<xsd:annotation>
<xsd:appinfo>trident.xsd v1.00 2002-10</xsd:appinfo>
PT Network Description
</xsd:annotation>

<xsd:simpleType name="PTConnectionLinkTypeType">
<xsd:annotation>
Enumeration containing all the possible type of non PT access link
</xsd:annotation>
</xsd:restriction>
</xsd:simpleType>



<xsd:complexType name="StopAreaType">
<xsd:annotation>
A PT area made up of a set of PT Stop Points
</xsd:annotation>
<xsd:extension base="trd:AreaType">
<xsd:sequence>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="RouteType">
<xsd:annotation>
An ordered list of Stop Points on wich Journey
pattern are applied
</xsd:annotation>
<xsd:extension base="trd:TridentObjectType">
<xsd:sequence>
<xsd:element name="name" type="xsd:string" minOccurs="0"/>
<xsd:element name="publishedName" type="xsd:string" minOccurs="0"/>
<xsd:element name="number" type="xsd:string" minOccurs="0"/>
November 2002
D3.7/4 – page 26/71
Version 2.0
D3.7
<xsd:element name="direction" type="trd:PTDirectionType" minOccurs="0"/>
<xsd:element name="ptLinkId" type="trd:TridentIdType" maxOccurs="unbounded"/>
<xsd:element name="journeyPatternId" type="trd:TridentIdType" maxOccurs="unbounded"/>
<xsd:element name="wayBackRouteId" type="trd:TridentIdType" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="LineType">
<xsd:annotation>
A line is a set of Route _.
</xsd:annotation>
<xsd:extension base="trd:LogicalLocationType">
<xsd:sequence>
<xsd:element name="transportModeName" type="trd:TransportModeNameType" minOccurs="0"/>
<xsd:element name="lineEnd" type="trd:TridentIdType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="routeId" type="trd:TridentIdType" maxOccurs="unbounded"/>
<xsd:element name="registration" type="trd:RegistrationType" minOccurs="0"/>
<xsd:element name="ptNetworkIdShortcut" type="trd:TridentIdType" minOccurs="0"/>
<xsd:element name="comment" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="GroupOfLineType">
<xsd:annotation>
A set of lines
</xsd:annotation>
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element name="lineId" type="trd:TridentIdType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="JourneyPatternType">
<xsd:annotation>
Basically, JourneyPattern are some ordered list of
Stop Points, but these StopPoints have to be linked
together (by couples)
</xsd:annotation>
<xsd:sequence>
<xsd:element name="routeId" type="trd:TridentIdType"/>
<xsd:element name="origin" type="trd:TridentIdType" minOccurs="0"/>
<xsd:element name="destination" type="trd:TridentIdType" minOccurs="0"/>
<xsd:element name="stopPointListe" type="trd:TridentIdType" minOccurs="2" maxOccurs="unbounded"/>
<xsd:element name="lineIdShortcut" type="trd:TridentIdType" minOccurs="0"/>
November 2002
D3.7/4 – page 27/71
Version 2.0
D3.7


</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="VehicleJourneyAtStopType">
<xsd:annotation>
Passing time on a stop point
</xsd:annotation>
<xsd:sequence>
<xsd:element name="stopPointId" type="trd:TridentIdType"/>
<xsd:element name="vehicleJourneyId" type="trd:TridentIdType" minOccurs="0"/>
<xsd:element name="connectingServiceId" type="trd:TridentIdType" minOccurs="0"/>
<xsd:element name="arrivalTime" type="xsd:time" minOccurs="0"/>
<xsd:element name="departureTime" type="xsd:time" minOccurs="0"/>
<xsd:element name="waitingTime" type="xsd:time" minOccurs="0"/>
<xsd:element name="headwayFrequency" type="xsd:duration" minOccurs="0"/>
<xsd:element name="boardingAlightingPossibility" type="trd:BoardingAlightingPossibilityType" minOccurs="0"/>
<xsd:element name="relativeTime" type="trd:RelativeTimeType" minOccurs="0"/>
<xsd:element name="order" type="xsd:positiveInteger" minOccurs="0"/>

</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="VehicleJourneyType">
<xsd:annotation>
Instance of a Journey Pattern
</xsd:annotation>
<xsd:sequence>
<xsd:element name="journeyPatternId" type="trd:TridentIdType"/>
<xsd:element name="publishedJourneyName" type="xsd:string" minOccurs="0"/>
<xsd:element name="publishedJourneyIdentifier" type="xsd:string" minOccurs="0"/>
<xsd:element name="transportMode" type="trd:TransportModeNameType" minOccurs="0"/>
<xsd:element name="vehicleTypeIdentifier" type="xsd:string" minOccurs="0"/>
<xsd:element name="statusValue" type="ServiceStatusValueType" minOccurs="0"/>
<xsd:element name="routeIdShortcut" type="trd:TridentIdType" minOccurs="0"/>
<xsd:element name="operatorId" type="trd:TridentIdType" minOccurs="0"/>
<xsd:element name="facility" type="xsd:string" minOccurs="0"/>
<xsd:element name="vehicleJourneyAtStop" type="trd:VehicleJourneyAtStopType" minOccurs="2"
maxOccurs="unbounded"/>
<xsd:element name="period" type="trd:PeriodType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="calendarDay" type="xsd:date" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="dayType" type="trd:DayTypeType" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="PeriodType">
<xsd:annotation>
Period during which a Vehicle Journey is applicable
</xsd:annotation>
<xsd:sequence>
<xsd:element name="StartOfPeriod" type="xsd:date"/>
<xsd:element name="EndOfPeriod" type="xsd:date"/>
</xsd:sequence>
November 2002
D3.7/4 – page 28/71
Version 2.0
D3.7
</xsd:complexType>
<xsd:complexType name="ConnectingServiceType">
<xsd:annotation>
Connecting service description
</xsd:annotation>
<xsd:sequence>
<xsd:element name="minimumConnectingTime" type="xsd:duration"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="CompanyType">
<xsd:annotation>
PT Operator description
</xsd:annotation>
<xsd:sequence>
<xsd:element name="shortName" type="xsd:string" minOccurs="0"/>
<xsd:element name="organisationalUnit" type="xsd:string" minOccurs="0"/>
<xsd:element name="operatingDepartmentName" type="xsd:string" minOccurs="0"/>
<xsd:element name="code" type="xsd:string" minOccurs="0"/>
<xsd:element name="phone" type="xsd:string" minOccurs="0"/>
<xsd:element name="fax" type="xsd:string" minOccurs="0"/>
<xsd:element name="email" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="TimetableType">
<xsd:annotation>
TimeTable informations (merge of LineTimeTable and PointTimeTable)
</xsd:annotation>
<xsd:sequence>
<xsd:element name="version" type="xsd:string" minOccurs="0"/>
<xsd:element name="period" type="trd:PeriodType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="calendarDay" type="xsd:date" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="dayType" type="trd:DayTypeType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="stopPointId" type="trd:TridentIdType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="vehicleJourneyId" type="trd:TridentIdType" minOccurs="0"
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="PTNetworkType">
<xsd:annotation>
PT Network description, and link to all the entry point
for this network in the Data Model.
</xsd:annotation>
<xsd:extension base="trd:TransportNetworkType">
November 2002
D3.7/4 – page 29/71
Version 2.0
D3.7
<xsd:sequence>
<xsd:element name="sourceName" type="xsd:string" minOccurs="0"/>
<xsd:element name="sourceIdentifier" type="xsd:string" minOccurs="0"/>
<xsd:element name="sourceType" type="trd:SourceTypeType" minOccurs="0"/>
<xsd:element name="lineId" type="trd:TridentIdType" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="RoadNetworkType">
<xsd:annotation>
PT Network description, and link to all the entry point
for this network in the Data Model.
</xsd:annotation>
<xsd:extension base="trd:TransportNetworkType">
<xsd:sequence>
<xsd:element name="JunctionId" type="trd:TridentIdType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="RoadElementId" type="trd:TridentIdType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="TransportNetworkType" abstract="true">
<xsd:annotation>
PT Network description, can be for Public Transport or Road Network.
</xsd:annotation>
<xsd:sequence>
<xsd:element name="versionDate" type="xsd:date"/>
<xsd:element name="description" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>

<xsd:complexType name="StatusType">
<xsd:annotation>
Status on PT Network
</xsd:annotation>
<xsd:sequence>
<xsd:element name="phrase" type="trd:PhraseType" minOccurs="0"/>
<xsd:element name="foreCast" type="xsd:boolean" minOccurs="0"/>
<xsd:element name="qualityIndex" type="trd:QualityIndexType" minOccurs="0"/>
<xsd:element name="severity" type="trd:SeverityType" minOccurs="0"/>
<xsd:element name="ptSituationId" type="trd:TridentIdType" minOccurs="0"/>
<xsd:element name="operatorActions" type="trd:OperatorActionsType" minOccurs="0"/>
<xsd:element name="mobility" type="trd:MobilityType" minOccurs="0"/>
<xsd:element name="serviveStatus" type="trd:ServiceStatusType" minOccurs="0"/>
<xsd:choice>
<xsd:element name="vehicleJourneyId" type="trd:TridentIdType"/>
<xsd:element name="stopPointId" type="trd:TridentIdType"/>
November 2002
D3.7/4 – page 30/71
Version 2.0
D3.7
<xsd:element name="ptLinkId" type="trd:TridentIdType"/>
<xsd:element name="lineId" type="trd:TridentIdType"/>
<xsd:element name="networkId" type="trd:TridentIdType"/>
</xsd:choice>
<xsd:element name="vehicleJourneyAtStop" type="trd:VehicleJourneyAtStopType" minOccurs="0"

</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="OperatorActionsType">
<xsd:annotation>
Description of the operator action related to a status
</xsd:annotation>
<xsd:sequence>
<xsd:element name="actionPlanIdentifier" type="xsd:string" minOccurs="0"/>
<xsd:element name="diversionAdvice" type="xsd:boolean" minOccurs="0"/>

</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ServiceStatusType">
<xsd:annotation>
Service status information
</xsd:annotation>
<xsd:sequence>
<xsd:element name="PercentageOfServiceOperating" type="trd:PercentageType" minOccurs="0"/>
<xsd:element name="ServiceStatusValue" type="trd:ServiceStatusValueType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="RelativeTimeType">
<xsd:annotation>
Shift from timetable !
</xsd:annotation>
<xsd:sequence>
<xsd:element name="departureTimeDelayValue" type="xsd:duration" minOccurs="0"/>
<xsd:element name="arrivalTimeDelayValue" type="xsd:duration" minOccurs="0"/>
<xsd:element name="vehicleJourneyId" type="trd:TridentIdType" minOccurs="0"/>
<xsd:element name="vehicleJourneyAtStopId" type="trd:TridentIdType" minOccurs="0"/>
<xsd:element name="ptLinkId" type="trd:TridentIdType" minOccurs="0"/>

</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="RegistrationType">
<xsd:annotation>
Registration informations
</xsd:annotation>
<xsd:sequence>
<xsd:element name="registrationNumber" type="xsd:string" minOccurs="0"/>
<xsd:element name="submissionDate" type="xsd:date" minOccurs="0"/>
<xsd:element name="submissionAuthor" type="xsd:string" minOccurs="0"/>
<xsd:element name="authorPosition" type="xsd:string" minOccurs="0"/>
<xsd:element name="ptNetworkID" type="trd:TridentIdType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="lineId" type="trd:TridentIdType" minOccurs="0" maxOccurs="unbounded"/>
November 2002
D3.7/4 – page 31/71
Version 2.0
D3.7
<xsd:element name="journeyPatternId" type="trd:TridentIdType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="companyId" type="trd:TridentIdType" minOccurs="0"/>

</xsd:sequence>
</xsd:complexType>
</xsd:schema>
November 2002
D3.7/4 – page 32/71
Version 2.0
D3.7
3.3.3 Situation description

version="2.0">
<xsd:annotation>
Situations Definitions
</xsd:annotation>


<xsd:complexType name="SituationQualificationType" abstract="true">
<xsd:annotation>
Qualification for traffic situations
</xsd:annotation>
<xsd:sequence>
<xsd:element name="NumberOfAccident" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="NumberOfIncident" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="Severity" type="trd:SeverityType" minOccurs="0"/>
<xsd:element name="LinkWithOtherSituation" type="trd:TridentIdType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="SituationElementType" abstract="true">
<xsd:annotation>
Situation element, refers to Datex definitions
for road trafic and PT network
</xsd:annotation>
<xsd:sequence>
<xsd:element name="cause" type="trd:PhraseType" minOccurs="0"/>
<xsd:element name="codedDuration" type="trd:CodedDurationType" minOccurs="0"/>
<xsd:element name="elementState">
<xsd:simpleType>
<xsd:enumeration value="Active"/>
<xsd:enumeration value="NotActive"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="phrase" type="trd:PhraseType"/>
<xsd:element name="severity" type="trd:SeverityType" minOccurs="0"/>
<xsd:element name="supplementaryInformation" type="trd:SupplementaryAdviceType" minOccurs="0"
<xsd:element name="indicatorValue" type="ProcessingIndicatorType" minOccurs="0"/>
<xsd:element name="mobility" type="MobilityType" minOccurs="0"/>
<xsd:element name="primaryLocationId" type="TridentIdType" minOccurs="0"/>
<xsd:element name="secondaryLocationId" type="TridentIdType" minOccurs="0"/>
November 2002
D3.7/4 – page 33/71
Version 2.0
D3.7




</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="SituationType">
<xsd:annotation>
A complete situation description
</xsd:annotation>
<xsd:sequence>
<xsd:element name="SituationQualification" type="trd:SituationQualificationType" minOccurs="0"
<xsd:element name="situationElement" type="trd:SituationElementType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="StatusIDType">
<xsd:annotation>
<xsd:documentation>
Sequence of Status identifier
</xsd:annotation>
</xsd:complexType>
<xsd:complexType name="RoadMaintenanceType">
<xsd:annotation>
Description of some road maintenance
</xsd:annotation>
<xsd:extension base="trd:SituationElementType">
<xsd:sequence>
<xsd:element name="positionExtent" type="trd:PositionAndExtentType" minOccurs="0"/>
<xsd:element name="consequence" type="trd:ConsequenceType" minOccurs="0"/>
<xsd:element name="trafficControls" type="trd:TrafficControlsType" minOccurs="0"/>
<xsd:element name="maintenanceDescription" type="trd:MaintenanceDescriptionType" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="TrafficControlsType">
<xsd:annotation>
Description of traffic controls
</xsd:annotation>
<xsd:sequence>
<xsd:element name="numberOfRampControls" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="setsOfTemporaryTrafficLights" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="setsOTrafficLights" type="xsd:nonNegativeInteger" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="MaintenanceDescriptionType">
<xsd:annotation>
Description of maintenance installation
</xsd:annotation>
<xsd:sequence>
<xsd:element name="setOfSlowMovingMaintenanceVehicle" type="xsd:nonNegativeInteger" minOccurs="0"/>
November 2002
D3.7/4 – page 34/71
Version 2.0
D3.7
<xsd:element name="maintenanceVehicle" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="setsOfBlastingWork" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="setsOfConstructionWork" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="setsOfMaintenanceWork" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="setsOfRoadMarkingWork" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="sectionsOfResurfacingWork" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="setsOfRoadWorks" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="numberOfBridges" type="xsd:nonNegativeInteger" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="IncidentType">
<xsd:annotation>
Description of an Incident
</xsd:annotation>
<xsd:sequence>
<xsd:element name="Consequence" type="trd:ConsequenceType" minOccurs="0"/>
<xsd:element name="DangerousGoods" type="trd:DangerousGoodsType" minOccurs="0"/>
<xsd:element name="PositionExtent" type="trd:PositionAndExtentType" minOccurs="0"/>
<xsd:element name="VehicleQuantitative" type="trd:VehicleQuantitativeType" minOccurs="0"/>
<xsd:element name="VehicleSpecific" type="trd:VehicleSpecificType" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="AccidentType">
<xsd:annotation>
Description of an accident
</xsd:annotation>
<xsd:sequence>
<xsd:element name="positionExtent" type="trd:PositionAndExtentType" minOccurs="0"/>
<xsd:element name="dangerousGoods" type="trd:DangerousGoodsType" minOccurs="0"/>
<xsd:element name="vehicleSpecific" type="trd:VehicleSpecificType" minOccurs="0"/>
<xsd:element name="vehicleQuantitative" type="trd:VehicleQuantitativeType" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="VehicleQuantitativeType">
<xsd:annotation>
Description of different numbers of vehicles implicated
</xsd:annotation>
<xsd:sequence>
<xsd:element name="numberOfCaravans" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="numberOfBuses" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="numberOfBrokenDownVehicle" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="numberOfHeavyLorries" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="numberOfHeavyVehicles" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="numberOfShedLoads" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="numberOfVehicles" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="numberOfVehiclesOnFire" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="numberOfTrailers" type="xsd:nonNegativeInteger" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PTIncidentType">
<xsd:annotation>
Description of a situation on the PT Network
November 2002
D3.7/4 – page 35/71
Version 2.0
D3.7
</xsd:annotation>
<xsd:sequence>
<xsd:element name="statusID" type="trd:TridentIdType" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="OtherTCCObjectsType">
<xsd:annotation>
TCC other than Accident and Incident
</xsd:annotation>
<xsd:sequence/>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="WeatherDataType">
<xsd:annotation>
Let's talk about the weather
</xsd:annotation>
<xsd:sequence>
<xsd:element name="precipitationCode" type="xsd:integer" minOccurs="0"/>
<xsd:element name="windDirection" type="trd:CompassPointDirectionType" minOccurs="0"/>
<xsd:element name="surfaceTemperature" type="trd:UnitisedQuantityType" minOccurs="0"/>
<xsd:element name="airTemperature" type="trd:UnitisedQuantityType" minOccurs="0"/>
<xsd:element name="precipitationVolume" type="trd:UnitisedQuantityType" minOccurs="0"/>
<xsd:element name="windSpeed" type="trd:UnitisedQuantityType" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="OtherAMBObjectsType">
<xsd:annotation>
TCC other than Weather
</xsd:annotation>
<xsd:sequence/>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="TRRObjectsType">
<xsd:annotation>
Information on traffic management
</xsd:annotation>
<xsd:sequence/>
</xsd:extension>
November 2002
D3.7/4 – page 36/71
Version 2.0
D3.7
</xsd:complexType>
<xsd:complexType name="OtherRCOObjectsType">
<xsd:annotation>
RCO other than Road Maintenance
</xsd:annotation>
<xsd:sequence/>
</xsd:extension>
</xsd:complexType>
</xsd:schema>
November 2002
D3.7/4 – page 37/71
Version 2.0
D3.7
3.3.4 Road description

version="2.0">
<xsd:annotation>
Road, traffic events ands status Definitions
</xsd:annotation>


<xsd:simpleType name="LaneType">
<xsd:annotation>
<xsd:documentation>
Defines the way Lane ID has to be coded:
H: hard shoulder
1: first lane
2: second lane
N: nth lane
C: central reservation
A or *: all lanes from 1 to n:
I: Entry slip road
O: Exit slip road
S: slip roads
P: parallel carriageway
R: rest or service area
T: toll plaza
When several lanes are concerned, their numbers are put together (e.g. the two left lanes of a 4 lane carriageway are coded 34)
</xsd:annotation>
<xsd:pattern value="[0-9]*[HCAIOSPRT\*]?"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="NationnalityType">
<xsd:annotation>
<xsd:documentation>
Nationnality is an ISO 2-alpha code of the country
a pattern is used here, not a huge enumertaion: refer
to ISO documentation for the full code list
</xsd:annotation>
<xsd:pattern value="\p{L}\p{L}"/>
</xsd:restriction>
</xsd:simpleType>


<xsd:complexType name="TrafficDataType">
November 2002
D3.7/4 – page 38/71
Version 2.0
D3.7
<xsd:annotation>
General traffic data information, refers to
Datex definitions
for road traffic
</xsd:annotation>
<xsd:sequence>
<xsd:element name="trafficDataMeasurementPoint" type="trd:TrafficDataMeasurementPointType"
<xsd:element name="processingIndicator" type="trd:ProcessingIndicatorType" minOccurs="0"/>

</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="TrafficDataMeasurementPointType" abstract="true">
<xsd:annotation>
General traffic measurement description, refers to
Datex definitions
for road traffic
</xsd:annotation>
<xsd:extension base="trd:TrafficDataType">
<xsd:sequence>
<xsd:element name="measurementPointReference" type="trd:TridentIdType" maxOccurs="unbounded"/>
<xsd:element name="measurementTime" type="xsd:dateTime"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="MeasurementPointType">
<xsd:annotation>
General traffic measurement description, refers to
Datex definitions
for road traffic
</xsd:annotation>
<xsd:sequence>
<xsd:element name="dob" type="trd:DataObjectType"/>
<xsd:element name="reference" type="xsd:string" minOccurs="0"/>
<xsd:element name="vehicleClass" type="xsd:string"/>
<xsd:element name="vehicleClassification" type="xsd:string"/>
<xsd:element name="measurementPeriod" type="xsd:duration"/>
<xsd:element name="measurementUnit" type="trd:UnitType"/>
<xsd:element name="measurementEquipmentReference" type="xsd:string"/>
<xsd:element name="measurementPointLocation" type="trd:MeasurementPointLocationType"/>

</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="MeasurementPointLocationType">
<xsd:annotation>
Location description of a Measurement Point, refers to
Datex definitions
for road traffic_
November 2002
D3.7/4 – page 39/71
Version 2.0
D3.7
</xsd:annotation>
<xsd:extension base="trd:AlertCLocationPointType">
<xsd:sequence>
<xsd:element name="lane" type="trd:LaneType"/>
<xsd:element name="measurementSideName" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="AverageSpeedType">
<xsd:annotation>
Measurement of an average speed !!
for road traffic_
</xsd:annotation>
<xsd:extension base="trd:TrafficDataMeasurementPointType">
<xsd:sequence>
<xsd:element name="averageSpeedNumericaValue" type="xsd:decimal" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="ConcentrationType">
<xsd:annotation>
Measurement of an concentration !!
for road traffic_
</xsd:annotation>
<xsd:sequence>
<xsd:element name="concentrationNumericalValue" type="xsd:decimal" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="FlowType">
<xsd:annotation>
Measurement of a flow !
for road traffic_
</xsd:annotation>
<xsd:sequence>
<xsd:element name="axleFlowNumericalValue" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="pcuFlowNumericalValue" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="vehicleFlowNumericalValue" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="ratioOfAVehicleClassInTraficFlow" type="xsd:decimal" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="OccupancyType">
<xsd:annotation>
Measurement of an occupancy
for road traffic_
</xsd:annotation>
November 2002
D3.7/4 – page 40/71
Version 2.0
D3.7
<xsd:sequence>
<xsd:element name="occupancyNumericalValue" type="xsd:decimal" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="IndividualVehicleDataType">
<xsd:annotation>
Measurement of some individual vehicle data
for road traffic_
</xsd:annotation>
<xsd:sequence>
<xsd:element name="distanceGap" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="distanceHeadway" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="travelTimeNumericalValue" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="vehicleSpeed" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="linkTime" type="xsd:duration" minOccurs="0"/>
<xsd:element name="delay" type="trd:DelayType" minOccurs="0"/>
<xsd:element name="detectionTime" type="trd:DetectionTimeType" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="TravelTimeMeasurementType">
<xsd:annotation>
Values for a travel time
for road traffic_
</xsd:annotation>
<xsd:sequence>
<xsd:element name="travelTimeNumericalValue" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="travelTimeIncrease" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="linkTime" type="xsd:duration" minOccurs="0"/>
<xsd:element name="Delay" type="trd:DelayType" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>

<xsd:complexType name="MeasurementPointValueType">
<xsd:annotation>
All the possible values for a measurement Point
for road traffic_
</xsd:annotation>
<xsd:choice>
<xsd:element name="AverageSpeedNumericalValue" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="VehicleSpeed" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="VehicleFlowNumericalValue" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="AxleFlowNumericalValue" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="PCUFlowNumericalValue" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="LinkTime" type="xsd:duration" minOccurs="0"/>
<xsd:element name="TimeGap" type="xsd:duration" minOccurs="0"/>
<xsd:element name="TravelTimeNumericalValue" type="xsd:duration" minOccurs="0"/>
<xsd:element name="TravelTimeIncrease" type="xsd:decimal" minOccurs="0"/>
November 2002
D3.7/4 – page 41/71
Version 2.0
D3.7
<xsd:element name="RatioOfAVehicleClassInTrafficFlow" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="ConcentrationNumericalValue" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="DistanceGap" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="OccupancyNumericalValue" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="DistanceHeadway" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="VehicleLength" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="VehicleWidth" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="VehicleWeight" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="VehicleHeight" type="xsd:decimal" minOccurs="0"/>
</xsd:choice>

</xsd:complexType>
<xsd:complexType name="DetectionTimeType">
<xsd:annotation>
Values for detection Time
for road traffic_
</xsd:annotation>
<xsd:sequence>
<xsd:element name="arrivalTime" type="xsd:dateTime" minOccurs="0"/>
<xsd:element name="exitTime" type="xsd:dateTime" minOccurs="0"/>
<xsd:element name="passageTime" type="trd:UnitisedQuantityType" minOccurs="0"/>
<xsd:element name="presenceTime" type="trd:UnitisedQuantityType" minOccurs="0"/>
<xsd:element name="timeGap" type="trd:UnitisedQuantityType" minOccurs="0"/>
<xsd:element name="timeHeadway" type="trd:UnitisedQuantityType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="DelayType">
<xsd:annotation>
Value and description for a delay
for road traffic_
</xsd:annotation>
<xsd:choice>
<xsd:element name="codedDelayTime">
<xsd:simpleType>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="delayTimeValue" type="xsd:duration"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="AdviceType">
<xsd:annotation>
Available Advice
for road traffic_
</xsd:annotation>
<xsd:sequence>
<xsd:element name="DiversionAdvice" type="xsd:boolean"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="CasualtiesType">
<xsd:annotation>
Information on casualties
for road traffic_
</xsd:annotation>
<xsd:sequence>
November 2002
D3.7/4 – page 42/71
Version 2.0
D3.7
<xsd:element name="numberOfDeaths" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="numberOfInjured" type="xsd:nonNegativeInteger" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="DangerousGoodsType">
<xsd:annotation>
Information on dangerous goods
for road traffic_
</xsd:annotation>
<xsd:sequence>
<xsd:element name="regulation" type="DangerousGoodsRegulationsType" minOccurs="0"/>
<xsd:element name="hasardSubsItem" type="xsd:string" minOccurs="0"/>
<xsd:element name="hasardSubstanceItemPageNumber" type="xsd:string" minOccurs="0"/>
<xsd:element name="hasardCodeVersionNumber" type="xsd:string" minOccurs="0"/>
<xsd:element name="undgNumber" type="xsd:string" minOccurs="0"/>
<xsd:element name="tremCardNumber" type="xsd:string" minOccurs="0"/>
<xsd:element name="chemicalName" type="xsd:string" minOccurs="0"/>
<xsd:element name="dangerousGoodsFlashPoint" type="trd:UnitisedQuantityType" minOccurs="0"/>
<xsd:element name="volumeOfDangerousGoods" type="trd:UnitisedQuantityType" minOccurs="0"/>
<xsd:element name="weightOfDangerousGoods" type="trd:UnitisedQuantityType" minOccurs="0"/>

</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="SpeedLimitType">
<xsd:annotation>
Description of a spped limit
for road traffic_
</xsd:annotation>
<xsd:sequence>
<xsd:element name="mandatorySpeedLimit" type="trd:UnitisedQuantityType" minOccurs="0"/>
<xsd:element name="advisorySpeedLimit" type="trd:UnitisedQuantityType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="QueueType">
<xsd:annotation>
Description of a queue
for road traffic_
</xsd:annotation>
<xsd:sequence>
<xsd:element name="queueLength" type="trd:UnitisedQuantityType" minOccurs="0"/>
<xsd:element name="numberOfWaitingVehicles" type="xsd:nonNegativeInteger" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="CapacityType">
<xsd:annotation>
Available Advice
for road traffic_
</xsd:annotation>
<xsd:sequence>
<xsd:element name="capacityRemaining" type="UnitisedQuantityType" minOccurs="0"/>
<xsd:element name="numberOfLanes" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="numberOfServiceLanes" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="originalNumberOfLanes" type="xsd:nonNegativeInteger" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="DirectionType">
<xsd:annotation>
Description of the direction
for road traffic_
November 2002
D3.7/4 – page 43/71
Version 2.0
D3.7
</xsd:annotation>
<xsd:sequence>
<xsd:element name="directionBearing" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="compassPointDirection" type="trd:CompassPointDirectionType" minOccurs="0"/>

</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PositionAndExtentType">
<xsd:annotation>
Information on the position
for road traffic_
</xsd:annotation>
<xsd:sequence>
<xsd:element name="lane" type="trd:LaneType" minOccurs="0"/>
<xsd:element name="direction" type="trd:DirectionType" minOccurs="0"/>
<xsd:element name="lengthAffected" type="trd:UnitisedQuantityType" minOccurs="0"/>
</xsd:sequence>

</xsd:complexType>
<xsd:complexType name="VehicleSpecificType">
<xsd:annotation>
Information on a specificvehicle
for road traffic_
</xsd:annotation>
<xsd:sequence>
<xsd:element name="individualVehicleIdentifier" type="xsd:string" minOccurs="0"/>
<xsd:element name="nationnality" type="trd:NationnalityType" minOccurs="0"/>
<xsd:element name="typeOfLoad" type="trd:TypeOfLoadType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="vehicleHeight" type="trd:UnitisedQuantityType" minOccurs="0"/>
<xsd:element name="vehicleWidth" type="trd:UnitisedQuantityType" minOccurs="0"/>
<xsd:element name="vehicleWeight" type="trd:UnitisedQuantityType" minOccurs="0"/>
<xsd:element name="vehicleLength" type="trd:UnitisedQuantityType" minOccurs="0"/>
<xsd:element name="VehicleClassification" type="trd:ClassificationType" minOccurs="0"
<xsd:element name="vehicleConfiguration" type="trd:VehicleConfigurationType" minOccurs="0"/>

</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ClassificationType">
<xsd:annotation>
Information vehicle classification
for road traffic_
</xsd:annotation>
<xsd:sequence>
<xsd:element name="vehicleClass" type="xsd:string" minOccurs="0"/>
<xsd:element name="vehicleClassification" type="xsd:string" minOccurs="0"/>
</xsd:sequence>

</xsd:complexType>
<xsd:complexType name="VehicleConfigurationType">
<xsd:annotation>
Description of a vehicle
for road traffic_
</xsd:annotation>
<xsd:sequence>
<xsd:element name="axleClass" minOccurs="0">
<xsd:simpleType>
November 2002
D3.7/4 – page 44/71
Version 2.0
D3.7
<xsd:enumeration value="SingleAxle"/>
<xsd:enumeration value="DualAxle"/>
<xsd:enumeration value="TripleAxle"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="axleNumber" type="xsd:nonNegativeInteger" minOccurs="0"/>
<xsd:element name="AxleWeight" type="trd:UnitisedQuantityType" minOccurs="0"/>
<xsd:element name="AxleSpacing" type="trd:UnitisedQuantityType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ConsequenceType">
<xsd:annotation>
Description some consequences
</xsd:annotation>
<xsd:sequence>
<xsd:element name="delay" type="trd:DelayType" minOccurs="0"/>
<xsd:element name="advice" type="trd:AdviceType" minOccurs="0"/>
<xsd:element name="casualties" type="trd:CasualtiesType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="Queue" type="trd:QueueType" minOccurs="0"/>
<xsd:element name="capacity" type="trd:CapacityType" minOccurs="0"/>
<xsd:element name="VehicleSpecific" type="trd:VehicleSpecificType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="SpeedLimit" type="trd:SpeedLimitType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="JunctionType">
<xsd:annotation>
Description of a road junction (simple...)
</xsd:annotation>
<xsd:sequence>
<xsd:element name="RoadElements" type="trd:TridentIdType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="RoadElementType">
<xsd:annotation>
Description of a Raod Element (simple...)
</xsd:annotation>
<xsd:extension base="trd:GeneralLinkType">
<xsd:sequence>
<xsd:element name="TravelTime" type="trd:UnitisedQuantityType"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
</xsd:schema>
November 2002
D3.7/4 – page 45/71
Version 2.0
D3.7
3.3.5 Location description

version="2.0">
<xsd:annotation>
Location referencing Description
</xsd:annotation>


<xsd:complexType name="LogicalLocationType" abstract="true">
<xsd:annotation>
General description of a logical location (point, area, link,network,line....)
</xsd:annotation>
<xsd:extension base="trd:TridentObjectType"/>
</xsd:complexType>
<xsd:complexType name="LocationType" abstract="true">
<xsd:annotation>
General description of a location (point, area, link)
</xsd:annotation>
<xsd:sequence>
<xsd:element name="alertCExtendedLocationTypeCoded" type="trd:LocationTypeType" minOccurs="0"/>
<xsd:element name="referencingMethod" type="trd:LocationReferencingMethodType" minOccurs="0"/>
<xsd:element name="alertCCode" type="AlertCLocationCodeType" minOccurs="0"/>
<xsd:element name="gdfIdentifier" type="trd:GdfIdentifierType" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>

<xsd:complexType name="AddressType">
<xsd:annotation>
Full Description of an address
</xsd:annotation>
<xsd:sequence>
<xsd:element name="CountryCode" type="xsd:string"/>

</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="RoadAddressType">
<xsd:annotation>
November 2002
D3.7/4 – page 46/71
Version 2.0
D3.7
</xsd:annotation>
<xsd:extension base="trd:AddressType">
<xsd:sequence>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="PostalAddressType">
<xsd:annotation>
</xsd:annotation>
<xsd:extension base="trd:AddressType">
<xsd:sequence>
<xsd:element name="province" type="xsd:string" minOccurs="0"/>
<xsd:element name="region" type="xsd:string" minOccurs="0"/>
<xsd:element name="town" type="xsd:string" minOccurs="0"/>
<xsd:element name="streetName" type="xsd:string" minOccurs="0"/>
<xsd:element name="roadNumber" type="xsd:string" minOccurs="0"/>
<xsd:element name="houseNumber" type="xsd:string" minOccurs="0"/>
<xsd:element name="postalCode" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="PointOfInterestType">
<xsd:annotation>
Description of a point of interest: this is provided if the point is at or near a major landmark or point of interest.
</xsd:annotation>
<xsd:sequence>
<xsd:element name="type" type="trd:POITypeType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="WGS84PositionType">
<xsd:annotation>
Position of a point in WGS 84 Coordinate.
</xsd:annotation>
<xsd:sequence>
<xsd:element name="Longitude" type="trd:LongitudeType"/>
<xsd:element name="Latitude" type="trd:LatitudeType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ProjectedPointType">
<xsd:annotation>
Position of a point in a projection system.
</xsd:annotation>
<xsd:sequence>
<xsd:element name="X" type="xsd:decimal"/>
<xsd:element name="Y" type="xsd:decimal"/>
<xsd:element name="projectionType" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="IlocPlusDescriptorsType">
<xsd:annotation>
November 2002
D3.7/4 – page 47/71
Version 2.0
D3.7
The set of ILOC+ descriptors built out of the Supplier's DB that may help the client to match the same point on its own
database
</xsd:annotation>
<xsd:sequence>
<xsd:element name="wordOrder" type="trd:WordOrderType"/>
<xsd:element name="descriptor1" type="xsd:string"/>
<xsd:element name="descriptor2" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ProprietaryIdentifierType">
<xsd:sequence>
<xsd:element name="id" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="GridReferenceType">
<xsd:annotation>
<xsd:documentation>For grid coordinates</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="northing" type="xsd:string"/>
<xsd:element name="easting" type="xsd:string"/>
<xsd:element name="gridReferenceType" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:annotation>
General point used to build any kind of point
</xsd:annotation>
<xsd:extension base="trd:LocationType">
<xsd:sequence>
<xsd:element name="longitude" type="trd:LongitudeType"/>
<xsd:element name="latitude" type="trd:LatitudeType"/>
<xsd:element name="longLatType" type="LongLatTypeType"/>
<xsd:element name="languageCode" type="xsd:string" minOccurs="0"/>
<xsd:element name="address" type="trd:AddressType" minOccurs="0"/>
<xsd:element name="pointOfInterest" type="trd:PointOfInterestType" minOccurs="0"/>
<xsd:element name="projectedPoint" type="trd:ProjectedPointType" minOccurs="0"/>
<xsd:element name="gridReference" type="GridReferenceType" minOccurs="0"/>
<xsd:element name="ilocPlusDescriptors" type="trd:IlocPlusDescriptorsType" minOccurs="0"/>
<xsd:element name="proprietaryIdentifier" type="trd:ProprietaryIdentifierType" minOccurs="0"/>
<xsd:element name="containedIn" type="trd:TridentIdType" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="PlaceType">
<xsd:annotation>
</xsd:annotation>
<xsd:sequence>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
November 2002
D3.7/4 – page 48/71
Version 2.0
D3.7
<xsd:complexType name="RoadPointType">
<xsd:annotation>
General point used to build any kind of point
</xsd:annotation>
<xsd:sequence>
<xsd:element name="LanguageCode" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="PTAccessPointType">
<xsd:annotation>
The physical (spatial) possibility for a passenger
to access or leave the PT network.
</xsd:annotation>
<xsd:sequence>
<xsd:element name="type" minOccurs="0">
<xsd:simpleType>
<xsd:enumeration value="In"/>
<xsd:enumeration value="Out"/>
<xsd:enumeration value="InOut"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="openingTime" type="xsd:time" minOccurs="0"/>
<xsd:element name="closingTime" type="xsd:time" minOccurs="0"/>
<xsd:element name="mobilityRestrictedSuitability" type="xsd:boolean" minOccurs="0"/>
<xsd:element name="stairsAvailability" type="xsd:boolean" minOccurs="0"/>
<xsd:element name="liftAvailability" type="xsd:boolean" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="NonPTAccessLinkendType">
<xsd:annotation>
An origin place not belonging to the PT network.
</xsd:annotation>
<xsd:sequence>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="StopPointType">
<xsd:annotation>
</xsd:annotation>
<xsd:sequence>
November 2002
D3.7/4 – page 49/71
Version 2.0
D3.7
<xsd:element name="ptNetworkIdShortcut" type="trd:TridentIdType" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="AirportStopPointType">
<xsd:annotation>
An airport
</xsd:annotation>
<xsd:extension base="trd:StopPointType">
<xsd:sequence>
<xsd:element name="terminalIdentifier" type="xsd:string" minOccurs="0"/>
<xsd:element name="gateIdentifier" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="BusStopPointType">
<xsd:annotation>
An bus sopt point
</xsd:annotation>
<xsd:sequence>
<xsd:element name="ptDirection" type="PTDirectionType" minOccurs="0"/>
<xsd:element name="streetNumber" type="xsd:string" minOccurs="0"/>
<xsd:element name="platformIdentifier" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="TramStopPointType">
<xsd:annotation>
An TRAM stop point
</xsd:annotation>
<xsd:sequence>
<xsd:element name="streetNumber" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="MetroStopPointType">
<xsd:annotation>
An metro stop point
</xsd:annotation>
<xsd:sequence>
November 2002
D3.7/4 – page 50/71
Version 2.0
D3.7
<xsd:element name="lineName" type="xsd:string" minOccurs="0"/>
<xsd:element name="lineNumber" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="RailwayStopPointType">
<xsd:annotation>
An Railwaystop point
</xsd:annotation>
<xsd:sequence>
<xsd:element name="stationInternalDivision" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>

<xsd:complexType name="GeneralLinkType">
<xsd:annotation>
A General Link Between two Points (or object inheriting
from Point)
</xsd:annotation>
<xsd:sequence>
<xsd:element name="startOfLink" type="trd:TridentIdType"/>
<xsd:element name="endOfLink" type="trd:TridentIdType"/>
<xsd:element name="linkDistance" type="xsd:decimal" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="ConnectionLinkType">
<xsd:annotation>
The path between two places covered by any "personal" mean of transport
</xsd:annotation>
<xsd:sequence>
<xsd:element name="linkType" type="trd:ConnectionLinkTypeType" minOccurs="0"/>
<xsd:element name="defaultDuration" type="xsd:duration" minOccurs="0"/>
<xsd:element name="frequentTravellerDuration" type="xsd:duration" minOccurs="0"/>
<xsd:element name="occasionalTravellerDuration" type="xsd:duration" minOccurs="0"/>
<xsd:element name="mobilityRestrictedTravellerDuration" type="xsd:duration" minOccurs="0"/>
<xsd:element name="mobilityRestrictedSuitability" type="xsd:boolean" minOccurs="0"/>
<xsd:element name="stairsAvailability" type="xsd:boolean" minOccurs="0"/>
<xsd:element name="liftAvailability" type="xsd:boolean" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="PTAccessLinkType">
<xsd:annotation>
November 2002
D3.7/4 – page 51/71
Version 2.0
D3.7
Link between a StopPoint and an AccessPoint.
</xsd:annotation>
<xsd:extension base="trd:ConnectionLinkType">
<xsd:sequence>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="NonPTAccessLinkType">
<xsd:annotation>
Link between a StopPoint and an AccessPoint.
</xsd:annotation>
<xsd:extension base="trd:ConnectionLinkType">
<xsd:sequence>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="PTLinkType">
<xsd:annotation>
A Link between two StopPoints
</xsd:annotation>
<xsd:sequence>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="CarType">
<xsd:annotation>
The path between two places covered on the road network by a private means of transport (car, truck, etc).
</xsd:annotation>
<xsd:sequence>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>

<xsd:complexType name="AreaType">
<xsd:annotation>
An area made up of a set of Points
</xsd:annotation>
<xsd:sequence>
<xsd:element name="contains" type="trd:TridentIdType" maxOccurs="unbounded"/>
November 2002
D3.7/4 – page 52/71
Version 2.0
D3.7
<xsd:element name="boundaryPoint" type="trd:TridentIdType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="centroidOfArea" type="trd:TridentIdType" minOccurs="0"/>

</xsd:sequence>
</xsd:extension>
</xsd:complexType>

<xsd:complexType name="AlertCLocationPointType">
<xsd:annotation>
Description of all the Alert C Point
</xsd:annotation>
<xsd:sequence>
<xsd:element name="alertCFirstName" type="xsd:string" minOccurs="0"/>
<xsd:element name="alertCDistanceFromPrimaryLocation" type="trd:UnitisedQuantityType"
minOccurs="0"/>
<xsd:element name="alertCDirection" type="trd:AlertCDirectionType" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="AlertCPrimaryLocationPointType">
<xsd:annotation>
Description of all the Alert C primary Point
</xsd:annotation>
<xsd:extension base="trd:AlertCLocationPointType"/>
</xsd:complexType>
<xsd:complexType name="AlertCSecondaryLocationPointType">
<xsd:annotation>
Description of all the Alert C secondary Point
</xsd:annotation>
<xsd:extension base="trd:AlertCLocationPointType"/>
</xsd:complexType>
<xsd:complexType name="ExtentType">
<xsd:annotation>
Extention of an Alert C secondary Point
</xsd:annotation>
<xsd:extension base="trd:AlertCSecondaryLocationPointType">
<xsd:sequence>
<xsd:element name="alertCExtent" type="xsd:integer"/>
<xsd:element name="alertCSecondName" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="AlertCDirectionType">
<xsd:annotation>
Description of all the Alert C Point
</xsd:annotation>
<xsd:sequence>
<xsd:element name="RDSDirection" type="trd:RDSDirectionType"/>
November 2002
D3.7/4 – page 53/71
Version 2.0
D3.7
<xsd:element name="alertCDirectionName" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="AlertCOffsetDistancesType">
<xsd:annotation>
Description of all the Alert C offset distance
</xsd:annotation>
<xsd:sequence>
<xsd:element name="alertCDistanceFromPrimaryLocation" type="trd:UnitisedQuantityType"/>
<xsd:element name="alertCDistanceFromSecondaryLocation" type="trd:UnitisedQuantityType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="AlertCLinkLocationType">
<xsd:annotation>
Link between Alert C Point
</xsd:annotation>
<xsd:sequence>
<xsd:element name="alertCDirection" type="trd:AlertCDirectionType" minOccurs="0"/>
<xsd:element name="alertCOffsetDistance" type="trd:AlertCOffsetDistancesType" minOccurs="0"/>
<xsd:element name="alertCTableReference" type="xsd:string"/>
<xsd:element name="alertCLocationTableVersionNumber" type="xsd:string"/>
</xsd:sequence>
</xsd:extension>

</xsd:complexType>
<xsd:complexType name="AlertCLocationCodeType">
<xsd:annotation>
<xsd:documentation>Description of an Alert C Code ....</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="alertCLocationTableReference" type="xsd:string"/>
<xsd:element name="alertCLocationTableVersionNumber" type="xsd:integer"/>
<xsd:element name="alertCLocationCode" type="xsd:integer"/>
<xsd:element name="alertCSubTypeCode" type="xsd:string"/>
<xsd:element name="areaReference" type="xsd:integer" minOccurs="0"/>
<xsd:element name="linearReference" type="xsd:integer" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="GdfIdentifierType">
<xsd:annotation>
<xsd:documentation>Description of a GDF road Network: this is provided if the Supplier can match the point on a
GDF digital cartography.
</xsd:annotation>
<xsd:sequence>
<xsd:element name="dsetId" type="xsd:integer"/>
<xsd:element name="sectId" type="xsd:integer"/>
<xsd:element name="featItemId" type="xsd:integer"/>
<xsd:element name="featCategory" type="xsd:integer"/>
<xsd:element name="provider" type="xsd:string"/>
<xsd:element name="version" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
November 2002
D3.7/4 – page 54/71
Version 2.0
D3.7
3.3.6 Trip description

<xsd:schema targetNamespace="http://www.trident.org/schema/trident" xmlns:trd="http://www.trident.org/schema/trident"
xmlns="http://www.trident.org/schema/trident" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" version="2.0">
<xsd:annotation>
Trip/travel description _
</xsd:annotation>

<xsd:simpleType name="OptimisationType">
<xsd:annotation>
Enumeration containing all the possible transport modes
</xsd:annotation>
<xsd:enumeration value="MinTravelDuration"/>
<xsd:enumeration value="MinTravelDistance"/>
<xsd:enumeration value="MinWalkingDuration"/>
<xsd:enumeration value="MinNumOfTransfers"/>
<xsd:enumeration value="MinTravelCost"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="NonPTAccessLinkTypeType">
<xsd:annotation>
Enumeration containing all the possible type of non PT access link
</xsd:annotation>
</xsd:restriction>
</xsd:simpleType>


<xsd:complexType name="TripTimeType">
<xsd:sequence>
<xsd:element name="dataObject" type="DataObjectType"/>
<xsd:element name="phrase" type="PhraseType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ItineraryType">
<xsd:annotation>
Description of an Itinerary on PT network.
</xsd:annotation>
November 2002
D3.7/4 – page 55/71
Version 2.0
D3.7
<xsd:sequence>
<xsd:element name="bookingReferenceIdentifier" type="xsd:string" minOccurs="0"/>
<xsd:element name="subjectOfItinerary" type="xsd:string" minOccurs="0"/>
<xsd:element name="transportModeName" type="TransportModeNameType" minOccurs="0"
<xsd:element name="optimisationType" type="trd:OptimisationType" minOccurs="0"
<xsd:element name="originPlace" type="trd:LocationType"/>
<xsd:element name="destinationPlace" type="trd:LocationType"/>
<xsd:element name="travellerDepartureTime" type="xsd:date" minOccurs="0"/>
<xsd:element name="travellerDepartureTime" type="xsd:time" minOccurs="0"/>
<xsd:element name="tripSegments" type="TripSegmentType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="TripSegmentType">
<xsd:annotation>
Description of trip segment.
</xsd:annotation>
<xsd:sequence>
<xsd:element name="tripTime" type="xsd:duration"/>
<xsd:element name="ride" type="trd:RideType"/>

</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="RideType">
<xsd:annotation>
Description of a ride on a line.
</xsd:annotation>
<xsd:sequence>
<xsd:element name="lineId" type="trd:TridentIdType"/>
<xsd:element name="actualRideDuration" type="xsd:duration" minOccurs="0"/>
<xsd:element name="scheduledRideDuration" type="xsd:duration" minOccurs="0"/>
<xsd:element name="forecastRideDuration" type="xsd:duration" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
</xsd:schema>
November 2002
D3.7/4 – page 56/71
Version 2.0
D3.7
3.3.7 Requests and Answers
This is the mapping of requests and answers from the D3.3/2.

version="2.0">
<xsd:annotation>
Request / Answer schema
</xsd:annotation>


<xsd:simpleType name="RequestedVersionType">
<xsd:annotation>
All the way to request for a specific version
</xsd:annotation>
<xsd:enumeration value="rvAllVersions"/>
<xsd:enumeration value="rvThisVersion"/>
<xsd:enumeration value="rvLatestVersion"/>
<xsd:enumeration value="rvFirstVersion"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ObjectChildrenType">
<xsd:annotation>
All the way to request for children of an object
</xsd:annotation>
<xsd:enumeration value="AllChildren"/>
<xsd:enumeration value="Network_StopPoint"/>
<xsd:enumeration value="Network_Line"/>
<xsd:enumeration value="Network_Route"/>
<xsd:enumeration value="Network_StopArea"/>
<xsd:enumeration value="Network_PTAccessLink"/>
<xsd:enumeration value="Network_NonPTAccessLink"/>
<xsd:enumeration value="Network_ConnectionLink"/>
<xsd:enumeration value="Line_Route"/>
<xsd:enumeration value="Route_StopPoint"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="WhichStopPointsType">
<xsd:annotation>
All the way to to select a stop point
November 2002
D3.7/4 – page 57/71
Version 2.0
D3.7
</xsd:annotation>
<xsd:enumeration value="All"/>
<xsd:enumeration value="AllWithinRadius"/>
<xsd:enumeration value="Nearest"/>
<xsd:enumeration value="NearestWithinRadius"/>
</xsd:restriction>
</xsd:simpleType>


<xsd:complexType name="RequestObjectType">
<xsd:sequence>
<xsd:element name="requestedVersion" type="trd:RequestedVersionType"/>
<xsd:element name="objectReference" type="trd:ObjectReferenceType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="ResponseObjectType">
<xsd:sequence>
<xsd:element name="objects" type="trd:TridentObjectType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>


<xsd:complexType name="RequestObjectChildrenType">
<xsd:sequence>
<xsd:element name="objectChildren" type="trd:ObjectChildrenType" minOccurs="0"/>
<xsd:element name="wholeObjectTree" type="xsd:boolean" minOccurs="0"/>
<xsd:element name="objectReference" type="trd:ObjectReferenceType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="ResponseObjectChildrenType">
<xsd:sequence>
<xsd:element name="objects" type="trd:TridentObjectType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>


<xsd:simpleType name="ItineraryDetailLevel">
<xsd:annotation>
<xsd:documentation>Detail Level requested for an itinerary</xsd:documentation>
</xsd:annotation>
<xsd:enumeration value="PrivateOnly"/>
<xsd:enumeration value="PublicOnly"/>
<xsd:enumeration value="Intermodal"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ItineraryTypeType">
<xsd:annotation>
Type of a requested Itinerary
</xsd:annotation>
<xsd:enumeration value="HighLevel"/>
<xsd:enumeration value="LowLevel"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ItineraryResultType">
<xsd:annotation>
Result type of a requested Itinerary
</xsd:annotation>
<xsd:enumeration value="Found"/>
<xsd:enumeration value="NotFound"/>
</xsd:restriction>
November 2002
D3.7/4 – page 58/71
Version 2.0
D3.7
</xsd:simpleType>
<xsd:complexType name="RequestItineraryType">
<xsd:sequence>
<xsd:element name="itineraryType" type="trd:ItineraryTypeType" minOccurs="0"/>
<xsd:element name="optimisation" type="trd:OptimisationType"/>
<xsd:element name="travellerDepartureTime" type="xsd:dateTime" minOccurs="0"/>
<xsd:element name="travellerArrivalTime" type="xsd:dateTime" minOccurs="0"/>
<xsd:element name="origin" type="trd:PointType"/>
<xsd:element name="destination" type="trd:PointType"/>
<xsd:element name="vias" type="trd:PointType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="ResponseItineraryType">
<xsd:sequence>
<xsd:element name="itinerary" type="trd:ItineraryType" minOccurs="0"/>
<xsd:element name="itineraryResult" type="trd:ItineraryResultType"/>
</xsd:sequence>
</xsd:complexType>


<xsd:complexType name="FilterSituationsType">
<xsd:sequence>
<xsd:element name="phrases" type="trd:PhraseType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="network" type="trd:ObjectReferenceType"/>
<xsd:element name="logicalLocation" type="trd:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="physicalLocation" type="trd:LocationType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="RequestSituationsType">
<xsd:sequence>
<xsd:element name="filters" type="trd:FilterSituationsType"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="ResponseSituationsType">
<xsd:sequence>
<xsd:element name="situations" type="trd:SituationType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>


<xsd:complexType name="RequestNetworkListType">

</xsd:complexType>

<xsd:complexType name="ResponseNetworkListType">
<xsd:sequence>
<xsd:element name="network" type="TransportNetworkType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>


<xsd:complexType name="RequestMeasurementPointsType">
<xsd:sequence>
<xsd:element name="locations" type="trd:LocationType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="ResponseMeasurementPointsType">
<xsd:sequence>
<xsd:element name="measurementPoints" type="trd:MeasurementPointType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>


<xsd:complexType name="RequestRTDataType">
<xsd:sequence>
<xsd:element name="measurementPoints" type="ObjectReferenceType" maxOccurs="unbounded"/>
November 2002
D3.7/4 – page 59/71
Version 2.0
D3.7
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="ResponseRTDataType">
<xsd:sequence>
<xsd:element name="rtData" type="TrafficDataType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>


<xsd:complexType name="RequestPTStopPointsType">
<xsd:sequence>
<xsd:element name="whichStopPoints" type="trd:WhichStopPointsType"/>
<xsd:element name="radius" type="xsd:decimal" minOccurs="0"/>
<xsd:element name="networkId" type="trd:ObjectReferenceType"/>
<xsd:element name="point" type="trd:PointType"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="ResponsePTStopPointsType">
<xsd:sequence>
<xsd:element name="stopPoint" type="trd:StopPointType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>


<xsd:complexType name="RequestTimetableType">
<xsd:sequence>
<xsd:choice>
<xsd:element name="logicalLocations" type="ObjectReferenceType"/>
<xsd:element name="stopPoints" type="ObjectReferenceType"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="ResponseTimetableType">
<xsd:sequence>
<xsd:element name="timetable" type="trd:TimetableType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>


<xsd:complexType name="RequestPTStatusType">
<xsd:sequence>
<xsd:element name="networkId" type="trd:ObjectReferenceType"/>
<xsd:element name="logicalLocations" type="trd:ObjectReferenceType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="ResponsePTStatusType">
<xsd:sequence>
<xsd:element name="status" type="trd:StatusType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>




<xsd:element name="RequestObject" type="trd:RequestObjectType"/>
<xsd:element name="RequestObjectChildren" type="trd:RequestObjectChildrenType"/>
<xsd:element name="RequestNetworkList" type="trd:RequestNetworkListType"/>
<xsd:element name="RequestPTStopPoints" type="trd:RequestPTStopPointsType"/>
<xsd:element name="RequestTimetable" type="trd:RequestTimetableType"/>
<xsd:element name="RequestPTStatus" type="trd:RequestTimetableType"/>
<xsd:element name="RequestItinerary" type="trd:RequestItineraryType"/>
<xsd:element name="RequestSituation" type="trd:RequestSituationsType"/>
<xsd:element name="RequestMeasurementPoints" type="trd:RequestMeasurementPointsType"/>
<xsd:element name="RequestRTData" type="trd:RequestRTDataType"/>

November 2002
D3.7/4 – page 60/71
Version 2.0
D3.7
<xsd:element name="ResponseObject" type="trd:ResponseObjectType"/>
<xsd:element name="ResponseObjectChildren" type="trd:ResponseObjectChildrenType"/>
<xsd:element name="ResponseNetworkList" type="trd:ResponseNetworkListType"/>
<xsd:element name="ResponsePTStopPoints" type="trd:ResponsePTStopPointsType"/>
<xsd:element name="ResponseTimetable" type="trd:ResponseTimetableType"/>
<xsd:element name="ResponsePTStatus" type="trd:ResponsePTStatusType"/>
<xsd:element name="ResponseItinerary" type="trd:ResponseItineraryType"/>
<xsd:element name="ResponseSituation" type="trd:ResponseSituationsType"/>
<xsd:element name="ResponseMeasurementPoints" type="trd:ResponseMeasurementPointsType"/>
<xsd:element name="ResponseRTData" type="trd:ResponseRTDataType"/>
</xsd:schema>
November 2002
D3.7/4 – page 61/71
Version 2.0
D3.7
3.3.8 Example of exchange schema
The following example shows how to built a schema, from the above TRIDENT definition,
to exchange information on a Stop Point. The way to built this example can be applied for
the exchange of any kind of information defined above.
<xsd:schema targetNamespace="http://www.trident.org/schema/trident" xmlns:trd="http://www.trident.org/schema/trident"
xmlns="http://www.trident.org/schema/trident" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" version="2.00">
<xsd:annotation>
Simple sample schema for TRIDENT stop pointt exchange
</xsd:annotation>

<xsd:element name="MyPoint" type="trd:StopPointType"/>
</xsd:schema>
3.3.9 Example of a resulting XML file
A resulting XML stream/file, from the above schema, could then be something like:

<MyPoint xmlns="http://www.trident.org/schema/trident" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
My_StopPoint.xsd">
<objectId>RATP:StopPoint:1234</objectId>
<objectVersion>2</objectVersion>
<creationTime>2001-09-11T09:30:47</creationTime>
<expiryTime>2003-09-11T09:30:47</expiryTime>
<creatorId>RATP</creatorId>
<validityPeriod>
<start>2001-09-11T09:30:47</start>
<end>2002-09-11T09:30:47</end>
</validityPeriod>
<alertCExtendedLocationTypeCoded>BusStopPoint</alertCExtendedLocationTypeCoded>
<referencingMethod>1</referencingMethod>
<longitude>121.23</longitude>
<latitude>60.65</latitude>
<longLatType>WGS84</longLatType>
<name>My Stop Point</name>
<lineIdShortcut>RATP:Line:1234</lineIdShortcut>
November 2002
D3.7/4 – page 62/71
Version 2.0
D3.7
<ptNetworkIdShortcut>RATP:PTNetwork:5</ptNetworkIdShortcut>
<comment>This is a sample Stop Point</comment>
</MyPoint>
November 2002
D3.7/4 – page 63/71
Version 2.0
D3.5 & D3.7
Final Specifications for the Object Oriented & EDI Approach
D3.5 & D3.7/Annex A – Multimodal Traffic and Travel Data
Dictionary
TRIDENT
Multimodal Traffic and Travel Data Dictionary
Annex A to Deliverables D3.5 and D3.7
Version 2.0
7 November 2002
Produced by:
TRIDENT Consortium
November 2002
D3.5 & D3.7/4 – page 1/97
Version 2.0
D3.5 & D3.7
Dictionary
Activity name:
TRIDENT
Work area:
WP3 / WG1
Document title:
Multimodal Traffic and Travel Data Dictionary
Document number:
D3.5 and D3.7 Annex A
Electronic reference :
D:\DATA\DONNEES\Trident\Data dictionary\TRIDENT D3
Annex A- v2.0.doc
Michel Liger (CETE Mediterranée)
Version history
Version
Date
Main author
Summary of changes
working draft
1
03/10/2000
Michel Liger (CETE
Mediterranée)
---
working draft
1.1
07/03/2001
Michel Liger
Inputs from the consortium (Various meetings)
working draft
1.2
21/03/2001
Michel Liger
Various changes
1.0
9/08/2001
Michel Liger
Inputs from the consortium (Various meetings)
1.2
11/10/2001
Michel Liger
New name syntax, consistency with data model
1.3
26/4//2002
Michel Liger
Additions of phrases for PT, various changes
2.0
10/10/2002
Michel Liger
Merge of tables 2.3 and 12, various changes
November 2002
D3.5 & D3.7/4 – page 2/97
Version 2.0
D3.5 & D3.7
Dictionary
CONTENT LIST
1
FOREWORD [INFORMATIVE] ...................................................................... 4
2
INTRODUCTION [INFORMATIVE] ................................................................ 5
3
SCOPE[NORMATIVE] ................................................................................... 6
4
NORMATIVE REFERENCES ........................................................................ 7
5
PRESENTATION OF THE DICTIONARY ITEMS .......................................... 8
5.1
5.2
5.3
5.4
5.5
5.6
RELATIONSHIP BETWEEN TRIDENT, DATEX AND TRANSMODEL ............................ 8
GENERAL DEFINITIONS .................................................................................... 8
ENTITIES........................................................................................................ 9
ATTRIBUTES ................................................................................................. 10
TABLES OF ENTITIES, ATTRIBUTES AND UNITS .................................................. 12
PRESENTATION OF PHRASES AND SUPPLEMENTARY INFORMATION FOR EDI AND OO
63
6
CLASSIFICATIONS OF VEHICLES [NORMATIVE] .................................... 91
7
RELATIONSHIP BETWEEN DATA OBJECTS AND ATTRIBUTES
[INFORMATIVE]........................................................................................... 92
8
USER GUIDE FOR THE EDI APPROACH [INFORMATIVE]...................... 93
8.1
8.2
8.3
8.4
8.5
8.6
TRAFFIC AND TRAVEL SITUATIONS ................................................................. 93
UNDERSTANDING AND USING THE DATA DICTIONARY ....................................... 93
MESSAGE MANAGEMENT ISSUES ................................................................... 93
DEVELOPING ATRAFFIC AND TRAVEL DATABASE USING THE DATA DICTIONARY . 93
PHRASES AND CAUSES .................................................................................. 93
HOW TO LINK INFORMATION ........................................................................... 94
ANNEX 1 TRANSMODEL DATA DEFINITION (EXCERPTS OF ENTITIES USED IN
TRIDENT) .................................................................................................... 95
November 2002
D3.5 & D3.7/4 – page 3/97
Version 2.0
D3.5 & D3.7
Dictionary
1 Foreword
[informative]
[This clause substitutes Clause 1 in the reference document DATEX Data Dictionary v3.1a]
This paper has been prepared by the TRIDENT consortium as a proposal of amendment to the ENV
13106:2000 Datex traffic and travel data dictionary (version 3.1a). This proposal relates to the EDI
and object-orientated approaches of the TRIDENT specifications.
The above mentioned ENV has been voted and accepted as a standard in 2000. This draft aims at
expanding the DATEX data dictionary towards multimodality and to the use of object oriented
technology.
November 2002
D3.5 & D3.7/4 – page 4/97
Version 2.0
D3.5 & D3.7
Dictionary
2 Introduction
[informative]
[This clause substitutes Clause 2 in the reference document DATEX Data Dictionary v3.1a]
Information system applications are increasingly interconnected. A predominant trend towards
standardisation has been a major theme throughout DRIVE and its successors, which is found in
national projects as well. The minimum need for project interoperability is a common dictionary.
This is why the DATEX Task since its creation in the ATT programme released several versions of
the Traffic/Travel Data Dictionary which have been provided to the CEN WG8 as working
documents and became the basis of the Data Dictionary [REF1]
In the mean time, technologies have evolved and a strong trend towards multimodal travel
information has lead to new concepts. Hence the EU TRIDENT project which has worked out a
DATEX extension to multimodality and newer technologies.
This draft is compatible with ENV 12896:1997 [REF2] Transmodel. It uses a part of the
Transmodel concepts, adds entities and attributes, but does not modify the ENV definitions.
This dictionary has a triple aim:
(i)
it serves general purposes, by enabling a normative common understanding of data and
information and proposing informative pre-defined codes, units and formats for system
design,
(ii)
it is to be used as a companion book of the EDI approach of the DATEX-Net
Specifications for Interoperability, an ENV in data/information exchange.
(iii)
it is to be used as a companion book of theEDI and object-oriented approaches of the
TRIDENT specifications, proposed for standardisation in data/information exchange.
For this reason this prENV contains common normative elements and specific informative parts.
One of the key decisions within the project regarding the format of this document is to numerate
chapters following the same numeration of the reference document of the DATEX Data Dictionary
(ENV13106:2000). This decision simplifies the recognition of which additions and modifications
have been introduced against the reference document. Obviously the final ENV would incorporate
the full clauses whether modified or not.
At the beginning of each Chapter or Section a bracketed message tells which changes, if any, have
been introduced in the Chapter or Section.
Note: all tables are sorted by alphabetical order of Full Names. All new items, i.e. introduced
by Trident in the Datex dictionary, are in bold.
November 2002
D3.5 & D3.7/4 – page 5/97
Version 2.0
D3.5 & D3.7
Dictionary
3 Scope[normative]
[This clause substitutes Clause 3 of the reference document DATEX Data Dictionary v3.1a]
This standard defines terms used for data and information in the fields of traffic and travel. The
standard is applicable to traffic and transport engineering in general, and particularly data and
information exchange.
This prENV is expected to supersede ENV 13106:2000.
The normative terminology is provided in tables 1 to 4. Table 1 provides general definitions; it is
normative. Table 2 lists the data objects, classes and attributes with their definitions, values, units,
data type, field width and default format. The columns of table 2 have various statuses which are
defined in paragraph 5.3. This table mixes up the entities used for the EDI and OO approaches.
Table 3 provides a list of units, partially based on Edifact, given as informative.
Tables 4 and 5 list the instances of the attributes phrase, cause and supplementary information, a
majority of which are Alert C and copied from [REF3] Only the names and definitions are
normative.
Clause 6 gives normative information on vehicles classes and classification. These vehicle classes
and classifications need not be used in electronic tolling and automatic fee collection systems,
during the time that a European classification standard for such systems is being determined. This
clause is identical to REF1 and contains tables 6 to 10 (numbers 7 to 11 in the ENV).
Clause 7 which defined the relationship between data objects and attributes, for information only,
has been deleted and replaced by the data models provided in the specifications.
To help understanding and using the dictionary a User Guide for the EDI approach is provided in
Clause 8. Its content, including the simplified data model for the data object approach, is
informative.
This document is comprehensive, but it is recognised that extra requirements for dictionary entries
will exist. In this case, new codes can be used. However, in order to keep the standard up-to-date,
and to avoid inappropriate usage, it is requested that all additional codes are reported to the CEN
TC278 secretariat and not used before registration. All such additions will then be included in the
formal maintenance of the standard.
November 2002
D3.5 & D3.7/4 – page 6/97
Version 2.0
D3.5 & D3.7
Dictionary
4 Normative references
[ This Clause substitutes clause 4 of the reference document DATEX Data Dictionary v3.1a]
[REF1]
[REF2]
[REF3]
ENV 13106:2000
Datex traffic and travel data dictionary (version 3.1a)
ENV 12896:1997
Public transport - Reference data model
ENV 12313-2:1997 Traffic and Travel Information (TTI) - TTI Messages via traffic
message coding - Part 2: Event and information codes for Traffic Message Channel
(RDS-TMC)
November 2002
D3.5 & D3.7/4 – page 7/97
Version 2.0
D3.5 & D3.7
Dictionary
5 Presentation of the dictionary items
[This clause substitutes Clause 5 of the reference document DATEX Data Dictionary v3.1a]
5.1 Relationship between Trident, Datex and Transmodel
The ENV 13106 :2000, version 3.1a of the Datex Traffic/Travel Data Dictionary, is the basis of this
Trident dictionary.
Datex proposed a double-aim dictionary, both containing general definitions and details for the
Datex data exchange based on Edifact. The ENV only dealt with traffic information.
This Trident dictionary contains the same information and adds new information in two ways :
•
Trident proposes an object-oriented approach
• Trident expands the Datex domain to public transport and multimodal information
Those extensions have several consequences:
•
The extension to multimodality is defined partly for the EDI and fully for the OO
approaches. Table 2 contains all the classes, data objects and attributes definitions and
other features like values, and is designed for EDI and OO.
•
Trident builds on Transmodel which it expands to data exchange and to other transport
modes. Transmodel is based on the entity-relationship modelling, while Trident
provides an object-oriented modelling in UML.
•
The entities from Transmodel are not defined in this dictionary in order not to duplicate
this standard. However to help using the Trident dictionary and make it clear which
Transmodel version has been used, a Transmodel document is reproduced as an annex
to this document. The Transmodel version, as available on the Web site is referred to as
CEN prENV 00278021, version 4.1.1, Annex A1. We also used Annex A2 which gives
the attributes for each entity.
5.2 General definitions
Table 1 provides a general terminology used in the data dictionary. The entity “Object Set” has
been deleted from the dictionary. The new items are in bold.
Table 1 Glossary of general definitions (normative)
Coded name
for EDI
ATT
Full Name
Definition
Access
Module
A piece of software implementing one of the interfaces towards the services
implemented by the Peer
Attribute ; Data
Item
Elementary information that may characterise entities or messages. Examples: a message
number may be used as an attribute of a message; a vehicle class may be used as an
attribute of an entity “vehicle”.
A synonym commonly used is data item
November 2002
D3.5 & D3.7/4 – page 8/97
Version 2.0
D3.5 & D3.7
Coded name
for EDI
DOB
ENT
Full Name
A logically related set of traffic/travel data e.g. “level of service”.
Any type of “thing” in the real world (abstract or concrete) about which information is
maintained. An entity is characterised by attributes
Function
One of the high-level operations that are allowed and put into operation on
the Marketplace and that can be accessed by the Peers.
The logic environment which allows and sustains the exchange of (traffic and
travel) Information.
The hardware equipment hosting the communication software of a Peer. The
Network connects Nodes.
An actor which implements and is entitled to access one or more of the
Functions of the Marketplace.
Node
Peer
PT Operator
The operator of one or more public transport vehicle journey(s).
Pull Function
A Function which is activated by a Client when placing to a Supplier a
Request which is supposed to be answered immediately.
A Function which is activated by a Client when placing a Request that is
supposed to be stored on the Supplier’s.
A Request is a well-formed demand for Information that is forwarded by a
Client to a Supplier.
Clients expect that each Request is answered by one or more Responses
containing the Requested Information.
Push
Function
Request
Response
SEL
Definition
Data Object
Entity
Marketplace
PTO
Dictionary
Situation
Element
A traffic/travel circumstance related to one data object and one location.
Subscription
Telecom
Network
A Request that was registered on a Supplier’s system.
The hardware and software infrastructure – network equipment, software
communication subsystem, etc. – that supports the communication between
Peers.
UPC
Traffic
Equipment
Traffic Operator
Traffic/Travel
Message
Traffic/Travel
Situation
Update Class
VER
Version
Any equipment used to measure traffic or influence it, or to be used by end users: e.g.
variable message signs, traffic signals, emergency call boxes, measurement outstation, etc.
An organisation responsible for the operation of part or whole of a transport network.
Traffic/travel information being exchanged between two systems, characterising the
traffic/travel situation, or giving other relevant (e.g.. supporting) information.
A set of traffic/travel circumstances linked by a causal relationship which apply to a
common set of locations. A situation can be composed of situation elements.
A group of mutually exclusive phrases, used in Alert C applications for transmitter and
receiver management
A snapshot of the situation at a point in time. It is characterised by a set of attributes,
which collectively give details of the traffic/travel situation.
TEQ
TOP
TME
TTS
5.3 Entities
The basic entity is the data object in the EDI approach, on which data (attributes) are collected. In
the OO approach the corresponding concept is “class”.
Table 2 “List of classes, data objects and attributes (normative)”, collects:
•
the Datex data objects and the multimodal data objects created by Trident
November 2002
D3.5 & D3.7/4 – page 9/97
Version 2.0
D3.5 & D3.7
Dictionary
•
the classes created by Trident for public and multimodal transport
•
the attributes providing information on the above entities
A Trident class includes the EDI data objects plus classes not used in EDI, due to the fact that
Trident has developed more public transport data in OO than in EDI.
The data object FER Ferries/Trains is deleted. The definition of the data object PAR Car park is
modified. Numerous data objects are created including a number that are Transmodel entities
5.4 Attributes
Attributes give information on objects and on message and information management.
Table 2 can be used for 2 applications:
1. General definition of terms
2. Data exchange using the DATEX-Net specifications in the EDI approach and the Trident
specifications in both EDI and OO approaches.
The classification in data and management defined in the column “ function” in ENV 13106:2000
has been deleted.
More information is provided on the relationship attribute/data object in the data model for EDI in
the specifications
The columns of table 3 have various statuses:
•
the full name and definition are normative,
•
the coded name is normative for Edifact-based data exchange. When another exchange method
is preferred, e.g. object-oriented (OO), it need not be used,
•
the attribute values are normative.
•
the attribute units and unit codes are informative
•
the data type, field width, and default format only concern EDI and are informative
•
the status in EDI specifies whether the entity is used in EDI, either as a data object (DOB) or as
an attribute (ATT); in any case all entities are defined and usable in OO. When the cell is void
the entity is only used in OO.
In Trident we have adopted the Camel naming convention:
UCC - Upper Camel Case
All Objects/Classes are named as follows:
ThisIsAnObject
LCC - Lower Camel Case
All attributes are named as follows:
November 2002
D3.5 & D3.7/4 – page 10/97
Version 2.0
D3.5 & D3.7
Dictionary
thisIsAnAttribute
Words are concatened and the distinction between classes/data objects and attributes is done using
upper and lower case letters of the first word.
November 2002
D3.5 & D3.7/4 – page 11/97
Version 2.0
D3.5 & D3.7
Dictionary
5.5 Tables of entities, attributes and units
Table 2 List of classes, data objects and attributes (normative)
Coded
name
for
EDI
FullName
ALG
ACC
AboveStatedAltitu
de
Accident
ACU
accuracy
API
APL
Definition
Values
Status
in EDI
EDI
Data
type/fi
eld
width
n..6
Default
format for
EDI
ATT
n..3
NNN
ATT
an..35
(d): default unit
An altitude above which an event is expected or is occurring, normally weather
related.
Situations in which one or more vehicles lose control and do not recover. They include
collisions between vehicle(s) or other transport network user(s), between vehicle(s)
and obstacle(s).
The extent to which data may be subject to error. It can be indicated by the relative
value, or an absolute value
accuracyRange
The extent of values which a data is expected to fall in.
actionPlanIdentifie
r
actionPlans
The code or identifier of an action plan.
Metre: MTR
Percentage: PER (d)
Action plans are pre-planned regulations or schemes, which are prepared and
implemented by the authorities or by a traffic operator. Action plans are triggered
either on a periodic basis (e.g. yearly, weekly) or according to operational criteria.
Deliberate human actions external to the traffic stream which could disrupt traffic.
NNNNNN
DOB
activities
SPA
Advice
advisorySpeedLim
its
Any advice provided to motorists
The temporary maximum speed advised as a consequence of the traffic/travel situation.
airportName
The name of an airport
AirportStopPoint
A stop point in an airport
airTemperature
The air temperature measured in the shade between 1,5 and 2 metres above ground
level.
November 2002
D3.5 & D3.7/4 – page 12/97
ATT
DOB
Text
ACT
ATE
unit(s) codes
DOB
Version 2.0
KilometrePerHour:
KMH
ATT
n..6
NNNNNN
DegreesCelsius:
CEL
ATT
n..3
NNN
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
ARR
alertCAreaReferen
ce
ALERT C location code of an Area referred to by an other ALERT C location code.
RDS-TMC uses a hierarchical structure of pre-defined locations
Note: a system of pointers provides upward references to higher-level locations
containing the specified locations
AlertCDirection
alertCDirection,Na
med
alertCDistanceFro
mPrimaryLocation
The road direction as defined in Alert C
ALERT C name of a direction e.g. Brussels -> Lille
When using ALERT C location referencing: distance to the primary location of a
situation
Positive Integer
aLERTCDistanceF
romSecondaryLoc
ation
alertCExtendedLo
cationTypeCode
when using ALERT C location referencing: distance to the secondary location of a
situation
Positive integer
ALERT C location-type and sub-type defined in ENV ISO 14819-3:2000, extended to
the ILOC+ proposal (cf. Annex B to Trident specifications)
ILOC+ extensions are:
LDN
DPL
DSL
ELT
Definition
Values
ATT
EDI
Data
type/fi
eld
width
n..5
ATT
an..70
Metre: MTR
ATT
n..6
Metre: MTR
ATT
n..6
ATT
an..5
unit(s) codes
Status
in EDI
(d): default unit
November 2002
D3.5 & D3.7/4 – page 13/97
P3.48 BusStopPoint
P3.27 AirportStopPoint
P3.50 RailwayStopPoint
P3.51 MetroStopPoint
P3.52 TramStopPoint
P3.54 PTAccessPoint
P3.52 Address
P3.53 POI
P2.00 IntermediateRoadPoint
L7.00 Road link
L8.00 PTLink
L8.01 PTAccessLink
P8.02 Ride
P8.03 ConnectionLink
P9.00 NonPTAccessLink
Version 2.0
Default
format for
EDI
NNNNN
D3.5 & D3.7
Coded
name
for
EDI
FullName
LEX
alertCExtent
LFN
ITC
UPR
LCO
LTN
LTV
NEG
Dictionary
ATT
EDI
Data
type/fi
eld
width
n..2
ATT
ATT
an..35
an..8
ATT
n..5
ATT
n..5
Number allocated to an ALERT C table in a country. Ref. prENV12313-3 for the
allocation of a location table number
Version number associated to an ALERT C table reference
ATT
an..3
ATT
n..6
In case of segment or point location: ALERT C location of the subsequent segment or
point (referring to the positive direction adopted in a conventional way when coding
the locations)
ATT
n..5
Definition
Values
unit(s) codes
Status
in EDI
(d): default unit
Extent measures how far a situation spreads. It is the number of steps (number of predefined location codes) along the road, from a pre-defined primary location, through
other pre-defined locations, to reach the pre-defined secondary location. It is composed
of a sign (+ or-) and a number of steps. The sign indicates the direction of queue
growth, not the direction of traffic flow.
alertCFirstName
name of a location or “ negative end name ” in case of linear location
alertCIntersection the intersection code is a cross-reference to one or more location codes, representing
Code
the same point location, but related to one or more other roads. It includes the country
code and the database number (for inter-databases references)
alertCLinearRefere ALERT C location code of a linear reference (road, segment..) referred to by an other
nce
ALERT C location code (point or segment). RDS-TMC uses a hierarchical structure of
pre-defined locations
Note: a system of pointers provides upward references to higher-level locations
containing the specified locations
alertCLinkLocati The location table references
on
alertCLocationCod pre-defined ALERT C code of a location. According to the location referencing
e
method used, this location number can be used as primary (and secondary) location
number.
AlertCLocationP
oint
alertCLocationTab
leNumber
alertCLocationTab
leVersionNumber
alertCNegativeOff
set
This class includes the data of a point in the Alert C referencing method
alertCOffsetDista
nces
The distances between the ends of situation element and the Alert C primary and
secondary locations
November 2002
D3.5 & D3.7/4 – page 14/97
Version 2.0
Default
format for
EDI
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
POS
alertCPositiveOffs
et
In case of segment or point location: ALERT C location of the preceding segment or
point (referring to the positive direction adopted in a conventional way when coding
the locations)
AlertCPrimaryLo
cationPoint
AlertCSecondary
LocationPoint
alertCSecondNam
e
alertCTableRefere
nce
alertCUrbanCode
An Alert C entity (prENV ISO 14819-3)
LSN
LTR
URB
AMH
Definition
Values
unit(s) codes
Status
in EDI
ATT
EDI
Data
type/fi
eld
width
n..5
ATT
an..35
ATT
an..3
ATT
n..1
N
ATT
n..4
NNNN
ATT
n1
N
(d): default unit
Default
format for
EDI
“ positive end name ” in case of linear location.
An ALERT C table reference is an unique reference composed of the : EBU country
code + an ALERT C location table number
code indicating if a point location has mainly an urban or inter-urban character
Ref. ENV14819-3:2000 for the
allocation of this reference.
0: inter-urban
1 : urban
aMFrequency
This indicates the AM radio frequency being used to report a traffic/travel situation.
applicationType
The categorisation of the registration application
ARI
areaOfInterest
The extent to which an item of information should be distributed.
ATS
arrivalTime
The time of the arrival of an individual vehicle on a detection zone or of a PT vehicle
or train at a stop point
Local or
UniversalTime: UTC
(d)
LocalTime: LTI
ATT
an..35
CCYYM
MDDHH
MMZZZ
ADV
arrivalTimeDelay
Value
atmosphericPressu
reAtSeaLevel
The delay at the arrival at a stop point of a public transport vehicle or train
HMin: HOM (d)
ATT
an..35
HHMM
The force per unit area exerted by the atmosphere, measured at ground level and
converted to an equivalent sea level pressure.
Hectopascal: HPA
ATT
n..6
NNNNNN
authorPosition
The job title/position of the author of the registration with his/her organisation
APR
November 2002
D3.5 & D3.7/4 – page 15/97
kHz: KHZ
1: continent-wide
2: neighbouring countries
3: national
4: regional
5: not specified
Version 2.0
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
AVS
AverageSpeed
AVV
averageSpeedNum
ericalValue
WDS
averageWindSpee
d
The wind speed averaged over at least 10 minutes, measured at 10 (meteo standard) or
at 2 metre height.
AXC
axleClass
The type which the axles of an individual vehicle belong to.
Note: This a one-dimensional matrix. E.g. E2E2E1E3 corresponds to the following
Definition
Values
Status
in EDI
Default
format for
EDI
ATT
n..6
NNNNNN
ATT
n..6
NNNNNN
ATT
n1
N
ATT
n..15
Metre: MTR
ATT
ATT
n..3
n..15
NNN
NNNNNN
Tonne: TNE
Metre: MTR
ATT
ATT
n..15
n..6
NNNNNN
NNNNNN
(d): default unit
Is the average of individual vehicle speeds. The different ways of computing this
average are defined in the attribute COM, computation method.
The average speed may be a single value or an n-dimensional matrix; a onedimensional matrix is often used for speeds per vehicle class.
A specific numerical value of the average speed.
C4
AFV
EDI
Data
type/fi
eld
width
unit(s) codes
DOB
KilometrePerHour:
KMH(d);
MetrePerSecond:
MTS
KilometrePerHour:
KMH(d);
MetrePerSecond:
MTS
1 single axle
2 dual axle
3 triple axle
R4B
. This reference section of the dictionary provides for
axle structure:
the classification method in which this example is coded KZ29.
axleFlowNumerica A specific numerical value of the axle flow.
lValue
AXN
AXs
axleNumber
axleSpacing
AXw
BSA
axleWeight
belowStatedAltitu
de
The total number of axles of an individual vehicle.
The spacing of the sth interval between the axles of an individual vehicle from front to
back of this vehicle.
The weight of the wth axle of an individual vehicle from front to back of this vehicle.
An altitude at or below which an event is expected or is occurring, normally weather
related.
November 2002
D3.5 & D3.7/4 – page 16/97
Version 2.0
AxlesInTheMeasure
mentPeriod: AXL;
AxlesPerH: AXH
(d);
AxlesPerD: AXD
D3.5 & D3.7
Coded
name
for
EDI
FullName
BAP
boardingAndAlig
htingPossibility
BRO
BID
CAN
Dictionary
Definition
Values
unit(s) codes
Status
in EDI
(d): default unit
The possibility for passengers of boarding and alighting at a stop point for a
specific vehicle journey
bookingReference This attribute identifies a specific itinerary booking
Identifier
broadcast
Indication as to whether the data may be re-sent by the recipient.
buildingIdentifier
BusStopPoint
The name and/or number of a building
A bus stop point
CalendarDay
A Transmodel entity
calendarDayDate
A Transmodel attribute providing the date of specific calendar day
cancel
Indication that all the element information previously sent is not considered valid, due
to an incorrect content.
EDI
Data
type/fi
eld
width
Default
format for
EDI
A
1: board and alight
2: board only
3: alight only
4: neither board or alight
5: board and alight on request
6: board on request
7: alight on request
ATT
Y: yes;
N: no
ATT
a1
ATT
an..35
ATT
a1
A
Percentage: PER
ATT
n..3
NNN
PartsPerMillion:
PPM
Percentage: PER
ATT
n..6
NNNNNN
ATT
n..3
NNN
YMD
Y: yes;
N: no
Capacity
CYR
CMC
POC
PAR
This class includes information about the original and restricted capacity of the
road
capacityRemaining The ratio of the current capacity to the normal road network link capacity, as a
percentage. The capacity is the maximum number of vehicles that can pass a specified
point on the roadlink, in unit time.
carbonMonoxideC The concentration of CO in the air, i.e. the volume of CO contained in unit volume of
oncentration
air, usually measured in parts per million.
carParkOccupancy The percentage value of car parking spaces occupied.
CarParks
The availability of spaces.
Casualties
The dead and injuries persons in an accident
November 2002
D3.5 & D3.7/4 – page 17/97
Version 2.0
DOB
D3.5 & D3.7
Coded
name
for
EDI
FullName
CLR
PHC
catalogueLineRefe
rence
catalogueReferenc
e
cause
NCH
AAD
channelNumber
chemicalName
CAT
CIN
CLI
DLC
Dictionary
Definition
Values
unit(s) codes
Status
in EDI
EDI
Data
type/fi
eld
width
Default
format for
EDI
ATT
an..3
AAA
ATT
ATT
n..2
an..35
0
NN
ATT
an..35
ATT
an..5
ATT
n1
(d): default unit
Identification of a line of a supplier data catalogue in a data exchange context
ATT
Identification of a supplier data catalogue in a data exchange context
ATT
An attribute describing the origin of the situation element.
Note: "An attribute describing the reason for the situation element, is to be used when
this reason is not fully described by another situation element (i.e. it is only described
by a phrase, e.g. "dense fog", without any further information on fog location or time).
When the reason for the element is fully described by another situation element, then
this other element can be the first element of the causal chain in the situation, with its
"situation cause" attribute set of "Y" (ref. to Situation cause)"
This indicates the channel number being used to report a traffic/travel situation.
This is a free text facility to add the chemical name of a hazardous substance
associated with a traffic/travel situation.
circulatedAuthori A list of the authorities that have received a specific registration
ties
cityName
Part of the postal address identifying the city
Classification
The classification and vehicle class a specific vehicle belongs to
clientIdentification In a data exchange process, the organisation which receives information from another
called “ supplier ”.
codedDelayTime
The coded additional travel time due to adverse travel conditions of any kind, when
compared to "normal conditions".
November 2002
D3.5 & D3.7/4 – page 18/97
The values of this attribute are to
be taken out of the list of phrases
provided in this reference section
of this dictionary, table 4
In DATEX-Net the code is the
country ISO 2-alpha code plus user
id in the country, e.g. GBAAR
3 hours <1< 6 h;
1 h <2< 3 h;
30 min <3< 1 h;
4: < 30 minutes;
5: negligible
Version 2.0
N
D3.5 & D3.7
Coded
name
for
EDI
FullName
DUR
codedDuration
LRA
codeListResponsib
leAgency
codeListVersionN
umber
comment
CLV
SUR
Dictionary
The coded expected period over which the information contained in an element is
D0 or L0: unspecified;
thought likely to continue. This will equate to the difference between the start and stop 1/4 hour <D1< 1/2 h;
times if they are both defined.
1/2 h <D2< 1 h;
1 h <D3< 2 h;
2 h <D4<3 h;
3 h<D5< 4 h;
D6> 4 hours;
L1: throughout the morning/
afternoon/night;
L2: for the rest of the day;
L3: until tomorrow evening;
L4: for the rest of the week;
L5: until the end of next week;
L6: until the end of the month;
L7: for a long period
code of the organisation in charge of maintaining and publishing the list of location
code.
Identification of the version of the list of codes used in an application
ATT
EDI
Data
type/fi
eld
width
an..2
ATT
an..3
ATT
n..3
Free text facility that can be offered to the operator for uncoded observations, not
intended for eventual end users (e.g. a vehicle brand).
ATT
an..35
0
Definition
Values
unit(s) codes
Status
in EDI
(d): default unit
Company
A Transmodel entity
November 2002
D3.5 & D3.7/4 – page 19/97
Version 2.0
Default
format for
EDI
AN
NNN
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
DRC
compassPointDirec The direction of traffic flow concerned by a situation or traffic data given in compass
tion
point form.
COM
computationMetho
d
Method of computation which has been used to compute data
CTT
Concentration
CTV
concentrationNum
ericalValue
Is the total number of vehicles present on a specified section of road at a particular
time, divided by the length of the section. It may be a single value or an n-dimensional
matrix.
A specific numerical value of the concentration.
Definition
Values
unit(s) codes
Status
in EDI
ATT
EDI
Data
type/fi
eld
width
a..3
AAA
ATT
n1
N
n..6
NNNNNN
(d): default unit
November 2002
D3.5 & D3.7/4 – page 20/97
The following codes for a 4, 8 or
16 position compass card:
N: north
NNE: north north east
NE: north east
ENE: east north east
east
ESE: east south east
SE: south east
SSE: south south east
S: south
SSW: south south west
SW: south west
WSW: west south west
W: west
WNW: west north west
NW: north west
NNW: north north west
1: arithmetic average of measures
in a time period;
2: harmonic average of measures in
a time period;
3: moving average of measures;
4: arithmetic average of measures
based on a fixed number of
measurements
Version 2.0
Default
format for
EDI
DOB
vehicles/km: VPK
ATT
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
CFI
confidentiality
The extent to which the information may be circulated, according to the recipient type.
CNT
confirmationTime
The date/time at which the information containing in the element was last verified, e.g.
by a direct observation or new information associated with the element has been
confirmed.
CSE
ConnectingService
s
Vehicle journeys that connect to specified vehicle journeys at specified stop points
DOB
COL
ConnectionLink
A Transmodel entity
DOB
Consequence
contactTel
costForTheDuratio
nIndicated
The set of impacts of a situation element on road and traffic
Telephone number for contacting an operator
This indicates a cost (normally for parking) for the associated time period.
countryCode
creationTime
Specifies the country in question
Time the object was created.
creatorId
Unique identifier of the originator of the message (not the organisation
forwarding or distributing the message)
DangerousGoods
dangerousGoodsFl
ashPoint
This class includes alll information concerning the dangerous goods in a situation
This is temperature at which the vapour from a hazardous substance will ignite in air.
COS
COU
DGF
Definition
Values
unit(s) codes
Status
in EDI
Default
format for
EDI
ATT
EDI
Data
type/fi
eld
width
n1
ATT
an..35
CCYYM
MDDHH
MMZZZ
ATT
n..18
NNNN.N
N
ATT
a3
AAA
ATT
an..3
NNN
(d): default unit
November 2002
D3.5 & D3.7/4 – page 21/97
1: Internal use;
2: Restricted to Authorities;
3: Restricted to Authorities and
traffic operators;
4: Restricted to Authorities, traffic
operators and publishers;
5: No restriction
UniversalTime: UTC
(d)
LocalTime: LTI
In DATEX-Net the currency code
used is the ISO 4217 3-alpha code
Currency
unitCurrency: CUR
Code list ISO 3166
Version 2.0
DegreesCelsius:
CEL
N
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
DRE
dangerousGoodsR
egulations
This item indicates a code defining the regulations, international or national, applicable ADR: European agreement on the
for a means of transport.
international carriage of dangerous
goods on road.
ICA: IATA ICAO Regulations
covering the international
transportation of dangerous goods
issued by the International Air
Transport Association and the
International Civil Aviation
Organisation.
IMD: IMO IMDG code.
Regulations regarding the
transportation of dangerous goods
on ocean-going vessels issued by
the International Maritime
Organisation.
RID: Railroad dangerous goods
book (RID). International
regulations concerning the
international carriage of dangerous
goods by rail.
ATT
EDI
Data
type/fi
eld
width
an..3
DDV
dataDictionaryVer
sion
dataGroup
The version of the data dictionary currently used in the application
e.g. “1.0”
ATT
an..6
A series of traffic data items corresponding to a sequence in time: e.g. 24 hourly flow
for a given day, or 12 average speeds in a given hour.
This attribute aims at grouping data for transmission effectiveness
to be defined
ATT
an..35
DGR
Definition
Values
unit(s) codes
Status
in EDI
(d): default unit
November 2002
D3.5 & D3.7/4 – page 22/97
Version 2.0
Default
format for
EDI
AAA
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
DOW
dayOfWeek
The day of the week at which the associated event will occur
Definition
ATT
1: Monday
2: Tuesday
3: Wednesday
4: Thursday
5: Friday
6: Saturday
7: Sunday
ATT
n1
N
ATT
an..35
MM
ATT
an..35
HHMM
ATT
a1
A
ATT
an..35
NNNNNN
DDHHM
M
unit(s) codes
Status
in EDI
(d): default unit
DayType
A Transmodel entity
DUN
dayUntil
The day of the week until which the associated event will occur.
CDD
defaultDuration
The default time necessary to walk through a link
DLT
Delay
Delays/Cancellatio
ns
delayTimeValue
The delay to road traffic
Disruptions to public transport services resulting in hold-ups, lateness or unavailability
of service.
The value of the additional travel time due to adverse travel conditions of any kind,
when compared to "normal conditions".
DBK
deliveryBreak
DIN
deliveryInterval
Indicates that a data delivery is stopped for unplanned reasons, i.e. excluding the end
of the order validity (attribute FIL) or the case when the filter expression is not met
(attribute OOR).
Value of the interval of data delivery in the delivery mode “periodic”
DEC
1: Monday
2: Tuesday
3: Wednesday
4: Thursday
5: Friday
6: Saturday
7: Sunday
EDI
Data
type/fi
eld
width
n1
Values
November 2002
D3.5 & D3.7/4 – page 23/97
MinuteOfTime:
MIN
Default
format for
EDI
N
DOB
Days: 0-99
Hours: 0-23
Minutes: 0-59
DHMin: DHM;
HMin: HOM (d)
Y: yes;
N: no
Version 2.0
DHMin: DHM
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
DMD
deliveryMode
The way in time the data are or will be delivered by the supplier to a client. The three
ways are:
on occurrence: the information is delivered as soon as it is available
periodic: the information is delivered at specified intervals
one shot: the information is delivered once
EDT
departureTime
The departure time of a PT vehicle or train from a stop
DTD
The delay at the departure from a stop point of a public transport vehicle or train
DPH
departureTimeDe
layValue
depth
DAR
detectionArray
The area of detection is made up of one or more associated sensors. There may be
several detection arrays for the same traffic lane.
DIR
GAP
DIH
DetectionTimes
Direction
directionBearing
distanceGap
distanceHeadway
DAD
diversionAdvice
DUV
durationValue
ERF
elementReference
The times associated with the passage of a vehicle on a detection zone
The data related to the direction(s) affected by a situation
The direction of traffic flow concerned by a situation or traffic data given as a bearing.
The distance between the front of this vehicle and the rear of the preceding one.
The distance between the front (respectively back) of this vehicle and the front
(respectively back) of the preceding vehicle.
A binary attribute (Y/N) indicating whether travellers are recommended to find and
follow an alternative route around a traffic/travel situation.
The value of the expected period over which the information contained in an element
is thought likely to continue. This will equate to the difference between the start and
stop times if they are both defined.
This is a unique alphanumeric reference for the situation element described by the
message (e.g. 1), when used in combination with the message sender, and situation
reference. Other messages may refer to the same traffic/travel situation element.
Definition
Values
unit(s) codes
Status
in EDI
(d): default unit
The depth of flooding or of snow on the roadnetwork link.
November 2002
D3.5 & D3.7/4 – page 24/97
ATT
O: on occurrence
P: periodic
S: one shot
Default
format for
EDI
HHMMH
HMMSS
HHMM
NNN
A
HMin: HOMh
HMinSec: HMS (d)
HMin: HOM (d)
ATT
ATT
an..35
an..35
an..35
Millimetre:
MMT(d);
Centimetre: CMT
ATT
n..3
ATT
n..35
ATT
ATT
ATT
n..3
n..6
n..6
NNN
NNNNNN
NNNNNN
ATT
a1
A
ATT
an..35
HHMM
ATT
an..35
The arrays are numbered as odd or
even according to the direction of
traffic
DEG
Metre: MTR
Metre: MTR
Y: yes;
N: no
Version 2.0
EDI
Data
type/fi
eld
width
a1
YMDH: YXH;
HMin: HOM (d)
D3.5 & D3.7
Coded
name
for
EDI
FullName
Dictionary
Definition
Values
unit(s) codes
Status
in EDI
EDI
Data
type/fi
eld
width
ATT
n..10
ATT
an..35
CCYYM
MDDHH
MMZZZ
ATT
a1
A
ATT
an..4
HHMM
ATT
an..35
CCYYM
MDDHH
MMZZZ
ATT
an..35
CCYYM
MDDHH
MMZZZ
ATT
a1
A
ATT
a1
A
(d): default unit
elementState
Indicates whether a situation element is active, i.e. not neither ended nor expired,
or inactive, i.e. ended or expired
Each element of a situation may have a series of versions that indicate a change in
information associated with the element. The element version number uniquely
identifies the version of a particular element within a traffic/travel situation.
The date/time of this version of the element. The first value of this attribute is the start
time. This item gives the known, forecast or estimated time of the situation reported
and not the time of the report.
1: active
2: non active
Y: yes;
N: no
VNM
elementVersionNu
mber
VET
elementVersionTi
me
END
end
A binary attribute specifying whether the situation element is finished (yes) or not
(no).
DEN
EXH
enquiryTel
enteringDelay
ExhaustPollution
Telephone number to get information from an operator
This is the delay time expected to enter a parking area.
Air pollution due to exhaust fumes.
EXT
exitTime
The time when an individual vehicle leaves a detection zone.
EXP
expiryTime
The date/time at which a data record shall be considered to be invalid and be deleted
from the active part of a database.
Extent
Facility
Describes the available services, conveniences and amenities on a vehicle,
stoppoint, station or other location
Indicates the action to be taken when a filter is satisfied in the process of updating a
situation
Indicates that a data delivery is stopped, due to the end of the data order validity, i.e.
when the validity data order stop time has been exceeded
Is the number of vehicles, axles, axle-pairs or pcu (passenger car units) which pass a
fixed point in a specified measurement period. It may be a single value or an ndimensional matrix; a one-dimensional matrix is often used for flows per vehicle class.
FIA
filterAction
FIL
filterEnd
FLO
Flow
November 2002
D3.5 & D3.7/4 – page 25/97
UniversalTime: UTC
(d)
LocalTime: LTI
HMin: HOM
Default
format for
EDI
DOB
UniversalTime: UTC
(d)
LocalTime: LTI
UniversalTime: UTC
(d)
LocalTime: LTI
E : Element only
W : Whole situation
Y: yes;
N: no
Version 2.0
DOB
D3.5 & D3.7
Coded
name
for
EDI
FullName
FMH
FOS
fmFrequency
fogSmoke
Dust
forecast
FOR
CFD
Dictionary
Definition
Values
EDI
Data
type/fi
eld
width
n..4
Default
format for
EDI
ATT
a1
A
MinuteOfTime:
MIN
ATT
an..35
MM
Tonne: TNE
ATT
n..6
NNNNNN
unit(s) codes
Status
in EDI
(d): default unit
This indicates the FM radio frequency being used to report a traffic/travel situation.
Environmental or weather conditions (other than precipitation) which prevent drivers
from seeing clearly.
Forecast is a binary item ,item, the value of which mHMinay be yes or no. "Yes"
means that the indicated situation element version is a forecast, while "no" means that
this is an actual situation. Any version may be forecast, from the beginning to the end
of an event.
MHz: MEZ
ATT
Y: yes;
N: no
frequentTraveller The time necessary for a frequent traveller to walk through a link.
Duration
gateIdentifier
The reference of a gate in an airport
GdfIdentifier
GeneralLink
The GDF definition of a location in the Geographical Data File (GDF) standard
Any type of link used in a trip or itinerary
getFullSituation
Tells whether the full situation has to be returned or only the requested events.
grossVehicleWeig
ht
The maximum permitted weight of an individual vehicle and its load, including any
trailers.
GroupOfLines
hazardCodeIdentifi
cation
hazardCodeVersio
nNumber
hazardSubstanceIt
emPageNo
A set of associated lines
This is a dangerous goods description code.
ATT
an..7
The version/revision number of date of issuance of the hazardous material code used.
ATT
n..10
This is a number giving additional hazard code classification of a goods item within
the applicable dangerous goods regulation.
ATT
an..7
EHF
headwayFrequen
cy
Iclient
The time interval between the passage of two successive vehicles at a specific stop
point for a specific period of time.
The interface published by Client Peers.
ATT
an..35
an..35
DES
IlocPlusDescripto
r
Incident
In ILOCPlus, the proprietary identifiers used by the information provider
GVW
HCI
HZV
HSI
INC
HMin: HOMh
HMinSec: HMS (d)
Ref Trident specifications Annex
B
Abnormal traffic situation adversely affecting the normal traffic flow.
November 2002
D3.5 & D3.7/4 – page 26/97
NNNN
DOB
DOB
Version 2.0
NNNNNN
HHMMH
HMMSS
D3.5 & D3.7
Coded
name
for
EDI
FullName
IVD
IndividualVehicle
Data
individualVehicleI
dentifier
VID
INP
inputTime
isupplier
ITS
JPA
Definition
Values
unit(s) codes
Status
in EDI
(d): default unit
ipeer
ITN
Dictionary
The attributes of a single vehicle including its intrinsic features and its specific traffic
parameters.
A code, either a specific one in a particular framework, or the registration number and
registration authority, defining an individual vehicle. In order to make this a unique
identifier the 2-alpha country code should be placed at the front of the identifying
string.
The date/time of the input of the information in a system.
itineraryResult
itinerarySubject
itineraryType
Intended user of the itinerary, i.e. the traveller
The type of requested itinerary
JourneyPattern
A Transmodel entity
Junction
A GDF entity
November 2002
D3.5 & D3.7/4 – page 27/97
Default
format for
EDI
DOB
Text
UniversalTime: UTC
(d)
LocalTime: LTI
ATT
an..15
ATT
an..35
Root of the hierarchy of interfaces. Each interface published by any peer is
ultimately derived by IPeer.
The interface published by Supplier Peers.
A travel route, or a plan for travel including a route, stopping places, and
schedule
The result of the itinerary calculation operation.
itinerary
EDI
Data
type/fi
eld
width
DOB
1 : itinerary found,
100 : itinerary not found
ATT
1 : private only,
2 : public only,
3: intermodal
DOB
Version 2.0
an..35
CCYYM
MDDHH
MMZZZ
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
LNP
lane
The lateral position in a road cross-section of a situation or data
The lanes are coded from the hard
shoulder to the central reservation
from 1 to n
H: hard shoulder
1: first lane
2: second lane
N: nth lane
C: central reservation
A or *: all lanes from 1 to n:
I: Entry slip road
O: Exit slip road
S: slip roads
P: parallel carriageway
R: rest or service area
T: toll plaza
Note: when several lanes are
concerned, their numbers are put
together (e.g. the two left lanes of a
4 lane carriageway are coded 34)
LAN
languageCode
Specifies the language used
Code list ISO 639-1988
DLE
LEN
latitude
leavingDelay
lengthAffected
LOS
LevelOfService
Latitude position expressed in a specific co-ordinate system
This is the delay time expected to leave a parking area.
This indicates the length of road network link affected by the associated traffic/travel
situation.
A qualitative measure describing traffic flowing conditions and their perception by
motorists and passengers.
Definition
Values
unit(s) codes
Status
in EDI
Default
format for
EDI
ATT
EDI
Data
type/fi
eld
width
an..10
ATT
a2
AA
ATT
ATT
an..4
n..6
HHMM
NNNNNN
an..35
NNNN
(d): default unit
licenceNumber
HMin: HOM
Kilometre: KMT
DOB
The licence number of an operator
LIN
Line
A Transmodel entity
LDS
linkDistance
The distance of a general link
November 2002
D3.5 & D3.7/4 – page 28/97
DOB
Metre: MTR
Version 2.0
ATT
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
LTT
linkTime
LNK
linkWithOtherTraf
ficOrTravelSituati
on
The value of the time taken to travel from the origin to the end of a link, including any
time taken by involuntary stops and delays.
Attribute provided to enable the establishment of links between situation data, whether
or not belonging to the same data objects, which could appear unconnected. This
attribute has the value of the situation reference.
LDO
Location
locationDomain
Defines the location referencing method and location type used
code of the domain to which a list of location type codes belongs
LNA
locationName
LRM
locationReferencin
gMethod
name of a location. For ALERT C see first name and second name and prENV12313-3
for the rules to apply when fulfilling these attributes
location referencing method
Definition
Values
unit(s) codes
Status
in EDI
ATT
EDI
Data
type/fi
eld
width
an..35
ATT
an..35
ATT
an..2
ATT
an..35
ATT
an..3
(d): default unit
November 2002
D3.5 & D3.7/4 – page 29/97
HMinSec: HMS (d)
RA: road/area location
Location referencing method used
in DATEX are :
1: RDS-TMC based - predefined
primary location + extent
primary and secondary location
primary location + extent +
distance
primary and secondary location +
distances
5: ILOC+ Plus based – single
point location
6: ILOCPlus+ based – link defined
by two locations
7: Gazetteer
8: Proprietary identifiers
Version 2.0
Default
format for
EDI
HHMMSS
N
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
LOT
locationUsage
This indicates the usage of the associated location information.
Note: the distribution area (DIL) specifies the geographical area within which the
associated information may be re-distributed. This permits centres to re-send the
information to other centres within this area.
The presentation area (PAL) specifies the geographical area within which the
associated information may be broadcast.
LOL
longitude
longitudeAndLatit
ude
Longitude position expressed in a specific co-ordinate system
Position expressed by an ordered co-ordinate pair (longitude/latitude). The co-ordinate
system used is WGS84.
longLatType
defines the referencing method for longitude and latitude
Definition
Values
unit(s) codes
Status
in EDI
(d): default unit
November 2002
D3.5 & D3.7/4 – page 30/97
DIL : distribution area
LOC: element location
LSP: location of source of problem
MPL : measurement point location
PAL : presentation area
RDD: element rerouting locations
RDL: element rerouting destination
location
RDP: element rerouting decision
point
RGL : route guidance location
TDL : traffic data location
ORP: origin place
DEP: destination place
JPO: journey pattern origin
JPD: journey pattern destination
JPM: journey pattern intermediate
stop point
LOR: line origin
LDE: line destination
ATT
ATT
1: WGS84
2: WGS92
3: standard
Version 2.0
EDI
Data
type/fi
eld
width
an..3
an..32
(sign/8
charac
ters/si
gn/78c
haract
ers)
Default
format for
EDI
AAA
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
SPM
mandatorySpeedLi
mits
maximumPermitte
dAxleWeight
maximumTempera
ture
maximumWindSpe
ed
A temporary maximum speed limit legally imposed as a consequence of the
traffic/travel situation
The maximum permitted weight of an individual axle
KilometrePerHour:
KMH
Tonne: TNE
The expected maximum temperature during the forecast period.
DegreesCelsius:
CEL
KilometerPerHour:
KMH(d);
MeterPerSecond:
MTS
MeanPassengerW
aitTime
measurementEquip
mentReference
measurementLengt
h
A Transmodel entity
DOB
This indicates the reference given to traffic measurement equipment
ATT
an..35
Kilometre: KMT (d);
Metre: MTR
ATT
n..6
NNNNNN
HMin: HOM
ATT
an..35
HHMM
name of a measurement point
ATT
an..70
identification of a measurement point
ATT
an..35
the numerical value that is associated with a measurement point. The measurement
point defines the nature of the measurement recorded, the units used and its location
ATT
n..15
MAW
MTE
MWS
WAT
MTQ
MLE
MEP
MPN
F
V
Definition
Values
unit(s) codes
Status
in EDI
Default
format for
EDI
ATT
EDI
Data
type/fi
eld
width
n..3
ATT
n..15
NNNNNN
ATT
n..3
NNN
ATT
n..6
NNNNNN
(d): default unit
measurementPerio
d
MeasurementPoi
nt
measurementPoint
Name
measurementPoint
Reference
measurementPoint
Value
The maximum wind speed in a measurement period of 10 minutes.
The length of road on which a measurement has been performed. This is used in
particular to specify the length of the detection zone for occupancy measurements.
This item may differ from the unit of the value; e.g. concentration in veh/km can be
measured over a 2 km section of road.
The time elapsed between the beginning and the end of measurements. This item may
differ from the unit attribute; e.g. an hourly flow can be estimated from a 5-minute
measurement period.
This class provides the traffic characteristics of a traffic measurement
November 2002
D3.5 & D3.7/4 – page 31/97
Version 2.0
NNN
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
MSN
side of the road on which mHMineasurement are acquired, corresponds to the
direction of the road
The time associated with a measurement. It may be the time of the beginning, the end
or the middle of the measurement period.
e.g. : Brussels ! Lille
MTI
measurementSide
Name
measurementTime
MCH
messageChain
DIS
messageDisplay
This indicates the identification of previous message sender(s) of the same message
when a situation element is forwarded by a recipient to a further recipient. This is
useful to track the sending history of a message when is forwarded in a network
Note: in DATEX-Net there may be several occurrences of this attribute, listed in
chronological order.
The message displayed by a variable message sign.
Definition
Default
format for
EDI
ATT
EDI
Data
type/fi
eld
width
an..35
ATT
an..35
CCYYM
MDDHH
MMZZZ
ATT
an5
Free text
ATT
an..35
0
Values
unit(s) codes
Status
in EDI
(d): default unit
November 2002
D3.5 & D3.7/4 – page 32/97
UniversalTime: UTC
(d)
LocalTime: LTI
Version 2.0
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
MFU
messageFunction
The function performed by the message in the DATEX-Net specifications
N: New order
U: Update an earlier data order
E: End, this means that the
Supplier will modify the order stop
time to his computer time
C: Cancel, this deletes the data
order from the Supplier database
RSU: rejection with suggestion
APP: approval
1: information only (default value)
16: diversionary route request
29: approval of diversionary route
27: rejection of request for
diversionary route
ALT: alternative diversionary
route proposal
SVR: vehicle route request
CVR: approval of vehicle route
RVR: rejection of request for
vehicle route
AVR: alternative vehicle route
proposal
MPR
messagePriority
MRE
messageRecipient
MRF
messageReference
The degree to which an item of information should be processed or transmitted without 1: highest priority;
delay by the recipient.
2: high priority;
3: normal priority;
4: low priority;
5: lowest priority
Identification of the addressee of a message
Identification of a message
Definition
Values
unit(s) codes
Status
in EDI
Default
format for
EDI
ATT
EDI
Data
type/fi
eld
width
an…3
ATT
n1
N
ATT
an..5
ATT
an..35
(d): default unit
November 2002
D3.5 & D3.7/4 – page 33/97
Version 2.0
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
MSE
messageSender
The organisation which sends a message.
This identifier must be unique in the exchange network.
MST
messageSendingTi
me
This is a date/time that is included by the message sender’s software to indicate when
the message was exchanged.
CH4
methaneConcentra
tion
The hourly average concentration of methane
MetroStopPoint
A stop point in a metro station
OCP
MIT
Definition
Values
unit(s) codes
Status
in EDI
Default
format for
EDI
ATT
EDI
Data
type/fi
eld
width
an..5
ATT
an..35
CCYYM
MDDHH
MMZZZ
ATT
n..6
NNNNNN
ATT
n..3
NNN
ATT
n..3
NNN
A
(d): default unit
UniversalTime: UTC
(d)
LocalTime: LTI
PartsPerMillion:
PPM
minimumCarOccu The minimum number of persons in a vehicle required to satisfy a traffic restriction or
pancy
a special fare condition.
minimumTemperat The expected minimum temperature during the forecast period.
ure
DegreesCelsiuss
:
CEL
MBY
mobility
Indicating whether an activity or a roadwork network maintenance is mobile (e.g.. a
march or parade) or static (e.g. a crowd, or sign-post maintenance).
M: mobile;
S: stationary
ATT
a1
SMR
mobilityRestricte
dSuitability
mobilityRestricte
dSuitability
mobilityRestricte
dTravellerDurati
on
motoringCondition
s
The possibility for a mobility restricted traveller to go through a link
1: suitable
2: not suitable
1: yes
2: no
ATT
an..17
ATT
an..17
N
ATT
an..35
MM
ATT
n1
N
MHZ
MovingHazards
Chance occurrences due to abnormal loads or dangerous vehicles, which could disrupt
or endanger traffic.
NAL
name
nationality
A word or group of words used to identify something
Specification of the country in which a vehicle or other entity is registered
an2
AA
MOR
CMD
MOT
Indicates whether a facility like e;g. a PT access point, link or vehicle is suitable
for mobility restricted travellers.
The time necessary for a mobility restricted traveller to walk through a link.
Global estimate of the driving conditions resulting from an event or situation.
November 2002
D3.5 & D3.7/4 – page 34/97
MinuteOfTime:
MIN
1: Normal;
2: Difficult;
3: Impossible
DOB
ISO 2-alpha code of the country
Version 2.0
ATT
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
NAT
nature
In ALERT-C, description of how a message shall be presented to the traveller, with the (blank): information;
description sandwiched between appropriate wording.
F: forecast;
S: silent event
networkDescripti
on
NetworkMaintena
nce
A textual description providing a reference or description of a network
networkVersion
A Transmodel entity
networkVersionD
ate
nextDepartureTim
e
The date of a network version
nitrogenDioxideCo
ncentration
nitrogenMonoxide
Concentration
nonMethaneHydro
carbonsConcentrat
ion
This is the concentration of NO2 in the air, i.e. the volume of NO2 contained in unit
volume of air, usually measured in parts per million.
This is the concentration of NO in the air, i.e. the volume of NO contained in unit
The hourly average concentration of non-methane hydrocarbons
NonPTAccessLin
k
nonPTAccessLink
Duration
nonPTAccessLink
Type
The path from an origin place to a PT access point or in the opposite direction,
covered by any non-PT means, e.g. walk, cycling, private car, etc
The time necessary to cover a non-PT access link
RMT
NTI
N2C
NOC
NMC
NOA
NOD
NAC
Definition
Values
unit(s) codes
Status
in EDI
EDI
Data
type/fi
eld
width
a1
Default
format for
EDI
ATT
an..35
CCYYM
MDDHH
MMZZZ
ATT
n..6
NNNNNN
ATT
n..6
NNNNNN
ATT
n..6
NNNNNN
ATT
an..35
MM
ATT
n..3
NNN
(d): default unit
ATT
Network maintenance activities that may potentially affect traffic operations.
DOB
The next time of departure of a ferry, or any public transport.
The position of the link in relation to the ground
UniversalTime: UTC
(d)
LocalTime: LTI
PartsPerMillion:
PPM
PartsPerMillion:
PPM
PartsPerMillion:
PPM
DOB
MinuteOfTime:
MIN
1: underground
2: mixed
3: overground
number
A numeral that labels or identifies something
numberOfAccident The number of accidents contained with the situation as a whole.
s
November 2002
D3.5 & D3.7/4 – page 35/97
A
Version 2.0
D3.5 & D3.7
Coded
name
for
EDI
FullName
NBR
NBV
numberOfBridges
numberOfBrokenD
ownVehicles
numberOfBurstPip
es
numberOfBuses
numberOfCaravan
s
numberOfConvoys
numberOfDeaths
numberOfDrivers
numberOfFallenTr
ees
numberOfHeavyL
orries
numberOfHeavyV
ehicles
numberOfIncidents
numberOfInjured
numberOfLanes
numberOfLoads
numberOfObjects
numberOfObstruct
ions
numberOfQueues
numberOfRampCo
ntrols
numberOfServiceL
anes
NBP
NBU
CAV
NCY
DEA
NRD
NFT
NHL
NHV
NIC
INJ
NLN
NLD
NOJ
NOB
NLQ
NRC
NSL
Dictionary
The number of bridges on which construction or blasting works are occurring.
The number of broken down vehicles involved.
ATT
ATT
EDI
Data
type/fi
eld
width
n..3
n..3
The number of burst pipes (water, gas, etc.) involved in the situation disrupting traffic.
ATT
n..3
NNN
The number of buses or public transport vehicles involved.
The number of caravans involved.
ATT
ATT
n..3
n..3
NNN
NNN
The number of convoys or groups of vehicles involved.
The number of persons fatally injured in an accident.
The number of drivers involved in a specific situation.
The number of fallen trees that are partly or wholly obstructing the roadnetwork link.
ATT
ATT
ATT
ATT
n..3
n..4
n..3
n..3
NNN
NNNN
NNN
NNN
The number of heavy lorries involved.
ATT
n..3
NNN
The number of heavy vehicles
ATT
n..3
NNN
The number of incidents included in a situation.
The number of persons injured in an accident.
The number of lanes operational.
The number of vehicle loads involved.
The number of objects involved.
The number of obstructions that are partly or wholly blocking the roadnetwork link.
ATT
ATT
ATT
ATT
ATT
ATT
n..3
n..4
n..3
n..3
n..3
n..3
NNN
NNNN
NNN
NNN
NNN
NNN
The number of parallel lanes of queuing traffic caused by a situation.
The number of ramp controls involved.
ATT
ATT
n..4
n..3
NNNN
NNN
The number of service lanes open to traffic at a toll plaza, customs point, etc.
ATT
n..4
NNNN
Definition
Values
unit(s) codes
Status
in EDI
(d): default unit
November 2002
D3.5 & D3.7/4 – page 36/97
Version 2.0
Default
format for
EDI
NNN
NNN
D3.5 & D3.7
Coded
name
for
EDI
FullName
NSW
NSH
numberOfSewers
numberOfShedLoa
ds
numberOfSituation
Elements
numberOfTrailers
numberOfVacantP
arkingSpaces
numberOfVehicles
numberOfVehicles
OnFire
numberOfWaiting
Vehicles
objectChildren
NSE
TAI
NPS
NVE
NVF
NWV
OHZ
Dictionary
The number of sewers involved in the situation disrupting traffic.
The number of shed loads involved in a traffic situation.
ATT
ATT
EDI
Data
type/fi
eld
width
n..3
n..3
The number of traffic/travel situation elements active at a point in time.
ATT
an..35
NN
The number of trailers involved.
This indicates the number of vacant parking spaces available in a specified parking
area.
The number of vehicles involved in a traffic/travel situation such as an accident.
The number of vehicles that are on fire at the specified location.
ATT
ATT
n..3
n..6
NNN
NNNNNN
ATT
ATT
n..6
n..3
NNNNNN
NNN
The number of vehicles waiting in a queue.
ATT
n..6
NNNNNN
Definition
Values
unit(s) codes
Status
in EDI
(d): default unit
Indicates which children of the specified object have to be returned. For example,
if the specified object is a Network object and one wants to download all the stop
points of the network then the Network StopPoints enumerated value shall be
chosen.
objectId
Unique identifier of the object.
objectIdentificati
on
objectVersion
Contains the identifiers of another object (a reference to another existing object).
ObstructionHazard
s
Motionless chance occurrences involving earlier causes (e.g. earlier accidents) or
causes external to the traffic stream (e.g. physical obstacles other than vehicles), which
could disrupt or endanger traffic.
0 : AllChildren (default),
1 : Network StopPoint,
2 : Network Line,
3 : Network Route,
4 : Network StopArea,
5 :Network PTAccessLink,
6 : Network NonPTAccessLink,
7 :Network ConnectionLink,
8 : Line Route,
9 : Route StopPoint
Version of the specific object
November 2002
D3.5 & D3.7/4 – page 37/97
Version 2.0
DOB
Default
format for
EDI
NNN
NNN
D3.5 & D3.7
Coded
name
for
EDI
FullName
COD
occasionalTravell
erDuration
Occupancy
OCC
Dictionary
Definition
Values
unit(s) codes
Status
in EDI
EDI
Data
type/fi
eld
width
Default
format for
EDI
ATT
an..35
MM
n..3
NNN
(d): default unit
The time necessary for an occasional traveller to walk through a link.
MinuteOfTime:
MIN
The proportion of time that a vehicle presence sensor is activated within a
measurement period. It may be a single value or an n-dimensional matrix.
A specific numerical value of the occupancy.
DOB
OCV
occupancyNumeri
calValue
ODE
OperatingDepart
ment
operatingDepart
mentName
OperatorActions
A Transmodel entity
DOB
The name of the department administering certain lines
ATT
The actions that a traffic operator can decide or implement to prevent or help correct
dangerous or poor driving conditions.
DOB
optimisationType
The optimisation type for an itinerary calculation request.
orderNumber
The number of the data order sent by a client to a supplier
ODN
OPA
ORN
November 2002
D3.5 & D3.7/4 – page 38/97
Percentage: PER
ATT
an..35
1 : min travel duration,
2 : min travel distance,
3 : min walking duration
4 : min num of transfers,
5: min travel cost
ATT
Version 2.0
an..35
NNNN
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
OST
orderStatus
The answer of the supplier in response to an order
ORU
OrganisationalUn
it
organisationalUni
tName
originalNumberOf
Lanes
OriginDestination
Matrix
outOfRange
A Transmodel entity
DOB
The name of the unit responsible for planning and controlling in a public
transport company
The normal number of lanes that the carriageway has before reduction due to
roadworks network maintenance or traffic events.
Flows of vehicles or passengers according to their origin and destination
ATT
an..35
ATT
n..3
NNN
ATT
a1
A
ATT
n..6
NNNNNN
OUN
ONL
ODM
OOR
O3C
Definition
Values
unit(s) codes
Status
in EDI
(d): default unit
ozoneConcentratio
n
AN: Accepted as new
CS: Cancelled successfully
IDM: Incompatible delivery mode
OER: Other error
RC: Rejected on confidentiality
grounds
RE: Ignored
TCC: Criteria too complex
TLL: Location definition too
complex
UDM: Unknown delivery mode
UDO: Unknown data object
UDR: Unknown data order
ULO: Unknown location
URQ: Request not understood
US: Updated successfully
UTE: Unknown traffic equipment
Default
format for
EDI
AAA
DOB
Indicates that a data delivery is stopped, due to the fact that the filter expression is no
more met, i.e. when the attribute used for filtering has passed back the threshold
This is the concentration of O3 in the air, i.e. the volume of O3 contained in unit
November 2002
D3.5 & D3.7/4 – page 39/97
ATT
EDI
Data
type/fi
eld
width
an..3
Y: yes;
N: no
Version 2.0
µG/m3: MGM
PartsPerMillion:
PPM (d)
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
DHMin: DHM;
HMin: HOM(d)
SecondOfTime: SEC
ATT
EDI
Data
type/fi
eld
width
an..35
PAD
parkingDuration
A duration indicating a period of time which the cost of parking is provided for.
PAS
passageTime
The time elapsed between the beginnings (or the ends) of activation of two sensors
ATT
n..6
PassengerCarUnitIn
TheMeasurementPer
iod: PCU;
PassengerCarUnitPer
Hour: PCH (d);
PassengerCarUnitPer
Day: PCD
ATT
n..10
Percentage: PER
ATT
an..35
PED
percentageOfServ The proportion of vehicle journeys operating
iceOperating
Period
A Transmodel entity
PDY
periodOfEachDay
HMin: HOM
PWK
periodOfEachWee
k
PHR
phrase
Definition
Values
unit(s) codes
Status
in EDI
(d): default unit
SSSS
HHMM
password
FLV
The password used by a Peer when connecting to another Peer in order to place a
request. It can depend on the Supplier to which the Request is directed.
pcuFlowNumerical A specific numerical value of the passenger car unit flow.
Value
Default
format for
EDI
peerAddress
PSO
The network address of the peer.
DOB
In the filtering process of data exchange, specification of the period of time within
which the filter has to be applied each day. It is composed of 2 times.
In the filtering process of data exchange, specification of days of the weeks for which
the filter has to be applied each week
A phrase is a partial description of a traffic/travel situation or traffic data. It can be
considered as a specific situation data attribute which specifies the state of the data
object concerned (e.g. "stationary traffic" for the data object "level of service"). Each
data object has a suggested set of phrases, but these are not mandatory and exclusive.
November 2002
D3.5 & D3.7/4 – page 40/97
1: Monday
2: Tuesday
3: Wednesday
4: Thursday
5: Friday
6: Saturday
7: Sunday
e.g.: Monday to Friday: 15;
Saturday to Monday: 61
the list of Phrases is provided in
this reference section of the
dictionary, table 4
Version 2.0
ATT
an..35
ATT
an..35
HHMMH
HMM
NN
ATT
an..3
AAA
D3.5 & D3.7
Coded
name
for
EDI
PLA
PLC
PRE
PIN
PDD
PRT
PPP
PHQ
PRB
FullName
Dictionary
Definition
Values
unit(s) codes
Status
in EDI
(d): default unit
Place
A Transmodel entity
platformIdentifie
r
pointName
The reference of a platform in a PT station
The name of a point
PointOfInterest
Places which are of interest for a tourist.
This identifies additional information which is used to qualify the associated phrase
probabilityValue
This indicates a degree of the likelihood of the reported event occurring.
PropertyOfDay
A Transmodel entity
propertyOfDayN
ame
ProprietaryIdenti
fier
The name of the property a day may possess
ATT
an..35
DOB
MillimetresPerHour:
MMH
ATT
n..6
NNNNNN
Millimetre: MMT
ATT
n..6
NNNNNN
SecondOfTime: SEC
µG/m3:MGM
PartsPerMillion:
PPM (d)
ATT
ATT
n..6
n..6
SSSS
NNNNNN
ATT
a..3
A
ATT
n..3
NNN
d: danger of
e: expected
Percentage: PER
A point identification in a proprietary reference system
November 2002
D3.5 & D3.7/4 – page 41/97
Default
format for
EDI
DOB
PositionAndExten The location of a situation element
t
postCode
Part of the postal address identifying a part of a city.
Precipitation
Precipitation is rainfall, snowfall, sleet or hail and includes both qualitative and
quantitative measurements per unit time.
precipitationIntens The height of the precipitation received per unit time.
ity
This measure is usually coded according to the type of precipitation {rain, drizzle,
snow} and the intensity in mm/h.
precipitationOrDe The equivalent depth of the water layer resulting from precipitation or deposition on a
positionDepth
non-porous horizontal surface. Non liquid precipitation are considered as melted in
water
presenceTime
The time during which a vehicle activates a presence sensor.
primaryParticulate The hourly concentration of primary particulate particles, emitted in the atmosphere by
Concentration
natural and artificial sources.
probabilityCoded
EDI
Data
type/fi
eld
width
Version 2.0
D3.5 & D3.7
Coded
name
for
EDI
FullName
Dictionary
Definition
Values
unit(s) codes
Status
in EDI
(d): default unit
EDI
Data
type/fi
eld
width
Default
format for
EDI
ALI
PTAccessLink
The path from a PT access point to a stop point or in the opposite direction
ADD
ptAccessLinkDefa
ultDuration
ptAccessLinkFre
quentTravellerDu
ration
ptAccessLinkMob
ilityRestrictedTra
vellerDuration
ptAccessLinkOcc
asionalTravellerD
uration
PTAccessPoint
The default time necessary to walk from a PT access point to the stop point,
within the PT premises.
The time necessary for a frequent traveller to walk from a PT access point to the
stop point, within the PT premises.
MinuteOfTime:
MIN
MinuteOfTime:
MIN
ATT
an..35
MM
ATT
an..35
MM
The time necessary for a mobility restricted traveller to walk from a PT access
point to the stop point, within the PT premises.
MinuteOfTime:
MIN
ATT
an..35
MM
The time necessary for an occasional traveller to walk from a PT access point to
the stop point, within the PT premises.
MinuteOfTime:
MIN
ATT
an..35
MM
ALF
AMR
ALO
APO
PTR
DOB
A physical point of entry into the PT premises, allowing the access to one or more
stop points
ptAccessPointTyp The possibilities of entering/leaving the PT domain
e
ptDirection
The geographical direction of vehicle journeys at specific stop point
Ptincident
Abnormal PT situation adversely affecting the normal PT operation
November 2002
D3.5 & D3.7/4 – page 42/97
1: in
2: out
3: in/out
The following codes for a 4or 8
position compass card:
1: north
2: north east
3: east
4: south east
5: south
6: south west
7: west
8: north west
or, for circular lines:
9: clockwise
10: counterwise
Version 2.0
D3.5 & D3.7
Coded
name
for
EDI
FullName
Dictionary
Definition
Values
unit(s) codes
Ptnetwork
ATT
an..35
ATT
n1
N
ATT
n..6
NNNNNN
ATT
n..18
ATT
n..18
ATT
n..3
NNNN.N
N
NNNN.N
N
NNN
Default
format for
EDI
The unique, oriented way between two consecutive Stop Points on a route against
which distances are usually expressed
A static topological presentation of a multimodal public transport network
QIN
PtNetwork
publishedJourney
Identifier
publishedJourney
Name
publishedName
publishedRouteN
ame
qualityIndex
QUE
Queue
queueLength
This class includes information about queues on the road
The length of a queue or the average length of queues in separate lanes due to a
situation.
Kilometre: KMT
radius
A radius for searching stop points.
Metre: MTR
PJN
EDI
Data
type/fi
eld
width
(d): default unit
Ptlink
PJI
Status
in EDI
The abstract network of PT lines
The identification of a journey as it is disseminated to the general public
The name of a journey as it is disseminated to the general public
The name of a concept, e.g. line, as it is disseminated to the general public
The name of a route as it is disseminated to the general public
The confidence that the sender has in the information.
1: certain;
2: very reliable;
3: reliable;
4: probably reliable;
5: unconfirmed
RailwayStopPoint A stop point in a railway station
RPD
ratePerDay
This indicates a cost per day (normally for parking) for the associated time period.
RPH
ratePerHour
This indicates a cost per hour (normally for parking) for the associated time period.
VCF
ratioOfAVehicleCl The proportion of a specific vehicle class to a part or the entire traffic flow.
assInATrafficFlow The most common use of this attribute is the proportion of heavy vehicles in the entire
flow.
November 2002
D3.5 & D3.7/4 – page 43/97
Version 2.0
CUR: Currency
unit/day
CUR: Currency
unit/hour
Percentage: PER
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
RDI
rdsDirection
The direction of traffic flow concerned by a situation or traffic data.
In Alert C the positive (resp. negative) direction corresponds to the positive offset
direction within the RDS location table.
Note: this attribute is addressed by the CEN-WG 7.3
RTI
referenceTime
An attribute indicating whether local or UniversalTime is used
REG
Registration
Submission to regulatory body for submission of a service (Journey Pattern)
HUM
registrationNumb An operator-unique identifier which provides a reference to the registration
er
relativeHumidity
The amount of water vapour in the air, as a percentage of the amount of water vapour
in saturated air at the same temperature and at atmospheric pressure. The measurement
is taken between 1.5 and 2 m above the ground and behind a meteo screen.
Definition
Values
unit(s) codes
Status
in EDI
Default
format for
EDI
ATT
EDI
Data
type/fi
eld
width
a1
ATT
a1
A
(d): default unit
RelativeTimes
Request
The delay of a service at a stop point
Objects of this class encapsulate Requests produced by Clients
requestedVersion
Specifies which version of the object is to be returned.
requestID
Unique identifier of the request.
requestPriority
The priority level of a request, as suggested by the client.
REQ
requestTime
The date/time of a request sent by an organisation to another one
ROU
Rerouting
An action which involves diverting traffic, whether mandatory or advisory.
November 2002
D3.5 & D3.7/4 – page 44/97
P or p: positive;
N or n: negative;
B or b or *: both ;
U or u: unknown
L: local;
U: universal
A
DOB
Percentage: PER
ATT
n..3
NNN
UniversalTime:
UTC (d)
LocalTime: LTI
ATT
an..35
CCYYM
MDDHH
MMZZZ
1 : rvAllVersions ,
2 : rvThisVersion ,
3 : rvLatestVersion ,
4 : rvFirstVersion
0 : low priority
1 : normal priority (default)
2: high priority
DOB
Version 2.0
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
RAR
reroutingAgreeme
ntRequestReferenc
er
This is a unique alphanumeric reference that identifies a rerouting agreement request
and responses to that request, when used in combination with the message sender.
Response
Objects of this class encapsulate Responses produced by Suppliers.
responsePriority
The priority level of a response, as suggested by the supplier. It must be equal to
the priority level of the corresponding request.
Definition
Values
responseTime
The time when the response was prepared.
Ride
A Transmodel entity
ERD
rideDuration
The time taken for a ride .
RDU
rideDuration
The time taken for a specific ride.
RoadElement
roadNetwork
A section of road or street between 2 junctions
A static topological presentation of a road traffic transport network
RoadNetwork
roadSurfaceTempe
rature
The physical network of roads and streets allowing public and private transport
The temperature measured on the road surface.
Route
A Transmodel entity
sectionsOfResurfa
cingWork
sequentialRampNu
mber
ServiceInformatio
n
ServiceStatus
SRR
SEQ
INF
SST
Status
in EDI
(d): default unit
RID
RTE
unit(s) codes
ATT
EDI
Data
type/fi
eld
width
an..35
Default
format for
EDI
HHMMH
HMMSS
HHMMH
HMMSS
0 : low priority
1 : normal priority (default)
3: high priority =
DOB
HMin: HOM
HMinSec: HMS (d)
HMin: HOM
HminSec: HMS (d)
ATT
ATT
an..35
an..35
an..35
DegreesCelsius:
CEL
ATT
n..3
NNN
The number of sections of road resurfacing work at the specified location.
ATT
n..3
NNN
The sequential number of an exit/entrance ramp from a given location in a given
direction.
This item gives information about the availability of the information service and about
items presented over the audio channel.
ATT
n..3
NNN
Information relating to a vehicle or group of vehicles.
DOB
November 2002
D3.5 & D3.7/4 – page 45/97
Version 2.0
DOB
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
SSV
serviceStatusValu
e
The operational status of a specific service
SBL
setsOfBlastingWor
k
setsOfConstruction
Work
setsOfMaintenance
Work
setsOfRoadMarkin
gWork
setsOfRoadworks
setsOfSlowMoving
MaintenanceVehic
les
setsOfTemporaryT
rafficLights
setsOfTrafficLight
s
SCR
SMW
SRM
SRW
SMM
NTL
STL
Status
in EDI
EDI
Data
type/fi
eld
width
Default
format for
EDI
ATT
n..1
N
The number of blasting or quarrying works at the specified location.
ATT
n..3
NNN
The number of sets of construction work at the specified location.
ATT
n..3
NNN
The number of sets of maintenance work at the specified location. This includes work
on underground services and cabling.
The number of sets of road marking work at the specified location.
ATT
n..3
NNN
ATT
n..3
NNN
The number of sets of roadworks network maintenance at the specified location.
The number of sets of slow moving maintenance vehicles at the specified location.
ATT
ATT
n..3
n..3
NNN
NNN
The number of sets of temporary traffic lights involved.
ATT
n..3
NNN
The number of sets of traffic lights involved.
ATT
n..3
NNN
Definition
Values
unit(s) codes
(d): default unit
November 2002
D3.5 & D3.7/4 – page 46/97
1: normal
2: delayed
3: cancelled
4: disrupted
5: reduced service
6: increased service
7: rerouted
8: not stopping
9: early
Version 2.0
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
SEV
severity
The amount of disruption to traffic likely to be caused by a particular situation.
SIC
shortName
situationCause
An abbreviation of a name
An attribute that indicates this situation element is the reason for the situation.
Note: It is then the first element of the causal chain in the situation and its value is set
to "Y". This attribute is only valid to a multi-element situation.
When an element is caused by something which is only described by a phrase (e.g.
"dense fog", without any further information on fog location or time) this phrase is to
be mentioned in the Cause attribute"
SIC
situationCause
SNM
situationReference
TAB
situationTimetable
An attribute that indicates this situation element is the reason for the situation.
1: yes;
Note: It is then the first element of the causal chain in the situation and its value is 2: no
set to "Y". This attribute is only valid to a multi-element situation.
When an element is caused by something which is only described by a phrase (e.g.
"dense fog", without any further information on fog location or time) this phrase
is to be mentioned in the Cause attribute"
This is a unique alphanumeric reference for the situation partly or wholly described by
the message (e.g. 101), when used in combination with the message sender. Other
messages may refer to the same traffic/travel situation.
To be defined later
Definition
1: extremely severe;
2: very severe;
3: severe;
4: low severity;
5: lowest severity;
6: not provided
ATT
EDI
Data
type/fi
eld
width
n1
Y: yes;
N: no
ATT
a1
ATT
an..35
ATT
an..35
Values
unit(s) codes
Status
in EDI
(d): default unit
November 2002
D3.5 & D3.7/4 – page 47/97
Version 2.0
Default
format for
EDI
A
N
D3.5 & D3.7
Coded
name
for
EDI
FullName
Dictionary
Definition
Values
unit(s) codes
Status
in EDI
(d): default unit
situationType
The particular type of requested situation.
SHZ
SkidHazards
DOB
SMF
smoothingFactor
SNE
SnowAndIceEquip
ment
SnowOnTheTrans
portNetwork
sourceIdentificatio
n
Situations in which the normal risks of skidding are increased, other than those
resulting from snow on the transport network.
Coefficient required, when a moving average is computed, to give specific weighs to
the former average and the new data. A typical formula is, F being the smoothing
factor:
New average = old average F + new data (1 - F)
The requirements for special equipment to improve vehicle adhesion on snow or ice.
Presence of snow on the transport network, which mHMinay cause skid or obstruction
hazards, or both.
A coded information on the organisation or on the traffic equipment which has
produced the information relating to this version of the element information, when this
is not the message sender.
The name of the organisation which has produced the information relating to this
version of the element information, when this is not the message sender.
DOB
SNO
SID
SNA
sourceName
November 2002
D3.5 & D3.7/4 – page 48/97
EDI
Data
type/fi
eld
width
1: Incident
2: Incident with queue
3: Accident
4: Accident with queue
5: Road maintenance
6:Road maintenance with queue
7: FOS
8: FOS with queue
9: Queue
10: Delay
11: Cancellation
12: Strike
13: Breakdown
14: Track maintenance…
15: PT situation
ATT
n..15
DOB
Text
ATT
an..5
Free text
ATT
an..35
Version 2.0
Default
format for
EDI
D3.5 & D3.7
Coded
name
for
EDI
FullName
SOT
sourceType
Dictionary
Definition
Values
unit(s) codes
Status
in EDI
(d): default unit
Information about the technology used for measuring the data or the method used for
obtaining qualitative descriptions relating to this version of the element information.
November 2002
D3.5 & D3.7/4 – page 49/97
ACP: Automobile club patrol;
AIR: Spotter aircraft;
BRD: Breakdown service (private);
CAM: Camera observation;
ESP: Emergency service patrol
(non-police);
FVO: Freight vehicle operator;
IRD: Infrared monitoring station;
LOP: Induction loop monitoring
station;
MIC: Microwave monitoring
station;
MTC: Mobile telephone caller;
OIN: Other information;
OVH: Other official vehicle;
PPT: Police patrol;
PUT: Public and private utilities;
RAU: Road Authorities;
RMO: Registered motorist
observer;
RTO: Roadside telephone caller;
TMS: Traffic monitoring station;
TRO: Transit operator;
VDO: Video processing
monitoring station;
VPM: Vehicle probe measurement
PTO: public transport;
PTA: passenger transport
coordinating authority;
TIP: travel information service
provider;
TRA: travel agency
STI: indiviidual subject of travel
itinerary.
Version 2.0
ATT
EDI
Data
type/fi
eld
width
an..3
Default
format for
EDI
AAA
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
SVE
specificationVersi
on
The specification version of the application using this dictionary (e.g. DATEX-Net).
speedlimit
speedReduction
The speed indicated to the user as mandatory or advised
The difference between the average free-flow speed .and the current average flow
speed for a section of road
speedReductionRa
tio
The ratio of the current average flow speed to the average free-flow speed.
stairsAvailability
Indicates whether a facility is equiped with stairs
The mathematical entity
STA
standardDeviatio
n
startTime
A section of a station serving specific travellers or destinations
STT
stationInternalDi
vision
Status
SAR
SPV
SPR
Definition
Values
ATT
EDI
Data
type/fi
eld
width
an..9
KilometrePerHour:
KMH
ATT
n..6
Percentage: PER
ATT
n..3
NNN
UniversalTime: UTC
(d)
LocalTime: LTI
ATT
an..35
CCYYM
MDDHH
MMZZZ
unit(s) codes
Status
in EDI
(d): default unit
e.g. “1.0”
1: yes
2: no
The date/time at which the information contained in an element is expected to start, or
said to have started.
StopArea
A characterisation of a traffic/travel situation or PT service whether normal or
abnormal (e.g., flows, travel times, speeds, weather, level of service, waiting time).
A Transmodel entity
DOB
ARN
stopAreaName
A Transmodel attribute
ATT
STP
StopPoint
A Transmodel entity
DOB
SPT
stopPointType
The physical nature of a stop point, depending on the type of vehicle type, e.g.
platform, street stop, etc
STO
stopTime
The date/time at which the information contained in an element is expected to end or
said to have ended.
November 2002
D3.5 & D3.7/4 – page 50/97
Default
format for
EDI
1: on the street
2: platform in a station
3: gate in an airport
4: pier in a port
Version 2.0
UniversalTime: UTC
(d)
LocalTime: LTI
an..35
ATT
n..2
ATT
an..35
CCYYM
MDDHH
MMZZZ
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
SNN
streetName
subjectOfItinerar
y
submissionAutho
r
submissionDate
Part of the postal address identifying the name of a street
The traveller who has requested an itinerary
SUT
subscription
This item specifies whether the information is subject to a subscription by the recipient
S2C
SRN
sulphurDioxideCo
ncentration
sunNetRadiation
STR
sunTotalRadiation
SAD
supplementaryInfo
rmation
SUP
supplierIdentificati
on
This is the concentration of SO2 in the air, i.e. the volume of SO2 contained in unit
The hourly average of sun net radiation, i.e. the total radiation minus the fraction of
sun radiation outgoing from the ground.
The hourly average of sun total radiation, i.e. the sum of the direct solar radiation plus
the diffuse radiation coming from the sun and reradiated downwards.
One or more supplementary information phrases can be added to any element, using
the codes defined in this dictionary . The order in which supplementary information is
received must be respected in retransmission of the information.
In a data exchange process, the organisation that sends information to another, called
“ client ”.
In the Trident object oriented process this is the unique identifier of a Peer. It is
the PeerID of that peer when the peer behaves like a Supplier
The identification of a transport emergency card giving advice for emergency actions.
TRN
Definition
Status
in EDI
EDI
Data
type/fi
eld
width
ATT
an..35
ATT
n1
N
PartsPerMillion:
PPM
Watt/m2: WM2
ATT
n..6
NNNNNN
ATT
n..6
NNNNNN
Watt/m2: WM2
ATT
n..6
NNNNNN
Re table 5 List of the instances of
Alert C supplementary information
ATT
an..3
AAA
ATT
an..5
ATT
an..10
ATT
an..5
SecondOfTime: SEC
ATT
n..6
SSSS
SecondOfTime: SEC
ATT
n..6
SSSS
Values
unit(s) codes
(d): default unit
temCardNumber
Default
format for
EDI
The person who was the author of the registration content
The date when a registration is submitted to the regulatory body
UniversalTime UTC (d)
LocalTime LTI
1: required;
2: not required
AAAAAA
terminalIdentifier The reference of a terminal in an airport
TES
GAT
testMessageNumb
er
timeGap
TIH
timeHeadway
This indicates the numerical reference given in test messages
The time interval between this vehicle front's arrival at a point on the roadway, and
that of the departure of the rear of the preceding one.
The time interval between this vehicle's arrival at (or departure from) a point on the
roadway, and that of the preceding one.
November 2002
D3.5 & D3.7/4 – page 51/97
Version 2.0
D3.5 & D3.7
Coded
name
for
EDI
FullName
TOD
timeOfDay
Dictionary
Definition
The time at which the associated event will occur.
A schedule listing the times at which or within which certain events, such as the arrival
and departure of trains, buses, and airplanes, are to occur
TAV
TimetableVersion A Transmodel entity
UTM
timeUntil
The time until which the associated event will occur.
timingType
Specify whether a time information is scheduled, forecasted or actual
tmcMessageRefere
nce
totalHydrocarbons
Concentration
Identification of a TMC message associated with the situation element
THC
TDT
EQU
unit(s) codes
Status
in EDI
EDI
Data
type/fi
eld
width
an..35
Default
format for
EDI
ATT
an..35
HHMM
ATT
an..35
ATT
n..6
NNNNNN
ATT
a3
AAA
(d): default unit
Timetable
TMN
Values
HMin: HOM
1: scheduled
2: forecasted
3: actual
Note: in Transmodel these values
are respectively timetabled,
expected and recorded
PartsPerMillion:
PPM
Numbers of the traffic control equipement types in a situation element
this indicates whether the data are identified by a measurement point reference or by a
complete set of attributes
TrafficEquipmentS The situation of the traffic equipment: operating status, position or information
tatus
displayed.
November 2002
D3.5 & D3.7/4 – page 52/97
HHMM
DOB
HMin: HOM
The hourly average concentration of total hydrocarbons, i.e. including methane and
non-methane
TrafficControls
trafficDataType
ATT
CUR: current
MPD: measurement point data
Version 2.0
DOB
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
TET
trafficEquipmentT
ype
The type of traffic equipment used.
RES
TrafficRestrictions
SIG
TrafficSignalPlans
Restrictions on transport network usage, whether by legal order or by operational
decisions. It includes road and lane closures, weight and dimensional limits, banned
turns, contraflows and alternate traffic operations.
Signal plan settings.
TramStopPoint
A tram stop point
Definition
Values
unit(s) codes
Status
in EDI
(d): default unit
November 2002
D3.5 & D3.7/4 – page 53/97
ACC: motorway access control
system;
DVM: diversion variable message
sign;
EBO: emergency call boxes;
ENU: emergency phone number;
FOG: fog detection station;
ICE: black ice detection station;
IVM: information VMS;
LCL: lane control lights;
LVC: level crossing;
MEA: traffic measurement station;
MET: weather measurement
station;
PME: pollution measurement
station;
RME: roadside measurement
station;
RVM: road variable message sign
(VMS);
TLI: traffic lights
ATT
DOB
DOB
Version 2.0
EDI
Data
type/fi
eld
width
an..3
Default
format for
EDI
AAA
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
MOD
transportModeNa The name of a transport mode
me
TTM
TTI
TTV
Definition
Values
unit(s) codes
Status
in EDI
EDI
Data
type/fi
eld
width
Default
format for
EDI
ATT
n..2
NN
n..3
an..35
NNN
HHMMSS
an..35
an..35
HHMM
(d): default unit
TransportNetwor
k
travellerArrivaTti
me
travellerDeparture
Time
TravelTime
1:air
2: train
21: long/mid distance train
22: local train
23: rapid transit
3: metro
4:tramway
5:bus, coach
6:ferry
7:waterborne
8: private vehicle
9 walk
10: other
The networ made up of road and PT networks
The time of arrival of a traveller to his destination place
The time of departure of a traveller from his origin place
The time taken to travel between 2 specified points, by a specified route, including any
time taken by involuntary stops and delays. It may be a single value or a ndimensional matrix.
travelTimeIncrease The ratio of the current average travel time on a link to the free-flow travel time.
travelTimeNumeri A specific numerical value of the travel time.
calValue
TridentObject
Message management object inherited by all messages through base
model objects
TRI
Trip
A Transmodel entity
TRD
TSN
tripDuration
tripSegment
The travel time of a trip
A part of a trip
November 2002
D3.5 & D3.7/4 – page 54/97
DOB
Percentage: PER
HMinSec: HMS (d)
ATT
ATT
DOB
HMin: HOM
Version 2.0
ATT
ATT
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
LOA
TypeOfLoad
The type of load carried by a vehicle, especially in respect of hazardous loads.
UNN
undgNumber
UNI
unit
This item is a unique serial number assigned within the United Nations to substances
and articles contained in a list of the dangerous goods most commonly carried.
Each quantitative value, having a dimension, must be qualified explicitly or implicitly
by a "unit" an attribute specifying which unit is used.
Definition
Values
unit(s) codes
Status
in EDI
Default
format for
EDI
ATT
EDI
Data
type/fi
eld
width
an..3
ATT
n4
NNNN
ATT
an..3
(d): default unit
November 2002
D3.5 & D3.7/4 – page 55/97
AMM: Ammunition;
CHI: children;
CHM: chemicals;
COM: combustible materials;
COR: corrosive materials;
DAE: materials dangerous for the
environment;
DAN: materials dangerous for
people;
DEB: debris;
EXN: explosive materials;
FUE: fuel;
GLA: glass;
HAZ: hazardous materials;
LIV: livestock;
MAT: materials;
OIL: oil;
ORD: ordinary;
NEG: perishable products;
NET: petrol;
NHA: pharmaceutical materials;
NRS: persons;
RAD: radioactive materials;
REF: refuse;
SIC: sick people;
TOX: toxic materials;
VIP: VIP;
XND: exceeds normal dimensions
Re table 3 List of Units
Version 2.0
AAA
D3.5 & D3.7
Coded
name
for
EDI
FullName
Dictionary
Definition
Values
Status
in EDI
EDI
Data
type/fi
eld
width
Default
format for
EDI
ATT
a1
A
ATT
an..3
ATT
an..3
ATT
ATT
an..35
n..10
(d): default unit
UnitisedQuantity
A value that uses a unit
URG
urgency
VCL
vehicleClass
This indicates the urgency with which a message recipient or Client should distribute
the enclosed information. Urgency particularly relates to functions within RDS-TMC
applications. This attribute indicates the appropriate receiver response mode for an
automated receiving system. It has three values: normal (N) - routine processing;
urgent (U) - draw to user's attention subject to established filters; extremely urgent (X)
- override all filters and draw to user's attention immediately.
The vehicle category or type to which an individual vehicle belongs.
CLA
vehicleClassificati
on
VDE
VFV
unit(s) codes
X: Extremely urgent;
U: Urgent;
N: Normal urgency
Re section on Classification of
vehicles
Note: when every vehicle class is
used, this attribute is either void or
suffixed 0 (ref. section on
classification) e.g. KX0
The classes into which other attributes are classified. A class can be defined by a single Re section on Classification of
value, or a range of values. For example, where traffic is classified by vehicle classes,
vehicles
the classification attribute refers to a list of classes which could be "cars, heavy
Note: when .all vehicles are
vehicles, others". Where traffic is classified by speed, the classification attribute could grouped together in a single class,
refer to a list such as 0-20 km/h, 20-40 km/h, etc
this attribute is void
VehicleConfigura The axle configuration of a specific vehicle
tion
vehicleDetection
Information resulting from a vehicle passage on a sensor or set of sensors
vehicleFlowNumer A specific numerical value of the vehicular flow.
icalValue
November 2002
D3.5 & D3.7/4 – page 56/97
VehiclesInTheMeas
urementPeriod:
VEH;
VehiclesPerH: VHH;
VehiclesPerMin:
VHM;
VehiclesPerD: VHD
(d)
Version 2.0
D3.5 & D3.7
Coded
name
for
EDI
FullName
HEI
vehicleHeight
Dictionary
Definition
Values
unit(s) codes
Status
in EDI
(d): default unit
The height of the highest part, excluding antennae, of an individual vehicle above the
road surface.
Metre: MTR
ATT
EDI
Data
type/fi
eld
width
n..6
Default
format for
EDI
NNNNNN
VEJ
VehicleJourney
A Transmodel entity
DOB
VJP
VehicleJourneyAt
Stop
vehicleJourneyId
entifier
vehicleJourneyId
entifierConnectingServic
e
VehicleJourneySt
atus
vehicleJourneySt
atusValue
A set of vehicle journeys at a specific stop
DOB
The identification of a specific vehicle journey
ATT
an..35
The vehicle journey identification of a service connected to the service considered
ATT
an..35
ATT
n..1
N
VLN
vehicleLength
The overall distance between the front and back of an individual vehicle, including the
length of any trailers, couplings, etc.
Metre: MTR
ATT
n..6
NNNNNN
Numbers of the various vehicle types in a situation element
IVS
VehicleQuantitati
ve
VehicleSpecific
vehicleSpeed
This class includes information describing a specific vehicle
The distance travelled by an individual vehicle divided by travel time.
KilometrePerHour:
KMH(d);
MetrePerSecond:
MTS
ATT
n..6
NNNNNN
VTP
VehicleType
A Transmodel entity
VJI
CNS
VJS
The status of an individual vehicle journey
The operational status of a specific vehicle journey
November 2002
D3.5 & D3.7/4 – page 57/97
1: normal
2: delayed
3: cancelled
4: early
5: rerouted
6: not stopping
DOB
Version 2.0
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
VTY
vehicleTypeIdenti Unique identifier of specific Public Transport Vehicles
fier
WEI
WID
VIS
vehicleWeight
vehicleWidth
visibility
VDG
volumeOfDangero
usGoods
EWA
waitingTime
WDA
WeatherData
Definition
Values
unit(s) codes
Status
in EDI
EDI
Data
type/fi
eld
width
ATT
an..8
(d): default unit
1 - Bus
11 - LowLying
12 - DoubleDecker
2 - Train
21 - Passenger
22 - Light
23 - Tramway
3 - MotorVehicle
31 - PrivateVehicle
32 - Taxi
33 - ChaffeurVehicle
4 - Aircraft
41 - Light
42 - Medium
43 - Heavy
5 - Ferry
51 - PassengerOnly
52 - PassengerAndVehicle
53 - VehicleOnly
Default
format for
EDI
The static weight of an individual vehicle. and its load, including any trailers
The maximum width of an individual vehicle.
The distance, measured or estimated, beyond which drivers may be unable to clearly
see a vehicle or an obstacle.
This indicates the volume of dangerous goods on the vehicle(s) reported in a
traffic/travel situation.
Tonne: TNE
Metre: MTR
Metre: MTR
ATT
ATT
ATT
n..10
n..6
n..6
NNNNNN
NNNNNN
m3: MCU
ATT
n..8
NNN
The time a public transport vehicle is or will be waiting at a particular stop point
or timing point for a specific journey
Meteorological data: e.g. temperatures, pressure and humidity.
HMin: HOM
HMinSec: HMS (d)
ATT
an..35
an..35
HHMMH
HMMSS
November 2002
D3.5 & D3.7/4 – page 58/97
Version 2.0
DOB
D3.5 & D3.7
Dictionary
Coded
name
for
EDI
FullName
WDG
weightOfDangerou This indicates the weight of dangerous goods on the vehicle(s) reported in a
sGoods
traffic/travel situation.
WIN
WDB
WDD
WMH
Definition
Values
unit(s) codes
Status
in EDI
EDI
Data
type/fi
eld
width
n..6
Default
format for
EDI
ATT
n..3
NNN
ATT
a..3
AAA
ATT
n..6
NNNNNN
(d): default unit
whichStopPoints
Tells which stop points are to be returned by the request for stop points
wholeObjectTree
Wind
If true, all the hierarchy of objects below the specified ones is returned.
Wind conditions on the transport network.
Tonne: TNE
DOB
bearing in degrees
°Degree: DEG
The following codes for a 4, 8 or
16 position compass card:
N: north
NNE: north north east
NE: north east
ENE: east north east
east
ESE: east south east
SE: south east
SSE: south south east
S: south
SSW: south south west
SW: south west
WSW: west south west
W: west
WNW: west north west
NW: north west
NNW: north north west
This is the height above ground level at which wind measurement is performed.
November 2002
D3.5 & D3.7/4 – page 59/97
NNNNNN
1 : All
2 : All withinradius
3 : Nearest
4: Nearest withinradius
windDirectionBear The average direction from which the wind blows, in terms of a bearing.
ing
windDirectionCom The average direction from which the wind blows, in terms of points of the compass.
pass
windMeasurement
Height
ATT
Metre: MTR
Version 2.0
D3.5 & D3.7
Dictionary
facilityType
Specify the facility available
Street number
Duration
validityDomain
distance
Part of the postal address identifying the position in the street
The interval of time during which something exists or proceeds
An expression stating the time domain in which information is true
an extent of space between two places
(Data Set) Reference to a collection of related data files, in GDF
dSetId
sectId
(Section) Reference to a certain subset of a dataset based on geographical cooordinates, in GDF
featItemId
(Feature Item) Reference to a database representation of a real world
object, in GDF
(Feature Category) Type of representation of a feature, i.e. Point, Line,
Area or complex feature, in GDF
featCategory
longitudeSign
Western or eastern longitude
latitudeSign
Southern or northern latitude
objectValidity
objectValiditySta
rt
objectValidityEn
d
TransportMode
Period for which an object’s content is valid
The start of the validity period
1: bar, snack
2: restaurant
3: toilets
4: lift
5: escalator
6: space for bikes
7: nursery
8: infirmary
(-) Western Longitude
(+) Eastern Longitude
(-) Southern Latitude
(+) Northern Latitude
The end of the validity period
A Transmodel entity
November 2002
D3.5 & D3.7/4 – page 60/97
Version 2.0
D3.5 & D3.7
WOR
wordOrder
Dictionary
In the ILOC+ descriptors, this attribute indicates the direction used to code the
location names: according to languages, the significant words are at the beginning
or end of the location names (ref Trident specifications annex A).
November 2002
D3.5 & D3.7/4 – page 61/97
1: from the first to the last word
2: from the last to the first word
Version 2.0
ATT
n..1a
1
NA
D3.5 & D3.7
Dictionary
Table 3 List of Units (informative)
A new unit has been created (in bold): PRD PeriodOfTime.
Coded
namefor EDI
MGM
AXL
AXD
AXH
CMT
CUR
DEG
CEL
DHM
HPA
HOM
HMS
HOR
KHZ
KMT
KMH
LTI
MCU
MDH
MEZ
MTR
MTS
MMT
MMH
MIS
MIN
PPM
PCU
Full name/coded name for OO
PCD
PCH
PER
µGPerCubicMetre
AxlesInTheMeasurementPeriod
AxlesPerD
AxlesPerH
Centimetre
Currency
Degree
DegreesCelsius
DHMin
Hectopascals
HMin
HMinSec
Hour
Kilohertz
Kilometre
KilometresPerHour
LocalTime
M3
MDH
Megahertz
Metre
MetresPerSecond
Millimetre
MillimetresPerHour
Min,Sec
Minute(OfTime)
PartsPerMillion
PassengerCarUnitInTheMeasurement
Period
PassengerCarUnitPerDay
PassengerCarUnitPerHour
Percentage
PRD
SEC
TNE
UTC
VPK
VEH
VHD
VHH
VHM
WM2
WHM
YMD
YXH
PeriodOfTime
Second(OfTime)
Tonne
UniversalTime
VehiclePerKilometre
VehiclesInTheMeasurementPeriod
VehiclesPerD
VehiclesPerH
VehiclesPerMin
WattPerM2
Weekday,HMin
YMD
Y,MDH
November 2002
D3.5 & D3.7/4 – page 62/97
Version 2.0
D3.5 & D3.7
YXM
YXS
Dictionary
YMDHMin
YMDHMinSec
5.6 Presentation of Phrases and Supplementary
information for EDI and OO
[No change has been brought to the previous text below. New phrases have been created for
public transport that are dealt with in the OO approach. New phrases are in bold.]
In Alert C, there are phrases (PHR) and supplementary information, formerly named
supplementary advice, (SAD). The latter do not stand by themselves but are made to
supplement the phrase content. As an example, the phrase SMG “ smog alert ” may be
supplemented by the supplementary information OE “ switch engine off ”.
In the Data Object approach, most Alert C phrases may be used. More information is
provided on the relation between the Alert C and DATEX-Net use of phrases in Clause 8. In
broad terms, the use of a phrase plus an attribute in DATEX-Net can generate several Alert C
phrases, e.g. the phrase TCN “ traffic congestion ”, line 36 of the prENV12313-2 plus the
values 10, 20,… 70 km/h of the attribute AVV “ average speed numerical value ” can
generate the Alert C phrases “ traffic congestion, average speed of 10 km/h…70 km/h ”, lines
37-43 of the prENV12313-2.
In DATEX-Net some supplementary information attributes are used as phrases because in this
context they are self-supporting. A typical example is WR “ winter equipment
recommended ” for the data object SNO “ snow/ice equipment ”.
In DATEX-Net some phrases have been created for the need of operators or Authorities
initiatives; a typical example is WRM “ winter equipment mandatory ”. They are not used in
Alert C.
The following tables provide comprehensive information on the practical use of phrases and
supplementary information. Table 4 gives the list of the instances of the attributes PHR and
PHC which includes Alert C phrases, Alert C supplementary information and DATEX
specific phrases. One column gives the status of the item in Alert C: the possible values are
PHR, SAD and void. The right-hand column gives the name(s) of the data object(s), which
can use this item in DATEX-Net. Table 5 gives the list of supplementary information (SAD)
for which no definition is provided as the name is sufficiently self-evident.
It is worth mentioning that in DATEX-Net the attribute PHC “ cause ” can be used in most
data object; PHC can use any phrase provided it makes sense.
It is important to note that the relation data object/phrase is not mandatory even in DATEXNet, being only a suggestion to ease a common understanding and the interoperability of
systems.
Table 4 List of the instances of Phrases and Causes for EDI and OO
Coded
Full name
Definition
name for
(normative)
(normative)
EDI
(normative)
OBR
(Q) object(s) on roadway The road may be obstructed or traffic hindered due to
November 2002
D3.5 & D3.7/4 – page 63/97
Alert C Related
status
data
objects
for EDI
PHR
OHZ
Version 2.0
D3.5 & D3.7
Coded
name for
EDI
(normative)
PSA
ABL
ACL
ACX
ACW
ACB
ACH
ACI
ACZ
TXB
ALR
APT
ATR
AIC
AIR
DCL
ALA
ALC
ALL
APF
CWC
Full name
(normative)
Dictionary
Definition
(normative)
{something that does not objects laying on the roadway.
necessarily block the road
or part of it}
(Q) parking spaces
specified car parks have car-parking spaces available.
available enough spaces
available
abnormal load(s)
includes all vehicles carrying exceptional loads, which
mHMinay disrupt traffic.
accident clearance
Removal of damaged vehicles
accident cleared
traffic is back to normal following the clearance of an
accident reported earlier.
accident investigation
authorised investigation work connected to an earlier
work
reported accident that may disrupt traffic.
accident involving bus(es) includes all accidents involving at least one passenger
vehicle.
accident involving heavy includes all accidents involving at least one heavy goods
lorr(y/ies)
vehicle.
accident(s)
Situations in which one or more vehicles lose control and
do not recover. They include collisions between
vehicle(s) or other transport network user(s), between
vehicle(s) and obstacle(s).
accident(s) involving
includes all accidents involving at least one vehicle
hazardous materials
believed to be carrying materials, which could present an
additional hazard to travellers.
active TMC service on
this frequency to be
resumed
additional local
information is provided
by another TMC service
additional public transport
additional regional
Agression
air crash
a traveller or employee is assaulted
includes all situations where traffic may be disrupted due
to an air crash adjacent to the roadway.
air raid
includes all types of threat from foreign air powers.
air raid warning cancelled the earlier reported air raid warning has finished.
alarm call: important new includes all warnings of further traffic information.
information on this
frequency follows now
alarm call: new
includes all warnings of the times of the broadcast of
information will be
traffic information.
broadcast between these
times
Alarm signal triggered
all accident cleared, no
problems to report
all car parks full
all carriageways cleared
a passenger has activated an alarm signal
the earlier reported accidents have been cleared and there
are no further traffic problems to report
all car parks are full within a specified area.
the earlier accidents, obstacles or broken down vehicles
November 2002
D3.5 & D3.7/4 – page 64/97
Alert C Related
status
data
objects
for EDI
PHR
PAR
PHR
MHZ
PHR
PHR
OPA
ACC
PHR
ACC
PHR
ACC
PHR
ACC
PHR
ACC
PHR
ACC
PHR
INF
PHR
INF
PHR
INF
PHR
INF
PHR
OHZ
PHR
PHR
PHR
ACT
ACT
INF
PHR
INF
PHR
ACC
PHR
PHR
PAR
RES
Version 2.0
D3.5 & D3.7
Coded
name for
EDI
(normative)
ROA
IMA
Full name
(normative)
ANM
EAM
AVL
avalanches
AVS
average speed
EBG
RBI
Bad weather
ball game
black ice
RBL
blasting work
BLI
blizzard
RCB
blocked
RBA
blocked ahead
BLO
blowing dust
BLS
EBA
blowing snow
bomb alert
EBT
Bomb attack
boxing tournament
BRB
BRC
RBD
RBM
BDB
HBD
Definition
(normative)
have been cleared
all carriageways reopened traffic can once again use all roads in the specified
direction following the lifting of an earlier closure or the
clearance of an earlier blockage.
almost impassable
includes all environmental conditions resulting in the
roadway being almost impassable to vehicles. This
information may be applied to roads above a specified
altitude.
Animal in a tunnel
Animal on the tracks
animals on the road
athletics meeting
BDX
Dictionary
traffic may be disrupted due to an animal in a tunnel
traffic may be disrupted due to an animal on the track
traffic may be disrupted due to animals on the roadway.
includes all types of athletics events that could disrupt
traffic.
the network link may be obstructed or partially
obstructed due to snowslides.
The average speed is the average of individual vehicle
speeds. The different ways of computing this average are
defined in the attribute COM, computation method. The
average speed may be a single value or a n-dimensional
matrix; a one dimensional matrix
includes all types of ball games that could disrupt traffic.
severe skid risk due to black ice (i.e. clear ice, which is
impossible or very difficult to see).
includes all network maintenance and works adjacent to
the network link that involve the use of explosives.
heavy snowfall in combination with strong winds,
limiting visibility to 50m or less.
the network link is totally obstructed, for all vehicles in
both directions, due to an unplanned event.
the network link is totally obstructed, for all vehicles in
the specified direction, due to an unplanned event.
dust blowing across the network link causing
significantly reduced visibility.
fallen snow moving due to the forces of wind.
includes all situations where suspected or actual
explosive or incendiary devices may cause disruption to
traffic.
includes all types of boxing events that could disrupt
traffic.
breakdown cleared
the broken down vehicle, reported previously, has been
removed from the carriageway.
bridge blocked
the bridge is blocked in the specified direction.
bridge closed
the bridge is closed in the specified direction.
bridge demolition work
demolition of bridges over or under the highway.
bridge maintenance work includes all construction, reconstruction, repair and
maintenance of bridges over or under the highway.
broken down bus(es)
includes all situations resulting in the break down of a
passenger vehicle on the carriageway.
broken down heavy
includes all situations where a disabled heavy vehicle
lorr(y/ies)
could present a potential hazard to road users.
November 2002
D3.5 & D3.7/4 – page 65/97
Alert C Related
status
data
objects
for EDI
PHR
RES
PHR
SHZ
PHR
PHR
OHZ
ACT
PHR
OHZ
PHR
AVS
PHR
PHR
ACT
SHZ
PHR
RMT
PHR
PRE
PHR
RES
PHR
RES
PHR
FOS
PHR
PHR
FOS
ACT
PHR
ACT
PHR
INC
PHR
PHR
PHR
PHR
RES
RES
RMT
RMT
PHR
INC
PHR
INC
Version 2.0
D3.5 & D3.7
Coded
Full name
name for
(normative)
EDI
(normative)
BKD
broken down vehicle(s)
BCL
EBF
BRP
BWM
LBB
LCB
BSI
BUN
CAC
PKO
LBP
LAP
CAA
CRC
CRX
broken-down vehicle
clearance
bull fight
RRW
LBC
centre lane(s) blocked
LCC
centre lane(s) closed
EVC
ceremonial event
ACE
CHI
chemical spillage
accident(s)
children on roadway
SCI
civil emergency
LO3
LO2
Definition
(normative)
includes all situations where a disabled vehicle could
present a potential hazard to road users.
Removal of broken-down vehicle
includes all types of bull fighting events that could
disrupt traffic.
burst pipe
the road surface has sunken or collapsed in places due to
burst pipe.
burst water main
traffic may be disrupted due to local flooding and/or
subsidence because of a broken water main.
bus lane blocked
the bus lane is totally obstructed by an unplanned event.
bus lane closed
the bus lane is closed to traffic.
bus services irregular.
normal bus services are affected and running at irregular
Delays
intervals and delays are expected for passengers.
bus services not operating bus services are not operating until the specified time.
cancellations
public transport, park-and-ride, rail or bus services will
be cancelled until the specified time.
car park full
a specified car park is completely occupied.
carpool lane blocked
the carpool lane is totally obstructed by an unplanned
event.
carpool lane closed
the carpool lane is closed to traffic.
carpool lane in operation dedicated carpool lanes are available for vehicles
carrying at least the specified number of occupants.
carpool restrictions
the restrictions governing use of the carpool lane have
changed
changed.
carpool restrictions lifted the previous reported carpool restrictions have been
lifted.
Carriageway blocked by
an accident
carriageway reduced to
one lane
three lanes
two lanes
central reservation work
LO1
Dictionary
only one lane is open for traffic travelling in the specified
direction.
three lanes are open for traffic travelling in the specified
direction.
two lanes are open for traffic travelling in the specified
direction.
includes all construction and maintenance work located
primarily in the central reservation (median). These
works may also involve the closure of adjacent lanes.
the centre lane (of three) or one or more of the central
lanes (of four or more) is totally obstructed.
the centre lane (of three) or one or more of the central
lanes (of four or more) is closed to traffic.
includes all formal or religious acts and rites that could
disrupt traffic.
includes all situations resulting in a spillage of chemicals
on the carriageway.
traffic may be disrupted due to children on the roadway.
includes all perceived or actual situations, which result in
a civil emergency, which could disrupt traffic. These
may include large scale destruction, through events such
as earthquakes, insurrection, and civil disobedience.
November 2002
D3.5 & D3.7/4 – page 66/97
Alert C Related
status
data
objects
for EDI
PHR
INC
PHR
OPA
PHR
ACT
PHR
OHZ
PHR
OHZ
PHR
PHR
PHR
RES
RES
DEC
PHR
PHR
DEC
DEC
PHR
PHR
PAR
RES
PHR
PHR
RES
RES
PHR
RES
PHR
RES
PHR
RES
PHR
RES
PHR
RES
PHR
RMT
PHR
RES
PHR
RES
PHR
ACT
PHR
ACC
PHR
ACT,
OHZ
ACT
PHR
Version 2.0
D3.5 & D3.7
Dictionary
Coded
Full name
Definition
Alert C Related
name for
(normative)
(normative)
status
data
EDI
objects
for EDI
(normative)
SEX
civil emergency cancelled earlier reported civil emergency has finished.
PHR
ACT
CLW
clearance work
traffic may be disrupted due to clearance work associated PHR
OHZ
with an earlier traffic problem.
CLE
clearing action
unspecified clearing action undertaken by the traffic
OPA
operator
RCD
closed
the network link is closed to all vehicles in both
PHR
RES
directions by decision of the appropriate authorities.
RCA
closed ahead
the network link is closed to all vehicles in the specified
PHR
RES
direction by decision of the appropriate authorities.
SMC
closed due to smog alert a specified section of network link is closed due to
PHR
EXH
pollution.
CV3
closed for vehicles with a specified section of road is closed to vehicles with less
PHR
EXH,
less than three occupants than three occupants.
RES
CV1
closed for vehicles with a specified section of road is closed to vehicles with only
PHR
EXH,
only one occupant
one occupant.
RES
CBW
closures due to bad
network links are closed for bad weather conditions
WDA,
weather
RES
CTT
concentration
Concentration is the total number of vehicles present on a PHR
CTT
specified section of road at a particular time, divided by
the length of the section. It may be a single value or an
n-dimensional matrix.
CCB
connecting carriageway the connecting carriageway between specified locations
PHR
RES
blocked
in the specified direction of travel is totally obstructed by
an unplanned event.
CCC
connecting carriageway the connecting carriageway between specified locations
PHR
RES
closed
in the specified direction of travel is closed.
RCW
construction work
includes new network construction, typically lasting for
PHR
RMT
many months.
CTR
contraflow
two-way traffic is temporarily sharing a single
PHR
RES
carriageway.
CTX
contraflow removed
the earlier reported contraflow has been removed.
PHR
RES
CVX
convoy cleared
earlier warning about traffic convoy has been cleared.
PHR
MHZ
COW
convoy service due to bad traffic is only possible in convoys due to bad weather
WDA,
weather
conditions
RES
CVY
convoy(s)
a group of vehicles moving together in formation, which
PHR
MHZ
mHMinay disrupt traffic.
LBA
crawler lane blocked
the crawler lane is totally obstructed by an unplanned
PHR
RES
event.
LCA
crawler lane closed
the crawler lane is closed to traffic.
PHR
RES
ECM
cricket match
includes all types of cricket matches that could disrupt
PHR
ACT
traffic.
WIC
crosswinds
winds at least strong, across the direction of the network
PHR
WIN
link (e.g. on a ridge).
ECR
crowd
includes all major gatherings of people that could disrupt
PHR
ACT
traffic.
TMP
current temperature
this indicates the air temperature in the shade at 1.20
PHR
WDA
metres above ground level.
ECY
cycle race
includes all types of cycle races that could disrupt traffic. PHR
ACT
CYC
cyclists on roadway
traffic may be disrupted due to cyclists on the roadway.
PHR
ACT,
MHZ
Damage-only accident
an accident with no personal injury
November 2002
D3.5 & D3.7/4 – page 67/97
Version 2.0
D3.5 & D3.7
Coded
Full name
name for
(normative)
EDI
(normative)
HAD
damaging hail
AQD
VSM
Dictionary
Definition
(normative)
Alert C Related
status
data
objects
for EDI
large falling ice pellets or frozen rain capable of causing
injury or damage to property.
increased skid risk due to water lying on the roadway.
includes all slow moving vehicles which present a hazard
to road users
earlier warning of dangerous vehicle no longer applies.
PHR
PRE
PHR
PHR
SHZ
MHZ
PHR
MHZ
deep snow on the network link.
a public transport, park-and-ride, rail or bus service will
be delayed until the specified time.
includes all situations where hold-ups or late operation of
services causes delay to travellers.
earlier reported delays have cleared.
PHR
PHR
SNO
DEC
PHR
DEC
PHR
DLY
danger of aquaplaning
dangerous slow moving
vehicle in the roadway
dangerous vehicle
warning cleared
deep snow
delayed until further
notice
delays
DEX
delays cleared
DXX
delays expected to be
cleared
delays of uncertain
duration
the reported delays are expected to clear shortly.
PHR
delays whose predicted duration cannot be estimated
accurately.
PHR
DEC,
FER
DEC,
FER
DEC
Delivery lorry
a delivery lorry is blocking or delaying the PT
operation
includes all forms of public protest, with potential to
disrupt traffic.
dense fog, limiting visibility to 50m or less.
PHR
ACT
PHR
FOS
PHR
INF
PHR
INF
PHR
SHZ
SAD
ROU
PHR
PHR
SHZ,
SNO
ACC
PHR
OHZ
PHR
EQU
normal service has been resumed for emergency calls.
PHR
EQU
only one lane is open in total, for use by each direction of
traffic in turn.
the emergency lane is closed to traffic.
PHR
RES
PHR
RES
VWX
SND
DEU
DUD
EVD
demonstration
FOD
dense fog
DIP
DEI
DCD
DO
Derailment
detailed information is
provided by another TMC
provider
detailed information will
be given on audio
program broadcast
difficult driving
includes all environmental conditions in which driving is
conditions
more difficult than normal. This information may be
applied to roads above a specified altitude.
diversion in operation
a diversionary is operation.
ACA
Driver faintness
driving conditions
improved
earlier accident(s)
EQD
earthquake damage
MSR
Electrical breakdown
electronic signs repaired
DCN
LBE
Emergency break
triggered
emergency call facilities
restored
emergency lane blocked
LCE
emergency lane closed
EFR
earlier reported problems have reduced and driving
conditions have returned towards normal.
an earlier reported accident that is causing disruption to
traffic or is resulting in further accidents.
obstructed because of damage caused by an earthquake.
electronic control signals or variable message signs on
the roads are once again working.
a passenger has activated an emergency break
November 2002
D3.5 & D3.7/4 – page 68/97
Version 2.0
D3.5 & D3.7
Coded
Full name
name for
(normative)
EDI
(normative)
NOO
emergency telephone
number not working
COO
emergency telephones not
working
EMX
emergency vehicle
warning cleared
EMV
emergency vehicle(s)
RBE
entry blocked
REO
entry reopened
REB
entry slip road blocked
REC
entry slip road closed
RCE
entry slip road(s) closed
EVA
Equipment failure
evacuation
ABX
EVX
RBX
RXO
RXB
RXC
RXD
EXB
EXC
TXC
TEX
DCE
EFA
FPC
Dictionary
Definition
(normative)
Alert C Related
status
data
objects
for EDI
the designated telephone number for reporting problems
or requesting assistance is not working.
emergency telephones within a specified length of road
are not working.
earlier warning of emergency vehicles no longer applies.
PHR
EQU
PHR
EQU
PHR
MHZ
emergency service vehicles are on the roadway in
response to an emergency situation.
traffic cannot join the highway at a particular location, in
the specified direction, due to an unplanned event.
traffic can join the highway at a particular intersection, in
the specified direction, following the clearance of the
earlier problem.
traffic cannot join the highway at a particular
intersection, in the specified direction, due to an
unplanned event.
traffic cannot join the highway at a particular
intersection, in the specified direction.
traffic cannot join the highway at a particular series of
locations, in the specified direction.
PHR
MHZ
PHR
RES
PHR
RES
PHR
RES
PHR
RES
PHR
RES
PHR
ACT
PHR
MHZ
PHR
PHR
ACT
RES
PHR
RES
PHR
RES
PHR
RES
PHR
RES
PHR
RES
PHR
RES
PHR
PHR
PHR
WDA
WDA
SHZ
PHR
ACT
PHR
OHZ
a piece of equipment is not or not properly working
a definite area is being cleared due to dangerous
conditions or for security reasons.
exceptional load warning earlier warning about exceptional load has been cleared.
cleared
exhibition
a major display or trade show which could disrupt traffic.
exit blocked
traffic cannot leave the highway at a particular location,
in the specified direction, due to an unplanned event.
exit reopened
traffic can leave the highway at a particular intersection,
in the specified direction, following the clearance of the
earlier problem.
exit slip road blocked
traffic cannot leave the highway at a particular
unplanned event.
exit slip road closed
traffic cannot leave the highway at a particular
exit slip road(s) closed
traffic cannot leave the highway at a particular series of
locations, in the specified direction.
express lanes blocked
the express lanes in the specified direction of travel are
totally obstructed by an unplanned event.
express lanes closed
the express lanes in the specified direction of travel are
closed.
extreme cold
abnormally low temperatures.
extreme heat
abnormally high expected maximum temperature.
extremely hazardous
driving conditions
much mHMinore hazardous than normal. This
information may be applied to roads above a specified
altitude.
fair
a periodic (e.g. annual), often traditional, gathering for
entertainment or trade promotion, which could disrupt
traffic.
fallen power cables
the network link is obstructed or partially obstructed by
November 2002
D3.5 & D3.7/4 – page 69/97
Version 2.0
D3.5 & D3.7
Coded
name for
EDI
(normative)
Full name
(normative)
Dictionary
Definition
(normative)
FSN
one or more fallen power cables.
one or more fallen trees.
ferry service not operating ferry services are not operating until the specified time.
EVF
festival
FLF
flash floods
FLD
flooding
FLO
flow
FOG
FOX
FFX
EFM
fog
fog cleared
fog forecast withdrawn
football match
SSF
FOF
RAF
free shuttle service
operating
freezing fog
freezing rain
SNF
fresh snow
FRO
ACF
frost
fuel spillage accident(s)
SFO
FUN
fuel station reopened
funfair
GAL
GAS
gales
gas leak
GMW
gas main work
FLT
ECL
EHL
EGT
FIG
GP
fallen trees
Gas pipe explosion
give way to emergency
vehicles on the carpool
lane
give way to the
emergency vehicles on the
heavy vehicle lane
golf tournament
grass fire
gritting vehicles in use
Alert C Related
status
data
objects
for EDI
PHR
OHZ
PHR
PHR
DEC,
FER
ACT
PHR
OHZ
PHR
OHZ
PHR
FLO
PHR
PHR
PHR
PHR
FOS
FOS
FOS
ACT
PHR
DEC
PHR
PHR
FOS
SHZ
PHR
SNO
PHR
PHR
WDA
ACC
PHR
PHR
RES
ACT
PHR
PHR
WIN
OHZ
PHR
RMT
all vehicles using the carpool lane must give way to
emergency vehicles on that lane.
PHR
RES
all vehicles using the heavy vehicle lane must give way
to emergency vehicles on that lane.
PHR
RES
includes all types of golf events that could disrupt traffic.
traffic may be disrupted due to a grass fire adjacent to the
network link.
network maintenance vehicles are been used to salt or grit
the road.
PHR
PHR
ACT
OHZ
SAD
MHZ,O
PA
a celebratory event or series of events which could
disrupt traffic.
the network link may become quickly inundated by
powerful floodwaters due to heavy rain nearby.
flood water.
Flow is the number of vehicles, axles, axle-pairs or pcu
(passenger car units) which pass a fixed point in a
specified measurement period. It may be a single value or
a n-dimensional matrix; a one dimensional matrix is often
used for flows per vehicle class
fog, visibility more than 50m.
the earlier report fog has cleared.
the earlier forecast of fog has been withdrawn.
includes all types of football matches that could disrupt
traffic.
a shuttle service is operating at no charge between
specified locations until the specified time.
fog, in conjunction with sub-zero air temperatures.
severe skid risk due to rain falling on sub-zero
temperature road surface and freezing.
fresh snow (lightly trafficked or untrafficked) on the
network link.
frost can be expected.
includes all situations resulting in a spillage of fuel on the
carriageway.
the earlier reported fuel station is open.
entertainment, which could disrupt traffic.
winds between 60 km/h and 90 km/h.
traffic may be disrupted due to an explosion hazard from
gas escaping in or near the network link.
includes all gas main construction and maintenance work
on the network link.
November 2002
D3.5 & D3.7/4 – page 70/97
Version 2.0
D3.5 & D3.7
Coded
name for
EDI
(normative)
Full name
(normative)
GUN
Ground level works
gunfire on roadway
WIG
HAI
LBH
gusty winds
hail
hard shoulder blocked
LCH
hard shoulder closed
DCZ
hazardous driving
conditions
HAX
hazardous load warning
cleared
heavy frost
heavy rain
heavy snowfall
heavy traffic
FRH
RAH
SFH
LS4
LBV
LCV
ANH
HSC
EMH
HUR
RIC
IBU
ICP
Definition
(normative)
includes all perceived or actual acts of gunfire, through
terrorism or crime, which could disrupt traffic.
constantly varying winds, strong at times.
falling ice pellets or frozen rain.
the paved shoulder (for emergency use) is totally
obstructed.
the paved shoulder (for emergency use) is closed to
traffic.
more hazardous than normal. This information may be
applied to roads above a specified altitude.
earlier warning about hazardous loads has been cleared.
a thick coating of frost can be expected.
heavy rainfall, limiting visibility to 50m or less.
dense falling snow, limiting visibility to 50m or less.
the average speed of traffic is between 75Percentage and
90% of its free-flow level.
heavy vehicle lane
the heavy goods vehicle lane is totally obstructed by an
blocked
unplanned event.
heavy vehicle lane closed the heavy goods vehicle lane is closed to traffic.
herd of animals on the
traffic may be disrupted due to a herd of animals on the
road
roadway.
high-speed chase
authorised and unauthorised vehicles are travelling at
high speeds along the roadway. This may present a
hazard to other vehicles.
high-speed emergency
emergency service vehicles progressing at high speed
vehicle(s)
along the roadway in response to or en route from an
emergency situation.
hurricane force winds
winds over 120 km/h.
ice
increased skid risk due to ice (of any kind).
ice build-up
ice is building up on the network link causing a serious
skid hazard.
icy patches
severe skid risk due to icy patches (i.e. intermittent icy on
roadway).
IMP
Identification of a
suspected object
Ill traveller
impassable
INS
incident(s)
IVD
individual vehicle data
TXV
information about major
events is no longer valid
information available
IAV
Dictionary
Alert C Related
status
data
objects
for EDI
PHR
ACT
PHR
PHR
PHR
WIN
PRE
RES
PHR
RES
PHR
SHZ
PHR
MHZ
PHR
PHR
PHR
PHR
WDA
PRE
PRE
LOS
PHR
RES
PHR
PHR
RES
OHZ
PHR
MHZ
PHR
MHZ
PHR
PHR
PHR
WIN
SHZ
SHZ
PHR
SHZ
PHR
SHZ
PHR
INC
PHR
IVD
PHR
INF
an unattended luggage or parcel has been identified as
suspect
roadway being impassable to vehicles. This information
may be applied to roads above a specified altitude.
incidents are chance occurrences involving vehicles from
the traffic stream, which could present potential hazards
to travellers. This item excludes accidents.
Individual vehicle data describes attributes of a single
vehicle including its intrinsic features and its specific
traffic parameters
default phrase indicating that the situation element
conveys some valuable information
November 2002
D3.5 & D3.7/4 – page 71/97
APL,
DEC,
Version 2.0
D3.5 & D3.7
Coded
name for
EDI
(normative)
Full name
(normative)
Dictionary
Definition
(normative)
Alert C Related
status
data
objects
for EDI
conveys some valuable information
TXA
RRI
EIS
AJA
AJC
AJT
LSL
LBX
LRS
SNW
SWN
SWI
LRX
LBK
LCS
ANL
RLS
LBL
LCL
LPB
LPC
TLX
PSN
information restricted to
this area
intermittent rerouting
international sports
meeting
jack-knifed articulated
lorr(y/ies)
Alternative rerouting is in operation
includes all types of large sporting events that could
disrupt traffic.
includes all situations resulting in a heavy goods vehicle
folding together in an accidental skidding movement on
the carriageway.
jack-knifed caravan(s)
includes all situations resulting in a vehicle and caravan
the carriageway.
jack-knifed trailer(s)
includes all situations resulting in a vehicle and trailer
the carriageway.
landslips
obstructed due to landslides.
lane blockages cleared
the earlier reported lane obstructions have been cleared.
lane closures removed
all lanes are reopened following the lifting of earlier
restrictions.
lane control signs not
includes all failures to electronic lane traffic control
working
signals.
lane control signs
includes all situations where lane control signs are
operating
operating (indicating lane closures, speed limits, etc.).
lane control signs working includes all malfunctions to electronic lane traffic control
incorrectly
signals (such that misleading or incorrect information is
provided).
lane restrictions lifted
the previous reported lane restrictions have been lifted.
lane(s) blocked
one or more lanes is totally obstructed in the specified
direction.
lane(s) closed
one or more lanes is closed to traffic in the specified
direction.
large animals on the road traffic may be disrupted due to large animals on the
roadway.
leaves on road
increased skid risk due to leaves on road.
left lane(s) blocked
the lane furthest to the left is totally obstructed.
left lane(s) closed
the lane furthest to the left is closed to traffic.
left-hand parallel
the left-hand parallel carriageway in the specified
carriageway blocked
direction of travel is totally obstructed by an unplanned
event.
left-hand parallel
the left-hand parallel carriageway in the specified
carriageway closed
direction of travel is closed.
less extreme temperatures temperatures will rise or fall towards normal
expected
temperatures.
less than XX parking
specified car parks have a specified number or less car
spaces available
parking spaces available.
November 2002
D3.5 & D3.7/4 – page 72/97
PHR
EXH,
EQU,
FER,
INF,
ROU,
PAR,
WDA,
WIN
INF
PHR
ROU
ACT
PHR
ACC
PHR
ACC
PHR
ACC
PHR
OHZ
PHR
PHR
RES
RES
PHR
EQU
PHR
EQU
PHR
EQU
PHR
PHR
RES
RES
PHR
RES
PHR
OHZ
PHR
PHR
PHR
PHR
SHZ
RES
RES
RES
PHR
RES
PHR
WDA
PHR
PAR
Version 2.0
D3.5 & D3.7
Coded
Full name
name for
(normative)
EDI
(normative)
LCF
level crossing failure
LCW
LLB
LLC
DLL
LLD
LS6
RWL
LCI
LSR
LSG
RMM
RMK
RMX
EVM
RWM
MAR
EMR
MKT
EMT
CAL
MIL
MVL
MHR
RMD
MUD
Dictionary
Definition
(normative)
the traffic control equipment where a railway crosses the
road is not working.
level crossing now
the traffic control equipment is again working normally
working normally
where a railway crosses the road.
local lanes blocked
the local traffic lanes in the specified direction of travel
are totally obstructed by an unplanned event.
local lanes closed
the local traffic lanes in the specified direction of travel
are closed.
long delays
delays of unusual severity.
long load(s)
a vehicle of length greater than that normally allowed,
which mHMinay disrupt traffic.
long queues
queues of unusual severity.
long-term roadworks
includes major road widening projects and substantial
improvements to alignment, lasting for at least three
months.
loose chippings
increased skid risk and injury risk due to loose chippings
on road.
loose sand on road
increased skid risk due to loose sand on road.
low sun glare
difficult visibility conditions created by low evaluation
evolution sunlight.
maintenance vehicles
maintenance vehicles are merging into the traffic flow,
merging into traffic flow creating a potential hazard for road users.
maintenance work
includes all highway maintenance activities which
mHMinay potentially affect traffic operations.
Maintenance work cleared the earlier reported warning of slow moving maintenance
slow moving maintenance vehicle(s) work no longer apply.
vehicle warnings
withdrawn
major event
includes all deliberate human actions external to the
traffic stream which could disrupt traffic.
major roadworks
includes major road widening projects and substantial
improvements to alignment, lasting up to three months.
marathon
includes all types of marathon, cross-country and road
running events that could disrupt traffic.
march
includes all situations where people walk together in
large groups for a common purpose, with potential to
disrupt traffic.
market
a periodic (e.g. weekly) gathering for buying and selling,
which could disrupt traffic.
match
includes all types of sports matches that could disrupt
traffic.
Mechanical breakdown
message cancelled
this item is used to say that the referred message is to be
cancelled, due to an incorrect content.
military convoy(s)
a group of military vehicles moving together in
formation, which mHMinay disrupt traffic.
motor vehicle restrictions earlier reported motor vehicle restrictions have been
lifted
lifted.
moving hazards on the
unspecified moving hazards on the road
road
mud on road
increased skid risk due to mud on road.
mud slide
November 2002
D3.5 & D3.7/4 – page 73/97
Alert C Related
status
data
objects
for EDI
PHR
EQU
PHR
EQU
PHR
RES
PHR
RES
PHR
PHR
DEC
MHZ
PHR
PHR
LOS
RMT
PHR
SHZ
PHR
PHR
SHZ
FOS
PHR
RMT
PHR
RMT
PHR
RMT,
MHZ
PHR
ACT
PHR
RMT
PHR
ACT
PHR
ACT
PHR
ACT
PHR
ACT
PHR
all
PHR
MHZ
PHR
RES
MHZ
PHR
PHR
SHZ
OHZ
Version 2.0
D3.5 & D3.7
Coded
name for
EDI
(normative)
PMS
ACM
NLS
TIA
Full name
(normative)
Dictionary
Definition
(normative)
obstructed due to mudslides.
multi level car parks are fully occupied.
includes all accidents involving three or more vehicles.
normal lane widths are temporarily reduced.
NRL
RNL
multi story car parks full
multi-vehicle accident
narrow lanes
national traffic
new road layout
new roadworks layout
NAR
next arrival (Q)
warning of a changed layout for the permanent roadway.
warning of a changed layout for roadworks on the
carriageway.
the next arrival will occur at the specified time.
NDT
next departure
the next departure will occur at the specified time.
TXO
no cross-border
information provided by
this service
no detailed local
this service
no detailed regional
this service
no information available
no more parking spaces
available
no motor vehicles
no new traffic information
available
no park and ride
information
no park and ride
information to report
no parking allowed
no parking information
available
no problems to report
no public transport
information available
no through traffic
TXX
TXD
NIA
PMN
RMP
TXN
PRX
PRC
PFN
PIX
LPX
TXP
RCT
TSX
LRR
PRL
NCR
TNL
Alert C Related
status
data
objects
for EDI
PHR
PHR
PHR
PHR
PAR
ACC
RES
INF
PHR
PHR
RMT
RMT
PHR
PHR
PHR
DEC,
FER
DEC,
FER
INF
PHR
INF
PHR
INF
no information will be available until the specified time
specified car parks are fully occupied.
PHR
PHR
INF
PAR
the road is closed to all motor vehicles in both directions.
no new traffic information is available until the specified
date.
no park and ride information will be available until the
specified time.
park and ride services are operating normally and there
are no problems to report.
no parking allowed until the specified time.
Car-parking information is not available until a specified
time.
there are no traffic problems to report.
PHR
PHR
RES
INF
PHR
PHR
PAR,
INF
PAR
PHR
PHR
PAR
PAR
PHR
PHR
LOS
INF
PHR
RES
PHR
INF
PHR
RES
PHR
PAR
PHR
DEC,
FER
LOS,
RES
the road is closed to all vehicles in the specified direction,
except for local access.
no TMC service available no Traffic Message Channel service is available until the
specified date.
normal lane regulations
the normal restrictions applying to dedicated traffic lanes
restored
are in force.
normal parking
the normal restrictions that apply to parking in a specified
restrictions lifted
area have been lifted.
normal services resumed traffic and travel conditions are back to normal following
the ending of earlier delays or cancellations.
normal traffic expected
normal traffic conditions are expected to resume shortly.
November 2002
D3.5 & D3.7/4 – page 74/97
PHR
Version 2.0
D3.5 & D3.7
Coded
Full name
name for
(normative)
EDI
(normative)
NML
null message - completely
silent
NUL
null message with
location
OMV
objects falling from
moving vehicle
OCL
obstacle clearance
OSI
obstacle signalling
Dictionary
Definition
(normative)
Alert C Related
status
data
objects
for EDI
PHR
INF
Information.
PHR
INF
includes all incidents when objects fall from moving
vehicles, presenting a hazard to other vehicles.
Removal of obstacles
Putting signs before or around an obstacle to protect
drivers
PHR
MHZ
PHR
PHR
OPA
OPA
OWW
obstruction warning
withdrawn
PHR
OHX
obstruction(s) on the road includes all chance occurrences on the roadway involving
earlier causes, or causes external to the traffic stream,
occupancy
This is the proportion of the time a vehicle presence
sensor is activated within a measurement period. It may
be a single value or an n-dimensional matrix.
oil on road
increased skid risk due to oil on road.
oil spillage accident(s)
includes all situations resulting in a spillage of oil on the
carriageway.
one lane blocked
one lane is totally obstructed in the specified direction.
one lane closed
one lane is closed to traffic.
only a few spaces
specified car parks have 95% or greater occupancy.
available
only local information
provided by this service
only major road
this service
only regional information
provided by this service
open
specified carriageways or intersections are available for
use.
PHR
MHZ,
OHZ ,
OPA
OHZ
PHR
OCC
PHR
PHR
SHZ
ACC
PHR
PHR
PHR
RES
RES
PAR
PHR
INF
PHR
INF
PHR
INF
PHR
RES
PHR
INC
PHR
INC
PHR
RES
RES
PHR
PHR
RES
ACC
PHR
ACC
PHR
PHR
SNO
ACT
PHR
RES
OCC
FUE
AOI
LB1
LC1
PFS
TXL
TIR
TXR
OPE
OHV
OHW
CON
LVB
LCP
AOL
AOV
SNP
EVP
PCB
Overhead cables fallen
overheight vehicle(s)
electrical cables have fallen down on the ground
includes all vehicles of height greater than normally
allowed, which mHMinay disrupt traffic.
overheight warning
an overheight vehicle has been detected by the overheight
system triggered
warning system.
overnight closures
the road is closed every night
overtaking lane(s) blocked the overtaking lane is totally obstructed by an unplanned
event.
overtaking lane(s) closed the overtaking lane is closed to traffic.
overturned heavy
includes all situations resulting in the overturning of a
lorr(y/ies)
heavy goods vehicle on the carriageway.
overturned vehicle(s)
includes all situations resulting in the overturning of a
vehicle on the carriageway.
packed snow
packed snow (heavily trafficked) on the network link.
parade
a march which includes a formal display or organised
procession, which could disrupt traffic.
parallel carriageway
the parallel carriageway in the specified direction of
November 2002
D3.5 & D3.7/4 – page 75/97
Version 2.0
D3.5 & D3.7
Coded
name for
EDI
(normative)
PCC
PRI
PRN
PRO
PKT
PSS
PAC
FOP
PEO
OIL
SPC
PTB
PTC
PTH
PRA
TXW
EPR
PRV
EPD
PTN
Full name
(normative)
Definition
(normative)
blocked
parallel carriageway
closed
park and ride information
available again
park and ride service not
operating
park and ride service
operating
park and ride trip time
travel is total obstructed by an unplanned event.
the parallel carriageway in the specified direction of
travel is closed.
the information service for park and ride is now
available.
park and ride services are not operating until the specified
time.
park and ride services are operating until the specified
time.
Travel time is the time taken to travel between 2
specified points, by a specified route, including any time
taken by involuntary stops and delays, when using park
and ride transportation. It may be a single value or an ndimensional matrix.
passable
roadway being passable by vehicles. This information
may be applied to roads above a specified altitude.
passable with care
roadway being passable by vehicles with care from the
driver. This information may be applied to roads above a
specified altitude.
patchy fog
fog, in which intermittent areas of dense fog may be
encountered.
people on roadway
traffic may be disrupted due to people on the roadway.
petrol on roadway
increased skid risk due to fuel on road.
police checkpoint
a permanent or temporary area established on or adjacent
to the carriageway for use by police or other authorities.
police directing traffic via police are directing traffic via the bus lane. Normal bus
the bus lane
lane restrictions do not apply.
police directing traffic via police are directing traffic via the carpool lane. Normal
the carpool lane
carpool restrictions do not apply.
police directing traffic via the police are directing traffic via the heavy vehicle lane.
the heavy vehicle lane
Normal restrictions do not apply.
precipitation on the area unspecified precipitation are falling down on the area
previous announcement
about this or other TMC
services no longer valid
procession
an organised procession which could disrupt traffic.
prohibited vehicle(s) on vehicles not normally permitted on the highway are
the roadway
present. This may cause a hazard.
PT traffic rerouted
PT traffic stopped
public disturbance
PTS
public transport services
not operating
public transport services
resumed
public transport strike
LS2
queuing traffic
RTO
Dictionary
includes all situations of public disorder, with potential to
disrupt traffic.
public transport services are not operating until the
specified time.
public transport services are operating normally.
public transport services are reduced or not operating due
to a strike.
the average speed of traffic is between 10% and 25% of
its free-flow level.
November 2002
D3.5 & D3.7/4 – page 76/97
Alert C Related
status
data
objects
for EDI
PHR
RES
PHR
PAR
PHR
DEC,
PAR
DEC,
PAR
PAR,
TTM
PHR
PHR
PHR
SHZ
PHR
SHZ
PHR
FOS
PHR
PHR
PHR
ACT
SHZ
ACT
PHR
RES
PHR
RES
PHR
RES
PHR
PRE
INF
PHR
PHR
ACT
MHZ
PHR
ACT
PHR
DEC
PHR
DEC,
FER
DEC,
FER
LOS
PHR
PHR
Version 2.0
D3.5 & D3.7
Coded
Full name
name for
(normative)
EDI
(normative)
ERA
race meeting
Dictionary
Definition
(normative)
REL
includes all types of horse racing events that could
disrupt traffic.
rail crash
traffic may be disrupted due to a rail crash.
rail services irregular.
normal rail services are affected and running at irregular
Delays
intervals and delays are expected for passengers.
rail services not operating rail services are not operating until the specified time.
rain
rain, visibility more than 50m.
ramp control signals not the ramp control signals that control vehicles entry to and
working
exit from carriageways at a specified location are not
working (i.e. they appear to be switched off).
ramp control signals
the traffic lights that control vehicles entry to and exit
working incorrectly
from a carriageway at a specified location are working
incorrectly, presenting a potential hazard to motorists.
reckless driver(s)
a vehicle may cause a hazard due the driver driving
without care and attention.
reference to audio
programmes no longer
valid
reference to other TMC
services no longer valid
Reopened
traffic can once again use the network link in the
specified direction following the lifting of an earlier
closure or the clearance of an earlier blockage.
rerouting advised
Rerouting is advised to drivers
rescue and recovery work work is being undertaken by emergency services which
mHMinay present a hazard to travellers.
restaurant reopened
the earlier reported restaurant is open.
restrictions
restrictions different from the normal highway
restrictions have been imposed on specific network links.
restrictions for high-sided the earlier reported hazard warning for high-sided
vehicles lifted
vehicles has been cancelled.
restrictions lifted
earlier restrictions reported have now been lifted.
RWR
resurfacing work
RAC
RSI
RSN
RAI
RNW
RCI
RDW
TXY
TXZ
RCR
RAD
REW
SRX
RET
TOX
LBR
LCR
RPB
RCP
RC2
RIN
RCX
RCL
RLU
includes all work associated with overlays or renewal of
worn-out road surfaces (pavements).
right lane(s) blocked
the lane furthest to the right is totally obstructed.
right lane(s) closed
the lane furthest to the right is closed to traffic.
right-hand parallel
the right-hand parallel carriageway in the specified
carriageway blocked
direction of travel is totally obstructed by an unplanned
event.
right-hand parallel
the right-hand parallel carriageway in the specified
carriageway closed
direction of travel is closed.
road cleared
the roadway has been cleared of earlier reported
problems.
road closed intermittently road closures occur intermittently on the specified road in
the specified direction.
road conditions improved driving conditions have improved relative to those
indicated in earlier messages.
road free again
the roadway is back to normal following the removal of
the obstruction hazard.
road layout unchanged
the existing road layout will remain unchanged during the
period of roadworks.
November 2002
D3.5 & D3.7/4 – page 77/97
Alert C Related
status
data
objects
for EDI
PHR
ACT
PHR
PHR
PHR
PHR
PHR
OHZ
DEC,
FER
DEC
PRE
EQU
PHR
EQU
PHR
MHZ
PHR
INF
PHR
INF
PHR
RES
PHR
PHR
ROU
OHZ
PHR
PHR
RES
RES
PHR
WIN
PHR
PHR
RES,
ROU
RMT
PHR
PHR
PHR
RES
RES
RES
PHR
RES
PHR
MHZ
PHR
RES
PHR
PHR
SHZ,
SNO
OHZ
PHR
RMT
Version 2.0
D3.5 & D3.7
Coded
Full name
name for
(normative)
EDI
(normative)
RMW
road marking work
RPC
CPW
RWX
RWK
RWC
ROC
RRU
SAL
SAN
Dictionary
Definition
(normative)
includes all striping and repainting of road markings, plus
placement or replacement of reflecting studs (cats’ eyes).
road surface in poor
increased driving hazards due to poor road surface
condition
condition. The road surface is damaged, severely rutted
or potholed. This may be applied to roads above a
specified altitude.
roads permanently closed the road is closed during winter
for the winter
roadwork clearance in
roadworks are completed and are being cleared.
progress
roadworks
includes all highway maintenance activities which
potentially affect traffic operations.
roadworks cleared
the roadway is back to normal following the termination
of earlier maintenance or construction activities.
rockfalls
obstructed due to fallen rocks.
rugby match
includes all types of rugby matches that could disrupt
traffic.
salting in progress
Spreading salt on the network link surface to prevent or
melt snow or ice
sandstorms
sand blowing across the network link causing
PHR
RMT
PHR
SHZ
RES
PHR
RMT
PHR
RMT
PHR
RMT
PHR
OHZ
PHR
ACT
OPA
PHR
FOS
PHR
ACC
PHR
ACT
PHR
PHR
ACT
ACT
PHR
ACC
PHR
OHZ
PHR
PHR
RES
RES
PHR
RES
PHR
RES
PHR
DEC,
FER
PHR
DEC,
FER
DEC,
FER
DEC,
FER
ACT
DPN
a group of people is scuffling in the PT premises
includes all situations resulting from vehicles avoiding or
being distracted by earlier accidents.
security alert
includes all official responses to perceived or actual
threats of crime or terrorism, which could disrupt traffic.
security alert cleared
earlier reported security problems have been cleared.
security incident
includes all perceived or actual threats of crime or
terrorism, which could disrupt traffic.
serious accident(s)
includes all accidents believed to involve fatality or
injury expected to require overnight hospitalisation.
serious fire
traffic may be disrupted due to a fire (other than a vehicle
fire) adjacent to the network link.
service area busy
the service area specified is close to capacity.
service area overcrowded, the service area specified is close to capacity and
drive to another service
motorists are advised to seek an alternative.
area
service area, fuel station the fuel station at the specified service area is closed.
closed
service area, restaurant
the restaurant at the specified service area is closed.
closed
service not operating,
the specified service is not operating but an alternative
substitute service
service is available.
available.
service suspended
all services have been suspended until the specified time.
SCN
service withdrawn
a particular departure is cancelled.
PHR
SFB
service(s) fully booked
a particular departure is full.
PHR
ESM
several major events
a series of deliberate human actions external to the traffic
PHR
ACD
ESA
ESY
ESI
ACS
FIR
SAB
SAO
SFC
SRC
SNS
Scuffle
secondary accident(s)
Alert C Related
status
data
objects
for EDI
November 2002
D3.5 & D3.7/4 – page 78/97
Version 2.0
D3.5 & D3.7
Coded
name for
EDI
(normative)
Full name
(normative)
EXS
severe exhaust pollution
SSM
severe smog
SWC
SEW
SHL
ESH
ESJ
SWS
SSO
ESS
SAT
SHX
SLT
RSR
RSB
REX
RSO
RSL
RMV
LS3
LBD
LCD
SVH
SLU
Dictionary
Definition
(normative)
stream which could disrupt traffic.
pollution from exhaust fumes has reached a level
sufficient to cause concern.
environmental warning of very poor air quality resulting
from smog.
Severe traveller personal a traveller has been severely injured
injury accident
sewer collapse
the network link surface has sunken or collapsed in
places due to sewer failure.
sewer overflow
the road is obstructed or partially obstructed by overflows
from one or more sewers.
shed load(s)
includes all situations resulting in the spillage of
transported goods on the network link.
show
includes all entertainment events that could disrupt
traffic.
show jumping
includes all types of showing jumping and tournament
events that could disrupt traffic.
showers
light rain or intermittent rain.
shuttle service operating a shuttle service is operating between specified locations
until the specified time.
sightseers obstructing
attendees or sightseers to reported events causing
access
obstruction to access.
Signal failure
train signals are not or not properly working
single alternate line traffic traffic is being controlled to move in alternate single
lines. This control may be undertaken by traffic lights or
flagmen. Congestion is expected.
skid hazard reduced
the network link surface conditions have improved
relative to those indicated in earlier messages.
sleet
rain mingled with snow or hail.
slip road restrictions
other restrictions are in force preventing certain classes of
traffic joining or leaving the highway in the specified
direction.
slip roads blocked
traffic cannot join or leave the highway at a particular
unplanned event.
slip roads closed
traffic cannot join or leave the highway at a particular
slip roads reopened
traffic can once again join or leave the highway at a
particular intersection following the lifting of an earlier
slip road closure or restriction.
slippery road
includes all situations in which the normal risks of
skidding are increased.
slow moving maintenance slow moving vehicles undertaking maintenance work
vehicle(s)
may pose a hazard to other vehicles on the carriageway
slow traffic
the average speed of traffic is between 25% and 75% of
its free-flow level.
slow vehicle lane blocked the slow vehicle lane is totally obstructed by an
unplanned event.
slow vehicle lane closed the slow vehicle lane is closed to traffic.
slow vehicle(s)
a vehicle travelling at well below normal highway
speeds, which mHMinay disrupt traffic.
slush
increased skid risk due to melting snow on network link.
November 2002
D3.5 & D3.7/4 – page 79/97
Alert C Related
status
data
objects
for EDI
PHR
EXH
PHR
FOS
PHR
OHZ
PHR
OHZ
PHR
PHR
ACC,
INC
ACT
PHR
ACT
PHR
PHR
PHR
PRE
DEC,
FER
ACT
PHR
RMT
PHR
SHZ
PHR
PHR
PRE
RES
PHR
RES
PHR
RES
PHR
RES
PHR
SHZ
PHR
PHR
RMT,
MHZ
LOS
PHR
RES
PHR
PHR
RES
MHZ
PHR
SNO
Version 2.0
D3.5 & D3.7
Coded
Full name
name for
(normative)
EDI
(normative)
SMG
smog alert
SMX
SMO
smog alert ended
smoke hazard
Dictionary
Definition
(normative)
environmental warning of poor air quality resulting from
smog.
earlier smog alert has ended.
smoke drifting across the network link causing
SNX
Smoke release
snow chains mandatory
snow chains
recommended
snow cleared
SNR
snow drifts
SRO
snow on the road
TM
TR
SFL
SN
snow tyres mandatory
snow tyres recommended
snowfall
falling snow, visibility more than 50m.
snowploughs in use
snowploughs or other similar mechanical devices are
being used to clear snow from the network link.
special parking
parking restrictions, other than those that normally apply,
restrictions in force
are in force in a specified area.
special parking
earlier reported special parking restrictions have finished.
restrictions lifted
special public transport
public transport services providing special facilities are
services operating
operating until the specified time.
spillage occurring from
includes all incidents when substances are spilled from
moving vehicle
moving vehicles, presenting a hazard to other vehicles.
spillage on the road
includes all situations where a spillage has occurred on
the roadway due to an earlier incident.
sports meeting
includes all types of sporting events that could disrupt
traffic.
sports traffic cleared
traffic disruption due to a sporting event has ended.
spray hazard
reduced visibility resulting from spray created by moving
vehicle on a wet roadway.
state occasion
includes all public ceremonies and visits of national or
international significance, which could disrupt traffic.
SM
SR
PSR
PSL
PRS
SMV
SPL
ESP
ESX
SPY
ESO
LS1
Alert C Related
status
data
objects
for EDI
PHR
EXH
PHR
PHR
EXH
FOS
SAD
SAD
SNE
SNE
PHR
SNO
PHR
SNO
PHR
SNO
SAD
SAD
PHR
SAD
SNE
SNE
PRE
OPA
PHR
PAR
PHR
PAR
PHR
DEC
PHR
MHZ
PHR
OHZ
PHR
ACT
PHR
PHR
ACT
FOS
PHR
ACT
PHR
LOS
smoke is being released for an unspecified reason
the earlier reported snow on the network link has been
cleared.
snow drifting in progress, or patches of deep snow due to
earlier drifting.
includes all situations with snow lying on the road
surface.
Station access closed
Station access re-opened
Station closed
Station closed but
interconnection
maintained
Station re-opened
stationary traffic
the average speed of traffic is less than 10% of its freeflow level.
Stop point closed
Stop point moved
Stop point returned to
normal
November 2002
D3.5 & D3.7/4 – page 80/97
Version 2.0
D3.5 & D3.7
Coded
Full name
name for
(normative)
EDI
(normative)
STD
storm damage
STM
EST
storm force winds
strike
WIS
WIX
Strike due to an attack
Strike in a bus unit
Strike of the electricity
supplier
Strike on the line
Strike on the whole
network
strong winds
strong winds have eased
STF
STU
SUB
stud tyres are not
authorised
stud tyres may be used
subsidence
SWH
Suicide
surface water hazard
SWA
swarms of insects
SWT
TFA
TAL
TAX
TGW
HLT
HLL
LLT
LLL
TLT
TNW
TWI
Dictionary
Definition
(normative)
obstructed by debris caused by strong winds.
include all types of action that could disrupt road
traffic or PT operation.
Alert C Related
status
data
objects
for EDI
PHR
OHZ
PHR
PHR
WIN
ACT
PHR
PHR
WIN
WIN
a strike concerns a specific bus unit
a strike concerns a specific line
a strike concerns the whole network
earlier warning of winds (at least strong) no longer
applies.
SNE
the network link surface has sunken or collapsed in
places.
suicide of a traveller on the tracks
water resting on the network link which provides an
increased hazard to vehicles.
large numbers of insects which create a hazard for
network link users through reduced visibility.
Switch (rail point)
incident
switch your car radio to instructions to retune car radios to a specified frequency.
XX
temperature falling
the current temperature is expected to fall.
temporary axle load limit a temporary restriction has been imposed, limiting the
maximum permitted axle load of vehicles.
temporary axle weight
the earlier reported temporary axle weight limited has
limit lifted
ended.
temporary gross weight
a temporary restriction has been imposed, limiting the
limit
maximum permitted gross weight of vehicles.
temporary height limit
maximum permitted height of vehicles.
temporary height limit
the earlier temporary height limit is no longer in force.
lifted
temporary length limit
maximum permitted length of vehicles.
temporary length limit
the earlier temporary length limit is no longer in force.
lifted
temporary traffic lights
includes all temporary traffic layouts controlled by traffic
lights (red-yellow-green or red-green).
the temporary traffic signals at a specified location are
not working
not working (i.e. they appear to be switched off).
the temporary traffic lights at a specified location are
working incorrectly
working incorrectly, presenting a potential hazard to
motorists.
November 2002
D3.5 & D3.7/4 – page 81/97
PHR
SNE
OHZ
PHR
SHZ
PHR
EXH,
FOS
PHR
INF
PHR
PHR
WDA
RES
PHR
RES
PHR
RES
PHR
RES
PHR
RES
PHR
RES
PHR
RES
PHR
RMT
PHR
EQU
PHR
EQU
Version 2.0
D3.5 & D3.7
Coded
Full name
name for
(normative)
EDI
(normative)
TGL
temporary weight limit
lifted
WLT
temporary width limit
WLL
ETT
temporary width limit
lifted
tennis tournament
STI
terrorist incident
TMO
LB3
this message is for test
purposes only. Please
ignore
three lanes blocked
LC3
TTB
three lanes closed
through traffic lanes
blocked
TTL
TRX
TOR
through traffic lanes
closed
thunderstorms
TMC broadcast on this
frequency will stop
tornado warning ended
tornadoes
ETO
tournament
TLV
Track breaking
Track works
track-laying vehicle(s)
TRA
trade fair
TBU
traffic building up
TCN
TDX
traffic congestion
traffic disruption cleared
TEA
traffic easing
THU
TXS
LS5
ETN
LTH
TLN
Dictionary
Definition
(normative)
Alert C Related
status
data
objects
for EDI
the earlier temporary axle or gross vehicle weight limit is
no longer in force.
maximum permitted width of vehicles.
the earlier temporary width limit is no longer in force.
PHR
RES
PHR
RES
PHR
RES
includes all types of tennis tournament that could disrupt
traffic.
includes all perceived or actual threats of terrorism,
includes all test messages for operational and
maintenance use only.
PHR
ACT
PHR
ACT
PHR
INF
PHR
RES
PHR
PHR
RES
RES
PHR
RES
PHR
PHR
PRE
INF
PHR
PHR
WIN
WIN
PHR
ACT
PHR
MHZ
PHR
ACT
PHR
LOS
PHR
PHR
PHR
LOS
ACC,
ACT,
INC,
LOS
LOS
PHR
LOS
PHR
ACT
PHR
LOS
PHR
LOS
three lanes are totally obstructed in the specified
direction.
three lanes are closed to traffic.
the lanes for through traffic (non-local traffic) in the
specified direction of travel are totally obstructed by an
unplanned event.
the lanes for through traffic (non-local traffic) in the
specified direction of travel are closed.
electrical storms, generally with heavy rain.
the earlier warning of tornadoes has ended.
very violent, whirling windstorms affecting narrow strips
of country.
a sporting event or series of events which could disrupt
traffic.
the rupture of a track
traffic conditions are back to normal following the
clearance of an earlier disruption.
trade promotion, which could disrupt traffic.
traffic conditions are changing from free-flow to heavy or
slow service levels. Queues may also be expected.
traffic congestion present.
the earlier report traffic disruption has ended.
traffic conditions are changing from heavy or slow
service levels to free-flow.
traffic flowing freely
the average speed of traffic is at least 90% of its free-flow
level.
traffic has returned to
traffic is back to normal following the ending of an
normal
earlier event.
traffic heavier than
current traffic conditions are more congested than normal
normal
conditions.
traffic lighter than normal current traffic conditions are less congested than normal
conditions.
November 2002
D3.5 & D3.7/4 – page 82/97
Version 2.0
D3.5 & D3.7
Dictionary
Coded
Full name
Definition
Alert C Related
name for
(normative)
(normative)
status
data
EDI
objects
for EDI
(normative)
TLO
traffic lights not working the traffic signals at a specified location are not working
PHR
EQU
(i.e. they appear to be switched off).
TLI
traffic lights working
the traffic lights at a specified location are working
PHR
EQU
incorrectly
incorrectly, presenting a potential hazard to motorists.
LSO
traffic problem
a traffic situation is resulting in a reduced level of service PHR
LOS
TCX
traffic problem congestion traffic is now free flowing following the clearance of
PHR
LOS
cleared
conditions reported earlier.
TRC
traffic regulations have
includes all situations where traffic regulations have been PHR
RES
been changed
permanently modified.
TCC
traffic signal control
the traffic signal timing computer is not working possibly PHR
EQU
computer not working
causing greater disruption to traffic than normal
conditions.
TSC
traffic signal timings
traffic signal phase timings or sequence have been altered PHR
EQU
changed
which mHMinay cause a hazard to travellers.
TSR
traffic signals repaired
traffic signals are again working normally.
PHR
EQU
LTM
traffic very much heavier current traffic conditions are very much mHMinore
PHR
LOS
than normal
congested than normal conditions.
RIS
tram service not operating tram services are not operating until the specified time.
PHR
DEC
TTM
travel time
Travel time is the time taken to travel between 2
TTM
specified points, by a specified route, including any time
taken by involuntary stops and delays. It may be a single
value or an n-dimensional matrix.
Traveller in a tunnel
Traveller on the tracks
TRT
TUB
TUC
TVX
LBT
trip time
tunnel blocked
tunnel closed
tunnel ventilation not
working
turning lane blocked
LCT
LB2
LC2
turning lane closed
two lanes blocked
two lanes closed
USN
USI
UGI
Undefined event
Undefined explosion
Undefined traveller
incident
Undefined works
underground service not
operating
underground services
irregular
traffic may be disrupted due to a traveller in a tunnel
traffic may be disrupted due to a traveller on the
track
the duration of a journey between specified points.
the tunnel is blocked in the specified direction.
the tunnel is closed in the specified direction.
ventilation equipment in the tunnel is not working,
possibly causing pollution problems and poor air quality.
the turning lane is totally obstructed in the specified
direction .two-way traffic is temporarily sharing a single
carriageway, and normal lanes widths are reduced.
the turning lane is closed to traffic.
two lanes are totally obstructed in the specified direction.
two lanes are closed to traffic.
PHR
PHR
PHR
PHR
DEC
RES
RES
EQU
PHR
RES
PHR
PHR
PHR
RES
RES
RES
PHR
DEC
PHR
DEC
PHR
INF
a traveller is involved in an undefined incident
underground services are not operating until the specified
time.
underground services are affected and running at
irregular intervals.
Underground works
Undetermined strike
a strike the extent or nature of which is not specified
Undetermined technical
incident
urgent information will be
given on normal program
November 2002
D3.5 & D3.7/4 – page 83/97
Version 2.0
D3.5 & D3.7
Coded
name for
EDI
(normative)
UBV
UBA
UCA
UHA
UHV
VNW
VWN
VWI
VFR
VOD
HAZ
VWC
ASP
VSA
Full name
(normative)
broadcast
use of bus lane allowed
for all vehicles
use of bus lane allowed
under carpool restriction
use of carpool lane
allowed for all vehicles
use of hard shoulder
allowed
use of heavy vehicle lane
allowed for all vehicles
variable message signs
not working
operating
working incorrectly
vehicle fire(s)
vehicle with overheight
load, danger
vehicle(s) carrying
hazardous materials
vehicle(s) on wrong
carriageway
vehicle(s) spun around
DVL
VSX
vehicles slowing to look
at accident(s)
very long delays
visibility improved
VIR
visibility reduced
WMW
water main work
EWS
water sports meeting
WSZ
RWI
weather expected to
improve
weather situation
improved
wet and icy roads
WHI
white out
WLD
wide load(s)
WRM
winter equipment
WSX
Dictionary
Definition
(normative)
all vehicles may use the bus lane. Bus lane restrictions
are not in force.
vehicles satisfying carpool restrictions may use the bus
lane.
all vehicles may use the carpool lane. Carpool
restrictions are not in force.
motorists are permitted to use the hard shoulder including
non-emergency reasons.
the restrictions governing use of the heavy vehicle lane
are not in force.
includes all failures to variable message signs.
includes all situations where variable message signs
(indicating lane closures, speed limits, etc.).
includes all malfunctions to variable message signs (such
that misleading or incorrect information is provided).
includes all situations resulting where a vehicle is or has
been on fire.
an overheight vehicle has been detected, and this may
present a hazard to travellers
vehicles carrying materials which could present an
additional hazard to travellers.
a vehicle is travelling the wrong way along a divided
highway (i.e. on the wrong side).
includes all situations resulting where a vehicle has
skidded and has come to rest not facing its intended line
of travel.
reduced level of service resulting from passing vehicles
slowing to look at an accident.
delays of abnormally unusual severity.
earlier reduced visibility has lifted.
includes all environmental conditions resulting in reduced
visibility.
includes all water main construction and maintenance
work on the highway.
includes all types of water sports meeting and events (e.g.
rowing, powerboat racing, sailing, etc.) that could disrupt
traffic.
the weather conditions are expected to improve from the
current conditions.
earlier bad weather easing, or weather warning cancelled.
increased skid risk due to partly thawed, wet road with
packed snow and ice, or rain falling on packed snow and
ice.
falling snow in blizzard conditions resulting in reduced
visibility
a vehicle of width greater than that normally allowed,
which mHMinay disrupt traffic.
November 2002
D3.5 & D3.7/4 – page 84/97
Alert C Related
status
data
objects
for EDI
PHR
RES
PHR
RES
PHR
RES
PHR
RES
PHR
RES
PHR
EQU
PHR
EQU
PHR
EQU
PHR
INC
PHR
MHZ
PHR
MHZ
PHR
MHZ
PHR
ACC
PHR
PHR
ACC,
INC
DEC
EXH,
FOS
FOS
PHR
RMT
PHR
ACT
PHR
WDA
PHR
WDA
PHR
SHZ
PHR
FOS
PHR
MHZ
PHR
PHR
SNE
Version 2.0
D3.5 & D3.7
Coded
name for
EDI
(normative)
Full name
(normative)
EWT
mandatory
winter equipment
recommended
winter sports meeting
WST
winter storm
WBC
work on buried cables
WBS
work on buried services
WR
Dictionary
Definition
(normative)
includes all types of winter sports meeting and events
(e.g. skiing, ski jumping, skating) that could disrupt
traffic.
heavy rain, sleet, hail and/or snow in combination with
strong winds, limiting visibility to 50m or less.
includes all construction and maintenance work on buried
cables under the highway.
includes all water main construction and maintenance
work on the highway.
November 2002
D3.5 & D3.7/4 – page 85/97
Alert C Related
status
data
objects
for EDI
SAD
SNE
PHR
ACT
PHR
PRE
PHR
RMT
PHR
RMT
Version 2.0
D3.5 & D3.7
Dictionary
Table 5 List of the instances of Alert C supplementary information (normative)
Coded name for
EDI
AO
EP
AP
BE
AH
RU
FE
CW
CD
CC
DA
DX
DF
Full name
access only
allow emergency vehicles to pass
approach with care
around a bend in the road
at high altitudes
avoid the rush hour
clear a lane for emergency vehicles
close all windows. Turn off heater and vents
Compulsory diversion in operation
cross junction with care
danger
danger of explosion
danger of fire
DO
diversion in operation
DL
UG
NS
NA
NL
SU
DC
DE
EC
EE
EI
FR
HE
HT
LN
ST
TP
OF
DY
NI
EW
TU
EX
XP
FF
FD
FV
FS
DM
TV
diversion is no longer recommended
do not allow unnecessary gaps
do not drive on the hard shoulder
do not follow diversion signs
do not leave your vehicle
do not slow down unnecessarily
drive carefully
drive with extreme caution
due to an earlier accident
due to an earlier event
Due to an earlier incident
due to frost
due to heat
Due to holiday traffic
due to large numbers of visitors
due to shear weight of traffic
due to technical problems
during off-peak periods
during the day time
during the night
emergency vehicles at workscene
entering or leaving tunnels
except
extra police patrols in operation
fairly frequent service
follow diversion signs
follow local diversion
follow signs
follow special diversion markers
follow the vehicle in front, smoothly
November 2002
D3.5 & D3.7/4 – page 86/97
Version 2.0
D3.5 & D3.7
Coded name for
EDI
LI
AB
AL
FA
AV
BU
CO
CA
CT
TL
FP
DI
XO
FY
HZ
LO
HO
HV
TH
LV
LT
LD
LG
EN
FC
RC
RE
RF
RI
RT
FT
VC
VT
VW
VI
FQ
FM
GP
HA
HL
HR
IN
PP
IL
SA
BL
HU
CE
Dictionary
Full name
for a limited time
for abnormal loads only
for all vehicles
for arrivals
for articulated vehicles only
for buses only
for cars and light vehicles only
for cars only
for cars with caravans only
for cars with trailers only
for departures
for diesel-engined vehicles with diesel engines only
for exceptional loads only
for ferry service
for hazardous loads only
for heavy lorries only
for heavy vehicles only
for high-sided vehicles only
for holiday traffic
for light vehicles only
for local traffic
for long distance traffic
For LPG vehicles with liquid gas or LPG engines only
for petrol-engined vehicles with internal combustion engines only
For rail services
for regional traffic
for residents
for roads from
for roads in
for roads leading towards
For through traffic
for vehicles with catalytic converters
for vehicles with trailers only
for vehicles without catalytic converters
For visitors
frequent service
from
gritting vehicles in use
heavy lorries are recommended to avoid the area
heavy vehicles use left lane
heavy vehicles use right lane
in
in emergency, wait for police patrol
in low-laying areas
in shaded areas
in the bus lane
in the carpool lane
in the centre
November 2002
D3.5 & D3.7/4 – page 87/97
Version 2.0
D3.5 & D3.7
Coded name for
EDI
IC
CR
CL
EL
XL
IH
IA
LL
LP
LA
ML
OL
OD
VL
PC
RL
RP
IR
IV
IG
TG
IT
FO
RK
NN
KR
KL
KD
PS
AA
FL
SL
NF
NV
NK
ND
OZ
OS
OG
OP
OB
OX
HS
LE
OO
RG
OR
OU
Dictionary
Full name
in the city centre
In the connecting carriageway
in the crawler lane
in the emergency lane
In the express lane
In the heavy vehicle lane
in the inner city area
in the left lane
In the left-hand parallel carriageway
In the local lane
in the middle lane
in the opposing lanes
in the opposite direction
in the overtaking lane
In the parallel carriageway
in the right lane
In the right-hand parallel carriageway
in the roadworks area
In the slow vehicle lane
In the through traffic lane
In the turning lane
in tunnels
increase normal following distance
increased risk of accident
is this your no-ride day?
keep to the left
keep to the right
keep your distance
leave your vehicle. Proceed to next save place
local drivers are recommended to avoid the area
look out for flagman
mandatory speed limit in force
no naked flames
no overtaking
no smoking
no suitable diversion available
observe recommended speed
observe signals
observe signs
observe speed limits
on bridges
on slip roads
on the hard shoulder
on the left
on the opposite carriageway
on the right
on the roadway
On the underground
November 2002
D3.5 & D3.7/4 – page 88/97
Version 2.0
D3.5 & D3.7
Coded name for
EDI
ON
DN
OC
VE
PI
UB
UV
UT
UU
PD
PA
SC
PU
RD
RS
RQ
RA
RW
SV
Dictionary
Full name
only
only travel if absolutely necessary
over the crest of a hill
overtake with care
pilot car in operation
Please use bus service
Please use rail service
Please use tram service
Please use underground service
police directing traffic
police in attendance
police speed checks in operation
pull over to the edge of the roadway
Radiation hazard
reduce your speed
regularly frequent service
repairs in progress
rescue and recovery work in progress
several times
SM
snow chains mandatory
SR
snow chains recommended
TM
snow tyres mandatory
TR
snow tyres recommended
SN
snowploughs in use
SD
SH
NR
PL
OE
MR
TB
EA
NO
NE
NW
SO
SE
SW
WE
TO
LK
TA
WD
UN
UF
US
HW
UH
sorry for any delay
speed limit in force for heavy vehicles
stop at next rest service area or car park
stop at next safe place
switch off engine off
switch off mobile phones and two-way radios
test your brakes
the east
the north
the north-east
the north-west
the south
the south-east
the south-west
the west
to
Toxic leak
traffic being directed around accident area
Traffic wardens directing traffic
until further notice
use fog lights
use hard shoulder as lane
use hazard warning lights
use headlights
November 2002
D3.5 & D3.7/4 – page 89/97
Version 2.0
D3.5 & D3.7
Coded name for
EDI
GL
UL
LH
LC
UR
RH
TT
VF
EV
GC
PR
CP
PT
WR
PE
PO
ET
Dictionary
Full name
use heavy vehicle lane
use left lane
use left-hand parallel carriageway
use local traffic lanes
use right lane
use right-hand parallel carriageway
use through traffic lanes
very frequent service
wait for escort vehicle
we are grateful for your co-operation
why not park-and-ride?
why not ride share ?
why not try public transport?
winter equipment recommended
with even-numbered registration plates
with odd-numbered registration plates
your parking ticket covers the return ride
November 2002
D3.5 & D3.7/4 – page 90/97
Version 2.0
D3.5 & D3.7
Dictionary
6 Classifications of vehicles
[normative]
[No changes are necessary to Clause 6 in the reference document DATEX Data Dictionary
v3.1a, except a change in the table numbers: tables 7-11 should now read 6-10]
November 2002
D3.5 & D3.7/4 – page 91/97
Version 2.0
D3.5 & D3.7
Dictionary
7 Relationship between data objects and
attributes
[informative]
[This section is deleted and replaced by the data model which provides a better and more
concise definition of this relationship.]
November 2002
D3.5 & D3.7/4 – page 92/97
Version 2.0
D3.5 & D3.7
Dictionary
8 User Guide for the EDI approach
[Informative]
[The title of the user guide is modified to restrict its use to the EDI approach
8.1 Traffic and Travel Situations
[unchanged]
8.2 Understanding and Using the Data Dictionary
[unchanged]
8.3 Message Management Issues
[unchanged]
8.4 Developing aTraffic and Travel Database Using the
Data Dictionary
[unchanged]
8.5 Phrases and causes
[This clause substitutes clause 8.5 of the reference document Datex Data Dictionary v3.1a.]
These attributes may appear identical but they are not. The phrase is the major attribute for a
situation element, saying “what” has happened. The other attributes say when, where, how
many, etc; amongst them, the attribute “cause” is here to give the reason of the event reported.
The cause value is taken out of the same list used for phrases.
For example if an accident occurs, involving a jack-knifed caravan, due to storm force wind,
the situation element may be described in the following way:
Phrase: PHR=AJC (jack-knifed caravan); plus information on location, start time, etc
Cause: PHC=STM (storm force wind); no additional information on wind.
The following paragraphs describe examples of use of "cause" (PHC) and "situation cause"
(SIC).
Let us assume that an accident occurs due to fog. We assume that the traffic operator in
charge of this road has no information on the fog location, start time, duration, visibility
distance, etc. or no responsibility to report fog. He will create a situation with only one
November 2002
D3.5 & D3.7/4 – page 93/97
Version 2.0
D3.5 & D3.7
Dictionary
situation element, with data object ACC (Accident) and set PHC to FOG (fog) or possibly,
FOD (dense fog).
Now, let us assume that the accident is caused by roadworks. Roadworks are managed by the
traffic operator who is already reporting on them at the time that the accident occurs. He first
has created a single-element situation with the element containing a data object code RMT
(Road maintenance). He will then add a second element with data object ACC (Accident) and
insert in the first element (with data object RMT) the attribute SIC="Y". If due to the accident
stationary traffic occurs, a third element with data object LOS (Level of Service) will be
added, and the SIC value of the first element (RMT) will be kept unchanged because the
roadworks are the reason for the set of situation elements."
8.6 How to link information
[unchanged]
November 2002
D3.5 & D3.7/4 – page 94/97
Version 2.0
D3.5 & D3.7
Dictionary
Annex 1 Transmodel data definition
(excerpts of entities used in Trident)
November 2002
D3.5 & D3.7/4 – page 95/97
Version 2.0
D3.5 & D3.7
Dictionary
A1. DATA DEFINITIONS
Entity Name
----------------------------------------------------------------
Description
---------------------------------------------------------------------
CALENDAR DAY
A specific day in the calendar where public transport
operation takes place.
COMPANY
A company providing public transport services.
CONNECTION LINK
The physical (spatial) possibility for a passenger to
change from one public transport vehicle to another to
continue the trip. Different times may be necessary to
cover this link, depending on the kind of passenger.
DAY TYPE
A type of day characterised by one or more properties
which affect public transport operation. For example:
weekday in school holidays.
JOURNEY PATTERN
An ordered list of STOP POINTs and TIMING POINTs
on a single ROUTE, describing the pattern of working
for public transport vehicles. A JOURNEY PATTERN
may pass through the same POINT more than once. The
first point of a JOURNEY PATTERN is the origin. The
last point is the destination.
LINE
A group of ROUTEs which is generally known to the
public by a similar name or number.
MEAN PASSENGER WAIT TIME
An estimated mean waiting time for a passenger at a
STOP POINT, used to calculate the approximate
duration of a TRIP. This value is estimated from the
mean interval between vehicles on a JOURNEY
PATTERN or a COMMON SECTION.
NETWORK VERSION
A set of network data (and other data logically related
to these) to which the same validity period has been
assigned. A NETWORK VERSION is identified by the
start date of its validity period. The end date of this
validity period is derived from the start date of the next
NETWORK VERSION recorded. Thus, at each
CALENDAR DAY, one and only one NETWORK
VERSION will be valid.
OPERATING DEPARTMENT
The operating department which administers certain
LINEs.
ORGANISATIONAL UNIT
A grouping of responsibilities in a public transport
company for planning and control.
PERIOD
A continuous interval of time between two
CALENDAR DAYs which will be used to define
validities.
PLACE
A geographic place of any type whicHMinay be
specified as the origin or destination of a TRIP. A
November 2002
D3.5 & D3.7/4 – page 96/97
Version 2.0
D3.5 & D3.7
Dictionary
PLACE may be of dimension 0 (a POINT), 1 (a road
section) or 2 (a ZONE).
POINT
The smallest identified location in space.
Entity Name
----------------------------------------------------------------
Description
---------------------------------------------------------------------
PROPERTY OF DAY
A property which a day may posess, such as school
holiday, weekday, summer, winter etc.
A part of a TRIP corresponding to the theoretical
movement of a user (passenger, driver) on one and only
one public transport vehicle, from one STOP POINT to
another, on one JOURNEY PATTERN.
RIDE
ROUTE
An ordered list of MAPPING POINTs defining one
single path through the road (or rail) network. A
ROUTE may pass through the same MAPPING POINT
more than once.
STOP AREA
A group of STOP POINTs close to each other.
STOP POINT
A POINT where passengers can board or alight from
vehicles.
TIMETABLE VERSION
A set of timetable data (VEHICLE JOURNEYs and
BLOCKs) to which the same temporal validity has been
assigned. The temporal validity of a TIMETABLE
VERSION is defined by one or more PERIODs
whicHMinay have gaps between them, but must not
overlap.
TRANSPORT MODE
A part of the network characterised by means of
transport: bus, tram, metro, train, ferry, ship.
TRIP
The complete movement of a passenger (or another
person, e.g. driver) from one PLACE of any sort to
another. A TRIP may consist of one PT TRIP and the
corresponding movements (usually walks) to cover the
necessary ACCESS LINKs and CONNECTION
LINKs, or of one walk only.
VEHICLE JOURNEY
A particular journey of a vehicle on a particular DAY
TYPE.
VEHICLE TYPE
A classification of public transport vehicles according
to the vehicle scheduling requirements (e.g. standard
bus, double-deck, ...).
November 2002
D3.5 & D3.7/4 – page 97/97
Version 2.0
D3.6 & D3.7
Final specifications for the EDI & Object Oriented approach
D3.6 & D3.7/Annex B – Location Referencing Solutions
TRIDENT
D3.7/Annex B – Location Referencing
(v2.4)
Version 2.0
7 November 2002
Produced by:
TRIDENT Consortium
November 2002
D3.7/Annex B – page 1/33
Version 2.0
D3.6 & D3.7
Activity name:
TRIDENT
Work area:
WP3 / WG2
Document title:
Location referencing solutions
Document number:
D3.6 & D3.7 / Annex B
Brahms/groupes/reda/_service/_projets/
TRIDENT/dossiers techniques/WP3/WG2/
Location referencing annex to D3 (V1.3).doc
Michèle Blachere (CETE Mediterranée)
Version history:
Version
Date
Main author
Summary of changes
1.0
28/06/00
---
1.1
07/08/00
Michèle Blachere (CETE
Mediterranée)
Inputs from the consortium (Aix
and Roma meetings)
1.2
22/09/00
1.3
02/03/2001
1.4
15/04/2001
1.5
15/05/2001
1.6
23/07/2001
2.0
10/08/2001
Inputs from consortium (Verona
12-13 December - Aix 5-6
February)
Inputs from consortium (London
meting 02-03 April)
Remarks from consortium +
TPEG inputs
Inputs from Aix meeting
J.Booth, M. Liger, M.Blachère
Inputs from Verona meeting
2.1
02/10/01
Inputs from Roma meeting
2.2
02/2002
Inputs from Brussels meeting
2.3
04/2002
Inputs from Aix meeting
2.4
09/2002
∗
§2
Modification ILOC PT stop /
data model
Modifications from page 17 to
the end of the document
Modifications page 14 to 29
Modifications from §2.2 to the
end of the document
end of the document
end of the document
end of the document
This is either: Restricted (to the programme, to the activity partners) or for Public usage.
November 2002
Version 2.0
D3.6 & D3.7
Table of Contents
Table of Contents........................................................................................................................................................ 3
1 Test sites point of view....................................................................................................................................... 4
1.1
UK tests sites .............................................................................................................................................. 4
1.2
MVG - Flanders tests site........................................................................................................................... 4
1.2.1
Existing systems................................................................................................................................. 4
1.2.2
Possible Systems ................................................................................................................................ 5
1.2.3
Preferred solution ............................................................................................................................... 6
1.3
RATP test site............................................................................................................................................. 7
1.3.1
Existing system: RATP centralised system ....................................................................................... 7
1.3.1.1 Geographical location method ....................................................................................................... 7
1.3.1.2 Network location method............................................................................................................... 8
1.3.1.3 Exchange method between internal and external partners............................................................ 8
1.3.2
Location methods. Advantages/disadvantages .................................................................................. 8
1.4
Rome......................................................................................................................................................... 10
1.4.1
Existing systems............................................................................................................................... 10
1.4.1.1 STA – Road URBAN DATEX Node .......................................................................................... 10
1.4.1.2 FS – PTIC Public Transport Information Centre ........................................................................ 10
1.4.1.3 Other issues .................................................................................................................................. 10
1.4.2
Possible Systems .............................................................................................................................. 10
1.4.2.1 Alert C .......................................................................................................................................... 10
1.4.2.2 ALERT PLUS .............................................................................................................................. 11
1.4.2.3 ILOC............................................................................................................................................. 11
1.5
Bern........................................................................................................................................................... 11
1.6
Synthesis of tests sites point of view ....................................................................................................... 13
2 Solutions proposed for TRIDENT ................................................................................................................... 14
2.1
Context...................................................................................................................................................... 14
2.2
The short term solution (DATEX Plus)................................................................................................... 16
2.2.1
Main principles................................................................................................................................. 16
2.2.2
ILOC+ for Point location ................................................................................................................. 17
2.2.2.1 ILOC principles............................................................................................................................ 17
2.2.2.2 ILOC+ Location for stop points .................................................................................................. 18
2.2.2.3 Examples of location coding for Stop Point................................................................................ 22
2.2.2.4 ILOC+ Location for PT access point........................................................................................... 23
2.2.2.5 ILOC+ Location for address ........................................................................................................ 23
2.2.2.6 ILOC+ Location for “road point” ................................................................................................ 24
2.2.3
ILOC+ for link Location .................................................................................................................. 24
2.2.4
Rules for descriptor coding on the client side ................................................................................. 25
2.2.5
Integration of ILOC+ location in the EDI format ........................................................................... 26
2.3
The TRIDENTOO solution...................................................................................................................... 26
2.3.1
Main principles................................................................................................................................. 26
2.3.2
New location types for ILOC+ ........................................................................................................ 29
2.3.2.1 ILOC+ for Area............................................................................................................................ 31
2.3.2.2 ILOC+ for Stop Area ................................................................................................................... 32
2.3.2.3 ILOC+ for Point Of Interest (POI) .............................................................................................. 32
2.4
Other Issues .............................................................................................................................................. 32
2.4.1
Network Topology ........................................................................................................................... 32
2.4.2
ILOC+ Improvement........................................................................................................................ 33
2.4.2.1 Accuracy....................................................................................................................................... 33
2.4.2.2 Location-type ............................................................................................................................... 33
November 2002
Version 2.0
D3.6 & D3.7
1 Test sites point of view
1.1 UK tests sites
From a location-referencing viewpoint the issue is what location referencing systems are
needed to achieve ‘sufficient’ coverage of different modes of public and private transport.
To that end the following location referencing methods and their inter-mapping have to be
supported as a minimum.
RDS-TMC location referencing;
Proprietary PT location codes (station codes, bus stop numbers);
Latitude/Longitude (ILOC);
Text names/Gazetteers.
In the UK might be (outside TRIDENT) added O.S. Grid References, but in actuality this is a
conversion from Lat/Long (complex but possible), and also detailed O.S. digital maps of the
road network, such as OSCAR. It is also possible that GDF might be considered; indeed O.S
Grid references and OSCAR would not be internationally interoperable.
For the inter-mapping it would seem logical to use ILOC, but there are lot of questions
concerning the conversion of other systems/maps to ILOC and issues such as the accuracy of
mapping required. For instance, does a gazetteer locality, such as Woking, get mapped to
10m?
With regard to the new PT messages (for example revised TRAINS), all of the above methods
would be supported except ILOC, which was not invented then, but it is designed for the mass
transfer of timetables and not:
Dynamic updating of timetables;
Delivery of a subset of a timetable (for example for route planning);
Delivery of dynamic PT information (events, cancellations and status).
1.2 MVG - Flanders tests site
1.2.1 Existing systems
The main location referencing system used is the Reference Point (Kilometre point system).
Since the MVG is the administrator for numbered roads, this is to be expected. The system is
used in contacts with: traffic police, other road administrations within the region
(municipalities and provinces). The system is well understood by our partners within the
Flemish region.
November 2002
Version 2.0
D3.6 & D3.7
In due course (2000 Q4), ALERT-C will be used by the DATEX-node for the Flemish TIC
for international and interregional data exchange of traffic information with respect of the
TERN roads.
Within the Flemish Ministry and the other public Flemish organisations (incl. the public
transportation operator De Lijn, which is also a TRIDENT partner), a standard mid-scale
reference GIS-database of roads and streets is in use. This GIS-database is the StreetNet
product of the company TeleAtlas. Sometimes information is exchanged among users of this
product by referencing directly the identifiers of the features within the database. However,
this works only where versions are identical, this is a serious practical drawback to this
approach.
1.2.2 Possible Systems
The various referencing systems proposed for TRIDENT are evaluated as follows:
Alert-C/Alert+: sufficient for interregional/international TIC-to-TIC or RDS/TMC
messaging. Insufficient for urban traffic management. We feel it is not worthwhile to try to
extend the system to other modes than car travel. Considering public transportation: the
amount of extra location codes that would need to be generated is very large, and the location
tables would become non-maintainable due to the high frequency of changes on public
transportation networks.
KM-point: This solution works only for some modes (in Flanders: car and train travel). It is
however only useful for data exchange within a region since typically databases do not
contain the kilometre referencing systems used by the road administrations. These referencing
systems are only well known within one region.
Proprietary PT operator codes: these codes are ill suited for data exchange for two reasons:
i)
It typically doesn't contain the motorways, which is the most important part of the
road network for purposes of traffic management;
ii)
The operator codes are usually known and maintained only by the PT operator. It is in
practice impossible for organisations (other than the operator) to interpret these codes
correctly since this would imply maintaining parallel databases of all the relevant PT
operators that they wish to exchange data with.
X/Y + descriptors: This referencing system is the most appropriate for the MVG-Flanders
needs. It is simple to implement, it is flexible and it is the least demanding to the systems
between which data are exchanged.
But, it must be stressed that the location referencing of points is insufficient and therefore the
exchange of point information will be insufficient too.
November 2002
Version 2.0
D3.6 & D3.7
In the next section a view on how this exchange method could be implemented is briefly
presented.
1.2.3 Preferred solution
Exchanges with other partners concern data on (point and line)-events, but also, eventually,
descriptions of itineraries. This means that, not only points, but also any kind of linear
geographic feature should be exchanged.
There is also a need to exchange information using location about which there is no
geographic information available at the client side. The location referencing system should
therefore contain sufficient co-ordinate information such that the geographic feature could be
completely reconstructed (and nor only identified) on the basis of that co-ordinate
information.
At present the location referencing systems that are considered in the sub-workgroup, allow
only the unambiguous identification of a location. It is assumed that the receiver of the
information has the necessary spatial information about that location. When we consider
interregional data exchange that assumption will usually not be hold. When Flanders receives
location reference information coming from the RATP it will presumably refer to locations in
e.g. Paris (streets, bus stops...). We do not have any geographic information about Paris (no
digital street-database) and we do not intend to build and maintain such large databases.
This is important when we consider what PT-information is going to be exchanged between
regions. The Flemish administration hopes that a result of TRIDENT would be
procedures/standards or protocols that enable travel information services that are multi-modal
and interregional. In our view such travel information services need to be cooperative: the
Flemish site could e.g. provide the part of the itinerary from any point in Flanders to ParisNord train station) a French site (RATP, e.g.) could then provide the part from Paris-Nord to
La Défense (or any other location in Paris). In this perspective we would like to have
exchange mechanisms for itineraries. The itinerary could be described as a sequence of points,
each of which represents a bus stop, plus additional information (which PT line, travel times,
arrival/departure times, ticket cost...). The sequence of points represents the itinerary. If the
points have geographical coordinates a map display is possible.
Flanders definitely favours a solution in which X/Y + descriptors are used as the primary and
basic method for location referencing. However, we think that a large number of feature types
could easily be defined on the basis of this method. Linear features, e.g., could be represented
as lists of X/Y + descriptors. With new technology such as XML this approach could be
straightforwardly implemented.
November 2002
Version 2.0
D3.6 & D3.7
1.3 RATP test site
1.3.1 Existing system: RATP centralised system
1.3.1.1 Geographical location method
The system is equipped with « Géoroute » roads linear network, which is made of road
sections and locations, identified with « Lambert 2 » extended co-ordinates. The accuracy is
of +/- 5 m in urban area and of 20 m outside urban area. Data are available only for 10 000
inhabitants municipalities. Some pieces of information are associated to these vector type data
(e.g. street type, toponym, etc…). Streets numbers are provided only for start and end of each
road section. These data are mostly used for researching addresses. IGN tolerates about 10 %
as an error percentage (concerning geometry, toponyms, streets numbers, etc.) this implies
numerous extensions and corrections.
Bus routes and stop points are hand captured on a raster map, which was produced on the
basis of data provided by « Géoroute ». It is imperative that accuracy of co-ordinates should
be of +/- 50m, in order to facilitate legibility and superposition of layouts.
Accesses to railways (stairs) are captured with the same accuracy.
Sites of interest (21 different types) are also captured with the same accuracy.
Changes in the system will be:
Input of bus routes will be based on streets section selections; this will raise accuracy
up to « Géoroute » level for bus routes (another system is implementing this
technology for bus location). Stop points are geographically located with the help of
data collected on site for buses equipped with GPS (average number of stop points).
We have to distinguish:
Stop point represented on central section,
Position of the “potelet” (bus stop sign) itself,
Position of the bus at bus stop,
Bus location uses GPS co-ordinates, course and identification of the vehicle to obtain a
detailed position that will be linked to the network.
The cartographic system of map generating will use this drawing as a reference. It will
be able to keep the geometry of drawings presented on maps to travellers who
correspond to other criteria than geographical precision.
Some locations are directly found in « Géoroute ». Others are geographically located
by means of their postal address, automatically on « Géoroute » reference.
All sites and access, as well as bus (potelet) are located by a postal address which
mention the « I.N.S.E.E.1 » number of each municipality. As for “potelets”, only an
address related to a localisable point is provided (crossings, squares, sites.).
1
National Institute of Statistics and Economics
November 2002
Version 2.0
D3.6 & D3.7
1.3.1.2 Network location method
Bus routes are identified by a code provided by STP (« RER2 » route A, bus service 101),
sometimes they have a commercial name and a tag, which are specific of the system. Routes
and “antennes” needs new element to be add to the code.
Stop points own a commercial name, a direction. They are identified by a code system.
However, no entity is able to deliver a permanent code to be used by all kind of systems.
Several types of numbering exist, which follow the applied logic (maintenance, regulation,
traveller information). This work is being realised.
1.3.1.3 Exchange method between internal and external partners
Data exchanged with SNCF3 are textual (series of numbers and code for train station with
timetable); we must put a new geographical code on train stations and we must capture
railways in a geographical way.
Exchanges with SIER Points are brought nearer in order of geographical conformity,
following an X-ray circle.
1.3.2 Location methods. Advantages/disadvantages
Alert C:
Transport networks are also describable as following:
Area ! transfer area
Linear ! a section between two stop points
Point ! stop point
This kind of fixed codification is to be considered for railway (about 400 train stations, 500
sections and 100 single mode transfer areas). It is unforeseen for buses, because of bus routes
changes.
That amounts to transmitting network data in a schematic way. Only transmitted codes and
attributes remain to be defined.
ILOC:
ILOC system uses WGS84 co-ordinates and descriptors (part of directing words and
toponyms) « on the fly ». This system needs road reference here and there. It locates only
crossings. Is the validity of received information automatically checked or does an operator
check it?
2
Réseau Express Regional : local area fast train network
3
Société Nationale des Chemins de Fer Français : French Railways Society
November 2002
Version 2.0
D3.6 & D3.7
The system, extended to road, might be appropriate for localisation of surface networks
elements as for bus network, provided the direction is added; this would allow to distinguish
opposite course bus stops on a same way. However a reference is missing on bus route that
would allow people to distinguish stop points of several bus routes located in the same place.
The bus route is a network attribute that is not naturally shared by the local operators,
however STP defines it.
This method is less appropriate for railways. Location of trains is not a geographical one: the
direction should be took over by means of a railways rough drawing (often topological)
(measuring of direction while the train is stopped would suffer from numerous magnetic
jams) and the transport access addresses - which refer to road network – are too numerous and
too ambiguous to be eventually employed as a route reference.
Sharing road data is necessary for road location; at a same level, sharing network data is
necessary for the location of points, link and transport network zones.
In my opinion, ILOC coding technology is too constraining with regard to descriptors size. To
obtain the maximum level of meaning we should use the directing word (La Fontaine Square,
Commander Mouchotte Lane), which is generally the last word of a French address
(technique used by the French postal services).
We could only keep Fontaine, Mouchotte consonants => fntn, mchtt, as a coding technique
(only a suggestion).
As a summary, we may use a simple code of Alert C type but without kilometric reference for
“heavy “ (railways and metro) networks and ILOC would suit for buses and extensions.
Necessary attributes
These elements were chosen among the possible attributes for exchanges between partners
Attribute
Definition and values
Needs the same references for
both sides or are independent
X, Y
X, Y WGS4 co-ordinates
Independent
Toponym
Street name
Reference
Types Reference to be defined.
MODE
Type of transport mode or location (BUS,
METRO, RER, TRAM, PARKING,
LIEUX, ACCES) all kind of geographical
layers for specific type of site of interest or
transport mode.
ORIENTATION
Direction measured in degree or orientation Independent
in the same way as a compass card (North,
West-North)
ORIENTATION
With the help of both terminus of a bus
Necessary terminus points
route.
reference
Number or Route
Single number given by STP or commercial Necessary reference. But the
Name
name.
number is multi-conveyor by
adding the conveyor code. It is
released by a centralised local
organisation.
November 2002
Version 2.0
D3.6 & D3.7
1.4 Rome
1.4.1 Existing systems
1.4.1.1 STA – Road URBAN DATEX Node
The STA system has been designed, from the beginning, keeping the same logic and the same
standards used for inter-urban data-exchange. In particular the Location method used to code
the urban area has been derived from the ALERT C standard. Every urban road has been
structured with one LCD code and every intersection has been linked with each road is part
of. The Location table is also filled with WGS84 co-ordinates to locate points on a map.
Furthermore some itineraries (similar to ALERT + coding method) has been defined to
display information in “aggregate” format but not used to exchange information with other
centres.
One of the main results of the internal field trials, already conducted, brought to the
conclusion that the Rome’s Location Table used (6000 points, 1900 segments, 4000
segments) is good enough for TIC-to-TIC data exchange for road traffic information systems
and to exchange also main information about public transport.
1.4.1.2 FS – PTIC Public Transport Information Centre
The FS system used in the past to exchange public transport information within the TIC of
Motorway Company will be adopted and modified ad hoc in accordance to the TRIDENT
solutions. Actually the FS system is based on internal location coding format (textual based)
and no one geographical information is used (alphanumeric codes for Railway stations, and
trains).
One of the main choices adopted was to exchange, between TICs, the result of queries always
(one message called TRAVIP has been designed to this purpose) and never to exchange the
global timetables.
1.4.1.3 Other issues
Within the issue of the Turin 2000 ITS congress the Turin location table of urban area based
on ILOC method has been delivered. Some investigations to adopt it for the Public Transport
information systems are carrying out.
1.4.2 Possible Systems
1.4.2.1 Alert C
•
Available and useful for road information systems even in urban area
November 2002
Version 2.0
D3.6 & D3.7
•
Not available and not considered for public transport
1.4.2.2 ALERT PLUS
•
The concept of collection of points to exchange travel time or moreover network status
information, is already present and might be modified for TRIDENT purpose
1.4.2.3 ILOC
•
Some investigations has been conducted and it can be considered the preferred
solution on condition that some new TRIDENT features (bus stop, railway stations…)
makes it suitable for public transport
1.5 Bern
November 2002
Version 2.0
D3.6 & D3.7
1.6 Synthesis of tests sites point of view
Site
UK
General view
FLANDERS
All the following
methods must be
supported with their
inter-mapping
RATP
ROME
BERN
ALERT C for Road
ILOC preferred solution ALERT C extension for “heavy
PT network” (train metro) /
ILOC “Plus” for others
ILOC for others
ALERT C only for
ALERT C can be extended to
private traffic info not
the railways network (train,
suitable for PT
metro) not thinkable for Buses
(too much line, too much
modifications, need to know the
link to the road network)
ALERT C
ALERT C
ALERT C only for cars
in the interurban
environment: extensions
to PT not suitable
KM point
-
KM point (car train)
regional
-
-
OK
PT :only known by the
proprietary operator
(1)
-
OK(but not for
timetables)
OK
ILOC adapted to the road
network, applicable to the bus
network provided that specific
descriptors are defined
(orientation) and rules for
descriptors refined
OK
OK
-
-
-
Proprietary PT
locations
ILOC
Text names /
Gazetteers
(1) Unique reference is allowed to PT line in the region (line number linked to the PT operator identifier). This unique reference could be used as
descriptor in the ILOC method.
November 2002
Version 2.0
D3.6 & D3.7
2 Solutions proposed for TRIDENT
2.1 Context
The TRIDENT project aims to support multimodal travel ITS by developing mechanism for sharing
and exchanging data between transport operators of different modes while considering new
solutions for data exchanges based on the use of new technologies.
Nevertheless, during the 4FP, systems for data exchange, based on the DATEX specification, have
been implemented. These solutions, commonly qualified of “messaging approach”, is to day
operational, especially in TRIDENT tests sites.
One of the commitments of the project is to extend this messaging approach (especially the
possibility to exchange delays and cancellation in PT, travel time, etc) while ensuring backward
compatibility with previous DATEX version.
It must be remind that, in the location-referencing domain, DATEX is based on ALERT C.
However, due to the big amount of work necessary to create and maintain such tables and to the
poorness of the PT location possibilities, this solution is not considered to be completely adapted for
extension to multimodal application, even considering ALERT Plus.
But moving towards more promising solutions based on ILOC raises two problems:
-
ILOC is defined for the road network: extensions to include new locations types are necessary;
-
The introduction of new location referencing solutions in DATEX will cause problems of
backward compatibility and therefore they must be as much as possible minimised.
In so far TRIDENT has planned two steps in the project: firstly the extension of the messaging
approach to PT and then the use of new technologies. It is proposed that location-referencing
recommendation will be also two folded:
-
One for the short term that will be implemented in the messaging approach “DATEX Plus
solution”;
-
One for the so-called TRIDENTOO solution.
Clearly the choice of the location referencing solution should not depend on the technological
solution for data sharing and exchange (EDI or object oriented). The somewhat simpler proposal for
the EDI approach is mainly due to the backward compatibility required by the project.
November 2002
Version 2.0
D3.6 & D3.7
The figure 1 below shows the data type that are envisaged to be specified and implemented in the
TRIDENT data sharing/exchange mechanism:
DATEX Plus
DATEX OO
Tests sites
implementation
PT delays
"
"
PT Cancellation
"
"
Travel time (road and PT)
"
"
PT timetable
"
PT status
"
Only specifications
PT enquiries and booking
"
Fares (PT road tolls)
"
"
Network description
Road traffic events
"
"
Road traffic status
"
Journey planners
"
Point of interest
"
Tourist information
"
"
Special facilities
"
Weather
Figure 1
November 2002
Version 2.0
D3.6 & D3.7
The figure 2 below shows what are the possible location referencing solutions for each data type
(grey cells are still to be defined)
ILOC
(extensions)
ALERT C ALERT +
KM
Prop PT
Gazetteer
s
PT delays
(")
(")
"
"
PT Cancellation
(")
(")
"
"
Travel time (road and PT)
(")
"
"
"
"
"
PT timetable
PT status
"
(")
PT enquiries and booking
Fares (PT road tolls)
Network description
Road traffic events
(")
Road traffic status
(")
"
"
"
Journey planners
Point of interest
(")
Tourist information
Special facilities
Weather
Figure 2
2.2 The short term solution (DATEX Plus)
2.2.1 Main principles
As explained before, in the DATEX Plus solution, the extension of the location referencing solution
will be « minimized » to favour backward compatibility with existing systems.
The proposal is to:
•
Continue to use ALERT C for existing messages and,
•
Add the location referencing methods necessary to include new messages related to:
- PT Delays
- PT Cancellations
- Travel Times (Road and PT).
In order to keep a simple solution, there will be no knowledge of the underlying network (lines
routes, links etc…). In this solution, intermodal process (route finder, itinerary...) cannot be done
November 2002
Version 2.0
D3.6 & D3.7
without other data exchanges and inter-mapping process outside DATEX (especially PT network
layer on digital maps, look-up tables...).
Information will be provided:
- At Stop Points.
- On links, that means between two points location:
An ILOC like solution, called ILOC+ will be used to describe these new locations:
-
Point location for stop point, address and “road point”
-
Link location (starting point location – ending point location)
2.2.2 ILOC+ for Point location
2.2.2.1 ILOC principles
The following proposal for ILOC+ Point location is based on the extension of the ILOC location
referencing principles as described by the EVIDENCE project: deliverable D2.2 30 April 1999 in
which the content and format of an Intersection location is:
Field name
Type
Sign longitude
1 character
Longitude
8 digits
Sign latitude
1 character
Latitude
7 digits
Road descriptor 1
5 characters
Road descriptor 2
5 characters
Road descriptor 3
5 characters
Location-Type
3 digits:
Values
001 Intersection
It is proposed that:
-
Descriptors will not be coded on the supplier side in order that the location received could
be understandable and used directly without using digital map databases;
-
Descriptors can be coded by the client of messages to help them, if needed, to find the
corresponding locations in their digital map database. Rules for the coding of descriptors
must be improved especially to take into account language characteristics.
-
Four descriptors might be used for point location.
-
Location-type: (4 characters) the first character to indicate the transport network, the
three others to indicate the location-type according to ALERT C: existing location-type
will be used or added when necessary. (Without the category letter (P, L, and A) and
without the point (example for “airport stop point”: P3.27 will become 327). In the data
dictionary this attribute is called: Alert C Extended Location Type Code
November 2002
Version 2.0
D3.6 & D3.7
2.2.2.2 ILOC+ Location for stop points
An ILOC+ location for stop points is composed of:
# (X, Y) pair, in WGS84 co-ordinates: signed longitude and latitude
# Characteristics of the language *:
-
a language code (country_code: 2 characters )
-
a word order :1 (coding from the last to the first word), 2 (coding from the first to the last
word).
# Descriptor part
Descriptors (stop point id, stop point name, destination name etc..) are proprietary identifiers or
attributes used by the system provider. Obviously this proposal is not incompatible with the setting
up of common and unique references at local, regional or national level.
# Location type that identifies the kind of location. It is composed of four characters. The
proposal is to use :
-
the first character to indicate the Transport Mode concerned (see the data dictionary
TransportMode)
-
the three others for the Alert C Extended Location Type Code
-
348 for Bus Stop Point
-
327 for Airport Stop Point
-
350 for Railway Stop Point
-
351 for Metro Stop Point
-
352 for Tram Stop Point
The general content and format of an ILOC+ Stop Point is:
Field name
Type
Sign Longitude
1 character
Longitude
8 digits
Sign Latitude
1 character
Latitude
7 digits
Language
2 characters
Word Order
1 character
Descriptor 1
75 characters
Descriptor 2
75 characters
Descriptor 3:
75 characters
Descriptor 4
75 characters
Alert C Extended Location Type Code
4 characters
November 2002
Version 2.0
D3.6 & D3.7
Descriptors will be different depending on the Transport Mode (see location-type below).
Bus Stop Point
Field name
Type
Sign Longitude
1 character
Longitude
8 digits
Sign Latitude
1 character
Latitude
7 digits
Language
2 characters
Word Order
1 character
Descriptor 1: Stop Point Name
75 characters
Descriptor 2 : Street Name And Number 75 characters
Descriptor 3: PT Direction *
75 characters
Descriptor 4 : Platform Identifier
75 characters
4 characters
* (N,S,E, NE,SE ..or CW, CWW clockwise and counterclockwise
Airport Stop Point
Field name
Type
Sign Longitude
1 character
Longitude
8 digits
Sign Latitude
1 character
Latitude
7 digits
Language
2 character
Word Order
1 character
Descriptor 1: Airport Name
75 characters
Descriptor 2 : Terminal Identifier
75 characters
Descriptor 3: Gate identifier
75 characters
4 characters
November 2002
Version 2.0
D3.6 & D3.7
Railway Stop Point
Field name
Type
Sign Longitude
1 character
Longitude
8 digits
Sign Latitude
1 character
Latitude
7 digits
Language
2 characters
Word Order
1 character
Descriptor 1: Railway Station Name
75 characters
Descriptor 2 : Station Internal Division
75 characters
Descriptor 3: Platform Identifier
75 characters
4 characters
Field name
Type
Sign Longitude
1 character
Longitude
8 digits
Sign Latitude
1 character
Latitude
7 digits
Language
2 characters
Word Order
1 character
Descriptor 1: Metro Station Name
75 characters
Descriptor 2 : Line Name/Number
75 characters
75 characters
75 characters
4 characters
Metro Stop Point
* (N,S,E, NE,SE ..or CW, CWW clockwise and counterclockwise) and/or destination_name
Tram Stop Point
Field name
Type
Sign Longitude
1 character
Longitude
8 digits
Sign Latitude
1 character
Latitude
7 digits
November 2002
Version 2.0
D3.6 & D3.7
Language
2 characters
Word Order
1 character
75 characters
Descriptor 2 : Street Name And Number 75 characters
75 characters
75 characters
4 characters
* (N,S,E, NE,SE ..or CW, CWW clockwise and counterclockwise) and/or destination_name
* Language code and Word order can be used to code the descriptors, see paragraph below. The
need for both attributes or only one of them must be tested by the TRIDENT tests sites.
November 2002
Version 2.0
D3.6 & D3.7
2.2.2.3 Examples of location coding for Stop Point
Example of Bus Stop point coding:
Rue du cherche midi
Boulevard Montparnasse
Montparnasse
Rue de Vaugirard
The stop point is located at:
Longitude
+01234567
Latitude
+6543210
The names are expressed in French, then the
Word Order is
1
We know that the stop point is named "Montparnasse" and is located in "rue du cherche midi"
The direction is "NE"
The ILOC+ Bus Stop Point is:
Field name
Type
Sign Longitude
+
Longitude
01234567
Sign Latitude
+
Latitude
6543210
Language
FR
Word Order
1
Montparnasse
Descriptor 2: Street Name And Number
rue du cherche midi
Descriptor 3: PT Direction
NE
November 2002
P348
Version 2.0
D3.6 & D3.7
Applying the rules for coding the descriptors defined gives:
53165 for "Montparnasse"
53262 for "rue du cherche midi"
5 for the direction (rules must be improved to distinguish NE and NW)
2.2.2.4 ILOC+ Location for PT access point
An Access point is an access to a Stop point or to a Stop area ( One access point may give
access to several stop points in a stop area).
The ILOC+ PT Access point location is composed of :
# (X, Y) pair, in WGS84 co-ordinates (signed longitude and latitude) of the PT Access
point
#
Characteristics of the language *:
-
-
a word order :1 (coding from the last to the first word), 2 (coding from the first to
the last word).
# Descriptors
descriptor 1 : PT Access Point Name
descriptor2 : Name Of Related Stop Point or Stop Area
descriptor3 : Street Name And Number
-
the first character to indicate the transport Mode (I: Irrelevant)
the three others
Point)
for the Alert C Extended Location Type Code (354 for PT Access
2.2.2.5 ILOC+ Location for address
This location-type may be used to indicate the origin / destination of a trip.
The ILOC+ address location is composed of :
# (X, Y) pair, in WGS84 co-ordinates (signed longitude and latitude) of address
#
Characteristics of the language :
-
-
the last word).
# Descriptors
descriptor 1 : Building Identifier
descriptor 2 : Street Name And Number
November 2002
Version 2.0
D3.6 & D3.7
descriptor 3 : City name
descriptor 4 : Post Code + Country Code
-
the first character to indicate the Transport Mode (I : Irrelevant)
-
the three others for the Alert C Extended Location Type Code (352 for Address)
2.2.2.6 ILOC+ Location for “road point”
This location-type is used to describe a point on a road.
The ILOC+ road point location is composed of :
# (X, Y) pair, in WGS84 co-ordinates (signed longitude and latitude) of the point
#
-
-
the last word).
# Descriptors
descriptor 1 : Road Number
descriptor 2 : Road Name
descriptor 3 : tbd
-
the first character to indicate the Transport Mode (R : Road)
the three others
road point)
for the Alert C Extended Location Type Code(200 for intermediate
N.B: ILOC defined for intersection (AGORA project) is a specific "road point" located at an
intersection.
2.2.3 ILOC+ for link Location
Up to now link location have been poorly designed in the ILOC approach (proposals concerns only
link between two intersection on a same road). The following proposal is a starting point that must
be improved and validated by the tests sites.
This location-type is used to describe a link between two points location using a single mode of
transport on an unambiguous path of the network.
The ILOC+ link location is composed of :
# (X, Y) pair, in WGS84 co-ordinates (signed longitude and latitude) of the starting point
# (X, Y) pair, in WGS84 co-ordinates (signed longitude and latitude) of the ending point
November 2002
Version 2.0
D3.6 & D3.7
#
-
-
the last word).
# Descriptors
descriptor 1 : location-type of the starting point
descriptor 2 : characteristic of the starting point
descriptor 3 : location-type of the ending point
descriptor 4 : characteristic of the ending point
descriptor 5 : common descriptor if it exists
The rules to fulfil the descriptors depend on the location-type of the two points defining the
link.
-
Road link : link between two road points that must be situated on the same road
(descriptor 5 : road number and/or name).
-
PTLink :
-
PTAccessLink : the path from a PT Access Point to a Stop Ppoint
-
Ride : link between two bus stop point . They must be situated on the same line
(descriptor 5 : line number and/or name).
-
Connection Link :
-
NonPTAccessLink : the path from an origin place to a PT Access Point, covered by any
non-PT means (walk, cycling, private ..)
-
the first character to indicate the Transport Mode (ex R : Road)
the three others for the Alert C Extended Location Type Code that defines the type of
link :
-
Road link (700)
-
PTLink (800)
-
PTAccessLink (801)
-
Ride (802).
-
Connexion Link (803)
-
NonPTAccessLink (900)
2.2.4 Rules for descriptor coding on the client side
In the ILOC solution, descriptors are the firsts five characters of the names. In the ILOC + solution,
it is proposed to improve this rule applying a phonetic algorithm
November 2002
Version 2.0
D3.6 & D3.7
Depending on the language used, this algorithm will be applied from the last to the first word
(example in French : Square La Fontaine), value:1, from the first to the last word (example in
English : La Fontaine square) value:2 For each descriptor an alphanumeric code will be supplied
(proposal based on the "Soundex" ORACLE function. :
-
if numeric character keep it
-
retain the first letter of the string and remove A, E, H,I, O, W,Y
-
upper case letter = lower case letter
-
double letter = simple letter
-
assign the number to the following letter:
0 = A,E,H,I,O,W,Y
1 = B,F,P V
2 = C,G,J, K, Q, S,X, Z
3 = D,T
4=L
5 = M,N
6= R
-
if two or more numbers are in sequences, remove all but the first
2.2.5 Integration of ILOC+ location in the EDI format
This mapping is provided in the EDIFACT specifications.
2.3 The TRIDENT OO solution
2.3.1 Main principles
The analysis of possible solutions for multimodal systems shows that the ILOC method is the most
promising approach to exchange information between transport operator centers, provided they use
a digital map database.
In the context of TRIDENT in which test sites are mostly in urban area, it is the case.
In order to take into account the variety of situations (cf 1.6 synthesis of tests sites point of view)
the following methods will be supported :
-
Alert C
-
ILOC+ (location-type already defined in the datex solution + some extensions)
-
Proprietary identifiers
November 2002
Version 2.0
D3.6 & D3.7
However the use of X,Y co-ordinates will be mandatory and will be used as a “pivot” for the intermapping between different methods.
November 2002
Version 2.0
Location: for the EDI & Object Oriented approach
Final specifications
D3.6 & D3.7
-
Location:: General Link
AlertCExtendedLocationTypeCode : LocationType
LocationReferencingMethod: Enum
start
Location:: Point
-Longitude : Decimal
-Latitude : Decimal
end
AlertCLocationPoint
Location:: Area
-AreaName
ILOCPlusPoint
ProprietaryPoint
-Language: enum
-WordOrder : enum
-PointName : String
ILOCPlusOtherPoint
ILOCPlusStopPoint
ILOCPlusBusStoppoint
PTAccessPoint
StopPointName : String
StreetNameAndNumber :String
PTDirection : String
PlatformIdentifier : String
PTAccessPointName : String
NameOfRelatedStopPointOrArea: string
StreetNameAndNumer : String
ILOCPlusRailwayStoppoint
PointOfInterest
PointOfInterest Name
RailwayStationName : String
StationInternalDivision : String
Address
ILOCPlusAirportStopPoint
BuildingIdentifier : String
StreetNameAndNumber :
String
CityName : String
PostCode: String
CountryCode : String
AirportName
TerminalIdentifier
GateIdentifier
RoadPoint
RoadNumber : String
RoadName : String
ILOCPlusTramStopPoint
ILOCPlusMetroStopPoint
StopPointName : String
StreetNameAndNumber :String
MetroStationName : string
LineName/Number : String
November 2002
Version 2.0
D3.6 & D3.7
The results of the use of this solution by the tests sites will be analysed to consolidate the original
proposal.
The rules (and components) to translate location references from each method to ILOC and vice
versa are still to be specified. Two aspects have to be take into account for the location referencing:
-
extension of location-types for new data sharing/exchanges : a first extension of the ILOC
method has already been defined (EDI) for stop point, new extensions are proposed below
-
definition of the exchange of the network topology to which the traffic/travel information
exchanged are related.
2.3.2 New location types for ILOC+
The new data sharing/exchange envisaged in TRIDENT and the corresponding location type are :
Nature of transferred information Information supplied and related locations
Point timetable definition
Location type used
Passing time (arrival, departure, waiting time) - Stop Point
at a stop point for each line stopping at this
stop. The lines are described by two or more
stop points (origin destination and if necessary
intermediate points )
Line/journey timetable definition Between an origin and a destination : passing
time (arrival, departure, waiting time) at the
stop points of a specific path (line or journey)
- Stop Point
- Area
Status/delays - individual vehicle Status and delays at each stop point of the - Stop Point
journey definition
vehicle journeys of a line
Trip time definition
Trip time is composed of a sequence of
elementary link or trip segment : walk time,
access time, waiting time, Pt time which in
turn is composed of ride time access time
waiting time). See figure 2.4.2.1 for
definitions.
Request for information
-
Stop Point
-
PT Access Point
-
Address
-
Stop Area
-
Point Of Interest
All locations type
defined above
The needed location-types :
Stop Point
PT Access Point
Address
Stop Area
Area
Point Of Interest
November 2002
Version 2.0
D3.6 & D3.7
are represented in the figures below:
Pt line 2
Pt line
Stop Area
Pt line 1
I
Stop Point
PT Access Point
PT Access Link
Non PT Access
Figure 2.4.2.1- Stop Area – Stop Point – PT Access Point – Access Link – PT Access Link
Trip
PT Trip
Pt Access
Non PT
Access Link Link
Ride
Connection
Link
Ride
Non PT
Access Link
Figure 2.4.2.2- Trip description
Part of these location-types have already been defined for the EDI approach
◊
Stop Point
Already defined in §2.2.2.2
November 2002
Version 2.0
D3.6 & D3.7
◊
PT Access Point
-
◊
Already defined in 2.2.2.4
Address
-
Already defined in 2.2.2.5
2.3.2.1 ILOC+ for Area
An area is used to locate the origin and the destination of a trip. It can be:
-
a Site (TM definition: a well known place to which a passenger may refer to indicate
the origin or the destination of a TRIP),
-
a Stop area (TM definition: A group of Stop point close to each other)
-
a Fuzzy Area (ALERT C definition: Named extent of land about which messages can
be given. The boundaries and shape of such areas need not be precisely defined)
-
an Administrative area
The ILOC+ Area location is composed of :
# (X, Y) pair, in WGS84 co-ordinates (signed longitude and latitude) of the centroïd
of the area
-
-
a word order :1 (coding from the last to the first word), 2 (coding from the first
to the last word).
# Descriptors
Area descriptor 1 : Area Name
Area descriptor 2: Area Name of the administrative area including the area concerned
Area descriptor 3 : tbd
# Location type that identifies the kind of location. It is composed of four characters.
The proposal is to use :
-
the first character to indicate the type of area (administrative area or fuzzy area see
Alert C codification?)
the three others for the Alert C Extended Location Type Code :
-
300 for country
-
700 order 1 area
-
800 order 2 area
-
900 order 3 area
-
600 for fuzzy area
November 2002
Version 2.0
D3.6 & D3.7
2.3.2.2 ILOC+ for Stop Area
A stop area is composed of stop points (cf . TRANSMODEL definitions), this relationship
is part of the network topology description which is not attached to the data transferred in
"real time". A stop area is therefore considered in the sharing/exchange mechanism as an
Area .
2.3.2.3 ILOC+ for Point Of Interest (POI)
The ILOC+ POI location is composed of :
# (X, Y) pair, in WGS84 co-ordinates (signed longitude and latitude) of the POI
-
-
a word order :1 (coding from the last to the first word), 2 (coding from the first to the
last word).
# Descriptors
descriptor 1 : POI Name
descriptor2 : tbd
descriptor3 : tbd
# Location type that identifies the kind of location. It is composed of four characters.
The proposal is to use :
-
the first character to indicate the Transport Mode (I : Irrelevant)
-
the three others for the Alert C Extended Location Type Code (353 for POI)
2.4 Other Issues
2.4.1 Network Topology
The location referencing proposal gives the description of the basic location necessary for
multi-purpose / multimodal applications. The PT network topology, necessary for request on
the PT network is described in the TRIDENT OO model is based on them.
November 2002
Version 2.0
D3.6 & D3.7
2.4.2 ILOC+ Improvement
2.4.2.1 Accuracy
There is a need to add some attributes in the ILOC approach to define the accuracy of the coordinates that will help to match location in the receiving database. This covers two aspects:
- What is the precision of the location (1metre, 10 metres …). Range should be sufficient;
- Where is the exact position of a location (where is the X,Y of a station,, of a bus stop…).
This is a complex matter that cannot be solved in the frame of the TRIDENT project alone.
2.4.2.2 Location-type
There is still work to be done to achieve coherency between location-types used in different
method. The proposal in this document is a first attempt.
November 2002
Version 2.0
D3.7
Annex C – Appendices
TRIDENT
Version 2.0
7 November 2002
Produced by:
TRIDENT Consortium
November 2002
D3.7/Annex C – page 1/20
Version 2.0
D3.7
Activity name:
TRIDENT
Work area:
WP 3
Document title:
Final specifications for the Object Oriented
Approach
Document number:
D3.7 Annex C – Appendices
I:\Contratti\TRIDENT\Deliverables\D3.7\D3.7v2.0\D3-7AnnexC_v2.0.doc
Michele Manzato
Other author(s):
Version history
Version
1.0
1.1
1.3
2.0
Date
02/08/01
26/09/2001
07/12/2001
Nov 2002
Main author
Michele Manzato
Michele Manzato
Michele Manzato
Michele Manzato
Summary of changes
-Small editorial revisions.
Upgrade to v1.3 - No revisions
Final version, after site tests.
November 2002
Version 2.0
D3.7
Foreword
D3.7/4. XML Schema
Annex C. Appendices
TRIDENT.
This document contains two appendices:
•
The bibliography
•
A glossary of terms commonly used throughout the specifications.
November 2002
Version 2.0
D3.7
Table of contents
Foreword...........................................................................................................................................3
Table of contents ..............................................................................................................................4
A
Bibliography .............................................................................................................................5
A.1 Summary ................................................................................................................................5
A.2 Normative references .............................................................................................................5
A.3 Other references .....................................................................................................................6
B
ISO-3166 List of Countries and Country codes ....................................................................8
C
ISO-639:1988 List of Languages and Language Codes......................................................14
D
Glossary ..................................................................................................................................18
November 2002
Version 2.0
D3.7
A Bibliography
A.1 Summary
This section lists the reference documents that were used in the production of the TRIDENT Draft
specifications for the Object Oriented approach. The Normative References section lists documents
that are national or international standards, while all the other documents are listed in the Other
References section.
A.2 Normative references
DATEX
CEN TC278, Road transport and traffic telematics - DATEX specifications for data exchange
between traffic and travel information centres (version 1.2a), ENV 13777, May 2000
(www.datex.org, www.cenorm.be)
DATEX Data Dictionary
CEN TC278, Road transport and traffic telematics - DATEX traffic and travel data dictionary
(version 3.1a), ENV 13106, May 2000
(www.datex.org, www.cenorm.be)
TRANSMODEL
CEN TC278, Road Transport and Traffic Telematics - Public Transport -Reference Data
Model, prENV 12896, May 1997
(www.transmodel.org, www.cenorm.be)
TransXChange
DETR Traffic Area Network, DETR TransXchange, June 2000
(www.transxchange.dtlr.gov.uk)
UML
OMG, OMG Unified Modeling Language Specification, Version 1.3, June 1999
(www.omg.org)
XML
W3C, Extensible Markup Language (XML) Version 1.0 (Second Edition), W3C
Recommendation, 6 October 2000
(www.w3.org)
November 2002
Version 2.0
D3.7
XML Schema Structures
W3C, XML Schema Part 1: Structures, W3C Recommendation, 2 May 2001
(www.w3.org)
XML Schema Datatypes
W3C, XML Schema Part 2: Datatypes, W3C Recommendation, 2 May 2001
(www.w3.org)
A.3 Other references
XML Schema Primer
W3C, XML Schema Part 0: Primer, W3C Recommendation, 2 May 2001
(www.w3.org)
XML Technical introduction
TRIDENT Consortium, D2.1 - Characteristics and benefits of state of the art data sharing &
exchange technologies, Version 1.4, February 2000
(http://www.ertico.com/links/trident.htm)
TRIDENT EDI specifications
TRIDENT Consortium, D3.1 - Draft specifications for the Messaging approach, Version 1.0,
September 2000
(http://www.ertico.com/links/trident.htm)
ISO discussion documents
ISO TC204, Transport Information and Control Systems – Data Modelling for the TICS
Sector – Part 1: Requirements for the TC204 Central Data Registry and for TICS data
dictionaries, ISO WD 14817-1v4, February 2000
ISO TC204, Transport Information and Control Systems – System Architecture – Data
Registration – Part 4: Rules for populating data dictionaries, ISO WD 14817-4Disc.V3.2,
Disc.v3.2, February 2000
(http://www.iteris-east.com/standards)
Highways Agency OO Data Model
Highways Agency, Technical Note 298/135/TN/007: Data Dictionary and Messaging
Standards, DATEX Traffic/Travel Situation Publication Data Model, January 2000
(www.highways.gov.uk)
ILOC
EVIDENCE Project Consortium, Deliverable D2.2 - Final location referencing rules
specifications, June 1999
(http://www.ertico.com/activiti/projects/evidecon.htm)
DATEX-ASN
ISO TC 204, DATEX-ASN (draft), Version 0.10, ISO14827
November 2002
Version 2.0
D3.7
(http://www.iteris-east.com/standards)
SIOERS++
RATP/BUS/MSE, Modélisation de SIOERS++ (Système d’Information Objet pour
l’Exploitation des Réseaux de Surface), 6 Juillet 1999
(www.ratp.fr)
November 2002
Version 2.0
D3.7
B ISO-3166
List of Countries and Country codes1
Last update: Thu Feb 10 10:20:28 MET 1994
Country
AFGHANISTAN
ALBANIA
ALGERIA
AMERICAN SAMOA
ANDORRA
ANGOLA
ANGUILLA
ANTARCTICA
ANTIGUA AND BARBUDA
ARGENTINA
ARMENIA
ARUBA
AUSTRALIA
AUSTRIA
AZERBAIJAN
BAHAMAS
BAHRAIN
BANGLADESH
BARBADOS
BELARUS
BELGIUM
BELIZE
BENIN
BERMUDA
BHUTAN
BOLIVIA
BOSNIA AND HERZEGOWINA
BOTSWANA
BOUVET ISLAND
BRAZIL
BRITISH INDIAN OCEAN TERRITORY
BRUNEI DARUSSALAM
BULGARIA
1
A2
AF
AL
DZ
AS
AD
AO
AI
AQ
AG
AR
AM
AW
AU
AT
AZ
BS
BH
BD
BB
BY
BE
BZ
BJ
BM
BT
BO
BA
BW
BV
BR
IO
BN
BG
A3
AFG
ALB
DZA
ASM
AND
AGO
AIA
ATA
ATG
ARG
ARM
ABW
AUS
AUT
AZE
BHS
BHR
BGD
BRB
BLR
BEL
BLZ
BEN
BMU
BTN
BOL
BIH
BWA
BVT
BRA
IOT
BRN
BGR
Number
4
8
12
16
20
24
660
10
28
32
51
533
36
40
31
44
48
50
52
112
56
84
204
60
64
68
70
72
74
76
86
96
100
Downloaded from: ftp://info.ripe.net/iso3166-countrycodes
November 2002
Version 2.0
D3.7
BURKINA FASO
BURUNDI
CAMBODIA
CAMEROON
CANADA
CAPE VERDE
CAYMAN ISLANDS
CENTRAL AFRICAN REPUBLIC
CHAD
CHILE
CHINA
CHRISTMAS ISLAND
COCOS (KEELING) ISLANDS
COLOMBIA
COMOROS
CONGO
COOK ISLANDS
COSTA RICA
COTE D'IVOIRE
CROATIA (local name: Hrvatska)
CUBA
CYPRUS
CZECH REPUBLIC
DENMARK
DJIBOUTI
DOMINICA
DOMINICAN REPUBLIC
EAST TIMOR
ECUADOR
EGYPT
EL SALVADOR
EQUATORIAL GUINEA
ERITREA
ESTONIA
ETHIOPIA
FALKLAND ISLANDS (MALVINAS)
FAROE ISLANDS
FIJI
FINLAND
FRANCE
FRANCE, METROPOLITAN
FRENCH GUIANA
FRENCH POLYNESIA
FRENCH SOUTHERN TERRITORIES
GABON
GAMBIA
GEORGIA
November 2002
BF
BI
KH
CM
CA
CV
KY
CF
TD
CL
CN
CX
CC
CO
KM
CG
CK
CR
CI
HR
CU
CY
CZ
DK
DJ
DM
DO
TP
EC
EG
SV
GQ
ER
EE
ET
FK
FO
FJ
FI
FR
FX
GF
PF
TF
GA
GM
GE
BFA
BDI
KHM
CMR
CAN
CPV
CYM
CAF
TCD
CHL
CHN
CXR
CCK
COL
COM
COG
COK
CRI
CIV
HRV
CUB
CYP
CZE
DNK
DJI
DMA
DOM
TMP
ECU
EGY
SLV
GNQ
ERI
EST
ETH
FLK
FRO
FJI
FIN
FRA
FXX
GUF
PYF
ATF
GAB
GMB
GEO
854
108
116
120
124
132
136
140
148
152
156
162
166
170
174
178
184
188
384
191
192
196
203
208
262
212
214
626
218
818
222
226
232
233
231
238
234
242
246
250
249
254
258
260
266
270
268
Version 2.0
D3.7
GERMANY
GHANA
GIBRALTAR
GREECE
GREENLAND
GRENADA
GUADELOUPE
GUAM
GUATEMALA
GUINEA
GUINEA-BISSAU
GUYANA
HAITI
HEARD AND MC DONALD ISLANDS
HONDURAS
HONG KONG
HUNGARY
ICELAND
INDIA
INDONESIA
IRAN (ISLAMIC REPUBLIC OF)
IRAQ
IRELAND
ISRAEL
ITALY
JAMAICA
JAPAN
JORDAN
KAZAKHSTAN
KENYA
KIRIBATI
KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF
KOREA, REPUBLIC OF
KUWAIT
KYRGYZSTAN
LAO PEOPLE'S DEMOCRATIC REPUBLIC
LATVIA
LEBANON
LESOTHO
LIBERIA
LIBYAN ARAB JAMAHIRIYA
LIECHTENSTEIN
LITHUANIA
LUXEMBOURG
MACAU
MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OF
MADAGASCAR
November 2002
DE
GH
GI
GR
GL
GD
GP
GU
GT
GN
GW
GY
HT
HM
HN
HK
HU
IS
IN
ID
IR
IQ
IE
IL
IT
JM
JP
JO
KZ
KE
KI
KP
KR
KW
KG
LA
LV
LB
LS
LR
LY
LI
LT
LU
MO
MK
MG
DEU
GHA
GIB
GRC
GRL
GRD
GLP
GUM
GTM
GIN
GNB
GUY
HTI
HMD
HND
HKG
HUN
ISL
IND
IDN
IRN
IRQ
IRL
ISR
ITA
JAM
JPN
JOR
KAZ
KEN
KIR
PRK
KOR
KWT
KGZ
LAO
LVA
LBN
LSO
LBR
LBY
LIE
LTU
LUX
MAC
MKD
MDG
276
288
292
300
304
308
312
316
320
324
624
328
332
334
340
344
348
352
356
360
364
368
372
376
380
388
392
400
398
404
296
408
410
414
417
418
428
422
426
430
434
438
440
442
446
807
450
Version 2.0
D3.7
MALAWI
MALAYSIA
MALDIVES
MALI
MALTA
MARSHALL ISLANDS
MARTINIQUE
MAURITANIA
MAURITIUS
MAYOTTE
MEXICO
MICRONESIA, FEDERATED STATES OF
MOLDOVA, REPUBLIC OF
MONACO
MONGOLIA
MONTSERRAT
MOROCCO
MOZAMBIQUE
MYANMAR
NAMIBIA
NAURU
NEPAL
NETHERLANDS
NETHERLANDS ANTILLES
NEW CALEDONIA
NEW ZEALAND
NICARAGUA
NIGER
NIGERIA
NIUE
NORFOLK ISLAND
NORTHERN MARIANA ISLANDS
NORWAY
OMAN
PAKISTAN
PALAU
PANAMA
PAPUA NEW GUINEA
PARAGUAY
PERU
PHILIPPINES
PITCAIRN
POLAND
PORTUGAL
PUERTO RICO
QATAR
REUNION
November 2002
MW
MY
MV
ML
MT
MH
MQ
MR
MU
YT
MX
FM
MD
MC
MN
MS
MA
MZ
MM
NA
NR
NP
NL
AN
NC
NZ
NI
NE
NG
NU
NF
MP
NO
OM
PK
PW
PA
PG
PY
PE
PH
PN
PL
PT
PR
QA
RE
MWI
MYS
MDV
MLI
MLT
MHL
MTQ
MRT
MUS
MYT
MEX
FSM
MDA
MCO
MNG
MSR
MAR
MOZ
MMR
NAM
NRU
NPL
NLD
ANT
NCL
NZL
NIC
NER
NGA
NIU
NFK
MNP
NOR
OMN
PAK
PLW
PAN
PNG
PRY
PER
PHL
PCN
POL
PRT
PRI
QAT
REU
454
458
462
466
470
584
474
478
480
175
484
583
498
492
496
500
504
508
104
516
520
524
528
530
540
554
558
562
566
570
574
580
578
512
586
585
591
598
600
604
608
612
616
620
630
634
638
Version 2.0
D3.7
ROMANIA
RUSSIAN FEDERATION
RWANDA
SAINT KITTS AND NEVIS
SAINT LUCIA
SAINT VINCENT AND THE GRENADINES
SAMOA
SAN MARINO
SAO TOME AND PRINCIPE
SAUDI ARABIA
SENEGAL
SEYCHELLES
SIERRA LEONE
SINGAPORE
SLOVAKIA (Slovak Republic)
SLOVENIA
SOLOMON ISLANDS
SOMALIA
SOUTH AFRICA
SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS
SPAIN
SRI LANKA
ST. HELENA
ST. PIERRE AND MIQUELON
SUDAN
SURINAME
SVALBARD AND JAN MAYEN ISLANDS
SWAZILAND
SWEDEN
SWITZERLAND
SYRIAN ARAB REPUBLIC
TAIWAN, PROVINCE OF CHINA
TAJIKISTAN
TANZANIA, UNITED REPUBLIC OF
THAILAND
TOGO
TOKELAU
TONGA
TRINIDAD AND TOBAGO
TUNISIA
TURKEY
TURKMENISTAN
TURKS AND CAICOS ISLANDS
TUVALU
UGANDA
UKRAINE
UNITED ARAB EMIRATES
November 2002
RO
RU
RW
KN
LC
VC
WS
SM
ST
SA
SN
SC
SL
SG
SK
SI
SB
SO
ZA
GS
ES
LK
SH
PM
SD
SR
SJ
SZ
SE
CH
SY
TW
TJ
TZ
TH
TG
TK
TO
TT
TN
TR
TM
TC
TV
UG
UA
AE
ROM
RUS
RWA
KNA
LCA
VCT
WSM
SMR
STP
SAU
SEN
SYC
SLE
SGP
SVK
SVN
SLB
SOM
ZAF
SGS
ESP
LKA
SHN
SPM
SDN
SUR
SJM
SWZ
SWE
CHE
SYR
TWN
TJK
TZA
THA
TGO
TKL
TON
TTO
TUN
TUR
TKM
TCA
TUV
UGA
UKR
ARE
642
643
646
659
662
670
882
674
678
682
686
690
694
702
703
705
90
706
710
239
724
144
654
666
736
740
744
748
752
756
760
158
762
834
764
768
772
776
780
788
792
795
796
798
800
804
784
Version 2.0
D3.7
UNITED KINGDOM
UNITED STATES
UNITED STATES MINOR OUTLYING ISLANDS
URUGUAY
UZBEKISTAN
VANUATU
VATICAN CITY STATE (HOLY SEE)
VENEZUELA
VIET NAM
VIRGIN ISLANDS (BRITISH)
VIRGIN ISLANDS (U.S.)
WALLIS AND FUTUNA ISLANDS
WESTERN SAHARA
YEMEN
YUGOSLAVIA
ZAIRE
ZAMBIA
ZIMBABWE
November 2002
GB
US
UM
UY
UZ
VU
VA
VE
VN
VG
VI
WF
EH
YE
YU
ZR
ZM
ZW
GBR
USA
UMI
URY
UZB
VUT
VAT
VEN
VNM
VGB
VIR
WLF
ESH
YEM
YUG
ZAR
ZMB
ZWE
826
840
581
858
860
548
336
862
704
92
850
876
732
887
891
180
894
716
Version 2.0
D3.7
C ISO-639:1988
List of Languages and Language Codes2
The Registration Authority for ISO 639 is: Infoterm, Osterreichisches Normungsinstitut (ON),
Postfach 130, A-1021 Vienna, Austria.
Code
aa
ab
af
am
ar
as
ay
az
ba
be
bg
bh
bi
bn
bo
br
ca
co
cs
cy
da
de
dz
el
en
eo
es
et
eu
fa
fi
fj
2
Language name
Afar
Abkhazian
Afrikaans
Amharic
Arabic
Assamese
Aymara
Azerbaijani
Bashkir
Byelorussian
Bulgarian
Bihari
Bislama
Bengali; Bangla
Tibetan
Breton
Catalan
Corsican
Czech
Welsh
Danish
German
Bhutani
Greek
English
Esperanto
Spanish
Estonian
Basque
Persian
Finnish
Fiji
Downloaded from: ftp://dkuug.dk/i18n/ISO_639
November 2002
Version 2.0
D3.7
fo
fr
fy
ga
gd
gl
gn
gu
ha
he
hi
hr
hu
hy
ia
id
ie
ik
is
it
iu
ja
jw
ka
kk
kl
km
kn
ko
ks
ku
ky
la
ln
lo
lt
lv
mg
mi
mk
ml
mn
mo
mr
ms
mt
my
Faroese
French
Frisian
Irish
Scots Gaelic
Galician
Guarani
Gujarati
Hausa
Hebrew (formerly iw)
Hindi
Croatian
Hungarian
Armenian
Interlingua
Indonesian (formerly in)
Interlingue
Inupiak
Icelandic
Italian
Inuktitut
Japanese
Javanese
Georgian
Kazakh
Greenlandic
Cambodian
Kannada
Korean
Kashmiri
Kurdish
Kirghiz
Latin
Lingala
Laothian
Lithuanian
Latvian, Lettish
Malagasy
Maori
Macedonian
Malayalam
Mongolian
Moldavian
Marathi
Malay
Maltese
Burmese
November 2002
Version 2.0
D3.7
na
ne
nl
no
oc
om
or
pa
pl
ps
pt
qu
rm
rn
ro
ru
rw
sa
sd
sg
sh
si
sk
sl
sm
sn
so
sq
sr
ss
st
su
sv
sw
ta
te
tg
th
ti
tk
tl
tn
to
tr
ts
tt
tw
Nauru
Nepali
Dutch
Norwegian
Occitan
(Afan) Oromo
Oriya
Punjabi
Polish
Pashto, Pushto
Portuguese
Quechua
Rhaeto-Romance
Kirundi
Romanian
Russian
Kinyarwanda
Sanskrit
Sindhi
Sangho
Serbo-Croatian
Sinhalese
Slovak
Slovenian
Samoan
Shona
Somali
Albanian
Serbian
Siswati
Sesotho
Sundanese
Swedish
Swahili
Tamil
Telugu
Tajik
Thai
Tigrinya
Turkmen
Tagalog
Setswana
Tonga
Turkish
Tsonga
Tatar
Twi
November 2002
Version 2.0
D3.7
ug
uk
ur
uz
vi
vo
wo
xh
yi
yo
za
zh
zu
Uighur
Ukrainian
Urdu
Uzbek
Vietnamese
Volapuk
Wolof
Xhosa
Yiddish (formerly ji)
Yoruba
Zhuang
Chinese
Zulu
November 2002
Version 2.0
D3.7
D Glossary
ASN.1
Abstract Syntax Notation-1. A common language for data exchange that
reduces the number of needed interfaces when several systems exchange
coded information.
ALERT-C
The location referencing method used in the DATEX standard. ALERT-C is
based on regional location tables.
CORBA
Common Object Request Broker Architecture. Standardised architecture for
distributed object-oriented programming. (www.omg.org)
DATEX
DATa EXchange. European experimental standard for traffic information
exchange that uses a messaging approach based on EDIFACT.
(www.cenorm.org)
DBMS
DataBase Management System. A system that manages one or more
databases by providing a) means of creating databases; b) means of
accessing (querying) them; and c) utilities to ensure that the database is
working properly.
EDIFACT
Electronic Data Interchange for Administration, Commerce and Transport.
An ISO standard that specifies data interchange structure in terms of
standard segments and data elements associated with syntax rules.
(www.edi.org)
IDL
Interface Definition Language. The language used in files that describe the
interface to CORBA distributed objects. (www.omg.org)
IETF
Internet Engineering Task Force. A large open international community of
network designers, operators, vendors, and researchers concerned with the
evolution of the Internet architecture and the smooth operation of the
Internet. It is open to any interested individual. (www.ietf.org)
ILOC
Intersection LOCation. A point location referencing method developed
within the EU project EVIDENCE. A road intersection is coded in ILOC
with its WGS’84 coordinates plus three descriptors that are the names of the
intersecting roads.
ILOC+
The extension to ILOC developed in TRIDENT.
IIOP
Internet Inter-ORB Protocol. A wire protocol for making requests to an
object and for the object to respond to the application making the request in
the CORBA architecture. (www.omg.org)
Internet
The Internet is a network of networks, linking computers to computers
sharing the TCP/IP protocols. Each runs software to provide or “serve”
information and/or to access and view information. The Internet is the
transport vehicle for the information stored in files or documents on another
computer. An international body (the IETF) is in charge for guiding and
November 2002
Version 2.0
D3.7
administering the smooth operation and the evolution of the Internet
(www.ietf.org)
Java
A high-level programming language and a programming platform developed
by Sun Microsystems which is explicitly addressed to interoperation
between different operating systems and to application scalability.
(www.java.sun.com)
OMG
Object Management Group. A not-for-profit corporation in whose
commitment is to develop technically excellent, commercially viable and
vendor independent specifications for the software industry.
(www.omg.org).
OO
Object-Oriented. Adjective. Developed according to the Object Oriented
programming paradigm.
OOP
Object-Oriented Programming. A software modelling paradigm whose key
idea is modelling the real world in conceptual entities called ‘objects’.
SGML
Standard Generalized Markup Language. A method for creating
interchangeable, structured documents. With SGML one can: define a
document structure using a special grammar called a Document Type
Definition (DTD); add markup to show the structural units in a document;
validate that documents follow the structure defined in the DTD. SGML is
an ISO standard (ISO 8879:1986, Information processing – Text and office
systems – Standard Generalized Markup Language). (www.iso.ch)
TCP/IP
Transmission Control Protocol/Internet Protocol. The basic communication
protocols of the Internet. They can also be used as a communications
protocol in a private network (either an intranet or an extranet). Each
computer connected to the Internet is equipped with software that
implements TCP/IP. (www.ietf.org)
TRIDENT
TRansport Intermodality Data sharing and Exchange NeTworks. The EU
project and project consortium that developed these draft specifications.
(www.ertico.com/links/trident.htm)
UML
Unified Modeling Language. A visual language, developed by the OMG,
that is used for the conceptual modelling of software systems. By means of
UML complex software systems can be formally described in a collection of
graphical diagrams. Many different types of diagrams are defined in UML
each dedicated to the modelling of a particular aspect of the software
system. (www.omg.org)
URL
Universal Resource Identifier. The unique identifier for a resource (file,
image, service) on the Internet. (www.w3c.org)
W3C
World Wide Web Consortium. The W3C leads the World Wide Web to its
full potential by developing common protocols that promote its evolution
and ensure its interoperability. W3C develops and maintains standards like
HTML and XML. W3C standards are called Recommendations.
(www.w3c.org)
WGS’84
World Geodetic System of 1984. Defines the shape and size of the ellipsoid
of revolution (an oblate spheroid) that is considered to be the best
November 2002
Version 2.0
D3.7
representation of the Earth. The parameters of the ellipsoid are Flattening
F=1/298.257223563 (≈3.35 ‰), equatorial radius = 6 378 137.0 m.
XML
Extensible Markup Language. A simple (but powerful) mark-up language
for documents containing structured information that allows data structures
and informative content to be identified within ordinary text files. XML is a
simple application profile of the SGML expressly developed to ease the
exchange of information in a network of computer. (www.w3c.org)
November 2002
Version 2.0

trident - URBA 2000

Transcription

Similar documents

Ticketmaster API - Affiliate Window

Module/Tool Profile AXEPTool

HMCS Athabaskan visits NASDAQ during Fleet Week New York City

Dynamic Trust in Mixed Service-oriented Systems

AXDB - Axmedis

JC3IEDM-Annex O-XML-3.1.4.doc

Batch Production of Driving Distances and Times Using SAS® and

Swedbank Gateway Service Description 7.0

MIDI-PYRENÉES

Giving yourself all the chances to succeed... in college !