ISO 21219-18:2019

INTERNATIONAL ISO
STANDARD 21219-18
First edition
2019-07
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 2019
© ISO 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2019 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Application specific constraints . 3
5.1 Application identification . 3
5.2 Version number signalling . 3
5.3 Ordered components . 3
5.4 Extendibility . 3
5.5 TPEG Service Component Frame. 4
6 TFP structure . 4
7 TFP Message components . 5
7.1 TFPMessage . 5
7.2 TFPMethod . 6
7.3 MMCSwitch . 6
7.4 MessageManagementContainerLink. 6
7.5 MMCMasterLink . 6
7.6 MMCPartLink . 6
7.7 LocationReferencingContainer . 7
7.8 FlowPolygonObject . 8
7.9 FlowPolygon . 9
7.10 FlowStatus .10
7.11 FlowMatrix .11
7.12 FlowVector .16
7.13 SectionExtensionComponent .17
7.14 RestrictionExtensionComponent .17
7.15 StatusExtensionComponent .17
7.16 StatisticsExtensionComponent .17
8 TFP Data Types .17
8.1 General .17
8.2 FlowVectorSection .17
8.3 PolygonPoint .19
8.4 LinkedCause .20
8.5 StatusParameters .20
8.6 Restrictions .21
8.7 StatisticalParameters.22
9 TFP Tables .23
9.1 tfp001: VehicleClass .23
9.2 tfp002: VehicleCredentials .24
9.3 tfp003: LevelOfService .24
9.4 tfp004: SpatialResolution .26
9.5 tfp005:LaneR estriction .26
9.6 tfp006: CauseCode .28
9.7 tfp007: SectionType.31
9.8 tfp008: FlowDataQuality .31
Annex A (normative) Traffic Flow and Prediction, TPEG-Binary Representation .32
Annex B (normative) Traffic Flow and Prediction, TPEG-ML Representation .43
Bibliography .58
iv © ISO 2019 – All rights reserved

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 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 of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso
.org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
This first edition cancels and replaces ISO/TS 21219-18:2015, which has been technically revised.
A list of all parts in the ISO 21219 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
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, in conjunction with ISO/TC 204, established a group
comprising members of the former EBU B/TPEG and this working group continued development work.
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 of 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
When the Traveller Information Services Association (TISA), derived from former forums, was
inaugurated in December 2007, TPEG development was taken over by TISA and continued in the TPEG
applications working group.
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 ISO 21219-2, ISO 21219-3 and ISO 21219-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 2019 – All rights reserved

TPEG2 has a three-container conceptual structure: message management (ISO 21219-6), application
(several parts) and location referencing (ISO/TS 21219-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. Note that the list below may be incomplete, e.g. new TPEG2 parts may be introduced
after publication of this document.
— Toolkit parts: TPEG2-INV (ISO/TS 21219-1), TPEG2-UML (ISO 21219-2), TPEG2-UBCR (ISO 21219-3),
TPEG2-UXCR (ISO 21219-4), TPEG2-SFW (ISO 21219-5), TPEG2-MMC (ISO 21219-6), TPEG2-LRC
(ISO/TS 21219-7).
— Special applications: TPEG2-SNI (ISO/TS 21219-9), TPEG2-CAI (ISO/TS 21219-10), TPEG2-LTE
(ISO/TS 21219-24).
— Location referencing: TPEG2-OLR (ISO/TS 21219-22), TPEG2-GLR (ISO/TS 21219-21), TPEG2-TLR
(ISO 17572-2), TPEG2-DLR (ISO 17572-3).
— Applications: TPEG2-PKI (ISO/TS 21219-14), TPEG2-TEC (ISO/TS 21219-15), TPEG2-FPI
(ISO/TS 21219-16), TPEG2-TFP (ISO 21219-18), TPEG2-WEA (ISO/TS 21219-19), TPEG2-RMR
(ISO/TS 21219-23), TPEG2-EMI (ISO/TS 21219-25), TPEG2-VLI (ISO/TS 21219-26).
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 document is based on the TISA specification technical/editorial version reference: SP17001.
INTERNATIONAL STANDARD ISO 21219-18:2019(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 document 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 can also be presented directly to the user by textual, voice and
graphical output devices.
TFP is status oriented, i.e. the transmitted information continuously updates 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:
— provides dynamic navigation systems with up-to-date traffic state information;
— ensures travel safety for the driver;
— enables the calculation of alternative routes;
— avoids delays (e.g. traffic jams);
— lowers traffic load on over-saturated parts of the network;
— keeps the driver informed about current and upcoming traffic;
— compact and efficient coding of the traffic information.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
3.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.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.3
Location Referencing Container
concept applied to the grouping of all the Location Referencing elements, of a TPEG-Message, together
in one place
Note 1 to entry: See ISO/TS 21219-7 for full details of the Location Referencing container.
4 Abbreviated terms
ACID Application and Content Identifier
ADC Application Data Container
AID (TPEG) Application IDentification
CEN Comité Européen de Normalisation
EBU European Broadcasting Union
ITS Intelligent Transport Systems
LRC Location Referencing Container
MMC Message Management Container
OSI Open Systems Interconnection
SFW (TPEG) Service Framework
SID Service and Network Information
SNI Service and Network Information
TISA Traveller Information Services Association
TFP Traffic Flow and Prediction
TMC Traffic Message Channel
TPEG Transport Protocol Expert Group
TTI Traffic and Traveller Information
UML Unified Modelling Language
XML Extensible Markup Language
XSD XML Schema Definition
2 © ISO 2019 – All rights reserved

5 Application specific constraints
5.1 Application identification
The word 'application' is used in the TPEG specifications to describe specific subsets of the TPEG
structure. An application defines a limited vocabulary for a certain type of message, e.g. parking
information or road traffic information. Each TPEG application is assigned a unique number, called the
Application IDentification (AID). An AID is defined whenever a new application is developed. These are
all listed in ISO/TS 21219-1.
The application identification number is used within the TPEG2-SNI application (ISO/TS 21219-9) to
indicate how to process TPEG content and facilitates the routing of information to the appropriate
application decoder.
5.2 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.
The version numbering principle is defined in ISO/TS 21219-1.
Table 1 shows the current version numbers for signaling TFP within the SNI application.
Table 1 — Current version numbers for signalling of TFP
major version number 1
minor version number 1
5.3 Ordered components
TPEG2-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 one or more Application Data Container components, 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 7.1).
Figure 1 — Composition of TPEG messages
5.4 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. This means that a TFP decoder shall be able to detect and skip unknown
components.
5.5 TPEG Service Component Frame
TPEG2 TFP makes use of the “Service Component Frame with dataCRC, groupPriority, and
messageCount” according to ISO 21219-5.
6 TFP structure
Figure 2 — TFP message structure
4 © ISO 2019 – All rights reserved

7 TFP Message components
7.1 TFPMessage
A 'TFPMessage' component is the top container of a TFP message. It contains all information about a
particular part of the network, e.g. 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 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 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', 7.8).
— FlowStatus-Method: A flow status applied to the overall road stretch defined by the LRC of the
message (see description of component 'FlowStatus', 7.10). 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', 7.11). 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 8.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 7.11).
The attributes of the 'TFPMessage' component are listed hereunder:
Table 2 — TFPMessage
Name Type Multiplicity Description
Ordered Components
mmc MessageManagementContainer 1 Message Management Container
(external)
method Component TFPMethod 0.* Traffic flow data
loc LocationReferencingContainer 0.1 Location Referencing Container
(external)
7.2 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', FlowStatus' and
FlowMatrix'.
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 'startTime'+'duration'. This attribute shall be
used by the 'PolygonFlowObject' component and may be
used if required otherwise.
7.3 MMCSwitch
The MMCSwitch component is an abstract component, allowing the flexible use of monolithic or multi-
part message management.
7.4 MessageManagementContainerLink
The MessageManagementContainerLink is a placeholder for the MessageManagementContainer as
defined in the MMC-toolkit specification (see ISO 21219-6). It assigns the Traffic Flow and Prediction
application specific local component ID for the MMC container (see Annex A).
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 (see ISO 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.
7.5 MMCMasterLink
The MMCMasterLink is a placeholder for the Master-Message MMC for Multi-part message management,
as defined in the MMC-toolkit specification (see ISO 21219-6). It assigns the Traffic Flow and Prediction
application specific local component ID for the MMC container (see Annex A).
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 (see ISO 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.
7.6 MMCPartLink
The MMCPartLink is a placeholder for the external Partial-Message MMC (MMCMessagePart) for multi-
part message management, as defined in the MMC-toolkit specification (see ISO 21219-6). It assigns
the Traffic Flow and Prediction application specific local component ID for the MMC container (see
Annex A).
6 © ISO 2019 – All rights reserved

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 (see ISO 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.
7.7 LocationReferencingContainer
The LocationReferencingContainer component is a placeholder for the LocationReferencingContainer
(LRC) as described in the LRC toolkit specification defined in ISO/TS 21219-7. It assigns the Traffic Flow
and Prediction (TFP) application specific local component ID for the LRC container (see also Annex A).
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 shall be used if the LRC is not present in a TFP message. 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 Reference Point offsets are used to dedicated points on the road stretch, e.g. Polygon Points (see
description of the Flow-Polygon-Method, see 7.8) or delimiters of road sections (see description of the
Flow-Matrix-Method, see 7.11).
If TMC location referencing (ISO 17572-3) 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, whenever it is feasible to construct an “TMC extent > 0” location reference for the TMC primary
location, i.e. when this primary location has a predecessor TMC location against driving direction in the
TMC location table.
Only in the exceptional case, when for a linear (road segment) location only a “TMC extent 0” location
reference is possible (e.g. typically for P4.0 type link roads), then a TMC extent 0 location reference
is permitted under the following condition. Any first spatial offset in an TMC extent 0 location
reference shall always be assigned a spatial resolution of type ‘tfp004: start -of -location’ (for backward
compatibility reasons).
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
7.8 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
8 © ISO 2019 – All rights reserved

by a vector of 'PolygonPoints'. For reasons of efficiency, these polygon points use the following 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).
— 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'.
Table 3 defines the FlowPolygonObject component.
Table 3 — FlowPolygonObject
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 'startTime'+'duration'. This
attribute shall be used by the 'PolygonFlowObject'
component and may be used if required otherwise.
spatialResolution tfp004: 1 Resolution of the spatial offset used in this structure
SpatialResolution in steps 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. The 'start-of-location' spatial
offset (table entry 7) shall neither be used.
polygons Component 1.* Flow polygon data.
FlowPolygon
7.9 FlowPolygon
A 'FlowPolygon' includes a spatial/temporal area with a consistent traffic flow status.
Table 4 defines the FlowPolygon component.
Table 4 — FlowPolygon
Name Type Multiplicity Description
polygonIndex IntUnLoMB 1 Unique index within related
'FlowPolygonObject'. Used for
ordering the FlowPolygons within
the 'FlowPolygonObject'.
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
SpatialResolution used for this polygon, in 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 'FlowPolygonObject'
component. Relative spatial offsets
(table entries 5 and 6) shall not be used.
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: 0.1 A simple cause for the reported traffic
CauseCode 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)
7.10 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.
Table 5 defines the FlowStatus component.
Table 5 — FlowStatus
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 'startTime'+'duration'.
This attribute shall be used by the
'PolygonFlowObject' component and
may be used if required otherwise.
status StatusParameters 1 Attributes describing the traffic flow status at the
related location.
restriction Restrictions 0.1 Information on restrictions related to the reported
traffic flow.
10 © ISO 2019 – All rights reserved

Table 5 (continued)
Name Type Multiplicity Description
statistics StatisticalParameters 0.1 Statistical information related to the reported
flow status.
cause t f p 0 0 6 : C au s e C o de 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).
7.11 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/60 min 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 relative offsets
to the beginning of the following section may also be used (see use case 6 below).
Figure 5 — Example of a Flow Matrix Object with 4 Flow Vectors (1 for current status, 3 for
prognosis)
Table 6 defines the FlowMatrix component.
Table 6 — FlowMatrix
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 'startTime'+'duration'.
This attribute shall be used by the
'PolygonFlowObject' component and
may be used if required otherwise.
spatialResolution tfp004: 1 Resolution of the spatial offset used in this structure
SpatialResolution in steps 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 attributes
(i.e. 'spatialResolutionVector' in component
'FlowVector' and 'spatialResolutionSection'
in data structure 'FlowVectorSection'). Relative
spatial offsets (table entries 5 and 6) shall not
be used for this attribute. The 'start-of-location'
spat
...