General information: NeTEx
- Copy Page Tree
- Johan Wiklund
- Hans Inge Letnes
Content
Preface
Harmonization of exchange methodology between different systems is essential to:
Entur AS on behalf of Jernbanedirektoratet
...in order to efficiently collect all timetable data from each data provider, ensure consistency of data, and increase data quality. This allows the creation of multimodal information systems which may be used to implement nationwide journey planning solutions and publicize business neutral information to all interested parties.
for travellers
...in order to present relevant, and high-quality journey suggestions.
for public transport operators
...in order to re-use the data in their own journey planning-, ticketing-, and information systems, and offer a better service to their customers.
for third-party service providers
...in order to minimize unnecessary costs related to supporting multiple different exchange formats, and to contribute to the continued growth of standardized public transport data exchange.
Introduction
NeTEx (CEN TS 16614-1, 16614-2 og 16614-3) is a CEN-standard which defines the data format and description for public transport data exchanges. The standard is based on Transmodel (EN 12896), and the reference model for permanent objects required for access to public transport: IFOPT (Identification of Fixed Objects in Public Transport, EN 28701).
NeTEx supports the exchange of data necessary for stop place information, journey planning, and ticketing, and is divided into three main categories:
Network Topology (
CEN TS 16614-1)Scheduled Timetables Plan data (
CEN TS 16614-2)Fare Information (
CEN TS 16614-3)
NeTEx was created by CEN / TC278 / WG3 / SG9 lead by France. The final part of the format was published in 2015. The format was created to support the needs of a collection of public transport data providers in Europe, among others ERA (European Rail Agency) and UIC (International Union of Railways).
NeTEx is a general-purpose XML format that facilitates the exchange of complex public transport data between distributed systems. Data in the NeTEx format should be used to effectively update various information and operational applications through both file-based services and web service architectures. The official website contains a detailed explanation of the intention underlying the standard, data models and publicly available standard documentation. In particular, "NeTEx White Papers", available under the website's Downloads-section provides a good introduction to how different concepts in public transport can be modelled using NeTEx.
NeTEx is a comprehensive data format intended to describe different concepts for public transport data in various ways. In many cases, there will be parts of the specification that exceed requirements in actual implementation. Therefore, the extraction of necessary objects, which constitute a so-called NeTEx profile, should be made. Such a profile should be used to specify which parts of the NeTEx format are expected to be exchanged between systems in a given context.
This document describes NeTEx's profile Norway for the exchange of stop and timetable data between external actors and central systems provided by Entur. Moreover, this profile has been prepared with the assistance of the NeTEx working group in CEN (Comité européen de normalisation, the European Committee for Standardization).
To reduce complexity, the profile is divided into several parts:
Reusable Components: framework
Information about StopPlaces: stops
Information about Transport Network Information: network
Information about Timetable: timetable
Information about Fares fares
Information about Sales sales
Each section describes data objects that belong to a given functionality. In addition, basic objects reused across the dataset are separated into a "commons" section.
References
The Norwegian NeTEx profile is based on the following documents:
TS 16614-1, Network and Timetable Exchange (NeTEx) - Part 1: Public transport network topology exchange formatTS 16614-2, Network and Timetable Exchange (NeTEx) - Part 2: Public transport scheduled timetables exchange formatEN 12896, Road Transport and traffic telematics - Public transport - Reference data model (Transmodel)EN 28701, Intelligent transportation systems - Public transport - Identification of Fixed Objects in Public Transport (IFOPT)
Exchanging information
Information exchanged in the NeTEx format should be XML files containing only one root tag: PublicationDelivery
The information should be delivered with one XML file per Line, packed as ZIP-file with a flat structure (no subdirectories). It is technically possible to deliver each line separately, packed in separate ZIP-files if all the data objects used by each Line are defined within its PublicationDelivery. However, in order to avoid issues with overwriting and ensure good data update/deletion management, it is strongly recommended that only complete datasets containing all lines are exchanged. Data objects used by multiple Lines can be defined in a separate "common" XML-file (must be prefixed with an underscore, e.g. "_common.xml") to avoid redundancy of unique objects.
Each PublicationDelivery must contain the following two mandatory fields:
<PublicationTimestamp> [data extraction time] </PublicationTimestamp><ParticipantRef> [codespace for data submitter] </ParticipantRef>
Within a PublicationDelivery, <dataObjects> are defined, which consist of a set of Frames. Each frame contains all relevant objects in a single group and specifies common validity conditions, e.g. validity and version. This mechanism supports incremental updating of individual objects in cases where the relationships between the objects are not altered and will assist in troubleshooting down to the object- or group level.
PublicationDelivery allows for any number of frames, and the same frame type can be reused multiple times. It is good practice to use as few frames as possible so that the grouping within the same PublicationDelivery is appropriate (avoid "wrapping" objects into their own frames). Objects that naturally belong together, i.e. have the same version and validity, must be collected in the same frame.
XML example for PublicationDelivery can be found in the GitHub-repository.
Data submission in CompositeFrame
When grouping Frames into a CompositeFrame, ValidityCondition must be the same for all its frames. That is, ValidityCondition is not set per frame, but is implicitly controlled from the CompositeFrame.
Data submission as single frames
When frames are not grouped in a CompositeFrame, all relevant frames must have explicitly defined ValidityConditions.
Generalization
In NeTEx, objects can be placed at many different levels, in whichever way is most purposeful. In order to avoid redundancy, the Norwegian profile dictates that all descriptions and references should be as high up in the hierarchy as possible.
For example, Operator can be referenced from the individual ServiceJourney in Timetable, but in most cases, a Line will have only one main operator. This should, therefore, be referenced in Line, and any exceptions will instead be overwritten per ServiceJourney (with reference to "additionalOperators" in Line).
Versioning
To ensure compatibility, NeTEx offers version control mechanisms which allow both sender and recipient to:
Specify the NeTEx version used
Ensures correct data handling when the parties in the exchange use different versions.
Correct usage of exchanged data by the recipient.
Notifications when using outdated elements etc.
Version control is based on the version attribute (VersionFrame) and should be placed on relevant objects as high up in the hierarchy as possible.
Version for profile
When submitting NeTEx XML for stop place information, or time table data, the NeTEx version has to be specified in order to instruct the recipient of how to read the data. This is accomplished by stating the profile version of the dataset.
Profile version is defined in a version attribute for the XML's PublicationDelivery root node.
Formats for profile version:
[NeTEx XSD-version]:[ProfileName]:[Profile-version]
NeTEx xsd-version is a numeric value specifying the NeTEx XSD (XML Schema) version being used (format X.Y)
NO-NeTEx-<profilnavn> is the profile name with one of the following values:
stops
networktimetable
fares
Profile version is a numeric value specifying the Norwegian NeTEx-profile version being used (format X.Y)
Examples:
Id | Meaning |
|---|---|
version="1.08:NO-NeTEx-stops:1.3" | NeTEx XSD version 1.08 with data according to Norwegian stops-profile version 1.3 |
version="1.08:NO-NeTEx-networktimetable:1.3" | NeTEx XSD version 1.08 with data according to Norwegian networktimetable-profile version 1.3 |
When the NeTEx format or the profile is updated, it will usually be backward compatible. When backward compatibility is not possible, both active versions will be considered valid and supported, until otherwise stated.
Versions for data elements
Individual elements are also versioned, and here it is up to the creator of the dataset to define a versioning system.
The version number must be a positive whole number (integer).
The version number must be increased in such a way that the latest version of the object always has the highest number.
Elements that must have versions
Most objects with an ID must also have a version (see Example catalogue for more details) to ensure all changes lead to an increase of version number.
The following changes are particularly important, and require incremental versioning:
Changes in Network/GroupOfLines.
Changes in Line (same ID, new version).
Changes in organisations (Authority, Operator - same ID, new version).
Changes in geographical data/positions for objects.
New additional information (such as AlternativeName).
Smaller corrections which impact information to the public (such as changes of departure times).
version="any"
NeTEx allows you to explicitly specify that an object is not versioned by defining the version attribute as "any".
An object defined outside the submitted dataset, such as external objects from the national stop place registry will always be the "current" version.
Versioning in references
A version attribute for references to a unique object defined in the same PublicationDelivery is required. This means that a reference to an element defined within the same XML-file must be versioned. References to external objects are not versioned.
Note that when referring to an object with both id and version, the consistency validation of the XML-file will require the existence of the object referred to (with the same referred id and version) within the same file. This also applies when the version is defined as "any".
For the same reason, when referring to external objects (for example an ID in the national stop place registry), the version attribute must be omitted in order for the XML file to be valid.
When the version attribute is stated on a reference, this reference is validated against existing objects with the same "ID + VERSION" in the current PublicationDelivery. Because XML validation uses string comparison in Schema validation it is not possible to use version="any" for references to objects with explicit version numbers. If there are several possible versions of the objects defined internally in the file, and a reference to the latest version is desired, a reference without version attributes should be used (just like when referencing external objects).
Validity for data elements
All objects with a version attribute must have a validity. Validity can be implicitly based on inherited values, or defined explicitly on the object through ValidityConditions. ValidityConditions can be set for a single line or a set of lines.
This is done in one of the following ways:
ValidityCondition set explicitly per frame in PublicationDelivery.
ValdityCondition for a CompositeFrame, which contains all the frames in PublicationDelivery.
This defines a validity which is inherited by all objects in the dataset and applies implicitly to all subordinate frames. It is not possible to override the ValidityCondition for frames which are grouped within a CompositeFrame.
Data elements which can override validity (ValidityCondition)
All underlying data elements implicitly inherit validity defined by the ValidityCondition of the frame, i.e. either its VersionFrame or a grouping CompositeFrame. When it is necessary to override inherited validity on subordinate objects, they can be given their own explicit ValidityConditions:
Overriding ValidityCondition is defined per object.
Overriding ValidityCondition is constrained by its inherited validity. This means the overriding validity must have a shorter time span than the inherited value.
Overriding is supported by the following objects:
Network
lines
organisations (Authority, Operator)
routes
serviceLinks
journeyPatterns
Overriding of Timetable- and ServiceCalendar related data must be done in a complete TimetabelFrame, and ServiceCalendarFrame with an unambiguous ValidityCondition for its child elements.
Conventions
Structure of ID's
The ID attribute of NeTEx objects must follow a common pattern, and should be structured in the following way:
[codespace]:[type]:[identification]
codespace
Codespace uniquely represents the owner, creator, or administrator of the data. (See List of current Codespaces.)type
Type should always be the name of the NeTEx data type, using exactly the same spelling as implemented in the NeTEx XSD (for example ResourceFrame, TransportMode, Network, Line, StopPlace, Quay etc.)identification
Identification must be a value which, in the context of the first two parts (codespace + type) of the ID, uniquely identifies the data object. Please note that the identification string can only use numbers (0-9), lowercase (a-z) and uppercase (A-Z) letters, dash (-) and underscore (_), in any combination.
Object | ID examples: |
|---|---|
Line | RUT:Line:ABC |
Route | RUT:Route:3434 |
RoutePoint | RUT:RoutePoint:43423342-3424 |
Static ID's
When exchanging stop place information (StopPlace, Quay etc.) with the central database, usage of nationally defined ID's is required. This ensures data integrity and uniformity over time.
It is recommended that all data objects describing continual public transport services, such as Line, Route, or ServiceJourney also maintain static ID's across datasets, even if each dataset contains changes to them. This makes the collection and use of historical data easier, as well as linking to the dataset from other datasets (between codespaces).
It would then likewise be important to not reuse ID's when there are significant changes to Lines etc.
Codespace
Just as namespace is used to identify a unique XML Schema, codespace is used in NeTEx to ensure that all elements and attributes in the XML are unique when combined with other datasets. The central agency (Entur) assigns each data provider a unique codespace, consisting of a three letter code, for example, "KOL" for the provider Kolumbus. Each dataset must have the correct codespace to pass validation.
Cardinality
Cardinality is a property which describes the number of instances of XML elements per document, as well as whether the element is required or not, according to the Norwegian NeTEx profile.
0: 1- Optional - None, or a maximum of 1 instance allowed.0: *- Optional - None, or a maximum of 1 or more instances allowed.1: 1- Required - At least one instance is required, but no more than one.1: *- Required - At least one or more instance is required.
Type description
Each object is described with a table:
<Inheritance hierarchy> | ||||
|---|---|---|---|---|
Attribute/Element | Name | Type | Cardinality | Description |
The inheritance hierarchy is described in the following way:
Class < ParentClass < ParentClass < ... < ParentClass
The first column is omitted if the table only contains elements (it is used to separate attributes and elements).
DataManagedObject < EntityInVersion < Entity | ||||
|---|---|---|---|---|
Name | Type | Cardinality | Description | |
attr | responsibilitySetRef | ResponsibilitySetIdType | 1: 1 | Points to roles and responsibility areas connected to STOP PLACE, BOARDING ZONE or ACCESS ZONE |
elem | keyList | KeyList | 0: 1 | A set of key-value pairs which describes additional properties for the relevant object (LINE, STOP PLACE, BOARDING ZONE, PLANNED STOP POINT etc.), and necessary for third-party systems (eg. ticketing, journey-planning, real-time) |
elem | Extentions | ExtentionStructure | 0: 1 | Extension element for data not defined by NeTEx. |
elem | BrandingRef | BrandingRefStructure | 0: 1 | Reference to Brand (e.g. Ruter, AtB) |
Use of Enumeration
The profile documents describe the various NeTEx-objects used in Norway, with relevant fields and datatypes. Some data types are Enumeration, that is a list of predefined values allowed for the field.
There are two ways to use Enumeration:
Simple Enumeration
When the datatype is set to xxxEnumeration (for example FacilitySetEnumeration), it means only one value is allowed:... <facilitySet>seatingOnly</facilitySet> ...List of Enumerations
When the datatype is set to xxxListOfEnumerations (for example MealFacilityListOfEnumerations), it means multiple values are allowed for the same element:... <mealFacilityList>breakfast dinner drinks</mealFacilityList> ...
PassingTimes when switching to and from Daylight Savings Time
Review needed. The text is easily misunderstood, and there are issues with the current model.
When JOURNEYs starting before the daylight savings time switch and operates during the switch, i.e. when the time of a time zone is changed from winter time to summer time skipping the hour between 02:00 (am) and 03:00 (am) and correspondingly when changed from summer time to winter time adding an extra hour between 02:00 (am) and 03:00 (am), all PASSING TIMEs of a SERVICE JOURNEY should be provided using the same reference time as for the regular OPERATING DAYs / Dates of the JOURNEYs.
This means the JOURNEYs affected by the daylight savings time change must still specify the regular sequence of PASSING TIMEs of a journey starting before 02:00 (am).
Inherently, journey planner systems and other timetable data consumers must themselves ensure their algorithms correctly manage local alignment (per given time zone) for the affected Dates, and automatically display recalculated PASSING TIMEs when daylight savings time changes.
In the case of JOURNEYs with an extraordinary service alteration like changed JOURNEY PATTERN or PASSING TIMEs for the service(s) affected by daylight savings time switch(es), e.g. if the service waits an hour during the switch to catch up to its regular schedule, this must be reflected in specialized DATED SERVICE JOURNEYs replacing the regular SERVICE JOURNEY for the affected OPERATING DAY / Date.
Change from winter time to summer time (the clock switches forward)
JOURNEYs that have PASSING TIMEs occurring between 02:00 (am) and 03:00 (am) during the switch from Wintertime to Summertime, when the clock is advanced one hour at 02:00 (am), must have these PASSING TIMEs provided as for the regular winter time in which the JOURNEYs start (i.e. 02:xx etc.)
Meaning that when 02:00 (am) instantly becomes 03:00 (am), the system(s) using this data must recalculate PASSING TIMEs to the actual time (i.e. 03:xx, correspondingly) for the affected JOURNEYs.
Example
Provided passing times:
01:45 - 01:55 - 02:05 - 02:15…
Should for the switch be calculated to:
01:45 - 01:55 - 03:05 - 03:15...
JOURNEYs and OPERATING DAYs starting between 02:00 (am) and 03:00 (am) during the switch from winter time to summer time (missing the hour between 02 and 03 am) will implicitly be cancelled in order to realign the schedules.
Change from summer time to winter time (the clock switches backwards)
JOURNEYs that have PASSING TIMEs occurring between 02:00 (am) and 03:00 (am) during the switch from Summertime to Wintertime, when the clock is turned back one hour at 03:00 (am), must have these PASSING TIMEs provided as for regular summer time in which the JOURNEYs start (i.e. 02:xx etc.)
Meaning that when 03:00 (am) goes back again and the clock becomes 02:00 (am) for the second time, the system(s) using this data must recalculate PASSING TIMEs to the actual time (i.e. 02:xx, correspondingly) for the affected JOURNEYs.
Example
Provided passing times:
02:45 - 02:55 - 03:05 - 03:15…
Should for the switch be calculated to:
02:45 - 02:55 - 02:05 - 02:15...
JOURNEYs and OPERATING DAYs starting between 02:00 (am) and 03:00 (am) during the switch from summer time to winter time (adding an extra hour between 02:00 and 03:00 am) should per default be serviced twice for the affected night, and thus requires planning of an extra service for the second time the affected SERVICE JOURNEYs starts (i.e. after the clock has been switched from 03:00 back to 02:00 am).
However, if the case is that this departure should only be serviced once during the switch from summer time to winter time, or it is for any other reason more appropriate to do so, this exception must be handled by replacement DATED SERVICE JOURNEYs for the affected JOURNEYs:
For DATED SERVICE JOURNEYs only serviced for the first occurence of 02:xx (am), this must be modeled for the previous day (on which summer time is still in affect) added a DepartureDayOffset of +1.
Example
Departure only on the first occurrence when switching from summer time to winter time
<DepartureTime>02:22:00</DepartureTime>
<DepartureDayOffset>1</DepartureDayOffset>
<dayTypes>
<DayTypeRef ref="ENT:DayType:Saturday"/>
</dayTypes>
For DATED SERVICE JOURNEYs only serviced for the second occurence of 02:xx (am), this must be modeled for the current day (on which winter time takes effect). For explicitness, it may also have added a DepartureDayOffset of ‘0’.
Example
Departure only on the second occurrence when switching from summer time to winter time
Definitions
Description of all NeTEx terminology used in the profile:
Term | Definition |
|---|---|
The physical (spatial) possibility for a passenger to access or leave the public transport system. 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). | |
Specialisation of PLACE EQUIPMENT dedicated to access (e.g. lifts, entrances, stairs, ramps, etc.). | |
An area within a STOP PLACE that does not give direct access to transport vehicles. Can be connected to QUAYS by PATH LINKs. | |
The 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. | |
A 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. | |
An item of EQUIPMENT of a particular type actually available in an individual VEHICLE. | |
The 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. Can further be specified as either a ROAD ADDRESS, a POSTAL ADDRESS or both. | |
A PLACE which may have an address. | |
A set of allowed DIRECTIONs that can be used on a given ROUTE. | |
An alternative name for the entity. | |
A set of properties to be applied to another element. It has a name and an order. | |
A specialisation of LOCAL SERVICE for ASSISTANCE providing information like language, accessibility trained staff, etc. | |
The organisation under which the responsibility of organising the transport service in a certain area is placed. | |
VALIDITY CONDITION stated in terms of DAY TYPES and PROPERTIES OF DAYs. | |
The work of a vehicle from the time it leaves a PARKING POINT after parking until its next return to park at a PARKING POINT. Any subsequent departure from a PARKING POINT after parking marks the start of a new BLOCK. The period of a BLOCK has to be covered by DUTies. | |
A location within a QUAY from which passengers may directly board, or onto which passengers may directly alight from, a VEHICLE. | |
An arbitrary marketing classification. | |
Characteristics of e.g. SITE COMPONENT or SERVICE JOURNEY, 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. | |
A shared set of LINKS or POINTs. A part of a public transport network where the ROUTEs of several JOURNEY PATTERNs are going in parallel and where the synchronisation of SERVICE JOURNEYs may be planned and controlled with respect to commonly used LINKs and STOP POINTs. COMMON SECTIONs are defined arbitrarily and need not cover the total lengths of topologically bundled sections. | |
A VEHICLE TYPE composed of a sequence of more than one vehicles of the type TRAIN. | |
Contact details for ORGANISATION for public use. | |
A complete journey operated by a coupled train, composed of two or more VEHICLE JOURNEYs remaining coupled together all along a JOURNEY PATTERN. A COUPLED JOURNEY may be viewed as a single VEHICLE JOURNEY. | |
A specialisation of PLACE ACCESS EQUIPMENT for CROSSING EQUIPMENTs (zebra, pedestrian lights, acoustic device sensors, tactile guide strips, etc.). | |
Specialisation of PLACE EQUIPMENT for cycle storage. | |
An ENTITY in VERSION that can be associated with a RESPONSIBILITY SET that describes who has responsibility for managing the data. | |
The DATA SOURCE identifies the system which has produced the data. References to a data source are useful in an interoperated computer system. | |
A type of day characterized by one or more properties which affect public transport operation. For example "weekday in school holidays". | |
Associates a DAY TYPE with an OPERATING DAY within a specific Calendar. A specification of a particular DAY TYPE which will be valid during a TIME BAND on an OPERATING DAY. | |
A non-service VEHICLE JOURNEY. | |
The physical (spatial) possibility for a passenger to change from one public transport vehicle to another to continue the trip. It specifies default times to be used to change from one mode of transport to another at an area or national level as specified by a TOPOGRAPHIC PLACE, STOP AREA or SITE ELEMENT. It may be restricted to a specific MODE or OPERATOR or only apply in a particular direction of transfer, e.g. bus to rail may have a different time for rail to bus. | |
A variant text of a NOTICE for use in a specific media or delivery channel (voice, printed material, etc). | |
An advertised destination of a specific JOURNEY PATTERN, usually displayed on a headsign, on the front of a vehicle, or at other onboard locations. This information can be updated dynamically as the journey progresses, in particular when crossing VAI points. | |
Alternative DESTINATION DISPLAY, generally aimed at specific media (SMS, email, etc). | |
A classification for the general orientation of ROUTEs. | |
An outlet for selling a product. | |
Any data instance to be managed in an operational Version Management System. When several data sources coexist (multimodality and/or interoperability), an ENTITY has to be related to a given DATA SOURCE in which it is defined. | |
The ENTITY associated to a given VERSION. | |
A physical entrance or exit to/from a SITE. Can be a door, barrier, gate or another recognizable point of access. | |
A specialisation of PLACE ACCESS EQUIPMENT for ENTRANCEs (door, barrier, revolving door, etc.). | |
An item of equipment installed either fixed (PLACE EQUIPMENT) or on-board vehicles (VEHICLE EQUIPMENT). A service (LOCAL SERVICE such as LEFT LUGGAGE, TICKETING SERVICE) is considered as immaterial equipment as well. | |
Designated Place within a SITE for locating EQUIPMENT. | |
A set of FACILITIES that may be associated with an ENTITY and subject to a specific VALIDITY CONDITION. | |
An immaterial marketable element (access rights, discount rights etc), specific to a CHARGING MOMENT. | |
A specialisation of a FLEXIBLE QUAY (which is abstract) to identify what is the catchment area for a flexible service (so that a stop finder can find the nearest available types of transport). It is a named zone visited by a particular mode of transport. It is part of the SITE data set rather than the service data set, since it can be defined, and exists independently from an actual service. | |
A specialisation of LINE for flexible service. As all the service on a LINE may not all be flexible, flexibility itself is described at JOURNEY PATTERN level (meaning that a separate JOURNEY PATTERN is needed for each type of flexibility available for the line). | |
Set of properties describing the flexible characteristics of a LINK. A composition is used with LINK in order to avoid multiple inheritances and a type explosion of link subtypes | |
Set of characteristics describing the possible flexibility of POINTs. A composition is used with POINT in order to avoid multiple inheritances. | |
A physical ZONE such as a section of a road where a flexible service is available on demand. The existence of the zone makes the services visible to journey planners looking for available services for an area. | |
A specialisation of ROUTE for flexible service. May include both point and zonal areas and ordered and unordered sections. | |
Additional characteristics of a FLEXIBLE SERVICE. A service may be partly fixed, partly flexible. | |
Assignment of a SCHEDULED STOP POINT to a FLEXIBLE STOP PLACE and quay. etc. | |
A specialisation of the STOP PLACE describing a stop of a FLEXIBLE SERVICE. It may be composed of FLEXIBLE AREAs or HAIL AND RIDE AREAs identifying the catchment areas for flexible services (when they use areas or flexible quays). Some FLEXIBLE SERVICE also uses regular STOP PLACEs for their stops. When assigned to a SCHEDULED STOP POINT the corresponding SCHEDULED STOP POINT is supposed to be a ZONE (the centroid point of the ZONE being the SCHEDULED STOP POINT). | |
The frequency of Journey. (Type for a HEADWAY INTERVAL.) | |
A grouping of ENTITies which will be commonly referenced for a specific purpose. | |
A VALIDITY PARAMETER ASSIGNMENT specifying generic access rights for a class of products (e.g. a time band limit - 7 to 10 a.m. - for trips made with a student pass). | |
A grouping of DISTRIBUTION CHANNELs. | |
A set of ENTITies grouped together according to a PURPOSE OF GROUPING, e.g. grouping of stops known to the public by a common name. | |
A grouping of lines which will be commonly referenced for a specific purpose. | |
A group of OPERATORs having, for instance, common schemes for fare collection or passenger information. | |
A group of SERVICEs, often known to its users by a name or a number. | |
A grouping of SALES OFFER PACKAGEs | |
A grouping of STOP PLACEs which will be commonly referenced for a specific purpose. The term corresponds to a specialisation of standard Transmodel concept GROUP OF ENTITIES. | |
A section of Road between two points within which one may hail a bus to board it or alight from it or ask it to stop to alight. | |
A time interval or a duration defining a headway period and characterizing HEADWAY JOURNEY GROUP (e.g. every 10 min, every 4-6 min). | |
A group of VEHICLE JOURNEYs following the same JOURNEY PATTERN having the same HEADWAY INTERVAL between a specified start and end time (for example, every 10 min). This is especially useful for passenger information. | |
The scheduled possibility for transfer of passengers between two SERVICE JOURNEYs at the same or different STOP POINTs. | |
Common properties of VEHICLE JOURNEYs and SPECIAL SERVICEs, e.g. their link to accounting characteristics. | |
A group of JOURNEYs defined in order to describe special behaviour like frequency-based services or rhythmical services (runs all xxh10, xxh25 and xxh45... for example; this is especially useful for passenger information). | |
Headway interval information that is available for all the VEHICLE JOURNEYs running on the JOURNEY PATTERN for a given TIME DEMAND TYPE, at a given TIMING POINT. This is a default value that can be superseded by VEHICLE JOURNEY HEADWAY. This information must be consistent with HEADWAY JOURNEY GROUP if available (HEADWAY JOURNEY GROUP being a more detailed way of describing headway services). | |
Time allowance at the end of each journey on a specified JOURNEY PATTERN, to allow for delays and for other purposes. This layover supersedes any global layover and may be superseded by a specific VEHICLE JOURNEY LAYOVER. | |
A time constraint for one or several SERVICE JOURNEYs fixing interchanges between them and/or an external event (e.g. arrival or departure of a feeder line, the opening time of the theatre, etc.). | |
A part of a VEHICLE JOURNEY created according to a specific functional purpose, for instance in situations when vehicle coupling or separating occurs. | |
Two JOURNEY PARTs of different VEHICLE JOURNEYs served simultaneously by a train set up by coupling their single vehicles. | |
An ordered list of SCHEDULED STOP POINTs and TIMING POINTs on a single ROUTE, describing the pattern of working for public transport vehicles. A JOURNEY PATTERN may pass through the same POINT more than once. The first point of a JOURNEY PATTERN is the origin. The last point is the destination. | |
The JOURNEY PATTERN RUN TIME is the time taken to traverse a TIMING LINK in a particular JOURNEY PATTERN, for a specified TIME DEMAND TYPE. If it exists, it will override the DEFAULT SERVICE JOURNEY RUN TIME and DEFAULT DEAD RUN RUN TIME. | |
The JOURNEY PATTERN WAIT TIME represents the time a vehicle has to wait at a specific TIMING POINT IN JOURNEY PATTERN, for a specified TIME DEMAND TYPE. This wait time can be superseded by a VEHICLE JOURNEY WAIT TIME. | |
The time it takes to traverse a TIMING LINK in a particular JOURNEY PATTERN, for a specified TIME DEMAND TYPE. If it exists, it will override the DEFAULT SERVICE JOURNEY RUN TIME and DEFAULT DEAD RUN RUN TIME. | |
Time-related information referring to journey timing whose value depends on the time of use and so can be associated with a TIME DEMAND TYPE, TIME BAND or OPERATIONAL CONTEXT. | |
The time a vehicle has to wait at a specific TIMING POINT IN JOURNEY PATTERN, for a specified TIME DEMAND TYPE. This wait time can be superseded by a VEHICLE JOURNEY WAIT TIME. | |
A list of alternative Key values for an element. | |
An identified storey (ground, first, basement, mezzanine, etc) within an interchange building or SITE on which SITE COMPONENTs reside. A PATH LINK may connect components on different levels. | |
A group of ROUTEs which is generally known to the public by a similar name or number. | |
A description of the topological connectivity of a LINE as a set of LINE SECTIONs. This is sufficient to draw a route map for the whole line including branches and loops. | |
A part of a NETWORK comprising an edge between two nodes. Not directional. | |
An oriented spatial object of dimension 1 in view of the overall description of a network, describing a connection between two POINTs. | |
A SERVICE LINK or TIMING LINK in a JOURNEY PATTERN with its order in that JOURNEY PATTERN. | |
The order of a LINK in a LINK SEQUENCE to which it belongs. | |
An ordered sequence either of POINTs or of LINKs, defining a path through the network. | |
The position of a POINT with a reference to a given LOCATING SYSTEM (e. g. coordinates). | |
A specialisation of CUSTOMER SERVICE for LUGGAGE SERVICE (provides luggage service attributes like luggage trolley, free to use, etc.). | |
A designated path between two places. May include an ordered sequence of PATH LINKs. | |
A named grouping of LINEs under which a transport network is known. | |
A text for informational purposes on exceptions in a LINE, a JOURNEY PATTERN, etc. The information may be useful for passenger or driver information. | |
The assignment of a NOTICE showing an exception in a JOURNEY PATTERN, a COMMON SECTION, or a VEHICLE JOURNEY, possible specifying at which POINT IN JOURNEY PATTERN the validity of the NOTICE starts and ends respectively. | |
A day of public transport operation in a specific calendar. An OPERATING DAY may last more than 24 hours. | |
A continuous interval of time between two OPERATING DAYs which will be used to define validities. | |
A company providing public transport services. | |
A legally incorporated body associated with any aspect of the transport system. | |
A named subdivision of an ORGANISATION. | |
A named place where Parking may be accessed. Can be a building complex (e.g. a station) or an on-street location. | |
An area within a PARKING. | |
The capacity of a PARKING. | |
PARKING specific properties other than its CAPACITY. | |
Equipment for passengers that may be in a fixed within a STOP PLACE. | |
The allocation of a SCHEDULED STOP POINT (i.e. a SCHEDULED STOP POINT of a SERVICE PATTERN or JOURNEY PATTERN) to a specific STOP PLACE for a SERVICE JOURNEY, and also possibly a QUAY and BOARDING POSITION. | |
Time data concerning public transport vehicles passing a particular POINT; e.g. arrival time, departure time, waiting time. | |
A designated point, inside or outside of a STOP PLACE or POINT OF INTEREST, at which two or more PATH LINKs may connect or branch. | |
A link between any two PLACEs (That is STOP PLACEs, ACCESS SPACEs or QUAYs, BOARDING POSITIONs, POINTs OF INTEREST etc or PATH JUNCTIONs) that represents a step in a possible route for pedestrians, cyclists or other out of vehicle passengers within or between a PLACE. | |
A geographic place of any type which may be specified as the origin or destination of a trip. A PLACE may be represented as a POINT (dimension 0) , a road section (dimension 1) or a ZONE (dimension 2). | |
A specialisation of PLACE EQUIPMENT for LIGHTING EQUIPMENT (e.g. lamp post). | |
A 0-dimensional node of the network used for the spatial description of the network. POINTs may be located by a LOCATION in a given LOCATING SYSTEM. | |
A POINT in a LINK SEQUENCE indicating its order in that particular LINK SEQUENCE. | |
A type of SITE to or through which passengers may wish to navigate as part of their journey and which is modelled in detail by journey planners. | |
A ROUTE POINT used to define a ROUTE with its order on that ROUTE. | |
An oriented correspondence from one POINT of a source layer, onto an entity in a target layer: e.g. POINT, LINK, LINK SEQUENCE, COMPLEX FEATURE, within a defined TYPE OF PROJECTION. | |
A specification of ADDRESS refining it by using the attributes used for conventional identification for mail. Comprises variously a building Identifier, Street name, Postcode and other descriptors. | |
A FARE PRODUCT consisting of one or several VALIDABLE ELEMENTs, specific to a CHARGING MOMENT. | |
An oriented correspondence - of the shape of an ENTITY on a source layer, - onto an ENTITY in a target layer: e.g. POINT, LINK, LINK SEQUENCE, COMPLEX FEATURE, - within a defined TYPE OF PROJECTION. | |
A property which a day may possess, such as school holiday, weekday, summer, winter etc. | |
A place such as a platform, stance, or quayside where passengers have access to PT vehicles, Taxi, cars or other means of transportation. A QUAY may serve one or more VEHICLE STOPPING PLACEs and be associated with one or more STOP POINTS. A QUAY may contain other sub QUAYs. A child QUAY must be physically contained within its parent QUAY. | |
A specialisation of PLACE ACCESS EQUIPMENT for RAMPs (provides ramp attributes like length, gradient, etc.). | |
Whether and how the product may be refunded. | |
A specialisation of ADDRESS refining it by using the characteristics such as road number, and name used for conventional identification of along a road. | |
A specialisation of PLACE EQUIPMENT for rough surfaces, giving properties of surface texture, mainly for impaired person information. | |
An ordered list of located POINTs defining one single path through the road (or rail) network. A ROUTE may pass through the same POINT more than once. | |
An oriented link between two ROUTE POINTs allowing the definition of a unique path through the network. | |
A POINT used to define the shape of a ROUTE through the network. | |
A group of VEHICLE JOURNEYs following the same JOURNEY PATTERN having the same "rhythm" every hour (for example, ‘runs at xxh10, xxh25 and xxh45 past the hour’) between a specified start and end time. | |
Specification of codes assigned to particular VEHICLE JOURNEYs when operated by TRAINs of COMPOUND TRAINs according to a functional purpose (passenger information, operation follow-up, etc.) | |
SALES OFFER PACKAGE that may be used to substitute base SALES OFFER PACKAGE. | |
A SANITARY FACILITY, e.g. WC, Shower, baby change. | |
A POINT where passengers can board or alight from vehicles. | |
A map representing schematically the layout of the topographic structure of PLACEs (e.g. a set of SITEs) or the public transport network (a set of LINEs). It can include a pixel projection of a set of ENTITies onto a bitmap image so as to support hyperlinked interactions. | |
Projection of a transport network object on a SCHEMATIC MAP. | |
A collection of DAY TYPE ASSIGNMENTs. | |
A constraint on the use of a service. The service, on this specific JOURNEY PATTERN (usually an FTS JOURNEY PATTERN), cannot operate when another (regular) service operates. This may occur only on a subpart of the JOURNEY PATTERN, or only on one or some specific SCHEDULED STOP POINTs within the pattern. | |
Set of FACILITies available for a SERVICE JOURNEY or a JOURNEY PART. The set may be available only for a specific VEHICLE TYPE within the SERVICE (e.g. carriage built with a low floor). | |
A passenger-carrying VEHICLE JOURNEY for one specified DAY TYPE. The pattern of working is in principle defined by a SERVICE JOURNEY PATTERN. | |
The scheduled possibility for transfer of passengers between two SERVICE JOURNEYs at the same or different STOP POINTs. | |
A LINK between an ordered pair of STOP POINTs. Service links are directional - there will be separate links for each direction of a route. | |
The use of a SERVICE LINK in a specified order within a JOURNEY PATTERN or SERVICE PATTERN. | |
A specialisation of WAITING EQUIPMENT for a SHELTER. | |
SIGN EQUIPMENT can define signs visible to passengers at places in a SITE, such as PLACE SIGNS, DIRECTION SIGNs, etc. these can be used to provide guidance. | |
A type of PLACE, such as a STOP PLACE, POINT OF INTEREST or ADDRESS, to which passengers may wish to travel. A SITE can have designated ENTRANCEs that represent the available points of access for different USER NEEDs. | |
The physical (spatial) possibility for a passenger to change from one public transport vehicle to another to continue the trip, determined by physical locations, such as SITEs and/or its components and/or ENTRANCEs, in particular, STOP PLACEs and/or its components. Different times may be necessary to cover the resulting distance, depending on the kind of passenger. | |
A type of PLACE specifying common properties of a SITE or a SITE COMPONENT to describe it., including accessibility. | |
A specialisation of PLACE EQUIPMENT for SITEs (e.g. LUGGAGE LOCKER, WAITING EQUIPMENT, TROLLEY STAND, etc.) | |
Set of enumerated FACILITY values that are relevant to a SITE (names based on TPEG classifications, augmented with UIC etc.). | |
A passenger-carrying VEHICLE JOURNEY for one specified DAY TYPE. The pattern of working is in principle defined by a SERVICE JOURNEY PATTERN. | |
The allocation of a SCHEDULED STOP POINT (i.e. a SCHEDULED STOP POINT of a SERVICE PATTERN or JOURNEY PATTERN) to a specific STOP PLACE, for either a Passenger JOURNEY or VEHICLE SERVICE. | |
A place comprising one or more locations where vehicles may stop and where passengers may board or leave vehicles or prepare their trip. A STOP PLACE will usually have one or more well-known names. | |
A physical area within a STOP PLACE, for example, a QUAY, BOARDING POSITION, ACCESS SPACE or EQUIPMENT PLACE. | |
A POINT in a JOURNEY PATTERN which is a SCHEDULED STOP POINT. | |
A statement of whether a particular USER NEED can be met. It can be used to state whether a SITE can be accessed by a passenger with a particular USER NEED. | |
A ZONE used to define a zonal fare structure in a zone-counting or zone-matrix system. | |
A VEHICLE JOURNEY with a set of frequencies that may be used to represent a set of similar journeys differing only by their time of departure. | |
A repeating VEHICLE JOURNEY for which a frequency has been specified, either as a HEADWAY JOURNEY GROUP (e.g. every 20 minutes) or a RHYTHMICAL JOURNEY GROUP (e.g. at 15, 27 and 40 minutes past the hour) has been specified. | |
A specialisation of PASSENGER EQUIPMENT for TICKETING | |
A specialisation of PASSENGER EQUIPMENT (PLACE EQUIPMENT) for TICKET VALIDATOR. | |
A period in a day, significant for some aspect of public transport, e.g. similar traffic conditions or fare category. | |
A set of timetable data (VEHICLE JOURNEYs, etc.) to which the same VALIDITY CONDITIONs have been assigned. | |
Long-term planned time data concerning public transport vehicles passing a particular POINT IN JOURNEY PATTERN on a specified VEHICLE JOURNEY for a certain DAY TYPE. | |
An ordered pair of TIMING POINTs for which run times may be recorded. | |
The position of a TIMING LINK in a JOURNEY PATTERN. This ENTITY is needed if a TIMING LINK is repeated in the same JOURNEY PATTERN, and separate information is to be stored about each iteration of the TIMING LINK. | |
A POINT against which the timing information necessary to build schedules may be recorded. | |
A NODE in a JOURNEY PATTERN which is a TIMING POINT. | |
A type of PLACE providing the topographical context when searching for or presenting travel information, for example as the origin or destination of a trip. It may be of any size (e.g. County, City, Town, Village) and of different specificity (e.g. Greater London, London, West End, Westminster, St James s). A TOPOGRAPHICAL PLACE must always have an official name. | |
A vehicle composed of TRAIN ELEMENTs in a certain order, i.e. of wagons assembled together and propelled by a locomotive or one of the wagons. | |
A specification of the order of TRAIN ELEMENTs in a TRAIN. | |
An elementary component of a TRAIN (e.g. wagon, locomotive). | |
An instance of a TRAIN making up a COMPOUND TRAIN. | |
The association of a TRAIN COMPONENT at a SCHEDULED STOP POINT with a specific STOP PLACE and also possibly a QUAY and BOARDING POSITION. | |
The possibility of a passenger to transfer between two PLACEs. May have times associated with the transfer. | |
The time it takes to complete a TRANSFER. | |
Classification of a Service. | |
A parameter used to specify the use of a SALES OFFER PACKAGE or a FARE PRODUCT. | |
A set of all possible price features of a USAGE PARAMETER: discount in value or percentage etc. | |
A simple version of a VALIDITY CONDITION. Comprises a simple period. NO UNIQUENESS CONSTRAINT. | |
Condition used in order to characterise a given VERSION of a VERSION FRAME. A VALIDITY CONDITION consists of a parameter (e.g. date, triggering event, etc.) and its type of application (e.g. for, from, until, etc.). | |
An ACCESS RIGHT PARAMETER ASSIGNMENT relating a fare collection parameter to a theoretical FARE PRODUCT (or one of its components) or a SALES OFFER PACKAGE. | |
External event defining a VALIDITY CONDITION. E.g exceptional flow of a river, bad weather, road closure for works. | |
A public transport vehicle used for carrying passengers. | |
The planned movement of a public transport vehicle on a DAY TYPE from the start point to the endpoint of a JOURNEY PATTERN on a specified ROUTE. | |
Headway interval information that is available for a VEHICLE JOURNEY (to be understood as the delay between the previous and the next VEHICLE JOURNEY). This information must be consistent with HEADWAY JOURNEY GROUP if available (HEADWAY JOURNEY GROUP being a more detailed way of describing headway services). | |
A time allowance at the end of a specified VEHICLE JOURNEY. This time supersedes any global layover or JOURNEY PATTERN LAYOVER. | |
The time it takes to traverse a specified TIMING LINK IN JOURNEY PATTERN on a specified VEHICLE JOURNEY. This gives the most detailed control over times and overrides the DEFAULT SERVICE JOURNEY RUN TIME and JOURNEY PATTERN RUN TIME and the DEFAULT DEAD RUN RUN TIME. There may be different times for different TIME DEMAND TYPES. | |
The time for a vehicle to wait at a particular TIMING POINT IN JOURNEY PATTERN on a specified VEHICLE JOURNEY. This wait time will override the JOURNEY PATTERN WAIT TIME. | |
Type of VEHICLE. | |
A group of operational data instances which share the same VALIDITY CONDITIONs. A version belongs to a unique VERSION FRAME and is characterized by a unique TYPE OF VERSION. | |
A child ENTITY whose RESPONSIBILITY SET must be the same as its containing parent object, and which cannot exist independently of its parent in a repository, for example, a POINT IN PATTERN. Thus in practice, if the parent is deleted, so will the child be. | |
A location (e.g. a ROUTE POINT) used to distinguish a ROUTE from another ROUTE. It may be used for DESTINATION DISPLAYs | |
A specialisation of SITE EQUIPMENT for WAITING EQUIPMENTs (shelter, waiting room, etc.). | |
A two-dimensional PLACE within the service area of a public transport operator (administrative zone, TARIFF ZONE, ACCESS ZONE, etc.). | |
An oriented correspondence from one ZONE in a source layer, onto a target entity: e.g. POINT, COMPLEX FEATURE, within a defined TYPE OF PROJECTION. |