Multimodal mobility is fast becoming the biggest opportunity for us (as service providers and operators) to design seamless-interconnected journeys and to reimagine movement within urban cities. Multimodal mobility is the term used to describe integrated transport – seamless connectivity between different modes of transportation, such as buses, ferries, trains, trams, ridehailing, bikes, e-scooters and even walking.
Welcome to the April edition of the Multimodal Mondays micro-webinar series. This month Sandra is joined by Edwin van den Belt from Dat.mobility to discuss TOMP-API, which is being developed by an open source working group with public and private stakeholders, aimed at facilitating the implementation of MaaS and the corresponding exchange of data. The TOMP-API describes a full MaaS journey, including operator information, planning, booking, support, payments and trip execution.
Watch the micro-webinar below! Keep reading to learn more about Edwin van den Belt and for a brief summary of their multimodal discussion. Check out episode two here.
Multimodal Monday: Edwin Van Den Belt & Sandra Phillips
multimodal monday GUEST
On April 1st 2015 Edwin join the Dat.mobility ranks for a challenge in a new domain, mobility. His current focus is primarily on real-time data processing and MaaS and is currently involved with 7 MaaS pilots across the Netherlands. The NDW (national data warehouse for roads) requested a national platform for roadwork administration and cooperation for which Edwin was involved as a software architect.
Dat.mobility is the number-one expert on ICT solutions and data analyses in the field of mobility. Whether it’s about mobility monitoring, managing or planning: DAT.Mobility delivers the solutions needed. Their clients include transport consultants, planners, policymakers, transport operators, road construction companies and distributors and also marketeers, car park operators and event organisers.
Their mission is to make mobility choices more visible, simpler, and more effective, for today’s journey and tomorrow’s world. Drawing from their position as a leading knowledge institution in the field of mobility, they aim to add societal value by delivering well thought-out, user-friendly solutions.
Together with Mobidot and Kantar, Dat.mobility set up the National Movement Panel (NVP), where they follow the multimodal movements of thousands of Dutch people and use it to support advice to their customers. In the MaaS domain Edwin is involved with the TOMP API, where he helps in constructing a universal interface which lets transport operators and MaaS providers cooperate.
APRIL’S multimodal monday webinar:
TOMP is a collaborative initiative between Transport Operator and MaaS providers to create a standardized language for the technical communication between the two. TOMP-API was initiated by the Dutch ministry of Infrastructure, to facilitate scaling local MaaS pilots from a local to a national level. Last year they released the formal connections between the open source community “TOMP workgroup” and the ministry. The initiative was not limited to the Dutch boundaries anymore. It’s used nowadays throughout Europe and there are also implementations in Australia.
One of the challenge of MaaS is in getting the ever growing, new shared mobility side, integrated. Without a standardized language, it would seem that the operators with the most integrations would have an advantage, like Moovit. MaaS platform providers should ‘open up’ and cooperate with each other, making it possible to facilitate traveling between regions served by different platforms. There is also a need for:
- Interoperability – the complete user journey (TOMP-API),
- Sharing of user information (personal data stores, MyData)
- Discovery (a ‘yellow pages’ to find other MaaS platforms)
Another thing to consider is the clearing. This is highly dependent on standardized “digital contracts.” In Europe they are discussing about extending the ‘Open Bike II’ initiative to ‘Open Wheels’. This initiative is aiming for creating a reusable, standardized contract format.
Micromobility has its own standards already with the GBFS2 and MDS. If you look at the model of Sochor et all, you can see that GBFS, GTFS(-RT) and their European counterparts NeTEx and SIRI reside on level 1: providing information. The TOMP-API module ‘operator information’ provides more or less the same information as GBFS 2.0 and also resides here. Level 2 is about finding, booking, executing and paying of MaaS journeys. The TOMP-API resides here (excluding the ‘operator information’ module.) The general idea is that the TOMP-API can be used in combination with all of those level-one-standards.
Part of the initiative is focused on supporting cities in their urban planning efforts through a special API. Cities get their data consuming GBFS, GTFS or TOMP-API from several parties. Or, are getting data delivered using MDS (or the European counterpart CDS-M). Urban planning can be done using this near-real time information which is a huge effort. Edwin believes that we should look at the new extensions on MDS and CDS-M (providing OD-matrices with information) for planning purposes and law enforcement can be done using the real time part, for more fine-grained information.
What do you think will be the most important development in 2021 for MaaS?
‘I’m hoping we can achieve a better (technical) understanding, design and maybe an implementation (pilot) on one of the aspects above. I personally believe that the most necessary aspects are the Personal Data Stores and the ‘yellow pages’. But I’m completely aware of the fact that the mobility sector is nowadays in ‘severe weather’, so I think it’s up to the governments to inject financials after the COVID-19 period, with more MaaS travellers and less cars.’ – Edwin van den Belt
What’s next for TomP?
The TOMP-API is extending, reacting on issues on Github, but also thinking ahead. In version 1.2.0 (release date 1st of May), they’ll establish connections with the Personal Data Stores and full integration with deep link apps (mainly for bike operators). In the upcoming versions they’ve planned to integrate with clearing houses, but also comply with scenarios from the train and plane domains, like seat reservation and ancillaries. They try to stay backward compatible as long as possible, and have been for over a year. Another big item for the TOMP workgroup will be dissemination and alignment with MobilityData, the EU (CEN), National Access Points etc.
If you would like to watch more of our #MultiModalMondays webinar series’ visit here.