CEN/TS 16157-6:2022

SLOVENSKI STANDARD
01-september-2022
Nadomešča:
SIST-TS CEN/TS 16157-6:2016
Inteligentni transportni sistemi - Specifikacije za izmenjavo podatkov DATEX II pri
upravljanju prometa in informiranju - 6. del: Objave parkirišč
Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 6: Parking publications
Intelligente Verkehrssysteme - Datex II Datenaustauschspezifikationen für
Verkehrsmanagement und Verkehrsinformationen - Teil 6: Publikation von
Parkinformationen
Systèmes de transport intelligents - Spécifications DATEX II d'échange de données pour
la gestion du trafic et l'information routière - Partie 6: Publication de parking
Ta slovenski standard je istoveten z: CEN/TS 16157-6:2022
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN/TS 16157-6
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
August 2022
TECHNISCHE SPEZIFIKATION
ICS 35.240.60 Supersedes CEN/TS 16157-6:2015
English Version
Intelligent transport systems - DATEX II data exchange
specifications for traffic management and information -
Part 6: Parking publications
Systèmes de transport intelligents - Spécifications Intelligente Verkehrssysteme - DATEX II-
DATEX II d'échange de données pour la gestion du Datenaustauschspezifikationen für
trafic et l'information routière - Partie 6: Publication de Verkehrsmanagement und Verkehrsinformationen -
parking Teil 6: Publikation von Parkinformationen
This Technical Specification (CEN/TS) was approved by CEN on 10 July 2022 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to
submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS
available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in
parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2022 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16157-6:2022 E
worldwide for CEN national Members.

Contents Page
European foreword . 5
Introduction . 6
1 Scope . 7
2 Normative references . 8
3 Terms and definitions . 8
4 Symbols and abbreviations . 9
5 Conformance . 9
6 UML notation . 10
7 «D2Namespace» Parking . 10
7.1 Overview . 10
7.2 The Parking Table Publication model . 11
7.2.1 General structure of the model . 11
7.2.2 «D2Package» ParkingTablePublication . 15
7.2.3 «D2Package» PlaceHierarchy . 17
7.2.4 «D2Package» Place . 17
7.2.5 «D2Package» SubplaceElement . 18
7.2.6 «D2Package» IdentifiedArea . 19
7.2.7 «D2Package» Space . 20
7.2.8 «D2Package» OrganisationRole . 21
7.2.9 «D2Package» CommonComponents . 22
7.2.10 «D2Package» OperatingPattern . 25
7.2.11 «D2Package» Assignment . 26
7.2.12 «D2Package» Access . 28
7.2.13 «D2Package» ParkingRoute . 30
7.2.14 «D2Package» ThresholdConfiguration . 31
7.2.15 «D2Package» JunctionAndRoad . 33
7.3 The Parking Status Publication model . 35
7.3.1 Overview . 35
7.3.2 «D2Package» ParkingStatusPublication. 35
7.3.3 «D2Package» SupplyAndDemand . 36
7.3.4 «D2Package» ParkingStatus . 39
7.3.5 «D2Package» VehicleCountAndRate . 42
Annex A (normative) Data Dictionary for «D2Namespace» Parking . 44
A.1 Overview . 44
A.2 Data Dictionary for "Parking Publications" . 45
A.2.1 "Access" package . 45
A.2.2 "Assignment" package . 48
A.2.3 "CommonComponents" package . 50
A.2.4 "IdentifiedArea" package . 56
A.2.5 "JunctionAndRoad" package . 58
A.2.6 "OperatingPattern" package . 60
A.2.7 "OrganisationRole" package . 63
A.2.8 "ParkingRoute" package . 65
A.2.9 "ParkingStatus" package . 67
A.2.10 "ParkingStatusPublication" package . 74
A.2.11 "ParkingTablePublication" package . 75
A.2.12 "Place" package . 77
A.2.13 "PlaceHierarchy" package . 78
A.2.14 "Space" package . 80
A.2.15 "SubplaceElement" package . 81
A.2.16 "SupplyAndDemand" package . 82
A.2.17 "ThresholdConfiguration" package . 86
A.2.18 "VehicleCountAndRate" package . 88
A.3 Data Dictionary of <> for "Parking Publications" . 92
A.4 Data Dictionary of <> for "Parking Publications" . 92
A.4.1 Introduction. 92
A.4.2 The <> "AccessEquipmentEnum" . 92
A.4.3 The <> "AccessLaneTypeEnum" . 92
A.4.4 The <> "AccessTypeEnum" . 93
A.4.5 The <> "ActivityEnum" . 93
A.4.6 The <> "CalculationTypeEnum" . 93
A.4.7 The <> "CampusStatusEnum" . 94
A.4.8 The <> "ContactTypeEnum" . 94
A.4.9 The <> "CoveredEnum" . 95
A.4.10 The <> "DirectionEnum" . 95
A.4.11 The <> "ElementDescriptorEnum" . 96
A.4.12 The <> "EsporgStandardLevelEnum" . 97
A.4.13 The <> "HierarchyElementTypeEnum" . 97
A.4.14 The <> "JunctionClassificationEnum" . 98
A.4.15 The <> "LayoutEnum" . 99
A.4.16 The <> "OperatingRestrictionsEnum" . 99
A.4.17 The <> "OperationStatusEnum" . 100
A.4.18 The <> "ParkingConditionsEnum" . 100
A.4.19 The <> "ParkingFaultEnum" . 101
A.4.20 The <> "ParkingModeEnum" . 101
A.4.21 The <> "ParkingOccupancyEnum" . 102
A.4.22 The <> "ParkingOccupancyTrendEnum" . 102
A.4.23 The <> "ParkingPlaceStatusEnum" . 103
A.4.24 The <> "ParkingRouteOrientationEnum" . 103
A.4.25 The <> "ParkingRouteTypeEnum" . 103
A.4.26 The <> "ParkingSafetyEnum" . 104
A.4.27 The <> "ParkingSecurityEnum" . 104
A.4.28 The <> "ParkingSpaceConvenienceEnum" . 105
A.4.29 The <> "ParkingSpaceOccupancyDetectionEnum" . 105
A.4.30 The <> "ParkingStructuralCharacteristicsEnum" . 106
A.4.31 The <> "ParkingSupervisionEnum" . 107
A.4.32 The <> "ParkingUsageScenarioEnum". 107
A.4.33 The <> "ParkingVacantSpacesEnum" . 109
A.4.34 The <> "PedestrianAccessTypeEnum" . 109
A.4.35 The <> "PermitTypeEnum" . 110
A.4.36 The <> "PublicTransportTypeEnum" . 110
A.4.37 The <> "PublicTransportVehicleType". 111
A.4.38 The <> "RegulationEnum" . 111
A.4.39 The <> "ReservationTypeEnum" . 112
A.4.40 The <> "RoadTypeEnum" . 112
A.4.41 The <> "SessionActivationModeEnum" . 113
A.4.42 The <> "SpecialLocationEnum" . 114
A.4.43 The <> "StaffEnum" . 115
A.4.44 The <> "StructureGradeEnum" . 115
A.4.45 The <> "StructureTypeEnum" . 115
A.4.46 The <> "SupplyViewTypeEnum" . 115
A.4.47 The <> "TruckParkingDynamicManagementEnum" . 116
Annex B (normative) Referenced XML Schema for «D2Namespace» Parking . 117
B.1 Overview . 117
B.2 Schema for PayloadPublication . 117
B.3 Schema for «D2Namespace» Parking . 119
Annex C (informative) Namespace dependencies . 190
Annex D (informative) Overcrowding and Thresholds . 192
Annex E (informative) Specifying Electric charging and Rates/Tariffs . 194
E.1 Overview . 194
E.2 Electric charging . 194
E.3 Rates / Tariffs . 195
Bibliography . 197

European foreword
This document (CEN/TS 16157-6:2022) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes CEN/TS 16157-6:2015.
EN 16157 series consists several parts under the general title “Intelligent transport systems — DATEX II
data exchange specifications for traffic management and information”. Other parts may be developed in
the future.
In comparison with this previous edition, the specified data model changed significantly due to the
following major modifications:
— Update of the data model to support EN 16157-1:2018 (known as DATEX II, Version 3)
— Integrating the formerly published Level B-Approved extension approach into the core model,
specified by a new namespace "Parking" (see Clause 7).
— Using the core model elements of [4], also known as Alliance for Parking Data Standards (APDS)
model, as base for the new model approach.
EN 16157 series consists of several parts under the general title “Intelligent transport systems — DATEX
II data exchange specifications for traffic management and information”. Other parts may be developed
in the future.
As a user of this document, attention is drawn to the resources of www.datex2.eu. This web site contains
related software tools and software resources that aid the implementation of EN 16157 DATEX II.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN/CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United
Kingdom.
Introduction
This document defines a common set of data exchange specifications to support the vision of a seamless
interoperable exchange of traffic and travel information across boundaries, including national, urban,
interurban, road administrations, infrastructure providers and service providers. Standardisation in this
context is a vital constituent to ensure interoperability, reduction of risk, reduction of the cost base,
promotion of open marketplaces and many social, economic and community benefits to be gained from
more informed travellers, network managers and transport operators.
Delivering European Transport Policy in line with the White Paper issued by the European Commission
requires co-ordination of traffic management and development of seamless pan European services. With
the aim to support sustainable mobility in Europe, the European Commission has been supporting the
development of information exchange mainly between the actors of the road traffic management domain
for a number of years. In the road sector, DATEX II has been long in fruition, with the European
Commission being fundamental to its development through an initial contract and subsequent co-funding
through the Euro-Regional projects. With this standardisation of DATEX II, there is a real basis for
common exchange between the actors of the traffic and travel information sector.
This document includes the framework and context for exchanges, the modelling approach, data content,
data structure and relationships.
This document supports a methodology that is extensible.
The sixth part of the CEN/TS 16157- EN 16157 series (this document) deals with the publication of
parking information. It specifies the structures and definitions of information that may be exchanged to
convey urban parking information or truck parking information.
In normative Annex A, the data dictionary for the «D2Namespace» "Parking" is specified.
In normative Annex B, the referenced XML schema for the «D2Namespace» Parking is specified.
The European Committee for Standardisation (CEN) draws attention to the fact that it is claimed that
compliance with this document may involve the use of a patent concerning procedures, methods and/or
formats given in this document.
CEN takes no position concerning the evidence, validity and scope of patent rights.

1 Scope
This document specifies a publication sub-model supporting the exchange and shared use of data and
information in the field of traffic and travel. It includes the framework and context for exchanges, the
modelling approach, data content, data structure and relationships.
This document is applicable to:
— Traffic and travel information which is of relevance to road networks (non-urban and urban),
— Public transport information that is of direct relevance to the use of a road network (e.g. road link via
train or ferry service),
— Traffic and travel information in the case of Cooperative intelligent transport systems (C-ITS).
This document establishes specifications for data exchange between any two instances of the following
actors:
— Traffic Information Centres (TICs),
— Traffic Control Centres (TCCs),
— Service Providers (SPs),
— Use of this document may be applicable for use by other actors.
This document series covers, at least, the following types of informational content:
— Road traffic event information – planned and unplanned occurrences both on the road network and
in the surrounding environment,
— Operator initiated actions,
— Road traffic measurement data, status data, and travel time data,
— Travel information relevant to road users, including weather and environmental information,
— Road traffic management information and instructions relating to use of the road network.
This part of the CEN/TS 16157 specifies the informational structures, relationships, roles, attributes and
associated data types required for publishing parking information including static content (description
and attribution of parking places and spaces as well as campus information) and dynamic content
(occupancy and vehicle measurement information). It covers urban parking information as well as truck
parking information.
This document specifies a DATEX II Parking namespace, which is part of the DATEX II platform
independent model following EN 16157-1 (published as DATEX II, Version 3.x).
This Part excludes elements that are specified in other parts of the standard series, such as EN 16157-2
(Location referencing), EN 16157-7 (Common data elements) or CEN/TS 16157-12 (Facilities
publications).
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.
EN 16157-1:2018, Intelligent transport systems — DATEX II data exchange specifications for traffic
management and information – Part 1: Context and framework
EN 16157-2:2019, Intelligent transport systems — DATEX II data exchange specifications for traffic
management and information – Part 2: Location referencing
EN 16157-7:2018, Intelligent transport systems — DATEX II data exchange specifications for traffic
management and information – Part 7: Common data elements
CEN/TS 16157-12:2022, Intelligent transport systems — DATEX II data exchange specifications for traffic
management and information – Part 12: Facilities publications
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 16157-1, EN 16157-2,
EN 16157-7 and the following apply.
3.1
campus
large facility (such as a university campus, or an airport), or a large geographic zone (such as a city or a
town), which can contain numerous places that can be logically reported together

3.2
dynamic part [of the parking publications model]
Parking Status Publication model based on a ParkingStatusPublication class
3.3
EU truck parking regulation
short form for the “COMMISSION DELEGATED REGULATION (EU) No 885/2013 of 15 May 2013
supplementing ITS Directive 2010/40/EU of the European Parliament and of the Council with regard to
the provision of information services for safe and secure parking places for trucks and commercial
vehicles” [1]
3.4
hierarchy element general
generalised component of a place hierarchy that forms one element in the tree-like hierarchy
3.5
identifiedArea
identifiable discrete bounded geographic zone that shares common characteristics and is used for
parking and mobility related operations or other purposes
3.6
parking publications model
entirety of the Parking Table Publication model and the Parking Status Publication model
3.7
place
place or location used for parking, loading, unloading, standing, or some other mobility or transport
related activity
3.8
place hierarchy
method to build a hierarchy of place records, in on-street, off-street, and zone environments
Note 1 to entry: Zone environments as specified in this document.
3.9
space
single space for parking or other mobility related purposes, usually designed for one vehicle, which may,
but not necessarily, be denoted by painted or other road surface marker
3.10
static part [of the parking publications model]
Parking Table Publication model based on the ParkingTablePublication class
3.11
subplace element
sub-division of a place for the convenience of the operator to segment the place and identify varied uses
for parking and mobility related operations or other purposes
3.12
truck parking site
urban or interurban parking site which is assigned to trucks
Note 1 to entry: Other vehicles might be allowed as well.
4 Symbols and abbreviations
EU European Union
ITS Intelligent Transport Systems
UML Unified Modeling Language
URL Uniform Resource Locator
VMS Variable Message Sign
5 Conformance
The DATEX II platform independent data model of which the Parking Publications models are a part,
corresponds to the Level A model as defined in EN 16157-1.
Conformance with this Part shall require platform independent models from which platform specific
models are generated to comply with the UML modelling rules defined in EN 16157-1 and with the
following requirements of the models which are expressed in this part.
6 UML notation
The UML notation used in these Technical Specifications shall be as described in ISO/IEC 19505:2012
and in compliance with the methodology specified in EN 16157-1.
In line with normal UML practice, diagrams may be elided for clarity, with some model features described
across multiple Clauses.
7 «D2Namespace» Parking
7.1 Overview
The «D2Namespace» "Parking" may be used to specify parking infrastructure related information, i.e.
information about parking places, spaces, their structure, appearance and equipment and their
capabilities to park vehicles as well as their dynamic status information.
This «D2Namespace» "Parking" shall contain all required or necessary elements to specify truck parking
information in accordance with the EU Truck Parking Regulation (see 3.3) as well. A corresponding
profile is intended to be developed.
The «D2Namespace» "Parking" shall be immediately subordinate to the “PayloadPublication” package
defined in EN 16157-7 and shall comprise
— the «D2Package» "ParkingTablePublication" (see 7.2 " The Parking Table Publication model")
— the «D2Package» "ParkingStatusPublication" (see 7.3 "The Parking Status Publication model")
— and, in addition, the classes, data types and enumerations specific for these payload publications.
The prefix of the namespace shall be "prk".
Some of the packages and individual classes used within the “Parking” namespace reside in the
«D2Namespace» “Common”, defined in EN 16157-7, in «D2Namespace» "LocationReferencing", defined
in EN 16157-2 and in «D2Namespace» "Facilities", defined in CEN/TS 16157-12.
The classes, attributes, data types and enumerations that are specific to the namespace "Parking" are
defined in the normative Annex A. The XML schema corresponding to this namespace is provided in the
normative Annex B.
In informative Annex C, namespace dependencies with other namespaces are explained.
In informative Annex D, details on overcrowding information and threshold configuration are explained.
In informative Annex E, the specification of electric charging in combination with parking and the
specification of rates/tariffs is explained.
7.2 The Parking Table Publication model
7.2.1 General structure of the model
Figure 1 shows the general structure of the static part of the parking model (only some structural relevant
classes and no attributes are shown).

Figure 1 — General structure of the parking model
The specification in this document defines a method to build a hierarchy of place records, in on-street,
off-street, and zone environments. Each instance of a place record corresponds to an instance of a class
within the place hierarchy. This enables a parking or other type of operation to breakdown a place into
discrete parking enclosures or defined areas to better communicate operating hours, space counts,
operating restrictions, location, rights and associated pricing and occupancy information in a consistent
manner.
The hierarchy allows a data distributing party to decide the appropriate level of detail to specify.
The hierarchy supports the ability of lower-level place hierarchy class instances (child records) to inherit
specific instance data from a higher-level place hierarchy class instance (a parent record). The place
hierarchy enables lower-level place hierarchy class instances to document variations in specific
attributes from their parent, higher-level place hierarchy class instance.
Each of the component data concepts is mentioned in this Clause, but further details and descriptions
follow in subsequent Clauses. These component data concepts are: Place (see 7.2.4),
SubplaceElement (see 7.2.5), IdentifiedArea (see 7.2.6), Space (see 7.2.7), Campus,
VehicularAccess and PedestrianAcces (see 7.2.12), EquipmentServiceFacilityArea (see
7.2.6) and SpecificArea (see 7.2.6).
Place is a term introduced in the specification to define where a vehicle may park, stand, rest, or briefly
transit to allow a person to change modes of transport (i.e. taxi drop-off/pickup, ride share drop-
off/pickup, valet stand, etc.). Place in instantiated via the Place class. Place can also be used to define
entry and exit roadways, driveways, and acceleration/deceleration zones for vehicles. Place supports
both on-street and off-street operating environments. Place also defines specific areas to be defined for
mobility or other related uses such as bike storage, e-scooter enclosures, etc. where it is useful to share
operating parameters or assign RightSpecifications, Rates, or other data domains.
A Place is an aggregation of instances of SubplaceElement, IdentifiedArea and Space. In this
specification, the lowest mandatory class instance to define a Place is the IdentifiedArea. Note:
Space is lower data concept instance that can exists below IdentifiedArea data concept instance
but it is not required.
An aggregation of IdentifiedAreas can create an instance of a SubplaceElement or a Place.
Specific attributes are associated to each of the three specialization types of IdentifiedAreas.
An aggregation of instances of SubplaceElements can be linked to an instance of a higher level
SubplaceElement or a Place.
At the highest level of the place hierarchy, an aggregation of instances of Place can be linked to an
instance of a Campus. An instance of Campus is not required within an implemented place hierarchy.

Figure 2 – Place Hierarchy Example – User oriented
Figure 2 illustrates how the instances of the various place hierarchy data concepts are combined to
construct instances of nested parking hierarchy data concepts within one campus as a use case example.
To support parking, mobility or kerbside management operations, the IdentifiedArea class can be
refined, through specialization, as one of four specialization types: VehicularAccess,
PedestrianAccess, SupplementalFacility and SpecificArea.
The IdentifiedArea data concept collects general operating information such as operating hours,
operating restrictions, space information, and payment information. If the data is absent at the specific
instance of an IdentifiedArea, it is assumed the data for this information exists at a higher level in
the hierarchy, encapsulated in either instances of Place or any level instance of SubplaceElement
above the instance of IdentifiedArea. This allows for customization of operations at lower levels
while relying on default data.
A place is synonymous with the structure or area a consumer associates with where a vehicle parks or a
mobility service is delivered. It can be an entire parking structure or an aggregation of streets supporting
on-street parking (also sometimes called a zone). General operating information such as operating hours,
operating restrictions, space information, payment information, etc. is associated to a place and any parts
of the hierarchy underneath it as appropriate.
A core component of this model defines a hierarchy that supports the identification of parts of locations
that may be related to parking and other types of operations. Use of this hierarchy enables data suppliers
to provide a structured mechanism to refer to related zonal and place concepts with an ordered
hierarchy.
Figure 1 shows concepts within the place hierarchy:
• HierarchyElementGeneral – a generalised component of a place hierarchy that forms one
element in the tree-like hierarchy. This forms a reusable block of the hierarchy, with relations to
its parent element (if one exists) and any child elements. Each place in the hierarchy shall have a
name, and may support a free-text description and an operator/property owner defined
reference (e.g. location number/identifier).
• Note that a HierarchyElementGeneral is a specialisation of Facility, defined in
CEN/TS 16157-12 which offers a couple of general properties like rates, operation hours or
owner/operator information.
• There are five specializations of the place hierarchy (HierarchyElementGeneral class),
which conceptually defines different scales of hierarchy elements. From largest to smallest,
they are:
o Campus – the highest level in the hierarchy, it typically defines a large facility (such as a
university campus, or an airport), or a large geographic zone (such as a city or a town),
which may contain numerous places. A campus combines and encompasses a number of
Places that can be logically reported together. Different entities sharing data may create
their own aggregation of places. Thus, a place may appear in different campuses if a
receiving party receives data from different sending parties. Example: a parking
operator may group five (5) places together that it operates and call it a campus to
reflect the five (5) operations in a city. Three of the same places may be associated with
a property management firm that created a campus with the three places.
o Place – a place or location used for parking, loading, unloading, standing, or some
other mobility or transport related activity. Place typically identifies a parking
structure, surface lot or on street parking zone.
o SubplaceElement – a sub-division of a place for the convenience of the operator that
is used for parking related or other purposes. Examples of SubplaceElement include a
floor or level, specific street or row of a car parking facility.
o IdentifiedArea – an identifiable discrete bounded geographic zone that shares
common characteristics and is used for parking related or other purposes.
IdentifiedAreas are segmented into four specializations: VehicularAccess class,
PedestrianAccess, EquipmentServiceFacilityArea class and
SpecificArea class.
o Space – a single space for parking, usually designed for one vehicle, which may, but not
necessarily, be denoted by painted or other road surface marker.

These specialisations of place hierarchy (HierarchyElementGeneral)class (i.e. Campus,
Place, SubplaceElement, IdentifiedArea and Space) support both the notion of
different scales within the hierarchy, but also support different forms of attribution, which are
described later in this document.
The place hierarchy shall be defined “top-down” with the highest layer being numbered 0 (zero)
and each subsequent layer being numbered by incremental increasing integers.
The place hierarchy can best be considered as a tree-like structure which starts from one common
root element which will either be an instance of Place or, if used, Campus. Navigating down
through the layers of the hierarchy, irrespective of which branch is taken, each subsequently layer
sub-divides the previous. Each branch of hierarchy "tree" shall terminate in either an instance of
IdentifiedArea or Space. Each branch of the hierarchy shall contain one instance of Place,
and no more than one instance of IdentifiedArea. Note: A single instance of Place may
support multiple branches, thus an instance of Place can have multiple instances of
IdentifiedArea associated to it. If an instance of Campus is present, it shall only occur once
in each branch of the hierarchy. See Figure 3, which provides an illustrative example of elements
of a place hierarchy combine.
Figure 3 – Examples of Place Hierarchy
When describing the homogeneous characteristic for an entire place, the tree structure may terminate
with the instance of Place, (see Hierarchy 1 in Figure 3) with no further child hierarchy elements
(including IdentifiedArea).
If the place is sub-divided, each "branch" of the hierarchy tree shall terminate in one instance of
IdentifiedArea, and the IdentifiedArea class shall appear only once in each branch of the
hierarchy tree. Only instances of the Space class may exist at the levels of a hierarchy below the
occurrence of IdentifiedArea in each branch of the hierarchy tree. Every branch of the hierarchy
tree may use instances of the data concepts Campus, Place, SubplaceElement, IdentifiedArea
and Space in the order stated. Instances of SubplaceElement may be repeated in any branch of the
hierarchy, so long as it conforms to the order in the stated sequence.
7.2.2 «D2Package» ParkingTablePublication
7.2.2.1 Overview
The "ParkingTablePublication" package (see Figure 4) shall comprise a sub-model for defining one or
more publishable ParkingTable.
Each ParkingTable instance shall contain one or more instances of HierarchicalElement-
General, the top-level element (which will be further specialised) to specify different elements
describing parking related information.

Figure 4 — The “ParkingTablePublication” package class model
7.2.2.2 Semantics
7.2.2.2.1 «D2Class» ParkingTablePublication
The ParkingTablePublication class is a specific realisable case of a PayloadPublication
(defined in EN 16157-7). The ParkingTablePublication class is the base class for containing the
published ParkingTable.
Each instance of a ParkingTablePublication may have associated metadata contained in an
instance of the HeaderInformation class, which allows the supplier of the ParkingTable-
Publication to specify how the recipient should treat the information contained in it. Th
...