In order to provide accurate journey plans, it is valuable to be able to specify realistic connection times between journeys at interchanges that take into account the mode of transport, the detailed topology of the interchange and even the mobility of the user (for example a path suitable for a wheelchair using a lift may take longer). NeTEx allows both default and specific transfers time to be specified for any connection.
NeTEx also permits complex operational rules about journey interchanges to be described so that planned and guaranteed connections can be managed and so that real time systems and real-time journey planners can give accurate advice to users.
Yes, NeTEx supports the specification of accessibility attributes on both the fixed infrastructure (drawn from the CEN IFOPT standard) and on vehicle types used for specific journeys, so that full accessibility aware journey planning can be provided, including micro-navigation through interchanges. Both accessibility properties and equipment for different disabilities (e.g. wheelchair spaces, navigability, tactile strips etc) and accessibility services (e.g. boarding assistance) can be defined. Furthermore NeTEx defines a set of user needs (e.g. wheelchair, blindness, push chairs, etc ) that a journey planning engine can use to set criteria to find the optimal journey for a given set of accessibility criteria.
Frequency based serves are typically specified as operating at a given interval, rather than particular times. From a passenger point of view multiple journeys will typically be presented as a single journey running at an approximate interval, for example “every six to 10 minutes”. NeTEx uses TEMPLATE VEHICLE journeys to describe such journeys. From an operational point of view there will still need to be specific service journeys scheduled to fulfil the required frequency of service and NeTEx can also include these to support real time journeys.
Part 2 of NeTEx includes reusable components for constructing timetables of journeys from reusable components, NeTEx separates the concerns of where the timing of a PT route takes place (The TIMING PATTERN made up of TIMING POINTs and TIMING LINKs) from the actual timing values (which are held separately as RUN TIMEs and WAIT TIMEs). Different sets of timing values belong to different TIME DEMAND TYPEs (Peak, off peak, late night etc) can be used with the same TIMING PATTERN to generate accurate timetables for journeys at different times of day.
NeTEx can be used to describe zone based fare systems of any topology ranging from a simple patchwork (adjacent zones) to the complex, (honeycomb, doughnut) etc). The TARIFF ZONE allows zones to be associated with stops and stations. Mixed zonal and stage systems are also possible. Fare pricing may be a flat fare system per zone, or zone to zone using a (DISTANCE MATRIX ELEMENT), or be differentially priced for particular sequences of zones (using FARE STRUCTURE ELEMENTs in SEQUENCE)
Among the many different usage conditions that can be specified for NeTEx fare products are restrictions on the type of user – child, senior, student, disabled, etc using a USER PROFILE that may be given precise eligibility criteria (e.g. on age, membership, domicile, etc). A GROUP PROFILE allows the number and makeup of groups to be specified; it can also be used to specify companion criteria for disabled users and other special cases.
Some fare products only allow travel at particular times – such constraints can be expressed using USAGE PARAMETERs. Others only allow travel for a particular duration; FARE STRUCTURE ELEMENTs with TIME STUCTURE FACTORs can be used to describe the different durations. Furthermore, sometimes journey time is related to journey length, so for example a longer time is allowed for a two zone trip than a one zone trip; all this can be precisely specified in NeTEx.
Temporal conditions may also apply to the purchase or refund of tickets, likewise expressed as USAGE PARAMETERs attached to fare products.
As well as the routine examples given above, NeTEx can also handle more complex cases. For example, in the periphery of a large city, off peak times may start at different times in each station since by the time a journey to the centre starting from the station ends, the peak period will have ended.
Yes, one of the strengths of NeTEx is that it takes a global view of data identification, allowing data elements from different name spaces to be exchanged in the same schema.
For long distance travel, especially on-rail, there is increasing used of yield managed fares with dynamic pricing, provided by web services. Note that such applications increase rather than decrease the need for standards such as NeTEx as such applications nonetheless require a machine readable definition of the access rights fare structure and usage conditions that apply to the products for which prices are supplied. Furthermore the search parameters used to find the best fare for a user (such as age, possession of rail cards, fulfilment method etc) need to correspond to the properties of the fare product. The NeTEx Part3 specification and UML model includes an annex showing a sample fare query which shows all the NeTEx model elements relevant for constructing a Fare API.
Yes. Electronic payment cards such as OV Chipkart (NL), Oyster (London region), Navigo (Paris region) Sube T (Madrid), BIP Card (Turin) are becoming increasingly common and etc transport operators are able to devises increasingly sophisticate products . For example Oyster has fares that adjust according to consumption, capping the cost of trips made in a day to that of a day pass. NeTEx is able to describe the fare structures and scope and conditions for such complex products, as well as to supporting an record of consumption for account based products. (A NeTEx SALES TRANSACTION records an individual PRODUCT SALE).
As products on cards are physical invisible to the user, the ability to create user readable representations become increasingly important – such applications require a machine readable format with corresponding human readable rendering, such as is available through NeTEx.
Yes, unlike classical route and timetable standards, NeTEx is also designed to support FTS (Flexible Transport Service) and DRT (Demand Responsive Transport). DRT and FTS often cover similar services; FTS being more generic since flexibility may not be directly linked to the demand, but may be related to some operating needs or cost optimisations.
The flexibility can be applied to the line, route and stop structure (areas, corridors, hail and ride, etc.) or to their scheduling (dynamic and/or demand responsive passing times, with all necessary booking arrangements and contact details).
Yes, NeTEx includes full support for internationalisation. All text elements may be created in multiple languages so that place names and other names and descriptions can be provided in one or more languages. Other aspects important for multiregional use are parameterized such as time zones, currency, etc and the Calendar functions allow conditions based on different national holidays to be described.
Yes, every NeTEx data element can be versioned, and multiple versions can coexist. Coherent sets of data are assembled for exchange using a ‘version frame’, which itself has a version and knows the version of the elements in it. There are specific types of version frame for different type of data that ar commonly exchanged together (SERVICE, TIMETABLE, FARE etc).
Yes, one of the additional capabilities of NeTEx is the ability to define and exchange the full topology of a network as presented in simplified view to a user (often with presentational attributes such as colour) , with non-directional network segments, loops etc, while also retaining a projection onto the actual underlying stops and route. This allows automatic creation of interactive map applications.
- The LINE element names the line and sets basic properties.
- The LINE NETWORK and LINE SECTION elements can be used to described the topology
- The ROUTE, ROUTELINK, and ROUTE POINT elements can be used to define the directional elements of the underlying line
- The SCHEDULED STOP POINT can be used to define the stops of a line
All these objects can have their own geographic positions and geometry or an be projected onto a custom drawn map using a SCHEMATIC MAP element.
Yes, NeTEx allow arbitrary user defined code classifications for elements using the has TYPE OF STOP, TYPE OF LINE and other ‘Type of Entity’ elements that . In addition NeTEx, to encourage standardised use, also provides fixed enumerations of many commonly found classifications of specific elements, including types of equipment, on-board facilities, etc. The ‘Key Value’ extension mechanism allows Also allows additional user defined attributes to be added, which can include classifiers.