CEN/TS 28701:2010

SLOVENSKI STANDARD
01-april-2010
Cestna transportna in prometna telematika - Javni prevoz - Identifikacija stalnih
objektov v javnem transportu
Road transport and traffic telematics - Public transport - Identification of fixed objects in
public transport
Öffentlicher Verkehr - Identifizierung fester Objekte im Öffentlichen Verkehr (IFOPT)
Télématique des transports routiers et de la circulation - Transports publics -
Identification des objets fixes dans les transports publics
Ta slovenski standard je istoveten z: CEN/TS 28701:2010
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN/TS 28701
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
January 2010
ICS 35.240.60
English Version
Road transport and traffic telematics - Public transport -
Identification of fixed objects in public transport
Télématique des transports routiers et de la circulation - Öffentlicher Verkehr - Identifizierung fester Objekte im
Transports publics - Identification des objets fixes dans les Öffentlichen Verkehr (IFOPT)
transports publics
This Technical Specification (CEN/TS) was approved by CEN on 21 July 2008 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, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2010 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 28701:2010: E
worldwide for CEN national Members.

Contents Page
Foreword . 4
Introduction . 5
1 Scope . 7
1.1 General . 7
1.2 Explicit Exclusions from Scope . 7
1.3 Exclusions from Terminology . 8
1.4 Approach – Modularisation . 8
1.5 Approach – Modelling . 9
2 Normative references . 13
3 Terms and definitions . 13
3.1 Transport Related Terms . 13
3.2 Communications & Software Concepts . 28
4 Symbols (and abbreviated terms) . 28
5 Use Cases for Stop Point Data . 29
5.1 General . 29
5.2 Use Cases: Timetable Preparation & Scheduling Systems . 30
5.3 Use Cases: Journey Planning . 33
5.4 Use Cases: AVMS and Real-time Information Providers . 35
5.5 Use Cases: Public Transport Operations . 36
5.6 Use Cases: Urban Traffic Management Control systems . 37
5.7 Use Cases: Geographic Information Systems . 37
5.8 Use Cases: Local Authorities . 37
5.9 Use Cases: Other . 38
5.10 General Use Cases . 38
5.11 Excluded Use Cases . 39
6 Stop Place Model . 39
6.1 General . 39
6.2 Physical Models . 40
6.3 UML Model for Stop Place . 59
6.4 Navigation Paths . 89
6.5 Accessibility Navigation . 96
6.6 Stop Place Model Views. 105
6.7 On-Street Stop Place View . 107
6.8 Parking . 108
6.9 Stop Place Model Summary View . 110
6.10 Stop Identification . 111
6.11 Types of Stop Identifier. 111
6.12 Principles for Issuing Stop Identifiers . 111
6.13 Principles for Stop Place Identifiers (Normative) . 111
6.14 Discussion of Stop Identifiers, Codes and Labels (Informative) . 112
7 Point of Interest Model . 117
7.1 General . 117
7.2 Physical Models . 117
7.3 UML Model of Point of Interest Model . 123
8 Topographical Model . 126
8.1 General . 126
8.2 Physical Models . 126
8.3 UML Model of Topographical Model . 126
9 Administrative Model . 129
9.1 General . 129
9.2 Physical models . 129
9.3 UML Model for Data Administration . 129
10 Common Modelling Points . 132
10.1 Relationship to GIS data . 132
10.2 Common Enumerations . 132
Annex A (informative) Example of dimensional functions to classify disability included in
the FINAL (Complete Integration of Demand Responsive Transport and PT) project
in Sweden, as an example of Accessibility Classification of medical conditions . 139
Bibliography . 141

Foreword
This document (CEN/TS 28701:2010) has been prepared by Technical Committee CEN/TC 278 “Road
transport and traffic telematics”, 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 [and/or CENELEC] shall not be held responsible for identifying any or all such
patent rights.
According to the CEN/CENELEC Internal Regulations, the national standards organizations 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,
Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and the United Kingdom.
Introduction
Information systems for Public Transport (PT) need information related to objects or events of the real
world, such as bus stops, beacons, points of interest, access points to train stations, vehicles, traffic
lights, accidents, works, etc.
It is possible to classify these data into three families:
 Fixed objects: bus stops, beacons, points of interest, roads, etc.;
 Mobile objects: vehicles, on board validators, etc.;
 Events: accidents, works, and situations affecting parts of the network, etc.
Subsets of these objects are of particular importance for certain functional domains of Public Transport.
For instance, Automatic Vehicle Monitoring systems are concerned with the mobile objects (vehicles)
and their positions relative to the infrastructure.
Passenger Information systems are concerned with:
 Information provision and exchange about the network services (timetables, etc.);
 Optimization of passenger trips (trip proposals made according to specific criteria,etc.);
 Management of Public Transport resources (sales points, validators, passenger information
devices, etc.).
These systems need all types of data, but information related to the fixed objects is crucial, in
particular about the Public Transport stops, their unambiguous identification, their accurate description,
and their location in space.
Several particular problems apply to such data. One of them is the fact that the same fixed objects
(stops, interchanges) are often used by several operators or several modes and appear with different
descriptions and identifiers, so that complex correspondence tables have to be set up and maintained
to ensure inter-modal trip planning, for instance, where it is important to uniquely identify the stops.
Another problem appears when apparently the same fixed objects (e.g. a train station, a bus stop) are
considered as simple (points) or complex (clusters of points or areas) depending on the viewpoint of a
subsystem (for instance, precision of the map). This aspect is often solved by the identification of
several objects as one single object (a type of projection), but engenders at the same time the problem
of the location referencing of the complex object that has been considered as simple, without a precise
method for locating it in space.
Another aspect of the problem of referencing fixed objects for Public Transport is that they are often
related to urban infrastructure. The latter is often relevant and used for the description of these objects.
Topographical descriptors are introduced to characterise objects that are specific to Public Transport
and, furthermore, knowledge of the access points to buildings and other infrastructure objects may be
relevant for journey planning. In this case, if any change of the urban infrastructure occurs, Public
Transport specific data should be updated and, in a multi-operator context, a certain incoherence of
information is likely to appear.
All these reasons have led to several national programs to provide solutions to address at least parts
of the problem particularly relevant for Passenger Information. The UK-NaPTAN system focuses on
Public Transport stops, their unambiguous identification, their location in space and their description,
choosing a certain level of detail. In Germany DELFI and VDV-Datenmodel deal with similar issues.
The Swedish "Samtrafikens transportformat" provides topographical identification including addresses,
Public Transport stops with localization and path links for passengers.
Other European standards that exchange PT data, such as TPEG or TRIDENT, ALERT C, ILOC, EU-
Spirit, Transmodel or SIRI, aim at the description of location referencing of stops, but do not provide a
comprehensive solution for all the problems.
Another important recent study has been the French CERTU's "Étude des systèmes de localisation
pour les transports – Clarification des concepts liés aux ârrets de transports en commun" which makes
a systematic study of stop location concepts and furthermore relates them to the existing concepts of
the Transmodel standard. This "Identification of Fixed Objects" document draws heavily on the
CERTU study, which was carried out by the leading French Transmodel experts.
The identification of fixed objects needs to be managed at a national level and the standard should
take into account the respective national organisational models for administering data. Because of the
large number of stops and their geographical dispersal, this will typically involve a distributed process
with a number of parties needing to be coordinated.
1 Scope
1.1 General
This Technical Specification defines a model and identification principles for the main fixed objects
related to public access to Public Transport (e.g. stop points, stop areas, stations, connection links,
entrances, etc.), in particular:
 To identify the relevant functions which need a unique identification of fixed objects especially for
the Passenger Information domain in a multi-modal, multi-operator context;
 To identify the main fixed objects related to the Public Transport system, choosing a certain
viewpoint, i.e. considering a certain level of detail ("granularity") of the given description taking
into account the needs of the identified functions;
 To give a typology of these objects together with definitions;
 To present relationships between the identified Public Transport objects;
 To unambiguously describe these objects through their main properties (attributes);
 To describe how to locate these objects in space through coordinates and through the link to
topographic objects with a clear separation between the "Public Transport layer" and the
"topographic layer" described in its turn by geographic objects;
 To enable the assignment of data administration (responsibility for data maintenance) of each
fixed object.
Geospatial location referencing techniques of PT objects (e.g. use of satellites, roadside equipment for
positioning) or representation techniques on maps (projections) are outside the scope of this standard.
1.2 Explicit Exclusions from Scope
In order to limit the scope for this version of the Fixed Object Standard, certain types of potential Fixed
Object have been excluded for the time being, but will be proposed for inclusion in a second or
subsequent part of the standard. These include:
 Roadside Equipment such as Traffic Signals and Traffic Lights and approach information for
Urban Traffic Management and Control Systems;
 Road crossings and interchange data (though Access links may project onto tracks in other
models that consider these, such as the EuroRoads project);
 Parking: A Car Park Model defines the availability and nature of car, bicycle and other parking.
IFOPT includes only a rudimentary Parking model to indicate the relationship of the car parks to
the rest of the Stop Place model;
 Relationships with the location referencing requirements of DATEX2 and TPEG.
Fixed Objects are concerned primarily with physical infrastructure and equipment as referenced by
information services. Concepts that relate to fixed points that belong to other information layers, such
as the structure of Tariff Zones or Fare stages (which belong to the fares layer of Transmodel) are not
covered.
IFOPT describes a generic structure for classifying Points of Interest, for example Museums, Stadiums,
etc., but does not set out a recommended informative value set of Point Of Interest Categories.
1.3 Exclusions from Terminology
For the convenience of readers, the Terms and Definitions section of the IFOPT specification repeats
definitions of certain key Transmodel concepts that are fundamental to understanding the IFOPT
model. It does not repeat definitions of a number of other related Transmodel elements that are part of
other Transmodel information layers, i.e. not specific to the Fixed Object layer, for example LINE,
DESTINATION DISPLAY, PASSING TIME, or are not within the direct scope of the Fixed Object
models, such as RAILWAY ELEMENT, RAILWAY JUNCTION, ROAD ELEMENT, ROAD JUNCTION.
1.4 Approach – Modularisation
1.4.1 General
This Technical Specification builds on the Transmodel Standard to define four related sub models;
See Figure 1.
Each model is described as a set of entities, attributes and relationships with other models.

Figure 1 — Fixed Object Submodels
These constituent models of the Fixed Object model are enumerated as follows:
 Stop Place Model: Describes the detailed structure of a STOP PLACE (that is station, airport,
etc) including physical points of access to vehicles and the paths between the points, including
ACCESSIBILITY.
NOTE The concept of stops and the links between them in the Stop Place Model is distinct from the STOP
POINT and CONNECTION LINK concepts used in Transmodel to describe the logical stopping points and
connections of journey patterns for timetables: the Stop Place model describes the stops and paths as actual
physical locations in space.
 Point of Interest Model: Describes the structure of a POINT OF INTEREST including physical
points of access, i.e. ENTRANCES. Also provides a model for a standardised POINT OF
INTEREST CLASSIFICATION hierarchy – a means of providing a taxonomy of different types of
POINT OF INTEREST relevant for journey planning.
 Gazetteer Topographical Model: Provides a topographical representation of the settlements
(cities, towns, villages, etc.) between which people travel. It is used to associate Stop and Station
elements with the appropriate topographic names and concepts to support the functions of
journey planning, stop finding, etc. The TOPOGRAPHICAL PLACE entities in the Gazetteer
model may be referenced by the Stop Place and Point of Interest Model but do not reference the
elements of those models.
 Administrative Model: Provides an organisational model for assigning responsibility to create
and maintain data as a collaborative process involving distributed stakeholders. Includes
namespace management to manage the decentralised issuing of unique identifiers.
The Stop Place Model is the mandatory part of the Fixed Object model. The other models are ancillary
and may be implemented on an optional basis
1.4.2 Motivation for Modularisation
This partitioning of Fixed Object into distinct sub-models is in particular of significance for data
exchange. For data exchange, a model held on one computer system must typically be serialised into
an XML document or other flat file format and then, after transmission, be de-serialised and re-
referenced back into another model on a different system. In order to exchange data efficiently it must
be possible to partition the data of a large model (for example all the bus stops in a country) into
smaller coherent subsets (for example all the bus stops in a single area within a country) that include
references to objects that are not included in the export (for example stops in adjacent areas, or the
full definitions of the areas). This raises considerations for ensuring integrity of reference and in
particular for the management of the identifiers that are used to implement the reference across
different systems.
In practice the coherent subsets of data that are needed for efficient exchange must reflect the
operational processes and frequency of change of the data. The four Fixed Object submodels
represent four primary sets of data that usually will be exchanged as distinct documents between
different parties on different timescales. Thus for example, the Administrative model is a small model
that typically needs to be set up centrally with a view to coordinating the work of different stakeholders;
once created, its data will change only occasionally, but it will be extensively referenced by other
documents. At the other extreme, the Point of Interest and Stop Place models will need to be
managed as discrete large data sets for each locality, each requiring detailed geographical surveying
and local access knowledge for its creation and maintenance.
A second reason for modularisation is that it allows a more flexible and incremental approach to
adoption of the standards.
1.5 Approach – Modelling
1.5.1 Relationship to Transmodel
The Fixed Object model is developed from the existing Transmodel as follows:
 A number of existing Transmodel entities are referenced. In addition, the same separation of
concerns and use of distinct layers for different levels of discourse is followed as in Transmodel.
 Some new entities and attributes are added that are not present in Transmodel 5.1.
 A few existing Transmodel entities are refined or their semantics clarified, notably that the
Transmodel STOP POINT is actually a SCHEDULED STOP POINT and should be renamed as
such.
The Fixed Object submodels are expressed as an abstract model as per Transmodel, using the UML
notation and the relationships of "association" or "inheritance" between named entities. This is the
normative expression.
An example XML schema is provided as an informative concrete representation.
1.5.2 Level of Detail & Use of Partially Populated models
Different applications will be concerned to describe a STOP PLACE to different levels of detail. The
model is designed so that it may be used in sparsely or partially populated instances, as well as in fully
or densely populated implementations. For example, the model should still be useful if only data for
the Platforms of a Station are available, as opposed to a full data set that includes every access space,
entrance and accessibility. This enables an incremental approach to capturing data over time.
For journey planning applications it is in any case necessary to reduce the complicated structure of a
large interchange into a computationally tractable representation, and the model is designed to
support an efficient computation by reducing an interchange to a small number of nodes and edges for
the computation of navigation paths.
Thus there may be a difference between the data capture representation of a Stop Place, which aims
to describe the full physical details of a terminus in a general purpose representation suitable for
arbitrary data exchange, and a journey planning representation, which might be an optimised statically
computed simplification of the full model to reduce a full set of links to a simplified graph for computing
journeys and that is correlated with GIS, schedule and other data from other information layers. The
fixed object model is concerned to describe the data capture model, but to do this in a way that is
structured to meet the way that journey planners need to process and collate the captured data to
create their own efficient representations.
1.5.3 Data Administration
On a national scale, instances of a fixed object model can include large data sets (e.g. millions of
locations, hundreds of thousands of stop places) that need to be gathered and managed on a
distributed basis. The model should take into account how data can be partitioned into appropriate
small subsets for the purposes of exchange as the payload of generic data exchange services. The
IFOPT administrative model will support this.
Table 1 gives approximate total numbers of different types of fixed object nodes in an average
European country (the number of links to each node will be much larger). The numbers of instances of
different types of stop is significant both for their administration (it is the large data sets that must be
partitioned), and for the schemes used to identify instances for public reference. The length of the
public facing code should be large enough to handle the number of instances, yet should be as short
as possible in order to be usable by humans. Textual names of objects are also subject to usability
considerations. For some types of stop – for example airports or rail stations – the number of
instances is quite small and there are intuitive names (typically the town name) that can be used for
them. For other type of node, in particular bus stops and Points of Interest, there will be many more
than can be named or easily remembered and there will be a need to describe a stop in several
different ways, and with various qualifiers, to support stop finding and name discrimination tasks.
Table 1 — Indicative numbers of Access points
Indicative number of Fixed Object Entities per country

City, Town or District
0-100 000 City, Town or District Names
Names
Rail Stations 0-20 000 City or Towns
Bus /Tram Stops 50 000-500 000 Local Point Name
Ports & Ferry piers 2 000-20 000 City or Town Names or Local Name
Airports 0-500 Major Towns
Coach Stops 10 000-200 000 City or Town Names
Points of Interest 1 000 000-10 000 000 Local Point Name & National names
Data Administration
10-500 State, County names
Jurisdictions
Topographic Localities 10 000-500 000 State, County, City, Parish names

The informative XML XSD schema appended to this document gives an example of serialisation into
useful packages.
1.5.4 Stop Identification & Labelling
A particular use of Fixed Object model data is to enable stop and place finding by users of journey
planners and other on-line applications. This requires the appropriate association of entities with
topographical places. The Model is designed to allow for meaningful codes and labels to be
constructed according to many different application and usage contexts.
1.5.5 Relationship to GIS Standards
The Fixed Object model has a relationship to other standards describing the geographical features of
a country, but is not itself a GIS standard. The Fixed Object model describes the semantic structure of
stop places in a way that can be related to the Public Transport universe of discourse of Transmodel.
Transmodel and the Fixed Object model exclude the detailed description of geographic features, and
use standard GIS model elements to describe the GDF references needed to relate the Fixed Object
model entities to the underlying GIS models.
The Location models used in the Fixed Object need to be represented in a way such that they can be
projected onto a variety of geospatial representations. The Fixed Object model upholds the principles
from Transmodel of separation of information layers and the use of Point and Link representations
within the distinct layers which can be used to project elements between the models.
Point and Link and address data sufficient to make this projection are included in Fixed Objects: the
choice of coordinate reference systems is open.
1.5.6 Vertical Levels versus Altitude
Transport interchanges are often complex buildings with many interconnected levels. The labelling and
description of the levels is used in describing stops and directions in PT info systems and so needs to
be part of the Fixed Object model. This LEVEL is a distinct concept from that of a vertical spatial
coordinate in that it is a semantic label (for example "Departures", "Basement", "Floor 1", etc.). Altitude
is in effect the z coordinate of a POINT.
1.5.7 Security
The Fixed Object model describes data for exchange between responsible stakeholders. Such data
may include information that is for internal operational use rather than general public use. Where
appropriate, data can be flagged to indicate that its audience should be restricted.
1.5.8 Scope of Phase 1
This first part of the IFOPT Technical Specification is restricted in its scope to a core set of objects
relating to passenger information on public transport. We recognise that in future it may be useful to
consider additional fixed objects relevant for traffic and transport such as Traffic lights, pedestrian
crossings and Tariff Zones. Discussion of some of these elements needs to be in consultation with
other CEN Working Groups
The first part of IFOPT covers the following entities:
 Stop Model: Rail Stations, Metro Stations, Bus and Coach Stations, On-street bus, tram coach
and trolley bus stops and their associated Equipment. The same model may be used for Airports,
Ship and Ferry Ports, Taxi ranks and other access points.
 Point of Interest Model: Well known locations to which both Tourists and Residents are likely to
wish to Travel, such as Museums, Parks, Stadia, Galleries, Law Courts, Prisons, etc. A
classification mechanism is also provided.
 Topographical model: Cities, Towns, Hamlets, Suburbs and Quarters and other settlements to
which people may wish to travel and whose relation to Stop Places, Points of Interest and
Addresses is relevant. It includes an Address model.
 Administrative Model: An organisational structure or Administrators, roles and Administrative
Areas used to manage other data elements. The Fixed Object models are conceived as discrete
models, but share certain common concepts and base data type. Figure 2 indicates the
dependencies between the different Fixed Object Models. The Stop Place and Point of Interest
Models reference common concepts in the Administration and Topographical Models (though can
be used with a minimal implementation of these concepts). Further application views may be
constructed that reference some or all of the elements of the models. Further packages that
reference these models can be added in future.
The contents of the Stop Place Model and Point of Interest Model may be organised using elements
established in the Administrative and Topographical Model. All the models assume the existence and
reuse of common Address and generic data type packages. In any concrete implementation of the
individual Fixed Object models in XML, these can be based on reusable XML subschema, with the
logical dependencies shown in Figure 2. An informative XML schema is separately available at
http://www.ifopt.org.uk.
Figure 2 — Dependencies of Fixed Object Models
2 Normative references
The following referenced documents are indispensable for the application 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 12896:2006, Road transport and traffic telematics ― Public transport ― Reference data model
CEN/TS 15531:2007 (all parts), Public transport ― Service interface for real-time information relating
to public transport operations
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 12896:2006,
CEN/TS 15531:2007 (all parts) and the following apply.
3.1 Transport Related Terms
NOTE 1 This section includes terms for both PT entities and properties of PT entities used in IFOPT. For each
term, it is indicated whether the term derives from Transmodel version 5.1 (EN 12896:2006), another Technical
Specification (e.g. SIRI – CEN/TS 15531) or whether the term is specific to IFOPT. Definitions of most common
Transmodel and SIRI terms used in IFOPT are not repeated here (for example VEHICLE JOURNEY, JOURNEY
PATTERN, CONTROL ACTION), but a few are included where it is considered helpful to the reader (for example
STOP POINT).
NOTE 2 The glossary follows the Transmodel convention of using upper case to describe Transmodel entities,
for example STOP PLACE. It also uses upper case for IFOPT entities, as these may be regarded as candidates
for a future version of Transmodel. It furthermore follows the Transmodel practice of assigning particular
semantics to particular English nouns, for example POINT, ZONE and LINK each have connotations of a
particular spatial geometry, PLACE has a spatial implication (but not necessarily a topographic one), and GROUP
indicates a collective mechanism.
3.1.1
ACCESS LINK – Transmodel
physical (spatial) possibility for a passenger to access or leave the public transport system
NOTE 1 This link may be used during a trip for:
 The walking movement of a passenger from a PLACE (origin of the trip) to a STOP POINT (origin of the PT
TRIP); or
 The walking movement from a STOP POINT (destination of the PT TRIP) to a PLACE (destination of the trip).
NOTE 2 In IFOPT, a STOP PLACE, an ADDRESS, a POINT of INTEREST, a PARKING and a
TOPOGRAPHICAL PLACE are all types of PLACE and so an ACCESS LINK may also explicitly connect them.
3.1.2
ACCESS PATH LINK – IFOPT
type of external PATH LINK connecting a PLACE with another PLACE
NOTE 1 A sequence of ACCESS PATH LINKs may project onto an ACCESS LINK.
NOTE 2 Each end of an ACCESS PATH LINK should connect to an entity that is a concrete subtype of
PLACE, for example STOP PLACE, POINT OF INTEREST, ADDRESS, ROAD ADDRESS, QUAY, etc. that is an
ACCESSIBLE PLACE. Each end of an ACCESS PATH LINK may further have a specific ENTRANCE of the
same concrete subtype of PLACE associated with that end, that is, STOP PLACE ENTRANCE, QUAY
ENTRANCE, POINT OF INTEREST ENTRANCE, etc.; to indicate the exact entrance to the building.
NOTE 3 Inside a physical STOP PLACE, STOP PATH LINKs should be used instead of ACCESS PATH
LINKs.
3.1.3
ACCESS SPACE – IFOPT
passenger area within a STOP PLACE such as a concourse or booking hall, immigration hall or
security area that is accessible by passengers, but without a direct access to vehicles
NOTE Direct access to a VEHICLE is always from a QUAY and/or BOARDING POSITION. An ACCESS
SPACE may be a Room, Hall, Concourse, Corridor, or bounded open space within a STOP PLACE.
3.1.4
ACCESS SPACE ENTRANCE – IFOPT
entrance or exit for passengers to or from an ACCESS SPACE
NOTE An entrance may be Internal, giving access to another ACCESS SPACE or QUAY, in which case it
should connect to some other part of the same STOP PLACE; or External, representing a point of attachment with
which to navigate a route to the STOP PLACE.
3.1.5
ACCESS ZONE – Transmodel
ZONE for which the duration to cover any ACCESS LINK to a particular STOP POINT is the same
NOTE The IFOPT Concept of an ACCESS SPACE is distinct from the Transmodel concept of an ACCESS
ZONE as an ACCESS SPACE may have different NAVIGATION PATHS whose traversal takes different durations.
3.1.6
ACCESSIBLE PLACE – IFOPT
type of PLACE, such as a STOP PLACE, POINT OF INTEREST or ADDRESS, to which passengers
may wish to travel
NOTE An ACCESSIBLE PLACE may be the endpoint of a PATH LINK and can have designated entrances
that represent the best point of access for different USER NEEDs.
3.1.7
ACCESSIBILITY – IFOPT
possibility of a user with a specific USER NEED, such as a disability or encumbrance, to access either
fixed or moving Public Transport facilities
3.1.8
ACCESSIBILITY ASSESSMENT – IFOPT
ACCESSIBILITY characteristics of an entity used by passengers such as a STOP PLACE, or a STOP
PLACE COMPONENT, described by ACCESSIBILITY LIMITATIONs, and/or a set of SUITABILITies
3.1.9
ACCESSIBILITY LIMITATION – IFOPT
categorisation of the ACCESSIBILITY characteristics of a STOP PLACE COMPONENT such as a
STOP PATH LINK, STOP PLACE or ACCESS SPACE to indicate its usability by passengers with
specific needs, for example, those needing wheelchair access, step-free access or wanting to avoid
confined spaces such as lifts
NOTE A small number of well-defined categories are used that are chosen to allow the consistent capture of
data and the efficient computation of routes for different classes of user.
3.1.10
ACCESSIBILITY SUPPORT SERVICES – IFOPT
provision of services to enable guidance of specific classes of user, for example personal or auditory
or tactile device assistance for the blind, or visual devices and text announcement for the deaf, or
luggage porterage or language services
NOTE In IFOPT these are specified as types of LOCAL SERVICE.
3.1.11
ACTUAL STOP POINT EQUIPMENT – Transmodel
item of equipment of a particular type actually available at an individual STOP POINT (e.g. post,
shelter, seats, information display)
NOTE The IFOPT STOP PLACE EQUIPMENT is a generalisation of STOP POINT EQUIPMENT that may
include equipment located elsewhere in the STOP PLACE as well as on the QUAY.
3.1.12
ACTUAL VEHICLE EQUIPMENT – Transmodel
item of equipment of a particular type actually available in an individual VEHICLE
3.1.13
ADDRESS – IFOPT
descriptive data associated with a PLACE that can be used to describe the unique geographical
context of a PLACE for the purposes of identifying it
NOTE 1 It may be refined as either a ROAD ADDRESS, a POSTAL ADDRESS or both.
NOTE 2 An ADDRESS can be associated with a PLACE or POINT OF INTEREST where a trip can start or
end.
3.1.14
ADMINISTRATIVE AREA – IFOPT
grouping of STOP PLACE, PLACE or other managed data for management by a DATA
ADMINISTRATOR
NOTE 1 Each administrative area will have a common IDENTIFIER NAMESPACE for allocating identifiers.
NOTE 2 A distinction can be made between the management of the Transport of an area (the role of an
AUTHORITY managing an ADMINISTRATIVE ZONE) and the administration of the Transport related data (the
role of a DATA ADMINISTRATOR of an ADMINISTRATIVE AREA) which may be, but is not necessarily,
performed by the same body.
3.1.15
ALTERNATIVE COMMON NAME – IFOPT
Passenger Information systems will support the use of one or more names to identify PLACEs, STOP
PLACEs, DESTINATIONs, POINTs OF INTEREST, etc. to users in journey planners and other
systems
3.1.16
AREA IDENTIFIER NAMESPACE – IFOPT
IDENTIFIER NAMESPACE used to control the unique allocation of stop identifiers for each
ADMINISTRATIVE AREA, allowing the distributed management of STOP DATA
3.1.17
AUTHORITY – Transmodel
organisation under which the responsibility of organising the public transport service in a certain area
is placed
3.1.18
BOARDING POSITION – IFOPT
location within a QUAY from which passengers may directly board, or onto which passengers may
directly alight from, a vehicle
3.1.19
BOARDING POSITION ENTRANCE – IFOPT
entrance or exit for passengers to/from a BOARDING POSITION within a QUAY
3.1.20
CHECKPOINT– IFOPT
characteristics of a STOP PLACE COMPONENT representing a process, such as check-in, security
screening, ticket control or immigration, that may potentially incur a time penalty that should be
allowed for when journey planning
NOTE Used to mark STOP PATH LINKs to determine transit routes through interchanges.
3.1.21
CHECKPOINT DELAY– IFOPT
delay associated with a specific CHECKPOINT
NOTE The CHECKPOINT DELAY may vary according to time of day as specified by a VALIDITY
CONDITION, in line with the passenger processing capacity of the CHECKPOINT and traffic congestion levels.
3.1.22
CHECKPOINT PROCESS – IFOPT
classification of a CHECKPOINT as a par
...