7 Challenges for Smart Cities Transportation Managers

7 Challenges for Smart Cities Transportation Managers

by Roman Smolgovsky , Solutions Architect, Senior Engineering Manager

Whenever anyone talks about the Smart Cities, they focus on the technology. But Smart Cities are not just about technology. Ironically, that is the more straightforward part. The three words that should immediately come to mind for Smart Cities Transportation Managers are logistics, integrations, and processes. Technology, in and of itself, is not useful in Smart Cities unless it seamlessly integrates into the daily life of its inhabitants, especially service providers.

And as exciting as it is to get started on a project like mobility, there are some critical first steps that smart city managers need to think about before kicking things off. This is a view of Smart Transportation based on our work with New Zealand Transport Agency in Queenstown, New Zealand although the lessons herein can easily apply to other Smart City use cases as well.

Challenge #1: How does it work?

A city has many transportation providers - buses, trains, shuttles, taxis, rideshares, and more. Before we can coalesce all of their streaming live data, we first need to address some fundamental questions such as:

  • Do we understand how they operate?
  • Does this shuttle require advanced booking?
  • Does this provider has predefined routes or is it a taxi or a rideshare?

The process may be relatively straightforward with the public buses but shuttles, hop-on/hop-off buses, rideshares, and more may have entirely different use models that one needs to understand in-depth before deploying any technology. The solution is to test every provider (actually ride on each). That way you understand, in-depth, how each provider operates.

Challenge #2: Timely access to the provider’s data

Getting to the data may take some time as involves multiple parties coming to an agreement on what will you get and how will you get it. In a lot of cases, ‘what’ and ‘how’ are not easily attained together.

Start the process early and make sure that you have a pitch for the provider - what is the benefit for them if they give you access to their data? And be sure to schedule meetings upfront: Introduction -> Agreement ->Technical discussion.

Challenge #3: Do I have data?

You convinced your provider, spoken with their technical team, and received an API specification from the IT folks. Unfortunately, we’re not there yet. In most cases when you try their API you will learn that:

  • They do not have specific APIs. (e.g. cab company may not have a real-time tracking API).
  • Their request expects the data that you may not have. (e.g., a cab company may require putting the exact address including the building name or, the place name such as the name of the restaurant).
  • Their reply may, and most likely will, differ. (e.g. cab company statuses vary quite a bit).

The solution? Get early access to the API and try it right away. It is essential to prepare the exact specification of what API/data elements you expect and discuss it in details with the IT of the provider. Until you have an endpoint and access keys, you do not have a provider API. It is also essential to create a superset of the request data that will cover all providers and standardize the outputs and mappings. Lastly, automated testing is a must - especially for the smaller providers that will try to develop a solution ‘on the spot’.

Challenge #4: What are the implications of data changing?

The data is flowing but, how timely is it? This may present a substantial challenge as most of the providers may not be up to par. Take vehicle position for example. The majority of providers employ so-called AVL (Automatic Vehicle Location) solutions that are part of their fleet management system. These solutions can do a lot but from a fleet management perspective, how often do we need an update? Maybe once a few minutes? No one is going to stare at all 1000 buses all at once. But to the transit customer standing in the rain, a few minutes matters quite a bit. And remember, Smart Cities require much faster updates - once a second ideally, once every 10 seconds is a “worst case scenario.”

Learn the update rate for the data and make sure that it is sufficient as soon as you get access to an API and be prepared to provide an alternative solution if it is not sufficient

Blog Iot Tech Expo

Challenge #5: How do we bring it all together?

To start, we need a collection of data: shapes (i.e., the actual routes that the vehicles will use), stops, schedule - basically, trips. This data usually is organized using GTFS (General Transit Feed Specification) format. While large enough public transportation providers will likely have it, smaller commercial providers will likely not. Regardless, this information has to be present and maintained, and your system must have the means to receive updates when available.

Obtain GTFS for all providers and figure out the update process. Have the means to create GTFS for smaller providers (there are consulting agencies that may be able to help) if need be. Validate the GTFS using Google tools; do not just trust it! Assure that you can estimate the cost of the journey. For public transportation, it should be part of GTFS (it has special facilities for that), for taxis - use the API or calculate yourself and always use the API for the Rideshares.

For taxis and rideshares, the most significant issue is the cost estimate. Most of the bigger taxi providers may have an API that will return it, but be prepared to calculate it yourself for some cabs based on their rules - make sure you obtain both estimated length and estimated time of a journey for that. Rideshares usually have incredibly complex rules so unless they have an API, don’t bother.

Challenge #6: Which one is mine???

The whole idea of the Smart City travel is that the customers should receive the information about their journey in real time including vehicle location, notifications about its arrival, and so on.

Given the availability of an API, the process is relatively easy for taxis and rideshares. Public transportation and everything that operates using GTFS data or similar is different. The issue is that AVL installed on a bus will happily provide you with the vehicle id, lat/lon, and even bearing and speed but it has no idea which trip this bus is executing or if it is executing one at all. The bottom line is that if your solution deals with public transportation/shuttles/etc that uses routes and trips, you have to figure out how to associate the vehicle with its trips. Assure the presence of an API that retrieves the vehicle ID for a given booking (taxis/rideshares) and figure out vehicle-trip association for public transportation

Challenge #7: What is their process?

You have to make sure that you understand the provider processes and make sure your solution matches it as close as possible - otherwise the whole project it is doomed to fail. Remember, when dealing with a provider, you may deal with people for whom all your additions are just a nuisance. You must keep your ‘intrusion’ to the minimum.

Do not try to change the provider’s process, minimize your ‘intrusion’ as much as you can, and create tools and instruments to assure that the processes that you introduced work.

Conclusion

The challenges when creating Smart City Transportation solutions are numerous. Hopefully, this article has helped shed some light on the work that needs to be done upfront, before any technology is deployed. And who knows, maybe someday the robots and AI we talked about in the beginning will be able to deal with these challenges instead of us. Maybe.