ISO/TS 21219-14:2016

TECHNICAL ISO/TS
SPECIFICATION 21219-14
First edition
2016-06-01
Intelligent transport systems —
Traffic and travel information (TTI)
via transport protocol experts group,
generation 2 (TPEG2) —
Part 14:
Parking information application
(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: Informations relatives aux parcs de stationnement
(TPEG-PKI)
Reference number
©
ISO 2016
© ISO 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2016 – All rights reserved

Contents Page
Foreword .v
Introduction .vii
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 . 3
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 . 6
6.9 Logo . 7
6.10 Contact . 7
6.11 ParkingSpecification . 7
6.12 InformationFor . 8
6.13 SizeRestrictions . 9
6.14 GateInfo . 9
6.15 ParkingForEvent .10
6.16 ToSite .10
6.17 OpeningHours .10
6.18 PricingPayment .11
6.19 PaymentDetails .11
6.20 Facilities .11
6.21 AssociatedService .12
6.22 CurrentCapacity .12
6.23 CurrentCapacityFor .13
6.24 ExpectedCapacity .13
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 .16
7.5 pki005:AvailableFeatures .17
7.6 pki006:EventType .17
7.7 pki007: Reservability .18
7.8 pki008:FacilityType .18
7.9 pki009:SupervisionType .18
7.10 pki010:SecurityType .19
7.11 pki011:AssociatedService .19
7.12 pki012:ParkingStatus .20
7.13 pki013:PaymentMethod .20
7.14 pki014:SiteServed .21
7.15 pki015:GateType .21
7.16 pki016:ContactType .21
7.17 pki017:TransportType .22
7.18 pki018:OpeningHoursType .22
7.19 pki019:TermType .22
7.20 pki020:Advice .23
7.21 pki021:Tendency .23
7.22 pki022:FeeType .23
Annex A (normative) TPEG PKI, TPEG-Binary Representation .25
Annex B (normative) TPEG PKI, tpegML Representation .37
Bibliography .50
iv © ISO 2016 – 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 on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information.
The committee responsible for this document is ISO/TC 204, Intelligent transport systems.
ISO/TS 21219 consists of the following parts, under the general title Intelligent transport systems —
Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2):
— Part 1: Introduction, numbering and versions (TPEG2-INV)
— Part 2: UML modelling rules
— Part 3: UML to binary conversion rules
— Part 4: UML to XML conversion rules
— Part 5: Service framework (TPEG2-SFW)
— Part 6: Message management container (TPEG2-MMC)
— Part 9: Service and network information (TPEG2-SNI)
— Part 10: Conditional access information (TPEG2-CAI)
— Part 14: Parking information (TPEG2-PKI)
— Part 15: Traffic event compact (TPEG2-TEC)
— Part 18: Traffic flow and prediction application (TPEG2-TFP)
— Part 19: Weather information (TPEG2-WEA)
The following parts are under preparation:
— Part 16: Fuel price information and availability application (TPEG2-FPI)
— Part 23: Roads and multi-modal routes application (TPEG2-RMR)
— Part 24: Light encryption (TPEG2-LTE)
— Part 25: Electromobility charging infrastructure (TPEG2-EMI)
The following parts are planned:
— Part 7: Location referencing container
— Part 21: Geographic location referencing
— Part 22: OpenLR location referencing
vi © ISO 2016 – All rights reserved

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 committee 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,
Public Transport Information Application (TPEG-PTI, ISO/TS 18234-5), was developed. The so-called
TPEG-LOC location referencing method, which enabled both map-based TPEG-decoders and non-map-
based ones to deliver either map-based location referencing or human readable text information, was
issued as ISO/TS 18234-6 to be used in association with the other applications parts of the ISO/TS 18234
series to provide location referencing.
The ISO/TS 18234 series has become known as TPEG Generation 1.
TPEG Generation 2
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/TS 21219-2, ISO/TS 21219-3, ISO/TS 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.
TPEG2 has a three container conceptual structure: Message Management (ISO/TS 21219-6), Application
(many 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:
— Toolkit parts: TPEG2-INV (ISO/TS 21219-1), TPEG2-UML (ISO/TS 21219-2), TPEG2-UBCR
(ISO/TS 21219-3), TPEG2-UXCR (ISO/TS 21219-4), TPEG2-SFW (ISO/TS 21219-5), TPEG2-MMC
(ISO/TS 21219-6), TPEG2-LRC (ISO/TS 21219-7), TPEG2-LTE (ISO/TS 21219-24);
— Special applications: TPEG2-SNI (ISO/TS 21219-9), TPEG2-CAI (ISO/TS 21219-10);
— Location referencing: TPEG2-ULR (ISO/TS 21219-11), TPEG2-GLR (ISO/TS 21219-21), TPEG2-OLR
(ISO/TS 21219-22);
— Applications: Applications: TPEG2-PKI (ISO/TS 21219-14), TPEG2-TEC (ISO/TS 21219-15), TPEG2-
FPI (ISO/TS 21219-16), TPEG2-TFP (ISO/TS 21219-18), TPEG2-WEA (ISO/TS 21219-19), TPEG2-
RMR (ISO/TS 21219-23), TPEG2-EMI (ISO/TS 21219-25).
TPEG2 has been developed to be broadly (but not entirely) backward compatible with TPEG1 to assist
in transitions from earlier implementations, while not hindering the TPEG2 innovative approach and
being able to support many new features, such as dealing with applications having both long-term,
unchanging content and highly dynamic content, such as Parking Information.
This Technical Specification is based on the TISA specification technical/editorial version reference:
SP13009/1.1/001.
viii © ISO 2016 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 21219-14:2016(E)
Intelligent transport systems — Traffic and travel
information (TTI) via transport protocol experts group,
generation 2 (TPEG2) —
Part 14:
Parking information application (TPEG2-PKI)
1 Scope
This part of ISO/TS 21219 specifies the TPEG Parking Information application which has been designed
to deliver parking information to a variety of receivers using a number of different channels, foremost
of course are digital broadcasting and Internet technologies. Parking information may 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. Therefore, timely provision of parking information
could help ease traffic congestion. Furthermore, parking information would be valuable for the visitor,
particularly when it could be used to signal where a temporary parking facility is established for a
special occasion.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/TS 21219-1, Intelligent transport systems — Traffic and travel information via transport protocol
experts group, generation 2 (TPEG2) — Part 1: Introduction, numbering and versions (TPEG2-INV)
ISO/TS 21219-3, Intelligent transport systems — Traffic and travel information (TTI) via transport
protocol experts group, generation 2 (TPEG2) — Part 3: UML to binary conversion rules
ISO/TS 21219-4, Intelligent transport systems — Traffic and travel information (TTI) via transport
protocol experts group, generation 2 (TPEG2) — Part 4: UML to XML conversion rules
ISO/TS 21219-6, Intelligent transport systems — Traffic and travel information via transport protocol
experts group, generation 2 (TPEG2) — Part 6: Message management container (TPEG2-MMC)
3 Terms and definitions
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
Note 1 to entry: See TPEG2 MMC documents (ISO/TS 21219-6) for full details of the Message Management
Container explanations.
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 TPEG2 LRC documents (ISO/TS 21219-7) for full details of the Location Referencing container
explanations.
4 Abbreviated terms
ACID Application and Content Identifier
AID Application Identification
CA Conditional Access
CAI Conditional Access Information
CEN Comité Européen de Normalization
CRC Cyclic redundancy check
EBU European Broadcasting Union
ECM Entitlement Control Message
EMM Entitlement Management Message
MMC Message Management Container
n/a not available
SFW TPEG Service Framework: Modelling and Conversion Rules
TISA Traveller Information Services Association
5 Application specific constraints
5.1 Application identification
The word “application” is used in this part of ISO/TS 21219 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 Identification (AID). An AID is defined whenever a new application is developed
and these are all listed in ISO/TS 21219-1.
The application identification number is used within the TPEG-SNI application ISO/TS 21219-9 to
indicate how to process TPEG content and facilitates the routing of information to the appropriate
application decoder.
2 © ISO 2016 – All rights reserved

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/TS 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 1
5.3 Ordered components
TPEG-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 Message Management Container. This shall be the only component if the message is a cancellation
message. Otherwise, the MMC component shall be followed by the one or more Application Data
Container component(s) which includes 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. That 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/TS 21219-6 as follows.
“ServCompFramePrioritisedCountedProtected”
6 PKI Message components
6.1 ParkingMessage
A parking message shall hold one of the MessageManagement components and optionally can 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.
Figure 2 — Structure of the Parking Message
Methods of the TPEG Message Management Container ISO/TS 21219-6 may be used to transmit static
data independently to dynamic data.
NOTE 1 The components have been grouped to easily allow such dynamic updates.
For example, the name and the location of a parking site do not change frequently and thus, these data
can be transmitted less frequently than, say, 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 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 Message Management
Container types.
Unordered Components
parkingLocation ParkingLocation 0.1 As defined in external TPEG2-Location
Referencing specification.
parkingSiteDescription ParkingSiteDescription 0.1 n/a
currentCapacity CurrentCapacity 0.1 n/a
expectedCapacity ExpectedCapacity 0.* n/a
advice Advice 0.* n/a
4 © ISO 2016 – All rights reserved

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.
6 © ISO 2016 – All rights reserved

Table 4 — ParkingInfo
Name Type Multiplicity Description
parkingId ShortString 0.1 This attribute may hold a parking site specific ID
string, allowing linking this site to other referenc-
ing schemes. It shall not contain language specific
descriptions and should preferably not be presented
to the user as a description.
parkingName LocalizedShortString 0.* Name of the parking in various languages.
parkingAddress LocalizedShortString 0.* Address of the parking in language specific formats.
e.g. for German: Frauensteige 2, D-89075 Ulm
parkingOperator LocalizedShortString 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 can further signal who may or may not use the particular site. The number of reserved
spaces can e.g. be encoded as a component with userType “reservation holders”.
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 may be larger than the total number of
available spaces, because there may be overlapping groups. For example, all of the spaces available for a
certain user group, may be also available for a special vehicle type.
8 © ISO 2016 – All rights reserved

Table 8 — InformationFor
Name Type Multiplicity Description
vehicleType pki001:VehicleType 0.1 This attribute indicates the vehicle type the informa-
tion in the component is valid for.
userType pki003:UserType 0.1 This attribute indicates the user type the informa-
tion in the component is valid for.
fuelType pki004:FuelType 0.1 This attribute indicates the fuel type a vehicle must
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 the parking 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
can use the parking site, as shown in Table 9.
Table 9 — SizeRestrictions
Name Type Multiplicity Description
maxLength DistanceCentimetres 0.1 The maximum length in centimetres.
maxHeight DistanceCentimetres 0.1 The maximum height in centimetres.
maxWidth DistanceCentimetres 0.1 The maximum width in centimetres.
maxWeight Weight 0.1 The maximum weight in kilogrammes.
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 LocalizedShortString 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
centimetres.
gateHeight DistanceCentimetres 0.1 The minimum height of the gate, specified in
centimetres.
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 above mentioned
direction.
Table 10 (continued)
Name Type Multiplicity Description
street LocalizedShortString 0.* The language specific names of a street next
to the gate. Only one street shall be named, al-
though it can 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 can 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 indication of what kind of event the
parking is for.
eventDescription LocalizedShortString 0.* A language-specific name or description can be
included to further specify the related event.
siteType pki014:SiteServed 0.1 The type of the site for which this parking facility
serves can be given.
siteName LocalizedShortString 0.* A language-specific name or description can 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 can 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.
travel time IntUnLi 0.1 Duration in minutes it takes to the related
facility using the indicated transportation.
directionTo typ006:OrientationType 0.1 The direction to the related facility.
transportationType pki017:TransportType 0.1 The means of transportation for which the
information in this component is valid.
6.17 OpeningHours
Times that the parking facility is open with respect to vehicle and user type, as shown in Table 13.
10 © ISO 2016 – All rights reserved

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 can be paid.
acceptedBrand ShortString 0.* Brands, products and company names that are
accepted for the specified method of payment.
benefitInfo LocalizedLongString 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 can be encoded in the attributes of one Facilities component at the same time, if they,
for example, have identical hours of operation.
Table 16 — Facilities
Name Type Multiplicity Description
availableFeatures pki005:AvailableFeatures 0.* Features that are present at the parking
facility can 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
...