ISO 21219-19:2023

Intelligent transport systems - Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) - Part 19: Weather information (TPEG2-WEA)

This document defines the TPEG Weather (WEA) application for reporting weather information for travellers. It provides general weather-related information to all travellers and is not limited to a specific mode of transportation. This application does not provide specific weather-related safety warnings to drivers; these are provided as safety related messages as part of the TPEG2-TEC application (ISO 21219-15). The WEA application provides weather-related forecasts and status information over multiple time periods and for multiple, possibly linked, geographical areas. NOTE The presentation of the information is dependent on the specific human-machine interface (HMI) of the receiving device. Therefore, this document does not define any prerequisites for the HMI of the device. This document contains examples to help explain how some typical weather reports can be signalled (see Annex C) and suggested translations between WEA table codes and WMO SYNOP weather observation codes (see Annex D).

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 19: Renseignements météorologiques (TPEG2-WEA)

General Information

• Status: Published
• Publication Date: 08-Jun-2023
• ICS: 03.220.01 - Transport in general
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 10 - Traveller information systems
• Current Stage: 6060 - International Standard published
• Start Date: 09-Jun-2023
• Due Date: 04-Sep-2022
• Completion Date: 09-Jun-2023

Relations

• Revises: ISO/TS 21219-19:2016 - Intelligent transport systems - Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) - Part 19: Weather information (TPEG2-WEA)
• Effective Date: 23-Apr-2020

Overview

ISO 21219-19:2023 - TPEG2-WEA defines the TPEG Weather (WEA) application for delivering weather information to travellers as part of Intelligent Transport Systems (ITS). The standard specifies how to encode weather forecasts and status information for multiple time periods and for one or more linked geographic areas. Presentation is left to the receiving device HMI, so the standard focuses on information structure, not visual/audio rendering.

Keywords: ISO 21219-19:2023, TPEG2, TPEG2-WEA, weather information, intelligent transport systems, traffic and travel information.

Key topics and technical requirements

• Message structure and components: Detailed definitions for WeatherMessage, WeatherInformation, WeatherReport, WeatherItem, WeatherStatistics, WeatherWarning and related message links and containers.
• Data types and tables: Normative datatypes and lookup tables (e.g., Period, TrendItem, Direction, Visibility, UVIndex, AirQuality, WarningLevel, ElementType and many element-specific tables for rain, snow, wind, fog, temperature, etc.).
• Representation formats: Normative specifications for both TPEG binary and TPEG-ML encodings (Annex A and Annex B).
• Extendibility and versioning: Rules for application identification, version number signalling, ordered components and extensibility to accommodate future elements.
• Interoperability aids: Worked examples (Annex C) and suggested mappings to WMO SYNOP weather observation codes (Annex D).
• Safety note: WEA provides general traveller weather information; specific weather-related safety warnings for drivers are handled in TPEG2-TEC (ISO 21219-15), not in WEA.

Applications

• Real-time and forecast weather feeds for in-vehicle infotainment, mobile travel apps, public transport displays and traffic management centres.
• Multi-modal traveller services where generalized weather information is needed (road, rail, air, maritime) without prescribing HMI presentation.
• Integration with ITS services (routing, travel time estimation, travel advisories) that consume structured weather elements like wind, visibility, precipitation, UV index and air quality.

Who uses this standard

• ITS solution architects, telematics vendors and broadcast/data service providers implementing TPEG2 services.
• Automotive OEMs and infotainment platform developers integrating standardized weather feeds.
• Traffic and transport authorities, weather data providers and middleware vendors aiming for interoperable TTI (traffic and travel information) services.

Related standards

• ISO 21219 series (TPEG2 family) - other parts cover technical events and safety (e.g., ISO 21219-15 TPEG2-TEC for safety-related messages).
• WMO SYNOP mapping guidance (referenced in Annex D for interoperability with meteorological observation codes).

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 21219-19
First edition
2023-06
Intelligent transport systems —
Traffic and travel information (TTI)
via transport protocol experts group,
generation 2 (TPEG2) —
Part 19:
Weather information (TPEG2-WEA)
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 19: Renseignements météorologiques (TPEG2-WEA)
Reference number
© ISO 2023
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: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
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 . .2
5.1 Application identification . 2
5.2 Version number signalling . 2
5.3 Ordered components . . 2
5.4 Extendibility . 3
5.5 TPEG service component frame . 3
6 WEA structure . 3
7 WEA message components . 4
7.1 General . 4
7.2 WeatherMessage . 5
7.3 WeatherInformation . 6
7.4 WeatherReport . 7
7.5 WeatherItem . 7
7.6 WeatherStatistics . 8
7.7 WeatherWarning . 10
7.8 AltitudeElements . 10
7.9 OutlookTrend . 10
7.10 ReportLinkInfo . . 11
7.11 WebContentLinks . 11
7.12 MMCSwitch . 11
7.13 MMCMessagePartLink . 11
7.14 MMCMasterMessageLink .12
7.15 MessageManagementContainerLink .12
7.16 LocationReferencingContainerLink .12
8 WEA datatypes .12
8.1 LinkedMessage .12
8.2 Element . 13
9 WEA tables .13
9.1 wea000:ReportType . 13
9.2 wea001:Period . 13
9.3 wea002:TrendItem . 15
9.4 wea003:Direction . 16
9.5 wea004:PressureTendency . 16
9.6 wea005:Visibility . 17
9.7 wea006:SeaState . 17
9.8 wea007:PollenCount . 17
9.9 wea008:AirQuality . 18
9.10 wea009:WarningLevel . 18
9.11 wea010:UVIndex . 19
9.12 wea011:GeoSignificance . 19
9.13 wea012:WindDirectionTrend . 20
9.14 wea013:WindSpeedTrend . .20
9.15 wea014:ContentType . 20
9.16 wea099:ElementSubTable.20
9.17 wea100:ElementType . 21
iii
9.18 wea101:RainElements . . 21
9.19 wea102:SnowElements . 22
9.20 wea103:SleetHailElements . 22
9.21 wea104:WindElements .22
9.22 wea105:StormElements . 23
9.23 wea106:FogElements . 24
9.24 wea107:FrostElements .25
9.25 wea108:SunshineCloudElements . 25
9.26 wea109:TemperatureElements . 25
9.27 wea110:HazardElements . .26
9.28 wea200:ElementQualifier .26
9.29 wea201:ElementQualifierProbability .28
Annex A (normative) TPEG application, TPEG-binary representation .29
Annex B (normative) TPEG application, TPEG-ML representation .38
Annex C (informative) Worked examples .49
Annex D (informative) Suggested translation between WEA table codes and WMO SYNOP
weather observation codes .54
Bibliography .61
iv
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 the first edition (ISO/TS 21219-19:2016), which has been
technically revised.
The main changes are as follows:
— the document has been changed from a Technical Specification to an International Standard;
— a NOTE and one new WeatherStatistics value have been added in Table 6.
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.
v
Introduction
0.1  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 can 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, later 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, later 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, later 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 18234 series to provide location referencing.
The ISO 18234 series has become known as TPEG Generation 1.
0.2  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 the 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 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).
TPEG2 is embodied in the ISO 21219 series and it comprises many parts that cover an 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 (see Annex A) and XML (see Annex B); others can
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; this file forms the annex for each
physical format.
vi
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 is potentially incomplete, as there is the possibility that new
TPEG2 parts will be introduced after the publication of this document.
— Toolkit parts: TPEG2-INV (ISO 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 21219-9), TPEG2-CAI (ISO 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 21219-14), TPEG2-TEC (ISO 21219-15), TPEG2-FPI (ISO 21219-16),
TPEG2-SPI (ISO 21219-17), TPEG2-TFP (ISO 21219-18), TPEG2-WEA (ISO 21219-19 - this document),
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 with 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:
SP20014/1.2/001.
vii
INTERNATIONAL STANDARD ISO 21219-19:2023(E)
Intelligent transport systems — Traffic and travel
information (TTI) via transport protocol experts group,
generation 2 (TPEG2) —
Part 19:
Weather information (TPEG2-WEA)
1 Scope
This document defines the TPEG Weather (WEA) application for reporting weather information for
travellers. It provides general weather-related information to all travellers and is not limited to a
specific mode of transportation.
This application does not provide specific weather-related safety warnings to drivers; these are
provided as safety related messages as part of the TPEG2-TEC application (ISO 21219-15).
The WEA application provides weather-related forecasts and status information over multiple time
periods and for multiple, possibly linked, geographical areas.
NOTE The presentation of the information is dependent on the specific human-machine interface (HMI) of
the receiving device. Therefore, this document does not define any prerequisites for the HMI of the device.
This document contains examples to help explain how some typical weather reports can be signalled
(see Annex C) and suggested translations between WEA table codes and WMO SYNOP weather
observation codes (see Annex D).
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 21219-1, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 1: Introduction, numbering and versions (TPEG2-INV)
ISO 21219-9, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 9: Service and network information (TPEG2-SNI)
ISO 21219-14, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 14: Parking information (TPEG2-PKI)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 21219-9 and ISO 21219-14
apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
4 Abbreviated terms
For the purposes of this document, the abbreviated terms given in ISO 21219-1, ISO 21219-9,
ISO 21219-14 and the following apply.
AQI air quality index
HMI human-machine interface
RF radio frequency
SYNOP surface synoptic observations
UV ultraviolet
UVI UV Index
WHO World Health Organization
WMO World Meteorological Organization
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 messages, for example,
parking information or road traffic information. Each TPEG application is assigned a unique number,
called the application identity (AID). An AID number is defined in ISO 21219-1 whenever a new
application is developed.
The AID number is used within the TPEG2-SNI application (ISO 21219-9) to indicate how to process
TPEG content. It 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 can have an impact on client devices.
The version numbering principle is defined in ISO 21219-1.
Table 1 shows the current version numbers for signalling WEA within the SNI application.
Table 1 — Current version numbers for signalling of WEA
Major version number 1
Minor version number 2
5.3 Ordered components
TPEG2-WEA requires a fixed order of TPEG components. The order for the WEA message component
is shown in Figure 1. The first component shall be the MMC. This shall be the only component if the
message is a cancellation message. Otherwise, the MMC component shall be followed by the one or more
ADC component(s) which includes the application-specific information.
Figure 1 — Composition of TPEG messages
5.4 Extendibility
The requirement of a fixed component order does not affect the extension of WEA. Future application
extensions may insert new components or may replace existing components by new ones without
losing backward compatibility. That means a WEA decoder shall be able to detect and skip unknown
components.
5.5 TPEG service component frame
WEA makes use of the “service component frame with dataCRC and messageCount” according to
TPEG2-SFW specified by ISO 21219-5.
6 WEA structure
WEA message structure is shown in Figure 2. The binary format and XML format of the TPEG2-WEA
application for use in transmission shall be in accordance with Annexes A and B, respectively.
Figure 2 — WEA message structure
7 WEA message components
7.1 General
The WEA application provides a flexible message interface for distribution of weather information.
To enable multiple levels of detail to be signalled, WEA provides two different hierarchal structures to
allow messages to cover multiple geographical areas and also to cover different time periods. Messages
may be linked to each other to provide a geographical hierarchy of the weather reports which can be
exploited by receivers to help users find the messages they need.
EXAMPLE A UK service can provide a national overview, with regional reports and individual city reports.
Individual messages are linked by child and parent message IDs by linking individual messages in a
child/parent relationship. A message can only have 1 parent but can have multiple child messages, as
shown in Figure 3.
Key
1 Birmingham
2 London
3 South East England
Figure 3 — Location hierarchy
7.2 WeatherMessage
Each WEA message is associated with a single location and contains one or more weather reports
(excluding the case of a cancellation). The structure of a WeatherMessage is presented in Figure 4, and
the encoding of a WeatherMessage is shown in Table 2.
Figure 4 — Sample WEA message with different timescales covered
Table 2 — WeatherMessage
Name Type Multiplic- Description
ity
Ordered components
mmt MMCSwitch 1 MMC
weatherInfo WeatherInformation 0.1 Weather information (always included
except for cancellation of a message).
loc LocationReferencingContainerLink 0.1 LRC (always included except for cancella-
tion of a message).
7.3 WeatherInformation
A weather report can be either a simple single level report or can be made into a hierarchy of reports
associated to increasingly smaller time periods. The encoding of WeatherInformation is shown in
Table 3.
Table 3 — WeatherInformation
Name Type Multiplicity Description
geographicalSignifi- wea011: GeoSignificance 1 Defines the geographical significance or
cance “spatial extent” of the report.
Ordered components
TTaabblle 3 e 3 ((ccoonnttiinnueuedd))
Name Type Multiplicity Description
weatherReport WeatherReport 1 Contains the report data, defines what type
of period it covers and gives additional,
more detailed reports for smaller time peri-
ods if required.
reportLinks ReportLinkInfo 0.* Links to related WEA reports or other TPEG
messages.
webContent WebContentLinks 0.* Allows linkage to web-based content.
7.4 WeatherReport
The WeatherReport component provides the top level WeatherItem of the report and allows subsequent
lower levels to be defined. A multiple level hierarchy of time periods may be defined. Different timescales
are covered within a specific message by use of the different levels of Report (using the reportType).
The encoding of a WeatherReport is shown in Table 4.
Table 4 — WeatherReport
Name Type Multiplicity Description
reportType wea000: ReportType 1 Defines the time “extent” of a report.
Ordered components
weatherDefinition WeatherItem 1 Main details of weather report.
moreDetailedReport WeatherReport 0.* Optional next-level report.
7.5 WeatherItem
The WeatherItem component defines the main content for the weatherReport, including descriptive
and statistical parts. The encoding of a WeatherItem is shown in Table 5.
Table 5 — WeatherItem
Name Type Multiplicity Description
period we a 0 01: Per io d 0.* This provides an optional period for the
report.
weatherDescription Element 0.* Weather description provides a qualitative
description for the weather report. Any
number of elements can be selected from the
element tables.
start TimePoint 0.1 Start defines the specific time of day at
which the period of this weather report item
begins.
Typically, hours and minutes.
If Stop is not defined, then Start is used to
define a nominal time of the report. For
example: 2 pm sunny; 4 pm rain; 6 pm
showers, sunny intervals.
stop TimePoint 0.1 Stop defines the explicit end time of the peri-
od for the weather item.
date TimePoint 0.1 This provides the ability to report the main
date for a report (suitable for a daily fore-
cast).
Typically, date or date and month.
TTaabblle 5 e 5 ((ccoonnttiinnueuedd))
Name Type Multiplicity Description
reportName LocalisedShort- 0.* Title for the WEA report
String e.g. “Warwickshire Forecast”, “UK Weather”
Multiplicity allows multiple languages to be
carried.
reportText LocalisedLongString 0.* Additional text for weather related informa-
tion.
Can be advice or description of major
weather problem or can be specific infor-
mation related to weather at a specific
function/event. (For example: for the Lon-
don Marathon, “Due to high temperatures,
ensure you drink plenty of liquid if you are
running today.”)
Multiplicity allows multiple languages to be
carried.
Ordered components
outlook OutlookTrend 0.1 Outlook trend provides a description of how
the weather is expected to develop over a
following period.
statistics WeatherStatistics 0.1 Weather statistics are provided as required
to provide quantitative details for the
weather report.
warning WeatherWarning 0.* Warnings for specific weather.
weatherAltitudeDescription AltitudeElements 0.* Weather description provides a qualitative
description for the weather report. Any
number of elements may be selected from
the element tables.
7.6 WeatherStatistics
Statistics are provided to give a quantitative description of the weather status or forecast. The encoding
of the WeatherStatistics is shown in Table 6.
Table 6 — WeatherStatistics
Name Type Multiplicity Description
airQuality wea008: AirQuality 0.1 Air quality.
cloudCover IntUnTi 0.1 Cloud cover.
An okta is a measurement used to describe
cloud cover. Sky conditions are estimated
in terms of how many eighths of the sky are
obscured by cloud, ranging from completely
clear, 0 oktas, through to completely
overcast, 8 oktas. Valid range: 0 to 8.
pressure IntUnLi 0.1 Barometric pressure is hPascal (this is
nominally equivalent to mBar, which is still
the preferred unit in practice for weather
forecast, although not actually an SI unit).
pressureTendency wea004: PressureTendency 0.1 How pressure will (or has) change(d).
rainfallRate FixedPointNumber 0.1 Rate of rainfall in mm/h.
rainfallTotal FixedPointNumber 0.1 Total rainfall for defined period in mm.
seaState we a 0 0 6 : S e a St at e 0.1 Description of the size of the waves.
snowDepth FixedPointNumber 0.1 Depth of fallen snow (mm).
TTaabblle 6 e 6 ((ccoonnttiinnueuedd))
Name Type Multiplicity Description
sunshine FixedPointNumber 0.1 Hours of sunshine for defined period (either
recorded in past or expected in future).
temp FixedPointNumber 0.1 General temperature in degrees Celsius (to
define current or expected temperature).
NOTE The FixedPointNumber binary for-
mat does not cover the range of values in
the interval [-0,99, -0,01].
tempMax FixedPointNumber 0.1 Maximum temperature (degrees Celsius)
expected over a defined period (for daily
report type, this is typically maximum tem-
perature expected during daytime.).
NOTE The FixedPointNumber binary for-
mat does not cover the range of values in
the interval [-0,99, -0,01].
tempMin FixedPointNumber 0.1 Minimum temperature (degrees Celsius)
expected over a defined period (for daily
report type this is typically the minimum
temperature expected during nighttime).
NOTE The FixedPointNumber binary for-
mat does not cover the range of values in
the interval [-0,99, -0,01].
visibility wea005: Visibility 0.1 Subjective visibility description.
visibilityDistance FixedPointNumber 0.1 Nominal visibility in km.
feelsLike FixedPointNumber 0.1 "Feels like" defines what the temperature
will be perceived as to a person, due to
wind chill or humidity; temperature “that
it feels like” on exposed skin, due to wind/
humidity (Celsius).
NOTE The FixedPointNumber binary for-
mat does not cover the range of values in
the interval [-0,99, -0,01].
windDirection we a 0 03: D i r e c t ion 0.1 Wind direction based on cardinal, ordinal
and sub-ordinal directions of the compass.
windDirectionTrend we a 012: W i nd D i r e c t ionTr end 0.1 How the direction of the wind is changing.
windSpeed Velocity 0.1 Wind speed (m/s).
windSpeedTrend we a 013: W i nd Sp e e d Tr end 0.1 Defines how wind speed is changing.
cloudbase DistanceMetres 0.1 Height of base of lowest clouds above the
ground.
relativeHumidity FixedPercentage 0.1 Relative humidity; amount of water vapour
in the air.
dewPointTemp FixedPointNumber 0.1 The temperature to which a given body of
air must be cooled for it to condense (linked
to relative humidity); in degrees Celsius.
NOTE The FixedPointNumber binary for-
mat does not cover the range of values in
the interval [-0,99, -0,01].
uvIndex wea010: UVIndex 0.1 WHO measure of ultraviolet radiation.
sunrise TimePoint 0.1 Time of sunrise.
sunset TimePoint 0.1 Time of sunset.
pollenCount we a 0 07: Pol len C ou nt 0.1 Pollen count.
7.7 WeatherWarning
The WeatherWarning provides highlighted warning about specific types of weather. The encoding of a
WeatherWarning is shown in Table 7.
EXAMPLE “Warning strong wind”.
Table 7 — WeatherWarning
Name Type Multiplicity Description
warningLevel we a 0 0 9: Wa r n i n g L e ve l 1 Warning level.
warningElements Element 1.* Item taken from element tables for which a warn-
ing is provided.
isEarlyWarning Boolean 1 If true, the warning is provided more than 24 h
before expected bad weather period. If false, the
warning is related to time within 24 h of the report
period. This allows “today's” report to include a
warning about “tomorrow's” weather, allowing
users to prepare if needed.
warningText LocalisedLongString 0.* Additional information for warnings.
7.8 AltitudeElements
AltitudeElements allow an altitude to be assigned to an element or set of elements and or statistics. This
allows reporting of altitude-specific weather, such as snow above a certain altitude or temperature at
altitude. The encoding of AltitudeElements is shown in Table 8.
Table 8 — AltitudeElements
Name Type Multiplicity Description
atAltitude DistanceMetres 0.1 Defines that the reported weather elements are found
at this altitude (not to be combined with aboveAlti-
tude or belowAltitude attributes).
aboveAltitude DistanceMetres 0.1 Defines that the reported weather elements are found
above this altitude (e.g. snow above 3 000 m).
belowAltitude DistanceMetres 0.1 Defines that the reported weather elements are found
below this altitude
(e.g. humid below 1 000 m).
altElements Element 0.* Weather elements associated with the defined alti-
tude.
Ordered components
altStatistics WeatherStatistics 0.1 Statistical information associated with the defined
altitude.
7.9 OutlookTrend
This component provides an indication of how the weather will change over a given period. The
encoding of the OutlookTrend is shown in Table 9.
EXAMPLE 1 “Becoming wetter (by midweek)”.
EXAMPLE 2 “Becoming warmer (by later today)”.
EXAMPLE 3 “Becoming cooler (by Thursday)”.
EXAMPLE 4 “Becoming more humid (by this afternoon)”.
Table 9 — OutlookTrend
Name Type Multiplicity Description
trend we a 0 02: Tr end It em 1.5 How the weather is expected to progress.
trendTimescale we a 0 01: Per io d 0.1 Over what period the trend is defined.
7.10 ReportLinkInfo
Linked messages provide a method of referencing other WEA messages. This is used to provide a
hierarchy of WEA messages based on child or parent locations. The encoding of a ReportLinkInfo is
shown in Table 10.
EXAMPLE A message can have a location representing a region such as “The Midlands”, its parent can be
the “UK”, and several child messages can reference “Warwickshire”, “West Midlands”, “Staffordshire”, etc. See
Figure 3.
Table 10 — ReportLinkInfo
Name Type Multiplicity Description
parentMessage LinkedMessage 0.1 Link to parent message.
childMessage LinkedMessage 0.* Link to child message.
relatedMessage LinkedMessage 0.* Link to message related to this weather report, anoth-
er WEA report or a completely different TPEG applica-
tion; for example, reference to TEC message detailing
a bridge closure due to high winds or flooding.
7.11 WebContentLinks
The WebContentLinks allow linkage to web-based content, such as weather maps, plots, rain radar, cloud
or temperature maps. The type of data may be defined by ContentType. Additional title descriptions
may be signalled using text. The encoding of WebContentLinks is shown in Table 11.
Table 11 — WebContentLinks
Name Type Multiplicity Description
url ShortString 1 URL of online data content.
contentType wea014: ContentType 0.1 Type of content; may be used to set icon in HMI for
link.
contentText LocalisedShortString 0.* Used to add additional information relating to the
link if required. Also, if ContentType is not appro-
priate then this can be used to send another short
description of data type.
7.12 MMCSwitch
The MMCSwitch is a switch construct for MMC messages.
7.13 MMCMessagePartLink
The MMCMessagePartLink component is a placeholder for the MMCMessagePart component as
specified in TPEG2-MMC (ISO 21219-6). It assigns the traffic event compact (TEC) application specific
local component ID for the MMC container. All component IDs within the MMC container are local to the
MMC toolkit. The MMC contains all and only information related to message management.
Message generation systems shall ensure that the information given in the MMC allows unambiguous
interpretation over the whole time a message is valid. It is particularly important to recognize that
client devices are likely to suffer from non-continuous transmission channels as typically encountered
in broadcast systems suffering intermittent RF performance.
7.14 MMCMasterMessageLink
The MMCMasterMessageLink component is a placeholder for the MMCMasterMessage container as
specified in TPEG2-MMC (ISO 21219-6). It assigns the TEC application specific local component ID for
the MMC container. All component IDs within the MMC container are local to the MMC toolkit. The MMC
contains all and only information related to message management.
Message generation systems shall ensure that the information given in the MMC allows unambiguous
interpretation over the whole time a message is valid. It is particularly important to recognize that
client devices are likely to suffer from non-continuous transmission channels as typically encountered
in broadcast systems suffering int
...