Google General Transport Feed Specification (GTFS) is a widely used format for distributing timetables to third parties. The NeTEx and GTFS formats should be considered as complementary, covering different stages in the data management process: NeTEx is “upstream”, GTFS is “downstream”. NeTEx differs from GTFS in that it has a much wider scope, and that it is intended for use in back office use cases under which data is generated, refined and integrated (requiring the exchange of additional elements used to construct the timetable) , rather than just for provisioning journey planning systems (the prime purpose of GTFS).
GTFS covers stops, lines, and timetabled journey information (Gtf trips) sufficient to answer basic journey planning queries. It supports only a few simple types of fare product . GTFS data identifiers are specific to each data set and require registration of an identifier with Google.
NeTEx covers many other aspects of Public Transport Information apart from timetables (e.g. network descriptions, fare products,), as well as supporting a richer timetable model for export including journey patterns, timing patterns, joined journeys, train makeup, connection timings, etc. . This makes it able to exchange the data sets used to build timetables as well as the resulting timetables themselves. NeTEx includes the additional information needed to provision real-time systems (such as destination displays) and to link to operational systems (such as blocks) It also includes versioning and validity condition mechanisms to support the repeated peer-to peer integration of many data from many different parties.
Because it uses XML, NeTEx is able to package a complete data set as a single coherent document that can be managed and validated.
GTFS uses a traditional flat file format; this is compact and efficient but requires multiple files to describe the different types of element and thus additional rules for naming and packaging the files as a zip. Custom written tools are need to interpret and process the data.
It is possible to generate a full GTFS data set from NeTEx but not vice versa. The NeTEx UML includes a GTFS mapping package which shows how each GTFS element may be populated from the corresponding NeTEx element.
There are three different TAP /TSI standards for fares; m – B1 (standard fares) B2 (Integrated Reservation fares) and b3 (special fares), each using different models (with some common elements between B1 and B3) and quite different representations of the classes of user conditions, NeTEx is able to represent the elements and attributes of all three models with a single uniform model, based on access rights, using in particular DISTANCE MATRIX ELEMENTs to describe the point to point fares and USAGE PARAMETERs to describe the different conditions applying to the the rail products. Only a small number of FARE PRODUCTS are needed to describe the standard rail products. A number of sales conditions also relate to rail products and can be describe using SALES PACKAGES with NeTEx DISTRIBUTION CHANNELs and FULFILMENT elements. The mapping of most elements is straightforward and it is straightforward to create transformations using simple mapping tools such as those found in the XML SPY product suite.
The TapTSI standars make used of a number of UIC code sets (all represented in NetEx as either sets of enumerated values or ‘Types of value’ or in the case of station and oboard facilities as various types of Facility or Equipment. Stations (Locations in UIC terminology) can be uniformly represented in NeTEx as Scheduled Stop points.
For details on the Tap/TSi model see the UML model of the mapping and the mapping specifications.
The official start of BISON, the platform for Beheer Informatie Standaarden Openbaar Vervoer Nederland (Management Information Standards Public Transport Netherlands), took place on 16 September 2008. The BISON platform is the result of an earlier decision on the part of the National Mobility Deliberations (NMB) to set up a management organisation for the further development of collective standards and the incorporation of these standards, insofar as possible, in existing concessions.
The main function of the BISON platform is to formulate, manage, harmonise and monitor all of the information standards that facilitate the exchange of information within the public transport sector.
BISON considers NeTEx to be the standard of choice for the future. Parts of the standard have been applied and used within BISON (e.g. Part 3 – Fares). In due time BISON will migrate from its national PT information exchange standard to NeTEx, and in due time NL specific BISON profile(s) will be developed which will help to exchange travel information with other countries such as Germany ann Belgium.
Interoperable fare management (IFM) encompasses all systems and processes designed to manage the distribution and use of fare products in an interoperable public transport environment. Such systems are called interoperable when they enable the customer to use a portable electronic medium (e.g. a contact/contactless smart card) with compatible equipment (e.g. at stops, with retail systems, at platform entry points or on board vehicles).
IFM-Part 1 is an ISO standard (ISO 14014-1) aiming at the definition a reference functional architecture for Interoperable Fare Management System(s) and to identify the requirements that are relevant to ensure Interoperability between several Actors in the context of the use of electronic tickets. The exchanges between IFM actors are described from the functional point of view by the IFM standard, without the specification of data exchange format.
NeTEx- Part 3 describes fare elements as specified in public transport fare systems (zonal fares, flat fares, progressive fares, distance matrix, etc) and the resulting fare products using a conceptual data model, specifies a detailed physical data model for fares and derives data exchange message formats for fare exchange. The exchanges are concerning the information on fares (abstraction being made from any particular medium), on the conditions of use of fare products, on associated fare product distribution channels. Parameters necessary for the price calculation of fare products are also provided.
IFM is a process description and NeTEx is a data exchange format.
The Transmodel based Nordic Public Transport Interface Standard (NOPTIS) provides a consistent set of XML-exchange protocols covering both planned and real time aspects. One of these exchange protocols is the Data Input Interface (NOPTIS DII). This exchange protocol is optimised to transfer version-managed information concerning Network, Timetable, Vehicle Schedule, Services and other data to a PTA integrator system and is used extensively in Sweden and Denmark. NOPTIS DII was a significant input to NeTEx. There exists a mapping between NeTEx and NOPTIS DII covering the Calendar, Timetable and Vehicle Schedule aspects showing how to use NeTEx in a way that supports parallel partial data deliveries as in NOPTIS.
NEPTUNE is a French standard for data exchange in the domain of Network Topology and Timetables. It is based upon a draft EN version of Transmodel and incorporates several features of IFOPT as regards stop typology, equipment and accessibility characteristics. It is comparable as regards the functional coverage to NeTEx-Part 1&2, but smaller regards to number of data covered.
TransXChange, the UK national timetable standard, together with NaPTAN, the UK stop data standard, provides a functional equivalent subset of to the NeTEx stop and timetable elements in NeTEx Part1 & NeTEx Part2 and it is straightforward to map these to the contents of a NeTEx timetable frame. Both standards are based on Transmodel and allow the exchange of structural information such as timing information and journey patterns, The NeTEx representation is in many respects simpler, but is less specific about which elements must be present, and what the restrictions of values are. NeTEx also includes many additional elements in Part 1 & Part 2 that are not in TransXChange, including support complex for rail journeys, interchanges rules, . schematic maps, etc. TransXChange does not support fares and nearly all of NeTEx Part 3 is outside of its scope. The result of 2004 FareXChange study of UK Bus Fares was a significant input into NeTEx.
TransXChange also includes a small number of additional registration elements to support the Electronic Bus Service Registration process of the UK Vehicle Licensing authority (VOSA). Some of the registration concepts (such as administrative areas) have equivalents in NeTEx, but a few of them are specific to the UK regulatory context and are not supported by NeTEx. It would be possible to add a separate UK extension to NeTEx to include these.
Since NeTEx was influenced by existing European national standards and reference exchange protocols it also ensures compatibility with VDV452 (“VDV Standard Interface Network / Timetable” reference exchange protocol in Germany) at the level of conceptual and physical model. The aim of the VDV452 is to transfer network definitions and timetables from a source system into a target system, i.e. the timetable data from a scheduling program is transferred to consumer systems for the purpose of transit operations. NeTEx’s physical model provides specific elements (i.e. ExternalStopPointRef, ExternalJourneyRef, ExternalInterchangeRef, etc.) for VDV compatibility, specifically for use in AVMS systems.
A comparison between NeTEx and VDV452 is available at: www.vdv.de/netex.
IFOPT, similarly to Transmodel specifies a data model, whereas the primary aim of NeTEx is to define data exchange format. IFOPT has been integrated into the latest version of Transmodel (v6) and thus (see above) builds the basis for the NeTEx physical submodel dedicated to Fixed Objects for Public Transport. This data domain is concerned with particular different types of sites (and their components), such as points of interest, parking or stops and related objects like equipment, for instance, but also pedestrian navigation paths and takes into account accessibility characteristics. NeTEx specifies the exchange of the data defined by the IFOPT model.
NeTEx is primarily dedicated to data exchange, i.e. an XML message format and a protocol are specified. The content model of the NeTEx message structure is based upon the NeTEx physical data model and is derived directly from Transmodel, the CEN Public Transport Reference Data Model developed at a conceptual level and independent of an implementation in any specific technology.
As regards functional domains, NeTEx covers only a subset of Transmodel; the Network Topology, Timing Information, Vehicle Scheduling and Fare Information domains, whereas the full scope of Transmodel is broader, including in addition: Operations Monitoring and Control, Fare Management ( sales, validation, control), Management Information and Statistics, Driver Management: Driver Scheduling, Rostering, and Driving Personnel Disposition.
The Transmodel conceptual model is broken down into modular packages with a mostly linear dependency graph between modules. The same organisation of packages is used in the Phsyical model and XML schema so that there is a direct correspondence between the modules for each functional domain. This makes it straightforward to relate the high level design to the implementation.