NeTEx (Network Timetable Exchange) defines a standard for exchanging public transport passenger information data in XML format.
The functional scope of NeTEx is divided into three parts, each covering a functional subset of the CEN Transmodel conceptual model for Public Transport Information:
- Part 1 describes the fixed Network (stops, routes, lines, etc.);
- Part 2 is mainly focused on Timetables
- Part 3 covers Fare data.
All three parts use the same framework of reusable components, versioning mechanism, validity conditions, support to allow the uniquely identification of data elements in a global context, etc., defined in Part 1. NeTEx also includes container elements called “VERSION FRAMES” to group data into coherent sets for efficient exchange.
NeTEx deliverables comprise:
- a CEN Specification document (in three parts),
- a data model in the standard UML modelling language
- an accompanying XML schema providing a formal electronic description that can be used by data processing software.
Data in NeTEx format is encoded as XML documents that must conform exactly to the schema – standard XML validator tools can check conformance automatically. The schema can also be used to create bindings to different programming languages, automating part of the implementation process for creating software that supports NeTEx formats. Some example XML document encoding different data sets and exchange functions are provided along with the schema.
In effect, documents in NeTEx format are computer files that can be exchanged by a wide variety of protocols (http ftp, email, portable media, etc). In addition, a SIRI based protocol is specified for use by online web services.
The common SIRI framework is used to describe a specific NeTEx/data service (SIRI-NX) with specialized messages that can be used to request and return messages containing data in NeTEx format, as well as publish/subscribe messages for push distribution. The SIRI-NX responses return a NeTEx XML document that satisfies the request criteria (and also conforms to the NeTEx schema). There is a WSDL binding for this SIRI NeTEx service to make it easy to implement services and service clients as http requests.
A NeTEx service need only implement those elements of relevance to its business objectives – extraneous elements present in the binding can be ignored. Parties using NeTEx for a particular purpose will typically define a “PROFILE” to identify the elements that must be present and the code sets to be used to identify them, for example a French NeTEx profile has been defined that specifies the use of NeTEx for the exhange of NeTEx data.
Whereas TAP/TSI uses optimized flat files that aggregate different fare conditions and prices into a small number of records with dense semantics, NeTEx uses a parameterized approach, with discrete atomic elements that may be combined in many different ways and a ready-made library of almost all known fare conditions. This gives a high level of reuse, and richer semantics, that is, the ability to capture more complex conditions and additional types of fare – but requires a greater effort to understand in the first place. NeTEx uses a uniform design style and coding conventions, which, once grasped, helps to reduce the learning curve
Recently, a Part 4 has been defined describing the European Profile for NeTEx, focusing on information relevant to feed passenger information services and excluding operational and fares information.
The NeTEx extension for New Modes addresses the development of a data exchange format dedicated to the publication of data concerning ‘Alternative Modes’ (as requested in EU COMMISSION DELEGATED REGULATION (EU) 2017/1926 of 31 May 2017). This work will generate Net Part 5 focusing on (but not a limitation to) car sharing, cycle sharing, carpooling, car/cycle rental. It is primarily oriented towards static data (describing the service that is offered and associated infrastructure, more than its current running status). The corresponding real-time information is provided by SIRI.
This NeTEx extension is based on the Transmodel extension for New Modes (Transmodel is the data model, and NeTEx the exchange protocol). Additional input (GBFS, DATEX II, OCPI, MDS, etc.) will also be taken into account.
NeTEx already covers a lot of the needs to describes new modes (Site, Location, Role, Connection, Trip, Journey, Vehicle Type, Parking, Passing Time, etc.). Therefore, New Modes will mostly reuse concepts and will just add a few attributes and concept to the existing ones.
More information available in the document NeTEx extension for New Modes – Scope and overview