The Arlington Transit Tech Initiative provides an exciting opportunity to rethink individual commute options and travel planning in general.
Most existing travel-planning applications are well-suited for providing detailed, step-by-step directions for a particular trip at a particular time – for instance, how to travel from your home to your office on transit, leaving at 8:30 on a Monday morning. What these tools generally don’t do as effectively is provide users with a “big picture” view of how these places are connected without regard to specific times or itineraries, and how a user’s various travel options fit into the context of the larger transport network.
The Arlington Transit Tech Initiative is an opportunity to visualize data in a new and more complete way. To that end, a new library Transitive.js, has been created that will leverage the latest in web-based visualization practices to create a new type of user experience for online travel-planning applications.
To provide the more holistic, bigger-picture results that are lacking in existing travel planning apps, it’s important to rethink how we visually articulate transport network information to users in the context of online travel-planning applications. Specifically, we need to move away from the literal, geographical depiction of specific trip itineraries towards a network-based representation that highlights the salient elements of what we are trying to communicate about a user’s travel options.
As a starting point, we can look to the practice of stylized or schematic transit maps that has become commonplace around the world. Originally pioneered by Harry Beck’s London Underground map of 1931, which took its inspiration from electrical circuit diagrams, schematic maps seek to distill a network to its most essential representation, de-emphasizing real-world geographic detail and instead focusing on the underlying topological structure of a network.
Visual clarity and readability are key to these graphics, which often involve constraining the layout of the map to defined geometric parameters (often straight lines and 45-degree angles), and using a clear visual language of colors, styles, and symbols to convey specific information about the service being depicted. We see many of these elements at work in the now-familiar map of the Washington D.C. Metrorail system:
While this approach to transport-network visualization is now well established and widely used, it has traditionally been very “static” in nature, with most schematic transport maps created manually by professional graphic designers using desktop graphic applications like Adobe Illustrator. Given the labor-intensive nature of such work, schematic transport mapping has traditionally been limited to only those applications that speak to very large audiences of riders – for instance, an overview system map like the one above, or “spider maps” that show all services intersecting at a major transfer hub.
But what if we want to use the schematic mapping approach to visualization for more specialized or personalized results? Say we have a journey planner that can return a set of all possible transit connections between two points, and we want to display these results in a simple visual way that is easy for the user the grasp. Representing this “personal network” in the style of a schematic system map could be a great help to the user, but such an approach is not feasible on a widespread scale if we are relying on the manual creation of stylized network graphics.
Furthermore, what if we want to add an interactive component to stylized transit maps? Static maps typically focus on the overall spatial layout of a network, usually without regard to time of day or other temporal characteristics. But what about non-spatial variables? Factors like service span, frequency, and network robustness are often of great importance to users, but displaying this information on a static map can be challenge (as seen in the D.C. example above, where dashed lines are used to indicate special rush-hour-only service). Adding interactivity to this sort of visual display – for instance, a slider that represents time of day, with the map instantly redrawn as the user selects different time ranges – could greatly enhance the power of these graphics to convey complex information in an easy-to-understand way.
What we are effectively proposing in the above questions is a combination of the elegance and simplicity of professionally-designed schematic transport maps with the high degree of customization and personalization provided by interactive online journey planning applications. It is a synthesis of approaches that, to the best of our knowledge, has never been directly addressed in a transport mapping package, and it is exactly what Transitive.js has been created to accomplish.
At the core of the project is the automation of stylized map creation, a conceptually challenging problem that is perhaps easiest thought of as a sequence of steps, beginning with raw inputs describing the transport network and any specific journeys we want to highlight, and ending with a stylized visual display of that information. We can summarize this transformation visually as follows:
This visual workflow provides a high-level template for what Transitive.js is trying to achieve. Below, we explore the key elements of the project in greater detail.
Importing the transport network data: The transit network information we are displaying is derived from GTFS data, which provides a raw feed of basic network elements such as routes, stops, and individual trips. In order to display this information in a schematic way, however, additional processing of the GTFS is needed to add more structure to the network representation, which includes the identification of route “patterns” and grouping stops where appropriate. We may also want to show one or more journeys through the network, and need a way to describe those paths in terms of the underlying network elements.
Extracting the underlying network topology: Once the network and journey data has been processed and loaded as collection of network elements, we must construct from those inputs a representation of the network that is suitable for schematic mapping. To accomplish this, a topological graph of vertices and edges is created that represents the simplest possible geometric model of the network. After the graph is created, geometric constraints are applied, usually by “snapping” the edges and vertices to a defined set of angles and alignments. This geometrically constrained graph now provides a “wireframe” of sorts for the visual display of the network, on top of which specific visual elements (routes, stops, journeys) can be rendered.
Dynamically styling and rendering the network elements: With the underlying topological structure of the transport network now modeled, it is time to render the network graphically. Transitive.js is being built on the D3.js visualization library, which gives us a powerful toolkit for transforming our data models of the network into an SVG-based visual representation on the user’s screen. How that transformation happens, however, is its own unique challenge — at the heart of this task is defining and implementing a clear and consistent visual language for the styling of transport networks. Below is an example of a collection of journey options for a specific trip that have been rendered and styled using Transitive.js:
The above graphic illustrates several options for getting from the Mobility Lab office in Rosslyn to Union Station in D.C., including walking to the Rosslyn Metro and taking a series of trains (Orange to Red or Blue to Red, transferring at Metro Center) or, alternatively, walking to a nearby bus stop (Lee Highway & Quinn Street) and taking the 3Y to the Farragut North area, where a transfer to the Red Line is possible. Even in this relatively simple example, we see many of the styling decisions that the Transitive.js project seeks to address; for instance, how we clearly distinguish between different lines and modes, how we present stops and other points of interest (such as our start and end points), and what elements we label and how.
Styling can also be dynamic, with the display of visual information changing based on user inputs or activity. In the following rendering of the same set of journey options, we use styling to highlight a particular option by “graying out” the segments that are not of interest:
Styling is a critical component of the Transitive.js project, and will be explored in greater detail here soon.
Providing a seamless, interactive user experience: Interactivity is a key part of the user experience that we are seeking to provide. The Transitive.js library provides functionality for basic visual manipulation such as panning and zooming, and will also provide an API so that the library can be combined with other UI toolkits to create a fully interactive experience. As part of the Arlington Transit Tech Initiative, a related project, the Commute Planner tool, is being built that incorporates the Transitive.js rendering engine as part of a larger, interactive user experience.
With Transitive.js, we are seeking to provide a new kind of visual experience for users of the transport network, one that will combine the best elements of traditional static transit mapping – visual simplicity and understandability – with the interactivity and individualization provided by online journey planners.
Follow the project’s progress at https://github.com/conveyal/transitive.js.
Photo by Jennifer Snyder