Building a ticketing platform based on Transmodel and NeTEx

There is an ongoing debate in Europe at the moment concerning booking integrations for the railway sector, especially across borders. This is an important part of facilitating the shift from personal cars to more sustainable modes of transport. Some argue that the Open Sales and Distribution Model (OSDM) should be the preferred integration standard, whilst others point to the CEN standard of Transmodel, with its NeTEx data delivery format. In this article, I will share the experiences from Entur of using the Transmodel standard in creating a data-driven, multimodal ticketing platform, handling everything from long distance rail to zonal tickets and local ferries.

To sum it up — if you’re in a hurry — our experience is that Transmodel is well-suited for creating ticketing solutions for a multi-modal world of public transport. The standard facilitates a data driven approach, enabling public transport operators (and authorities) to provide their offerings to a larger market. Creating APIs based on this model is also very beneficial, as it lays the foundation for utilizing NeTEx data from the National Access Points (NAPs). Finally, Transmodel is well suited for railway offerings as well, and we have achieved a seamless ticketing integration between rail and other modes of public transport in Norway — which paves the way for more collaboration between the actors, and better services from the entire public transport sector.

What is Transmodel and NeTEx

First, we should probably take a moment to define (or explain) what Transmodel and NeTEx actually is. Transmodel is a CEN data model standard of modeling various concepts related to public transport. It is the official standard referenced in the MMTIS regulation and it is the basis for the NeTEx specification. Now, NeTEx is a data delivery standard (or a recipe) of how to deliver data from a data provider to a data consumer. Many think of this as solely a file exchange — and it sort of is — but it could also be delivered through other means, such as an API or an event stream.

It is easy to confuse these two terms, and a popular belief is that NeTEx and Transmodel are the same. However, the one thing (NeTEx) is based on the other (Transmodel), which means that concepts expressed in NeTEx will always be possible to utilize via Transmodel elements. This is probably the most important point to stress going forwards in this article — NeTEx is by default compatible with other Transmodel concepts.

NeTEx is mainly in use today as a format for publishing timetable data from public transport operators to the National Access Point (NAP). The MMTIS also defines that fares data (products and rates/prices) should be published in NAP, but this is not widely adopted yet in Europe. At Entur, we use Transmodel and NeTEx for timetable data, tripplanning, products, offerings, orders and account based ticketing (ABT).

Building a platform based on Transmodel/NeTEx

Background

Entur is a government-owned company responsible for building and running a national trip planning service and a national ticketing platform for public transport throughout Norway, both railways and other modalities. Since 2015 Entur has been working on creating a fully NeTEx and SIRI based digital infrastructure for public transport information. On top of this, OpenTripPlanner was the first national service created by Entur to provide JourneyPlanning-as-a-service. This was done to provide harmonized public transport information easily available to users of the Norwegian public transport system, and at the same time be compliant with the, then upcoming, MMTIS regulation. All supported by the foundation of Transmodel.

So when the time came to start working on the ticketing part of the platform, it was natural to build solutions based on Transmodel in this area as well. The theory was to become data-driven throughout the platform, and use timetable data along with product data to build a ticketing system that would allow for rapid product development and real-time, multi-modal ticketing on a whole new level, compared to the previous system. The previous system wasn’t all that bad by the way, it was just built for something completely different from what we were tasked with building now.

Data quality

One important aspect of a data-driven platform is of course data quality. In order to build a ticketing system based on (among other things) timetable data, we need to ensure that all the data providers adhere to the same specifications. Otherwise, it would be difficult to use their data in a ticketing context. We solved this by working together with the operators to create these specifications, and then validate the data when they provide it to our platform. At the moment, we don’t validate all aspects of the timetable data for use in a ticketing context. We do comprehensive validation on the timetable data to ensure data quality, but the ticketing often requires additional timetable parameters. This is mainly because not all operators that provide timetable data sell tickets on our platform as well. But, in general, transparency is the best data validation tool. If an operator uploads a data set with incorrect data, our data-driven approach means that this gives the traveler bad data and a bad experience — which the operators try to avoid. So it’s a kind of experienced data validation, and this often motivates the operators to deliver high data quality from the start.

Using product data

So — how do you create an offer and a ticket based on NeTEx data? Well, it’s not that complicated actually — but since we at Entur were the first to do it, it took us a while to figure it out. The basic concept is that we use the different parts of NeTEx to build services that integrate with each other and create value for the user (typically an app or website wanting to sell tickets for public transportation in Norway). When it comes to ticketing, we use a combination of data delivery feeds and graphic user interfaces (GUIs) to provide the data we need to calculate fares, provide offers and issue tickets.

We use various NeTEx-specifications to build the logic in our system, so that we interpret the data correctly. In this way, we can create fare offerings based on a combination of timetable data and product data. Now, there are several ways an application can request fare offerings from our platform:

• With a trip search from OTP — the system returns all available products for a specific trip. This trip can contain different legs and different modalities, or just be a simple serviceJourney.
• With zones — the client can provide a simple from-zone-to-zone request and the system will return all available products that can be purchased for this specific zone interval
• With stop-places — the system will return all available products between two stop places. This is mainly relevant for ferries or other non-zonal products, as well as period tickets for railways.
• With public transport authority — the system will return all products that have a static fare and validity, most common with youth tickets and school passes.

In each of these instances, the client can specify several other configurations, such as recommendations (filtering of offers based on preferences), group travelers, existing tickets (to facilitate that the traveler can use existing travel rights to avoid unnecessary ticket purchases) and a few others.

The important point here is that all these offerings are multi-modal. Since Transmodel is a data standard that is multi-modal at its core, providing offers across modalities is no different than creating an offer for — let’s say — a long-distance rail service. We simply use timetable data, product data and rolling stock data (more about that in a later article) to create the offer, regardless of the modality.

There are of course differences in the complexity of a zonal product and a seat reservation on a multi-leg long distance rail service. However, when everything is expressed in the same data model (Transmodel) interoperability becomes easy (or at least easier). The complexity can also be described in Transmodel terms and as such, the system can provide the necessary data to the user — and perform the necessary operations based on the data input.

Dynamic fares and NeTEx

A question I often get is how it’s possible to solve dynamic fares (i.e. yield managed fares) in NeTEx, which seems to be based on some statement about NeTEx not supporting dynamic fares. This is a common misconception, and not actually the case. Dynamic pricing is just a different rate than the normal base rate, and is accomplished via quotas used by the railway or bus operator to achieve revenue optimization — or in numerous other ways. As we have discussed now, NeTEx is a way to structure data, and as such it can also display yield managed fares — or dynamic pricing if you will. In Enturs platform we use NeTEx/Transmodel structures to express dynamic fares and also personalized fares from loyalty programs, discount codes and even capped fares.

However, this requires an “online” solution, more specifically an API. At Entur we have developed our own offers API to handle this — and it is indeed based on Transmodel/NeTEx, which makes it easy to combine with the other services in our platform. It even works well with the timetable data the operators provide us, and this again gives the operator a data drive yielding solution — across modalities as well. We can also include quotas and seating information on rail replacement buses (we have more than a few of these in Norway), all data-driven by the operators own timetable data, product data and rolling stock data. See how all this fits nicely together?

Integrations between systems

There are several initiatives regarding system integrations in the public transport sector, both across borders and within the same country. Some even argue that system integrations will not be necessary at all in the (not so distant future). While this may be true, we believe that systems at least should integrate easily with each other. The more complex the integrations are, the higher the adaptation costs will be. And with high costs, only a few actors will afford building these integrations. That does not create the level playing field that the EU commission is trying to achieve.

In order to simplify integrations between countries and operators, it is imperative that everyone uses the same data model. Since timetable and fares data already is defined to be delivered in Transmodel, this should also be the standard for any ticketing integrations. In this way, one could also envision building “thinner” APIs, because more complex information could be available if needed — because everyone will use the same data model and are therefore able to understand the data the same way.

By creating a ticketing platform based on Transmodel and NeTEx, we have done a proof-of-concept of the data standard at Entur — without actually realizing that this was what we were doing. Since our integrations are also based on Transmodel, we can safely say that this works quite well. Not forgetting the multi-modal aspect as well, which is important in Norway. The multi-modal aspect also creates interoperability and the basis of commercial agreements between different public transport operators, which in turn creates great value for the traveler.

In conclusion

In our experience, Transmodel and NeTEx is a coherent way to solve an important issue going forward, mainly public transport information and ticketing. One could think of public transport ticketing as a gigantic puzzle, with a lot of missing pieces in many different places. If everyone at least uses the same type of pieces (Transmodel) it would be a lot easier to complete the puzzle together.

We are always willing and eager to share our experiences and work together with others to create value. Our support of the open source community around OTP is a testament to this. We believe that by sharing the burden of building these systems, we can build the basis for even better solutions for the traveler — and for a level playing field in the public transport sector.