min

walk
bike
car
transit
Export Features
User Guide

HR&A Travelshed Mapping Tool

HR&A’s travelshed mapping tool is a web-based application for mapping the set of all destinations that can be reached from a location within a specified time budget. The travelshed area is sometimes also called an “isochrone.

Directions:

How is this useful?

The resulting travelshed geometries give quick visual cues about access, but can be used in further geospatial analysis. Some examples of their utility include:
The “Export Features” button allows for the download of the geographic data of the displayed travelshed in “GeoJSON” format for import into other GIS software such as ArcGIS Online where the user may run a geoenrichment analysis to find demographic data. Guides for how to use GIS are saved here.

Assumptions and Sources

The core routing technology is the Targomo API which utilizes OpenStreetMap (OSM) for the street network data represented in the “Walk”, “Bike”, and “Car” options. OSM provides both the geospatial data for the road network as well as data on street speed restrictions, accessibility flags, and turning restrictions, among others.

The generated transit routes where available are based on GTFS (General Transit Feed Specification) data provided by local transit agencies. A list of cities currently covered is available here. Transit is defined as any service provided by a public transit agency and includes busses, trains, and ferries where they exist. If you are unsure if the transit system you are looking for is represented, you can confirm by toggling between "Walk" and "Transit" to check for differences. If no transit data is available, the Walk and Transit layers will be the same.

The trip planning software creates a graph object by overlaying the transit network with the street network and identifying connections and points of transfer. The intersections between roadways, along with individual transit stops, become nodes and the connecting roadways and transit lines become the “edges” of the graph. The software uses the travel assumptions listed below to find the travelshed for any given point.

Routing - Streets

The trip planning software takes into account different types of roads as well as access flags, if present. Roads like motorways and other major roads are not accessible for pedestrians, while footways and pedestrian-only streets are not accessible for cars, unless they are flagged otherwise. It also fully considers turning restrictions for cars and bikes. If a crossing has a restriction that forbids turning from one street to another the algorithm will not take this route. Speed limitations of streets are also taken into account if present; otherwise, the following defaults are used. Elevation data has no impact on car routing. OSM’s default roadway assumptions for different classes of roads are listed below (Note: these assumptions are only utilized when a local municipal transportation authority has not provided more detailed speed restrictions):
Open Street Map Edge Type Defaults
Roadway Type Default speed (kph) Default speed (mph)
Motorway 120 75
Motorway Link 30 19
Trunk 90 56
Trunk Link 30 19
Primary 70 43
Primary Link 30 19
Secondary 60 37
Secondary Link 30 19
Tertiary 40 25
Residential 40 25
Tertiary Link 30 19
Road 30 19
Unclassified 30 19
Service 5 2
Living Street 7 4
Pedestrian 5 3
Track 10 6
Path 10 6
Cycleway 15 9
Footway 5 3
Steps 5 3
Unknown 5 3
Ferry 10 6
Penalties
Driver’s-side turns and traffic lights impose a penalty to the travel time.
A “Rush Hour” penalty is enabled by default (unless requested otherwise), applying a statistical probability for congestion based on the density of streets. This is then used to slow down the travel time for car travel.
Uphill/Downhill Travel
Walking and cycling also take elevation into account (unless requested otherwise). Uphill and downhill travel are altered using “uphill” and “downhill” parameters. Positive values acquired from OSM slow down travel while negative values speed it up. This is done by virtually increasing or decreasing the length of a street. Every meter in elevation difference, multiplied by the uphill or downhill penalty, increases or decreases the length used to calculate the travel time. So every additional vertical meter uphill with an uphill penalty of 10 is equivalent to an additional 10m of horizontal travel. The defaults are currently: uphill=10.0, downhill=0.0 for walking and uphill=20.0, downhill=-10.0 for cycling. The default speed without elevation for walking is 5.0 km/h, for cycling is 15.0 km/h

Routing - Transit

The General Transit Feed Specification (GTFS) is a data specification that allows public transit agencies to publish their transit data in a format that can be consumed by a wide variety of software applications. The GTFS used in the model is the static version that aligns with the published transit agency schedule along with geographic transit information such as stop locations and line routing. While real-time GTFS exists for routing in online mapping platforms such as Google Maps, accounting for delays and unexpected schedule changes, the model is meant to be a generalized tool based on macro-level transit schedules.

When using public transportation, the routing is performed for a time window (frame). The algorithm searches for the shortest route(s) in the given timeframe based on the static schedules provided by the local transit authority. For example, using a transit frame starting at 8:00am and a duration of 2 hours, a polygon ring for 20 minutes will include all points reachable within 20 min regardless of starting the travel at 8:00am or 9:40am. The default travel time for this analysis is set at 1.30pm. with a duration of 2 hours (unless requested otherwise).

Entering, leaving and changing a transit vehicle imposes a penalty; a route has to be faster (compared to walking and other transit routes with their penalties) at least by the sum of these penalties to be considered. The penalties are currently 90 seconds for entering and leaving and 180 seconds for changing.

Custom Inputs

If you are looking for a variance from the default assumptions, contact Kevin who can set-up the analysis. Currently, the API utilized does not allow for time intervals greater than 120 minutes, but it is possible for us to deploy a server running the routing software independently to incorporate greater time intervals or to make adjustments for new or unrepresented transit agencies or to other default assumptions.

If the transit system you are looking for is not represented, check TransitFeeds to check if your locality provides transit data in GTFS format, in which case, in which case it can be easily added to a new deployment of the routing software. If your local transit agency does not provide schedule data in GTFS format, it is still possible to run an analysis by converting the schedule to GTFS using an online GTFS manager (such as this one.) If you are interested in modeling accessibility for a transit agency without data in GTFS or for a prospective future transit route, please contact Kevin.