Share:Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someonePrint this page

When I was a teen, I visited the City of Saskatoon’s traffic operations centre. Admittedly, my memory is a bit fuzzy, but I recall a centralized control board visualizing the status of most of the traffic signals in the city. I also recall some complaint about “fault” conditions and “communication issues” with this centralized system. While impressive at the time, transportation technology has come a long way since the mid-1990s.

For the past decade, I have worked as a transportation engineer and conducted both planning and operational analyses. One of the biggest challenges to performing this type of work is acquiring relevant and sufficient field data – household activity surveys, vehicle turning movement counts, travel time surveys, etc. can become costly endeavours in many circumstances.

Admittedly, this is a huge topic to take on in one blog post, so please excuse me if it may be lacking in some areas. I am approaching this topic to share my perspectives from the transportation engineering profession; however, transportation system technologies do have a broader scope beyond my professional experience.

Potential Problems with Centralization in Transportation

Technological systems have historically been more centralized in nature. For example, think of computer mainframes or dedicated servers that provide data for individual terminals or computer clients from a central repository. Using today’s internet capabilities, many businesses and industries  have already experienced a shift to a more decentralized and/or distributed architecture. I believe that some processes in transportation planning and operations could use more innovation in this area.

For discussion, here are a few select examples where centralized systems may be failing transportation planning and operations:

  • Reduced Efficiency – Consider the optimization of traffic signals for a corridor. Traffic conditions change dynamically throughout the day. Currently, it is common practice to collect traffic data, hire human resources to analyze that data, develop signal timings solutions, and implement new timings in the field. Perhaps this would occur once every few years in order to develop a few timing plans. Would it not make more sense to collect data in real time and implement signal timing changes dynamically throughout the day? Several industry players are currently working on this problem/opportunity.
  • Less Redundancy, Slow Recovery – The concept of redundancy is not new.  However, despite precautionary measures to back up your work product regularly, how often have you experienced local file corruption, virus infection, or system failure that cause delays and rework? I know I’ve seen this happen with varying degrees of impact. It doesn’t even have to be your fault – I once saw a virus infect an entire network because one user clicked on a malicious link, which then took a whole day to purge the virus and restore the backups. This is significant lost time, and time is money.
  • Curated Data Sets – In transportation planning, one commonly utilized data set is trip generation rates. These rates are often curated by a centralized agency and require resources to collect, analyze, validate, and present the data. But what about more customized rates based on geographic location and development context? Could there be a better way to determine trip generation rates?
  • Cost Challenges – As mentioned above, field data collection can easily become a costly endeavour, depending on the scope of one’s project. Costs related to field data collection teams and specialized equipment can challenge any project budget.  Could this data collection cost be more distributed and utilized for more than one or two projects?

Despite the above criticisms, I am not simply stating that we should “throw the baby out with the bath water”.  Centralization of data or technology will always have a role in transportation planning and operations, especially for sensitive and/or proprietary applications.  To be clear, what I am proposing in the transportation engineering profession is that we consider the new abilities decentralized / distributed technologies bring that can potentially improve data collection, workflow efficiencies, and business models moving forward.  The question is, how wedded are we to the status quo way of doing things or do we have a desire to improve?  Is there enough demand for change or do traditional methodologies still serve the industry well?  How will methodologies change over time with shifting demographics, both within the profession and the general public?

Regardless, in recent years, we have seen some exciting developments in technologies that may directly play into the hands of decentralizing and/or distributing transportation systems, including:

  • Widespread use of mobile computing and emergence of wearable technology;
  • Blockchain technology for ledger keeping;
  • The crowdsourcing of data; and
  • Open-source and application programming interface (API) solutions.

While these are but a few teaser ideas on the subject, these technologies will be the primary focus of this article.

Mobile Computing and Wearable Technology

With the advent of smartphones in the 2000s, technology took a huge leap forward.  No longer was one bound to a physical connection to the internet, but instead, you could now take the internet everywhere with you.  For the first time in human history, we now quite literally have the ability to access all of human knowledge – anytime, anywhere – from a device we can fit in our pocket.  What we do with that capability is another question, but alas.

Steve Jobs with the Original iPhone (2007)

Steve Jobs with the Original iPhone (2007)

Combine this technological capability with GPS, sensors, and other means to capture quantifiable performance metrics; a whole new data source has emerged.  Individuals and companies have already spent a lot of time trying to play around with these new abilities.  Some endeavours have worked out tremendously, but others have fallen flat.  While this technology could be useful in such applications as a replacement and/or supplement for household activity surveys, under current conditions, data would typically be more weighted to younger demographics; however, this will change over time.

One growing issue with this type of technology is individual privacy.  However, that is a topic for another day – it all depends how that data is being captured and applied.

Blockchain Technology

Network Types [Source: Paul Baran, 1962]

Network Types [Source: Paul Baran, 1962]

One emerging technology that has barely scratched the surface in terms of implementation is the blockchain technology. The most common use of this technology to date has been for cryptocurrencies, such as Bitcoin. However, the blockchain technology is more than just for currencies; it can be applied to a plethora of systems, such as in transportation applications.

The best way to explain the blockchain technology is as follows – think of it as a centralized leger that is simultaneously distributed across multiple computing devices. Any one computer or “node” in the network would contain the whole ledger, regularly cross-checking and updating data with other “nodes”. The huge benefit here is a curated data set (inherent in the secure nature of the blockchain) that does not need to be centrally curated by any one company or entity. By nature, this could be an open-source solution where anyone is capable of accessing and applying the data within. Other “client” devices could access the data present on the ledger, but would not be required to hold the whole data set the same way each “node” would.

Such blockchain technologies could be used for such potential applications as data collection, near-real-time operational data, data analysis, transportation transactions (i.e. non-monetary tokens), and more. Regardless of the success or failure of Bitcoin as a specific application, the underlying blockchain technology behind it has thus far proven to be solid and should not be ignored. Examples of other, non-currency applications include Namecoin, Bitmessage, and Ethereum. This technology is only in its infancy, with many developers exploring its potential.

Crowdsourcing Data

Crowd Sourcing an Idea [Source: The Wina News]

Crowd Sourcing an Idea [Source: The Wina News]

More known in today’s internet, crowdsourcing of data is becoming more widely applied. Data collection is effectively outsourced to the general public (i.e. the crowd), relying on individuals to voluntarily contribute their own data points.  In terms of transportation, this would provide information on how people travel – directly or indirectly from each user. While some tools follow an open-data policy, others have their own ecosystems where data is applied back within the closed system to enhance the product.

Along the lines of transportation, here are a few examples of crowdsourced data:

The Waze app is one of my personal favourites. In the developer’s own words:

Waze is the world’s largest community-based traffic and navigation app. Join other drivers in your area who share real-time traffic and road info, saving everyone time and gas money on their daily commute.

Waze boasts live-time mapping where users can post traffic data, including accidents, construction, major events, and even speed traps for other users to be guided by. While somewhat controversial, this application is one example of how crowdsourcing can be useful for transportation.

Strava is an app you can use to self-track your activity data – cycling and running. At the time of writing, Strava appears to be testing a heat map that illustrates common travel paths utilized by individuals. Just one glance at this map and it is quickly apparent how such data could be applied to transportation planning, especially for active modes of travel.

Yet another entrepreneur has pioneered a $50 device for data collection of bicycles. Instead of hand counts and/or expensive communications hardware, this device uses low-powered Bluetooth to communicate bicycle counts to mobile devices passing by. In my humble option, this is quite ingenious, if it works, of course.

Open Source and API Solutions

Open Source Solutions [Source: int6ware]

Open Source Solutions [Source: int6ware]

Open source solutions have been around for a long time. They have been implemented alongside various pay models, even before the internet, to varying degrees of success. Considering the niche nature of transportation planning/operations and the very specialized applications required, I’ve primarily seen proprietary solutions in much of my career thus far.

So why include open source solutions again in this article? My answers: Open source development communities, such as GitHub, are allowing developers to come together from all over the world to collaboratively work on a problem or project; and, because open source solutions are currently being integrated into other proprietary software packages.

For example, I have seen Open Street Map integrated within modelling software packages, both as a base map layer and as a means to extract roadways for transportation model building. Other examples of open source solutions related to transportation include OpenCV or SimpleCV, which are used to analyze images and video, and OpenALPR, which is specifically used for license plate recognition.

Another “sort of” open source solution could be in the form of an application programming interface (API). An API acts like a “hook” in order to access proprietary / curated data sets or algorithms. Typically, using a request in the form of a query to a website address, the API provides a response of some sort of data or result. A practitioner can then use the response returned for additional analysis. An API could be applied for a one-off use or integrated into a larger application, potentially reducing proprietary development costs.

The easiest and most recognizable API to point to is the one used for Google Maps. More commonly, this API has been used to show locations (such as businesses) on maps.  However, it can also be applied in transportation planning. For example, I have used the Google API to calculate travel times/routing from multiple points; and, I have used the API to determine elevation profiles along study corridors, just to name a couple.

Yet another API related to transportation is the Walk Score, Bike Score, and Transit Score suite. These services are provided for existing neighbourhoods to illustrate how friendly these modes of travel are for a given location. As of this writing, Bike Score does not yet provide an API.

Moving Forward

Considering the above technological examples, where can we go from here? In the transportation industry, sustainability has taken hold over the past decade or two. Hand in hand with sustainability is technology, which provides the potential for improved efficiency to enable that sustainability. While we must be cautious in assuming technology will be the panacea for all that ails us, it should still be explored.

The following are a couple of parting thoughts for consideration:

  • Data storage is becoming cheaper and cheaper, thus more widely available. From the mobile devices we carry, to on-board vehicle computers, and to the storage of blockchain data, over time we will be able to carry more and more data with us.
  • Autonomous vehicles have also been gaining a lot of attention in recent years. At the Canadian Institute of Transportation Engineers (CITE) conference in Waterloo Region (2014), I attended a discussion about their role in the future and how they are poised to become a disruptive technology the same way automobiles were over a century ago. The point here is that distributed and/or decentralized technologies will enable these vehicles to communicate with each other, not only their relative positions to one another, but congestion conditions for real-time route planning during a trip.

How can individuals be incentivized to collect useful data for transportation planning / operations without intruding on their privacy? What are these types of technologies worth to governments and end users? At what point do these technologies reach “diminishing returns” in terms of their cost/benefit? These questions need more consideration and exploration. Nonetheless, it is not difficult to predict that many of these distributed tools for transportation planning and/or operational analysis will gain greater adoption in the coming years, especially with the shifting of demographics over time.

What do you think? What new technologies would you like to see in order to improve transportation planning and/or operations? How would this help your preferred means of travel (i.e. walking, biking, transit, vehicles, goods movement, etc.)? Would you be willing to anonymously contribute user data to help improve transportation planning and/or operations? Please leave your comments below.

Author’s Note: Featured image source from