A metropolitan mobility data platform can be implemented in several levels of functionality. Obviously, these various levels have consequences for the governance that the specific implementation requires. Here we discuss various models a data platform could take. Each next model will rank higher in terms of maturity. For each model we will consider possible consequences for the governance choices that would have to be taken.
First model: Open data policy
One of the key features of the data mobility platform is the wide availability of mobility related data. Data is the key prerequisite for the functionality and much of that data is in the hands of municipal or metropolitan governmental actors. In various cases, value was created in terms of improved travel pattern, transport operations or infrastructure planning due to available data, with other using that data for their own modelling, controlling, and planning.
The governance of this model is straightforward. Data is simply provided as open data, with data streams available. That open data policy can keep less control, with just open data streams, to stronger control, with licenses that are conditioned as for the types of use, types of users or data conversions allowed. So, the governance main characteristic is the license conditions under which the data is provided.
A second element of the governance is whether the licensing conditions are centralized or localized. We see examples where local or metropolitan governments are choosing and organizing their own open data licenses. In other cases, national governments force an open data policy with standardized licenses for most types of information generated with public money.
A third governance element of this model is whether the data type is standardized. Open data can be made available; however, the usefulness and potential uptake of that data is dependent on whether the data type is a recognized standard. This can be illustrated well by scheduling data. Transport for London has its own data format, whereas scheduling data mostly is presented in the GTFS format. Open data that is only about access is more limited than an open data policy that also standardizes the format of the data. Standardizing the data format is a clear step towards mobilizing the potential of mobility data.
A fourth element is further structuring the interaction between the data streams and other applications through API’s. The attractive side of this is that this allows for a more controlled interaction between the data sources and the data users.
So, key governance issues for the most basic for of mobilizing data for better mobility are: data availability, for example through an open data policy, data licenses, data standardization, and facilitation of interaction with the data through API’s. These are key decisions that can support more effective metropolitan mobility through the use of data. The management of this basic form could be limited. Open standardized data with standard licenses could
Second model: A data oriented platform
A major step beyond open data policy is the development of a data platform, as a single point of entry for the mobility data in the metropolitan area. That single point of entry is not necessarily of technical characteristics, as current level of connectedness of most data systems makes access ubiquitous. And indeed, such a single point of entry could very well operate as a pass through of data. The role of the platform in this context is mainly in the field of governance: it serves as a single point of access for licensing and the API’s mentioned above.
A second role the platform could add is quality control. The data that is accessed through the platform is considered to be of sufficient quality. For this, obviously, the manager of the platform will have to have quality control in place and a selection process that adds only data sources of a sufficient level of quality. That quality control will make it more interesting for users of the data.
A third element the platform could add is data retention and aggregation. Data streams can add value because they are real-time, however, they are also transient. This means that when data users would want or need more historical data, the platform could provide for that. Hardly ever, this is feasible or efficient by storing the direct output of the data streams. Consequently, aggregation of data for storage is needed.
Technically, this most basic form of the platform could be run on a cloud platform and as such, it is not relying on hardware of a possible metropolitan mobility platform manager. However, the need for a clear metropolitan organizational unit with the role of platform manager is substantially higher than in an open data model. The role of such a manager can be limited to both selecting and curing the data (streams) into the platform and licensing and facilitating the use of the data (streams) out of the platform. This would probably best be carried out by a department focused on data and technology.
When retention and aggregation become added functionalities, that retention and aggregation needs to be purposeful, aligned with the goals of the metropolitan authority that is funding and possibly hosting the platform, staff and facilities. This means that governance has to be set up to keep that alignment; the platform is more mobility policy driven, meaning that also a department focusing on mobility has to at least be involved in setting up and directing the platform’s retention and aggregation strategies.
In addition, with the retention and aggregation, privacy and data retention legislation play a more significant role in regulating the platform. Governance has to be in place, driving the technical choices of retention and aggregation, in line with the regulatory frameworks on these issues.
Third model: A network status modelling platform
Building on the model above, a data platform with data retention and aggregation, another functionality could be added. This would further mature the model. Building on the data, the platform could provide for the modelling of trip chains based on the raw data streams, to get a better perspective of the real-time network status. For example, GPS measuring points can be translated into paths and speeds, which can be amalgamated into current network status.
In addition, the modelling could be aimed at getting a predictive network status. Based on the historic data, maybe in conjunction with the real-time data, the platform could provide predictions on the network status in the upcoming hours or on a specific day, like an event. This could help operators prepare for the upcoming status with changes in vehicle and personnel capacity.
Finally, the platform could be used to evaluate the effect on the network status of specific policy interventions. Specific policies might drive people to use more public transport, new investments in infrastructures might be considered, increased parking possibilities might attract more car drivers to the city center. The platform, with a variety of historic multi-modal data on network status and trips could help make the right decisions and choose the, from a policy perspective, most effective options.
For the governance, the fact that the platform now has added focus is relevant. New actors come into view that might want to demand functionality from the platform and drive its development in a certain direction. The cases showed us that in this state of maturity, it becomes very relevant for the development of the platform who is taking the role as platform manager. For example, when the manager is the road traffic control center of the metropolitan area, road network status aimed at aiding car flow becomes the focus. When the manager is a public transport operator, the public transport trip planning and operational control of the bus fleet become the focus of the modelling. Technically, both functions could exist together on the platform. However, the governance is driving the solution and the governance generally takes focus. Consequently, the focus in the governance (a specific department taking ownership of the role of platform manager) seems to be driving the focus in the technological solution, even if that technological solution could be broader. This is the risk of appropriation: the wider potential of the platform is thwarted because the implementing department drives it towards its own preferred application.
Fourth model: A trip modelling platform
Again, building on the model above, the captured and modelled status of the networks, both historically and real-time, allow for the predictive modelling that provides travellers with an optimized multi-model trip advice. This come close to traditional trip planners. However, the variety of data in the platform and the quality of the network status, as they were captured, would allow for more sophisticated plans, in terms of the conditions of the network. For example, traditional trip planners for cars have to create an idea of the network status based the earlier trips of their users and the current users of their system in that network. The platform could have a much more detailed view of both the historic and real-time network status. Likely, the plans that are modelled on that better data are also more accurate predictors of the upcoming trip.
A second element that can be added beyond the optimized trip planning is making the plan multimodal. We have seen two ways in which this can be done. On the one hand, most trip planners are able to calculate different options using different modalities. The prospective traveller can choose between travelling by car, public transport, bike, or walk. The more mature trip planner would build trip chains from these different modalities, in line with the possibilities of the traveller, to further optimize the trip plan to the conditions the traveller is going to encounter on the network. The platform can probably distinguish more easily between modes than current trip planners, which would allow for more sophisticated planning of intermodal trips.
Another element that can be added is to go beyond traditional optimization of trip options for the least travel time. Because of the increased quality and variety of the data, other trip characteristics can be included or selected for optimization. For example, the trip can be optimized for reliability of the plan, for environmentally friendliness, for current weather conditions, for events, etc. Any data that can be added to the platform, like pollution data, can enrich the model and can be used to help travellers plan their trips, optimized for that data.
A further element that can be added is the coordination between influencing the travellers through the trips they plan, and other interventions in the transport system, like managing traffic flows traffic lights, information panels, etc. The platform would also allow for the evaluation of various interventions.
For governance, the modelling for trip planning and adding specific goals, further increases how mobility policy the platform is set up. It increases the need for the departments focusing on mobility to be involved in the decision-making on the development of the platform. In addition, the platform now has become a service to the travellers in the metropolitan area, to external users. In the governance, this means that the platform is entering a new market, with new clients and new competitors. The success of the platform now is less easily managed by internally selling the strengths of the platform to metropolitan authorities and allowing them to harvest the benefits. The competitions for trip planners is fierce and the function will only be successful if the uptake with travellers is substantial.
The multi-modal approach also means that more stakeholders are now have an interest, with different demands towards their metropolitan government on how to develop the trip planning service. Public transport operators, road network managers, mobility policy administrators, travellers, they all could have a different perspective on how to optimize the planning, and at the same time they all can help make the platform successful, for which their commitment is needed. The risk here is that a planner focused on the most environmentally friendly option would not be used by travellers, a planner focused on fasted travel time not (financially) supported by policy makers, a planner with a stronger car orientation hindered by public transport operators on which data the platform is relying, a planner with a stronger public transport orientation not supported by the road network manager. The governance will have to be able to deal with the dependence of this model of the platform on these stakeholders with possible conflicting interests.
Fifth model: A trip planning app connected to the platform
And again, building on the model above, the data platform, with modelling and trip planning could use a proprietary app that could further mature the platform. A first element this app could add is an additional data stream of real-time travellers flows over the networks of the various modalities. If the number of users of the app in a metropolitan area is high enough, this could further enhance the real-time understanding of the status of those networks.
A second element this would allow for is quality improvement of the planning model. If a substantial part of travellers is using the trip planning tool and allows the platform to follow their real trip, this allows for a constant revaluation of the quality of the trip plans and the model providing them against the real trip.
A third element is that the app would allow the governmental actors managing the platform to award travellers for choices that optimize for more collective values, like emissions and pollution, and less for individual values, like minimized travel time. This nudging would align the choices of the traveller more with the collective goals in the metropolitan area. A traveller could receive free public transport kilometres, when he follows a trip plan that is more environmentally friendly. Or another traveller could receive points for free coffee if she takes a route that alleviates congestion in more densely used areas of the network.
A fourth element the app could add is a dashboard to dynamically prioritize the values that they deem important and nudge the travellers. For example, in the morning rush hour, the collective travel time might be the key value. On warm days, the reduction of the emission of NOx in busy areas could be a key challenge, to which the trip planner could contribute by nudging travellers using the car away from these areas. On very congested days, travellers could be nudged to use public transport more. The dashboard could help governmental actors dynamically align the behaviour of the travellers more to the goals of mobility policies.
This trip planner app adds two key elements to the governance challenge of the data platform. First, privacy and trust become an even more important aspect of the relation with the data user. That relation will have to be set up to let travellers trust the app, as they allow for the app to track them. This also is generally highly conditioned by privacy legislation. Second, the nudging element is something that should be used carefully, balancing individual and collective losses and gains and focusing on the primary mobility challenges in the area. Nudging is a powerful and vulnerable approach for which decision-making on how to apply it should be carefully embedded in the wider governmental organization.