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
- Origin: Users can change the starting location by pointing and clicking on a new location on the
map, or by using the search bar in the upper left corner to find a new origin point.
- Travel Mode: The mode of travel can be toggled by selecting an option in the upper right-hand
- Note: By default, this analysis assumes one will walk to the nearest transit stops before
boarding. “Transit” is analogous to “Walk + Transit”
- Time Interval: The time interval can be adjusted by dragging the slider near the bottom of the
- Note: There is a 120-minute maximum time interval based on the restriction of the API we are
utilizing, for increased time intervals, see the “Custom Inputs” section below.
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:
- counting the population within 30 minutes time-distance of a public facility;
- counting the number of businesses/jobs accessible from a given location;
- finding the median income of residents living withing 30 minutes of an office development
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
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
Open Street Map Edge Type Defaults
||Default speed (kph)
||Default speed (mph)
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.
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
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.
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.