Major enhancements in 0.9 include the following:

Additional 0.9.x bug fix releases are likely in the coming weeks, but the next major release will be 1.0, hopefully before the end of the year. The 1.0 release is expected to include expanded support for real-time planning and the new mobile-optimized user interface developed for bikeplanner.org, among other additions and enhancements. Stay tuned!

From TriMet’s press release announcing the launch:

In the past year, riders have planned more than 5.5 million trips using TriMet’s trip planning tools. Now riders can combine transit with biking and walking using the newest version of the online trip planner. This open source trip planning tool is the first produced by a transit agency in the U.S. that allows users to combine multiple modes of transportation.

“We’ve heard from riders that they want more tools to help them get around by transit, bike and foot, which aligns with TriMet’s and our regional partners’ mission to encourage active transportation,” said Bibiana McHugh, TriMet IT Manager of GIS and Location-Based Service. “So last fall we launched a test version of this innovative new trip planner. Since then, hundreds of riders have helped us fine tune the tool.”

On the other side of the U.S., cyclists in the Washington, DC area have a new tool for planning two-wheeled trips around the capital with the the launch of BikePlanner.org. The site was developed by OpenPlans in collaboration with Mobility Lab, BikeArlington, and MapBox. It is the second recent deployment the showcases OTP’s recently added support for real-time bike share trip planning, following the launch of CiBi.me in New York earlier in the year. Both sites also offer a preview of a new Leaflet-based user interface that is optimized for use with both desktop and mobile displays.

Reception to BikePlanner.org has been enthusiastic, with coverage of the launch including two articles in the Washington Post as well as stories by Greater Greater Washington and local radio station WAMU. The site was also featured as part of a larger write-up of OTP at SmartPlanet, “OpenTripPlanner redefines public transit navigation.”

OTP continues to expand its reach globally as well. The project now has a presence in Africa with the launch of the fromA2B application serving Gauteng province in South Africa, covering a variety of bus and rail services in the Johannesburg and Pretoria areas. Back in the northern hemisphere, the OTP-backed Opti-Trans planner was launched in London this summer,  just in time for the 2012 Summer Olympic Games. For a complete list of live OTP deployments, visit the demos page.

• OTP 0.7.10 released: Version 0.7.10 of OTP was released yesterday; the latest tagged source tree can be downloaded from Github and artifacts are also on the Maven repo. This release includes a number of bug fixes and enhancements; among the most notable is a fix to a longstanding issue with bridge topography that was producing inaccurate elevation profiles, sometimes severe enough to affect the routing algorithm. In short, the models OTP typically uses are terrain models rather than surface models, meaning that the profile for a route along a bridge that traverses a deep ravine would follow the terrain of the ravine, rather than the surface of the bridge (see below left). OTP now accounts for this issue when processing bridge links from OpenStreetMap and generates elevation profiles consistent with what a cyclist or pedestrian actually experiences (below right).
   

  

• iOS KickStarter Campaign Underway — As you may have heard, transit trip planning via Google Maps will no longer be a built-in feature on the iPhone and iPad with the release of iOS 6, expected later this fall. While the news has disappointed many transit riders who rely on their iPhones for directions, it also presents an opportunity for third-party app providers to expand their presence on the platform. To that end, OpenPlans has launched a Kickstarter campaign to fund development of a native iOS app that would support multimodal trip planning, backed by OTP, for all cities in North America with open transit data. Please help spread the word!

• Coming Soon: Leaflet-Based UI — OTP developers have been experimenting recently with Leaflet, a lightweight Javascript mapping library that emphasis mobile-friendly interfaces. An initial experiment with Leaflet and OTP, an OTP-backed trip planner for New York’s soon-to-be-launched CitiBike bike share system, has been well-received by users, and work is currently underway on generalizing that UI to other OTP-based applications. Stay tuned for more updates!

However, the routing engine at its core has the potential to answer much more general questions about efficient paths through the city. These possibilities are what originally drew me to OpenTripPlanner, and my primary role within the project is now expanding OTP’s range of applications beyond passenger information into the areas of spatial analysis, urban planning, accessibility research, and transportation engineering.

All paths explored while finding a single itinerary (with goal direction disabled)

Many of these applications require very large batches of near-identical requests with the origin or destination taking on every value in some set. That set might be the centroids of census tracts when evaluating effects of a public transit service cut, the location of all real estate transactions over a given year in a housing price study, or a regular grid of cells or pixels in urban accessibility and travel time mapping applications.

At first glance, using OTP to find paths from some origin to thousands or millions of individual destinations seems like an excruciatingly slow process — and it would be if we adopted the naïve strategy of making the same request to the server over and over, changing only the destination each time. However, algorithms that find a shortest (a.k.a. lowest cost or “best”) path through a multi-modal transportation network produce a great deal of internal information that is discarded after only a few itineraries are returned to the user. With appropriate modifications this data about alternate paths can be retained and put to use in a variety of ways.

The OTP Analyst extension does just that. When finding an itinerary from point A to point B, many path search algorithms, from Edsger Dijkstra’s 1959 classic to it’s newer timetable-friendly variants, also produce paths to every point closer than B as a byproduct with no extra effort. By simply letting the algorithm run a little longer until the search reaches every corner of the graph, we obtain every shortest path branching out from a given origin point.

Taken together, all these paths form a “tree” rooted at a given departure point (or arrival point in the case of an arrive-by search). This data structure contains a lot of implicit information about the temporal landscape of the city as perceived from its root. We can for example calculate travel time to an arbitrary point within the geographic area covered by our OTP server by simply finding the closest segments in the street network, taking the perpendicular distance to those segments, and adding the travel time for the final leg to that given by the path tree. Travel time is then a function defined over a continuous 2D domain (a surface), and this function can be evaluated at any set of points specified by the user. Once computed, relationships between these points and neighboring streets can be cached, allowing results to be rapidly re-evaluated when some search parameter is changed.

The problem remains of how to meaningfully display or analyze all this information. Perhaps the most straightforward option is a map layer using colors or transparency to indicate travel times. In this case, the travel time function is simply evaluated at a regular grid of points corresponding to the individual pixels that make up a map in a particular projection. OpenTripPlanner exposes this method as a WMS service and a tile layer that can be overlayed on any standard base map.

“]

A regular grid of points linked to the nearest street segments in an OTP routing graph.

As a demonstration of these capabilities, we have set up a demo at http://analyst.opentripplanner.org/opentripplanner-analyst-client/. Since the Analyst module was recently merged into OTP proper, all the usual trip planner parameters now apply to Analyst requests, including departure time, mode of transportation, and maximum walking distance. The screen capture below shows public transit travel time from a point in central Washington, DC, with each color band representing 30 minutes of travel time in the order green, blue, yellow, red. Note that these are not solid blocks of color — the travel time gradient is expressed to one-minute resolution by varying saturation within each band.

Travel times from a point in central Washington, DC. Each color bands represents 30 minutes.

Multiple rasters can also be combined on the server side. A good example is the potential path area visualization, labeled “Hägerstrand” in the demo after the geographer who theorized it. Given an origin and destination place and time, it maps the remaining time to perform some activity along the route. This is essentially a 2.5D projection of Hägerstrand’s time/space prism onto the map surface. The image below shows the part of Washington, DC accessible to someone who must leave the green marker after 8:00 AM and arrive at the red marker before 9:30 AM via public transit. Greater transparency indicates a larger amount of time available to perform some activity at the intermediate location.

Potential path area via public transit for departure after 8:00 AM and arrival before 9:30 AM.

We are by no means limited to examining travel time. Any information accumulated in OTP State objects during the search is a candidate for display or analysis. For example, here is a map of the number of vehicles boarded in the lowest-cost path to each point in the Washington, DC area, starting from the New Carrollton station of the proposed Purple Line (but with service on that line disabled):

Number of vehicles boarded in lowest-cost paths to destinations in Washington, DC. (green:0, blue:1, yellow:2, red:3)

Over the coming months we will be identifying alternative metrics for transit quality of service and urban accessibility. The most effective ones will make their way into OTP Analyst. We are also not constrained to presenting our results as an image or on a regular grid. It is equally possible to substitute some other arbitrary set of endpoints from a shapefile or spatial database. As with map tiles, their relationships with streets are pre-computed, accelerating subsequent evaluations of the same points. The resulting data sets can be analyzed in external tools such as the open-source R statistical package.

Linear least-squares model for relative housing prices as a function of transit travel time from the city center. R-squared 0.20, p-value: < 2.2e16

The growing worldwide availability of open transit data in de facto standard formats means that once developed, spatial analysis tools can serve in both comparative and targeted studies in a large number of places. My hope is that besides enabling citizens to appropriate transportation planning methods and mobilize their resulting expertise in defense of the public interest and quality of life, the Analyst extensions to OpenTripPlanner will help the academic and planning communities to better grasp the syntax of the urban environment and factors favoring spatial legibility for those of us navigating it via shared, scheduled and non-motorized transport.

OpenPlans is pleased to announce the launch of OTP Deployer, the first fully automated deployment and hosting platform for OpenTripPlanner. It is available for public use at deployer.opentripplanner.org.

The purpose of the OTP Deployer project is to make launching an OpenTripPlanner deployment as simple as possible, particularly for transport providers who want to quickly see what OTP would look like for their system. In doing so, we seek to address what is currently one of the significant  barriers to widespread adoption of the platform: the relatively complex and technically demanding process of assembling the necessary data and setting up a live, usable OTP deployment.

To set up a hosted OTP instance using the deployer, all agencies must do is provide one or more GTFS feed(s) that represent their transit network. The application will automatically extract street network data from OpenStreetMap, and deployments within the United States will also include elevation data from the National Elevation Dataset. OTP Deployer then leverages the Amazon Elastic Compute Cloud (EC2) platform to both automate the OTP graph building process and the actual hosting of a built OTP instance.

There are currently two ways to use the service:

• Remote Graph Building — OTP Deployer can be used as a remote graph-building service by users that have their own means for deploying and hosting a built OTP instance. GTFS files are submitted using the web-based interface, and once complete, the user will be provided a link to download the graph file. OpenPlans is providing this feature as a free service to the OTP community.
• Hosted OTP Deployment — In addition, the platform supports ongoing hosting of OTP instances. OpenPlans will provide “preview” hosting at no charge for up to one week. Please contact us if you are interested in longer-term hosting.

The workflow logic for OTP Deployer is written primarily in Python, with the web interface built using the Django framework. All original code for OTP Deployer is open source and is available online via Github. The repository also includes an issue tracker for bug reports and feature requests.

As the OTP Deployer project moves forward from preliminary development and beta testing, a number of additional enhancements are planned, including automated integration with companion OTP projects such as the OTP Analyst extension, potential native support for elevation data for non-U.S. deployments, and redundant hosting of deployed OTP instances for production applications.

For more information, please don’t hesitate to contact me at demory@openplans.org.

As we prepare to celebrate the project’s third birthday next month, it is safe to say OpenTripPlanner has grown faster than any of us at the 2009 kickoff could have imagined. The codebase currently stands at over 100,000 lines of code, with more than 2500 commits and 600 closed tickets to date. The user interface has been translated into 12 languages, and several dozen live deployments can be found in ten countries. Most recently, the project’s scope has expanded beyond the initial focus on traveler information to also include a major policy analysis component.

As the project continues to mature, it is important that OTP be presented in a compelling and welcoming way, especially to those just joining the project. With that in mind, today we are pleased to launch this completely rebuilt version of opentripplanner.com, the project’s public face to the online world. Although the site was developed by OpenPlans, one of the project’s founding supporters, we intend for it to serve as a resource for the entire OTP community, and we are actively building content aimed at the project’s various audiences (including users & developers, transport providers, vendors, and researchers).

This site does not replace the various avenues for project communication and coordination already in place, such as the GitHub wiki, the mailing lists, IRC channel and so forth. But going forward, we do hope that the site can help broaden the conversation and expand the OTP’s audience online. This front-page project blog will be a particular focus; in addition to routine project updates, we anticipate a series of more in-depth posts on a range of topics, from project architecture to deployment case studies to future project directions. (The blog will be a collaborative effort; if you’d like to contribute, please let us know!).

Thanks to everyone who has contributed to the OpenTripPlanner project in any way over the past three years. We can only imagine what the next three years will bring!