DYNAcity is a research project initiated by the Flanders Institute for Mobility (VIM). It investigates what information and mobility options a city should offer in order for travelers to be willing and able to travel more efficiently. The data collected to build smart mobility solutions can also be used in working towards strategic goals.
The Flemish city of Ghent provided the civic playground for this project. About forty citizens who travel daily to and from the Zwijnaarde science park and the Sterre campus of Ghent University have been participating in a pilot in which they received multi-modal traveling advice every morning before they leave home.
Traveling within a city often goes hand in hand with suffering delays, says project manager Peter Defreyne.
But we still do not consider using alternative modes of transport often enough. The lack of relevant information before and during the trip is the biggest stumbling block for most people. Through smart information services, we can offer travellers real-time advice on their journeys and provide them with information on available, relevant mobility options. They can trust this advice just as car drivers trust their navigation systems.
Different traffic flows of cars, motorbikes, cyclists, public transport and pedestrians move crisscross through the city. Currently parts of these flows are being streamlined with traffic-guiding systems such as traffic police, information boards and pointers to parking spaces. These systems, however, are usually not connected to each other. There are also methods of transport for which little information is available.
DYNAcity tries to determine what an optimal urban traffic and mobility management system should cover and how it can encourage travelers to make their journeys in the most practical manner.
DYNAcity has disclosed all the relevant mobility data from 2016 and made it available on the open data platform of the City of Ghent. This data is used in three applications:
DYNAcity basically stands on three pillars, Defreyne explains.
Number one, open data, was the starting point of this project. The problem with data in general is that its usability is rather fugacious, especially when it comes to real-time data like traffic information. That's why we have built a data warehouse. Analysing this data in its historic perspective allows us to create longer-lasting value, like information on trends, and how the phenomena we are measuring evolve and develop over time. That is how we get the "three Vs of true Big Data": velocity, variety, and veracity.
The second main ingredient for this project is putting the information to use in an app that provides integrated travel advice, Defreyne continues.
Multi-modal route planners combining information on road traffic, public transport and cycling do already exist, but we are different because we use this information to motivate travellers to choose between alternative modes of transport.
For example, if you want to go shopping in the centre of Ghent on a Saturday afternoon, you know that some of the car parks will be full, and that in any case you will need at least half an hour to get to the centre. If we can provide you with current information showing that there is parking space available at the edge of the city, and that the buses are running on time, you may be persuaded to choose this option. That way, data has an impact on travellers and mobility in and around the city. We aim to add the "why" to all this route information.
Direct motivations for cyclists, for example, include the local weather forecast, and the availability of shared bikes at the station. This is the type of information that makes people decide whether they will use these services or not.
Defreyne mentions Waze as an example of an application that uses real-time information to change travellers' behaviour.
This app provides crowd-sourced traffic information in real time, which allows you choose an alternative route. We do something similar for different modes of transport.
The third and final pillar of DYNAcity incorporates the long-term view into this research project.
Collecting this kind of data over a longer period of time can help you in developing mobility policies, says Defreyne.
These trends and predictions can also be used in adjoining areas like the financial and retail sectors. Banks and stores, for example, are very interested in how their customers are behaving. They may use this information to service their customers better, increase their market shares, or measure the revenues new customers are bringing in.
While businesses use Euros to measure their returns, cities will be more interested in the number of cars, the number of hours spent in traffic jams, the number of cyclists, the number of accidents, and the levels of air pollution. They can relate this information to their strategic targets and use these numbers as Key Performance Indicators (KPIs). That way, policymakers are provided with concrete feedback on the impact of their measures.
In the future, commercial companies may even use real-time and trend information to make a business proposition for implementing certain measures to meet targets set out by government.
The outcomes of this research project are presented in the DYNAcity Catalogue. This provides an overview of the mobility data that has been made available and the apps that have been developed on top of the DYNAcity Smart Mobility platform.
The DYNAcity research project has been financed partly by the Flanders government (through the Flanders Innovation & Entrepreneurship agency), and partly by the private sector. The total budget was almost one million euros.
The project involved over two dozen partners, including the Flanders Roads and Traffic Agency (Agentschap Wegen en Verkeer), the Flanders Department of Mobility and Public Works, the Flanders Geographical Information Agency (FGIA), the City of Ghent, the Universities of Leuven and Ghent, several organisations involved in mobility, bike and car sharing, public transport providers, and companies in ICT, telecoms, energy, technology and innovation.
The innovative character and grants from the Flanders government made it easier to get other organisations and companies involved in this project, and have them bring in their data sources as part of their participation, says Defreyne.
That has made this a collective initiative, resulting in a regional community and platform for open mobility data.
Now that this project has been completed, Defreyne continues,
we are actively looking for partners in a successor project — on a Flemish level, or maybe on a European level. Ghent is the second-largest city in Flanders after Antwerp, and we know that the latter is working on similar things. So extending this into a larger Flemish initiative may be the most obvious option. In general, however, large cities are still searching for ways to deploy and finance these kinds of innovations.
We have the resources to keep the current operational platform up and running for as long as we work on disseminating the results. For its continuity on the longer term, however, the city, a commercial company or maybe a spin-off will have to take over the platform.
There definitely is a business model and a lot of interest in this project, but at this stage it is too early to say what will be the next phase. We would love to continue this research, to prove the value we are creating, and scale up. We really do not want to end up like a lot of other research projects, for which the publication and presentation of the outcomes is at the same time the end of it.
According to Defreyne, building an application based on open data requires specific attention to the accuracy and availability of the data.
If you have 500 or 1,000 people using the information, the primary open data publication service is not necessarily suited to cater to all these users. As soon as you start building applications, you have to make sure the required data can be reached. All these aspects — quality, availability and reachability — determine whether a service can create economic or social value in the end.
Issues like this were learned the hard way.
This is a research project, so we ran into these problems during the process. Some of these we saw coming, others we did not. Along the way we learned that some services cannot handle too many user requests at the same time. They were never designed for this and simply become unavailable.
Another problem is that some of the data providers upgraded their data formats during the project without us knowing about it. That resulted in odd behaviour of the application, or no information being available at all.
According to Defreyne, there is a huge difference between making data publicly available, and running a data service.
For an application to run properly, you need guarantees with regard to the quality, availability, format and scalability of the underlying data feed. An application basically requires a guaranteed service level to function properly.
At the same time, Defreyne is not sure whether this should be a task of the government.
Their role may be limited to providing the data on a best-effort basis, and leaving the rest to the market. There may be an opportunity for intermediaries here, who can do on a commercial basis what we have been doing ourselves: setting up a data warehouse, guaranteeing minimum service levels, and providing data in a programmer-friendly format like JSON.
I think this is especially true for domain-specific standards to exchange data. For mobility and traffic management, for example, we have DATEX II, a European standard well suited to interconnecting professional applications. It allows the exchange of information on roadworks, traffic delays, and so on.
Standards like this, however, may prove to be overly complex for junior developers, who otherwise are very well able to write an app using this data. So there definitely is a need for conversion back and forth between these complex data formats on the one hand, and JSON and other more basic formats used in web development on the other.
For government agencies, making topical data available in an accessible format is generally enough, Defreyne continues.
The market — having an interest in the service-related aspects of this information — should be able to create the ecosystem around it. A company renting out bikes, for example, has a business interest in making data on the availability and location of its bikes publicly available. That way, they enable others to incorporate this information in their applications.
There is an increasing push from the European level to make government data publicly available. In Flanders, we are evolving to a policy that all data should be open by default, unless there are good reasons — typically for privacy or security — not to do so. I think we are moving into the right direction, and it is only a matter of time before we get there.
For companies, it is harder. Making their data available, especially when it comes to real-time information, makes them vulnerable. They may be giving away strategic information to competitors or investors. So they will have to draw up the balance of costs and risks on the one side, and the business opportunity and return on the other. And this may even change over time: if you are one of the few providers not publishing your data, you may be out of business quickly when the market shifts.
An important lesson of this project is that over time the technical aspects become less important than the other issues, Defreyne concludes,
just as the operational part of the implementation has become more important than building the application.
Generally, the application itself requires only a limited number of lines of source code. Making your application secure, converting your data into other formats, making the data available outside the firewall, monitoring the platform, sending out alerts in case of problems and so on — all those require far more work.
Saying this, Defreyne takes the opportunity to warn about software developers and suppliers taking advantage of the hype and supposed complexity surrounding big data and data analytics.
Developing an app is not rocket science. So beware of software development companies abusing the innovative character of open data to ask large sums of money, or using your project as research for their own commercial applications.
You should take the time to sit down with a developer and see how many hours the implementation of the required functionality would take. That makes it easier to negotiate with a software supplier, who of course you will need for support on the application.
That brings me to the Data Challenge we organised last month, Defreyne continues.
While we were working on our own application to show the value of aggregated open mobility data, we learned that we were limited by our own budget, time and ideas. Since others may come up with very different applications that we would never think of, we decided to open up the whole thing.
We deliberately did not call it a hackathon, because that way we would mainly address developers and designers. So we focused on startups and new business models. Another group we hoped to attract were data scientists, because analytics can, for example, uncover correlations between the weather and mobility. What is the impact of rainy weather on traffic delays or the number of cyclists on the road? What about the impact of the student population on the city — in other words, how do the summer months compare with term-time?
The value of this information can be economic or social. It can be used to make a better match between supply and demand, and make transport systems more efficient. Bus routes and timetables, for example, are currently static, with just a few extra buses during rush hours and a few less at weekends. Bringing more flexibility into these models might increase the quality of the service or save a lot of money.