GTFS but for …

2000px-GTFS_class_diagram.svgJacob Baskin writes:

The Story of GTFS

GTFS is one of the biggest success stories in mobility data. In 2005, Chris Harrelson, a Google engineer, worked together with IT managers at TriMet, the transit agency for the Portland, Oregon metro area, to take an export of their schedule data and incorporate it into Google Maps to provide transit directions. The next step was adding transit in four more cities. Naturally, when Chris asked them to give him their transit data, he asked them to all provide it in the same format. In 2006, that format was enshrined as the Google Transit Feed Specification.

This GTFS format was static, a representation of where buses and trains were supposed to be according to schedule. Since then, a lot of progress has been made on real-time transit vehicle location data, and standards have emerged, and there is a real-time GTFS standard. Version 2.0 is out.

Given the success of GTFS, we want to know why so many other things are not standardized and openly available. This post summarizes the state to date of “GTFS but for.”

Applications:

 

  • Curbs
    • “SharedStreets creates a structured language for the street, unlocking new ways of collecting, analyzing and sharing information. A shared language lets us exchange information about what’s really happening on our streets, breaking down barriers the between public and private sectors, and combining layers of data in new ways to make streets work better for people.”
    • While it lacks curb usage data, DDOT (Washington DC DOT) has open public street cross-sectional data.
  • Parking (on and off street)
    • This is related to curb data in the on-street sense, but would track utilization as well as capacity, legality. It would also include off-street data.
  • Traffic signals states (past, present, and scheduled/future)
    • “There is an ongoing challenge to get 20 signals in all 50 states by 2020 to broadcast the signal phase and timing. A lot of progress has been made & agencies are deploying well into the 100s of signals. Resources and info can be found at  ” – Patrick Son
    • Traffic Technology Services has an API, which they charge for, for accessing this standard traffic signal data which AUDI uses for in-vehicle traffic light information. They claim 4700 signals in the system currently. Some DOTs have feeds accessible with registration.
    • VDOT’s SmarterRoads open data. Includes signal phase and timing based on J2735, for all state-controlled signals (which is most of Virginia). Also includes real-time tolling HOT tolls for I-66 and much more.
  • Services
    •  Taxis/ridesourcing
      • Some cities, e.g. New York, require taxi and ridesourcing companies to make data available. In other places, this is proprietary. Some companies are sharing selected data (Uber is sharing some data via Movement, as well as SharedStreets.)
    • Shared vehicles (bikes, ebikes, scooters)
      • Some of the shared bike and scooter companies make their data available. Others don’t. For instance, New York’s CitiBike data is available. There is a GBFS (General Bikeshare Feed Specification) standard. The trove of available data is collated at bikeshare-research.org.
      • DC also requires bike and scooter shares to provide public real-time information via an API, although the format varies. 
    • Shared vehicles (cars)
    • Mobility-as-a-Service – The City of Los Angeles has established a Mobility Data Specification. Transport for NSW has a proposed Specification for MaaS.
  • Traffic data (vehicle counts, turning movements, speeds, vehicle locations, etc.)
    • Various states have information like this, but it is not standard between states as far as I can tell. See e.g. PEMS (California) or IRIS (Minnesota)
  • Real-time tolls, road prices.
    • There is no standardized feed type, though various agencies make this public.
  • EV charging stations and occupancy (queue length)
  • Logistics (open delivery services, physical internet)

There is of course some movement. The V2X community (vehicle to vehicle, vehicle to infrastructure, etc.) is setting standards, but they are not widely deployed nor used, nor are the outputs freely available on the internet  — the challenge to get 1000 traffic signals by 2020, out of the million or so out there in the US, “broadcasting” their state (locally and online), shows the sluggishness of deployment.

The first issue is standardization. When the data is standard, applications can be built that suck it in, process it, and provide useful outputs. No one has to reinvent the data filter for every distinct agency.

The second issue is openness. The data needs to be easily accessed. The traffic signal data may exist, but there is as far as I can tell, no open source place where one can go and grab it all.

Some providers might value incompatibility or secrecy for their data, especially parking vendors who are in competition. From a societal perspective all of this information should be freely available (gratis (free as in at no cost) and libre (free to use in any interesting way)). Making these data available in a standard format should be a quid pro quo for a license to operate a parking facility, a taxi or shared vehicle, or a toll road.

What else should there be a “GTFS” for? How do we get from here to there? What other initiatives out there show promise?

Open Traffic

Open Traffic is a new initiative to make GPS traffic data open and available to the public and others, by linking it with OpenStreetMap. It is organized by Conveyal, MapBox, and MapZen with support from the World Bank. The Code is of course open source as well.

OpenTraffic is a free, global traffic speed data set linked to OpenStreetMap built with open source software.

Traffic speed data is a critical input to many transportation related applications. Fortunately many users who need speed data also produce the inputs necessary to create annonmyized traffic statistics.

OpenTraffic provides the space and tools to share traffic statistics from connected vehicles and mobile services. We support the development of analysis and routing tools that enable cities, businesses, and individuals to make use of this data.

How it Works

OpenTraffic connects anyone with real-time or archived GPS location data to processing technology, data storage, and routing and analysis applications.

Location data privacy is paramount. We allow contributors to share anonymized traffic speed statistcs from derived GPS data without disclosing individuals’ location information. In return, data contributors help build a global traffic speed data set that can be used in routing and analysis applications.

The OpenTraffic platform is comprised of several components to make it easy to share and use traffic data:

GPS Probes

GPS probe data can be generated from a variety of sources, including mobile applications or fixed GPS hardware. GPS data can be processed in real-time or archived and transmitted for batch analysis. The OpenTraffic platform has a variety of open source tools to help you load your GPS data from existing sources or connect to Amazon AWS Kinesis streams to manage real-time flows of any size.

Traffic Engine

GPS data is linked to the OpenStreetMap network via Traffic Engine. Data is converted from GPS locations to roadway speed observations and anonymized before being aggregated. As open source software, you control where Traffic Engine is deployed, allowing full control over GPS trace data. Simply install Traffic Engine and load your GPS data to start generating traffic data.

Data Pool

Once anonymized, traffic statistics are added to the global OpenTraffic data pool. By pooling data many different data sources are merged together to provide a seamless global data set, free for use by any application.

Get Involved

We are working with vehicle fleet operators, app developers, and governments to develop and operate the OpenTraffic platform. Learn how you can contribute and benefit: Contact Us

Open Source Trip Generation

We have long known in the transportation planning community that the use of trip generation for local area review, and ITE’s procedure for estimating trip generation is broken in any number of ways. Shoup’s Truth in Transportation Planning is a classic critique of the problems.

While we could (and perhaps should) throw the whole kit and caboodle into recycling, in practice trip generation methods will be with us decades from now (even as traditional work, shopping and driving disappear). So there is a small academic movement to make the methods better. The most recent issue of JTLU 8(1) has a special section on Trip Generation, including several papers about how to adjust and improve ITE’s Trip Generation methods based on better data.

Part of the problem is that ITE is functionally a for-profit organization, and makes bank on selling the Trip Generation Manual and associated software (recognizing the fact that use of ITE Trip Generation rates is ensconced in law and regulation).

What has long been needed is an open source database of trip generation studies so that better fits to actual site conditions can be used in analysis. I recall in my youth some engineers in Montgomery County, Maryland trying to set something up, but this was well before the world wide web made that easy.

Fortunately that day is upon us. Mike Spack and company have set up TripGeneration.org, which is populated with open access trip generation studies (licensed under a Creative Commons license), and for which they hope to grow the data set. This is new, and I assume as it grows the data will get better and better, as will the methods for inputting and extracting data. Kudos to Mike, Nate, and others at Spack Consulting for getting this going. I look forward to seeing where this goes, as Big Data and new sensors make data collection increasingly ubiquitous.

Developing a Comprehensive US Transit Accessibility Database

Recent working paper:

Transit Accessibility in Minneapolis
Transit Accessibility in Minneapolis

Owen, A. and Levinson, D. (2014) Developing a Comprehensive US Transit Accessibility Database

  • This paper discusses the development of a national public transit accessibility evaluation framework, focusing on lessons learned, data source evaluation and selection, calculation methodology, and examples of accessibility evaluation results. In both practice and in research, accessibility evaluation remains experimental and methodologically fragmented. This heightens the “first mover” risk for agencies seeking to implement accessibility-based planning practices, as they must select a method which might produce results that can only be interpreted locally. Development of a common baseline accessibility metric could advance the use of accessibility- based planning. The accessibility evaluation framework described here builds on methods developed in earlier project, extended for use on a national scale and at the Census block level. Application on a national scale involves assembling and processing a comprehensive national database of public transit network topology and travel times. This database incorporates the significant computational advancement of calculating accessibility continuously for every minute within a departure time window of interest. Values for contiguous departure time spans can then be averaged or analyzed for variance over time. This significantly increases computational complexity, but provides a very robust representation of the interaction between transit service frequency and accessibility at multiple departure times.

Simulating Cities with OpenStreetMap and OpenTripPlanner Analyst


From State of the Map 2014, a Video by Kevin Webb of Conveyal

In this session I will discuss transport accessibility modeling using OpenStreetMap and OpenTripPlanner Analyst.

Accessibility analysis techniques are one of a suite of tools used by transport planners to understand the efficiency of a city authority’s transportation system, and to inform decision-making about transport service planning.

The goal of the OTPA project is to produce quantitative indicators that inform debate and decision-making processes by revealing hidden dimensions of the relationship between transportation and land use.

We are using and extending OTP as part of the Accessibility Observatory.

Announcing the Journal of Transport and Land Use

Announcing the
Journal of Transport and Land Use

www.jtlu.org – ISSN 1938-7849

The Journal of Transport and Land Use is a new open-access, peer-reviewed online journal publishing original inter-disciplinary papers on the interaction of transport and land use. Domains include: engineering, planning, modeling, behavior, economics, geography, regional science, sociology, architecture and design, network science, and complex systems.


Summer 2008 issue available: www.jtlu.org

Contents:

Sprawl and Accessibility
Martin Bruegmann, Professor of Art History, Architecture, and Urban Planning, University of Illinois at Chicago
(Author of Sprawl: A Compact History)

Counterpoint: Sprawl and Accessibility
Randall Crane, UCLA Department of Urban Planning
(Co-editor of the forthcoming Oxford Handbook of Urban Planning)

Cities as Organisms: Allometric Scaling of Urban Road Networks
Horacio Samaniego and Melanie E. Moses, Department of Computer Science, University of New Mexico

A Use-Based Measure of Accessibility to Linear Features to Predict Urban Trail Use
John R. Ottensmann and Greg Lindsey, Center for Urban Policy and the Environment, Indiana University-Purdue University Indianapolis

Integral Cost-Benefit Analysis of Maglev Rail Projects Under Market Imperfections
J. Paul Elhorst and Jan Oosterhaven, Department of Regional Economics, University of Groningen (Netherlands)


To learn more about the Journal of Transport and Land Use, visit www.jtlu.org or contact:
David Levinson, General Editor: dlevinson@umn.edu
Kevin Krizek, Editor (Americas): krizek@colorado.edu

The Journal is housed at the University of Minnesota and sponsored by the Center for Transportation Studies.