CEN/TS 16157-12:2022
(Main)Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 12: Facility related publications
Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 12: Facility related publications
This document specifies and defines component facets supporting the exchange and shared use of data and information in the field of traffic and travel.
The component facets include 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 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 CEN/TS 16157 specifies the informational structures, relationships, association ends, attributes and associated data types required for publishing information about facilities within the DATEX II framework. This is specified as a DATEX II "Facilities" namespace, which is part of the DATEX II platform independent model, but this Part excludes those elements that are specified in EN 16157-2 (Location referencing) and EN 16157-7 (Common data elements).
Intelligente Verkehrssysteme - DATEX II-Datenaustauschspezifikation für Verkehrsmanagement und Verkehrsinformationen - Teil 12: Publikationen im Zusammenhang mit Einrichtungen
Inteligentni transportni sistemi - Specifikacije za izmenjavo podatkov DATEX II pri upravljanju prometa in informiranju - 12. del: Publikacije v zvezi z objekti
Na podlagi te nove delovne postavke bo objavljen 12. del tehničnih specifikacij DATEX II, ki opredeljuje nov imenski prostor DATEX II »FacilityRelated« in podmodele za naslednje teme, povezane z objekti:
• mere;
• oprema ali storitveni objekti;
• delovni čas;
• organizacije;
• tarife in plačilo.
Do teh podmodelov lahko neposredno dostopajo in jih uporabljajo drugi imenski prostori oziroma drugi deli skupine standardov DATEX, kot na primer publikacija o energetski infrastrukturi ali publikacije o parkiriščih. Z zagotavljanjem nekaj publikacij v tem novem 12. delu (na primer OperatingHoursPublication) je mogoče določiti in objaviti tudi samostojne informacije o zgoraj navedenih temah in preprosto vključiti sklice na te podatke drugje.
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-september-2022
Inteligentni transportni sistemi - Specifikacije za izmenjavo podatkov DATEX II pri
upravljanju prometa in informiranju - 12. del: Publikacije v zvezi z objekti
Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 12: Facility related publications
Intelligente Verkehrssysteme - Datex II Datenaustauschspezifikationen für
Verkehrsmanagement und Verkehrsinformationen - Teil 12: Publikationen im
Zusammenhang mit Einrichtungen
Ta slovenski standard je istoveten z: CEN/TS 16157-12: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-12
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
May 2022
TECHNISCHE SPEZIFIKATION
ICS 35.240.60
English Version
Intelligent transport systems - DATEX II data exchange
specifications for traffic management and information -
Part 12: Facility related publications
Intelligente Verkehrssysteme - Datex II
Datenaustauschspezifikationen für
Verkehrsmanagement und Verkehrsinformationen -
Teil 12: Publikationen im Zusammenhang mit
Einrichtungen
This Technical Specification (CEN/TS) was approved by CEN on 20 March 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-12:2022 E
worldwide for CEN national Members.
Contents
European foreword . 5
Introduction . 6
1 Scope . 7
2 Normative references . 8
3 Terms and definitions . 8
4 Symbols and abbreviations . 8
5 Conformance . 8
6 UML notation . 9
7 «D2Namespace» Facilities . 9
7.1 Overview . 9
7.2 «D2Package» Facilities . 9
7.2.1 Overview . 9
7.2.2 Semantics . 12
7.3 «D2Package» Dimension . 12
7.3.1 Overview . 12
7.3.2 Semantics . 13
7.4 «D2Package» OrganisationPublication . 13
7.4.1 Overview . 13
7.4.2 Semantics . 15
7.5 «D2Package» RatesPublication . 16
7.5.1 Overview . 16
7.5.2 Semantics . 19
7.6 «D2Package» SupplementalFacility . 21
7.6.1 Overview . 21
7.6.2 Semantics . 22
7.7 «D2Package» OperatingHoursPublication . 25
7.7.1 Overview . 25
7.7.2 Semantics . 26
7.8 Data types . 27
7.9 Duration value . 28
8 LocationExtension and EmissionsExtension in «D2Namespace» Extension . 28
8.1 FacilityLocation (Address) . 28
8.2 EmissionsExtension . 29
Annex A (normative) Data Dictionary for «D2Namespace» Facilities . 30
A.1 Overview . 30
A.2 Data Dictionary for "Facilities" . 31
A.2.1 "DataValue" package. 31
A.2.2 "Dimension" package . 32
A.2.3 "Eligibility" package . 33
A.2.4 "Facility" package . 36
A.2.5 "OperatingHoursPublication" package . 40
A.2.6 "OrganisationPublication" package . 45
A.2.7 "PaymentMethod" package . 51
A.2.8 "Rates" package . 53
A.2.9 "Right" package . 64
A.2.10 "SupplementalFacility" package . 67
A.3 Data Dictionary of ≤≤D2Datatype≥≥ for "Facilities" . 71
A.3.1 Introduction. 71
A.3.2 The ≤≤D2Datatype≥≥ "AmountOfMoney" . 71
A.3.3 The ≤≤D2Datatype≥≥ "CurrencyCode" . 71
A.3.4 The ≤≤D2Datatype≥≥ "Duration". 71
A.3.5 The ≤≤D2Datatype≥≥ "IndexReference" . 71
A.3.6 The ≤≤D2Datatype≥≥ "SquareMetres" . 71
A.3.7 The ≤≤D2Datatype≥≥ "TimeZone" . 71
A.4 Data Dictionary of ≤≤D2Enumeration≥≥ for "Facilities" . 71
A.4.1 Introduction. 71
A.4.2 The ≤≤D2Enumeration≥≥ "AccessibilityEnum" . 71
A.4.3 The ≤≤D2Enumeration≥≥ "AvailabilityEnum" . 72
A.4.4 The ≤≤D2Enumeration≥≥ "CredentialTypeEnum" . 72
A.4.5 The ≤≤D2Enumeration≥≥ "EnergySourceEnum" . 73
A.4.6 The ≤≤D2Enumeration≥≥ "EquipmentTypeEnum" . 74
A.4.7 The ≤≤D2Enumeration≥≥ "FacilityTypeEnum" . 76
A.4.8 The ≤≤D2Enumeration≥≥ "ImageFormatEnum" . 77
A.4.9 The ≤≤D2Enumeration≥≥ "MeansOfPaymentEnum" . 77
A.4.10 The ≤≤D2Enumeration≥≥ "OpeningStatusEnum". 78
A.4.11 The ≤≤D2Enumeration≥≥ "OperationStatusEnum" . 79
A.4.12 The ≤≤D2Enumeration≥≥ "OrganisationTypeEnum" . 79
A.4.13 The ≤≤D2Enumeration≥≥ "PaymentBrandsEnum" . 79
A.4.14 The ≤≤D2Enumeration≥≥ "PaymentTimingEnum" . 80
A.4.15 The ≤≤D2Enumeration≥≥ "RateAvailabilityTypeEnum" . 80
A.4.16 The ≤≤D2Enumeration≥≥ "RateLineTypeEnum" . 81
A.4.17 The ≤≤D2Enumeration≥≥ "RateTypeEnum" . 81
A.4.18 The ≤≤D2Enumeration≥≥ "RateUsageConditionsTypeEnum" . 81
A.4.19 The ≤≤D2Enumeration≥≥ "RefundTypeEnum" . 81
A.4.20 The ≤≤D2Enumeration≥≥ "ReservationTypeEnum" . 82
A.4.21 The ≤≤D2Enumeration≥≥ "RightTypeEnum" . 82
A.4.22 The ≤≤D2Enumeration≥≥ "ServiceFacilityTypeEnum" . 83
A.4.23 The ≤≤D2Enumeration≥≥ "SurchargeTypeEnum" . 84
A.4.24 The ≤≤D2Enumeration≥≥ "UserTypeEnum" . 84
Annex B (normative) Data Dictionary for «D2Namespace» Extension . 86
B.1 Overview . 86
B.2 Data Dictionary for "Extension" . 87
B.2.1 "CommonExtension" package . 87
B.2.2 "LocationExtension" package . 88
B.3 Data Dictionary of ≤≤D2Datatype≥≥ for "Extension" . 91
B.3.1 Introduction. 91
B.3.2 The ≤≤D2Datatype≥≥ "TimeZone" . 91
B.4 Data Dictionary of ≤≤D2Enumeration≥≥ for "Extension" . 91
B.4.1 Introduction. 91
B.4.2 The ≤≤D2Enumeration≥≥ "AddressLineTypeEnum" . 91
Annex C (normative) Referenced XML Schema . 92
C.1 Overview . 92
C.2 Schema for «D2Namespace» Facilities . 92
C.3 Schema for «D2Namespace» CommonExtension . 149
C.4 Schema for «D2Namespace» LocationExtension . 149
Annex D (informative) Differences from prISO 5206-1 . 152
D.1 Differences from prISO 5206-1 . 152
Bibliography. 154
European foreword
This document (CEN/TS 16157-12: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.
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.
For users 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.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association and supports essential requirements of EU Directive(s).
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.
th
The 12 part of the CEN/TS 16157 - EN 16157 series (this document) deals with information on
facilities. It defines a new DATEX II namespace “Facilities” and sub-models on the following facility
related topics:
— Dimensions;
— Equipment or service facilities;
— Operating hours;
— Organisations;
— Rates.
These sub-models can be directly accessed and used by namespaces defined in other parts of the
DATEX standard series by specialising the Facility or the FacilityStatus class, as for example, by the
energy infrastructure publication or the parking publications. By providing a couple of Publications
within this new Part 12 (for example, "OperatingHoursPublication"), it is also possible to specify and
publish stand-alone information on the above-mentioned topics and just reference this data elsewhere.
In normative Annex A, the data dictionary for the «D2Namespace» Facilities is specified.
In normative Annex C, the referenced XML schema for the «D2Namespace» Facilities 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 and defines component facets supporting the exchange and shared use of data
and information in the field of traffic and travel.
The component facets include 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 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 CEN/TS 16157 specifies the informational structures, relationships, association ends,
attributes and associated data types required for publishing information about facilities within the
DATEX II framework. This is specified as a DATEX II "Facilities" namespace, which is part of the DATEX
II platform independent model, but this Part excludes those elements that are specified in EN 16157-2
(Location referencing) and EN 16157-7 (Common data elements).
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, Intelligent transport systems - DATEX II data exchange specifications for traffic management
and information - Part 1: Context and framework
EN 16157-2, Intelligent transport systems - DATEX II data exchange specifications for traffic management
and information - Part 2: Location referencing
EN 16157-7, Intelligent transport systems - DATEX II data exchange specifications for traffic management
and information - Part 7: Common data elements
ISO/IEC 19505-1:2012, Information technology — Object Management Group Unified Modeling Language
(OMG UML) — Part 1: Infrastructure
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.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/
3.1
facility
any kind of site, building, structure, including also service- or supplemental facilities and equipment
4 Symbols and abbreviations
ETRS89 European Terrestrial Reference System 1989
EU European Union
GUID Globally Unique Identifier
HTML Hyper text mark-up language
IP Internet Protocol
PDF Portable document format created by Adobe
UML Unified Modeling Language
URL Uniform Resource Locator
5 Conformance
The DATEX II platform independent data model of which the Facilities 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-1:2012
and in compliance with the methodology specified in EN 16157-1.
7 «D2Namespace» Facilities
7.1 Overview
This namespace shall define a facility class structure with properties that are related to all kind of
facilities, for example, parking sites or energy stations.
For some of the elements it shall be possible to specify a separate publication. By this construct, it will
be possible to predefine sets and to reference them later.
The following elements are included in this namespace:
— «D2Package» Facility – An abstract facility class structure that utilises the elements of the hereafter
following packages;
— «D2Package» Dimension – Dimensions of facilities;
— «D2Package» OrganisationPublication – Organisation data with contact information;
— «D2Package» RatesPublication – A generic structure for tariffs and payment;
— «D2Package» SupplementalFacility – Equipment and service facilities supplemental to some origin
facility, offering all facility properties theirself;
— «D2Package» OperatingHoursPublication – Operating hours of facilities.
The namespace includes further data types, data values and enumerations that are integral part of the
above model parts.
The prefix of the namespace shall be "fac".
Some of the packages and individual classes used within the “Facilities” namespace reside in the
namespaces “Common” and "Location" defined in EN 16157-7 and EN 16157-2.
The classes, attributes, data types and enumerations that are specific to the namespace "Facilities" are
defined in the normative Annex A.
The classes, attributes, data types and enumerations that are specific to two additional extensions
specified in clause 8 are defined in the normative Annex B.
The XML schema corresponding to this namespace is provided in the normative Annex C.
7.2 «D2Package» Facilities
7.2.1 Overview
The "Facility" and "FacilityObject" class shall form an abstract class structure that utilises the elements
of the hereafter following clauses. Classes from other namespaces may specialise the Facility class to
inherit the features of a facility described in this document – see Figure 1.
Figure 1 — The facility class structure
Example: An EnergyInfrastructureSite from Namespace EnergyInfrastructure (specified in CEN/TS 16157-10) is a
specialisation of a Facility, and thus information on its location, operating hours, specific images and more can be
specified.
The distinction between FacilityObject and Facility (which is a specialisation of FacilityObject) shall
avoid recursion by the means of a SupplementalFacility, which is a specialisation of a FacilityObject
itself.
The "FacilityStatus" and "FacilityObjectStatus" class shall form an abstract class structure in the same
sense described above, focussing on dynamic status information for a facility – see Figure 2.
Figure 2 — The facility status class structure
Example: The class EnergyInfrastructureSiteStatus from Namespace EnergyInfrastructure (specified in CEN/TS
16157-10) is a specialisation of FacilityStatus, and thus status information on updated operating hours, faults and
more can be specified.
The distinction between FacilityObjectStatus and FacilityStatus (which is a specialisation of
FacilityObjectStatus) shall avoid recursion by the means of a SupplementalFacilityStatus, which is a
specialisation of FacilityObjectStatus itself.
The class FacilityObject shall be of type «D2VersionedIdentifiable». Thus, each facility may be
referenced by id and version. In class FacilityObjectStatus, the mandatory attribute reference of type
VersionedReference shall form the link between static and the dynamic part of the facility model.
NOTE All further classes depicted in Figure 1 and Figure 2 that are not denoted in 7.2.2 will be described in
the later clauses.
7.2.2 Semantics
7.2.2.1 «D2Class» Facility and «D2VersionedIdentifiable» FacilityObject
By the Facility class and its inheritance of the FacilityObject class, a facility may be described with the
following features:
— Basic information: A name, alias, external identifier, timestamp of last update, a description,
information on accessibility and some additional information;
— URLs of information websites and photos;
— Photos (in binary format);
— Operating hours (including closure information), see 7.7;
— Location reference, as specified in EN 16157-2;
— Owner and operator information, using the Organisation structure, see 7.4;
— Associated facility: A reference to another facility or a short indication of it;
— Rates: Tariffs and payment information, see 7.5;
— Applicable vehicles, as specified by VehicleCharacteristics in EN 16157-7;
— Dimension, i.e. basic information on height, width, length or usable area;
— Supplemental facility: Some associated service facility or equipment, being itself characterised as a
facility, see 7.6.
7.2.2.2 «D2Class» FacilityStatus and «D2Class» FacilityObjectStatus
By the FacilityStatus class and its inheritance of the FacilityObjectStatus class, a facility status may be
described with the following features:
— Basic status information: The reference to the static facility object, timestamp of last update, the
opening status, a status description;
— Operating hours (will replace formerly defined operating hours);
— Rates (will replace formerly defined rates);
— A fault;
— Supplemental facility status. As this is a facility itself, each supplemental facility can be addressed
and referenced by the versioned-identifiable mechanism of the FacilityObject.
7.3 «D2Package» Dimension
7.3.1 Overview
The “Dimension” class (see Figure 1) shall support provision of dimension information for a facility or
object.
7.3.2 Semantics
7.3.2.1 «D2Class» Dimension
Each instance of the “Dimension” class may be used to define dimensions (length, width, height, usable
area) of some facility or object, including length, width, height and the usable area.
7.4 «D2Package» OrganisationPublication
7.4.1 Overview
The “OrganisationPublication” package shall support the specification of organisation related
information such as organisation unit and contact information. The information may be specified
directly or by reference (see Figure 3).
By using the «D2Class» "OrganisationPublication", it shall be possible to define tables of organisation
information in advance and reference them later (see Figure 4).
Figure 3 — The “Organisation” class model
Figure 4 — The “OrganisationPublication” package class model
7.4.2 Semantics
7.4.2.1 «D2Class» Organisation
An instance of the abstract "Organisation" class shall be connected to some organisational role
described by the calling association end, for example, 'operator' or 'serviceProvider'.
It shall be specialised by:
— the class "UnknownOrganisation" to specify that the organisation fulfilling this role is unknown;
— the class "UndefinedOrganisation" to specify that organisation fulfilling this role is not (yet)
defined;
— the class "OrganisationByReference" to reference previously published organisation information;
— or by the class "OrganisationSpecification" to specify the corresponding organisation information.
7.4.2.2 «D2VersionedIdentifiable» OrganisationSpecification
An instance of this class may specify basic information about an organisation, like its name, a
description or its type. At least one organisation unit must be specified (even if the organisation
structure is not splitted).
It may be referenced by using the class "OrganisationByReference".
7.4.2.3 «D2Class» OrganisationUnit
An instance of this class may specify the name and function of an organisation unit, which can be
physically or logically divided. A location (including address), operating hours and contact information
may be supplied.
7.4.2.4 «D2Class» ContactInformation and «D2Class» ContactPerson
An instance of the “ContactInformation” class shall describe detailed information to contact the
organisation unit, like telephone, E-Mail, etc. It may be specialised to specify a specific contact person.
7.4.2.5 «D2Class» OrganisationPublication
By using this class, it is possible to specify information on multiple organisations in the form of a
payload publication to reference it later. The information shall be published by using one or more tables
(class "OrganisationTable").
7.5 «D2Package» RatesPublication
7.5.1 Overview
The “RatesPublication” package shall support provision of information about Rates. The information
may be specified directly or by reference (see Figure 5 and Figure 6).
By using the «D2Class» "RatesPublication", it shall be possible to define tables of rates information in
advance and reference them later (see Figure 7).
NOTE Parts of the Rates-Publication sub-model have been derived/imported from a proposed version of
prISO 5206-1, also known as "APDS-model". For this procedure, version v5 (05-2021) of that model was the
reference. For the DATEX import, some adaptions had to be made on this model – see informative Annex D for
details.
Figure 5 — The “Rates” package class model
Figure 6 — The “RateEligibility” class model
Figure 7 — The “RatesPublication” class model
7.5.2 Semantics
7.5.2.1 General semantics
The “RatesPublication” package provides a model for tariffs/fees, for example, for a parking or energy
infrastructure site, including reservations and season tickets. Different rate tables can be defined and
linked with periods and eligibility and quality criteria such as specific users or types of vehicles.
7.5.2.2 «D2Class» Rates
An instance of the abstract "Rates" class shall be specialised by:
— the class "UnknownRates" to specify that the rates are not known;
— the class "UnspecifiedRates" to specify that rates are not (yet) defined;
— the class "FreeOfCharge" to specify the absence of specific rates (no fees to pay);
— the class "GeneralRateInformation" to specify payment methods without defining a specific rate
table;
— the class "RatesByReference" to reference previously published rates information;
— or by the class "RateTable" to specify the corresponding organisation information.
7.5.2.3 «D2VersionedIdentifiable» RateTable and Eligibility structure
NOTE This description is basically based on prISO 5206-1, pre-version v5 (05-2021).
A RateTable represents a set of charges that are applied to a single set of criteria and a single
RightSpecification for parking or other operations (e.g. delivery permits, rideshare access, etc) at the
Place. Examples of a RateTable are a weekday charge rate scales in a public multi-storey car park. Other
related RateTables might be evening rates and weekend rates. The validity start and end define the
period of validity of a RateTable. If the validity end is not set, the RateTable is considered to be valid
until it is replaced. The rateSupercedeLink attribute may be used to indicate a reference to a previous
RateTable that is being temporarily superseded.
A RateMatrix is defined as an aggregation of instances of RateTable. There are no specific constraints to
the construction of a RateMatrix – it is simply an aggregation of instances of RateTable the data supplier
wishes to provide together. It cannot be assumed that the RateTable in a RateMatrix relate to only one
Place or that they provide any particular semantic meaning as an aggregation of RateTable.
To support the transmission of a RateTable that may contain multiple charging elements, a RateTable
contains one to many RateLineCollection(s). An example could be a RateTable that contains a flat rate
fee for e.g. reservation, plus a tiered time-based rate structure for charging over the time of the session.
Each RateLineCollection represents one of those charging elements. A RateLineCollection is constructed
of one-to-many RateLine.
The RateLine concept is flexible and supports a range of different characterisations, which include:
— Flat rate – where the RateLine is active the applied fee charge is a flat rate, unrelated to the
duration or timing of the parking or other type of session; An example is a flat rate reservation fee
for a session. Flat rate RateLine are defined by use of defining a value, but no use of the
durationStart, durationEnd or incrementingPeriod attributes.
— Flat rate tier – where the applied fee charged is charged in full if the parking or other type of
session indicates that that specific RateLine is active.
Example: in the second hour of a session the fee is 1€ – for any part of that hour.
For a flat rate within a tier the RateLines are defined the time boundary of the tier by use of the
durationStart and durationEnd attributes and the value attribute to define the charge amount. If
used, the incrementingPeriod attribute, in this case, shall be the same as the period between the
durationStart and durationEnd (i.e. there is one increment). Charging is assumed to occur at the
start of each increment.
— IncrementingRate – where the applied fee charged is related to the duration of this specific tier that
has been activated by the parking or other type of Session. This charge type supports a RateTable
that applies for short incrementing periods or time-based small increments of charge.
Example: in the second hour of a Session, charging is done at a rate of 0,05 € every 3 minutes.
For an incrementing rate within a tier, the RateLine defines the time boundary of the tier by use of the
durationStart and durationEnd attributes. The incrementingPeriod and the value attribute indicate the
charge amount of each increment (e.g. 0,05 € each 3 minutes). Charging is assumed to occur at the start
of each increment.
Under most circumstances the start and end of charging periods are fixed and relative to local time (e.g.
between 08:00 and 17:00 weekdays). In some instances, the charging period and related tiers may be
relevant to a specific event. This is indicated by the use of the relativeTimes set to TRUE in the
RateLineCollection and the use of the RelativeTimeRates class. All times are defined relative to the
referenceTimeStart.
The applicable currency is defined in the RateLineCollection.
Individual RateLine support indication of whether tax is applicable within the defined RateTable or
applied in addition to the defined Rate. The level of tax, if included, can be specified as either a
monetary amount or a percentage rate. Taxes may also be applied to a RateLineCollection in a similar
manner. It is common practice for taxes to be applied at the RateLine level – for example, the
application of Value Added Tax (VAT) in Europe which is added to a basic parking fee and declared in
the cost of the parking to the end user.
A RateLineCollection indicates whether the child RateLine are a chargeable tariff or represent a
surcharge, which may be partially or fully refundable.
Each RateTable is applicable to a singular set of criteria and a single RightSpecification. The
specification of the qualifying criteria is specified using Eligibility, see Figure 6.
Eligibility is specified as a collection of individual Qualifications. A Qualification is specified as a test
with any of the attributes in the Qualification class set. In addition, Qualifications can be specified for
other qualifications like for vehicle characteristics as defined in EN 16157-7.
Eligibility may be related or defined by membership. Typically, the Qualification in this case is defined
by the withMembership attribute set to TRUE and the membershipName attribute set to the names of
the relevant memberships (e.g. J-Park frequent users club, shoppers, cinema attendees, event ticket
holders, military, industry specific vehicle, etc).
Additionally, Eligibility may be defined by the use of another RateTable (memberofOtherRateTable set
to FALSE), or if the parker is a member of another specific RateTable (memberofOtherRateTable set to
TRUE), and the rateTableMember set to identify the earlier linked RateTable.
7.6 «D2Package» SupplementalFacility
7.6.1 Overview
The “SupplementalFacility” package (see Figure 8) may support providing detailed in
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...