The data in NeTEx is relevant for a number of types of mobile application – for example,  stop finding and journey planning. NeTEx includes web services that can be used to support certain mobile applications directly (e.g. stop finding); others such as journey planning or fare finding will typically involve a specialised API to an engine that is populated with NeTEx data. Note that the communication framework shared with SIRI v 2.0 also includes a specification for automatically mapping XML to JSON and other lightweight formats especially suitable for large scale mobile applications.

The NeTEx’s scope doesn’t include the actual retailing process – it covers only the products and fares that can be sold, along with all conditions of sale and use that accompany them. It can include information about available distribution channels and fulfilment methods needed to direct users towards the available retailing services. NeTEx can represent many of the ancillary elements relevant for retailing, since they are also relevant for some product definitions. For example passes and season tickets typically require a customer and a contract and because some modern products, are usage based such as pay as you go fares with capping,  it also includes a basic record of travel purchases for account based product use.

NeTEx doesn’t describe standards for the media used for tickets (for example the layout and content of a rail ticket), though it includes a ‘Travel document  concept that can be used to link to downstream retail systems that prescribe how a product should be materialized.

Yes, NeTEx include some SIRI based http protocols that can be used to request and return data in NeTEx format, embedding XML documents in the requests and responses.

NeTEx offers predefined SOAP and REST WEB Services.

Yes, NeTEx covers stations, networks, timetables and fares for Rail. The development process has involved experts from Rails (ERA, UIC, SNCF, ATOC, etc.) to make sure specific rails requirements are taken into account. The NeTEx design process included consideration of the B1, B2 and B3 Tap/TSI data models for European Rail fares as well as various national urban and suburban rail systems. NeTEx includes support for complex aspects of rail passenger information, such as journeys that join and split, train makeup, boarding positions on platforms, station and on-board facilities, accessibility and complex fare products. High value rail fare products often have complex conditions of use and NeTEx can describe these in a representation that gives both machine readable and human readable forms. Restrictions on routing (as in Tap/TSI  ‘Series’) can be described.  Multimodal products with rail components can also be described.

NeTEx can usefully be used to provision systems with the reference data needed to support real-time data, such as stops, lines, routes, timetables etc, but is not envisaged as a real-time data protocol. Real-time applications typically need to be optimised to exchange the data very quickly, very efficiently and specific protocols such as CEN SIRI are designed to do this. The NeTEx model can however be used to understand how the real-time data content of SIRI messages relates to the NeTEx & Transmodel models.

NeTEx model includes   additional data elements specifically to support stop and on board real-time systems, for example the headings to show on a vehicle at each stop, the stop announcements etc, that are not needed for simple timetable exchange such as by GTFS.

No, NeTEx defines an exchange format to exchange data between systems; it does not constrain the internal representation used by a given system to store or process the data, nor require the use of a specific database design. That said, any database supporting NeTEx data will need to have corresponding elements that can be mapped into the elements in the subset of NeTEx supported.

For more information refer to Transmodel for database modelling (http://transmodel-cen.eu/)

Spatial location is important for a number of NeTEx elements, for example to locate stops, but NeTEx is not of itself a GIS standard; rather it defines additional public transport related layers of information that may be projected onto a GIS data set. Thus for example a typical application such as a Journey Planner will seamlessly combine NeTEx data with map data address data to allow a user to plan travel from any location to any location. NeTEx uses a GML based coordinate system to reference GIS data, allowing a wide variety of GIS formats to be used (WGS84, National Ordnance Survey Grid, Lambert, etc). This should make it easy to combine NeTEx data with other data sets, and to support different GIS reference systems.

NeTEx also includes distinct concepts of topographic place and of administrative jurisdiction – again distinct from GIS location, but which can be mapped to other systems that give a spatial projection for reference. Thus stops can be located a serving a particular town or region (even as is sometimes the case for major interchanges, they are not physically contained within the geospatial boundaries).