ISO/TS 5206-1:2023

TECHNICAL ISO/TS
SPECIFICATION 5206-1
First edition
2023-04
Intelligent transport systems —
Parking —
Part 1:
Core data model
Systèmes intelligents de transport - Stationnement —
Partie 1: Modèle de données de base
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: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviated terms . 2
4 Conformance . 2
5 UML notation . 2
6 Data model . 3
6.1 Data model overview . 3
6.2 Place data concepts . 4
6.2.1 Place hierarchy . 4
6.2.2 IdentifiedArea sub-types .12
6.2.3 Common components . 16
6.2.4 Payment method. 17
6.2.5 Basic elements (in place) . 18
6.3 Occupancy . . 19
6.3.1 Introduction to occupancy . 19
6.3.2 Supply . 20
6.3.3 Demand . 21
6.3.4 Enumerations (for occupancy). 21
6.3.5 External codelists (for occupancy) . 22
6.4 Rates . 22
6.4.1 Introduction to rates. 22
6.4.2 Rate tables .22
6.4.3 Eligibility . 24
6.4.4 Enumerations (for rates) . 25
6.4.5 External codelists (for rates) . 26
6.5 Right . 26
6.5.1 Enumerations (for right) . 37
6.5.2 External codelists (for right) .38
6.6 Session .38
6.6.1 General .38
6.6.2 Enumerations (for session) .40
6.6.3 External codelists (for session) .40
6.7 Observation .40
6.7.1 Enumerations (for observation) . 42
6.7.2 External codelists (for observation) . 42
6.8 Quote . 42
6.8.1 Introduction to quote . 42
6.8.2 QuoteRightRequest — Request for a new transaction. 43
6.8.3 QuoteRightResponse — Response to a QuoteRightRequest for a new
transaction.44
6.8.4 QuoteSessionExtensionRequest — Request for an extension of an existing
session . 45
6.8.5 QuoteSessionExtensionResponse — Response to a
QuoteSessionExtensionRequest for an extension of an existing session .46
6.8.6 Enumerations (for quote) .48
6.8.7 External codelists (for quote) .48
6.9 Common elements .48
6.9.1 Introduction to common elements .48
iii
6.9.2 Data types (general) .50
6.9.3 Enumerations (general) .50
6.9.4 Common classes . 51
6.9.5 External codelists . 52
6.9.6 Organisation, contacts and address . 53
6.9.7 Describing Locations .56
6.9.8 Data types (for location) .64
6.9.9 Enumerations (for location) .64
6.9.10 External codelists (for location) .66
6.9.11 Times.66
6.10 Facilities . 69
6.10.1 Overview . 69
6.10.2 Data types (for facilities). 70
6.10.3 Enumerations (for facilities) . 70
6.10.4 External codelists (for facilities) . 70
6.11 Energy infrastructure . 71
6.11.1 Overview . 71
6.11.2 Data types (for energy infrastructure) .72
6.11.3 Enumerations (for energy infrastructure).73
6.11.4 External codelists (for energy infrastructure) .74
Annex A (normative) Data dictionary .75
Annex B (informative) Relationship to CEN 16157 "DATEX II" Data Modelling Concept and
Framework . 196
Annex C (informative) Use case examples . 197
Annex D (informative) Example user-defined codelists .246
Bibliography . 247
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.
A list of all parts in the ISO 5206 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
Around the globe, new services and technologies are intersecting to create value-added convenience
to customers and business owners while better utilizing available parking, mobility and transport
infrastructure. Whether supporting car sharing, ride sharing, micro mobility services, prepaid parking,
dynamic pricing in parking structures, remote management of operations, and/or improved reporting,
the sharing of data is key to accelerating the adoption of these services.
To enable the sharing of data, the global community has collaborated to create consensus-built,
international parking and mobility data specifications to establish a common language for data concepts
and definitions in the parking, transport and mobility sectors. These “data specifications” define a
common language composed of a set of data concepts and definitions that public and private property
owners, operators and service providers can follow to facilitate communication between themselves
and with the other industries. These specifications facilitate seamless integration, compatibility and
communication between parking entities, mobility operators, the automotive industry, IT developers,
ITS operators, services, and map and app providers, as well as other stakeholders.
These specifications, as defined in this document, seek to reduce the effort required to connect
technology solutions to one another and to allow companies to refocus their resources on innovating
new services and operations.
This document defines the structure, definition and relationships of data constructs relevant to parking
and mobility data. This document provides a description of the data constructs in the context of the
data model in Clause 6.
Annex A provides a data dictionary of definitions for attributes, classes and relationships.
Annex B provides a description of the data modelling approach defined in this document and how this
relates to the CEN 16157 series "DATEX II" modelling approach, defined in EN 16157-1.
NOTE By choice, the Alliance for Parking Data Standards has substantively adopted the DATEX II modelling
approach, as this can potentially facilitate simpler integration, at a later date, to data concepts and standards
defining road traffic management and information concepts.
Annex C provides use cases and examples for the use of the data defined.
vi
TECHNICAL SPECIFICATION ISO/TS 5206-1:2023(E)
Intelligent transport systems — Parking —
Part 1:
Core data model
1 Scope
This document defines terms, characterization and the relationship of concepts, defined using model-
driven architecture methods, for parking and parking-related activities (both on-street and off-street)
covering common data supporting business to business exchanges and end user services.
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 639-1, Codes for the representation of names of languages — Part 1: Alpha-2 code
ISO 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1: Country
code
ISO 4217, Codes for the representation of currencies
ISO 8601-1, Date and time — Representations for information interchange — Part 1: Basic rules
ISO/IEC 10646, Information technology — Universal coded character set (UCS)
ISO/IEC 19505-1, Information technology — Object Management Group Unified Modeling Language (OMG
UML) — Part 1: Infrastructure
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions 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.1
data receiving party
entity that is requesting or receiving data using the specification from a reliable data source
3.1.2
data distributing party
entity holding data with permission to distribute, that is issuing data using the specification to other
entities
3.2 Abbreviated terms
ANPR automatic number plate recognition
RFID radio frequency identification
UML unified modeling language
4 Conformance
A specification, system or exchange of data (hereafter called "specification") claiming conformance to
this document shall include a comparison of the specification of data against the data model defined in
this document. This comparison shall be defined at two conformance levels:
— level 1 (data domain) which identifies which data domains within the specification correspond to
the data domains specified in this document, and which are not;
— level 2 (detailed level) which compares the data model within the specification against the packages,
classes, attributes and relationships specified in this document.
The level 1 conformance statement should be presented as a table based on the data domains defined
in the normative part of this document. This includes place, occupancy, session, right, rates, quote,
observation, energy infrastructure and parking common (PkCommon); or
The level 2 conformance statement should be presented as a table in which the data concepts used in
the specification are described as follows.
— “Unmodified”: concepts in the specification which have the same definition, properties and
relationships as in the corresponding data domain specified in this document.
— “Modified”: concepts in the specification which are similar to the data concept defined in this
document, but which differ in the details of certain attributes and/or relationships (e.g. attributes
added).
— “Alternative”: concepts or groups of concepts in the specification intended to model the same
concepts as defined in this document but in a significantly different way.
— “Additional”: concepts in the specification which are additional to the concepts defined in this
document and therefore are not covered by and drawn from the data concepts specified in this
document.
— “Omitted”: data concepts specified in this document which are not used in the specification.
Data concepts shall include packages, classes, attributes, relationships, definitions and properties, and
comparison shall present conformance with the following requirements as expressed in this document:
— conformance to all stipulated minimum and maximum multiplicity requirements for UML elements
and relationships;
— conformance to all definitions, types and ordering;
— employment of optional elements as specified;
— conformance to all expressed constraints.
5 UML notation
The UML notation used in this document shall be as described in ISO/IEC 19505-1.
NOTE The use of UML notation follows the DATEX II methodology which is specified in EN 16157-1.
6 Data model
6.1 Data model overview
This specification facilitates the sharing of basic information between entities and systems. This
includes map services, online marketing and aggregator services, event ticketing platforms, transit and
transportation agencies, and other firms, organizations or individuals that have a need to know the
location of parking and other mobility-related services and general information about the operation.
Figure 1 shows the data domains in this document. Each data domain defines a specific set of data
concepts that logically can be grouped.
Figure 1 — Data domains
To assist navigation and understanding of the specification in this document, the overall model
is separated into data domains, which can be seen in UML packages in Figure 2. The domains focus
on functional groups of data concepts and relationships. Each of the domains is specified in its own
namespace. In addition, the structure of the data model supports the definition of common concepts
that are referenced and reused across several domains. These common concepts are specified in the
“PkCommon” domain.
Figure 2 — Namespace dependencies
Figure 2 illustrates the dependency between namespaces.
These data domains, as characterized by the namespaces, are combined in various manners to support
specific use cases that exist in parking and mobility operations. For example:
— the operations and systems to support automated valet parking rely on this document's data
domains of place, rate, quote, session, right and occupancy;
— the operation and systems to support curbside management rely on all data domains in this
document to support data sharing.
6.2 Place data concepts
6.2.1 Place hierarchy
6.2.1.1 Overview
This subclause describes concepts used in the place hierarchy, which are defined in the
namespace of the data model.
NOTE Location, time and contact/organization concepts are defined in the namespace of this
data model.
6.2.1.2 Place hierarchy
The specification defines a method for building 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 identify a location or zone in a
simple manner with a single hierarchy element or to break down a place into a multi-layered hierarchy
that identifies discrete parking enclosures or defined areas to communicate operating hours, space
counts, operating restrictions, location, rights and associated pricing and occupancy.
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) in order to
simplify the amount of data shared. The place hierarchy also enables lower-level place hierarchy class
instances to document variations in specific attributes from their parent, higher-level place hierarchy
class instance.
Additionally, the specification enables other operation types, not directly related to parking, to define a
place in discrete operating enclosures. This may include a defined on-street area for managing delivery
services or a sidewalk area enabled for bike or e-scooter placement.
The hierarchy allows a data distributing party to decide the appropriate level of detail to send to a data
receiving party via messaging protocols. In addition, it is not necessary to build multi-layer hierarchies
of Place data. Simple data needs can be represented without using the multiple layers available in the
data specification.
Each of the component Place data concepts is mentioned in this subclause, but further details and
descriptions follow in subsequent subclauses. These component data concepts are:
— Place (6.2.1.4),
— SubplaceElement (6.2.1.5),
— IdentifiedArea (6.2.1.6),
— Space (6.2.1.7),
— Campus,
— PedestrianAccess (6.2.2.1),
— VehicularAccess (6.2.2.2),
— SpecificArea (6.2.2.3), and
— SupplementalFacility (6.2.2.4).
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 is instantiated via the Place class. Place can also be used to define entry
and exit roadways, driveways, and acceleration/deceleration zones for vehicles as well as pedestrian
access points. 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 a lower data concept instance that can exist 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 four specialization types of IdentifiedAreas.
An aggregation of instances of SubplaceElements can be linked to an instance of a higher level
SubplaceElement or a Place. This allows a data provider to share as much or as little detail as necessary
to support their operation.
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 a required within an implemented place hierarchy.
Figure 3 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.
Figure 3 — Place hierarchy example – user-oriented
To support parking, mobility or curbside management operations, the IdentifiedArea class
can be refined, through specialization, as one of four specialization types: PedestrianAccess,
VehicularAccess, SpecificArea, and SupplementalFacility.
PedestrianAccess class is a specialization of IdentifiedArea class that enables a place to share
coherent, relevant information about pedestrian entry and exit access points to a Place. This allows
an entity to identify operating hours for the pedestrian access points and access requirements such as
credentials or restrictions for each access point.
VehicularAccess class is a specialization of IdentifiedArea class that enables a Place to share coherent,
relevant information about entry lane, exit lane and similar types of vehicular access points to a Place.
The VehicularAccess class is used to define entry and exit to a specific facility or is used to provide a
more macro description of an entry to a facility by reference to Road and RoadNodes.
Road: allows an organizational entity to identify the primary road on which a place exists and to
describe routes to that Place.
RoadNode: allows an organizational entity to identify nearby major intersections of roads.
SpecificArea class is a specialization of the IdentifiedArea class that denotes a specific (generally
geographically-bounded) area in a place that has a common operating purpose and common
characteristics. Examples of common operating purpose include reserved parking area, electric vehicle
parking, bike parking, delivery zone, loading zone, etc. The SpecificArea class describes the physical
components of a Place.
For clarity, when defining the use of a SpecificArea, authorized activities to perform in an
IdentifiedArea are defined by the assignment of a RightSpecification and include activities such as
valet parking, disabled parking, delivery zone, etc. The assignment and authorization to perform a use
in a SpecificArea occurs via the assignment of a RightSpecification. As an example, valet parking is
associated to an IdentifiedArea with a SpecificArea class via the RightSpecification which assigns
valet parking to a specific person and place.
SupplementalFacility is a specialization of IdentifiedArea class that enables a Place to identify the
type and location of equipment and services available within the Place. The SupplementalFacility
class is used to define restroom/toilet, shower, food concession services, etc. It is also used to identify
specific equipment available in a Place, such as bike storage, electric chargers, payment stations, etc.
This IdentifiedArea specialization defines physical structures and equipment in the place as well as
services available.
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 from higher levels in the Place hierarchy.
A Place is synonymous with the structure or area with which a consumer associates a vehicle being
parked or a mobility service being 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.
Place is a core component of this model as it defines a hierarchy that supports the identification of
portions 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 4 shows concepts within the place hierarchy.
Figure 4 — Place hierarchy
The concepts shown in Figure 4 are:
— HierarchyElementGeneral – a generalized 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).
— There are five specializations of the Place hierarchy (HierarchyElementGeneral class), which
conceptually defines different scales of hierarchy elements. From largest to smallest, they are:
— 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 that can be logically reported together. 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. For example, a parking operator
may group five (5) places together in which 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 defined a separate campus with the three places.
— Place – a place or location used for parking, loading, unloading, standing, or another mobility or
transport related activity. Place typically identifies a parking structure, surface lot or on-street
parking zone.
— SubplaceElement – a 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.
— IdentifiedArea – an identifiable discrete bounded geographic zone that shares common
characteristics and is used for parking and mobility-related operations or other purposes.
IdentifiedAreas are segmented into four specializations: PedestrianAccess class,
VehicularAccess class, SpecificArea class and SupplementalFacilityArea class.
— Space – a single space for parking or other mobility-related purposes, usually designed for one
vehicle, which may, but not necessarily, be denoted by painted marker or another road surface
marker.
These specializations of place hierarchy (HierarchyElementGeneral) class (i.e. Campus, Place,
SubplaceElement, IdentifiedArea and Space) support both the notion of different scales within the
hierarchy as well as 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 subsequent 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.
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 5, which provides an illustrative example of elements of a
place hierarchy combined.
Figure 5 — 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 5) 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 this
conforms to the order in the stated sequence.
6.2.1.3 Location hierarchy example
Top down:
Airport example
— Layer 0 – Campus (Airport)
— Layer 1 – Place (Short Stay Car Park) {others might be "long stay", "valet meet and greet", etc.}
— Layer 2 – SubplaceElement (Orange Level or Third Floor)
— Layer 3 – IdentifiedArea (Row J) - Type SpecificArea, with additional attributes
— Layer 4 – Space (74)
It is not necessary to build multi-layer hierarchies of Place data. Simple Place data needs can be
represented without using the multiple layers available in the data specification.
6.2.1.4 Place
Figure 6 provides a UML class diagram for Place.
Figure 6 — Place
An instance of Place can have zero, one or several point locations that represent the notional point
spatial location of the place. Additionally, an instance of Place can have zero, one or several area
locations that represent the notional bounding polygon or zone for the place. An instance of Place
can have zero, one or several street addresses. An instance of Place can access CommonComponents
classes which support a wide range of optional attribution for contacts (which includes addresses),
times (operating times, entrance opening times, exit opening times), location data, marketing content
references, payment methods, operating restrictions, colour association (where parking facility
elements are colour coded) and other characteristics (such as operating mode, type of the parking
structure, access control, etc.)
Instances of IdentifiedArea and Space enable additional classes beyond the CommonComponents to be
associated. IdentifiedArea is an abstract class, see Figure 8, which can be realized in four implementable
specializations: PedestrianAccess, VehicularAccess, SpecificArea, and SupplementalFacility.
SubplaceElement and Space have a user-defined codelist related to occupancy level. This user-defined
codelist enables a Place to define codes for various occupancy levels and the user-defined definition of
each occupancy level. As an example, a place or space may identify occupancy levels using user-defined
colour codes and define each colour code as follows:
User-defined Code 1: Green
User-defined Code 1 Definition: Occupancy utilization is less than 80 % of Supply
User-defined Code 2: Yellow
User-defined Code 2 Definition: Occupancy utilization is less than 85 % of Supply
User-defined Code 3: Red
User-defined Code 3: Definition: Occupancy utilization is equal to or greater than 95 % of Supply
6.2.1.5 SubplaceElement
Figure 7 provides a UML class diagram for SubplaceElement.
Figure 7 — SubplaceElement
6.2.1.6 IdentifiedArea
Figure 8 provides a UML class diagram for IdentifiedArea.
Figure 8 — IdentifiedArea
6.2.1.7 Space
Figure 9 provides a UML class diagram for Space.
Figure 9 — Space
6.2.2 IdentifiedArea sub-types
6.2.2.1 Pedestrian access
Figure 10 provides a UML class diagram for PedestrianAccess.
NOTE This model only supports the modelling of vehicular and pedestrian accesses at the present time.
Other forms of access can be introduced during a later revision if a stakeholder requirement is identified.
Figure 10 — PedestrianAccess class diagram
PedestrianAccessType enumerations (PedestrianAccessTypeEnum) for PedestrianAccess support the
definition of characteristics for access in and out from a place or part thereof respectively (denoted by
the pedestrianAccessType attribute, using the PedestrianAccessType enumerations). PedestrianAccess
enables an entity to identify the quanity of each access type as well as the operating times the
PedestrianAccess is available for use.
6.2.2.2 Vehicular access
Figure 11 provides a UML class diagram for VehicularAccess.
Figure 11 — VehicularAccess class diagram
AccessType enumerations (AccessTypeEnum
...