ISO 21219-14:2023

Intelligent transport systems — Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) — Part 14: Parking information (TPEG2-PKI)

This document specifies the TPEG parking information (PKI) application which has been designed to deliver parking information to a variety of receivers using a number of different channels, particularly digital broadcasting and internet technologies. Parking information can be presented to the user in many different ways, including text, voice or graphics. Today, traffic congestion has become a serious problem in urban areas. Some traffic congestion is attributed to drivers searching for parking spaces. Timely provision of parking information can help to ease traffic congestion. Furthermore, parking information is valuable for visitors, particularly when it can be used to signal where a temporary parking facility is established for a special event.

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 14: Information de parking (TPEG2- PKI)

General Information

• Status: Published
• Publication Date: 23-May-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: 24-May-2023
• Due Date: 31-Oct-2022
• Completion Date: 24-May-2023

Relations

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

Overview

ISO 21219-14:2023 - "Intelligent transport systems - Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) - Part 14: Parking information (TPEG2‑PKI)" specifies a standardized application for delivering parking information to a wide range of receivers over multiple channels (notably digital broadcasting and Internet technologies). The standard defines how parking data (text, voice or graphics) is structured, updated and encoded so service providers, navigation systems and consumer apps can present consistent, timely parking guidance that helps reduce urban congestion and support event parking.

Key technical topics and requirements

• TPEG2 application constraints and signalling
  • Application identification, version number signalling, ordered components and extension rules for reliable TPEG2 use.
• TPEG service component framing
  • Rules for embedding parking information within TPEG2 service component frames.
• PKI message components
  • Defined message elements include ParkingMessage, ParkingLocation, ParkingSiteDescription, ParkingInfo, Logo, Contact, ParkingSpecification, GateInfo, OpeningHours, PricingPayment, PaymentDetails, Facilities, CurrentCapacity, ExpectedCapacity, Advice and related container/link constructs.
• Data elements for dynamic and static attributes
  • Support for static details (site description, facilities, opening hours, payment methods) and dynamic updates (current capacity, expected capacity, status, tendencies).
• Taxonomies and code tables
  • PKI tables (vehicle types, parking types, user types, fuel type, available features, reservability, facility/security types, payment methods, parking status, etc.) provide standardized vocabularies for interoperable decoding.
• Representations
  • Normative binary representation (TPEG‑binary) and tpegML representations are specified (see Annex A and B).
• Extensibility and updates
  • Mechanisms for linking message management containers and parts to support partial updates and event‑driven changes (e.g., temporary event parking).

Applications and practical value

• Navigation and in‑vehicle systems: supply location, availability and routing to nearest suitable parking, displayed as text, voice prompts or map graphics.
• Traffic management and congestion relief: timely parking availability reduces cruising traffic and emissions in urban centers.
• Parking operators and municipalities: publish unified feeds for site profiles, pricing, opening hours, gate info and dynamic occupancy.
• Mobile apps and third‑party service providers: integrate standardized TPEG2‑PKI feeds to offer multi‑source parking search, booking and payment guidance.
• Event organizers: signal temporary facilities and special event parking conditions to visitors.

Who should use this standard

• ITS implementers, TTI service providers and broadcasters
• Automotive OEMs and navigation-platform vendors
• Parking operators, municipal transport planners and smart city solution integrators
• App developers and data aggregators offering parking search, reservation or payment services

Related elements and SEO keywords

Relevant items referenced in the standard include TPEG2, TPEG‑binary, tpegML, PKI message components and PKI code tables. Use keywords such as ISO 21219-14:2023, TPEG2 parking information, intelligent transport systems, parking availability data, traffic and travel information (TTI), parking guidance and smart parking integration when searching for or implementing this standard.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 21219-14
First edition
2023-05
Intelligent transport systems —
Traffic and travel information (TTI)
via transport protocol experts group,
generation 2 (TPEG2) —
Part 14:
Parking information (TPEG2-PKI)
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 14: Information de parking (TPEG2- PKI)
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 . . 3
5.4 Extensions . 3
5.5 TPEG service component frame . 3
6 PKI message components . 3
6.1 ParkingMessage . 3
6.2 MMCSwitch . 5
6.3 MessageManagementContainerLink . 5
6.4 MMCMasterLink . 5
6.5 MMCPartLink . 5
6.6 ParkingLocation . 5
6.7 ParkingSiteDescription . 5
6.8 ParkingInfo . 7
6.9 Logo . 7
6.10 Contact . 7
6.11 ParkingSpecification . 8
6.12 InformationFor . 9
6.13 SizeRestrictions . 9
6.14 GateInfo . 9
6.15 ParkingForEvent . 10
6.16 ToSite . 10
6.17 OpeningHours . 11
6.18 PricingPayment. 11
6.19 PaymentDetails . 11
6.20 Facilities .12
6.21 AssociatedService .12
6.22 CurrentCapacity .12
6.23 CurrentCapacityFor . 13
6.24 ExpectedCapacity . 14
6.25 ExpectedCapacityFor . 14
6.26 Advice . 14
7 PKI tables .14
7.1 pki001:VehicleType . 14
7.2 pki002:ParkingType . .15
7.3 pki003:UserType . 16
7.4 pki004:FuelType . 17
7.5 pki005:AvailableFeatures . 17
7.6 pki006:EventType . 18
7.7 pki007: Reservability. 18
7.8 pki008:FacilityType . 18
7.9 pki009:SupervisionType . 19
7.10 pki010:SecurityType . 19
7.11 pki011:AssociatedService .20
7.12 pki012:ParkingStatus .20
iii
7.13 pki013:PaymentMethod . 20
7.14 pki014:SiteServed . 21
7.15 pki015:GateType . 21
7.16 pki016:ContactType . 22
7.17 pki017:TransportType .22
7.18 pki018:OpeningHoursType . 23
7.19 pki019:TermType . 23
7.20 pki020:Advice . .23
7.21 pki021:Tendency . 24
7.22 pki022:FeeType . 24
Annex A (normative) TPEG PKI, TPEG-binary representation .26
Annex B (normative) TPEG PKI, tpegML representation .38
Bibliography .51
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-14:2016), which has been
technically revised.
The main changes are as follows:
— four new Feetypes values have been added in Table 44;
— the document has been changed from a Technical Specification to an International Standard;
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 - this document), 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),
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:
SP20009-TPEG2-PKI_1.2/001.
vii
INTERNATIONAL STANDARD ISO 21219-14:2023(E)
Intelligent transport systems — Traffic and travel
information (TTI) via transport protocol experts group,
generation 2 (TPEG2) —
Part 14:
Parking information (TPEG2-PKI)
1 Scope
This document specifies the TPEG parking information (PKI) application which has been designed to
deliver parking information to a variety of receivers using a number of different channels, particularly
digital broadcasting and internet technologies. Parking information can be presented to the user in
many different ways, including text, voice or graphics.
Today, traffic congestion has become a serious problem in urban areas. Some traffic congestion is
attributed to drivers searching for parking spaces. Timely provision of parking information can help to
ease traffic congestion. Furthermore, parking information is valuable for visitors, particularly when it
can be used to signal where a temporary parking facility is established for a special event.
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-10, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 10: Conditional access information (TPEG2-CAI)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 21219-9 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/
3.1
location referencing
LR
means of providing 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.2
location referencing container
LRC
concept applied to the grouping of all the location referencing (3.1) elements of a TPEG-Message together
in one place
Note 1 to entry: See TPEG2 LRC documents (e.g. ISO 21219-7) for full LRC explanations.
3.3
message management container
MMC
concept applied to the grouping of all message elements including message management information of
a TPEG-Message together in one place
Note 1 to entry: See TPEG2 MMC documents (e.g. ISO 21219-6) for full MMC explanations.
4 Abbreviated terms
For the purposes of this document, the abbreviated terms listed in ISO 21219-1, ISO 21219-9,
ISO 21219-10 and the following apply.
ACID application and content identifier
CA conditional access
LGV large goods vehicle
RFID radio frequency identification
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 PKI within the SNI application.
Table 1 — Current version numbers for signalling of PKI
Major version number 1
Minor version number 2
5.3 Ordered components
PKI does not generally require a fixed order of TPEG components, except where explicitly modelled.
The order for the PKI message components 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 include(s) the application-
specific information.
Figure 1 — Composition of TPEG messages
5.4 Extensions
Future application extensions may insert new components or may replace existing components by new
ones without losing backward compatibility. This means that a PKI decoder shall be able to detect and
skip unknown components.
5.5 TPEG service component frame
PKI makes use of the “service component frame with dataCRC and messageCount and priority”
according to ISO 21219-5.
6 PKI message components
6.1 ParkingMessage
A parking message shall hold one of the MessageManagement components and optionally may have
one ParkingLocation, one ParkingSiteDescription and multiple Advice components, as well as one
CurrentCapacity and multiple ExpectedCapacity components, as illustrated in Figure 2 and Table 2.
The binary format and XML format of the TPEG2-PKI application for use in transmission shall be in
accordance with Annexes A and B, respectively.
Figure 2 — Structure of the parking message
TPEG-MMC (ISO 21219-6) methods may be used to transmit static data independently to dynamic data.
NOTE 1 The components have been grouped to facilitate such dynamic updates.
For example, the name and the location of a parking site do not change frequently and thus, these data
may be transmitted less frequently than, for example, the number of available spaces. It is important
nonetheless, that the basic information required to display a sensible message to the user should be sent
in suitable intervals to allow receivers just switched on to decode and display data within a reasonable
time.
Clients should decode messages with the same version number (and PartID in case of partial messages)
only once.
Table 2 — Parking message
Name Type Multiplicity Description
Ordered components
mmt MMCSwitch 1 Includes one of the MMC types.
Unordered components
parkingLocation ParkingLocation 0.1 see ISO/TS 21219-7.
parkingSiteDescription ParkingSiteDescription 0.1 n/a
currentCapacity CurrentCapacity 0.1 n/a
expectedCapacity ExpectedCapacity 0.* n/a
advice Advice 0.* n/a
6.2 MMCSwitch
The MMCSwitch is an abstract container that allows the use of the different message management
options.
6.3 MessageManagementContainerLink
The MessageManagementContainerLink serves as a link to the message management container.
6.4 MMCMasterLink
The MMCMasterLink serves as a link to the message management container.
6.5 MMCPartLink
The MMCPartLink serves as a link to the message management container.
6.6 ParkingLocation
The ParkingLocation serves as a link to the LocationReferenceContainer.
6.7 ParkingSiteDescription
The ParkingSiteDescription component is a wrapper for largely static information about a parking
facility. The information is grouped in the ParkingName, ParkingSpecification, OpeningHours,
PricingPayment, Facilities, ParkingForEvent and AssociatedService components; see Figure 3 and
Table 3.
Figure 3 — Structure of parking site description
Table 3 — ParkingSiteDescription
Name Type Multiplicity Description
Unordered components
parkingInfo ParkingInfo 0.1 n/a
parkingSpecification ParkingSpecification 0.1 n/a
parkingForEvent ParkingForEvent 0.* n/a
openingHours OpeningHours 0.* n/a
pricingPayment PricingPayment 0.* n/a
facilities Facilities 0.* n/a
associatedService AssociatedService 0.* n/a
6.8 ParkingInfo
The ParkingInfo component contains address and contact information about a parking facility to be
displayed to the user. This includes name, address, operator, logo and the contact details for the parking
facility, as shown in Table 4.
Table 4 — ParkingInfo
Name Type Multiplicity Description
parkingId ShortString 0.1 This attribute may hold a parking-site-specific ID
string, allowing linking of this site to other refer-
encing schemes. It shall not contain language-spe-
cific descriptions and should preferably not be
presented to the user as a description.
parkingName LocalisedShortString 0.* Name of the parking site in various languages.
parkingAddress LocalisedShortString 0.* Address of the parking site in language-specific
formats.
e.g. for German: Frauensteige 2, D-89075 Ulm
parkingOperator LocalisedShortString 0.* Language-specific strings representing the name
and/or company of the operator.
Unordered components
logo Logo 0.1 n/a
contact Contact 0.* n/a
6.9 Logo
The logo component provides a URI and a mimeType for a company or parking site logo type. It does not
contain the image data itself, as shown in Table 5.
Table 5 — Logo
Name Type Multiplicity Description
mimeType ShortString 1 The mime type of the image at the provided source.
Src ShortString 1 URI where the logo can be retrieved.
6.10 Contact
This component provides contact information, as shown in Table 6.
Table 6 — Contact
Name Type Multiplicity Description
contactType pki016: ContactType 1 Indicates the type of the information in the contact-
Info attribute.
contactInfo ShortString 1 The actual contact information of the type indicated
in the contactType attribute.
6.11 ParkingSpecification
The ParkingSpecification component (see Figure 4 and Table 7) contains detailed and largely static
information about a parking facility describing properties of the parking site. This includes the type of
parking and the maximum capacity among other information.
Figure 4 — Structure of parking specification
Table 7 — ParkingSpecification
Name Type Multiplicity Description
parkingType pki002: ParkingType 1 Indicates the overall type for the parking facility.
parkingTerm pki019: TermType 0.1 Classifies the site with respect to the maximum al-
lowed parking time or pricing schema. For example,
short-term parking sites are usually very expensive
for long term use. For the rare case that a parking
site offers places for several term types, the parking
site should be represented as one separate “virtual”
parking site for each term type.
parkingCapacity IntUnLi 0.1 Total number of parking spaces in the parking
facility.
reservability pki007: Reservability 0.1 Indicates whether it is possible to reserve places.
Unordered components
informationFor InformationFor 0.* n/a
sizeRestrictions SizeRestrictions 0.1 n/a
gateInfo GateInfo 0.* n/a
6.12 InformationFor
The InformationFor component contains more detailed information for specific vehicle types, user
groups or fuel types, as shown in Table 8. This component allows targeted information to be delivered
to particular groups, such as disabled drivers for example, with regard to the parking duration, the
number of reserved spaces, the maximum number of available spaces and other specific information.
The component may further signal who may or may not use the particular site. The number of reserved
spaces may be encoded as a component with userType “reservation holders” for example.
The numbers contained within this component are a subset of the numbers indicated in the attributes
of the ParkingSpecification component. The sum of the numbers can be larger than the total number of
available spaces, because there can be overlapping groups. For example, all of the spaces available for a
certain user group can be also available for a special vehicle type.
Table 8 — InformationFor
Name Type Multiplicity Description
vehicleType pki001: VehicleType 0.1 This attribute indicates the vehicle type for which
the information in the component is valid.
userType pki003: UserType 0.1 This attribute indicates the user type for which the
information in the component is valid.
fuelType pki004: FuelType 0.1 This attribute indicates the fuel type a vehicle has
to use for the information in this component to be
valid.
validity Boolean 1 If set to true, the following attribute “prohibited”
contains valid information. If set to false, the follow-
ing attribute shall be ignored.
prohibited Boolean 1 If set to true, the usage of this site is prohibited for
groups indicated by the above attributes. If set to
false, the use is explicitly allowed.
parkingTerm pki019: TermType 0.1 Holds information about the term for which the
parking site is available for the indicated group.
parkingCapacity IntUnLi 0.1 Number of spaces available for the indicated group.
6.13 SizeRestrictions
The SizeRestrictions component defines physical limits concerning the maximum size of a vehicle that
may use the parking site, as shown in Table 9.
Table 9 — SizeRestrictions
Name Type Multiplicity Description
maxLength DistanceCentiMetres 0.1 The maximum length in cm.
maxHeight DistanceCentiMetres 0.1 The maximum height in cm.
maxWidth DistanceCentiMetres 0.1 The maximum width in cm.
maxWeight Weight 0.1 The maximum weight in kg.
6.14 GateInfo
GateInfo provides details for individual gates. It can hold a ParkingLocation to accurately identify the
location of the specific gate, as shown in Table 10.
Table 10 — GateInfo
Name Type Multiplicity Description
gateName LocalisedShortString 0.* Language-specific names for the gate to be pre-
sented to the user.
gateType pki015: GateType 0.1 Specifies the type of the gate.
gateWidth DistanceCentiMetres 0.1 The minimum width of the gate, specified in cm.
gateHeight DistanceCentiMetres 0.1 The minimum height of the gate, specified in cm.
directionTo typ006: OrientationType 0.1 Direction to the street listed in the street attrib-
ute. For example, the next street from the gate is
in direction “north”.
distanceTo DistanceMetres 0.1 The distance to the street listed in the street
attribute. For example, the next street from the
gate is 1 500 m away in the abovementioned
direction.
street LocalisedShortString 0.* The language-specific names of a street next
to the gate. Only one street shall be named, al-
though it may be named in various languages.
Unordered components
parkingLocation ParkingLocation 0.1 n/a
6.15 ParkingForEvent
Parking sites sometimes offer places for visitors of major events or famous places, or are at times
even especially set up for a specific event. The type and name of the event may be indicated within
this component. Additional details about the event would be expected to be delivered via other TPEG
applications. A separate component shall be used for each event, as shown in Table 11.
Table 11 — ParkingForEvent
Name Type Multiplicity Description
eventType pki006: EventType 0.1 Allows an indication of what kind of event the
parking is for.
eventDescription LocalisedShortString 0.* A language-specific name or description may be
included to further specify the related event.
siteType pk i 014 : Si t e S er ve d 0.1 The type of the site this parking facility serves may
be given.
siteName LocalisedShortString 0.* A language-specific name or description may be
included to further specify the related site.
Unordered components
contact Contact 0.* n/a
toSite ToSite 0.* n/a
6.16 ToSite
This component provides information on how the related site may be reached, as shown in Table 12.
Table 12 — ToSite
Name Type Multiplicity Description
spatialDistance IntUnLi 0.1 The distance in metres to reach the related
facility.
TTaabblle 1e 12 2 ((ccoonnttiinnueuedd))
Name Type Multiplicity Description
temporalDistance IntUnLi 0.1 Duration in minutes it takes to reach the
related facility using the indicated transpor-
tation.
directionTo typ006: OrientationType 0.1 The direction to the related facility.
transportationType pki017:T ransportType 0.1 The means of transportation for which the
information in this component is valid.
6.17 OpeningHours
Times at which the parking facility is open with respect to vehicle and user type, as shown in Table 13.
Table 13 — OpeningHours
Name Type Multiplicity Description
openingHoursType pki018: OpeningHoursType 1 Defines how the openingHours attribute
has to be interpreted.
openingHoursInfo TimeToolkit 1 The actual timespan encoded using the
TimeToolkit container.
vehicleType pki001: VehicleType 0.1 The vehicle type for which the information
within this component is valid.
userType pki003: UserType 0.1 The information in this component is rele-
vant for these users.
6.18 PricingPayment
The PricingPayment component describes the costs for parking at this parking location, as well as
further payment details, as shown in Table 14.
Table 14 — PricingPayment
Name Type Multiplicity Description
feeType pki022: FeeType 1 Defines what sort of fee is described within this
component.
amount Float 1 The actual amount of the fee, expressed in the cur-
rency specified in the currencyType attribute.
currencyType typ003: CurrencyType 1 The currency in which the amount of the fee is
given.
time TimeToolkit 0.1 Time period for which this pricing information
applies.
vehicleType pki001: VehicleType 0.1 Limits the information to a vehicle type.
userType pki003: UserType 0.1 Limits the information to a user type.
Unordered components
paymentDetails PaymentDetails 0.* n/a
6.19 PaymentDetails
The component PaymentDetails provides additional details on currencies, methods of payment and
benefit information, as shown in Table 15.
Table 15 — PaymentDetails
Name Type Multiplicity Description
currencyType typ003: CurrencyType 0.* Payment is accepted in these currencies.
method pki013: PaymentMethod 0.1 How the fee may be paid.
acceptedBrand ShortString 0.* Brands, products, and company names that are
accepted for the specified method of payment.
benefitInfo LocalisedLongString 0.* Language-specific announcement of a special
benefit.
6.20 Facilities
The component Facilities indicates facilities and features, such as guided parking, which are available
at the parking site and their operating hours, as well as the user type, as shown in Table 16.
Several facilities may be encoded in the attributes of one Facilities component at the same time, if they
have identical hours of operation, for example.
Table 16 — Facilities
Name Type Multiplicity Description
availableFeatures pk i 0 05: Av a i l a bleFe a t u r e s 0.* Features that are present at the parking
facility may be listed here.
parkingGuidanceType pki008: FacilityType 0.1 The information is related to the parking
guidance specified here.
securityType pki010: SecurityType 0.1 The information concerns this security
type.
supervisionType pki009: SupervisionType 0.1 The information is related to this
supervision type.
operationHours TimeToolkit 0.1 This attribute is used to indicate the
operation time for the information
provided in the other attributes of this
component.
userType pki003: UserType 0.1 The facility is relevant for this user type.
6.21 AssociatedService
The component AssociatedService, as shown in Table 17, carries the description of associated services
which are available at the parking site and usually have a name. Simple services that usually do not
have a name may be indicated in the availableFeatures attribute in the Facilities component.
Table 17 — AssociatedService
Name Type Multiplicity Description
serviceType pk i 011: A s s o c i a t e d S er v ic e 1 The type of the associated service.
serviceName LocalisedShortString 0.* Descriptio
...