Blog Intelligent Mobility 2 February 2026

Data, Static, Dynamic, Real-time: What’s actually needed?

Jorgen Pedersen

Consultant, Total Transportation Consultants

This is the fifth of a short series of articles that aims to better define the requirements, limitations, and the potential pitfalls to avoid when delivering Digital Mobility Platforms (DMP’s – previously referred to as MaaS) within a UK deregulated transport environment.

This article will concentrate on the data requirements needed to deliver your next generation mobility platform. It needs to be stated that some of your data requirements will largely depend on what features and functionality that you wish to implement. For example, if you wish to implement accessibility features, you are likely to need lift, escalator, steps, help points, tactile pavement positions, facilities etc. In essence, a wealth of additional data! Likewise, if one wishes to incorporate mobility hubs, one might also wish to incorporate, bike parking, car parking spaces, parking costs, security, lockers, EV charging points, and potentially additional data that will need to be collected, displayed and maintained.

Whilst the objective of writing this set of articles is to create a blueprint for a Digital Mobility Platform, or at least a well-defined delivery approach, it must be acknowledged that no two systems will be the same. A similar analogy would be that no two pieces of hand-made furniture are ever identical. Despite being made at the same time, on the same equipment, by the same craftsman, there will always be differences.

Core Data Requirements

When I started delivering journey planning solutions, I remember being told that all one needed was route, stop and schedule data. I am sure that never before has the magnitude of a task ever been so mis-sold. While route, stop and schedule data are partially correct, it barely scratches the surface of your DMP needs. You will also potentially need real-time data, vehicle data, cancellation data, facilities data, ticketing data, payments data and a plethora of other data that may be feature of function specific.

The following graphic provides an indication of the data that may need to be obtained in order to deliver some of the specific features and functions that you may wish to consider. Some of these sections will be discussed in this paper.

Static data requirements: Public Transport

The above graphic provides a high-level overview of some of the static data required to incorporate and support public transport providers in your platform. However, once again this is likely to vary depending on whether you are running scheduled services, headway services, route deviation services, and even on-demand services. And, it will vary as and when autonomous mobility options are incorporated, or when dynamic EV charging stations are introduced at, or in proximity to, public transport nodes and stops. There may be a requirement to capture on-the-go EV charging stations for public transport where vehicles are required to stop for a few minutes to recharge.

Let’s explore these in a little more detail, taking stop location data as an example. Stops move – in some cases they can move quite significantly, to accommodate new road layouts, route deviations, construction, maintenance etc. They can even move reasonably dynamically in the event of an incident, and once moved they may not move back again. NaPTAN (National Public Transport Access Node) is Great Britain’s dataset for all public transport stops, and it is the authority’s responsibility to audit these to ensure they are accurately identified. The question is,: is a stops’ location that important? The short answer is in general ‘no’, but now let’s assume that a stop has moved to another street, around the corner from where it is. Not only will a person as part of their itinerary be routed to the wrong location, but it could also mean the difference between catching a connecting service or missing it. This can have more far-reaching consequences for the mobility impaired.

Walking itineraries at interchange points will be incorrect, as will the length of time it takes to get from one stop to another. While it sounds implausible, it may even impact the overall itinerary by finding services or interchange points that either are better or worse than reality. So we find that not only is the devil in the detail, but that the delivery of your Digital Mobility Platform, is much more involved than the delivery of a reasonably simple app. It requires a level of data accuracy that will also need a program of continuous data improvement to provide the best possible solutions to provide to your users and customers.

We’re also going to briefly touch on Route Definition Data – something makes the difference between the good and the mediocre. Public transport rarely navigate exactly the same route all day-every day. The services provided might take account of additional service requirements such as school stops, which might only be used on specific days and times. Routes may terminate early on specific runs, there may be route deviations to accommodate villages, or if running on-demand services, to accommodate the needs of an individual.

Therefore, in a lot of cases a route is divided into trips. Where a trip can identify the stops that are going to be serviced as part of the schedule, each of these will have their own timing points which will ultimately feed into the overall schedule, but each of which will need to be made available in your DMP.

As indicated in this article’s introduction, the incorporation of an accessible, wheelchair friendly, or data specific to the mobility impaired will also require additional datasets, much of which is unlikely to exist at this time. But don’t let that put you off. Data can quite quickly be collected. Whilst delivering the London Journey Planner we identified what data we wanted, and then created a group of users that collected the data within a structured form. In San Francisco, I did the same with just two interns, who collected data over a period of about 6 weeks. In Nottingham and Derby, we collected data for both cities in just a few days. However, there must also be some consideration given to how this data will be continuously maintained. Here you could employ crowd sourced data, you could have a department given the responsibility for data maintenance, or one could put it into a repository such as Open Street Maps which can then be updated and improved in line with feedback generated from a much wider group of people. Whichever data maintenance approach you decide upon, it is highly recommended that periodically you audit all available data.

Real-time data requirements: Public Transport

This section will explore some of the real-time data sets that may be required to be incorporated into your DMP. It is not by any measure a complete list as that will depend on what features, services and capabilities that you may want to introduce. For example, on demand services might require person specific notifications, another layer of prediction, booking systems and the ability to book travel companions. Route deviation services may require dynamic rerouting, real-time journey rerouting and push notifications sending updates.

One major hole in transport data standardisation is cancellation data. The Bus Open Data Service (BODS) provides us with “on exception” real-time data. This means that if the bus is running on time (or within a time tolerance) then there is no exception, and therefore no additional notifications of plus or minus x minutes. While delivering on-exception data is a pretty standard way of minimising the amount of data that is published, and processed, this leaves a gap in capability that must at some time be addressed. The gap is, that if a bus isn’t running at all, there is no exception data, because there is nothing to suggest that the bus isn’t just running on time.

In the US, their systems for real-time analysis are defined asComputer Aided Dispatch Automatic Vehicle Location (CADAVL) which means that the bus must at first be defined as running and leaving the depot, after which on-exception works. But at present, within BODS, we have no way of defining the dispatch notification, and therefore no way of telling the difference between a bus running on time, and one that’s not running at all. Some bus operators collect this data and even publish it manually, but it’s not standardised, and in general it isn’t of primary importance at the business level. It therefore can be quite some time before anyone has the time to enter such data, and in some cases data is just not entered.

Enter Micromobility

One of the primary roles of micro mobility is the opportunity to provide first-mile/last-mile options to those users that are served by public transport, but perhaps do not live within reasonable walking distances to stops or stations.

While micro mobility is a reasonably new addition to our rich transport environment, it is already reasonably well developed from a technology, reporting, and API perspective. Most already have API endpoints for payments, refunds, state of charge, location, end of ride parking photo, geofenced parking locations, as well as no-go and slow-go zones. However, when contracting a bike or scooter partner, it is advisable to concentrate on externally facing API endpoint capability, as well as back-office capability, and specifically real-time reporting and dashboards.

Facilities Data

This section will explore some of the facilities data that you may want to introduce into your DMP. The thing to remember is that some of this data will evolve quite rapidly, such as shops, coffee bars and restaurants, which you may not want the responsibility of maintaining. However, some of these could potentially be purchased through information providers such as Yelp or Google. Some information whilst helpful, may also be of concern from an information accuracy point of view. This may include parking prices, opening and/or closing times, service availability etc.

Perhaps the most difficult data that should be made available is real-time lift and escalator service availability data. Again, to my knowledge no service exists to collect this data, which is generally attributed to the number of service providers that one would need to integrate with. However, if we were to think a little outside the box, we might find some innovative ways of collecting this data, with varying degrees of latency. One way that was implemented on the Docklands Light Railway (DLR) years ago was the stations staff, inspectors and everyone else working within the DLR operations team were required to report known issues to a centralised team, who sent out notifications, which appeared as part of the journey itinerary. Now, there would also be the expectation that the journey planner would also provide a push notification updating the user of the issue and also the potential to offer an alternative itinerary.

Conclusion

Data is complicated, a general rule of thumb is that the more features or capabilities that are built into your DMP, the more datasets that will be required. At present the latest DMP that I have delivered requires about 300 data sets to be incorporated, some of which are simple static data files, others are significantly more complicated such as accessibility data. When I used to be a software developer, I always started with chasing down data, seeing what was available, what would need to be collected, how it could be maintained, the accuracy of what was available, and from that point work backwards. It is suggested that the same approach is employed as one starts to design and develop your DMP.

Coming next

The next article will concentrate on integrated ticketing and payments. It will look at what are the expectations of users, the business and your supplier – what we should be striving to deliver for our customers, and how these elements could impact the success of failure of your Digital Mobility Platform.