Content

Harmonization of exchange methodology between different systems is essential to:

Entur AS on behalf of Jernbanedirektoratet

for travellers

for public transport operators

for third-party service providers

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:

1. Network Topology (CEN TS 16614-1)

2. Scheduled Timetables Plan data (CEN TS 16614-2)

3. 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: frameworkPreview

• Information about StopPlaces: stopsPreview

• Information about Transport Network Information: networkPreview

• Information about Timetable: timetablePreview

• Information about Fares faresPreview

• Information about Sales salesPreview

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.

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 format

• TS 16614-2, Network and Timetable Exchange (NeTEx) - Part 2: Public transport scheduled timetables exchange format

• EN 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)

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.

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.

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.

When frames are not grouped in a CompositeFrame, all relevant frames must have explicitly defined ValidityConditions.

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).

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.

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:

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.

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.

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).

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.

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.

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).

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.
  
  

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.

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.

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.

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

Each object is described with a table:

The inheritance hierarchy is described in the following way:

The first column is omitted if the table only contains elements (it is used to separate attributes and elements).

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:

1. Simple Enumeration
   When the datatype is set to xxxEnumeration (for example FacilitySetEnumeration), it means only one value is allowed:

   ... <facilitySet>seatingOnly</facilitySet> ...

   
   
   

2. 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> ...

    

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. The time zone in effect at noon (12:00, DayOffset = 0) on the SERVICE JOURNEY's OPERATING DAY is used.

Scenario: DST ends at 03:00 on Sunday, October 26, 2025 (Clocks move back: 03:00 becomes 02:00)

Service Journey A

• Operating day: Saturday, October 25 (DST)

• Noon on October 25 is in DST, therefore all times use DST

The time 03:30:00 with DayOffset +1 represents "03:30 DST on the next calendar day after Saturday", which when experienced by passengers on Sunday will be 02:30 Standard Time.

Service Journey B

• Operating day: Sunday, October 26 (Standard Time)

• Noon on October 26 is in Standard Time, therefore all times use Standard Time

Note: Clock time 02:30 occurs twice on Sunday (once in DST, once in Standard). Since the operating day is Sunday (Standard Time), 02:30:00 refers to the Standard Time occurrence.

Service Journey C

• Operating day: Saturday, October 25 (DST)

• Noon on October 25 is in DST, therefore all times use DST

Both times are DST times on Saturday's operating day, even though passengers experience the time on stop 2 on Sunday in Standard Time.

Service Journey D

• Operating day: Sunday, October 26 (Standard Time)

• Noon on October 26 is in Standard Time, therefore all times use Standard Time

• Journey starts before midnight on Saturday

Since the operating day is Sunday (Standard Time), all times must be encoded in Standard Time. The wall-clock time 00:25 DST equals 23:25 Standard Time on the previous calendar day, so it's encoded as 23:25:00 with DayOffset -1.

Scenario: DST begins at 02:00 on Sunday, March 30, 2025 (Clocks move forward: 02:00 becomes 03:00)

Service Journey E