BSI DD CEN/TS 28701:2010

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.

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 rereferenced 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