ISO/TS 21219-18:2015

TECHNICAL ISO/TS
SPECIFICATION 21219-18
First edition
2015-03-01
Intelligent transport systems - Traffic
and travel information (TTI) via
transport protocol experts group,
generation 2 (TPEG2) —
Part 18:
Traffic flow and prediction
application (TPEG2-TFP)
Systèmes intelligents de transport — Informations sur le trafic
et le tourisme via le groupe expert du protocole de transport,
génération 2 (TPEG2) —
Partie 18: Flux de trafic et application de prédiction (TPEG2-TFP)
Reference number
©
ISO 2015
© ISO 2015
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2015 – All rights reserved

Contents Page
Foreword .iv
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 2
3.1 Terms and definitions . 2
3.2 Abbreviated terms . 3
4 Application specific constraints . 3
5 TFP Structure . 5
6 TFP Message components . 5
6.1 TFPMessage . 5
6.2 MessageManagementContainer . 6
6.3 LocationReferencingContainer . 7
6.4 TFPMethod . 7
6.5 FlowPolygonObject . 8
6.6 FlowPolygon . 9
6.7 FlowStatus . 9
6.8 FlowMatrix .10
6.9 FlowVector .14
6.10 SectionExtensionComponent .15
6.11 RestrictionExtensionComponent .15
6.12 StatusExtensionComponent .15
6.13 StatisticsExtensionComponent .15
7 TFP Data Types .15
7.1 PolygonPoint .16
7.2 FlowVectorSection .16
7.3 StatusParameters .17
7.4 Restrictions .17
7.5 StatisticalParameters.18
7.6 LinkedCause .19
8 TFP Tables .19
8.1 tfp001: VehicleClass .19
8.2 tfp002: VehicleCredentials .20
8.3 tfp003: LevelOfService .20
8.4 tfp004: SpatialResolution .22
8.5 tfp005:laneRestriction .22
8.6 tfp006: CauseCode .23
8.7 tfp007: SectionType.26
8.8 tfp008: FlowDataQuality .27
Annex A (normative) Traffic Flow and Prediction, TPEG-Binary Representation .28
Annex B (normative) Traffic Flow and Prediction, TPEG-ML Representation .38
Bibliography .49
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO and TISA shall not be held responsible for identifying any or all such patent rights.
Details of any patent rights identified during the development of the document will be in the Introduction
and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical Barriers
to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 204 Intelligent transport systems, in cooperation
with the Traveller Information Services Association (TISA), TPEG Applications Working Group through
Category A Liaison status.
ISO/TS 21219 consists of the following parts, under the general title Intelligent transport systems —
Traffic and travel information (TTI) via transport protocol expert group, generation 2 (TPEG2):
— Part 2: UML modelling rules [Technical Specification]
— Part 3: UML to binary conversion rules [Technical Specification]
— Part 4: UML to XML conversion rules [Technical Specification]
— Part 5: Service framework [Technical Specification]
— Part 6: Message management container [Technical Specification]
— Part 7: Location referencing container [Technical Specification]
— Part 18: Traffic flow and prediction application [Technical Specification]
The following parts are planned:
— Part 1: Introduction, numbering and versions [Technical Specification]
— Part 9: Service and network information [Technical Specification]
— Part 10: Conditional access information [Technical Specification]
— Part 14: Parking information application [Technical Specification]
— Part 15: Traffic event compact application [Technical Specification]
— Part 16: Fuel price information application [Technical Specification]
iv © ISO 2015 – All rights reserved

— Part 19: Weather information application [Technical Specification]
— Part 20: Extended TMC location referencing [Technical Specification]
— Part 21: Geographic location referencing [Technical Specification]
— Part 22: OpenLR·location·referencing [Technical Specification]
— Part 23: Roads·and·multi-modal·routes·application [Technical Specification]
Introduction
History
TPEG technology was originally proposed by the European Broadcasting Union (EBU) Broadcast
Management Committee, who established the B/TPEG project group in the autumn of 1997 with a brief
to develop, as soon as possible, a new protocol for broadcasting traffic and travel-related information
in the multimedia environment. TPEG technology, its applications and service features were designed
to enable travel-related messages to be coded, decoded, filtered and understood by humans (visually
and/or audibly in the user’s language) and by agent systems. Originally a byte-oriented data stream
format, which may be carried on almost any digital bearer with an appropriate adaptation layer, was
developed. Hierarchically structured TPEG messages from service providers to end-users were designed
to transfer information from the service provider database to an end-user’s equipment.
One year later in December 1998, the B/TPEG group produced its first EBU specifications. Two documents
were released. Part 2 (TPEG-SSF, which became ISO/TS 18234-2) described the Syntax, Semantics and
Framing structure, which was used for all TPEG applications. Meanwhile Part 4 (TPEG-RTM, which
became ISO/TS 18234-4) described the first application, for Road Traffic Messages.
Subsequently in March 1999, CEN TC 278/WG 4, in conjunction with ISO/TC 204/WG 10, established a
project group comprising members of the former EBU B/TPEG and they continued the work concurrently.
Further parts were developed to make the initial set of four parts, enabling the implementation of a
consistent service. Part 3 (TPEG-SNI, ISO/TS 18234-3) described the Service and Network Information
Application, used by all service implementations to ensure appropriate referencing from one service
source to another.
Part 1 (TPEG-INV, ISO/TS 18234-1), completed the series, by describing the other parts and their
relationship; it also contained the application IDs used within the other parts. Additionally, Part 5,
the Public Transport Information Application (TPEG-PTI, ISO/TS 18234-5), was developed. The so-
called TPEG-LOC location referencing method, which enabled both map-based TPEG-decoders and non
map-based ones to deliver either map-based location referencing or human readable text information,
was issued as ISO/TS 18234-6 to be used in association with the other applications parts of the
ISO/TS 18234-series to provide location referencing.
The ISO/TS 18234-series has become known as TPEG Generation 1.
TPEG Generation 2
With the inauguration of the Traveller Information Services Association (TISA) in December 2007
derived from former Forums and the CEN/ISO development project group, the TPEG Applications
Working Group took over development work for TPEG technology.
It was about this time that the (then) new Unified Modelling Language (UML) was seen as having major
advantages for the development of new TPEG Applications in communities who would not necessarily
have binary physical format skills required to extend the original TPEG TS work. It was also realized
that the XML format for TPEG described within the ISO/TS 24530-series (now superseded) had a greater
significance than previously foreseen; especially in the content-generation segment and that keeping
two physical formats in synchronism, in different standards series, would be rather difficult.
As a result TISA set about the development of a new TPEG structure that would be UML based – this has
subsequently become known as TPEG Generation 2.
TPEG2 is embodied in the ISO/TS 21219-series and it comprises many parts that cover introduction,
rules, toolkit and application components. TPEG2 is built around UML modelling and has a core of rules
that contain the modelling strategy covered in Parts 2, 3, 4 and the conversion to two current physical
formats: binary and XML; others could be added in the future. TISA uses an automated tool to convert
from the agreed UML model XMI file directly into an MS Word document file, to minimize drafting
errors, that forms the Annex for each physical format.
vi © ISO 2015 – All rights reserved

TPEG2 has a three container conceptual structure: Message Management (Part 6), Application (many
Parts) and Location Referencing (Part 7). This structure has flexible capability and can accommodate
many differing use cases that have been proposed within the TTI sector and wider for hierarchical
message content.
TPEG2 also has many location referencing options as required by the service provider community,
any of which may be delivered by vectoring data included in the Location Referencing Container. The
following classification provides a helpful grouping of the different TPEG2 parts according to their
intended purpose:
Toolkit parts: TPEG2-INV (Part 1), TPEG2-UML (Part 2), TPEG2-UBCR (Part 3), TPEG2-UXCR (Part 4),
TPEG2-SFW (Part 5), TPEG2-MMC (Part 6), TPEG2-LRC (Part 7)
Special applications: TPEG2-SNI (Part 9), TPEG2-CAI (Part 10)
Location referencing: TPEG2-ULR (Part 11), TPEG2-ETL (Part 20), TPEG2-GLR (Part 21), TPEG2-OLR
(Part 22)
Applications: TPEG2-PKI (Part 14), TPEG2-TEC (Part 15), TPEG2-FPI (Part 16), TPEG2-TFP (Part 18),
TPEG2-WEA (Part 19), TPEG2-RMR (Part 23)
TPEG2 has been developed to be broadly (but not totally) backward compatible with TPEG1 to assist in
transitions from earlier implementations, while not hindering the TPEG2 innovative approach and being
able to support many new features, such as dealing with applications having both long-term, unchanging
content and highly dynamic content, such as Parking Information.
This Technical Specification is based on the TISA specification technical/editorial version number:
TPEG2-TFP/1.0/003.
TECHNICAL SPECIFICATION ISO/TS 21219-18:2015(E)
Intelligent transport systems - Traffic and travel
information (TTI) via transport protocol experts group,
generation 2 (TPEG2) —
Part 18:
Traffic flow and prediction application (TPEG2-TFP)
1 Scope
This Technical Specification specifies the TPEG application Traffic Flow and Prediction (TFP). It has been
specifically designed to provide information to a variety of receivers using different channels, including
in the first instance Digital Broadcasting and Internet technologies. Traffic flow and prediction messages
are intended for in-car applications and may be as well presented directly to the user by textual, voiced
and graphically output devices.
TFP is status oriented, i.e. the transmitted information updates continuously the receiver’s knowledge
for a dedicated road network. In particular the traffic states are delivered any time and for all road
sections of the network, even when there are no abnormal traffic situations.
Generally, TFP focuses on the following requirements:
— provide dynamic navigation systems with up-to-date traffic state information,
— ensure travel safety for the driver,
— enable the calculation of alternative routes,
— avoid delays (e.g. traffic jams),
— lower traffic load on over-saturated parts of the network,
— keep driver informed about current and upcoming traffic,
— compact and efficient coding of the traffic information.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO 17572-1:2008, Intelligent transport systems (ITS) — Location referencing for geographic databases —
Part 1: General requirements and conceptual model
ISO 17572-2:2008, Intelligent transport systems (ITS) — Location referencing for geographic databases —
Part 2: Pre-coded location references (pre-coded profile)
ISO 17572-3:2008, Intelligent transport systems (ITS) — Location referencing for geographic databases —
Part 3: Dynamic location references (dynamic profile)
ISO/TS 18234-1:2013, Intelligent transport systems — Traffic and travel information via transport
protocol experts group, generation 1 (TPEG1) binary data format — Part 1: Introduction, numbering and
versions (TPEG1-INV)
ISO/TS 18234-6:2006, Traffic and Travel Information (TTI) — TTI via Transport Protocol Expert Group
(TPEG) data-streams — Part 6: Location referencing applications
ISO/TS 21219-2, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 2: UML modelling rules
ISO/TS 21219-3, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 3: UML to binary conversion rules
ISO/TS 21219-4, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 4: UML to XML conversion rules
ISO/TS 21219-5, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2 — Part 5: Service framework (TPEG2-SWF)
ISO/TS 21219-6, Intelligent transport systems — Traffic and travel information via transport protocol
experts group, generation 2(TPEG2) — Part 6: Message management container (TPEG2-MMC)
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1.1
Message Management Container
concept applied to the grouping of all message elements including Message Management Information of
a TPEG-Message together in one place
3.1.2
Location Referencing
means to provide information that allows a system to accurately identify a location
Note 1 to entry: The content of a location reference allows the location to be presented in a graphical or textual
manner to the end-user (e.g. coloured network graphs) as well as to be used for navigational systems purposes.
3.1.3
Location Referencing Container
concept applied to the grouping of all the Location Referencing elements, of a TPEG-Message,
together in one place
2 © ISO 2015 – All rights reserved

3.2 Abbreviated terms
ADC Application Data Container
AID TPEG Application ID
CEN Comité Européen de Normalization
EBU European Broadcasting Union
LRC Location Referencing Container
MMC Message Management Container
OSI Open Systems Interconnection
SSF TPEG Specification: Syntax, Semantics and Framing Structures
TPEG Transport Protocol Expert Group
TTI Traffic and Traveller Information
UML Unified Modelling Language
XML Extensible Markup Language
XSD XML Schema Definition
4 Application specific constraints
Ordered Components
TPEG-TFP requires a fixed order of TPEG components. The order for the TFP message component is
shown in Figure 1; the first component shall be the Message Management Container. This shall be the only
component if the message is a cancellation message. Otherwise, the MMC component shall be followed by
the Application Data Container component which includes the traffic flow information. This shall be followed
by the Location Referencing Container component, if the LRC is present in this message (see also 6.1).
Figure 1 — Composition of TPEG messages
Extendibility
The requirement of a fixed component order does not affect the extension of TFP. Future application
extensions may insert new components or may replace existing components by new ones without losing
backward compatibility. That means a TFP decoder shall be able to detect and skip unknown components.
For reasons of efficiency some data structures of TFP which may potentially require extensions in future
are defined as TPEG DataStructures though these structures are not extensible in a backward compatible
way. To ensure extensibility dedicated extension components are added to these DataStructures which
may be used for future TFP extensions of TFP (DataStructures ‘FlowVectorSection’, ‘StatusParameters’,
‘Restrictions’, ‘StatisticalParameters’, see also 6.1).
TPEG Service Component Frame
TFP makes use of the “Service Component Frame with dataCRC, groupPriority, and messageCount”
according to ISO/TS 21219-5.
Version number signalling
Version numbering is used to track the separate versions of an application through its development and
deployment. The differences between these versions may have an impact on client devices.
For services basing on this TFP specification the following version numbers shall be signalled in the SNI:
— major version number 1
— minor version number 0
Application ID (AID)
The TFP application ID is assigned by ISO/TS 18234-1:2013. As this document requires some time for
update with the recent AIDs it may not include all assigned AIDs. In this case, please contact TISA for
further information.
4 © ISO 2015 – All rights reserved

5 TFP Structure
Figure 2 — UML Class Model of TPEG-TFP
6 TFP Message components
6.1 TFPMessage
A ‘TFPMessage’ component is the top container of a TFP message. It contains all information about a
particular part of the network, for example the traffic state for a road segment.
The traffic flow content of a TFPMessage is typically highly dynamic while the affected road stretch
defined by the Location Referencing Container (LRC) shall remain static during the life cycle of a
message. Thus, partial message management (ISO/TS 21219-6) may be applied to update the traffic
flow states of a message frequently whereas the LRC may be repeated with a longer repetition interval.
Accordingly, a TFP message can include alternatively
— One MMC only in case of a cancellation message (ISO/TS 21219-6)
— One MMC, one or several ADCs and one LRC in case of monolithic message management
(ISO/TS 21219-6):
— Partial message management (ISO/TS 21219-6):
— One MMC only, including the multipart message directory
— One MMC and one or several ADCs
— One MMC and one LRC
TFP provides three methods for the representation of current and predicted traffic flow states which
may be used alternatively, i.e. just one method shall be applied within one TFP message:
— Flow-Polygon-Method: The traffic flow is modelled by a number of spatial/temporal
‘FlowPolygonObjects’ (see description of component ‘FlowPolygonObject’, 6.5).
— FlowStatus-Method: A flow status applied to the overall road stretch defined by the LRC of the
message (see description of component ‘FlowStatus’, 6.7). A TFP message using this method and
which is not a cancellation message shall contain exactly one ‘FlowStatus’ container.
— Flow-Matrix-Method: The road stretch is divided into sections each with a homogenous flow state,
thus building a ‘FlowVector’. A ‘FlowMatrix’ consists of one or several FlowVectors for dedicated
temporal intervals, e.g. with one FlowVector for the current flow status and another one for
prognosis in 15 min (see description of components ‘FlowMatrix’, 6.8). A TFP message using this
method and which is not a cancellation message shall contain exactly one ‘FlowMatrix’ container.
To minimize the length of TFP messages the spatial positions of the Flow-Matrix and Flow-Polygon
methods are coded by spatial offsets to the location reference in the LRC. These offsets shall be calculated
in upstream direction to the end of the road stretch as defined by the location reference of the message
(see also 6.3). The location reference in the LRC shall cover the entire road stretch required for this TFP
message. The Flow-Matrix method allows also the usage of relative offsets (see 6.8).
The attributes of the ‘TFPMessage’ component are listed hereunder:
Multiplic-
Name Type Description
ity
Ordered Components
mmc MessageManagementContainer 1 Message Management Container
(external)
method Component TFPMethod 0.* Traffic flow data
loc LocationReferencingContainer 0.1 Location Referencing Container
(external)
6.2 MessageManagementContainer
The MessageManagementContainer is a placeholder for the MessageManagementContainer as defined in
the MMC-toolkit specification (ISO/TS 21219-6). It assigns the Traffic Flow and Prediction application
specific local component ID for the MMC container (see A.3.4).
This component contains all and only information related to message management. The TPEG server side,
especially the instance generating the transmission data, has to ensure that the message management
information allows unambiguous interpretation over time and in appropriate scenarios with disturbed
reception specific to the transmission channel.
TFP implementations may use both monolithic and partial message management (ISO/TS 21219-
6). A TPEG service may contain messages with both MMC methods but it shall be used alternatively
for a particular message, i.e. a dedicated message shall not be transmitted with an alternating
partial/monolithic MMC.
6 © ISO 2015 – All rights reserved

6.3 LocationReferencingContainer
The LocationReferencingContainer component is a placeholder for the LocationReferencingContainer
(LRC) as described in the LRC toolkit specification (ISO/TS 18234-6:2006). It assigns the Traffic Flow
and Prediction (TFP) application specific local component ID for the LRC container (see also A.3.5). All
component IDs within the LRC container are local to the LRC toolkit
The location of a TFP message (e.g. a road stretch) may be quite stable where the related traffic flow
values may change dynamically. Thus, the LRC may not be required in each version of the message. The
MMC Partial Update mechanism if the LRC is not present in a TFP message the receiver shall use the LRC
of the most recently received message with the same Message ID (MID) for determining the location.
Accordingly, the sender side shall use a new message ID if the location respectively the LRC is changed.
The LRC component contains all information describing the location where the situation described in
TFP is taking place. TFP shall use only linear locations to define the road stretch affected, but no area
or point locations.
The end of the LRC location (in driving direction) defines the Spatial Reference Point. Based on this Refer-
ence Point offsets are used to dedicated points on the road stretch, e.g. Polygon Points (see description of the
Flow-Polygon-Method, 6.5) or delimiters of road sections (see description of the Flow-Matrix-Method, see 6.8).
If TMC location referencing (ISO 17572-3:2008) is used in the LRC, the Spatial Reference Point shall be
always the Primary Location. As the TMC Primary Location defines only an intersection and is thus not
very accurate the following convention shall be applied in TFP for TMC locations (see also Figure 3):
It is strongly recommended that TFP services use only one-directional but no bi-directional location
references.
As TFP uses linear locations only the TMC extent defining the secondary location shall be greater than 0.
The Spatial Reference Point for TMC locations is the position on the road stretch where the last entry or
exit in driving direction is entering or leaving the road stretch (see Figure 3 below).
Figure 3 — Application of TMC location references in TFP
6.4 TFPMethod
Traffic conditions are modelled as traffic flow objects. TFP provides three different methods to define
such an object, for details see descriptions of components ‘FlowPolygonObject’ (see 6.5), FlowStatus’
(see 6.7) and FlowMatrix’ (see 6.8).
The template ‘TFPMethod’ is the generalization of these three methods.
Name Type Multiplicity Description
startTime DateTime 1 The start of the time period for which the provided content is
valid.
duration IntUnLoMB 0.1 The duration [min] of the time period for which the provided
content is valid. The period starts at ‘startTime’ and ends at ‘start-
Time’+’duration’. This attribute shall be used by the ‘PolygonFlow-
Object’ component and may be used if required otherwise.
6.5 FlowPolygonObject
The Flow Polygon method describes the traffic situation within the network by a number of
‘FlowPolygonObjects’. Each of these objects defines a spatial and temporal area with critical or congested
conditions, whereas the rest of the considered road network is assumed to be in a free-flow state (see
Figure 4 below).
Figure 4 — Example of a Flow Polygon Object with 2 Flow Polygons
A particular ‘FlowPolygonObject’ consists of a set of nested ‘FlowPolygons’. A Flow Polygon represents a
distinct traffic flow state within a spatial and temporal area surrounded by a polygon, which is defined
by a vector of ‘PolygonPoints’. For reasons of efficiency, these polygon points are using offset information:
— spatial offsets to the end of location reference related to the message (Spatial Reference Point)
— temporal offsets to the start-time defined by the ‘validityPeriod’ of the surrounding
‘FlowPolygonObject’
The following requirements shall be fulfilled for the construction of the FlowPolygonObjects:
— Within a ‘FlowPolygonObject’ a traffic flow state related to a ‘FlowPolygon’ shall ‘overwrite’ in
its temporal/spatial area the traffic status of a Flow Polygon with a lower value of the attribute
‘polygonIndex’ (e.g. in figure above the red polygon overrides the orange one).
8 © ISO 2015 – All rights reserved

— For that, the Flow Polygons of a Flow Polygon Object shall be ordered from ‘outer to inner’, i.e.
the temporal/spatial area covered by the Flow Polygon with polygonIndex A shall be a sub-area
of the Flow Polygon with polygonIndex B, if B is smaller than A (see also definition of component
‘FlowPolygon’).
— Only convex Flow Polygons shall be used in TFP, i.e. very internal angle of the surrounded area is
less than 180 degrees.
— The vector of ‘PolygonPoints’ of a ‘FlowPolygon’ shall be ordered in clockwise direction starting
with Polygon Point with the minimum value of attribute ‘timeOffset’.
Name Type Multiplicity Description
startTime DateTime 1 See 6.4
duration IntUnLoMB 0.1 See 6.4; this attribute shall be present in the ‘FlowPolygon-
Object’ component as it is required for the temporal interval
flow polygon
spatialResolution tfp004: 1 Resolution of the spatial offset used in this structure in steps
SpatialResolution of 10/50/100/500 m or TMC-locations. This spatial resolution
value shall be used for all spatial offsets in the embedded
‘FlowPolygon’ components if not overridden there by the
corresponding attribute ‘spatialResolutionPolygon’. Relative
spatial offsets (table entries 5 and 6) shall not be used.
polygons Component FlowPol- 1.* Flow polygon data; see 6.6
ygon
6.6 FlowPolygon
A ‘FlowPolygon’ includes a spatial/temporal area with a consistent traffic flow status.
Multiplic-
Name Type Description
ity
polygonIndex IntUnLoMB 1 Unique within related ‘FlowPolygonObject’. Used for
ordering the FlowPolygons within the ‘FlowPolygonObject’
(see 6.5).
status StatusParameters 1 Attributes describing the traffic flow status within the
polygon
polygonPoints PolygonPoint 1.* Vector with polygon points
spatialResolutionPolygon tfp004: 0.1 Resolution of the spatial offset used for this polygon, in
SpatialResolution steps of 10/50/100/500 m or TMC-locations. The value of
this attribute - if present - overrides for this FlowPolygon
the attribute value ‘spatialResolution’ of the related ‘Flow-
PolygonObject’ component. Relative spatial offsets (table
entries 5 and 6) shall not be used.
restriction Restrictions 0.1 Information on restrictions related to the reported infor-
mation
statistics StatisticalParameters 0.1 Statistical information related to the reported flow status
cause tfp006: 0.1 A simple cause for the reported traffic flow status may be
CauseCode added by this attribute; this parameter should be omitted
if a detailed cause is available by an external message (see
attribute ‘linked cause’)
detailedCause LinkedCause 0.1 A detailed cause may be reported by a linked message (e.g.
a TEC-message)
6.7 FlowStatus
The ‘FlowStatus’ component includes the information about the traffic flow status at a dedicated location
defined by the LRC and for a distinct time interval.
A message may contain more than one ‘FlowStatus’ component in order to provide information for
several vehicle classes or for several time intervals.
Name Type Multiplic- Description
ity
startTime DateTime 1 See 6.4
duration IntUnLoMB 0.1 See 6.4; this attribute shall be used in the ‘FlowStatus’ compo-
nent if forecast or tendency data are provided by the message
and may be omitted otherwise.
status StatusParameters 1 Attributes describing the traffic flow status at the related loca-
tion
restriction Restrictions 0.1 Information on restrictions related to the reported traffic flow
statistics StatisticalParameters 0.1 Statistical information related to the reported flow status
cause tfp006:CauseCode 0.1 A simple cause for the reported traffic flow status may be added
by this attribute; this parameter shall be omitted if a detailed
cause is available by an external message (see attribute ‘linked
cause’)
detailedCause LinkedCause 0.1 A detailed cause may be reported by a linked message (e.g. a
TEC-message)
6.8 FlowMatrix
The Flow Matrix method describes the traffic situation of the considered road network using temporal
and spatial matrices of traffic flow states, such that the overall considered network is covered by the
transmitted matrix objects (see Figure 5 below):
— A particular ‘FlowMatrix’ component covers a dedicated part of the road network, e.g. a road or
a section of a road. It is composed of a number of ‘FlowVectors’. In particular a Flow Matrix may
include one Flow Vector, e.g. if no forecast data are available and only the current traffic status on
the network part is transmitted.
— Each ‘FlowVector’ of a ‘Flow Matrix’ covers the same network part but only for a dedicated time
interval (e.g. the FlowVectors in Figure 5 may have one vector for current status and each one for
15/30/45/60min prognosis). The temporal partition is determined by temporal offsets to the value
of attribute ‘startTime’ of the related ‘FlowMatrix’ object.
— The spatial area of a Flow Vector is divided into ‘FlowVectorSections’ with consistent traffic flow
states. This spatial partition is determined by spatial offsets to the end point of the affected road
stretch defined by the LRC (see also use cases below). For the Flow Matrix method also relative
offsets to the beginning of the following section may be used (see use case 6 below)
10 © ISO 2015 – All rights reserved

Figure 5 — Example of a Flow Matrix Object with 4 Flow Vectors (1 for current status, 3 for
prognosis)
Name Type Multiplicity Description
startTime DateTime 1 See 6.4
duration IntUnLoMB 0.1 See 6.4, this attribute shall be used in the ‘FlowMatrix’
component if forecast or tendency data are provided by the
message and may be omitted otherwise.
spatialResolution tfp004: 1 Resolution of the spatial offset used in this structure in steps
SpatialResolution of 10/50/100/500 m or TMC-locations. This spatial resolution
value shall be used for all spatial offsets in the embedded data
objects if not overridden there by the corresponding attrib-
utes (i.e. ‘spatialResolutionVector’ in component ‘FlowVector’
and ‘spatialResolutionSection’ in datastructure ‘FlowVector-
Section’).
Relative spatial offsets (table entries 5 and 6) shall not be
used for this attribute.
vectors Component FlowVec- 1.* Flow vector data; see 6.9
tor
Examples and Use Cases:
1. UC1: Flow Matrix with one Flow Vector for current traffic and with 3 Flow Sections along the road
stretch
2. UC2: Flow Matrix with two Flow Vectors (current traffic and 30min forecast), each with 3 Flow
Sections along the road stretch
3. UC3: Flow Matrix with one Flow Vector for current traffic including a Flow Section for an entry and
a Flow Section for an exit
12 © ISO 2015 – All rights reserved

4. UC4: Flow Matrix with one Flow Vector for current traffic including two exit Flow Sections leaving the
road at the same position, differentiated by the ‘angle’ attribute (datastructure ‘Restrictions’, see 7.4)
5. UC5: Flow Matrix with one Flow Vector for current traffic including two Flow Sections with lane
restrictions (datastructure ‘Restrictions’, see 7.4); other restrictions may be used in the same way
6. UC6: Flow Matrix one Flow Vector for current traffic and with 4 Flow Sections along the road stretch; the
beginning of sections 1, 3 and 4 are defined by absolute offsets in TMC-extents, the beginning of section
2 is defined by a relative metric offset to the TMC location determining the beginning of section 3.
6.9 FlowVector
A ‘FlowVector’ includes traffic flow status information for the road stretch covered by the surrounding
Flow Matrix, but only for a dedicated time interval. The ‘FlowVector’ consists of a number of
14 © ISO 2015 – All rights reserved

‘FlowVectorSections’ which shall be ordered in the ‘vectorSections’ attribute in downstream direction
i.e. in descending order of the related ‘spatialOffset’ attributes.
Name Type Multiplic- Description
ity
timeOffset IntUnLoMB 1 Temporal offset [min] to the ‘startTime’ of the surrounding
‘FlowMatrix’ object, defining the end of the related time
interval. In case of a current status the beginning of the time
interval is the ‘startTime’ of the related ‘FlowMatrix’ object.
In case of a prognosis the beginning of the time interval is the
end of the previous interval. May be zero for the FlowVector
of the current status if there are no further flow vectors with
forecast data (0 equals to ‘end undefined’).
vectorSections FlowVectorSection 1.* Flow section data; the ‘FlowVectorSections’ objects in this
attribute shall be ordered in driving direction, i.e. the section
with the highest spatial offset first (see also 7.2).
spatialResolutionVector tfp004: 0.1 Resolution of the spatial offset used for
...