TransitWiki - User contributions [en]

Planning Tool Exchange

2018-06-29T16:52:04Z

Aaronantrim: Update: This website appears to have shut down.

{{edit queue
|editor=Leeor
}}
{{infobox
|title=Planning Tool Exchange
|vendor=Oron Family Foundation
|website=http://www.planningtoolexchange.org/
}}

Update: This website appears to have shut down.

Project Evaluation Tool Comparison

2018-06-29T16:49:50Z

Aaronantrim: added note about TriMet's Farecard and Ridership Data Analysis project

This matrix shows various attributes for a series of tools that were evaluated for supporting the Atlanta Regional Commission in the 2018 Transit Vision update and for TriMet's Farecard and Ridership Data Analysis project. If you have any comments suggestions, or edits, please contact [[User_talk:Leeor|Leeor]].

[https://docs.google.com/spreadsheets/d/1Nrx8mpp55R66uwgXiKi9o_6AQtutnbcSWuvavXhh5Pc/pubhtml Project Evaluation Tool Comparison Matrix]

Project Evaluation Tool Comparison

2018-06-29T16:49:15Z

Aaronantrim: added note about TriMet's Farecard and Ridership Data Analysis project

This matrix shows various attributes for a series of tools that were evaluated for supporting the Atlanta Regional Commission in the 2018 Transit Vision update and for TriMet's Farecard and Ridership Data Analysis project. If you have any comments suggestions, or edits, please contact[[User_talk: Leeor | Leeor]].

[https://docs.google.com/spreadsheets/d/1Nrx8mpp55R66uwgXiKi9o_6AQtutnbcSWuvavXhh5Pc/pubhtml Project Evaluation Tool Comparison Matrix]

Project Evaluation Tool Comparison

2018-06-29T16:48:07Z

Aaronantrim: added note about TriMet's Farecard and Ridership Data Analysis project

This matrix shows various attributes for a series of tools that were evaluated for supporting the Atlanta Regional Commission in the 2018 Transit Vision update and for TriMet's Farecard and Ridership Data Analysis project. If you have any comments suggestions, or edits, please contact [[User_talk: Leeor | Leeor]].

[https://docs.google.com/spreadsheets/d/1Nrx8mpp55R66uwgXiKi9o_6AQtutnbcSWuvavXhh5Pc/pubhtml Project Evaluation Tool Comparison Matrix]

Talk:Planning Tool Exchange

2018-06-29T16:40:12Z

Aaronantrim: The website/domain appears to be invalid.

The website/domain http://www.planningtoolexchange.org/ appears to be invalid. --[[User:Aaronantrim|Aaronantrim]] ([[User talk:Aaronantrim|talk]]) 16:40, 29 June 2018 (UTC)

Talk:Bus rapid transit

2018-02-19T20:52:14Z

Aaronantrim: /* frequent service discussion */ new section

article created --[[User:Amiller|Amiller]] 09:32, 20 July 2012 (MST)

== frequent service discussion ==

Perhaps on another page it would be useful to add a discussion of high-frequency transit planning and operations -- and, in particular, discuss headway-based dispatch. --[[User:Aaronantrim|Aaronantrim]] ([[User talk:Aaronantrim|talk]]) 20:52, 19 February 2018 (UTC)

User:Bcon29

2018-02-01T16:24:58Z

Aaronantrim: added contributions link

[[Special:Contributions/Bcon29]]

User talk:Bcon29

2018-02-01T16:24:07Z

Aaronantrim: welcome!

Welcome to TransitWiki. Can you please create a user page so that we know who you are? --[[User:Aaronantrim|Aaronantrim]] ([[User talk:Aaronantrim|talk]]) 16:24, 1 February 2018 (UTC)

Swiftly

2018-01-31T18:25:43Z

Aaronantrim: created page

{{Stub}}

Provider of Insights and Transitime.

Company website: https://www.goswift.ly/

[[Category:GTFS-consuming applications]]
[[Category:Category:Real-time applications]]

Automatic vehicle location

2018-01-31T01:20:52Z

Aaronantrim: /* Types of Systems */ GPS!

[[Image:CulverCityBus.jpg|right|thumb|350px|Culver City's CityBus uses Automatic Vehicle Location on its buses. Photo by Flickr user DPRegionalTransport.]]

==Introduction==
Automatic Vehicle Location (AVL) describes the use of computers and Global Positioning Systems (GPS) in dispatching and tracking transit vehicles. AVL is accompanied by added costs of operating and maintaining additional computer equipment, but transit agencies benefit from improvements to customer service through [[real-time information]]. Operating costs, however, are not generally reduced by these improvements. Because AVL is becoming so common, it is increasingly becoming expected as standard for fixed-route systems. AVL is very common on [[bus rapid transit]] systems<ref name="tcrp73">[http://www.trb.org/main/blurbs/159906.aspx Parker, D. J. (2008). “AVL Systems for Bus Transit: Update.” Transit Cooperative Research Program.]</ref>. AVL systems can vary widely in cost - from $100 to $7,000 per bus, depending on the type of technology being used<ref>[http://www.trb.org/Publications/Blurbs/152932.aspx Schweiger, C. (2003). "Real-Time Bus Arrival Information Systems." Transportation Cooperative Research Program."]</ref>.

==Types of Systems==
There are two commonly used types of tracking technologies: Radio navigation and dead-reckoning technologies. Radio navigation was used in the earliest AVL systems, which use radio transponders that communicate with passing buses and a central dispatch center. These include ‘signpost’ transponders that are mounted on posts above the height of the bus, to allow communication at level with antennas on top of the vehicles. Dead-reckoning sensors on buses measure its distance from a fixed point. Some of these systems use a wheel odometer to count the number of wheel revolutions between stops as a way to measure distance. AVL systems that use dead-reckoning sensors can be made up of all on-board equipment, while radio navigation systems require communication with off-board technology. Both types of system require maintenance and calibration that can add to the costs of managing them. Some systems use a hybrid of the two technologies, using one to aid the other, or as a backup in case of problems<ref>[http://www.trb.org/main/blurbs/158961.aspx Okunieff, P. E. (1997). “AVL Systems for Bus Transit.” Transit Cooperative Research Program.]</ref>.

'''Temporary note:''' We need to add more to the "Types of Systems" section. Currently, this section not include modern GPS-based systems. --[[User:Aaronantrim|Aaronantrim]] ([[User talk:Aaronantrim|talk]]) 01:20, 31 January 2018 (UTC)

==Benefits==
Many operators have found that AVL has helped to improve service by increasing schedule adherence and enabling agencies to easily monitor bus driver performance. AVL also helps to reduce response time to operational problems by improving communication between bus drivers and dispatchers. Dispatchers can handle communication with and monitoring of a greater volume of vehicles. Passengers also perceive their transit systems to be more modern and reliable because they can access real-time bus arrival information. AVL also aids in planning by collecting better historical data<ref name="tcrp73" />. Automatic vehicle location, combined with computer aided dispatch (CAD), has also been proven to improve safety and security on transit vehicles because many systems include a silent alarm and video monitoring capabilities. Denver's Regional Transportation District saw a 20 percent drop in assaults after adding an AVL/CAD system to its vehicles<ref>[[media:CUTR_RealTime.pdf| National Center for Transit Research at the Center for Urban Transportation Research, University of South Florida. (2005). “Enhancing the Rider Experience: The Impact of Real-Time Information On Transit Ridership.” Florida Department of Transportation.]]</ref>.

==Challenges==
The challenges associated with AVL are primarily found in managing expectations for the system within the agency, training staff, and ensuring that the interfaces for software and hardware work together throughout the agency, including with any paratransit service. Some agencies reported that after they implemented AVL, they had much greater information technology needs and had to hire staff specifically for IT<ref name="tcrp73" />.

==References==
<references/>

==Additional Reading==
[http://www.trb.org/main/blurbs/159906.aspx Parker, D. J. (2008). “AVL Systems for Bus Transit: Update.” Transit Cooperative Research Program.]
: This update to the 1997 Synthesis, also sponsored by the Federal Transit Administration, includes detailed information about the state of the practice and how AVL has been used over the past few decades. It offers more specific information on the operational benefits of AVL and actual costs of several recent contracts awarded by transit agencies. This synthesis also provides an update of the wide variety of functions that AVL can provide, such as updated headsigns at the end of trips, that previously were not available.

[[Category:Technology]]

Talk:Automatic vehicle location

2018-01-31T01:19:46Z

Aaronantrim: /* Types of Systems GPS */ new section

Article created--[[User:Amiller|Amiller]]

== Types of Systems GPS ==

We need to add more to the "Types of Systems" section. Currently, this section not include modern GPS-based systems. --[[User:Aaronantrim|Aaronantrim]] ([[User talk:Aaronantrim|talk]]) 01:19, 31 January 2018 (UTC)

Transit software

2018-01-15T22:48:56Z

Aaronantrim: added cleanup template and notes

{{cleanup|This topic feels too broad, as software can be used in nearly every part of transit. I recommend linking to pages and categories on specific types of software, and making this page be about generalized topics such as software procurement, license types, and operations and maintenance recommendations. --[[User:Aaronantrim|Aaronantrim]] ([[User talk:Aaronantrim|talk]]) 22:48, 15 January 2018 (UTC)}}

[[File:Route Match.jpg|thumbnail|right|Route Match transit software in action. Source: http://www.laketransit.org/]]
== Introduction ==
There are many vendors providing software for the transit industry for various applications. While the field includes a few large, well-known players, there are also smaller businesses providing customized solutions. One resource for discovering any vendors in the industry is to attend an [http://www.apta.com/Pages/default.aspx American Public Transportation Association] (APTA) Expo. APTA also provides a [http://apta.officialbuyersguide.net/ buyer's guide] on their website which includes paid advertising as well as basic listings of vendors in various categories including software.

''The software packages or vendors referenced in this article are provided as examples within the industry, not meant to be an exhaustive list, nor representative of any rating, ranking, or promotion of any vendor over another. Users and industry representatives are encouraged to add other active vendors to create a reference page. Promotional language or personal opinions are not acceptable.''

== Purchasing ==
As with procurement of almost anything in the public transportation business, transit software packages are typically not an off-the-shelf product. They typically require procurement using a pre-defined specification allowing for various firms to competitively bid. Bidding for software the first time for an agency can be challenging without expertise in the field. Small but growing agencies that need to move away from basic solutions towards more robust software can find themselves frustrated during software implementation if their specifications were not adequate to reach the final desired product. Even with a well-written specification, software implementation can be challenging because most packages are tailored to suit each agencies' need. Unlike consumer software such as Microsoft Office, which has been developed over decades of response with a huge user base, transit software has a much smaller audience and comparatively less development history.

Agencies are advised to consult other agencies for specifications and experience before setting out on a new software procurement.

=== Modules ===
Many vendors provide numerous software solutions which can incorporate various aspects of transit operations and planning into one procurement. Specificity about what your agency needs in a software package is crucial. Integrated software can be very helpful in providing comprehensive analysis, but adding modules to a procurement increases the price of purchase. Modules can include otherwise distinct software for dispatching, service scheduling, work (bid) scheduling, paratransit scheduling, fleet maintenance, fare management, and more.

== Software ==

=== Service Scheduling and Dispatch ===
Some of the businesses providing scheduling and dispatch (often separately for fixed-route and paratransit as modules), include:
* [http://www.optibus.co/ Optibus]
* [http://routematch.com/ RouteMatch]
* [http://www.trapezegroup.com/solutions/public-transit/scheduling-software Trapeze]
* GIRO's [http://www.giro.ca/en/ HASTUS]
* [http://initusa.com/en/products/ITCS.php?thisID=435 INIT]
* [http://www.cts-software.com/ CTS Software] for paratransit (not to be confused with [http://cts.cubic.com/en-us/solutions/enterprisesystemsfortransit.aspx Cubic Transportation Systems])
* [http://www.ecolane.com/ Ecolane North America]
* [http://www.themasterscheduler.com/ The Master Scheduler]

=== Journey Planners ===
Software to provide transit and/or multimodal trip itineraries based on a original and a destination.
* [http://bliksemlabs.com Bliksem Labs] known for the open source [[rrrr]] journey planner.
* [http://hacon.de/ Hacon] known for the HAFAS journey planner.
* [http://www.tt-solutions.nl/ HPe] known for the national rail planners.
* [http://opentripplanner.org/ OpenTripPlanner] Open source multimodal journeyplanner home of [[OpenTripPlanner]].

=== Fare Media ===
Fare media vendors can include both hardware and software providers; some firms provide the software solution that can accompany varying hardware, while others provide a fully integrated proprietary product.
* [http://routematch.com/ RouteMatch]
* [http://www.trapezegroup.com/solutions/public-transit/scheduling-software Trapeze]
* [http://cts.cubic.com/en-us/solutions/enterprisesystemsfortransit.aspx Cubic Transportation Systems]
* [http://www.mjminnovations.com/ MJM Innovations]
* [http://www.spx.com/en/genfare/ SPX Genfare (formerly GFI)]
* [https://addtransit.com/online-ticketing.php AddTransit]

=== GTFS Feed ===
Firms that create GTFS files and/or display GTFS data:
* [https://www.rome2rio.com/ Rome2Rio]
* [http://www.transittimesapp.com/ Transit Times App]
* [http://thetransitapp.com/ The Transit App]
* [https://addtransit.com/online-ticketing.php AddTransit]
* Mapping and Stop Location utilities from [http://www.themasterscheduler.com/ The Master Scheduler]
* [https://maps.google.com Google Maps]

=== Agency Management ===
Firms that offer software that manages various parts of the Agency:
* [https://www.trackittransit.com/ Trackit Transit]

== Other Resources ==
* APTA [http://apta.officialbuyersguide.net/ buyer's guide]
* "[http://publictransport.about.com/od/Transit_Technology/a/Software-Used-In-The-Public-Transit-Industry-Hastus-By-Giro.htm Software Used in the Public Transit Industry]" by Christopher MacKechnie for About.com

[[Category: Technology]]

Talk:Fixed-route scheduling

2017-10-21T18:23:14Z

Aaronantrim: Created page with "I don't think that Human Transit is relevant for this topic --~~~~"

I don't think that Human Transit is relevant for this topic --[[User:Aaronantrim|Aaronantrim]] ([[User talk:Aaronantrim|talk]]) 18:23, 21 October 2017 (UTC)

Reliability of service

2017-10-21T18:04:23Z

Aaronantrim: /* Passenger Behavior in Response to Unreliability */ demo @ NYC Transportation Camp

[[File:MTA NYC Bus Nova Bus LFS (TL40102A) 8470.jpg|thumb|600px|An out-of-service bus in New York City. Source: [https://commons.wikimedia.org/wiki/File:MTA_NYC_Bus_Nova_Bus_LFS_(TL40102A)_8470.jpg Mtattrain]]]
== Introduction ==
A common theme among articles within TransitWiki is strategies to improve reliability of transit service (see [[Off-vehicle fare payment]], [[Transit signal priority (TSP)|Transit signal priority]], and [[Internet communications]], for example). To understand how to improve reliability of service, transit planners should understand the perception of unreliability among passengers and common responses to such factors. Many people may consider transit were it not for fear of perceived or true unreliability. Reliability can be an objective, performance-based measure, but what is most important for passengers making a decision about how to travel is the subjective perception of reliability <ref>Prashker, J.N. "Direct Analysis of the Perceived Importance of Attributes of Reliability of Travel Modes in Urban Travel." Transportation 8, pp 329-346. 1979.</ref>. Users do not typically consider the reported statistical performance of a roadway when making a trip; they rely on their personal recollection of typical circumstance or from reputation and other subjective information sources. Therefore, it is in the best interest of transit planners to consider passenger perceptions of the travel experience and, to the extent possible, plan to mitigate factors of unreliability.

== Research ==
In 2013, student researchers from the University of California at Berkeley (UCB) conducted a survey of current and former users of the San Francisco area public transportation system<ref>Carrel, Andre, Anne Halvorsen and Joan Walker. Transportation Research Board: Transit 2013, Volume 2. "Passengers' Perception of and Behavioral Adaptation to Unreliability in Public Transportation." pp 153-162. 2013. http://trid.trb.org/view/1243072</ref>. Survey respondents rated the importance of reliability factors, including the time waiting at a transfer and possibility of waiting for less than 10 minutes for a bus after walking to a stop.

The researchers also gathered information on how passengers handled anticipated unreliability. [[Real-time information]] is a tool for mitigating unreliability, for example, but planners should remember that not all riders have access to real-time information. Most important in considering passenger response is that negative experiences can actually reduce transit use by individuals; regaining those lost customers could be more challenging than simply addressing problems of reliability.

=== Factors of Unreliability ===
Reliability may seem like an intuitive concept: can I depend on the transit service to be there on schedule and arrive at my destination on time? However there are many other factors that passengers may consider. The availability of seats on a bus, or [[Bicycle connections|bike rack space at certain stops]] could be one factor. The UCB report contrasts two riders: one typically travels every day at peak-hours and experiences longer, but predictable travel times. This rider might consider their trips reliable even in congestion, because it is expected. Another rider might typically take the bus during the off-peak time with shorter travel times; they may consider an experience riding during peak-period to be highly unreliable. Therefore, reliability can be affected by predictable circumstances such as congestion, and unpredictable, non-recurring circumstances.

According to passengers surveyed in San Francisco, 10 minutes is the maximum amount of time between buses and trains still considered frequent. In other words, a headway longer than 10 minutes is considered infrequent, and by association, unreliable.

Reliability aspects for work and non-work trips were measured by survey respondents in terms of importance. Reliability is more important for work trips, intuitively. Many reliability factors in choosing transit are the same for work and non-work trips:
* Making connections that are possible according to the published schedule
* Ability to walk to a stop and leave within 10 minutes
* Waiting 10 minutes or less for transfers
* Actual trip time matches published schedule
* Each trip takes the same amount of time
* Checking real-time information shows departure within 10 minutes of desired time
* Service leaves at the time on the published schedule
* Service departs at the same time daily
* Availability of seating and space on the vehicle

Below is a selection of experiences reported by riders in order of frequency of occurrence on MUNI:
# Waited at least twice as long as scheduled for vehicles on a frequent route (in other words, a scheduled bus fails to arrive)
# Real-time information showed a bus arriving that never did
# Bus unexpectedly arrived that was not on real-time info
# Service delayed by traffic
# Service delayed by unknown issue further ahead on the route
# Passenger missed bus because the real-time info was incorrect
# Delayed by other agency [MUNI] vehicles blocking bus passenger is riding
# Bus pulls away from stop as passenger is running to it
# Vehicle delayed by mechanical problem or other on-board emergency
# Waited 20 or more minutes past the scheduled time for an infrequent route (>10 minute headways)
# Bus was too crowded to board or did not stop because of crowding
# Bus turned around before reaching passenger's destination
# Waiting for long periods when transferring to an infrequent route
# Bus did not stop at passenger's requested stop
# Bus did not see passenger waiting at stop
# Bus switched routes or made a route diversion and didn't serve intended destination
# Missed last bus because it wasn't following schedule
# No available space on bus bike rack

=== Passenger Behavior in Response to Unreliability ===
Passengers facing unreliable service can either employ their own strategy for absorbing the consequence (such as leaving earlier or perhaps walking to a different route), or they can choose to reduce their use of public transit. People reducing their use of transit are more likely to be shifting travel modes than simply giving up a trip they would have made.

=== Measuring Reliability ===
There are various approaches to measuring reliability. See:
* [[On-time performance]]
* [[Headway]] reliability
* [[Network-level reliability indicators]]
* [[Accessibility]]

==References==
<references />

[[Category:Operating effectiveness]]

CityCast

2017-08-09T04:19:15Z

Aaronantrim: add Category:Scenario planning tools

[[Category:Scenario planning tools]]

{{infobox
|title=CityCast
|image=
|vendor= [https://transportfoundry.com/ Transport Foundry]
|license= Proprietary
|documentation= Not yet available
|data_in= Consumer data (e.g. Acxiom, Epsilon, Experian, Merkle), firm data (e.g. Dun & Bradstreet, InfoUSA), origin-destination data (e.g. AirSage, StreetLight Data), road network (e.g. [[Google Maps]], HERE, [[OpenStreetMap]]), [[GTFS]], [[NHTS]]
|data_out= Mode-split road network usage tables
|website= Coming soon
}}

CityCast is a web-based transportation modelling application developed by Transport Foundry. CityCast offers results similar to what an MPO might obtain from an ABM or 4-step model, but uses passively-collected data and a simplified process to make model development faster and less expensive.

==Data Inputs==
One of CityCast’s distinguishing features is the data it uses to run its model. ABMs generally rely on detailed household surveys and on-board transit surveys, which can take a lot of time and money to collect. CityCast relies on preexisting datasets that are predominantly gathered passively.
*Consumer data - data from marketing data-services firms that offer various demographic characteristics matched with home locations (e.g. Acxiom, Epsilon, Experian, Merkle)
*Firm data - data that details where employers are, how many people they employee, and what sector they operate in (e.g. Dun & Bradstreet, InfoUSA)
*Origin-destination data - aggregated cell phone location data (e.g. AirSage, StreetLight Data)
*Network data
**Road network data includes average traffic speeds, indicating congestion or other road issues, developed using cell phone and GPS data (e.g. [[Google Maps]], HERE, [[OpenStreetMap]])
**Transit network information, imported from [[General Transit Feed Specification]] datasets
**Parking information is not currently imported, but this is supported by MATSim (see notes below on the role of [[MATSim]]) using an extension<ref>http://www.ubiquitypress.com/site/books/10.5334/baw/read/#epubcfi(/6/54[Chapter_13]!/4/2/2/1:0)</ref>, so this capability could be feasibly added
*National Household Travel Survey ([[NHTS]]) - offers some more information on mode choice, travel patterns, and habits.

==Modeling Trips==
The various inputs are fused to create synthesized households and employers. The model proceeds to generate synthesized travel diaries for each person in the simulation based on the observed origin and destination data and [[NHTS]] data from similar-sized regions. The trips are then assigned to the network using [[MATSim]].

MATSim begins by assigning each trip to the fastest route, but because certain routes become congested, those routes are not necessarily the fastest for every individual once all trips are assigned. Each individual receives a score, and MATSim searches for an opportunity to improve the score for a given trip. MATSim improves scores by changing routes, changing modes, altering activity start and end times, and many other potential mutations of each person’s daily plan. It continues to optimize plans until everyone has their best possible score..

Scores for the optimization are primarily based on travel time and the time people spend doing activities. Other factors such as cost (for fuel, tolls, etc.) or preference to account for multimodal travel can also be included.

==Case Study==
CityCast has not been used for modelling by an MPO at the time of this writing as it is still under development. However, test runs were conducted in Asheville, NC. In those tests, runtime was about 4-5 hours. Runtime can vary greatly, depending predominantly on the size and complexity of the network.

==Comparison with an Activity-Based Model (ABM)==
'''See full [[Activity-Based Model]] page'''
===Transferability===
ABMs are usually custom built for MPOs. This is usually a very long and expensive project. Running the ABM also requires a significant amount of sample data collected from the region, which also takes a long time and is expensive. CityCast’s platform will be transferable between regions, because it is based on large-sample data products available nationally. Although the data would have to be acquired for each region where it is implemented, the process of synthesizing that data into a population and generating and assigning trips could be carried across regions. This may be a particular boon to smaller regions that may not have the resources to build their own ABM. On the other hand, transferability may mean a loss of sensitivity to a region’s particular transportation tendencies when assigning weights in the model, unless those trends can be derived from the existing datasets.

===Complexity===
CityCast offers a less complex and therefore less burdensome model. The simpler model allows for faster runtimes, shorter prep times, and less expertise needed to run the model. On the other hand, lower complexity excludes certain data that may be accounted for in a full ABM, which may then produce somewhat different results.

==References==
<references />

Remix

2017-06-15T00:30:55Z

Aaronantrim: /* Title VI Engine */ removed "Remix takes the complicated process of Title Vi analysis and simplifies it to a one-click automated function." Feels like overstatement/marketing.

{{infobox
|title= Remix
|image= Remix-logo.png
|vendor= Remix
|license= Proprietary
|documentation= https://help.remix.com/
|data_in= [[GTFS]], GIS shapefiles, ACS/Census, [[OpenStreetMap]], LEHD
|data_out= [[GTFS]], GIS shapefiles and database, maps, KML
|website= [https://www.remix.com/ https://www.remix.com/]
}}
[https://www.remix.com/ Remix] is web-hosted application for planning public transit systems. It automates the process of route and schedule scenario testing, letting planners draw routes onto a map and immediately see a potential schedule and fleet requirements. This can exponentially decrease the time costs of experimenting with different scenarios. As of October 2016, 36 transit agencies in California and over 150 across the world are using Remix. These agencies range in size from just a couple fleet vehicles to well over a thousand.
__TOC__
==How it Works==
[[Image:Remix1.png|right|thumb|700px|Remix makes it easy to draw a line and see schedule and cost information. Source: [https://www.remix.com/ Remix]]]
The process of route planning has typically required paper maps and work in Excel or other software packages. Remix consolidates data and analytical tools for route planning into a web interface. When an agency signs up with Remix, the company will work with them to integrate the system into the agency’s workflow.

===Street network===
The street network is imported from [[OpenStreetMap]] (OSM). This means that transit scenarios must be analyzed in the current street network. If street features are missing, they can be updated in OpenStreetMap.

===Setting up the existing transit network===
Remix employees import route info into the software using [[GTFS]] data and provide employee training. Remix identifies service spans and approximate frequencies -- average parameters describing the service abstracted from the exact imported schedule.

Variables such as operating cost per hour or mile (with costs for Saturday, peak) can be set for the agency.

===Creating scenarios / editing the network===
After onboarding is complete, the agency can start using Remix. New "scenarios" can be created. Each scenario can contain a different route network. Existing routes can be edited and new routes can be added. Span, frequency, and runtime can be adjusted for each route. Route alignments and stops are edited on a map. By default, Remix assumes that stops are placed every 0.25 miles. This default can be adjusted. Stops can also be deliberately placed on the map.

===Measures & Outputs===
Measures including the following update as the route is drawn.

====Costs & resources====
* Number of buses
* Operating cost per year
* Route miles

====Catchment====
* Population within defined buffer of stops
* Jobs within within defined of stops

Buffers are calculated according to "crow flies" methodology, not the street grid.<ref>https://help.remix.com/articles/2869-can-i-change-the-radius-of-the-buffer</ref>

===Layers===
In order to better understand the impact of a route, various information layers such as population density and poverty rate can be overlaid onto the map. This helps ensure that the system is reaching the people and places it needs to, and any changes are compliant with [[Transit and Civil Rights|Title 6 of the Civil Rights Act of 1964]]. In addition, the Remix staff can create custom layers using GIS data provided by the agency — both heat maps and point data. For example, one agency in Australia created a shapefile for projected population growth to better plan for their future service area.
[[Image:RemixJane.png|right|thumb|250px|When using Jane, the white circles show how far a rider can travel in a specific timeframe. Source: [https://www.remix.com/ Remix]]]

===Jane===
Transit systems aren’t lines on maps; they are ways for people to get around a city. Remix includes a rider surrogate isochrone tool called Jane. You can put Jane anywhere on the map, select a time of day, and see how far she could travel in 15, 30, 45, or 60 minutes. This is helpful both for intra-agency planning and public outreach.

===Title VI Engine===
Title VI of the Civil Rights Act of 1964 prevents against discrimination in the provision of government services, including public transportation.<ref>[https://www.transit.dot.gov/regulations-and-guidance/civil-rights-ada/title-vi-civil-rights-act-1964 Federal Transit Administration. "Title VI of the Civil Rights Act of 1964." 2016.]</ref> A transit agency must do a Title VI analysis of any route changes to ensure that they do not disproportionately impact minority populations. This is incredibly important, but it does make it difficult for agencies to engage in major system change.

See the Remix discussion of the [https://blog.remix.com/title-vi-in-10-minutes-or-less-with-remixs-title-vi-engine-87f55eadcc4e Title VI process using Remix].

===Output formats===
Remix can output transit network scenarios, indicators, and visualizations in these formats:
* Shapefile
* Excel (describing indicators)
* [[GTFS]] - Frequency-based, describing service parameters rather than an operationally-ready schedule
* Embeddable map for the web (with a mechanism to leave comments)
* Printable view

==Applications==
The most obvious application for Remix is in the internal planning process. Planners can use the tool to quickly model scenarios and plan anything from a simple detour on a single route to an entirely new transit system.

Remix can be used as an outreach tool. In public meetings, it can allow a presenter to give a live demonstration of possible changes to a system. The real-time cost adjustments give a clear representation of how feasible a plan is. Most people have trouble visualizing how the average citizen can interact with a transit system, so Jane has a large potential to clarify the utility of a system.

==Costs==
The cost for Remix depends on the scale of the agency. Contact Remix sales for a quote.

==Case Studies==
* '''Scenario Planning in Torrance, CA''' - With a very small team, [https://www.torranceca.gov/92.htm Torrance Transit] was unable to make significant changes to its service. Scenario planning could be a months-long process. Remix cut this down to just a few days. Using the platform, the agency was able to model the effects of consolidating service on one of its bus lines and figured out it could do so without harming the community. Once implemented, the change will save Torrance Transit over half a million dollars per year<ref>[https://blog.remix.com/taking-the-heartache-out-of-planning-in-torrance-ca-9de28a01e89f#.9qbl25ech Remix. "Taking the Heartache Out of Planning in Torrance, CA." 2016.].</ref>
* '''Collaboration in Greater Seattle, WA''' - Planning doesn’t just involve one agency; any project is going to have multiple stakeholders. When [http://metro.kingcounty.gov/ King County Metro] was working on a 25-year plan to add 2.5 million service hours to the network, it was looking at two years of consensus-building. Using Jane to clearly demonstrate the way routes interact, the planning team cut the feedback time on iterations in half and finalized the plan in just 9 months, with 2 or 3 fewer staff than would have been necessary otherwise<ref>[https://blog.remix.com/king-county-metro-builds-consensus-in-record-time-during-long-range-plan-76c14e57547d#.z7jcamego Remix. "King County Metro Builds Consensus in Record Time During Long-Range Plan." 2016.].</ref>
* '''Planning for a Transit Tax in Indianapolis, IN''' - In November 2016, residents in central Indiana voted on a quarter-cent income tax hike to let the [http://www.indympo.org/Pages/home.aspx Indianapolis Metropolitan Planning Organization] increase bus service in two counties. Remix has let the MPO clearly demonstrate where the money would go. Working entirely in-house, the organization planned 7 scenarios for 7 funding levels that they could take to public meetings. The referendum passed<ref>[https://blog.remix.com/preparing-for-a-transit-tax-increase-in-indianapolis-indiana-1001b49118aa#.lkf3cze2x Remix. "Preparing for a Transit Tax Increase in Indianapolis, Indiana." 2016.].</ref>

==References==
<references />

==Additional Reading==
[https://blog.remix.com/ Remix Blog]
: Remix maintains a blog with additional case studies, webinars, and information about product updates. The blog also has videos from Remix's annual conferences, where planners talk about the way they use the tool at their agencies.

[[Category:Network planning software]]
[[Category:GTFS-consuming applications]]
[[Category:Applications]]
[[Category: Complex data analysis]]
[[Category:Scenario planning tools]]

Remix

2017-04-25T15:39:37Z

Aaronantrim: /* How it Works */ add measures and ouputs

{{infobox
|title= Remix
|image= Remix-logo.png
|vendor= Remix
|license= Proprietary
|documentation= https://help.remix.com/
|data_in= [[GTFS]], GIS shapefiles, ACS/Census, [[OpenStreetMap]], LEHD
|data_out= [[GTFS]], GIS shapefiles and database, maps, KML
|website= [https://www.remix.com/ https://www.remix.com/]
}}
[https://www.remix.com/ Remix] is web-hosted application for planning public transit systems. It automates the process of route and schedule scenario testing, letting planners draw routes onto a map and immediately see a potential schedule and fleet requirements. This can exponentially decrease the time costs of experimenting with different scenarios. As of October 2016, 36 transit agencies in California and over 150 across the world are using Remix. These agencies range in size from just a couple fleet vehicles to well over a thousand.
__TOC__
==How it Works==
[[Image:Remix1.png|right|thumb|700px|Remix makes it easy to draw a line and see schedule and cost information. Source: [https://www.remix.com/ Remix]]]
The process of route planning has typically required paper maps and work in Excel or other software packages. Remix consolidates data and analytical tools for route planning into a web interface. When an agency signs up with Remix, the company will work with them to integrate the system into the agency’s workflow.

===Street network===
The street network is imported from [[OpenStreetMap]] (OSM). This means that transit scenarios must be analyzed in the current street network. If street features are missing, they can be updated in OpenStreetMap.

===Setting up the existing transit network===
Remix employees import route info into the software using [[GTFS]] data and provide employee training. Remix identifies service spans and approximate frequencies -- average parameters describing the service abstracted from the exact imported schedule.

Variables such as operating cost per hour or mile (with costs for Saturday, peak) can be set for the agency.

===Creating scenarios / editing the network===
After onboarding is complete, the agency can start using Remix. New "scenarios" can be created. Each scenario can contain a different route network. Existing routes can be edited and new routes can be added. Span, frequency, and runtime can be adjusted for each route. Route alignments and stops are edited on a map. By default, Remix assumes that stops are placed every 0.25 miles. This default can be adjusted. Stops can also be deliberately placed on the map.

===Measures & Outputs===
Measures including the following update as the route is drawn.

====Costs & resources====
* Number of buses
* Operating cost per year
* Route miles

====Catchment====
* Population within defined buffer of stops
* Jobs within within defined of stops

Buffers are calculated according to "crow flies" methodology, not the street grid.<ref>https://help.remix.com/articles/2869-can-i-change-the-radius-of-the-buffer</ref>

===Layers===
In order to better understand the impact of a route, various information layers such as population density and poverty rate can be overlaid onto the map. This helps ensure that the system is reaching the people and places it needs to, and any changes are compliant with [[Transit and Civil Rights|Title 6 of the Civil Rights Act of 1964]]. In addition, the Remix staff can create custom layers using GIS data provided by the agency — both heat maps and point data. For example, one agency in Australia created a shapefile for projected population growth to better plan for their future service area.
[[Image:RemixJane.png|right|thumb|250px|When using Jane, the white circles show how far a rider can travel in a specific timeframe. Source: [https://www.remix.com/ Remix]]]

===Jane===
Transit systems aren’t lines on maps; they are ways for people to get around a city. Remix includes a rider surrogate isochrone tool called Jane. You can put Jane anywhere on the map, select a time of day, and see how far she could travel in 15, 30, 45, or 60 minutes. This is helpful both for intra-agency planning and public outreach.

===Title VI Engine===
Title VI of the Civil Rights Act of 1964 prevents against discrimination in the provision of government services, including public transportation<ref>[https://www.transit.dot.gov/regulations-and-guidance/civil-rights-ada/title-vi-civil-rights-act-1964 Federal Transit Administration. "Title VI of the Civil Rights Act of 1964." 2016.]</ref>. A transit agency must do a Title VI analysis of any route changes to ensure that they do not disproportionately impact minority populations. This is incredibly important, but it does make it difficult for agencies to engage in major system change. Remix takes the complicated process of Title Vi analysis and simplifies it to a one-click automated function.

See the Remix discussion of the [https://blog.remix.com/title-vi-in-10-minutes-or-less-with-remixs-title-vi-engine-87f55eadcc4e Title VI process using Remix].

===Output formats===
Remix can output transit network scenarios, indicators, and visualizations in these formats:
* Shapefile
* Excel (describing indicators)
* [[GTFS]] - Frequency-based, describing service parameters rather than an operationally-ready schedule
* Embeddable map for the web (with a mechanism to leave comments)
* Printable view

==Applications==
The most obvious application for Remix is in the internal planning process. Planners can use the tool to quickly model scenarios and plan anything from a simple detour on a single route to an entirely new transit system.

Remix can be used as an outreach tool. In public meetings, it can allow a presenter to give a live demonstration of possible changes to a system. The real-time cost adjustments give a clear representation of how feasible a plan is. Most people have trouble visualizing how the average citizen can interact with a transit system, so Jane has a large potential to clarify the utility of a system.

==Costs==
The cost for Remix depends on the scale of the agency. Contact Remix sales for a quote.

==Case Studies==
* '''Scenario Planning in Torrance, CA''' - With a very small team, [https://www.torranceca.gov/92.htm Torrance Transit] was unable to make significant changes to its service. Scenario planning could be a months-long process. Remix cut this down to just a few days. Using the platform, the agency was able to model the effects of consolidating service on one of its bus lines and figured out it could do so without harming the community. Once implemented, the change will save Torrance Transit over half a million dollars per year<ref>[https://blog.remix.com/taking-the-heartache-out-of-planning-in-torrance-ca-9de28a01e89f#.9qbl25ech Remix. "Taking the Heartache Out of Planning in Torrance, CA." 2016.]</ref>.
* '''Collaboration in Greater Seattle, WA''' - Planning doesn’t just involve one agency; any project is going to have multiple stakeholders. When [http://metro.kingcounty.gov/ King County Metro] was working on a 25-year plan to add 2.5 million service hours to the network, it was looking at two years of consensus-building. Using Jane to clearly demonstrate the way routes interact, the planning team cut the feedback time on iterations in half and finalized the plan in just 9 months, with 2 or 3 fewer staff than would have been necessary otherwise<ref>[https://blog.remix.com/king-county-metro-builds-consensus-in-record-time-during-long-range-plan-76c14e57547d#.z7jcamego Remix. "King County Metro Builds Consensus in Record Time During Long-Range Plan." 2016.]</ref>.
* '''Planning for a Transit Tax in Indianapolis, IN''' - In November 2016, residents in central Indiana voted on a quarter-cent income tax hike to let the [http://www.indympo.org/Pages/home.aspx Indianapolis Metropolitan Planning Organization] increase bus service in two counties. Remix has let the MPO clearly demonstrate where the money would go. Working entirely in-house, the organization planned 7 scenarios for 7 funding levels that they could take to public meetings. The referendum passed<ref>[https://blog.remix.com/preparing-for-a-transit-tax-increase-in-indianapolis-indiana-1001b49118aa#.lkf3cze2x Remix. "Preparing for a Transit Tax Increase in Indianapolis, Indiana." 2016.]</ref>.

==References==
<references />

==Additional Reading==
[https://blog.remix.com/ Remix Blog]
: Remix maintains a blog with additional case studies, webinars, and information about product updates. The blog also has videos from Remix's annual conferences, where planners talk about the way they use the tool at their agencies.

[[Category:Network planning software]]
[[Category:GTFS-consuming applications]]
[[Category:Applications]]
[[Category: Complex data analysis]]
[[Category:Scenario planning tools]]

File:Decay function.png

2017-04-24T18:31:21Z

Aaronantrim: Added source

Accessibility decay function

Source: "Operationalizing Accessibility: Tools and Practices." State Smart Transportation Initiative. 30 March 2017. http://www.ssti.us/Events/operationalizing-accessibility-part-1-tools-and-practices/

Accessibility

2017-04-24T14:25:24Z

Aaronantrim: added note about accessibility for people with disabilities

"Accessibility" may also refer to [[accessible design]] of transit vehicles and stations to provide mobility for all, including people with disabilities.

In this article, accessibility (or just access) refers to the ability to reach goods, services, activities, and destinations, which together are called opportunities.<ref>"Accessibility for Transportation Planning: Measuring People’s Ability to Reach Desired Goods and Activities." 27 February 2017. Todd Litman. Victoria Transport Policy Institute. http://www.vtpi.org/access.pdf</ref>

Accessibility nearly always is measured by how long it takes to reach destinations, or rather how many destinations can be reached within a certain amount of time. However, different tools and evaluations vary in the way they measure first and last mile, the types of destinations they include, population segmentation analysis, and the mechanisms used for counting destinations.

==Accessibility vs. Mobility==
Transit systems have been increasingly focused on accessibility when evaluating their systems and new projects. Although accessibility has always been a chief goal of transit, past measures have tended to focus on mobility, looking at the number of people who can access the transit system, system capacity, and line speeds. While improvements in service strengthen the transit system, these measures do not evaluate whether people have access to important destinations. Fast transit lines reaching many may nevertheless fail to connect people to job centers, grocery stores, or schools. Far reaching transit systems may force multiple transfers to reach a destination, such that the trip becomes unreasonable long. Accessibility directly addresses these questions by measuring people's ability to reach desired destinations.

==Decay vs. Cut-offs==
One major distinction in measuring accessibility is how parameters are set for determining if a destination is accessible. One method is to create a time cut-off. For example, one can ask, how many jobs can be reached in 30 minutes using transit from a given location? Or, how many household/job combinations are there within 30 minutes of each other along a transit line or in a transit system? The alternative is to use a decay function. A decay function weights destinations based on how far they are, so that farther locations are given less weight than closer ones.

===Time cut-off===
Time cut-offs are useful because they are slightly easier to calculate. Some tool is needed to figure out how far one can go on a system in the specified amount of time, and then all points corresponding to a destination within that area are counted up. They also tend to be easier to communicate to the public or to decision makers. 10,000 jobs accessible in 30 minutes from a given area, or a new line or faster service increasing the number of jobs available in 30 minutes of travel is a relatively easy idea to understand.
Time cut-offs suffer a few disadvantages however. A large employment center just outside of the time range is completely disregarded. So if there are 1,000 jobs available in 30 minutes but 2,000 jobs available in 31 minutes, the analysis will ignore the jobs just outside the cut-off and yield misleading results. Cut-offs also fail to discriminate between where destinations are located within a region. For example, this type of analysis will provide the same results if all of the jobs are five minutes away or thirty minutes way, although being five minutes away clearly provides better access. Some of these disadvantages can be overcome by conducting multiple analyses with different cut-offs, such that instead of having one number for a certain distance, the change as one gets farther away can be observed.

===Decay===
[[File:Decay function.png|thumb|A decay function showing the change in weighted values for different modes and destination as travel time increases<ref>"Operationalizing Accessibility: Tools and Practices." State Smart Transportation Initiative. 30 March 2017. http://www.ssti.us/Events/operationalizing-accessibility-part-1-tools-and-practices/</ref>]]
Decay functions offer a more fine-tuned assessment of accessibility by weighting destinations based on how far away they are. A job that is five minutes away contributes more to accessibility than one that is thirty minutes away, and a job that is thirty minutes away contributes about the same as one that is thirty-one minutes away. Decay functions usually have a cut-off, somewhere around the 60 to 90 minute mark, where destinations are considered so inaccessible that they can no longer greatly contribute.
Using decay is challenging for a number of reasons. A meaningful and reliable decay function has to be developed. The computation effort of calculating the exact distance to each location and weighting the location is large and complicated. Finally, because locations are weighted, the final output is unit-less; it cannot be explained as number of jobs within a 30 minute travel time. This may allow for internal comparisons but may be difficult to convey conceptually at public presentations. One solution to improve presentation is developing a clear scale and creating references as explanations for various points on the scale. (ex. a 1-100, where 80-100 is excellent accessibility, etc.)

==First and Last Mile==
First and last mile is a common expression referring to how people get to a transit station, and how they get from transit to their destination. These considerations recognize that the time it takes to travel by transit is broken up into four pieces: Travel to the station, waiting at the station, travel on transit, and travel to destination. More complicated trips may include other elements such as waiting for a transfer, or traveling between stations to transfer. Some tools only look at travel time between stations, with the possible inclusion of wait time (usually calculated as half of headway). In that case they use circular buffers to determine which populations and destinations are accessible from the stations. Other tools incorporate travel time to and from the stations by using circular buffers and averages or by calculating travel time on the street network.

===Buffers===
For a quick and relatively simple analysis of who has access to the transit stop, circular buffers can be drawn around them, capturing households and destinations. A standard size for buffers is 1/4 mile radius for bus stops and 1/2 mile radius for [[LRT]] or [[BRT]]. Drawing buffers offers quick analysis, but has some disadvantages. People or destinations just outside the buffer may be unnecessarily excluded. Buffers measure distance on a map, so barriers such as highways or railroad tracks are ignored, meaning some people are included that have no access to the stations, or for whom the station is much farther away than the 1/4 or 1/2 mile measured.
When buffers are used, travel time can be estimated as an average. For example, one could say that people inside of a 1/2 mile buffer around a light rail station take 7 minutes on average to get to the station. This helps establish realistic accessibility expectations, but glosses over the fact that some people in the buffer only have a 1 minute walk to the station, while others might have a 12 minute walk, which drastically changes their total travel time.

===Using the street network===
Some tools use the street network to estimate travel time between origin or destination and the transit station. This calculation can much more accurately determine the first mile and last mile travel time and therefore yield a more accurate total travel time. It avoids the pitfalls of cutting off people or destinations just outside of a buffer and effectively recognizes relative distances from stations. However, it requires an individual calculation from each origin to each destination, rather than reserving calculations to between stations, hence a much more computationally intensive process. It also requires an accurate street network that includes pedestrian paths.

==Destinations==
Accessibility analysis measures how long it takes to arrive at certain types of destinations. The most common destination that is measured is jobs. Access to jobs is crucial for employers and employees to maintain a robust economy, and peak commute hours tend to be the most congested times of the week, so increasing accessibility to jobs via transit is particularly important. Data sources for jobs are also easy to acquire through the publicly available LODES and LEHD data.
Other destinations are also often sought out. These can include restaurants, grocery stores, schools, health facilities, parks, etc. Accessibility to these types of amenities has a serious impact on quality of life, and is therefore important in evaluating transit effects on a community. Also, since only 20% of trips are for a home-to-work commute<ref>"Commuting in America 2013: The National Report on Commuting Patterns and Trends." American Association of State Highway and Transportation Officials. http://traveltrends.transportation.org/Pages/default.aspx</ref>, factoring in other trip destinations has a big impact on how much people will use a transit system. There are no government generated sources for these databases. Some tools use open source options, such as [[OpenStreetMap]], while other acquire proprietary databases. A challenge when working with other destinations is how to group them or weight them. Analyzing accessibility to grocery stores might be relatively easy (although even in this example, classifying grocery stores might be difficult). However, analyzing accessibility to amenities broadly raises questions of which amenities count and which amenities are most important.

==Population Analysis==
In order to address equity issues and to comply with [[Title VI]], accessibility measurements seek to display how accessibility will change for different segments of the population. This can include relative effects on low-income households, different racial minorities, people with disabilities, households without cars or with fewer cars than workers, among others. Demographic data can be fairly easily acquired in the US through the Census and/or ACS. A simple visual analysis layers a demographic map and an accessibility map. A more complicated analysis would actually calculate the changes in accessibility to census blocks or block groups of varying demographic characteristics and measure relative effects.

==Example Tools==
Some tools that measure accessibility are discussed below

*[[Sugar]] is a tool offered by [[Citilabs]]. It measures access using decay functions, creating an access score. Sugar incorporates first and last mile travel on a the pedestrian street network in measuring its total travel time. It offers accessibility measures to many types of destinations using destination data from navigation company HERE and allows for custom weighting of destination data. Sugar allows for easy layering of demographic data, but does not include demographic based calculations.
[[File:Analysis-spectrogram.png|thumb|Accessibility spectrogram from Conveyal Analyst. Shows the increase in accessible opportunities (in this case jobs) as travel time increases. The wider portions reveal system uncertainty or unreliability caused by low service frequency.<ref>Conveyal analysis-ui documentation. Accessed 20 April 2017. http://analysis-ui.readthedocs.io/en/latest/analysis/#spectrogram</ref> ]]
*[[Transport Analyst]] offered by [[Conveyal]] is an open source tool. It offers accessibility information for various cut-off points and creates spectrograms that show the change in accessibility as travel time increases, but does not create a related score. Analyst offers accessibility measures for a number of different destination types, acquired from [[OpenStreetMap]], and allows for demographic overlays.
*[[TBEST]] is a tool mostly used for estimating transit boardings that was developed by [http://www.fdot.gov/ FDOT]. TBEST includes an accessibility analysis function, but it is limited in destination options, and only calculates stop to stop travel times.

==Further Reading==
*"The Why and How of Measuring Access to Opportunity: A Guide to Performance Management." Governors’ Institute on Community Design. January 2017. http://www.govinstitute.org/wp-content/uploads/2017/01/how-and-why-of-measuring-access-to-opportunity.pdf

==References==
<references />

LRT

2017-04-21T19:27:59Z

Aaronantrim: redirect to Light rail

#REDIRECT [[Light rail]]

Accessibility

2017-04-21T19:25:51Z

Aaronantrim: /* Decay */ small correction

Accessibility (or just access) refers to the ease of reaching goods, services, activities, and destinations, which together are called opportunities.<ref>"Accessibility for Transportation Planning: Measuring People’s Ability to Reach Desired Goods and Activities." 27 February 2017. Todd Litman. Victoria Transport Policy Institute. http://www.vtpi.org/access.pdf</ref>

Accessibility almost always measures how long it takes to reach a destinations, or rather how many destinations can be reached within a certain amount of time. However, different tools and evaluations vary in the way they measure first and last mile, the types of destinations they include, population segmentation analysis, and the mechanisms used for counting destinations.

==Accessibility vs. Mobility==
Transit systems have been increasingly focused on accessibility when evaluating their systems and new projects. Although accessibility has always been a chief goal of transit, past measures have tended to focus on mobility, looking at number of people who can access the transit system, system capacity, and line speeds. While improvements in service strengthen the transit system, these measures do not evaluate whether people have access to important destinations. Fast transit lines reaching many may nevertheless fail to connect people to job centers, grocery stores, or schools. Far reaching transit systems may force multiple transfers to reach a destination, such that the trip becomes unreasonable long. Accessibility directly addresses these questions by measuring people's ability to reach desired destinations.

==Decay vs. Cut-offs==
One major distinction in measuring accessibility is how parameters are set for determining if a destination is accessible. One method is to create a time cut-off. For example, one can ask how many jobs can be reached in 30 minutes using transit from a given location? Or, how many household/job combinations are there within 30 minutes of each other along a transit line or in a transit system? The alternative is to use a decay function. A decay function weights destinations based on how far they are, so that a farther locations are given less weight than closer ones.

===Time cut-off===
Time cut-offs are useful because they are slightly easier to calculate. Some tool is needed to figure out how far one can go on a system in the specified amount of time, and then all points corresponding to a destination within that area are counted up. They also tend to be easier to communicate to the public or to decision makers. The idea that there are 10,000 jobs accessible in 30 minutes from a given area, or that a new line or faster service will increase the number of jobs available in 30 minutes of travel is easy to understand.
Time cut-offs suffer a few disadvantages however. A large employment center just outside of the time range is completely disregarded. So if there are 1,000 jobs available in 30 minutes but 2,000 jobs available in 31 minutes, the analysis will ignore the jobs just outside the cut-off. Cut-offs also don't discriminate between where destinations are located within a region. For example, this type of analysis will provide the same results is all of the jobs are five minutes away or thirty minutes way, although being five minutes away clearly provides better access. Some of these disadvantages can be over come by conducting multiple analyses with different cut-offs, such that instead of having one number for a certain distance, the change as one gets farther away can be observed.

===Decay===
[[File:Decay function.png|thumb|A decay function showing the change in weighted values for different modes and destination as travel time increases<ref>"Operationalizing Accessibility: Tools and Practices." State Smart Transportation Initiative. 30 March 2017. http://www.ssti.us/Events/operationalizing-accessibility-part-1-tools-and-practices/</ref>]]
Decay functions offer a more fine-tuned assessment of accessibility by weighting destinations based on how far away they are. A job that is five minutes away contributes more to accessibility than one that is thirty minutes away, and a job that is thirty minutes away contributes about the same as one that is thirty-one minutes away. Decay functions usually have a cut-off, somewhere around the 60 or 90 minute mark, where destinations are considered so inaccessible that they can no longer greatly contribute.
Using decay is challenging for a number of reasons. A meaningful and reliable decay function has to be developed. The computation effort of calculating the exact distance to each location and weighting the location is large and complicated. Finally, because location are weighted, the final output is unit-less; it cannot be explained as number of jobs within 30 travel time. This may allow for internal comparisons but may be difficult to understand conceptually for public presentations. One solution to improve presentation is developing a clear scale and creating references are explanations for various points on the scale. (ex. a 1-100, where 80-100 is excellent accessibility, etc.)

==First and Last Mile==
First and last mile is a common expression referring to how people get to a transit station, and how they get from transit to their destination. These considerations recognize that the time it takes to travel by transit is broken up into four pieces: Travel to the station, waiting at the station, travel on transit, and travel to destination. More complicated trips may include other elements such as waiting for a transfer, or traveling between stations to transfer. Some tools only look at travel time between stations, with the possible inclusion of wait time (usually calculated as half of headway). In that case they use circular buffers to determine which populations and destinations are accessible from the stations. Other tools incorporate travel time to and from the stations by using circular buffers and averages or by calculating travel time on the street network.

===Buffers===
For a quick and relatively simple analysis of who has access to the transit stop, circular buffers can be drawn around them, capturing households and destinations. A standard size for buffers is 1/4 mile radius for bus stops and 1/2 mile radius for [[LRT]] or [[BRT]]. Drawing buffers offers quick analysis, but has some disadvantages. People or destinations just outside the buffer may be unnecessarily excluded. Buffers measure distance on a map, so barriers such as highways or railroad tracks that are ignored, meaning some people are included that have no access to the stations, or for whom the station is much farther away than the 1/4 or 1/2 mile measured.
When buffers are used, travel time can be estimated as an average. For example, one could say that people inside of a half mile buffer around a light rail station take 7 minutes on average to get to the station. This helps establish realistic accessibility expectations, but glosses over the fact that some people in the buffer only have a 1 minute walk to the station, while others might have a 12 minute walk, which drastically changes their total travel time.

===Using the street network===
Some tools use the street network to estimate travel time between origin or destination and the transit station. This calculation can much more accurately determine the first mile and last mile travel time and therefore yield a more accurate total travel time. It avoids the pitfalls of cutting off people or destinations just outside of a buffer and effectively recognizes relative distances from stations. However, it requires an individual calculation from each origin to each destination, rather than reserving calculations to between stations, hence a much more computationally intensive process. It also requires an accurate street network that includes pedestrian paths.

==Destinations==
Accessibility analysis measures how long it takes to arrive at certain types of destinations. The most common destination that is measured is jobs. Access to jobs is crucial for employers and employees to maintain a robust economy, and peak commute hours tend to be the most congested times of the week, so increasing accessibility to jobs via transit is particularly important. Data sources for jobs are also easy to acquire through the publicly available LODES and LEHD data.
Other destinations are also often sought out. These can include restaurants, grocery stores, schools, health facilities, parks, etc. Accessibility to these types of amenities has a serious impact on quality of life, and is therefore important in evaluating transit effects on a community. Also, since only 20% of trips are for a home-to-work commute<ref>"Commuting in America 2013: The National Report on Commuting Patterns and Trends." American Association of State Highway and Transportation Officials. http://traveltrends.transportation.org/Pages/default.aspx</ref>, factoring in other trip destinations has a big impact on how much people will use a transit system. There are no government generated sources for these databases. Some tools use open source options, such as [[OpenstreetMap]], while other acquire proprietary databases. A challenge when working with other destinations is how to group them or weight them. Analyzing accessibility to grocery stores might be relatively easy (although even in this example, classifying grocery stores might be difficult). However, analyzing accessibility to amenities broadly raises questions of which amenities count and which amenities are most important.

==Population Analysis==
In order to address equity issues and to comply with [[Title VI]], accessibility measurements seek to display how accessibility will change for different segments of the population. This can include relative effects on low-income households, different racial minorities, people with disabilities, households without cars or with fewer cars than workers, among others. Demographic data can be fairly easily acquired in the US through the Census and/or ACS. A simple visual analysis layers a demographic map and an accessibility map. A more complicated analysis would actually calculate the changes in accessibility to census blocks or block groups of varying demographic characteristics and measure relative effects.

==Example Tools==
Some tools that measure accessibility are discussed below

*[[Sugar]] is a tool offered by [[Citilabs]]. It measures access using decay functions, creating an access score. Sugar incorporates first and last mile travel on a the pedestrian street network in measuring its total travel time. It offers accessibility measures to many types of destinations using destination data from navigation company HERE and allows for custom weighting of destination data. Sugar allows for easy layering of demographic data, but does not include demographic based calculations.
*
[[File:Analysis-spectrogram.png|thumb|Accessibility spectrogram from Conveyal Analyst. Shows the increase in accessible opportunities (in this case jobs) as travel time increases. The wider portions reveal system uncertainty or unreliability caused by low service frequency.<ref>Conveyal analysis-ui documentation. Accessed 20 April 2017. http://analysis-ui.readthedocs.io/en/latest/analysis/#spectrogram</ref> ]]
[[Transport Analyst]] offered by [[Conveyal]] is an open source tool. It offers accessibility information for various cut-off points and creates spectrograms that show the change in accessibility as travel time increases, but does not create a related score. Analyst offers accessibility measures for a number of different destination types, acquired from [[OpenStreetMap]], and allows for demographic overlays.
*[[TBEST]] is a tool mostly used for estimating transit boardings that was developed by [http://www.fdot.gov/ FDOT]. TBEST includes an accessibility analysis function, but it is limited in destination options, and only calculates stop to stop travel times.

==Further Reading==
*"The Why and How of Measuring Access to Opportunity: A Guide to Performance Management." Governors’ Institute on Community Design. January 2017. http://www.govinstitute.org/wp-content/uploads/2017/01/how-and-why-of-measuring-access-to-opportunity.pdf

==References==
<references />

Sugar

2017-04-03T21:42:36Z

Aaronantrim: Many updates - outputs, cost, access and SNE

{{infobox
|title=Sugar
|image= Sugar-logo.png
|vendor= [[Citilabs]]
|license= Proprietary [http://www.citilabs.com/end-user-license-agreement/ http://www.citilabs.com/ end-user-license-agreement/]
|documentation= None found online
|website= [http://www.citilabs.com/software/sugar/ http://www.citilabs.com/ software/sugar/]
}}

=Overview=
Sugar offers tools for managing, analyzing, and visualizing transportation networks and accessibility in any community. Sugar has two main components:
* Sugar Access
* Sugar Network Editor

=Sugar Network Editor=
'''Sugar Network Editor (SNE)''' is an add-on to ESRI's ArcGIS desktop. It allows one to create and maintain transportation networks directly in ArcGIS. These networks are directly compatible with ESRI’s Network Analyst extension and other ESRI extensions, and transportation software products such as Citilabs Cube and Trafficware® Synchro.

==Transit data==
'''Transit data''' can be imported from [[GTFS]]:
* Route alignments
* Stop locations
* Schedules

The SNE allows editing all of the above features.

==Street network==
'''Street network''' information can also be edited in the SNE. The default roadway map comes from [https://here.com/en/products-services/data/here-map-data HERE].

==Points of interest (POI) / Destinations==
'''POI''' data is also imported from the [https://here.com/en/products-services/data/here-map-data HERE] dataset (this is the same dataset that is also used for mobile navigation systems). This is used for calculating access to destinations and categories of destinations.

=Sugar Access=
'''Sugar Access''' is used to score and understand accessibility to employment opportunities, various errands, public services, and other destinations. It provides multi-modal accessibility calculations. Because street and transit data is incorporated in the analysis, accessibility analysis takes into account physical barriers in the street network. The software comes pre-loaded with data for communities.

Sugar Access can provide the following indicators:

* Travel times from single origin to many destinations
* Destination summation for a particular location (number of destinations of a particular type), e.g. parks by walking, jobs by transit
* Comprehensive accessibility analysis: For an entire population, what % of {jobs, etc.} can be accessed in 10 min, 20 min, 30min, etc.
* "Access Score": A weighted score that represents the accessibility implications of a transit scenario (see further discussion below).

==Access Score==
The software can generate an "Accessibility Score" that is calibrated according to travelers' willingness to to make commute trips of various time lengths according to mode. The below graph shows one comparison of travelers' willingness to accept travel times by mode.<ref>See slide 6, Eric Sundquist, TCS 2016, https://www.slideshare.net/otrec/eric-sundquist-tcs-2016/1</ref>

[[File:Calculating accessibility.png|100px|frame|none]]

Factoring travelers' willingness to travel to weight the usefulness or realistic availability of jobs helps to provide a more complete picture of accessibility and avoids the "cliff effect" where a job that is 31 minutes away is not factored into an indicator of "Jobs within 30min".

==Data outputs==
All analysis outputs can be exported as an ArcGIS Geodatabase (.GDP) or Microsoft Access database file (.MDB). All outputs used for rendering maps is available in ArcGIS or in exported files.

=Requirements=
Sugar requires [http://arcgis.com ArcGIS].

=Cost / Licensing=
This software is generally licensed on an annual basis, but shorter subscriptions are available with a premium fee.

=Case study=
Sugar Access was used in [http://smartscale.org/ Virginia DOT's Smart Scale project].

=References=
<references />

[[Category:GTFS-consuming applications]]
[[Category:Network planning software]]
[[Category:Scenario planning tools]]

File:Calculating accessibility.png

2017-04-03T21:09:21Z

Aaronantrim: Presentation: "Measuring what matters: access to destinations" by Eric Sundquist Transportation & Communities Summit Sept. 9, 2016 See slide 6, Eric Sundquist, TCS 2016, https://www.slideshare.net/otrec/eric-sundquist-tcs-2016/1

Presentation: "Measuring what matters: access to destinations"
by Eric Sundquist
Transportation & Communities Summit Sept. 9, 2016

See slide 6, Eric Sundquist, TCS 2016, https://www.slideshare.net/otrec/eric-sundquist-tcs-2016/1

Sugar

2017-03-30T22:31:01Z

Aaronantrim: Checking in some updates, in-progress

Remix

2017-03-30T22:13:49Z

Aaronantrim: /* How it Works */ add ===Street network=== (openstreetmap)

{{infobox
|title= Remix
|image= Remix-logo.png
|vendor= Remix
|license= Proprietary
|documentation= None found online
|data_in= [[GTFS]], GIS shapefiles
|website= [https://www.remix.com/ https://www.remix.com/]
}}
[https://www.remix.com/ Remix] is web-hosted application for planning public transit systems. It automates the process of route and schedule scenario testing, letting planners draw routes onto a map and immediately see a potential schedule and fleet requirements. This can exponentially decrease the time costs of experimenting with different scenarios. As of October 2016, 36 transit agencies in California and over 150 across the world are using Remix. These agencies range in size from just a couple fleet vehicles to well over a thousand.
__TOC__
==How it Works==
[[Image:Remix1.png|right|thumb|700px|Remix makes it easy to draw a line and see schedule and cost information. Source: [https://www.remix.com/ Remix]]]
The process of route planning has typically required paper maps and work in Excel or other software packages. Remix consolidates data and analytical tools for route planning into a web interface. When an agency signs up with Remix, the company will work with them to integrate the system into the agency’s workflow.

===Street network===
The street network is imported from [[OpenStreetMap]] (OSM). This means that transit scenarios must be analyzed in the current street network. If street features are missing, they can be updated in OpenStreetMap.

===Setting up the existing transit network===
Remix employees import route info into the software using [[GTFS]] data and provide employee training. Remix identifies service spans and approximate frequencies -- average parameters describing the service abstracted from the exact imported schedule.

Variables such as operating cost per hour or mile (with costs for Saturday, peak) can be set for the agency.

===Creating scenarios / editing the network===
After onboarding is complete, the agency can start using Remix. New "scenarios" can be created. Each scenario can contain a different route network. Existing routes can be edited and new routes can be added. Span, frequency, and runtime can be adjusted for each route. Route alignments and stops are edited on a map. By default, Remix assumes that stops are placed every 0.25 miles. This default can be adjusted. Stops can also be deliberately placed on the map.

Measures including the following update as the route is drawn:
* Number of buses
* Operating cost per year
* Route miles
* Population within 0.25 mile of stops
* Jobs within 0.25 mile of stops

===Layers===
In order to better understand the impact of a route, various information layers such as population density and poverty rate can be overlaid onto the map. This helps ensure that the system is reaching the people and places it needs to, and any changes are compliant with [[Transit and Civil Rights|Title 6 of the Civil Rights Act of 1964]]. In addition, the Remix staff can create custom layers using GIS data provided by the agency — both heat maps and point data. For example, one agency in Australia created a shapefile for projected population growth to better plan for their future service area.
[[Image:RemixJane.png|right|thumb|250px|When using Jane, the white circles show how far a rider can travel in a specific timeframe. Source: [https://www.remix.com/ Remix]]]

===Jane===
Transit systems aren’t lines on maps; they are ways for people to get around a city. Remix includes a rider surrogate isochrone tool called Jane. You can put Jane anywhere on the map, select a time of day, and see how far she could travel in 15, 30, 45, or 60 minutes. This is helpful both for intra-agency planning and public outreach.

===Title VI Engine===
Title VI of the Civil Rights Act of 1964 prevents against discrimination in the provision of government services, including public transportation<ref>[https://www.transit.dot.gov/regulations-and-guidance/civil-rights-ada/title-vi-civil-rights-act-1964 Federal Transit Administration. "Title VI of the Civil Rights Act of 1964." 2016.]</ref>. A transit agency must do a Title VI analysis of any route changes to ensure that they do not disproportionately impact minority populations. This is incredibly important, but it does make it difficult for agencies to engage in major system change. Remix takes the complicated process of Title Vi analysis and simplifies it to a one-click automated function.

See the Remix discussion of the [https://blog.remix.com/title-vi-in-10-minutes-or-less-with-remixs-title-vi-engine-87f55eadcc4e Title VI process using Remix].

===Output formats===
Remix can output transit network scenarios, indicators, and visualizations in these formats:
* Shapefile
* Excel (describing indicators)
* [[GTFS]] - Frequency-based, describing service parameters rather than an operationally-ready schedule
* Embeddable map for the web (with a mechanism to leave comments)
* Printable view

==Applications==
The most obvious application for Remix is in the internal planning process. Planners can use the tool to quickly model scenarios and plan anything from a simple detour on a single route to an entirely new transit system.

Remix can be used as an outreach tool. In public meetings, it can allow a presenter to give a live demonstration of possible changes to a system. The real-time cost adjustments give a clear representation of how feasible a plan is. Most people have trouble visualizing how the average citizen can interact with a transit system, so Jane has a large potential to clarify the utility of a system.

==Costs==
The cost for Remix depends on the scale of the agency. Contact Remix sales for a quote.

==Case Studies==
* '''Scenario Planning in Torrance, CA''' - With a very small team, [https://www.torranceca.gov/92.htm Torrance Transit] was unable to make significant changes to its service. Scenario planning could be a months-long process. Remix cut this down to just a few days. Using the platform, the agency was able to model the effects of consolidating service on one of its bus lines and figured out it could do so without harming the community. Once implemented, the change will save Torrance Transit over half a million dollars per year<ref>[https://blog.remix.com/taking-the-heartache-out-of-planning-in-torrance-ca-9de28a01e89f#.9qbl25ech Remix. "Taking the Heartache Out of Planning in Torrance, CA." 2016.]</ref>.
* '''Collaboration in Greater Seattle, WA''' - Planning doesn’t just involve one agency; any project is going to have multiple stakeholders. When [http://metro.kingcounty.gov/ King County Metro] was working on a 25-year plan to add 2.5 million service hours to the network, it was looking at two years of consensus-building. Using Jane to clearly demonstrate the way routes interact, the planning team cut the feedback time on iterations in half and finalized the plan in just 9 months, with 2 or 3 fewer staff than would have been necessary otherwise<ref>[https://blog.remix.com/king-county-metro-builds-consensus-in-record-time-during-long-range-plan-76c14e57547d#.z7jcamego Remix. "King County Metro Builds Consensus in Record Time During Long-Range Plan." 2016.]</ref>.
* '''Planning for a Transit Tax in Indianapolis, IN''' - In November 2016, residents in central Indiana voted on a quarter-cent income tax hike to let the [http://www.indympo.org/Pages/home.aspx Indianapolis Metropolitan Planning Organization] increase bus service in two counties. Remix has let the MPO clearly demonstrate where the money would go. Working entirely in-house, the organization planned 7 scenarios for 7 funding levels that they could take to public meetings. The referendum passed<ref>[https://blog.remix.com/preparing-for-a-transit-tax-increase-in-indianapolis-indiana-1001b49118aa#.lkf3cze2x Remix. "Preparing for a Transit Tax Increase in Indianapolis, Indiana." 2016.]</ref>.

==References==
<references />

==Additional Reading==
[https://blog.remix.com/ Remix Blog]
: Remix maintains a blog with additional case studies, webinars, and information about product updates. The blog also has videos from Remix's annual conferences, where planners talk about the way they use the tool at their agencies.

[[Category:Network planning software]]
[[Category:GTFS-consuming applications]]
[[Category:Applications]]
[[Category: Complex data analysis]]
[[Category:Scenario planning tools]]

Remix

2017-03-30T21:52:40Z

Aaronantrim: /* Layers */ import GIS - both heat maps and point data

{{infobox
|title= Remix
|image= Remix-logo.png
|vendor= Remix
|license= Proprietary
|documentation= None found online
|data_in= [[GTFS]], GIS shapefiles
|website= [https://www.remix.com/ https://www.remix.com/]
}}
[https://www.remix.com/ Remix] is web-hosted application for planning public transit systems. It automates the process of route and schedule scenario testing, letting planners draw routes onto a map and immediately see a potential schedule and fleet requirements. This can exponentially decrease the time costs of experimenting with different scenarios. As of October 2016, 36 transit agencies in California and over 150 across the world are using Remix. These agencies range in size from just a couple fleet vehicles to well over a thousand.
__TOC__
==How it Works==
[[Image:Remix1.png|right|thumb|700px|Remix makes it easy to draw a line and see schedule and cost information. Source: [https://www.remix.com/ Remix]]]
The process of route planning has typically required paper maps and work in Excel or other software packages. Remix consolidates data and analytical tools for route planning into a web interface. When an agency signs up with Remix, the company will work with them to integrate the system into the agency’s workflow.

===Setting up the existing transit network===
Remix employees import route info into the software using [[GTFS]] data and provide employee training. Remix identifies service spans and approximate frequencies -- average parameters describing the service abstracted from the exact imported schedule.

Variables such as operating cost per hour or mile (with costs for Saturday, peak) can be set for the agency.

===Creating scenarios / editing the network===
After onboarding is complete, the agency can start using Remix. New "scenarios" can be created. Each scenario can contain a different route network. Existing routes can be edited and new routes can be added. Span, frequency, and runtime can be adjusted for each route. Route alignments and stops are edited on a map. By default, Remix assumes that stops are placed every 0.25 miles. This default can be adjusted. Stops can also be deliberately placed on the map.

Measures including the following update as the route is drawn:
* Number of buses
* Operating cost per year
* Route miles
* Population within 0.25 mile of stops
* Jobs within 0.25 mile of stops

===Layers===
In order to better understand the impact of a route, various information layers such as population density and poverty rate can be overlaid onto the map. This helps ensure that the system is reaching the people and places it needs to, and any changes are compliant with [[Transit and Civil Rights|Title 6 of the Civil Rights Act of 1964]]. In addition, the Remix staff can create custom layers using GIS data provided by the agency — both heat maps and point data. For example, one agency in Australia created a shapefile for projected population growth to better plan for their future service area.
[[Image:RemixJane.png|right|thumb|250px|When using Jane, the white circles show how far a rider can travel in a specific timeframe. Source: [https://www.remix.com/ Remix]]]

===Jane===
Transit systems aren’t lines on maps; they are ways for people to get around a city. Remix includes a rider surrogate isochrone tool called Jane. You can put Jane anywhere on the map, select a time of day, and see how far she could travel in 15, 30, 45, or 60 minutes. This is helpful both for intra-agency planning and public outreach.

===Title VI Engine===
Title VI of the Civil Rights Act of 1964 prevents against discrimination in the provision of government services, including public transportation<ref>[https://www.transit.dot.gov/regulations-and-guidance/civil-rights-ada/title-vi-civil-rights-act-1964 Federal Transit Administration. "Title VI of the Civil Rights Act of 1964." 2016.]</ref>. A transit agency must do a Title VI analysis of any route changes to ensure that they do not disproportionately impact minority populations. This is incredibly important, but it does make it difficult for agencies to engage in major system change. Remix takes the complicated process of Title Vi analysis and simplifies it to a one-click automated function.

See the Remix discussion of the [https://blog.remix.com/title-vi-in-10-minutes-or-less-with-remixs-title-vi-engine-87f55eadcc4e Title VI process using Remix].

===Output formats===
Remix can output transit network scenarios, indicators, and visualizations in these formats:
* Shapefile
* Excel (describing indicators)
* [[GTFS]] - Frequency-based, describing service parameters rather than an operationally-ready schedule
* Embeddable map for the web (with a mechanism to leave comments)
* Printable view

==Applications==
The most obvious application for Remix is in the internal planning process. Planners can use the tool to quickly model scenarios and plan anything from a simple detour on a single route to an entirely new transit system.

Remix can be used as an outreach tool. In public meetings, it can allow a presenter to give a live demonstration of possible changes to a system. The real-time cost adjustments give a clear representation of how feasible a plan is. Most people have trouble visualizing how the average citizen can interact with a transit system, so Jane has a large potential to clarify the utility of a system.

==Costs==
The cost for Remix depends on the scale of the agency. Contact Remix sales for a quote.

==Case Studies==
* '''Scenario Planning in Torrance, CA''' - With a very small team, [https://www.torranceca.gov/92.htm Torrance Transit] was unable to make significant changes to its service. Scenario planning could be a months-long process. Remix cut this down to just a few days. Using the platform, the agency was able to model the effects of consolidating service on one of its bus lines and figured out it could do so without harming the community. Once implemented, the change will save Torrance Transit over half a million dollars per year<ref>[https://blog.remix.com/taking-the-heartache-out-of-planning-in-torrance-ca-9de28a01e89f#.9qbl25ech Remix. "Taking the Heartache Out of Planning in Torrance, CA." 2016.]</ref>.
* '''Collaboration in Greater Seattle, WA''' - Planning doesn’t just involve one agency; any project is going to have multiple stakeholders. When [http://metro.kingcounty.gov/ King County Metro] was working on a 25-year plan to add 2.5 million service hours to the network, it was looking at two years of consensus-building. Using Jane to clearly demonstrate the way routes interact, the planning team cut the feedback time on iterations in half and finalized the plan in just 9 months, with 2 or 3 fewer staff than would have been necessary otherwise<ref>[https://blog.remix.com/king-county-metro-builds-consensus-in-record-time-during-long-range-plan-76c14e57547d#.z7jcamego Remix. "King County Metro Builds Consensus in Record Time During Long-Range Plan." 2016.]</ref>.
* '''Planning for a Transit Tax in Indianapolis, IN''' - In November 2016, residents in central Indiana voted on a quarter-cent income tax hike to let the [http://www.indympo.org/Pages/home.aspx Indianapolis Metropolitan Planning Organization] increase bus service in two counties. Remix has let the MPO clearly demonstrate where the money would go. Working entirely in-house, the organization planned 7 scenarios for 7 funding levels that they could take to public meetings. The referendum passed<ref>[https://blog.remix.com/preparing-for-a-transit-tax-increase-in-indianapolis-indiana-1001b49118aa#.lkf3cze2x Remix. "Preparing for a Transit Tax Increase in Indianapolis, Indiana." 2016.]</ref>.

==References==
<references />

==Additional Reading==
[https://blog.remix.com/ Remix Blog]
: Remix maintains a blog with additional case studies, webinars, and information about product updates. The blog also has videos from Remix's annual conferences, where planners talk about the way they use the tool at their agencies.

[[Category:Network planning software]]
[[Category:GTFS-consuming applications]]
[[Category:Applications]]
[[Category: Complex data analysis]]
[[Category:Scenario planning tools]]

Remix

2017-03-30T21:51:36Z

Aaronantrim: /* Applications */ Added "Costs", toned down "marketing" tone

{{infobox
|title= Remix
|image= Remix-logo.png
|vendor= Remix
|license= Proprietary
|documentation= None found online
|data_in= [[GTFS]], GIS shapefiles
|website= [https://www.remix.com/ https://www.remix.com/]
}}
[https://www.remix.com/ Remix] is web-hosted application for planning public transit systems. It automates the process of route and schedule scenario testing, letting planners draw routes onto a map and immediately see a potential schedule and fleet requirements. This can exponentially decrease the time costs of experimenting with different scenarios. As of October 2016, 36 transit agencies in California and over 150 across the world are using Remix. These agencies range in size from just a couple fleet vehicles to well over a thousand.
__TOC__
==How it Works==
[[Image:Remix1.png|right|thumb|700px|Remix makes it easy to draw a line and see schedule and cost information. Source: [https://www.remix.com/ Remix]]]
The process of route planning has typically required paper maps and work in Excel or other software packages. Remix consolidates data and analytical tools for route planning into a web interface. When an agency signs up with Remix, the company will work with them to integrate the system into the agency’s workflow.

===Setting up the existing transit network===
Remix employees import route info into the software using [[GTFS]] data and provide employee training. Remix identifies service spans and approximate frequencies -- average parameters describing the service abstracted from the exact imported schedule.

Variables such as operating cost per hour or mile (with costs for Saturday, peak) can be set for the agency.

===Creating scenarios / editing the network===
After onboarding is complete, the agency can start using Remix. New "scenarios" can be created. Each scenario can contain a different route network. Existing routes can be edited and new routes can be added. Span, frequency, and runtime can be adjusted for each route. Route alignments and stops are edited on a map. By default, Remix assumes that stops are placed every 0.25 miles. This default can be adjusted. Stops can also be deliberately placed on the map.

Measures including the following update as the route is drawn:
* Number of buses
* Operating cost per year
* Route miles
* Population within 0.25 mile of stops
* Jobs within 0.25 mile of stops

===Layers===
In order to better understand the impact of a route, various information layers such as population density and poverty rate can be overlaid onto the map. This helps ensure that the system is reaching the people and places it needs to, and any changes are compliant with [[Transit and Civil Rights|Title 6 of the Civil Rights Act of 1964]]. In addition, the Remix staff can create custom layers using GIS data provided by the agency. For example, one agency in Australia created a shapefile for projected population growth to better plan for their future service area.
[[Image:RemixJane.png|right|thumb|250px|When using Jane, the white circles show how far a rider can travel in a specific timeframe. Source: [https://www.remix.com/ Remix]]]
===Jane===
Transit systems aren’t lines on maps; they are ways for people to get around a city. Remix includes a rider surrogate isochrone tool called Jane. You can put Jane anywhere on the map, select a time of day, and see how far she could travel in 15, 30, 45, or 60 minutes. This is helpful both for intra-agency planning and public outreach.

===Title VI Engine===
Title VI of the Civil Rights Act of 1964 prevents against discrimination in the provision of government services, including public transportation<ref>[https://www.transit.dot.gov/regulations-and-guidance/civil-rights-ada/title-vi-civil-rights-act-1964 Federal Transit Administration. "Title VI of the Civil Rights Act of 1964." 2016.]</ref>. A transit agency must do a Title VI analysis of any route changes to ensure that they do not disproportionately impact minority populations. This is incredibly important, but it does make it difficult for agencies to engage in major system change. Remix takes the complicated process of Title Vi analysis and simplifies it to a one-click automated function.

See the Remix discussion of the [https://blog.remix.com/title-vi-in-10-minutes-or-less-with-remixs-title-vi-engine-87f55eadcc4e Title VI process using Remix].

===Output formats===
Remix can output transit network scenarios, indicators, and visualizations in these formats:
* Shapefile
* Excel (describing indicators)
* [[GTFS]] - Frequency-based, describing service parameters rather than an operationally-ready schedule
* Embeddable map for the web (with a mechanism to leave comments)
* Printable view

==Applications==
The most obvious application for Remix is in the internal planning process. Planners can use the tool to quickly model scenarios and plan anything from a simple detour on a single route to an entirely new transit system.

Remix can be used as an outreach tool. In public meetings, it can allow a presenter to give a live demonstration of possible changes to a system. The real-time cost adjustments give a clear representation of how feasible a plan is. Most people have trouble visualizing how the average citizen can interact with a transit system, so Jane has a large potential to clarify the utility of a system.

==Costs==
The cost for Remix depends on the scale of the agency. Contact Remix sales for a quote.

==Case Studies==
* '''Scenario Planning in Torrance, CA''' - With a very small team, [https://www.torranceca.gov/92.htm Torrance Transit] was unable to make significant changes to its service. Scenario planning could be a months-long process. Remix cut this down to just a few days. Using the platform, the agency was able to model the effects of consolidating service on one of its bus lines and figured out it could do so without harming the community. Once implemented, the change will save Torrance Transit over half a million dollars per year<ref>[https://blog.remix.com/taking-the-heartache-out-of-planning-in-torrance-ca-9de28a01e89f#.9qbl25ech Remix. "Taking the Heartache Out of Planning in Torrance, CA." 2016.]</ref>.
* '''Collaboration in Greater Seattle, WA''' - Planning doesn’t just involve one agency; any project is going to have multiple stakeholders. When [http://metro.kingcounty.gov/ King County Metro] was working on a 25-year plan to add 2.5 million service hours to the network, it was looking at two years of consensus-building. Using Jane to clearly demonstrate the way routes interact, the planning team cut the feedback time on iterations in half and finalized the plan in just 9 months, with 2 or 3 fewer staff than would have been necessary otherwise<ref>[https://blog.remix.com/king-county-metro-builds-consensus-in-record-time-during-long-range-plan-76c14e57547d#.z7jcamego Remix. "King County Metro Builds Consensus in Record Time During Long-Range Plan." 2016.]</ref>.
* '''Planning for a Transit Tax in Indianapolis, IN''' - In November 2016, residents in central Indiana voted on a quarter-cent income tax hike to let the [http://www.indympo.org/Pages/home.aspx Indianapolis Metropolitan Planning Organization] increase bus service in two counties. Remix has let the MPO clearly demonstrate where the money would go. Working entirely in-house, the organization planned 7 scenarios for 7 funding levels that they could take to public meetings. The referendum passed<ref>[https://blog.remix.com/preparing-for-a-transit-tax-increase-in-indianapolis-indiana-1001b49118aa#.lkf3cze2x Remix. "Preparing for a Transit Tax Increase in Indianapolis, Indiana." 2016.]</ref>.

==References==
<references />

==Additional Reading==
[https://blog.remix.com/ Remix Blog]
: Remix maintains a blog with additional case studies, webinars, and information about product updates. The blog also has videos from Remix's annual conferences, where planners talk about the way they use the tool at their agencies.

[[Category:Network planning software]]
[[Category:GTFS-consuming applications]]
[[Category:Applications]]
[[Category: Complex data analysis]]
[[Category:Scenario planning tools]]

Remix

2017-03-30T21:49:04Z

Aaronantrim: /* How it Works */ Setting up the existing transit network, scenarios, outputs

{{infobox
|title= Remix
|image= Remix-logo.png
|vendor= Remix
|license= Proprietary
|documentation= None found online
|data_in= [[GTFS]], GIS shapefiles
|website= [https://www.remix.com/ https://www.remix.com/]
}}
[https://www.remix.com/ Remix] is web-hosted application for planning public transit systems. It automates the process of route and schedule scenario testing, letting planners draw routes onto a map and immediately see a potential schedule and fleet requirements. This can exponentially decrease the time costs of experimenting with different scenarios. As of October 2016, 36 transit agencies in California and over 150 across the world are using Remix. These agencies range in size from just a couple fleet vehicles to well over a thousand.
__TOC__
==How it Works==
[[Image:Remix1.png|right|thumb|700px|Remix makes it easy to draw a line and see schedule and cost information. Source: [https://www.remix.com/ Remix]]]
The process of route planning has typically required paper maps and work in Excel or other software packages. Remix consolidates data and analytical tools for route planning into a web interface. When an agency signs up with Remix, the company will work with them to integrate the system into the agency’s workflow.

===Setting up the existing transit network===
Remix employees import route info into the software using [[GTFS]] data and provide employee training. Remix identifies service spans and approximate frequencies -- average parameters describing the service abstracted from the exact imported schedule.

Variables such as operating cost per hour or mile (with costs for Saturday, peak) can be set for the agency.

===Creating scenarios / editing the network===
After onboarding is complete, the agency can start using Remix. New "scenarios" can be created. Each scenario can contain a different route network. Existing routes can be edited and new routes can be added. Span, frequency, and runtime can be adjusted for each route. Route alignments and stops are edited on a map. By default, Remix assumes that stops are placed every 0.25 miles. This default can be adjusted. Stops can also be deliberately placed on the map.

Measures including the following update as the route is drawn:
* Number of buses
* Operating cost per year
* Route miles
* Population within 0.25 mile of stops
* Jobs within 0.25 mile of stops

===Layers===
In order to better understand the impact of a route, various information layers such as population density and poverty rate can be overlaid onto the map. This helps ensure that the system is reaching the people and places it needs to, and any changes are compliant with [[Transit and Civil Rights|Title 6 of the Civil Rights Act of 1964]]. In addition, the Remix staff can create custom layers using GIS data provided by the agency. For example, one agency in Australia created a shapefile for projected population growth to better plan for their future service area.
[[Image:RemixJane.png|right|thumb|250px|When using Jane, the white circles show how far a rider can travel in a specific timeframe. Source: [https://www.remix.com/ Remix]]]
===Jane===
Transit systems aren’t lines on maps; they are ways for people to get around a city. Remix includes a rider surrogate isochrone tool called Jane. You can put Jane anywhere on the map, select a time of day, and see how far she could travel in 15, 30, 45, or 60 minutes. This is helpful both for intra-agency planning and public outreach.

===Title VI Engine===
Title VI of the Civil Rights Act of 1964 prevents against discrimination in the provision of government services, including public transportation<ref>[https://www.transit.dot.gov/regulations-and-guidance/civil-rights-ada/title-vi-civil-rights-act-1964 Federal Transit Administration. "Title VI of the Civil Rights Act of 1964." 2016.]</ref>. A transit agency must do a Title VI analysis of any route changes to ensure that they do not disproportionately impact minority populations. This is incredibly important, but it does make it difficult for agencies to engage in major system change. Remix takes the complicated process of Title Vi analysis and simplifies it to a one-click automated function.

See the Remix discussion of the [https://blog.remix.com/title-vi-in-10-minutes-or-less-with-remixs-title-vi-engine-87f55eadcc4e Title VI process using Remix].

===Output formats===
Remix can output transit network scenarios, indicators, and visualizations in these formats:
* Shapefile
* Excel (describing indicators)
* [[GTFS]] - Frequency-based, describing service parameters rather than an operationally-ready schedule
* Embeddable map for the web (with a mechanism to leave comments)
* Printable view

==Applications==
The most obvious application for Remix is in the internal planning process. Planners can use the tool to quickly model scenarios and plan anything from a simple detour on a single route to an entirely new transit system.

Remix can be used as a powerful outreach tool. In public meetings, it can allow a presenter to give a live demonstration of possible changes to a system. The real-time cost adjustments give a clear representation of how feasible a plan is. Most people have trouble visualizing how the average citizen can interact with a transit system, so Jane has a large potential to clarify the utility of a system.

==Case Studies==
* '''Scenario Planning in Torrance, CA''' - With a very small team, [https://www.torranceca.gov/92.htm Torrance Transit] was unable to make significant changes to its service. Scenario planning could be a months-long process. Remix cut this down to just a few days. Using the platform, the agency was able to model the effects of consolidating service on one of its bus lines and figured out it could do so without harming the community. Once implemented, the change will save Torrance Transit over half a million dollars per year<ref>[https://blog.remix.com/taking-the-heartache-out-of-planning-in-torrance-ca-9de28a01e89f#.9qbl25ech Remix. "Taking the Heartache Out of Planning in Torrance, CA." 2016.]</ref>.
* '''Collaboration in Greater Seattle, WA''' - Planning doesn’t just involve one agency; any project is going to have multiple stakeholders. When [http://metro.kingcounty.gov/ King County Metro] was working on a 25-year plan to add 2.5 million service hours to the network, it was looking at two years of consensus-building. Using Jane to clearly demonstrate the way routes interact, the planning team cut the feedback time on iterations in half and finalized the plan in just 9 months, with 2 or 3 fewer staff than would have been necessary otherwise<ref>[https://blog.remix.com/king-county-metro-builds-consensus-in-record-time-during-long-range-plan-76c14e57547d#.z7jcamego Remix. "King County Metro Builds Consensus in Record Time During Long-Range Plan." 2016.]</ref>.
* '''Planning for a Transit Tax in Indianapolis, IN''' - In November 2016, residents in central Indiana voted on a quarter-cent income tax hike to let the [http://www.indympo.org/Pages/home.aspx Indianapolis Metropolitan Planning Organization] increase bus service in two counties. Remix has let the MPO clearly demonstrate where the money would go. Working entirely in-house, the organization planned 7 scenarios for 7 funding levels that they could take to public meetings. The referendum passed<ref>[https://blog.remix.com/preparing-for-a-transit-tax-increase-in-indianapolis-indiana-1001b49118aa#.lkf3cze2x Remix. "Preparing for a Transit Tax Increase in Indianapolis, Indiana." 2016.]</ref>.

==References==
<references />

==Additional Reading==
[https://blog.remix.com/ Remix Blog]
: Remix maintains a blog with additional case studies, webinars, and information about product updates. The blog also has videos from Remix's annual conferences, where planners talk about the way they use the tool at their agencies.

[[Category:Network planning software]]
[[Category:GTFS-consuming applications]]
[[Category:Applications]]
[[Category: Complex data analysis]]
[[Category:Scenario planning tools]]

Remix

2017-03-30T21:25:58Z

Aaronantrim: /* Title VI Engine */ Added link to Title VI in 10 Minutes or Less with Remix’s Title VI Engine

{{infobox
|title= Remix
|image= Remix-logo.png
|vendor= Remix
|license= Proprietary
|documentation= None found online
|data_in= [[GTFS]], GIS shapefiles
|website= [https://www.remix.com/ https://www.remix.com/]
}}
[https://www.remix.com/ Remix] is web-hosted application for planning public transit systems. It automates the process of route and schedule scenario testing, letting planners draw routes onto a map and immediately see a potential schedule and fleet requirements. This can exponentially decrease the time costs of experimenting with different scenarios. As of October 2016, 36 transit agencies in California and over 150 across the world are using Remix. These agencies range in size from just a couple fleet vehicles to well over a thousand.
__TOC__
==How it Works==
[[Image:Remix1.png|right|thumb|700px|Remix makes it easy to draw a line and see schedule and cost information. Source: [https://www.remix.com/ Remix]]]
The process of route planning has typically required paper maps and work in Excel or other software packages. Remix consolidates data and analytical tools for route planning into a web interface. When an agency signs up with Remix, the company will work with them to integrate the system into the agency’s workflow. Remix employees import route info into the software using [[GTFS]] and provide employee training.

After onboarding is complete, the agency can start using Remix. Some or all routes appear on a map alongside tables showing route information like headways, speed, cost, and people served. As a planner draws or adjusts a route, this information changes in real time.

===Layers===
In order to better understand the impact of a route, various information layers such as population density and poverty rate can be overlaid onto the map. This helps ensure that the system is reaching the people and places it needs to, and any changes are compliant with [[Transit and Civil Rights|Title 6 of the Civil Rights Act of 1964]]. In addition, the Remix staff can create custom layers using GIS data provided by the agency. For example, one agency in Australia created a shapefile for projected population growth to better plan for their future service area.
[[Image:RemixJane.png|right|thumb|250px|When using Jane, the white circles show how far a rider can travel in a specific timeframe. Source: [https://www.remix.com/ Remix]]]
===Jane===
Transit systems aren’t lines on maps; they are ways for people to get around a city. Remix includes a rider surrogate isochrone tool called Jane. You can put Jane anywhere on the map, select a time of day, and see how far she could travel in 15, 30, 45, or 60 minutes. This is helpful both for intra-agency planning and public outreach.

===Title VI Engine===
Title VI of the Civil Rights Act of 1964 prevents against discrimination in the provision of government services, including public transportation<ref>[https://www.transit.dot.gov/regulations-and-guidance/civil-rights-ada/title-vi-civil-rights-act-1964 Federal Transit Administration. "Title VI of the Civil Rights Act of 1964." 2016.]</ref>. A transit agency must do a Title VI analysis of any route changes to ensure that they do not disproportionately impact minority populations. This is incredibly important, but it does make it difficult for agencies to engage in major system change. Remix takes the complicated process of Title Vi analysis and simplifies it to a one-click automated function.

See the Remix discussion of the [https://blog.remix.com/title-vi-in-10-minutes-or-less-with-remixs-title-vi-engine-87f55eadcc4e Title VI process using Remix].

==Applications==
The most obvious application for Remix is in the internal planning process. Planners can use the tool to quickly model scenarios and plan anything from a simple detour on a single route to an entirely new transit system.

Remix can be used as a powerful outreach tool. In public meetings, it can allow a presenter to give a live demonstration of possible changes to a system. The real-time cost adjustments give a clear representation of how feasible a plan is. Most people have trouble visualizing how the average citizen can interact with a transit system, so Jane has a large potential to clarify the utility of a system.

==Case Studies==
* '''Scenario Planning in Torrance, CA''' - With a very small team, [https://www.torranceca.gov/92.htm Torrance Transit] was unable to make significant changes to its service. Scenario planning could be a months-long process. Remix cut this down to just a few days. Using the platform, the agency was able to model the effects of consolidating service on one of its bus lines and figured out it could do so without harming the community. Once implemented, the change will save Torrance Transit over half a million dollars per year<ref>[https://blog.remix.com/taking-the-heartache-out-of-planning-in-torrance-ca-9de28a01e89f#.9qbl25ech Remix. "Taking the Heartache Out of Planning in Torrance, CA." 2016.]</ref>.
* '''Collaboration in Greater Seattle, WA''' - Planning doesn’t just involve one agency; any project is going to have multiple stakeholders. When [http://metro.kingcounty.gov/ King County Metro] was working on a 25-year plan to add 2.5 million service hours to the network, it was looking at two years of consensus-building. Using Jane to clearly demonstrate the way routes interact, the planning team cut the feedback time on iterations in half and finalized the plan in just 9 months, with 2 or 3 fewer staff than would have been necessary otherwise<ref>[https://blog.remix.com/king-county-metro-builds-consensus-in-record-time-during-long-range-plan-76c14e57547d#.z7jcamego Remix. "King County Metro Builds Consensus in Record Time During Long-Range Plan." 2016.]</ref>.
* '''Planning for a Transit Tax in Indianapolis, IN''' - In November 2016, residents in central Indiana voted on a quarter-cent income tax hike to let the [http://www.indympo.org/Pages/home.aspx Indianapolis Metropolitan Planning Organization] increase bus service in two counties. Remix has let the MPO clearly demonstrate where the money would go. Working entirely in-house, the organization planned 7 scenarios for 7 funding levels that they could take to public meetings. The referendum passed<ref>[https://blog.remix.com/preparing-for-a-transit-tax-increase-in-indianapolis-indiana-1001b49118aa#.lkf3cze2x Remix. "Preparing for a Transit Tax Increase in Indianapolis, Indiana." 2016.]</ref>.

==References==
<references />

==Additional Reading==
[https://blog.remix.com/ Remix Blog]
: Remix maintains a blog with additional case studies, webinars, and information about product updates. The blog also has videos from Remix's annual conferences, where planners talk about the way they use the tool at their agencies.

[[Category:Network planning software]]
[[Category:GTFS-consuming applications]]
[[Category:Applications]]
[[Category: Complex data analysis]]
[[Category:Scenario planning tools]]

TransCAD 6.0

2017-03-20T16:49:07Z

Aaronantrim: Aaronantrim moved page TransCAD 6.0 to TransCAD: Other software pages are not tied to specific versions. Make consistent.

#REDIRECT [[TransCAD]]

TransCAD

2017-03-20T16:49:07Z

Aaronantrim: Aaronantrim moved page TransCAD 6.0 to TransCAD: Other software pages are not tied to specific versions. Make consistent.

TransCad is a commercial travel demand forecasting software product sold by Caliper Corporation. Starting with TransCAD 6.0, GTFS file format input and GTFS-based best route solutions are supported <ref>Caliper Corporation. "TransCAD 6.0 is Released." Accessed November 1, 2012 from http://www.caliper.com/Press/pr20120814.htm</ref>.

==References==
[[Category:GTFS-consuming applications]]
[[Category:Network planning software]]
[[Category:Scenario planning tools]]

TransCAD

2017-03-20T16:48:27Z

Aaronantrim: added Category:Scenario planning tools

STOPS (Simplified Trips-on-Project Software)

2017-03-20T16:47:11Z

Aaronantrim: Add Category:Scenario planning tools

{{infobox
|title=Simplified Trips-on-Project Software
|image=
|vendor=[[FTA]]
|license=
|documentation=[https://www.transit.dot.gov/funding/grant-programs/capital-investments/stops-%E2%80%93-documentation-and-software www.transit.dot.gov/funding/grant-programs/capital-investments/stops-%E2%80%93-documentation-and-software]
|data_in=[[GTFS]], [[CTPP]], [[GIS]] shapefiles, regional travel models
|data_out=ridership projections, VMT changes
|website=[https://www.transit.dot.gov/funding/grant-programs/capital-investments/stops-%E2%80%93-fta%E2%80%99s-simplified-trips-project-software www.transit.dot.gov/funding/grant-programs/capital-investments/stops-%E2%80%93-fta%E2%80%99s-simplified-trips-project-software]
}}

The [[FTA]] releases STOPS in 2013 to help agencies adapt to the new Final Rule on major capitol investment projects approved through [[New Starts]] and [[Small Starts]]. The rule specifies that applications for these projects require ridership forecasts for new lines, since mobility benefits are evaluated as new trips on the project, with a double weight given to transit dependent users. A component of the environmental benefit that is evaluated in the creation of a new line will includes changes to vehicle miles traveled (VMT). STOPS provides this information to help agencies offer it as part of their application for funding.

__TOC__
==How it works==
===Four-step travel model===
STOPS is uses a an altered [[four-step travel model]] to produce ridership and VMT estimates using zone-to-zone markets stratified by household vehicle ownership and a conventional mode-choice model to predict zone-to-zone transit travel.

Stops differs from four-steps models in a number of key ways:
*STOPS replaces the trip-generation and trip-distribution components with worker-flow tabulations from the [[Census Transportation Planning Package]]
(CTPP)
*STOPS factors the worker flows to represent home-based work-trip patterns and to account for home-based non-work-trip patterns as well
*STOPS uses the transit trip attractions predicted in each zone for home-based travel to characterize the non-home-based travel market
*Trip patterns are scaled to different years using population and employment estimates
*Coded transit data is replaced with GTFS both for the current transit system and to represent proposed changes
*STOPS relies on zone-to-zone roadway times and distances derived from the regional travel model for both the current year and for future predictions. This takes the place of any direct representation of the roadway network or directly assigned automobile trips.
*VMT changes are calculated by multiplying trips shifted from automobile to transit on a zone-to-zone basis by the specified zone-to-zone travel distance.
*STOPS is calibrated for broad application, not for any specific region, as four-step models often are. STOPS adjusts to specific regions in application by calibrating based on
**total transit system boardings
**the share of CTPP worker flows to jobs in each subarea that is captured by transit
**daily number of boardings at individual stations on any existing fixed-guideway facilities

===Implementation===
Project staff can download STOPS from the FTA website and install it locally.

===Inputs===
STOPS uses a number of inputs for to make its predictions. Some are pulled directly through the software, whereas others have to be added by the project technician.
*[[Census Transportation Planning Products]] (CTPP) can be downloaded as a bundle by state from the STOPS page on the FTA website.<ref> CTPP data for STOPS https://www.transit.dot.gov/funding/grant-programs/capital-investments/stops-data-census</ref>. This data provides population data, workflows, household automobile ownership, and mode-choice by zone.
*[[GTFS]] data provided by the local agency.
*zone-specific population and employment estimates for the year 2000, the current year and, if applicable, for one or more future years pulled from the regional travel model
*zone-to-zone roadway travel times and distances from the regional travel model

==Evaluation==
===Benefits===
STOPS use of standardized data such as [[GTFS]] and [[CTPP]] makes it much easier to maintain consistency and therefore offer effective predictions across different metros. This is particularly true when metro specific adjustments are made. A comparison of STOPS predictions and observed ridership on 15 different systems found a near perfect match.<ref>FTA: An Overview of STOPS https://www.transit.dot.gov/sites/fta.dot.gov/files/docs/STOPS.overview-web-final.pdf ''Accessed 12 February 2017''</ref>

STOPS is particularly helpful where regional models are not available because they do not adequately represent transit as differentiated from road usage. Even where regional models are available, STOPS offers a useful quality control option to view a second ridership forecast, and the FTA will always accept the numbers dervived from a successful application of STOPS.

===Limitations===
*STOPS is only available for evaluation fixed guideway projects (because [[New Starts]] and [[Small Starts]] are only available for fixed guideway projects). It does not work for local buses or other roadway forecasts.
*The [[CTPP]] data that STOPS relies on only offers routine weekday travel information, which looks at resident travel patters in the trip categories: home-based work, home-based non-work, and non-home based. This excludes special markets such as students or airport trips.
*STOPS does not consider transit capacity. It does not adjust ridership forecasts based on limited capacity, and does not account for the benefits that a project can offer in relieving over-stressed transit capacity.
*As of 2013, STOPS was using projections from CTPP info that was pulled from the 2000 census. There is a planned update to use ACS data to make it more current.

==References==
<references />

==Further Reading==
* [https://www.transit.dot.gov/funding/grant-programs/capital-investments/stops-%E2%80%93-fta%E2%80%99s-simplified-trips-project-software STOPS documentation and overview] from the Federal Transit Administration (FTA)
* [http://tfresource.org/STOPS STOPS on the Travel Forecasting Resource wiki]
*FTA: An Overview of STOPS https://www.transit.dot.gov/sites/fta.dot.gov/files/docs/STOPS.overview-web-final.pdf
[[Category:GTFS-consuming applications]]
[[Category:Ridership forecasting]]
[[Category:Scenario planning tools]]

Category:Scenario planning tools

2017-03-17T19:33:44Z

Aaronantrim: add link to scenario planning article

Scenario planning tools allow for quick visualizations or demonstrations of effects, whether or riders, revenues, networks, or other factors, as a result of small changes to transit service and network. These tools have the potential to allow for better integration of transit data to offer quicker updates to transit systems that would be more responsive to changes in demand and need. Refer to the [[scenario planning]] article for a more complete discussion of this practice and the variety of definitions of scenario planning.

Transit Boardings Estimation and Simulation Tool (TBEST)

2017-03-17T19:29:36Z

Aaronantrim: correction to Category:Scenario planning tools

{{edit queue
|editor=Aaronantrim
}}

[[Image:Tbest.jpg|right|thumb|600px|An example of the land use analysis possible within TBEST. Source: [http://tbest.org/wp-content/files/TBEST_TRB_Applications_Conference-_may_2015.pdf Center for Urban Transportation Research]]]
==Introduction==
[http://tbest.org/ Transit Boardings Estimation and Simulation Tool (TBEST)] is a GIS-based transit modeling and analysis program developed for the [http://www.fdot.gov/ Florida Department of Transportation]. It was originally meant to estimate ridership numbers for Florida transit agencies for transportation demand management plans, but has been expanded to be applicable across the country and to assist in processes such as market analysis, bus rapid transit modeling, and Title VI analysis. TBEST requires a licensed copy of ArcGIS and Windows 7 or later, but the software itself is free to use.

==How it Works==
TBEST is based on transit system data. While these templates are provided for Florida agencies, in the rest of the country they must be created manually. This has been done in Los Angeles<ref>[http://tbest.org/download/TBEST41_Overview.pptx Center for Urban Transportation Research. "The TBEST Framework for Data Analysis and Forecasting." 2013.]</ref>. The TBEST team is available to help configure local [[GTFS]] and other data to be inputted into the system. Once the base scenario has been imported, actual ridership data is used to validate the scenario.

After validating the base scenario, TBEST can be used for in-depth scenario planning. A user can create alternative scenarios with new routes, stops, or service levels. These new scenarios can then be compared to the base scenario. These analyses can be done for six different time periods: AM peak, off-peak, PM peak, night, Saturday, and Sunday.

===Market Analysis===
The viability of a transit line is determined in part by the area it serves. To forecast viability, TBEST allows users to perform market analyses on current or potential routes. This can be done either using socio-economic data from the census or parcel-level land use data. The analysis can also take into account projected population, household, or employment growth.

Using socio-economic data, the analysis can be broken down to population, household, income, and employment profiles. Users can also see the distribution of a wide range of individual market variables, including race, gender, age, income, and vehicle ownership. These variables can then be compared to system averages. With land use data, the market area can be broken down by use.

After a market analysis has been performed, TBEST can generate reports in formats such as PDF, Excel, and PowerPoint.

===Title VI Analysis===
All transit agencies are required to comply with [[Transit and Civil Rights|Title VI of the 1964 Civil Rights Act]], which prevents recipients of federal money from discriminating against protected classes<ref>[https://www.transit.dot.gov/regulations-and-guidance/civil-rights-ada/title-vi-civil-rights-act-1964 Federal Transit Administration. "Title VI of the Civil Rights Act of 1964." 2016.]</ref>. This means performing analyses to ensure that service changes are not having disparate impacts on minority populations. TBEST includes a toolset to help automate this process. After inputting Title VI-compliant socio-economic data, the GTFS network, stop amenities, and service area, the software will perform an analysis and output the results in report and map format, as mandated by Title VI. Maps are created in the ArcMap format to facilitate further editing, if necessary. The core purpose of TBEST is scenario planning, and the program makes it easy to compare Title VI analyses for various potential scenarios. TBEST contains tools for performing both system-wide triennial analyses and interim disparate impact analyses on specific changes.

===Transit Access===
TBEST offers two different toolsets measuring transit access: Access to Transit and Access via Transit. Access to Transit measures walk access from homes and jobs to transit, while Access via Transit measures jobs, people, and land use accessible between stop pairs. Like the Title VI analysis, these analyses can be performed automatically after a few variables have been inputted and can be used to compare various scenarios.

==[http://tbest.org/ Transit Boardings Estimation and Simulation Tool]==

==References==
<references />

==Additional Reading==
[http://tbest.org/downloads/?dl_cat=10 TBEST 4.4 User Guide]

: This extremely detailed guide provides illustrated instructions for all of TBEST's many features.

[http://tbest.org/wp-content/files/TDPReviewandReporting_Final_1-19-2012.pdf TBEST - Guidelines for Transit Development Plan Ridership Estimation Review and Reporting]

: This document outlines the way in which TBEST can be used in transportation development plan modeling.

[https://www.cutr.usf.edu/2017/03/cutr-webcast-utilizing-tbest-for-comprehensive-transit-planning/ Utilizing TBEST for Comprehensive Transit Planning - CUTR Webcast Recording - March 2, 2017]

: Recording of an hour-long webinar presented by Rodney Bunner covering the functionality of the Transit Boardings and Simulation Tool (TBEST). Hosted by the Center for Urban Transportation Research (CURT).

[[Category:GTFS-consuming applications]]
[[Category:Network planning software]]
[[Category:Ridership forecasting]]
[[Category:Scenario planning tools]]

Transit Boardings Estimation and Simulation Tool (TBEST)

2017-03-17T19:23:41Z

Aaronantrim: added Category:Scenario planning tools, CUTR webinar link

Best practices for creating GTFS

2017-02-23T16:57:35Z

Aaronantrim: added gtfs.org/best-practices

The [[General Transit Feed Specification]] allows for transit features to be described using a variety of approaches. In some cases, particular approaches will result in better results in [[:Category:GTFS-consuming applications|GTFS-consuming applications]]. Various pages on the web offer advice on best practices for creating GTFS.

* [http://gtfs.org/best-practices/ GTFS.org Industry-Standard Best Practices] - These Best Practices are agreed to and published by 17 industry partners. These are the most broadly-accepted and complete GTFS Best Practices.
* [[The Transit App]] [http://transitapp.com/developers developers page] provides "Open Data Guidelines" which includes recommendations on how to form GTFS for best results in the application.
* Google Maps has a [https://maps.google.com/help/maps/mapcontent/transit/bestpractices.html GTFS Best Practices Guide]
* An [https://docs.google.com/document/d/1FeAJNDs-1EdzcQq_daq8_uR0KIug6tzKDxdPxSdi8L4/edit?usp=sharing open Google Doc] has captured some best practices from members of the GTFS community.
* [[RideSchedules]] provides GTFS Publisher Best Practices for creating and hosting GTFS.
* [https://kurtraschke.com/2014/03/gtfs-download Kurt Raschke] provides recommendations for how to host GTFS data on a server to ensure update availability in consuming applications.
* [https://gtfsbook.com Quentin Zervaas's Book The Definitive Guide to GTFS] offers some discussion of GTFS best practices and style choices.
* [https://github.com/google/transitfeed/wiki/FeedValidatorErrorsAndWarnings FeedValidator's errors and warnings] reference provides an inventory of some common GTFS defects to avoid. feedvalidator.py software can automatically identify these potential issues.
* [https://trilliumtransit.zendesk.com/hc/en-us/articles/201876369-Display-of-headsign-Google-Maps- Best practices and application-behavior context for specifying headsigns] in GTFS from [[Trillium]].
* The Center for Urban Transportation Research at the University of South Florida has identified [https://github.com/CUTR-at-USF/gtfs-realtime-validator/wiki/Rules-and-Test-Cases some best practices] as part of their experience with GTFS-realtime feeds.

[[Category:General Transit Feed Specification]]
{{Template:Contributors}}

Transit ITS Data Exchange Specification (TIDES)

2017-02-10T17:14:00Z

Aaronantrim: created page

"The Transit ITS Data Exchange Specification (TIDES) is designed to allow transit agencies to more easily share processes for accessing and managing intelligent transportation systems (ITS) data and share to reports and tools that use ITS data.

ITS data in this case refers to the information generated by automatic vehicle location (AVL), automatic passenger counter (APC), automatic fare collection (AFC), and similar systems. Basic data elements include vehicle location information and passenger boarding and alighting data." (TIDES Architecture document)<ref>https://docs.google.com/document/d/1hkEhMigZEfVUjzmLPftr3dI2GqNVFIaJrSzgw-4Jl_8/edit</ref>

Links:
* [https://docs.google.com/document/d/1hkEhMigZEfVUjzmLPftr3dI2GqNVFIaJrSzgw-4Jl_8/edit TIDES Architecture]
* [https://docs.google.com/document/d/11FKJnKVKHYXZEWAJhFkHF8T5RvRHMwrvkcMu43f-FHY/edit TIDES workplan]
* [https://drive.google.com/drive/u/1/folders/0BxRz85uz93fTUjNnR0FQd1NSR1k Introducing TIDES (slide deck)]

[[Category:Ridership data]]
[[Category:Data architecture]]

Accessibility Observatory

2017-02-10T01:30:12Z

Aaronantrim: Aaron Antrim --> Aaronantrim

{{edit queue
|editor=Aaronantrim
}}

{{infobox
|title=Accessibility Observatory
|vendor=University of Minnesota
|license=N/A
|website= [http://access.umn.edu/ http://access.umn.edu/]
}}

"The Accessibility Observatory at the University of Minnesota is the nation's leading resource for the research and application of accessibility-based transportation system evaluation. The Observatory is guided by a threefold mission:

#To advance the field of transportation system evaluation through research of new data sources and methods for accessibility evaluation
#To develop standards and tools to facilitate the use and communication of accessibility-based metrics in transportation planning, engineering, and evaluation
#To apply our tools and expertise in support of continual improvements in the planning, design, engineering, and analysis of transportation systems

The Observatory is a program of the [http://www.cts.umn.edu/ Center for Transportation Studies] and the [http://www.cege.umn.edu/ Department of Civil, Environmental, and Geo- Engineering].

The Accessibility Observatory builds on earlier work conducted at the University of Minnesota, including the [http://access.umn.edu/research/previous/destinations Access to Destinations study] and the [http://access.umn.edu/research/previous/trg/ Transportation and Regional Growth study]."<ref>http://access.umn.edu/about/</ref>

==References==
<references />

[[Category:GTFS-consuming applications]]

Transit Boardings Estimation and Simulation Tool (TBEST)

2017-02-10T01:29:09Z

Aaronantrim: Aaronantrim

{{edit queue
|editor=Aaronantrim
}}

[[Image:Tbest.jpg|right|thumb|600px|An example of the land use analysis possible within TBEST. Source: [http://tbest.org/wp-content/files/TBEST_TRB_Applications_Conference-_may_2015.pdf Center for Urban Transportation Research]]]
==Introduction==
[http://tbest.org/ Transit Boardings Estimation and Simulation Tool (TBEST)] is a GIS-based transit modeling and analysis program developed for the [http://www.fdot.gov/ Florida Department of Transportation]. It was originally meant to estimate ridership numbers for Florida transit agencies for transportation demand management plans, but has been expanded to be applicable across the country and to assist in processes such as market analysis, bus rapid transit modeling, and Title VI analysis. TBEST requires a licensed copy of ArcGIS and Windows 7 or later, but the software itself is free to use.

==How it Works==
TBEST is based on transit system data. While these templates are provided for Florida agencies, in the rest of the country they must be created manually. This has been done in Los Angeles<ref>[http://tbest.org/download/TBEST41_Overview.pptx Center for Urban Transportation Research. "The TBEST Framework for Data Analysis and Forecasting." 2013.]</ref>. The TBEST team is available to help configure local [[GTFS]] and other data to be inputted into the system. Once the base scenario has been imported, actual ridership data is used to validate the scenario.

After validating the base scenario, TBEST can be used for in-depth scenario planning. A user can create alternative scenarios with new routes, stops, or service levels. These new scenarios can then be compared to the base scenario. These analyses can be done for six different time periods: AM peak, off-peak, PM peak, night, Saturday, and Sunday.

===Market Analysis===
The viability of a transit line is determined in part by the area it serves. To forecast viability, TBEST allows users to perform market analyses on current or potential routes. This can be done either using socio-economic data from the census or parcel-level land use data. The analysis can also take into account projected population, household, or employment growth.

Using socio-economic data, the analysis can be broken down to population, household, income, and employment profiles. Users can also see the distribution of a wide range of individual market variables, including race, gender, age, income, and vehicle ownership. These variables can then be compared to system averages. With land use data, the market area can be broken down by use.

After a market analysis has been performed, TBEST can generate reports in formats such as PDF, Excel, and PowerPoint.

===Title VI Analysis===
All transit agencies are required to comply with [[Transit and Civil Rights|Title VI of the 1964 Civil Rights Act]], which prevents recipients of federal money from discriminating against protected classes<ref>[https://www.transit.dot.gov/regulations-and-guidance/civil-rights-ada/title-vi-civil-rights-act-1964 Federal Transit Administration. "Title VI of the Civil Rights Act of 1964." 2016.]</ref>. This means performing analyses to ensure that service changes are not having disparate impacts on minority populations. TBEST includes a toolset to help automate this process. After inputting Title VI-compliant socio-economic data, the GTFS network, stop amenities, and service area, the software will perform an analysis and output the results in report and map format, as mandated by Title VI. Maps are created in the ArcMap format to facilitate further editing, if necessary. The core purpose of TBEST is scenario planning, and the program makes it easy to compare Title VI analyses for various potential scenarios. TBEST contains tools for performing both system-wide triennial analyses and interim disparate impact analyses on specific changes.

===Transit Access===
TBEST offers two different toolsets measuring transit access: Access to Transit and Access via Transit. Access to Transit measures walk access from homes and jobs to transit, while Access via Transit measures jobs, people, and land use accessible between stop pairs. Like the Title VI analysis, these analyses can be performed automatically after a few variables have been inputted and can be used to compare various scenarios.

==[http://tbest.org/ Transit Boardings Estimation and Simulation Tool]==

==References==
<references />

==Additional Reading==
[http://tbest.org/downloads/?dl_cat=10 TBEST 4.4 User Guide]

: This extremely detailed guide provides illustrated instructions for all of TBEST's many features.

[http://tbest.org/wp-content/files/TDPReviewandReporting_Final_1-19-2012.pdf TBEST - Guidelines for Transit Development Plan Ridership Estimation Review and Reporting]

: This document outlines the way in which TBEST can be used in transportation development plan modeling.

[[Category:GTFS-consuming applications]]
[[Category:Network planning software]]
[[Category:Ridership forecasting]]

Transit Boardings Estimation and Simulation Tool (TBEST)

2017-02-10T01:28:18Z

Aaronantrim: added to Aaron's edit queue

{{edit queue
|editor=Aaron
}}

[[Image:Tbest.jpg|right|thumb|600px|An example of the land use analysis possible within TBEST. Source: [http://tbest.org/wp-content/files/TBEST_TRB_Applications_Conference-_may_2015.pdf Center for Urban Transportation Research]]]
==Introduction==
[http://tbest.org/ Transit Boardings Estimation and Simulation Tool (TBEST)] is a GIS-based transit modeling and analysis program developed for the [http://www.fdot.gov/ Florida Department of Transportation]. It was originally meant to estimate ridership numbers for Florida transit agencies for transportation demand management plans, but has been expanded to be applicable across the country and to assist in processes such as market analysis, bus rapid transit modeling, and Title VI analysis. TBEST requires a licensed copy of ArcGIS and Windows 7 or later, but the software itself is free to use.

==How it Works==
TBEST is based on transit system data. While these templates are provided for Florida agencies, in the rest of the country they must be created manually. This has been done in Los Angeles<ref>[http://tbest.org/download/TBEST41_Overview.pptx Center for Urban Transportation Research. "The TBEST Framework for Data Analysis and Forecasting." 2013.]</ref>. The TBEST team is available to help configure local [[GTFS]] and other data to be inputted into the system. Once the base scenario has been imported, actual ridership data is used to validate the scenario.

After validating the base scenario, TBEST can be used for in-depth scenario planning. A user can create alternative scenarios with new routes, stops, or service levels. These new scenarios can then be compared to the base scenario. These analyses can be done for six different time periods: AM peak, off-peak, PM peak, night, Saturday, and Sunday.

===Market Analysis===
The viability of a transit line is determined in part by the area it serves. To forecast viability, TBEST allows users to perform market analyses on current or potential routes. This can be done either using socio-economic data from the census or parcel-level land use data. The analysis can also take into account projected population, household, or employment growth.

Using socio-economic data, the analysis can be broken down to population, household, income, and employment profiles. Users can also see the distribution of a wide range of individual market variables, including race, gender, age, income, and vehicle ownership. These variables can then be compared to system averages. With land use data, the market area can be broken down by use.

After a market analysis has been performed, TBEST can generate reports in formats such as PDF, Excel, and PowerPoint.

===Title VI Analysis===
All transit agencies are required to comply with [[Transit and Civil Rights|Title VI of the 1964 Civil Rights Act]], which prevents recipients of federal money from discriminating against protected classes<ref>[https://www.transit.dot.gov/regulations-and-guidance/civil-rights-ada/title-vi-civil-rights-act-1964 Federal Transit Administration. "Title VI of the Civil Rights Act of 1964." 2016.]</ref>. This means performing analyses to ensure that service changes are not having disparate impacts on minority populations. TBEST includes a toolset to help automate this process. After inputting Title VI-compliant socio-economic data, the GTFS network, stop amenities, and service area, the software will perform an analysis and output the results in report and map format, as mandated by Title VI. Maps are created in the ArcMap format to facilitate further editing, if necessary. The core purpose of TBEST is scenario planning, and the program makes it easy to compare Title VI analyses for various potential scenarios. TBEST contains tools for performing both system-wide triennial analyses and interim disparate impact analyses on specific changes.

===Transit Access===
TBEST offers two different toolsets measuring transit access: Access to Transit and Access via Transit. Access to Transit measures walk access from homes and jobs to transit, while Access via Transit measures jobs, people, and land use accessible between stop pairs. Like the Title VI analysis, these analyses can be performed automatically after a few variables have been inputted and can be used to compare various scenarios.

==[http://tbest.org/ Transit Boardings Estimation and Simulation Tool]==

==References==
<references />

==Additional Reading==
[http://tbest.org/downloads/?dl_cat=10 TBEST 4.4 User Guide]

: This extremely detailed guide provides illustrated instructions for all of TBEST's many features.

[http://tbest.org/wp-content/files/TDPReviewandReporting_Final_1-19-2012.pdf TBEST - Guidelines for Transit Development Plan Ridership Estimation Review and Reporting]

: This document outlines the way in which TBEST can be used in transportation development plan modeling.

[[Category:GTFS-consuming applications]]
[[Category:Network planning software]]
[[Category:Ridership forecasting]]

STOPS (Simplified Trips-on-Project Software)

2017-02-10T01:27:45Z

Aaronantrim: added to Leeor's edit queue

{{edit queue
|editor=Leeor
}}

"At their option, sponsors of [[New Starts]] and [[Small Starts]] projects may use a simplified method developed by [[FTA]] to quantify the measures used by FTA to evaluate and rate projects. STOPS is a limited implementation of the conventional “4-step” travel model. STOPS replaces the standard “trip generation” and “trip distribution” steps with the Census Transportation Planning Package (CTPP) – tabulations from the 2000 Census (and soon, the American Community Survey) to describe overall travel markets. It also replaces the traditional “coded” transit network with standard transit-services data in the General Transit Feed Specification (GTFS) format."<ref>https://www.transit.dot.gov/funding/grant-programs/capital-investments/stops-%E2%80%93-fta%E2%80%99s-simplified-trips-project-software Accessed 13-November-2016</ref>

More information:
* [https://www.transit.dot.gov/funding/grant-programs/capital-investments/stops-%E2%80%93-fta%E2%80%99s-simplified-trips-project-software STOPS documentation and overview] from the Federal Transit Administration (FTA)
* [http://tfresource.org/STOPS STOPS on the Travel Forecasting Resource wiki]

[[Category:GTFS-consuming applications]]
[[Category:Ridership forecasting]]

Regional Strategic Planning Model (RSPM)

2017-02-10T01:21:40Z

Aaronantrim: minor correction

{{Template:Stub}}

The Regional Strategic Planning Model (RSPM) is a metropolitan version of the (statewide) [[GreenSTEP model]]. See more at the [https://www.oregon.gov/ODOT/TD/OSTI/Pages/scenario_planning.aspx#s2 Oregon Department of Transportation] website.

The RSPM has been implemented in various metropolitan regions, including in:

* [https://github.com/atlregional/RSPM Atlanta]

Regional Strategic Planning Model (RSPM)

2017-02-10T01:21:16Z

Aaronantrim: created page

Greenhouse Gas Strategic Transportation Energy Planning (GreenSTEP)

2017-02-10T01:15:54Z

Aaronantrim: created page

"The GreenSTEP model was developed by the Oregon Department of Transportation (ODOT) to estimate and forecast the long term effects of policies and other influences (e.g. gas prices) on the amount of vehicle travel, the types of vehicles and fuels used, energy consumption for vehicle travel and resulting greenhouse gas (GHG) emissions."<ref>Oregon Department of Transportation https://www.oregon.gov/ODOT/TD/TP/Pages/greenstep.aspx</ref>

The [[Regional Strategic Planning Model (RSPM)]] is an the metropolitan version of the GreenSTEP model, which has been implemented in several regions.

[[Category:Travel models]]

OpenTripPlanner: Analyst Extension

2017-02-10T01:02:43Z

Aaronantrim: added link to Transport Analyst

{{infobox
|title= OTP Analyst
|image= OpenTripPlanner-logo.png
|image_size= 150px
|vendor = [[OpenTripPlanner]]
|license= [[GNU Lesser General Public License]]
|documentation= [http://docs.opentripplanner.org/en/latest/Analyst/ docs.opentripplanner.org/ en/latest/Analyst/]
|website= [http://www.opentripplanner.org/analyst/ http://www.opentripplanner.org/analyst/]
}}

=== Update: Transport Analyst (2017) ===
OpenTripPlanner: Analyst Extension has been superseded by open-source software called [[Transport Analyst]].

=== OpenTripPlanner: Analyst Extension ===
In addition to features for trip planning, [[OpenTripPlanner]] (OTP) includes analysis tools within the core software package. For example, OTP servers can produce travel time graphic representations (i.e., isochrone) map tiles. OTP developers are now building out this framework to support off-line batch computations using large sets of origins and destinations, whose locations and attributes can be loaded from CSV, Shapefile, or raster file formats. Functions applied over the set of origins and destinations can produce cumulative opportunities accessibility measures, which are conceptually similar to an advanced version of Walk Score or Transit Score feature <ref>Jarrett Walker. (2011). "Beyond "transit scores": an exchange with matt lerner." January 24, 2011. Accessed: from http://www.humantransit.org/2011/01/beyond-transit-scores-an-exchange-with-matt-lerner.html</ref>. Therefore, OTP is also usable as a visualization application.

The above-described capabilities are being developed as part of the “Analyst Extension” for OTP. More information on OTP Analyst Extension is available in the OTP Analyst portions of the OpenPlans <ref>OpenPlans. "OpenTripPlanner: Analyst Extension." Accessed August 1, 2012 from http://analyst.opentripplanner.org/</ref> and OpenTripPlanner <ref>Andrew Byrd. (2012). "Visualizing urban accessibility with OpenTripPlanner Analyst." July 2, 2012. Accessed: from http://opentripplanner.com/2012/07/visualizing-urban-accessibility-with-opentripplanner-analyst/</ref> websites.

==References==
[[Category:GTFS-consuming applications]]
[[Category:Network planning software]]
[[Category:Scenario planning tools]]

Category talk:Complex data visualization

2017-02-05T21:19:57Z

Aaronantrim: response RE: subcategorization

===Sub-categorization===
I don't think that this should be categorized under [[:Category:GTFS-consuming applications]] --[[User:Aaronantrim|Aaronantrim]] ([[User talk:Aaronantrim|talk]]) 22:49, 3 February 2017 (MST)
:What guidelines should we establish for when something qualifies as a subcategory of [[:Category:GTFS-consuming applications]] and when it is too separate to qualify? -- [[User:Leeor|Leeor]] ([[User talk:Leeor|talk]]) 20:47, 4 February 2017 (MST)
:Articles can be filed under multiple categories. My thinking is that some/many data visualization applications might well not be GTFS-consuming. --[[User:Aaronantrim|Aaronantrim]] ([[User talk:Aaronantrim|talk]]) 14:19, 5 February 2017 (MST)

Category:Public information displays

2017-02-04T06:04:23Z

Aaronantrim: remove Category:GTFS-consuming applications

Many transit agencies offer information on bus arrival times, service alerts, and other pertinent information on public displays. These applications help translate [[GTFS]] and realtime data onto the display.

Category talk:Complex data visualization

2017-02-04T05:49:39Z

Aaronantrim: don't put under GTFS category

I don't think that this should be categorized under [[:Category:GTFS-consuming applications]] --[[User:Aaronantrim|Aaronantrim]] ([[User talk:Aaronantrim|talk]]) 22:49, 3 February 2017 (MST)

TransitWiki:Bugs

2017-01-08T14:16:29Z

Aaronantrim: noted error for page Page ODOT-sponsored proof of concept: “GTFS Data as a Basis for Optimization of Large Scale Transit Networks”

* Page [[ODOT-sponsored proof of concept: “GTFS Data as a Basis for Optimization of Large Scale Transit Networks”]] currently returns an error - ''Fatal error: Call to a member function getLocalURL() on null in /home/itsuclae/public_html/TransitWiki/TransitWiki/includes/skins/Skin.php on line 1051'' --[[User:Aaronantrim|Aaronantrim]] ([[User talk:Aaronantrim|talk]]) 07:16, 8 January 2017 (MST)