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