At the recent MaaS Market – Concept to Delivery conference in Atlanta, GA, our CTO and co-founder Adrian Schoenig talks about the role of trip planning in mobility as a service. Read the transcript of his talk below.
What MaaS promises to provide, is access to the growing variety of transport services in your city.
Mass transit as a backbone, various first-mile, last-mile solutions, on-demand transport, shared vehicles. People might want to use their own vehicles, too. As a complex example it should accommodate this kind of use case: of someone living out in the suburbs – they have a car. They want to going to the city for an event and come back later. They might start out driving the car to a park & ride station, taking the train from there, and then hopping onto an Uber for the last mile to the event. On the way back they then might switch the Uber for a bike share, maybe to a different train station, back to their car, and then drive back home.
While this is a complex example and not an every-day occurrence, it nicely illustrates some of the challenges for MaaS. What those challenge revolve around are all about convenience for the end user. If you want to convince people to give up on a car or at least use it less, then you need to provide an alternative that is convenient. If you can make such kind of trips convenient to use, then you’re on a good track with having a good alternative to using a car.
The challenges for MaaS here are: There can be a lot of transport options to choose from in the first place. Public transport, taxi, walking, car share, bike share, scooter share, car rental, cycling. Combining modes increases the number of options exponentially. How well a mode is suited changes with the day, depending on traffic, availability of services, road works and track works, and so on. If you take a trip combining modes, what do you do if you miss a transfer?
Then here’s the pre-planning aspect: For some modes like car share, on-demand transit, or a taxi or Uber in suburbs, you probably need to do pre-planning. Do you want to make your users plan their trips to work and home every day?
Tackling these challenges is important, because otherwise it’s easier to just drive and complain about traffic and parking. This is how trip planning helps. At the core, trip planning is a search engine for transport. You tell it where you want to go and what’s important to you when you travel, and it provides you with the best suited transport options. It suggests combinations of modes as appropriate. It lets you compare the options, by presenting them in a comparable way: Time, cost, convenience, environmental impact, calories burnt. It can also show “productive time”, so you can get work done, nap, or read a book. Depending on what’s relevant to you, it can highlight the important aspects for each option. As you do the trip, it provides you with real-time information and if something goes awry, it helps you get back on track.
To the end user, what they want is a trip planner with all the relevant information and recommendations for them, along with a convenient “buy” button. It needs to be more than just an app that let’s you browse available cars, bikes, let’s you order a taxi, or look-up public transport timetables. It needs to digest this information for you in a convenient way.
Brief side note: Ideally, this is more of a trip assistant than a trip planner and shop. This means it should be personalised to the preferences of each user. The recommendations should consider the context of each trip – you might not want to take a bike a long way to a work meeting and arrive all exhausted and sweaty. It should be proactive and do the planning for you, so you don’t have to worry about planning and booking each individual trip you take.
For cities and transport operators, there are additional benefits: Promoting more sustainable and healthy modes by showing the real-cost of driving, that also considers parking availability and time to find parking. From the usage of such platform, you also get good insights into aggregate travel needs and travel choice behaviour.
Now that we’ve had a look at the birds-eye view, let’s take a closer look. What I have described so far, is the kind of “one-stop-shop” for transport, that MaaS proponents often like claim for themselves. But there are many flavours of transport needs, and I would challenge if they can all be met by a single one-stop-shop. The one-stop-shop metaphor applies for helping users get from A-to-B, providing trip suggestions, booking functionality, real-time information and payment all in one app. But it’s unlikely that the same shop will be suitable for everyone.
Say, some people require special attention, such as the elderly, wheelchair users, the vision-impaired, or people on the autism spectrum, who require different modes and user interfaces. Similarly, some people might prefer certain modes, such as cyclists or anyone using some of these new micro-mobility vehicles. If you have a car, parking information and traffic-aware turn-by-turn navigation is very important. If you have an electric vehicle, you’ll appreciate information about destination charging.
Business travellers have different needs regarding cost and punctuality than students or people travelling for leisure. People from out-of-town need guidance on how to use the local transport options. This became obvious to mobility experts at the ITS Europe conference in Strasbourg last year, when a public transport strike coincided with one day of the conference.
It is difficult and costly to cover all these in a single one-stop-shop. MaaS can have solutions for each of these segments as a whole, but no individual transport provider or public authority or MaaS operator can cover all of these well. It certainly doesn’t scale down well to smaller cities and budget. Instead, this requires many MaaS offerings and mobility services and applications. It’s unclear which offer will end up being picked up well by users and which will be profitable. What they all have in common though is that availability of data helps everyone, especially when it comes to combining transport modes and providing real-time information. Therefore, a good way forward is to provide data openly, find partners, and let innovation and the market do their thing.
What can you do to help this? If you are a transport provider or public authority, provide the data.
Here are some key points about how best to provide data:
For trip chains, bulk data works best rather than just APIs, as that let’s trip planners like ours find the best combinations of modes. This is not possible with APIs due to the inherent lack and ability to analyse only a small handful of options. While with bulk data, it can crunch many orders of magnitude for more options. However, APIs work very well when it comes to anything dynamic such as real-time information, disruptions, and bookings.
Where possible, use a standard format, as that makes it much more likely that your service will be picked up by a MaaS platform. This is especially relevant to smaller TSPs. But do use proprietary APIs if it’s not cost effective for you otherwise. Proprietary formats are better than no data.
Also, some modes and use cases don’t have a good standard. For those, we’re also working with the MaaS Alliance to come up with guidelines, recommendations and standards. We do look for feedback there.
When you provide data, make sure it matches what people see in the real world, in the real-world infrastructure and on vehicles. If you provide both static bulk data and dynamic data through APIs, make sure those can be matched up.
Lastly, provide data with open licenses. Don’t just provide it to Google or the provider of your public transport app.
I’d like to point out two cities here as an example. Sydney, Australia, is a good example where data is provided with open licenses, in standard formats, but also with proprietary additions for data that’s not yet covered by standards, such as real-time occupancy for public transport. However, their data can be a bit “dirty” and matching up static to real-time data, and data from the APIs doesn’t always match the real world. This leads to a nice variety of transport apps in Sydney, meaning TfNSW could discontinue their old one which got poor ratings and have a more focussed offer.
Another good example is London, where data is also available in bulk and with generous licenses, though they are using a proprietary API. In summary: If you are a MaaS operator or want to be one, consider the value of trip planning and, even better, a trip assistant. If you are a transport operator, see if you can provide data, APIs, including bookings. Talk to your team to see if you can provide data openly.
Get in contact with the MaaS Alliance as we’re looking for feedback from TSPs and also want to hear about challenges and concerns that you might face about providing data. Get in contact with me if you’re providing a DRT service as we’re also collaborating on a data format for that. And, most of all, think about how your transport offering fits into the bigger picture, and how you can help provide a smooth transition from one mode to the next, and think about the different flavours of mobility needs.
The post Trip Planning and Enabling MaaS Projects appeared first on SkedGo.