<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://www.transitwiki.org/TransitWiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Leeor</id>
	<title>TransitWiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://www.transitwiki.org/TransitWiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Leeor"/>
	<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php/Special:Contributions/Leeor"/>
	<updated>2026-04-16T14:43:27Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.35.1</generator>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Conveyal_Analysis&amp;diff=4326</id>
		<title>Conveyal Analysis</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Conveyal_Analysis&amp;diff=4326"/>
		<updated>2017-08-31T22:24:12Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
{{infobox&lt;br /&gt;
|title=Conveyal Analysis&lt;br /&gt;
|image=&lt;br /&gt;
|vendor=[[Conveyal]]&lt;br /&gt;
|license=[[The MIT License]]&lt;br /&gt;
|documentation= http://analysis-ui.readthedocs.io/en/latest/&lt;br /&gt;
|data_in= [[GTFS]], [[OpenStreetMap]], ACS/Census, LODES, custom shapefiles&lt;br /&gt;
|data_out= GIS shapefiles, maps, accessibility graphs, GeoTIFF, &lt;br /&gt;
|website= [http://conveyal.com/analyst/ http://conveyal.com/analyst/]&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
Conveyal Analysis integrates transit and land use data to compare current system performance and accessibility with various scenarios. It is an open source tool developed by [[Conveyal]], and can be hosted and run independently or hosted by Conveyal for a fee along with consulting services.&lt;br /&gt;
&lt;br /&gt;
==Accessibility Assessment==&lt;br /&gt;
[[File:Conveyal-jobs-access.png|thumb|Identifying places that see increased access to jobs due to a new transit line. &amp;lt;br&amp;gt;Source: http://conveyal.com/projects/analyst/]]&lt;br /&gt;
&lt;br /&gt;
Conveyal Analysis offers basic statistics of how far or fast a system can carry people but also, by layering information from [[OpenStreetMap]] and census data, it allows planners to view accessibility. It can display job opportunities, businesses, and various amenities that become more accessible to people living near a new planned transit line. Accessibility outcomes offer new opportunities for collaboration between land use and transportation planning. The software can intake multiple alternatives and return graphical prototypes such as stacked percentile plots and isochrones that compare accessibility outcomes for the different scenarios.&lt;br /&gt;
&lt;br /&gt;
Conveyal Analysis measures travel time as multiple iteration within a travel time window. For example, if the time window is set to 7am to 9am, Conveyal will check accessible destinations at 7am, 7:01, 7:02 etc. The number of trips to fit into the time window can be set by the user.&lt;br /&gt;
&lt;br /&gt;
===Single point analysis===&lt;br /&gt;
[[File:Conveyal Isochrone.png|thumb|Two isochrones are shown for a baseline and project scenario, demonstrating travel accessibility in a 45 minute time window &amp;lt;ref&amp;gt;Analysis-Conveyal https://www.conveyal.com/analysis/ Accessed Aug 31 2017&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
[[File:Conveyal-comparison.png|thumb|Shows the stacked percentile curves, indicating access to jobs and reliability for a baseline and scenario case&amp;lt;ref&amp;gt;Analysis-Conveyal https://www.conveyal.com/analysis/ Accessed Aug 31 2017&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
The accessibility outcomes offered by Conveyal Analysis display the total number of a given amenity that can be reached within a given amount of time from a given point or within a region. For point analysis, accessibility can be viewed as an isochrone, showing how far someone could get on a map within a certain travel time budget. The data is also presented as a stacked percentile plot. The curve reveals how many opportunities are available as the median travel time increases or decreases. The stacked percentiles show the extent to which accessible destinations change depending on the time of departure. A wide spread indicates lower reliability, that is, many destinations are only accessible within a travel time budget when leaving at a specified time.&lt;br /&gt;
&lt;br /&gt;
===Regional Analysis===&lt;br /&gt;
[[File:Conveyal-regional.png|thumb|A map showing the relative opportunities to jobs for the Atlanta region &amp;lt;ref&amp;gt;Conveyal analysis Docs http://analysis-ui.readthedocs.io/en/latest/analysis/regional/ Accessed Aug 31 2017&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
Regional analysis calculates all of the accessible connections between households and jobs, or another destination, within the region. These are based on a predetermined time cut-off. By default, the user can choose the median travel time. However, if the user is interested in transportation for shopping trips, which may have more flexible arrival times, or for employment or school, which often have rigid arrival times, the user can choose a certain percentile above or below the median travel time. The results are displayed in on a map with a color scheme based on the number of opportunities at each grid cell.&lt;br /&gt;
&lt;br /&gt;
Conveyal does not use [[TAZ]]s, which are commonly employed, but rather a fine grid, resulting in more granular data quality of accessibility.&lt;br /&gt;
&lt;br /&gt;
===Runtime===&lt;br /&gt;
A single point analysis, showing accessibility from that point to all other points, can be calculated quickly, usually taking 5-15 second. An analysis of an entire region, looking at accessibility from every point to every other point, takes longer. The factors that most affect computation time are the size of the region, the number of points in the region, and the size and density of the transit and transportation network. Furthermore, a scenario analysis is able to use results from the base case and only run the analysis where results will differ. Therefore, more changes in a scenario will lead to longer computational time. An analysis run on a single server can take anywhere from a few hours to a few days depending on the complexity of the system. If the analysis is run on multiple servers, either using [[Conveyal|Conveyal's]] hosting service or through other access to cluster computing, the runtime can be reduced to a few minutes to a few hours.&lt;br /&gt;
&lt;br /&gt;
==Scenario Creation==&lt;br /&gt;
[[File:Analyst-scenario-editor.png|thumb|Modeling a new transit line using the scenario editor. &amp;lt;br&amp;gt;Source: http://conveyal.com/projects/analyst/]]&lt;br /&gt;
Different scenarios can be generated a number of different ways. Future scenarios can be generated by importing foretasted demographic and jobs data as custom shapefiles. These are usually derived from regional or state forecast models. Scenarios can also be generated by importing custom demographic, jobs, or point destination data that represent the predicted result of a land use change or of a new development. Furthermore, scenarios can represent changes or additions to the transit system, generated through edited [[GTFS]] files or by using [[conveyal|Conveyal's]] scenario editing tool. If a new potential transit line only has a route planned, the scenario editor can add stops according to a set spacing. These can be moved to represent more likely stop location, say at large intersections or transit centers. Multiple scenarios can be generated and run simultaneously to offer an accessibility and performance comparison analysis.&lt;br /&gt;
&lt;br /&gt;
==Other Features==&lt;br /&gt;
===Public Outreach===&lt;br /&gt;
Analyst can be run on a web interface that allows for public outreach and consultation. The map allows users to see the impact alternative scenarios would have on them and to make recommendations as a result. It can output maps in [[GIS]] format for integration into publications and reports. &lt;br /&gt;
&lt;br /&gt;
===Walk time===&lt;br /&gt;
Travel time calculations incorporate pedestrian travel time, using the street network to account for how long it takes to walk to and from the bus station. [[Conveyal]] is currently developing other multimodal access calculations, such and biking and driving, so that bikes on transit, bikeshare, and park-and-ride can be better accounted for. Walk time is calculated using the pedestrian street network available through [[OpenStreetMap]], however a direct street network editor is in development.&lt;br /&gt;
&lt;br /&gt;
===Title VI and Equity===&lt;br /&gt;
Using demographic data from census inputs, Analyst can preform equity analyses and reveal disparate impacts that a given scenario might create. This analysis aides transit agencies to ensure projects comply with [[Transit and Civil Rights| Title VI]] in the US, and supports agencies in determining how projects align with their own internal equity goals.&lt;br /&gt;
&lt;br /&gt;
==Open-source==&lt;br /&gt;
[[Conveyal| Conveyal's]] commitment to open data and open-source has led them to use open data for all of Transport Analyst's inputs, such as publicly available [[GTFS]] feeds, map data from [[OpenStreetMap]], and census data. The components for Analyst are themselves open source, licensed under the [[Apache 2]] license.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Category:GTFS-consuming applications]]&lt;br /&gt;
[[Category: Scenario planning tools]]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Conveyal_Analysis&amp;diff=4325</id>
		<title>Conveyal Analysis</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Conveyal_Analysis&amp;diff=4325"/>
		<updated>2017-08-31T22:22:22Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
{{infobox&lt;br /&gt;
|title=Conveyal Analysis&lt;br /&gt;
|image=&lt;br /&gt;
|vendor=[[Conveyal]]&lt;br /&gt;
|license=[[The MIT License]]&lt;br /&gt;
|documentation= http://analysis-ui.readthedocs.io/en/latest/&lt;br /&gt;
|data_in= [[GTFS]], [[OpenStreetMap]], ACS/Census, LODES, custom shapefiles&lt;br /&gt;
|data_out= GIS shapefiles, maps, accessibility graphs, GeoTIFF, &lt;br /&gt;
|website= [http://conveyal.com/analyst/ http://conveyal.com/analyst/]&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
Conveyal Analysis integrates transit and land use data to compare current system performance and accessibility with various scenarios. It is an open source tool developed by [[Conveyal]], and can be hosted and run independently or hosted by Conveyal for a fee along with consulting services.&lt;br /&gt;
&lt;br /&gt;
==Accessibility Assessment==&lt;br /&gt;
[[File:Conveyal-jobs-access.png|thumb|Identifying places that see increased access to jobs due to a new transit line. &amp;lt;br&amp;gt;Source: http://conveyal.com/projects/analyst/]]&lt;br /&gt;
&lt;br /&gt;
Conveyal Analysis offers basic statistics of how far or fast a system can carry people but also, by layering information from [[OpenStreetMap]] and census data, it allows planners to view accessibility. It can display job opportunities, businesses, and various amenities that become more accessible to people living near a new planned transit line. Accessibility outcomes offer new opportunities for collaboration between land use and transportation planning. The software can intake multiple alternatives and return graphical prototypes such as stacked percentile plots and isochrones that compare accessibility outcomes for the different scenarios.&lt;br /&gt;
&lt;br /&gt;
Conveyal Analysis measures travel time as multiple iteration within a travel time window. For example, if the time window is set to 7am to 9am, Conveyal will check accessible destinations at 7am, 7:01, 7:02 etc. The number of trips to fit into the time window can be set by the user.&lt;br /&gt;
&lt;br /&gt;
===Single point analysis===&lt;br /&gt;
[[File:Conveyal isochrone.png|thumb|Two isochrones are shown for a baseline and project scenario, demonstrating travel accessibility in a 45 minute time window &amp;lt;ref&amp;gt;Analysis-Conveyal https://www.conveyal.com/analysis/ Accessed Aug 31 2017&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
[[File:Conveyal-comparison.png|thumb|Shows the stacked percentile curves, indicating access to jobs and reliability for a baseline and scenario case&amp;lt;ref&amp;gt;Analysis-Conveyal https://www.conveyal.com/analysis/ Accessed Aug 31 2017&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
The accessibility outcomes offered by Conveyal Analysis display the total number of a given amenity that can be reached within a given amount of time from a given point or within a region. For point analysis, accessibility can be viewed as an isochrone, showing how far someone could get on a map within a certain travel time budget. The data is also presented as a stacked percentile plot. The curve reveals how many opportunities are available as the median travel time increases or decreases. The stacked percentiles show the extent to which accessible destinations change depending on the time of departure. A wide spread indicates lower reliability, that is, many destinations are only accessible within a travel time budget when leaving at a specified time.&lt;br /&gt;
&lt;br /&gt;
===Regional Analysis===&lt;br /&gt;
[[File:Conveyal-regional.png|thumb|A map showing the relative opportunities to jobs for the Atlanta region &amp;lt;ref&amp;gt;Conveyal analysis Docs http://analysis-ui.readthedocs.io/en/latest/analysis/regional/ Accessed Aug 31 2017&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
Regional analysis calculates all of the accessible connections between households and jobs, or another destination, within the region. These are based on a predetermined time cut-off. By default, the user can choose the median travel time. However, if the user is interested in transportation for shopping trips, which may have more flexible arrival times, or for employment or school, which often have rigid arrival times, the user can choose a certain percentile above or below the median travel time. The results are displayed in on a map with a color scheme based on the number of opportunities at each grid cell.&lt;br /&gt;
&lt;br /&gt;
Conveyal does not use [[TAZ]]s, which are commonly employed, but rather a fine grid, resulting in more granular data quality of accessibility.&lt;br /&gt;
&lt;br /&gt;
===Runtime===&lt;br /&gt;
A single point analysis, showing accessibility from that point to all other points, can be calculated quickly, usually taking 5-15 second. An analysis of an entire region, looking at accessibility from every point to every other point, takes longer. The factors that most affect computation time are the size of the region, the number of points in the region, and the size and density of the transit and transportation network. Furthermore, a scenario analysis is able to use results from the base case and only run the analysis where results will differ. Therefore, more changes in a scenario will lead to longer computational time. An analysis run on a single server can take anywhere from a few hours to a few days depending on the complexity of the system. If the analysis is run on multiple servers, either using [[Conveyal|Conveyal's]] hosting service or through other access to cluster computing, the runtime can be reduced to a few minutes to a few hours.&lt;br /&gt;
&lt;br /&gt;
==Scenario Creation==&lt;br /&gt;
[[File:Analyst-scenario-editor.png|thumb|Modeling a new transit line using the scenario editor. &amp;lt;br&amp;gt;Source: http://conveyal.com/projects/analyst/]]&lt;br /&gt;
Different scenarios can be generated a number of different ways. Future scenarios can be generated by importing foretasted demographic and jobs data as custom shapefiles. These are usually derived from regional or state forecast models. Scenarios can also be generated by importing custom demographic, jobs, or point destination data that represent the predicted result of a land use change or of a new development. Furthermore, scenarios can represent changes or additions to the transit system, generated through edited [[GTFS]] files or by using [[conveyal|Conveyal's]] scenario editing tool. If a new potential transit line only has a route planned, the scenario editor can add stops according to a set spacing. These can be moved to represent more likely stop location, say at large intersections or transit centers. Multiple scenarios can be generated and run simultaneously to offer an accessibility and performance comparison analysis.&lt;br /&gt;
&lt;br /&gt;
==Other Features==&lt;br /&gt;
===Public Outreach===&lt;br /&gt;
Analyst can be run on a web interface that allows for public outreach and consultation. The map allows users to see the impact alternative scenarios would have on them and to make recommendations as a result. It can output maps in [[GIS]] format for integration into publications and reports. &lt;br /&gt;
&lt;br /&gt;
===Walk time===&lt;br /&gt;
Travel time calculations incorporate pedestrian travel time, using the street network to account for how long it takes to walk to and from the bus station. [[Conveyal]] is currently developing other multimodal access calculations, such and biking and driving, so that bikes on transit, bikeshare, and park-and-ride can be better accounted for. Walk time is calculated using the pedestrian street network available through [[OpenStreetMap]], however a direct street network editor is in development.&lt;br /&gt;
&lt;br /&gt;
===Title VI and Equity===&lt;br /&gt;
Using demographic data from census inputs, Analyst can preform equity analyses and reveal disparate impacts that a given scenario might create. This analysis aides transit agencies to ensure projects comply with [[Transit and Civil Rights| Title VI]] in the US, and supports agencies in determining how projects align with their own internal equity goals.&lt;br /&gt;
&lt;br /&gt;
==Open-source==&lt;br /&gt;
[[Conveyal| Conveyal's]] commitment to open data and open-source has led them to use open data for all of Transport Analyst's inputs, such as publicly available [[GTFS]] feeds, map data from [[OpenStreetMap]], and census data. The components for Analyst are themselves open source, licensed under the [[Apache 2]] license.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Category:GTFS-consuming applications]]&lt;br /&gt;
[[Category: Scenario planning tools]]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Conveyal_Analysis&amp;diff=4324</id>
		<title>Conveyal Analysis</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Conveyal_Analysis&amp;diff=4324"/>
		<updated>2017-08-31T22:22:02Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
{{infobox&lt;br /&gt;
|title=Conveyal Analysis&lt;br /&gt;
|image=&lt;br /&gt;
|vendor=[[Conveyal]]&lt;br /&gt;
|license=[[The MIT License]]&lt;br /&gt;
|documentation= http://analysis-ui.readthedocs.io/en/latest/&lt;br /&gt;
|data_in= [[GTFS]], [[OpenStreetMap]], ACS/Census, LODES, custom shapefiles&lt;br /&gt;
|data_out= GIS shapefiles, maps, accessibility graphs, GeoTIFF, &lt;br /&gt;
|website= [http://conveyal.com/analyst/ http://conveyal.com/analyst/]&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
Conveyal Analysis integrates transit and land use data to compare current system performance and accessibility with various scenarios. It is an open source tool developed by [[Conveyal]], and can be hosted and run independently or hosted by Conveyal for a fee along with consulting services.&lt;br /&gt;
&lt;br /&gt;
==Accessibility Assessment==&lt;br /&gt;
[[File:Conveyal-jobs-access.png|thumb|Identifying places that see increased access to jobs due to a new transit line. &amp;lt;br&amp;gt;Source: http://conveyal.com/projects/analyst/]]&lt;br /&gt;
&lt;br /&gt;
Conveyal Analysis offers basic statistics of how far or fast a system can carry people but also, by layering information from [[OpenStreetMap]] and census data, it allows planners to view accessibility. It can display job opportunities, businesses, and various amenities that become more accessible to people living near a new planned transit line. Accessibility outcomes offer new opportunities for collaboration between land use and transportation planning. The software can intake multiple alternatives and return graphical prototypes such as stacked percentile plots and isochrones that compare accessibility outcomes for the different scenarios.&lt;br /&gt;
&lt;br /&gt;
Conveyal Analysis measures travel time as multiple iteration within a travel time window. For example, if the time window is set to 7am to 9am, Conveyal will check accessible destinations at 7am, 7:01, 7:02 etc. The number of trips to fit into the time window can be set by the user.&lt;br /&gt;
&lt;br /&gt;
===Single point analysis===&lt;br /&gt;
[[File:Conveyal isochrone|thumb|Two isochrones are shown for a baseline and project scenario, demonstrating travel accessibility in a 45 minute time window &amp;lt;ref&amp;gt;Analysis-Conveyal https://www.conveyal.com/analysis/ Accessed Aug 31 2017&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
[[File:Conveyal-comparison.png|thumb|Shows the stacked percentile curves, indicating access to jobs and reliability for a baseline and scenario case&amp;lt;ref&amp;gt;Analysis-Conveyal https://www.conveyal.com/analysis/ Accessed Aug 31 2017&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
The accessibility outcomes offered by Conveyal Analysis display the total number of a given amenity that can be reached within a given amount of time from a given point or within a region. For point analysis, accessibility can be viewed as an isochrone, showing how far someone could get on a map within a certain travel time budget. The data is also presented as a stacked percentile plot. The curve reveals how many opportunities are available as the median travel time increases or decreases. The stacked percentiles show the extent to which accessible destinations change depending on the time of departure. A wide spread indicates lower reliability, that is, many destinations are only accessible within a travel time budget when leaving at a specified time.&lt;br /&gt;
&lt;br /&gt;
===Regional Analysis===&lt;br /&gt;
[[File:Conveyal-regional.png|thumb|A map showing the relative opportunities to jobs for the Atlanta region &amp;lt;ref&amp;gt;Conveyal analysis Docs http://analysis-ui.readthedocs.io/en/latest/analysis/regional/ Accessed Aug 31 2017&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
Regional analysis calculates all of the accessible connections between households and jobs, or another destination, within the region. These are based on a predetermined time cut-off. By default, the user can choose the median travel time. However, if the user is interested in transportation for shopping trips, which may have more flexible arrival times, or for employment or school, which often have rigid arrival times, the user can choose a certain percentile above or below the median travel time. The results are displayed in on a map with a color scheme based on the number of opportunities at each grid cell.&lt;br /&gt;
&lt;br /&gt;
Conveyal does not use [[TAZ]]s, which are commonly employed, but rather a fine grid, resulting in more granular data quality of accessibility.&lt;br /&gt;
&lt;br /&gt;
===Runtime===&lt;br /&gt;
A single point analysis, showing accessibility from that point to all other points, can be calculated quickly, usually taking 5-15 second. An analysis of an entire region, looking at accessibility from every point to every other point, takes longer. The factors that most affect computation time are the size of the region, the number of points in the region, and the size and density of the transit and transportation network. Furthermore, a scenario analysis is able to use results from the base case and only run the analysis where results will differ. Therefore, more changes in a scenario will lead to longer computational time. An analysis run on a single server can take anywhere from a few hours to a few days depending on the complexity of the system. If the analysis is run on multiple servers, either using [[Conveyal|Conveyal's]] hosting service or through other access to cluster computing, the runtime can be reduced to a few minutes to a few hours.&lt;br /&gt;
&lt;br /&gt;
==Scenario Creation==&lt;br /&gt;
[[File:Analyst-scenario-editor.png|thumb|Modeling a new transit line using the scenario editor. &amp;lt;br&amp;gt;Source: http://conveyal.com/projects/analyst/]]&lt;br /&gt;
Different scenarios can be generated a number of different ways. Future scenarios can be generated by importing foretasted demographic and jobs data as custom shapefiles. These are usually derived from regional or state forecast models. Scenarios can also be generated by importing custom demographic, jobs, or point destination data that represent the predicted result of a land use change or of a new development. Furthermore, scenarios can represent changes or additions to the transit system, generated through edited [[GTFS]] files or by using [[conveyal|Conveyal's]] scenario editing tool. If a new potential transit line only has a route planned, the scenario editor can add stops according to a set spacing. These can be moved to represent more likely stop location, say at large intersections or transit centers. Multiple scenarios can be generated and run simultaneously to offer an accessibility and performance comparison analysis.&lt;br /&gt;
&lt;br /&gt;
==Other Features==&lt;br /&gt;
===Public Outreach===&lt;br /&gt;
Analyst can be run on a web interface that allows for public outreach and consultation. The map allows users to see the impact alternative scenarios would have on them and to make recommendations as a result. It can output maps in [[GIS]] format for integration into publications and reports. &lt;br /&gt;
&lt;br /&gt;
===Walk time===&lt;br /&gt;
Travel time calculations incorporate pedestrian travel time, using the street network to account for how long it takes to walk to and from the bus station. [[Conveyal]] is currently developing other multimodal access calculations, such and biking and driving, so that bikes on transit, bikeshare, and park-and-ride can be better accounted for. Walk time is calculated using the pedestrian street network available through [[OpenStreetMap]], however a direct street network editor is in development.&lt;br /&gt;
&lt;br /&gt;
===Title VI and Equity===&lt;br /&gt;
Using demographic data from census inputs, Analyst can preform equity analyses and reveal disparate impacts that a given scenario might create. This analysis aides transit agencies to ensure projects comply with [[Transit and Civil Rights| Title VI]] in the US, and supports agencies in determining how projects align with their own internal equity goals.&lt;br /&gt;
&lt;br /&gt;
==Open-source==&lt;br /&gt;
[[Conveyal| Conveyal's]] commitment to open data and open-source has led them to use open data for all of Transport Analyst's inputs, such as publicly available [[GTFS]] feeds, map data from [[OpenStreetMap]], and census data. The components for Analyst are themselves open source, licensed under the [[Apache 2]] license.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Category:GTFS-consuming applications]]&lt;br /&gt;
[[Category: Scenario planning tools]]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Conveyal_Analysis&amp;diff=4323</id>
		<title>Conveyal Analysis</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Conveyal_Analysis&amp;diff=4323"/>
		<updated>2017-08-31T22:20:45Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
{{infobox&lt;br /&gt;
|title=Conveyal Analysis&lt;br /&gt;
|image=&lt;br /&gt;
|vendor=[[Conveyal]]&lt;br /&gt;
|license=[[The MIT License]]&lt;br /&gt;
|documentation= http://analysis-ui.readthedocs.io/en/latest/&lt;br /&gt;
|data_in= [[GTFS]], [[OpenStreetMap]], ACS/Census, LODES, custom shapefiles&lt;br /&gt;
|data_out= GIS shapefiles, maps, accessibility graphs, GeoTIFF, &lt;br /&gt;
|website= [http://conveyal.com/analyst/ http://conveyal.com/analyst/]&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
Conveyal Analysis integrates transit and land use data to compare current system performance and accessibility with various scenarios. It is an open source tool developed by [[Conveyal]], and can be hosted and run independently or hosted by Conveyal for a fee along with consulting services.&lt;br /&gt;
&lt;br /&gt;
==Accessibility Assessment==&lt;br /&gt;
[[File:Conveyal-jobs-access.png|thumb|Identifying places that see increased access to jobs due to a new transit line. &amp;lt;br&amp;gt;Source: http://conveyal.com/projects/analyst/]]&lt;br /&gt;
&lt;br /&gt;
Conveyal Analysis offers basic statistics of how far or fast a system can carry people but also, by layering information from [[OpenStreetMap]] and census data, it allows planners to view accessibility. It can display job opportunities, businesses, and various amenities that become more accessible to people living near a new planned transit line. Accessibility outcomes offer new opportunities for collaboration between land use and transportation planning. The software can intake multiple alternatives and return graphical prototypes such as stacked percentile plots and isochrones that compare accessibility outcomes for the different scenarios.&lt;br /&gt;
&lt;br /&gt;
Conveyal Analysis measures travel time as multiple iteration within a travel time window. For example, if the time window is set to 7am to 9am, Conveyal will check accessible destinations at 7am, 7:01, 7:02 etc. The number of trips to fit into the time window can be set by the user.&lt;br /&gt;
&lt;br /&gt;
===Single point analysis===&lt;br /&gt;
[[File:Conveyal-isochrone.png|thumb|Two isochrones are shown for a baseline and project scenario, demonstrating travel accessibility in a 45 minute time window &amp;lt;ref&amp;gt;Analysis-Conveyal https://www.conveyal.com/analysis/ Accessed Aug 31 2017&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
[[File:Conveyal-comparison.png|thumb|Shows the stacked percentile curves, indicating access to jobs and reliability for a baseline and scenario case&amp;lt;ref&amp;gt;Analysis-Conveyal https://www.conveyal.com/analysis/ Accessed Aug 31 2017&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
The accessibility outcomes offered by Conveyal Analysis display the total number of a given amenity that can be reached within a given amount of time from a given point or within a region. For point analysis, accessibility can be viewed as an isochrone, showing how far someone could get on a map within a certain travel time budget. The data is also presented as a stacked percentile plot. The curve reveals how many opportunities are available as the median travel time increases or decreases. The stacked percentiles show the extent to which accessible destinations change depending on the time of departure. A wide spread indicates lower reliability, that is, many destinations are only accessible within a travel time budget when leaving at a specified time.&lt;br /&gt;
&lt;br /&gt;
===Regional Analysis===&lt;br /&gt;
[[File:Conveyal-regional.png|thumb|A map showing the relative opportunities to jobs for the Atlanta region &amp;lt;ref&amp;gt;Conveyal analysis Docs http://analysis-ui.readthedocs.io/en/latest/analysis/regional/ Accessed Aug 31 2017&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
Regional analysis calculates all of the accessible connections between households and jobs, or another destination, within the region. These are based on a predetermined time cut-off. By default, the user can choose the median travel time. However, if the user is interested in transportation for shopping trips, which may have more flexible arrival times, or for employment or school, which often have rigid arrival times, the user can choose a certain percentile above or below the median travel time. The results are displayed in on a map with a color scheme based on the number of opportunities at each grid cell.&lt;br /&gt;
&lt;br /&gt;
Conveyal does not use [[TAZ]]s, which are commonly employed, but rather a fine grid, resulting in more granular data quality of accessibility.&lt;br /&gt;
&lt;br /&gt;
===Runtime===&lt;br /&gt;
A single point analysis, showing accessibility from that point to all other points, can be calculated quickly, usually taking 5-15 second. An analysis of an entire region, looking at accessibility from every point to every other point, takes longer. The factors that most affect computation time are the size of the region, the number of points in the region, and the size and density of the transit and transportation network. Furthermore, a scenario analysis is able to use results from the base case and only run the analysis where results will differ. Therefore, more changes in a scenario will lead to longer computational time. An analysis run on a single server can take anywhere from a few hours to a few days depending on the complexity of the system. If the analysis is run on multiple servers, either using [[Conveyal|Conveyal's]] hosting service or through other access to cluster computing, the runtime can be reduced to a few minutes to a few hours.&lt;br /&gt;
&lt;br /&gt;
==Scenario Creation==&lt;br /&gt;
[[File:Analyst-scenario-editor.png|thumb|Modeling a new transit line using the scenario editor. &amp;lt;br&amp;gt;Source: http://conveyal.com/projects/analyst/]]&lt;br /&gt;
Different scenarios can be generated a number of different ways. Future scenarios can be generated by importing foretasted demographic and jobs data as custom shapefiles. These are usually derived from regional or state forecast models. Scenarios can also be generated by importing custom demographic, jobs, or point destination data that represent the predicted result of a land use change or of a new development. Furthermore, scenarios can represent changes or additions to the transit system, generated through edited [[GTFS]] files or by using [[conveyal|Conveyal's]] scenario editing tool. If a new potential transit line only has a route planned, the scenario editor can add stops according to a set spacing. These can be moved to represent more likely stop location, say at large intersections or transit centers. Multiple scenarios can be generated and run simultaneously to offer an accessibility and performance comparison analysis.&lt;br /&gt;
&lt;br /&gt;
==Other Features==&lt;br /&gt;
===Public Outreach===&lt;br /&gt;
Analyst can be run on a web interface that allows for public outreach and consultation. The map allows users to see the impact alternative scenarios would have on them and to make recommendations as a result. It can output maps in [[GIS]] format for integration into publications and reports. &lt;br /&gt;
&lt;br /&gt;
===Walk time===&lt;br /&gt;
Travel time calculations incorporate pedestrian travel time, using the street network to account for how long it takes to walk to and from the bus station. [[Conveyal]] is currently developing other multimodal access calculations, such and biking and driving, so that bikes on transit, bikeshare, and park-and-ride can be better accounted for. Walk time is calculated using the pedestrian street network available through [[OpenStreetMap]], however a direct street network editor is in development.&lt;br /&gt;
&lt;br /&gt;
===Title VI and Equity===&lt;br /&gt;
Using demographic data from census inputs, Analyst can preform equity analyses and reveal disparate impacts that a given scenario might create. This analysis aides transit agencies to ensure projects comply with [[Transit and Civil Rights| Title VI]] in the US, and supports agencies in determining how projects align with their own internal equity goals.&lt;br /&gt;
&lt;br /&gt;
==Open-source==&lt;br /&gt;
[[Conveyal| Conveyal's]] commitment to open data and open-source has led them to use open data for all of Transport Analyst's inputs, such as publicly available [[GTFS]] feeds, map data from [[OpenStreetMap]], and census data. The components for Analyst are themselves open source, licensed under the [[Apache 2]] license.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Category:GTFS-consuming applications]]&lt;br /&gt;
[[Category: Scenario planning tools]]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Conveyal_Analysis&amp;diff=4322</id>
		<title>Conveyal Analysis</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Conveyal_Analysis&amp;diff=4322"/>
		<updated>2017-08-31T22:19:46Z</updated>

		<summary type="html">&lt;p&gt;Leeor: edits for update to Conveyal Analysis&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
{{infobox&lt;br /&gt;
|title=Conveyal Analysis&lt;br /&gt;
|image=&lt;br /&gt;
|vendor=[[Conveyal]]&lt;br /&gt;
|license=[[The MIT License]]&lt;br /&gt;
|documentation= http://analysis-ui.readthedocs.io/en/latest/&lt;br /&gt;
|data_in= [[GTFS]], [[OpenStreetMap]], ACS/Census, LODES, custom shapefiles&lt;br /&gt;
|data_out= GIS shapefiles, maps, accessibility graphs, GeoTIFF, &lt;br /&gt;
|website= [http://conveyal.com/analyst/ http://conveyal.com/analyst/]&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
Conveyal Analysis integrates transit and land use data to compare current system performance and accessibility with various scenarios. It is an open source tool developed by [[Conveyal]], and can be hosted and run independently or hosted by Conveyal for a fee along with consulting services.&lt;br /&gt;
&lt;br /&gt;
==Accessibility Assessment==&lt;br /&gt;
[[File:Conveyal-jobs-access.png|thumb|Identifying places that see increased access to jobs due to a new transit line. &amp;lt;br&amp;gt;Source: http://conveyal.com/projects/analyst/]]&lt;br /&gt;
&lt;br /&gt;
Conveyal Analysis offers basic statistics of how far or fast a system can carry people but also, by layering information from [[OpenStreetMap]] and census data, it allows planners to view accessibility. It can display job opportunities, businesses, and various amenities that become more accessible to people living near a new planned transit line. Accessibility outcomes offer new opportunities for collaboration between land use and transportation planning. The software can intake multiple alternatives and return graphical prototypes such as stacked percentile plots and isochrones that compare accessibility outcomes for the different scenarios.&lt;br /&gt;
&lt;br /&gt;
Conveyal Analysis measures travel time as multiple iteration within a travel time window. For example, if the time window is set to 7am to 9am, Conveyal will check accessible destinations at 7am, 7:01, 7:02 etc. The number of trips to fit into the time window can be set by the user.&lt;br /&gt;
&lt;br /&gt;
===Single point analysis===&lt;br /&gt;
[[File:Conveyal-isochrone.png|thumb|Two isochrones are shown for a baseline and project scenario, demonstrating travel accessibility in a 45 minute time window &amp;lt;ref&amp;gt;Analysis-Conveyal https://www.conveyal.com/analysis/ Accessed Aug 31 2017&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
[[File:Conveyal-comparison.png|thumb|Shows the stacked percentile curves, indicating access to jobs and reliability for a baseline and scenario case&amp;lt;ref&amp;gt;Analysis-Conveyal https://www.conveyal.com/analysis/ Accessed Aug 31 2017&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
The accessibility outcomes offered by Conveyal Analysis display the total number of a given amenity that can be reached within a given amount of time from a given point or within a region. For point analysis, accessibility can be viewed as an isochrone, showing how far someone could get on a map within a certain travel time budget. The data is also presented as a stacked percentile plot. The curve reveals how many opportunities are available as the median travel time increases or decreases. The stacked percentiles show the extent to which accessible destinations change depending on the time of departure. A wide spread indicates lower reliability, that is, many destinations are only accessible within a travel time budget when leaving at a specified time.&lt;br /&gt;
&lt;br /&gt;
===Regional Analysis===&lt;br /&gt;
[[File:Conveyal-regional|thumb|A map showing the relative opportunities to jobs for the Atlanta region &amp;lt;ref&amp;gt;Conveyal analysis Docs http://analysis-ui.readthedocs.io/en/latest/analysis/regional/ Accessed Aug 31 2017&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
Regional analysis calculates all of the accessible connections between households and jobs, or another destination, within the region. These are based on a predetermined time cut-off. By default, the user can choose the median travel time. However, if the user is interested in transportation for shopping trips, which may have more flexible arrival times, or for employment or school, which often have rigid arrival times, the user can choose a certain percentile above or below the median travel time. The results are displayed in on a map with a color scheme based on the number of opportunities at each grid cell.&lt;br /&gt;
&lt;br /&gt;
Conveyal does not use [[TAZ]]s, which are commonly employed, but rather a fine grid, resulting in more granular data quality of accessibility.&lt;br /&gt;
&lt;br /&gt;
===Runtime===&lt;br /&gt;
A single point analysis, showing accessibility from that point to all other points, can be calculated quickly, usually taking 5-15 second. An analysis of an entire region, looking at accessibility from every point to every other point, takes longer. The factors that most affect computation time are the size of the region, the number of points in the region, and the size and density of the transit and transportation network. Furthermore, a scenario analysis is able to use results from the base case and only run the analysis where results will differ. Therefore, more changes in a scenario will lead to longer computational time. An analysis run on a single server can take anywhere from a few hours to a few days depending on the complexity of the system. If the analysis is run on multiple servers, either using [[Conveyal|Conveyal's]] hosting service or through other access to cluster computing, the runtime can be reduced to a few minutes to a few hours.&lt;br /&gt;
&lt;br /&gt;
==Scenario Creation==&lt;br /&gt;
[[File:Analyst-scenario-editor.png|thumb|Modeling a new transit line using the scenario editor. &amp;lt;br&amp;gt;Source: http://conveyal.com/projects/analyst/]]&lt;br /&gt;
Different scenarios can be generated a number of different ways. Future scenarios can be generated by importing foretasted demographic and jobs data as custom shapefiles. These are usually derived from regional or state forecast models. Scenarios can also be generated by importing custom demographic, jobs, or point destination data that represent the predicted result of a land use change or of a new development. Furthermore, scenarios can represent changes or additions to the transit system, generated through edited [[GTFS]] files or by using [[conveyal|Conveyal's]] scenario editing tool. If a new potential transit line only has a route planned, the scenario editor can add stops according to a set spacing. These can be moved to represent more likely stop location, say at large intersections or transit centers. Multiple scenarios can be generated and run simultaneously to offer an accessibility and performance comparison analysis.&lt;br /&gt;
&lt;br /&gt;
==Other Features==&lt;br /&gt;
===Public Outreach===&lt;br /&gt;
Analyst can be run on a web interface that allows for public outreach and consultation. The map allows users to see the impact alternative scenarios would have on them and to make recommendations as a result. It can output maps in [[GIS]] format for integration into publications and reports. &lt;br /&gt;
&lt;br /&gt;
===Walk time===&lt;br /&gt;
Travel time calculations incorporate pedestrian travel time, using the street network to account for how long it takes to walk to and from the bus station. [[Conveyal]] is currently developing other multimodal access calculations, such and biking and driving, so that bikes on transit, bikeshare, and park-and-ride can be better accounted for. Walk time is calculated using the pedestrian street network available through [[OpenStreetMap]], however a direct street network editor is in development.&lt;br /&gt;
&lt;br /&gt;
===Title VI and Equity===&lt;br /&gt;
Using demographic data from census inputs, Analyst can preform equity analyses and reveal disparate impacts that a given scenario might create. This analysis aides transit agencies to ensure projects comply with [[Transit and Civil Rights| Title VI]] in the US, and supports agencies in determining how projects align with their own internal equity goals.&lt;br /&gt;
&lt;br /&gt;
==Open-source==&lt;br /&gt;
[[Conveyal| Conveyal's]] commitment to open data and open-source has led them to use open data for all of Transport Analyst's inputs, such as publicly available [[GTFS]] feeds, map data from [[OpenStreetMap]], and census data. The components for Analyst are themselves open source, licensed under the [[Apache 2]] license.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Category:GTFS-consuming applications]]&lt;br /&gt;
[[Category: Scenario planning tools]]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=File:Conveyal-regional.png&amp;diff=4321</id>
		<title>File:Conveyal-regional.png</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=File:Conveyal-regional.png&amp;diff=4321"/>
		<updated>2017-08-31T22:16:47Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;regional analysis in conveyal&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=File:Conveyal-comparison.png&amp;diff=4320</id>
		<title>File:Conveyal-comparison.png</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=File:Conveyal-comparison.png&amp;diff=4320"/>
		<updated>2017-08-31T21:25:39Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Comparison between stacked percentile curves&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=File:Conveyal_Isochrone.png&amp;diff=4319</id>
		<title>File:Conveyal Isochrone.png</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=File:Conveyal_Isochrone.png&amp;diff=4319"/>
		<updated>2017-08-31T21:22:43Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;comparative isochrones for baseline and a scenario&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Conveyal&amp;diff=4318</id>
		<title>Conveyal</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Conveyal&amp;diff=4318"/>
		<updated>2017-08-31T21:08:29Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox&lt;br /&gt;
|title=Conveyal&lt;br /&gt;
|image= conveyal-logo.png&lt;br /&gt;
|image_size= 120px&lt;br /&gt;
|website= [http://conveyal.com/ http://conveyal.com/]&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
Conveyal is a consultancy specializing in the transport sector. their primary contribution is in offering services that help analyze, manage, and use open data and open source technology. Conveyal works with governments, transport agencies, and with non-governmental agencies on implementation strategies for various transportation technology options, In their work they attempt to promote sustainable transportation modes and existing technology infrastructure. End user experience is put at the forefront.&lt;br /&gt;
&lt;br /&gt;
Conveyal offers expertise in urban planning, open governance, and information technology, and as well as experience in developing and applying data collection, management, analysis, and visualization tools focused on transport users.&lt;br /&gt;
__TOC__&lt;br /&gt;
==Software Development==&lt;br /&gt;
Conveyal creates some software but does not place software development at the center of its work. You can find some of their projects on [https://github.com/conveyal Conveyal GitHub]. Some tools developed by or in partnership with Conveyal include:&lt;br /&gt;
*[[Conveyal Analysis]] - Transit system accessibility analysis&lt;br /&gt;
*[[Modeify]] - multimodal transportation information&lt;br /&gt;
*[[GTFS Editor]] - editing and creating transit data using [[GTFS]]&lt;br /&gt;
*[[GTFS Manager]] - manage [[GTFS]] feeds&lt;br /&gt;
*[[OpenTraffic]] - collecting and offering free and open source traffic speed data&lt;br /&gt;
*[[Scenario Editor]]&lt;br /&gt;
&lt;br /&gt;
==Example Cases==&lt;br /&gt;
*Conveyal partnered with Arlington to develop [[CarFreeAtoZ]], a multimodal trip planner for the region.&amp;lt;ref&amp;gt;Jaffe, Eric. &amp;quot;Car-Free Commuting Just Got a Whole Lot Easier in D.C.&amp;quot; CityLab, 2015. http://www.citylab.com/cityfixer/2015/05/car-free-commuting-just-got-a-whole-lot-easier-in-dc/393875/ Accessed 5 February 2017&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==External Links==&lt;br /&gt;
*Conveyal GitHub Repository [https://github.com/conveyal https://github.com/conveyal]&lt;br /&gt;
&lt;br /&gt;
[[Category:Consultants]]&lt;br /&gt;
[[Category:Developers]]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Transport_Analyst&amp;diff=4317</id>
		<title>Transport Analyst</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Transport_Analyst&amp;diff=4317"/>
		<updated>2017-08-31T21:07:30Z</updated>

		<summary type="html">&lt;p&gt;Leeor: redirect to Conveyal Analysis&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;#REDIRECT [[Conveyal Analysis]]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Conveyal_Analysis&amp;diff=4316</id>
		<title>Conveyal Analysis</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Conveyal_Analysis&amp;diff=4316"/>
		<updated>2017-08-31T21:06:42Z</updated>

		<summary type="html">&lt;p&gt;Leeor: migrate from Transport Analyst&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
{{infobox&lt;br /&gt;
|title=Transport Analyst&lt;br /&gt;
|image=&lt;br /&gt;
|vendor=[[Conveyal]]&lt;br /&gt;
|license=[[The MIT License]]&lt;br /&gt;
|documentation= http://analysis-ui.readthedocs.io/en/latest/&lt;br /&gt;
|data_in= [[GTFS]], [[OpenStreetMap]], ACS/Census, LODES, custom shapefiles&lt;br /&gt;
|data_out= GIS shapefiles, maps, accessibility graphs, GeoTIFF, &lt;br /&gt;
|website= [http://conveyal.com/projects/analyst/ http://conveyal.com/projects/analyst/]&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
Transport Analyst integrates transit and land use data to compare current system performance and accessibility with various scenarios. It is an open source tool developed by [[Conveyal]], and can be hosted and run independently or hosted by Conveyal for a fee along with consulting services.&lt;br /&gt;
&lt;br /&gt;
==Accessibility Assessment==&lt;br /&gt;
[[File:Conveyal-jobs-access.png|thumb|Identifying places that see increased access to jobs due to a new transit line. &amp;lt;br&amp;gt;Source: http://conveyal.com/projects/analyst/]]&lt;br /&gt;
[[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.&amp;lt;ref&amp;gt;Conveyal analysis-ui documentation. Accessed 20 April 2017. http://analysis-ui.readthedocs.io/en/latest/analysis/#spectrogram&amp;lt;/ref&amp;gt; ]]&lt;br /&gt;
&lt;br /&gt;
Analyst offers basic statistics of how far or fast a system can carry people but also, by layering information from [[OpenStreetMap]] and census data, it allows planners to view accessibility. Analyst can display job opportunities, businesses, and various amenities that become more accessible to people living near a new planned transit line. Accessibility outcomes offer new opportunities for collaboration between land use and transportation planning. The software can intake multiple alternatives and return graphical prototypes such as spectrograms and histograms that compare accessibility outcomes for the different scenarios.&lt;br /&gt;
&lt;br /&gt;
The accessibility outcomes offered by Analyst display the total number of a given amenity that can be reached within a given amount of time from a given point, or for a full system analysis, the number of origin destination combinations available within a given amount of time. For example, it can show how many jobs can be reached from a household, or how many household-job combinations exist withing a time cutoff. The information is displayed as a spectrogram that demonstrates the change in access to the given amenity as the travel time cutoff increases, and as a histogram that shows the variability of accessibility for a given time cutoff with in a time range, highlighting the effects of schedules and headways.&lt;br /&gt;
&lt;br /&gt;
A single point analysis, showing accessibility from that point to all other points, can be calculated quickly, usually taking 5-15 second. An analysis of an entire region, looking at accessibility from every point to every other point, takes longer. The factors that most affect computation time are the size of the region, the number of points in the region, and the size and density of the transit and transportation network. Furthermore, a scenario analysis is able to use results from the base case and only run the analysis where results will differ. Therefore, more changes in a scenario will lead to longer computational time. An analysis run on a single server can take anywhere from a few hours to a few days depending on the complexity of the system. If the analysis is run on multiple servers, either using [[Conveyal|Conveyal's]] hosting service or through other access to cluster computing, the runtime can be reduced to a few minutes to a few hours.&lt;br /&gt;
&lt;br /&gt;
==Scenario Creation==&lt;br /&gt;
[[File:Analyst-scenario-editor.png|thumb|Modeling a new transit line using the scenario editor. &amp;lt;br&amp;gt;Source: http://conveyal.com/projects/analyst/]]&lt;br /&gt;
Different scenarios can be generated a number of different ways. Future scenarios can be generated by importing foretasted demographic and jobs data as custom shapefiles. These are usually derived from regional or state forecast models. Scenarios can also be generated by importing custom demographic, jobs, or point destination data that represent the predicted result of a land use change or of a new development. Furthermore, scenarios can represent changes or additions to the transit system, generated through edited [[GTFS]] files or by using [[conveyal|Conveyal's]] scenario editing tool. If a new potential transit line only has a route planned, the scenario editor can add stops according to a set spacing. These can be moved to represent more likely stop location, say at large intersections or transit centers. Multiple scenarios can be generated and run simultaneously to offer an accessibility and performance comparison analysis.&lt;br /&gt;
&lt;br /&gt;
==Other Features==&lt;br /&gt;
===Public Outreach===&lt;br /&gt;
Analyst can be run on a web interface that allows for public outreach and consultation. The map allows users to see the impact alternative scenarios would have on them and to make recommendations as a result. It can output maps in [[GIS]] format for integration into publications and reports. &lt;br /&gt;
&lt;br /&gt;
===Walk time===&lt;br /&gt;
Travel time calculations incorporate pedestrian travel time, using the street network to account for how long it takes to walk to and from the bus station. [[Conveyal]] is currently developing other multimodal access calculations, such and biking and driving, so that bikes on transit, bikeshare, and park-and-ride can be better accounted for. Walk time is calculated using the pedestrian street network available through [[OpenStreetMap]], however a direct street network editor is in development.&lt;br /&gt;
&lt;br /&gt;
===Title VI and Equity===&lt;br /&gt;
Using demographic data from census inputs, Analyst can preform equity analyses and reveal disparate impacts that a given scenario might create. This analysis aides transit agencies to ensure projects comply with [[Transit and Civil Rights| Title VI]] in the US, and supports agencies in determining how projects align with their own internal equity goals.&lt;br /&gt;
&lt;br /&gt;
==Open-source==&lt;br /&gt;
[[Conveyal| Conveyal's]] commitment to open data and open-source has led them to use open data for all of Transport Analyst's inputs, such as publicly available [[GTFS]] feeds, map data from [[OpenStreetMap]], and census data. The components for Analyst are themselves open source, licensed under the [[Apache 2]] license.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Category:GTFS-consuming applications]]&lt;br /&gt;
[[Category: Scenario planning tools]]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=ARC_Project_Evaluation_Visualization&amp;diff=4307</id>
		<title>ARC Project Evaluation Visualization</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=ARC_Project_Evaluation_Visualization&amp;diff=4307"/>
		<updated>2017-08-11T22:52:38Z</updated>

		<summary type="html">&lt;p&gt;Leeor: add category&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox&lt;br /&gt;
|title= ARC Project Evaluation Visualization&lt;br /&gt;
|vendor= Atlanta Regional Commission&lt;br /&gt;
|documentation = https://github.com/atlregional/proj-eval&lt;br /&gt;
|website = http://atlregional.github.io/proj-eval/&lt;br /&gt;
}}&lt;br /&gt;
The Project Evaluation Visualization (PEV) web application was designed to make it easier to interact and navigate with all of the data generated for the project evaluation and comparison in the 2016 Regional Transportation Plan (RTP) of the Atlanta Regional Commission (ARC). The RTP has 798 projects, 163 of which have scheduled federal funding and were individually evaluated. The RTP process included a benefit-cost ratio for 2015 and 2040, as well as 7 needs criteria and 6 performance criteria.&amp;lt;ref&amp;gt;2016 Regional Transportation Plan, Appendix H. Atlanta Regional Commission. http://atlantaregional.org/regional-transportation-plan/ Accessed 11 August 2017&amp;lt;/ref&amp;gt;. PEV makes it possible to look at a number of factors across projects. A scatter plot can be populated with all projects, or just the projects in a specific county. Criteria can then be set for the x axis, y axis, size of points in the scatter plot, and color, allowing for multi-variable comparisons. PEV also shows specifics for any given project, and offers a comparison with the region and county average.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
[[Category:Data Visualization applications]]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=ARC_Project_Evaluation_Visualization&amp;diff=4306</id>
		<title>ARC Project Evaluation Visualization</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=ARC_Project_Evaluation_Visualization&amp;diff=4306"/>
		<updated>2017-08-11T22:50:23Z</updated>

		<summary type="html">&lt;p&gt;Leeor: Create page&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox&lt;br /&gt;
|title= ARC Project Evaluation Visualization&lt;br /&gt;
|vendor= Atlanta Regional Commission&lt;br /&gt;
|documentation = https://github.com/atlregional/proj-eval&lt;br /&gt;
|website = http://atlregional.github.io/proj-eval/&lt;br /&gt;
}}&lt;br /&gt;
The Project Evaluation Visualization (PEV) web application was designed to make it easier to interact and navigate with all of the data generated for the project evaluation and comparison in the 2016 Regional Transportation Plan (RTP) of the Atlanta Regional Commission (ARC). The RTP has 798 projects, 163 of which have scheduled federal funding and were individually evaluated. The RTP process included a benefit-cost ratio for 2015 and 2040, as well as 7 needs criteria and 6 performance criteria.&amp;lt;ref&amp;gt;2016 Regional Transportation Plan, Appendix H. Atlanta Regional Commission. http://atlantaregional.org/regional-transportation-plan/ Accessed 11 August 2017&amp;lt;/ref&amp;gt;. PEV makes it possible to look at a number of factors across projects. A scatter plot can be populated with all projects, or just the projects in a specific county. Criteria can then be set for the x axis, y axis, size of points in the scatter plot, and color, allowing for multi-variable comparisons. PEV also shows specifics for any given project, and offers a comparison with the region and county average.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=ARC_Project_Evaluation_Visualization&amp;diff=4305</id>
		<title>ARC Project Evaluation Visualization</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=ARC_Project_Evaluation_Visualization&amp;diff=4305"/>
		<updated>2017-08-11T22:35:57Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The Project Evaluation Visualization (PEV) web application was designed to make it easier to interact and navigate with all of the data generated for the project evaluation and comparison in the 2016 Regional Transportation Plan (RTP) of the Atlanta Regional Commission (ARC). The RTP has 798 projects, 163 of which have scheduled federal funding and were individually evaluated. The RTP process included a benefit-cost ratio for 2015 and 2040, as well as 7 needs criteria and 6 performance criteria.&amp;lt;ref&amp;gt;2016 Regional Transportation Plan, Appendix H. Atlanta Regional Commission. http://atlantaregional.org/regional-transportation-plan/ Accessed ~~~~&amp;lt;/ref&amp;gt;&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=ARC_Project_Evaluation_Visualization&amp;diff=4304</id>
		<title>ARC Project Evaluation Visualization</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=ARC_Project_Evaluation_Visualization&amp;diff=4304"/>
		<updated>2017-08-11T22:35:27Z</updated>

		<summary type="html">&lt;p&gt;Leeor: Created page with &amp;quot;The Project Evaluation Visualization (PEV) web application was designed to make it easier to interact and navigate with all of the data generated for the project evaluation an...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The Project Evaluation Visualization (PEV) web application was designed to make it easier to interact and navigate with all of the data generated for the project evaluation and comparison in the 2016 Regional Transportation Plan (RTP) of the Atlanta Regional Commission (ARC). The RTP has 798 projects, 163 of which have scheduled federal funding and were individually evaluated. The RTP process included a benefit-cost ratio for 2015 and 2040, as well as 7 needs criteria and 6 performance criteria.&amp;lt;ref&amp;gt;2016 Regional Transportation Plan, Appendix H. Atlanta Regional Commission. http://atlantaregional.org/regional-transportation-plan/ Accessed ~~~~~&amp;lt;/ref&amp;gt;&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Project_Evaluation_Tool_Comparison&amp;diff=4300</id>
		<title>Project Evaluation Tool Comparison</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Project_Evaluation_Tool_Comparison&amp;diff=4300"/>
		<updated>2017-07-28T00:58:46Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This matrix shows various attributes for a series of tools that were evaluated for supporting the Atlanta Regional Commission in the 2017 Transit Vision update. If you have any comments suggestions, or edits, please contact [[User_talk: Leeor | Leeor]]&lt;br /&gt;
&lt;br /&gt;
[https://docs.google.com/spreadsheets/d/1Nrx8mpp55R66uwgXiKi9o_6AQtutnbcSWuvavXhh5Pc/pubhtml Project Evaluation Tool Comparison Matrix]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Project_Evaluation_Tool_Comparison&amp;diff=4299</id>
		<title>Project Evaluation Tool Comparison</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Project_Evaluation_Tool_Comparison&amp;diff=4299"/>
		<updated>2017-07-28T00:58:28Z</updated>

		<summary type="html">&lt;p&gt;Leeor: add gsheets link&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This matrix shows various attributes for a series of tools that were evaluated for supporting the Atlanta Regional Commission in the 2017 Transit Vision update. If you have any comments suggestions, or edits, please contact [[User_talk: Leeor | Leeor]]&lt;br /&gt;
&lt;br /&gt;
[https://docs.google.com/spreadsheets/d/1Nrx8mpp55R66uwgXiKi9o_6AQtutnbcSWuvavXhh5Pc/pubhtml | Project Evaluation Tool Comparison Matrix]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Project_Evaluation_Tool_Comparison&amp;diff=4298</id>
		<title>Project Evaluation Tool Comparison</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Project_Evaluation_Tool_Comparison&amp;diff=4298"/>
		<updated>2017-07-28T00:57:29Z</updated>

		<summary type="html">&lt;p&gt;Leeor: add gsheets link&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This matrix shows various attributes for a series of tools that were evaluated for supporting the Atlanta Regional Commission in the 2017 Transit Vision update. If you have any comments, suggestions, or edits, please contact [[User_talk: Leeor | Leeor]]&lt;br /&gt;
&lt;br /&gt;
[https://docs.google.com/spreadsheets/d/1Nrx8mpp55R66uwgXiKi9o_6AQtutnbcSWuvavXhh5Pc/pubhtml | Project Evaluation Tool Comparison Matrix]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Project_Evaluation_Tool_Comparison&amp;diff=4297</id>
		<title>Project Evaluation Tool Comparison</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Project_Evaluation_Tool_Comparison&amp;diff=4297"/>
		<updated>2017-07-24T20:47:17Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This matrix shows various attributes for a series of tools that were evaluated for supporting the Atlanta Regional Commission in the 2017 Transit Vision update. If you have any comments suggestions, or edits, please contact [[User_talk: Leeor | Leeor]]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Project_Evaluation_Tool_Comparison&amp;diff=4296</id>
		<title>Project Evaluation Tool Comparison</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Project_Evaluation_Tool_Comparison&amp;diff=4296"/>
		<updated>2017-07-24T19:07:30Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This matrix shows various attributes for a series of tools that were evaluated for supporting the Atlanta Regional Commission in the 2017 Transit Vision update. If you have any comments suggestions, or edits, please contact [[User_talk: Leeor | Leeor]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;html&amp;gt;&amp;lt;iframe src=&amp;quot;https://docs.google.com/spreadsheets/d/e/2PACX-1vRQiqtYaYATjC52YDcdmNQdEL4SrBu049HPN95EtG_vObC-Ya1PhkY7ovCj_FNrLzPj4QtFdM481mT0/pubhtml?widget=true&amp;amp;amp;headers=false&amp;quot;&amp;gt;&amp;lt;/iframe&amp;gt;&amp;lt;/html&amp;gt;&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Project_Evaluation_Tool_Comparison&amp;diff=4295</id>
		<title>Project Evaluation Tool Comparison</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Project_Evaluation_Tool_Comparison&amp;diff=4295"/>
		<updated>2017-07-24T18:55:56Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This matrix shows various attributes for a series of tools that were evaluated for supporting the Atlanta Regional Commission in the 2017 Transit Vision update. If you have any comments suggestions, or edits, please contact [[User_talk: Leeor | Leeor]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;iframe src=&amp;quot;https://docs.google.com/spreadsheets/d/e/2PACX-1vRQiqtYaYATjC52YDcdmNQdEL4SrBu049HPN95EtG_vObC-Ya1PhkY7ovCj_FNrLzPj4QtFdM481mT0/pubhtml?widget=true&amp;amp;amp;headers=false&amp;quot;&amp;gt;&amp;lt;/iframe&amp;gt;&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Project_Evaluation_Tool_Comparison&amp;diff=4294</id>
		<title>Project Evaluation Tool Comparison</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Project_Evaluation_Tool_Comparison&amp;diff=4294"/>
		<updated>2017-07-24T18:46:37Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This matrix shows various attributes for a series of tools that were evaluated for supporting the Atlanta Regional Commission in the 2017 Transit Vision update. If you have any comments suggestions, or edits, please contact [[User_talk: Leeor | Leeor]]&lt;br /&gt;
&lt;br /&gt;
https://docs.google.com/spreadsheets/d/e/2PACX-1vRQiqtYaYATjC52YDcdmNQdEL4SrBu049HPN95EtG_vObC-Ya1PhkY7ovCj_FNrLzPj4QtFdM481mT0/pubhtml&lt;br /&gt;
&lt;br /&gt;
{{#widget:Google Spreadsheet&lt;br /&gt;
|key=2PACX-1vRQiqtYaYATjC52YDcdmNQdEL4SrBu049HPN95EtG_vObC-Ya1PhkY7ovCj_FNrLzPj4QtFdM481mT0&lt;br /&gt;
|width=600&lt;br /&gt;
|height=400&lt;br /&gt;
}}&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Project_Evaluation_Tool_Comparison&amp;diff=4293</id>
		<title>Project Evaluation Tool Comparison</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Project_Evaluation_Tool_Comparison&amp;diff=4293"/>
		<updated>2017-07-24T18:45:18Z</updated>

		<summary type="html">&lt;p&gt;Leeor: Created page with &amp;quot;This matrix shows various attributes for a series of tools that were evaluated for supporting the Atlanta Regional Commission in the 2017 Transit Vision update. If you have an...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This matrix shows various attributes for a series of tools that were evaluated for supporting the Atlanta Regional Commission in the 2017 Transit Vision update. If you have any comments suggestions, or edits, please contact [[User_talk: Leeor | Leeor]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;iframe src=&amp;quot;https://docs.google.com/spreadsheets/d/e/2PACX-1vRQiqtYaYATjC52YDcdmNQdEL4SrBu049HPN95EtG_vObC-Ya1PhkY7ovCj_FNrLzPj4QtFdM481mT0/pubhtml?widget=true&amp;amp;amp;headers=false&amp;quot;&amp;gt;&amp;lt;/iframe&amp;gt;&lt;br /&gt;
&lt;br /&gt;
{{#widget:Google Spreadsheet&lt;br /&gt;
|key=1oDnQlJ3eQ0ZOzmRiR8qkvEtSyEXaE32AyytUu6BMzRQ&lt;br /&gt;
|width=600&lt;br /&gt;
|height=400&lt;br /&gt;
}}&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Remix&amp;diff=4292</id>
		<title>Remix</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Remix&amp;diff=4292"/>
		<updated>2017-07-24T18:08:16Z</updated>

		<summary type="html">&lt;p&gt;Leeor: Update info on Jane&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox&lt;br /&gt;
|title= Remix&lt;br /&gt;
|image= Remix-logo.png&lt;br /&gt;
|vendor= Remix&lt;br /&gt;
|license= Proprietary&lt;br /&gt;
|documentation= https://help.remix.com/&lt;br /&gt;
|data_in= [[GTFS]], GIS shapefiles, ACS/Census, [[OpenStreetMap]], LEHD&lt;br /&gt;
|data_out= [[GTFS]], GIS shapefiles and database, maps, KML&lt;br /&gt;
|website= [https://www.remix.com/ https://www.remix.com/]&lt;br /&gt;
}}&lt;br /&gt;
[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.&lt;br /&gt;
__TOC__&lt;br /&gt;
==How it Works==&lt;br /&gt;
[[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]]]&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Street network===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Setting up the existing transit network===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Variables such as operating cost per hour or mile (with costs for Saturday, peak) can be set for the agency.&lt;br /&gt;
&lt;br /&gt;
===Creating scenarios / editing the network===&lt;br /&gt;
After onboarding is complete, the agency can start using Remix. New &amp;quot;scenarios&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
===Measures &amp;amp;  Outputs===&lt;br /&gt;
Measures including the following update as the route is drawn.&lt;br /&gt;
&lt;br /&gt;
====Costs &amp;amp; resources====&lt;br /&gt;
* Number of buses&lt;br /&gt;
* Operating cost per year&lt;br /&gt;
* Route miles&lt;br /&gt;
&lt;br /&gt;
====Catchment====&lt;br /&gt;
* Population within defined buffer of stops&lt;br /&gt;
* Jobs within within defined buffer of stops&lt;br /&gt;
&lt;br /&gt;
Buffers are calculated according to &amp;quot;crow flies&amp;quot; methodology, not the street grid.&amp;lt;ref&amp;gt;https://help.remix.com/articles/2869-can-i-change-the-radius-of-the-buffer&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Layers===&lt;br /&gt;
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.&lt;br /&gt;
[[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]]]&lt;br /&gt;
&lt;br /&gt;
===Jane===&lt;br /&gt;
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. Jane's travel time is composed of three elements. &lt;br /&gt;
*Walking distance: Jane walks at 3 mph and travels linearly on the map (not on the street network). This includes from her origin to transit, between transit stops if she transfers, and from the transit stop to her destination.&lt;br /&gt;
*Wait time: Jane waits for half of the headway of for each transit line that she boards.&lt;br /&gt;
*In vehicle time: In vehicle time is determined by average stop to stop speeds based on the provided GTFS feeds.&lt;br /&gt;
This is helpful both for intra-agency planning and public outreach.&lt;br /&gt;
&lt;br /&gt;
===Title VI Engine===&lt;br /&gt;
Title VI of the Civil Rights Act of 1964 prevents against discrimination in the provision of government services, including public transportation.&amp;lt;ref&amp;gt;[https://www.transit.dot.gov/regulations-and-guidance/civil-rights-ada/title-vi-civil-rights-act-1964 Federal Transit Administration. &amp;quot;Title VI of the Civil Rights Act of 1964.&amp;quot; 2016.]&amp;lt;/ref&amp;gt; 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. &lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
===Output formats===&lt;br /&gt;
Remix can output transit network scenarios, indicators, and visualizations in these formats:&lt;br /&gt;
* Shapefile&lt;br /&gt;
* Excel (describing indicators)&lt;br /&gt;
* [[GTFS]] - Frequency-based, describing service parameters rather than an operationally-ready schedule&lt;br /&gt;
* Embeddable map for the web (with a mechanism to leave comments)&lt;br /&gt;
* Printable view&lt;br /&gt;
&lt;br /&gt;
==Applications==&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Costs==&lt;br /&gt;
The cost for Remix depends on the scale of the agency. Contact Remix sales for a quote.&lt;br /&gt;
&lt;br /&gt;
==Case Studies==&lt;br /&gt;
* '''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&amp;lt;ref&amp;gt;[https://blog.remix.com/taking-the-heartache-out-of-planning-in-torrance-ca-9de28a01e89f#.9qbl25ech Remix. &amp;quot;Taking the Heartache Out of Planning in Torrance, CA.&amp;quot; 2016.].&amp;lt;/ref&amp;gt;&lt;br /&gt;
* '''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&amp;lt;ref&amp;gt;[https://blog.remix.com/king-county-metro-builds-consensus-in-record-time-during-long-range-plan-76c14e57547d#.z7jcamego Remix. &amp;quot;King County Metro Builds Consensus in Record Time During Long-Range Plan.&amp;quot; 2016.].&amp;lt;/ref&amp;gt;&lt;br /&gt;
* '''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&amp;lt;ref&amp;gt;[https://blog.remix.com/preparing-for-a-transit-tax-increase-in-indianapolis-indiana-1001b49118aa#.lkf3cze2x Remix. &amp;quot;Preparing for a Transit Tax Increase in Indianapolis, Indiana.&amp;quot; 2016.].&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Additional Reading==&lt;br /&gt;
[https://blog.remix.com/ Remix Blog]&lt;br /&gt;
: 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Category:Network planning software]]&lt;br /&gt;
[[Category:GTFS-consuming applications]]&lt;br /&gt;
[[Category:Applications]]&lt;br /&gt;
[[Category: Complex data analysis]]&lt;br /&gt;
[[Category:Scenario planning tools]]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Remix&amp;diff=4291</id>
		<title>Remix</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Remix&amp;diff=4291"/>
		<updated>2017-07-24T17:56:05Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox&lt;br /&gt;
|title= Remix&lt;br /&gt;
|image= Remix-logo.png&lt;br /&gt;
|vendor= Remix&lt;br /&gt;
|license= Proprietary&lt;br /&gt;
|documentation= https://help.remix.com/&lt;br /&gt;
|data_in= [[GTFS]], GIS shapefiles, ACS/Census, [[OpenStreetMap]], LEHD&lt;br /&gt;
|data_out= [[GTFS]], GIS shapefiles and database, maps, KML&lt;br /&gt;
|website= [https://www.remix.com/ https://www.remix.com/]&lt;br /&gt;
}}&lt;br /&gt;
[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.&lt;br /&gt;
__TOC__&lt;br /&gt;
==How it Works==&lt;br /&gt;
[[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]]]&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Street network===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Setting up the existing transit network===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Variables such as operating cost per hour or mile (with costs for Saturday, peak) can be set for the agency.&lt;br /&gt;
&lt;br /&gt;
===Creating scenarios / editing the network===&lt;br /&gt;
After onboarding is complete, the agency can start using Remix. New &amp;quot;scenarios&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
===Measures &amp;amp;  Outputs===&lt;br /&gt;
Measures including the following update as the route is drawn.&lt;br /&gt;
&lt;br /&gt;
====Costs &amp;amp; resources====&lt;br /&gt;
* Number of buses&lt;br /&gt;
* Operating cost per year&lt;br /&gt;
* Route miles&lt;br /&gt;
&lt;br /&gt;
====Catchment====&lt;br /&gt;
* Population within defined buffer of stops&lt;br /&gt;
* Jobs within within defined buffer of stops&lt;br /&gt;
&lt;br /&gt;
Buffers are calculated according to &amp;quot;crow flies&amp;quot; methodology, not the street grid.&amp;lt;ref&amp;gt;https://help.remix.com/articles/2869-can-i-change-the-radius-of-the-buffer&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Layers===&lt;br /&gt;
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.&lt;br /&gt;
[[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]]]&lt;br /&gt;
&lt;br /&gt;
===Jane===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Title VI Engine===&lt;br /&gt;
Title VI of the Civil Rights Act of 1964 prevents against discrimination in the provision of government services, including public transportation.&amp;lt;ref&amp;gt;[https://www.transit.dot.gov/regulations-and-guidance/civil-rights-ada/title-vi-civil-rights-act-1964 Federal Transit Administration. &amp;quot;Title VI of the Civil Rights Act of 1964.&amp;quot; 2016.]&amp;lt;/ref&amp;gt; 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. &lt;br /&gt;
&lt;br /&gt;
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].&lt;br /&gt;
&lt;br /&gt;
===Output formats===&lt;br /&gt;
Remix can output transit network scenarios, indicators, and visualizations in these formats:&lt;br /&gt;
* Shapefile&lt;br /&gt;
* Excel (describing indicators)&lt;br /&gt;
* [[GTFS]] - Frequency-based, describing service parameters rather than an operationally-ready schedule&lt;br /&gt;
* Embeddable map for the web (with a mechanism to leave comments)&lt;br /&gt;
* Printable view&lt;br /&gt;
&lt;br /&gt;
==Applications==&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Costs==&lt;br /&gt;
The cost for Remix depends on the scale of the agency. Contact Remix sales for a quote.&lt;br /&gt;
&lt;br /&gt;
==Case Studies==&lt;br /&gt;
* '''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&amp;lt;ref&amp;gt;[https://blog.remix.com/taking-the-heartache-out-of-planning-in-torrance-ca-9de28a01e89f#.9qbl25ech Remix. &amp;quot;Taking the Heartache Out of Planning in Torrance, CA.&amp;quot; 2016.].&amp;lt;/ref&amp;gt;&lt;br /&gt;
* '''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&amp;lt;ref&amp;gt;[https://blog.remix.com/king-county-metro-builds-consensus-in-record-time-during-long-range-plan-76c14e57547d#.z7jcamego Remix. &amp;quot;King County Metro Builds Consensus in Record Time During Long-Range Plan.&amp;quot; 2016.].&amp;lt;/ref&amp;gt;&lt;br /&gt;
* '''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&amp;lt;ref&amp;gt;[https://blog.remix.com/preparing-for-a-transit-tax-increase-in-indianapolis-indiana-1001b49118aa#.lkf3cze2x Remix. &amp;quot;Preparing for a Transit Tax Increase in Indianapolis, Indiana.&amp;quot; 2016.].&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Additional Reading==&lt;br /&gt;
[https://blog.remix.com/ Remix Blog]&lt;br /&gt;
: 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Category:Network planning software]]&lt;br /&gt;
[[Category:GTFS-consuming applications]]&lt;br /&gt;
[[Category:Applications]]&lt;br /&gt;
[[Category: Complex data analysis]]&lt;br /&gt;
[[Category:Scenario planning tools]]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Transit_Boardings_Estimation_and_Simulation_Tool_(TBEST)&amp;diff=4290</id>
		<title>Transit Boardings Estimation and Simulation Tool (TBEST)</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Transit_Boardings_Estimation_and_Simulation_Tool_(TBEST)&amp;diff=4290"/>
		<updated>2017-07-22T03:27:27Z</updated>

		<summary type="html">&lt;p&gt;Leeor: added cost info, especially on ServiceEdge contract&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox&lt;br /&gt;
|title= Transit Boardings Estimation and Simulation Tool (TBEST)&lt;br /&gt;
|image= Tbest-logo.png&lt;br /&gt;
|vendor= [[FDOT]]&lt;br /&gt;
|license= unknown&lt;br /&gt;
|documentation= http://tbest.org/downloads/?dl_cat=10&lt;br /&gt;
|data_in= ACS/Census, [[OpenStreetMap]], InfoUSA, custom shapefiles, [[GTFS]]&lt;br /&gt;
|data_out= [[GTFS]], GIS shapefiles, maps, ridership estimates, accessibility statistics&lt;br /&gt;
|website= http://tbest.org/&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
[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 and accessibility analysis. TBEST requires a licensed copy of ArcGIS and Windows 7 or later, but the software itself is free to use.&lt;br /&gt;
&lt;br /&gt;
==How it Works==&lt;br /&gt;
[[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]]]&lt;br /&gt;
&lt;br /&gt;
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&amp;lt;ref&amp;gt;[http://tbest.org/download/TBEST41_Overview.pptx Center for Urban Transportation Research. &amp;quot;The TBEST Framework for Data Analysis and Forecasting.&amp;quot; 2013.]&amp;lt;/ref&amp;gt;. 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. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Market Analysis===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
After a market analysis has been performed, TBEST can generate reports in formats such as PDF, Excel, and PowerPoint.&lt;br /&gt;
&lt;br /&gt;
===Title VI Analysis===&lt;br /&gt;
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&amp;lt;ref&amp;gt;[https://www.transit.dot.gov/regulations-and-guidance/civil-rights-ada/title-vi-civil-rights-act-1964 Federal Transit Administration. &amp;quot;Title VI of the Civil Rights Act of 1964.&amp;quot; 2016.]&amp;lt;/ref&amp;gt;. 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.&lt;br /&gt;
&lt;br /&gt;
===Transit Access===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Cost==&lt;br /&gt;
TBEST is provided and maintained by FDOT for free. However, a user needs a current [[ArcGIS]] license. &lt;br /&gt;
&lt;br /&gt;
Furthermore, it appears that agencies have not succeeded in implementing TBEST without a support contract from [https://myserviceedge.com/ ServiceEdge Solutions]. A major reason for contracting with ServiceEdge is because scenario socioeconomic data preparation is not documented or exposed in the TBEST software, and TBEST does not offer explicit tools for accomplishing these steps. A 2017 consultation with ServiceEdge revealed that contracting with them to set up the scenario data usually costs less than $10,000 but that exact prices depend on data compatibility with TBEST and the number of counties that need to be processed. &lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Additional Reading==&lt;br /&gt;
[http://tbest.org/downloads/?dl_cat=10 TBEST 4.4 User Guide]&lt;br /&gt;
&lt;br /&gt;
: This extremely detailed guide provides illustrated instructions for all of TBEST's many features.&lt;br /&gt;
&lt;br /&gt;
[http://tbest.org/wp-content/files/TDPReviewandReporting_Final_1-19-2012.pdf TBEST - Guidelines for Transit Development Plan Ridership Estimation Review and Reporting]&lt;br /&gt;
&lt;br /&gt;
: This document outlines the way in which TBEST can be used in transportation development plan modeling.&lt;br /&gt;
&lt;br /&gt;
[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]&lt;br /&gt;
&lt;br /&gt;
: 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).&lt;br /&gt;
&lt;br /&gt;
[[Category:GTFS-consuming applications]]&lt;br /&gt;
[[Category:Network planning software]]&lt;br /&gt;
[[Category:Ridership forecasting]]&lt;br /&gt;
[[Category:Scenario planning tools]]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=CityCast&amp;diff=4274</id>
		<title>CityCast</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=CityCast&amp;diff=4274"/>
		<updated>2017-06-23T18:42:01Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox&lt;br /&gt;
|title=CityCast&lt;br /&gt;
|image= &lt;br /&gt;
|vendor= [https://transportfoundry.com/ Transport Foundry]&lt;br /&gt;
|license= Proprietary&lt;br /&gt;
|documentation= Not yet available&lt;br /&gt;
|data_in= Consumer data (e.g. Acxiom, Epsilon, Experian, Merkle), firm data (e.g. Dun &amp;amp; Bradstreet, InfoUSA), origin-destination data (e.g. AirSage, StreetLight Data), road network (e.g. [[Google Maps]], HERE, [[OpenStreetMap]]), [[GTFS]], [[NHTS]]&lt;br /&gt;
|data_out= Mode-split road network usage tables&lt;br /&gt;
|website= Coming soon&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Data Inputs==&lt;br /&gt;
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.&lt;br /&gt;
*Consumer data - data from marketing data-services firms that offer various demographic characteristics matched with home locations (e.g. Acxiom, Epsilon, Experian, Merkle)&lt;br /&gt;
*Firm data - data that details where employers are, how many people they employee, and what sector they operate in (e.g. Dun &amp;amp; Bradstreet, InfoUSA)&lt;br /&gt;
*Origin-destination data - aggregated cell phone location data (e.g. AirSage, StreetLight Data)&lt;br /&gt;
*Network data&lt;br /&gt;
**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]])&lt;br /&gt;
**Transit network information, imported from [[General Transit Feed Specification]] datasets&lt;br /&gt;
**Parking information is not currently imported, but this is supported by MATSim (see notes below on the role of [[MATSim]]) using an extension&amp;lt;ref&amp;gt;http://www.ubiquitypress.com/site/books/10.5334/baw/read/#epubcfi(/6/54[Chapter_13]!/4/2/2/1:0)&amp;lt;/ref&amp;gt;, so this capability could be feasibly added&lt;br /&gt;
*National Household Travel Survey ([[NHTS]]) - offers some more information on mode choice,  travel patterns, and habits.&lt;br /&gt;
&lt;br /&gt;
==Modeling Trips==&lt;br /&gt;
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]]. &lt;br /&gt;
 &lt;br /&gt;
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..&lt;br /&gt;
 &lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Case Study==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Comparison with an Activity-Based Model (ABM)==&lt;br /&gt;
'''See full [[Activity-Based Model]] page'''&lt;br /&gt;
===Transferability===&lt;br /&gt;
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.&lt;br /&gt;
 &lt;br /&gt;
===Complexity===&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=MATSim&amp;diff=4273</id>
		<title>MATSim</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=MATSim&amp;diff=4273"/>
		<updated>2017-06-23T18:40:43Z</updated>

		<summary type="html">&lt;p&gt;Leeor: Created page with &amp;quot;{{edit queue |editor = Leeor }} {{infobox |title = MATSim |image = matsim-logo.png |vendor = [http://www.matsim.org/about-us MATSim Community] |license = GNU General Public...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{edit queue&lt;br /&gt;
|editor = Leeor&lt;br /&gt;
}}&lt;br /&gt;
{{infobox&lt;br /&gt;
|title = MATSim&lt;br /&gt;
|image = matsim-logo.png&lt;br /&gt;
|vendor = [http://www.matsim.org/about-us MATSim Community]&lt;br /&gt;
|license = [[GNU General Public License]]&lt;br /&gt;
|documentation = http://www.matsim.org/docs&lt;br /&gt;
|data_in =&lt;br /&gt;
|data_out =&lt;br /&gt;
|website = http://www.matsim.org/&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
From the [http://www.matsim.org/about-matsim MATSim about page]:&lt;br /&gt;
&lt;br /&gt;
==Agent-Based Transport Simulations==&lt;br /&gt;
MATSim provides a framework to implement large-scale agent-based transport simulations. The framework consists of severel modules which can be combined or used stand-alone. Modules can be replaced by own implementations to test single aspects of your own work. Currently, MATSim offers a framework for demand-modeling, agent-based mobility-simulation (traffic flow simulation), re-planning, a controler to iteratively run simulations as well as methods to analyze the output generated by the modules.&lt;br /&gt;
&lt;br /&gt;
==Key Features of MATSim==&lt;br /&gt;
*Fast Dynamic and Agent-Based Traffic Simulation: Simulate whole days within minutes&lt;br /&gt;
*Private and Public Traffic: Both private cars and transit traffic can be simulated&lt;br /&gt;
*Supports Large Scenarios: MATSim can simulate millions of agents or huge, detailed networks&lt;br /&gt;
*Versatile Analyses and Simulation Output: E.g. compare simulated data to real-world counting stations&lt;br /&gt;
*Modular Approach: Easily extended with your own algorithms&lt;br /&gt;
*Open Source: You get the Java Source Code, which runs on all major operating systems&lt;br /&gt;
*Active Development: The international MATSim community constantly adds new features and improves current ones&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=File:Matsim-logo.png&amp;diff=4272</id>
		<title>File:Matsim-logo.png</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=File:Matsim-logo.png&amp;diff=4272"/>
		<updated>2017-06-23T18:30:40Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;MATSim logo&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=CityCast&amp;diff=4271</id>
		<title>CityCast</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=CityCast&amp;diff=4271"/>
		<updated>2017-06-23T18:13:41Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox&lt;br /&gt;
|title=CityCast&lt;br /&gt;
|image= &lt;br /&gt;
|vendor= [https://transportfoundry.com/ Transport Foundry]&lt;br /&gt;
|license= Proprietary&lt;br /&gt;
|documentation= Not yet available&lt;br /&gt;
|data_in= Consumer data (e.g. Acxiom, Epsilon, Experian, Merkle), firm data (e.g. Dun &amp;amp; Bradstreet, InfoUSA), origin-destination data (e.g. AirSage, StreetLight Data), road network (e.g. [[Google Maps]], HERE, [[OpenStreetMap]]), [[GTFS]], [[NHTS]]&lt;br /&gt;
|data_out= Mode-split road network usage spreadsheet&lt;br /&gt;
|website= Coming soon&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Data Inputs==&lt;br /&gt;
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.&lt;br /&gt;
*Consumer data - data from marketing data-services firms that offer various demographic characteristics matched with home locations (e.g. Acxiom, Epsilon, Experian, Merkle)&lt;br /&gt;
*Firm data - data that details where employers are, how many people they employee, and what sector they operate in (e.g. Dun &amp;amp; Bradstreet, InfoUSA)&lt;br /&gt;
*Origin-destination data - aggregated cell phone location data (e.g. AirSage, StreetLight Data)&lt;br /&gt;
*Network data&lt;br /&gt;
**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]])&lt;br /&gt;
**Transit network information, imported from [[General Transit Feed Specification]] datasets&lt;br /&gt;
**Parking information is not currently imported, but this is supported by MATSim (see notes below on the role of [[MATSim]]) using an extension&amp;lt;ref&amp;gt;http://www.ubiquitypress.com/site/books/10.5334/baw/read/#epubcfi(/6/54[Chapter_13]!/4/2/2/1:0)&amp;lt;/ref&amp;gt;, so this capability could be feasibly added&lt;br /&gt;
*National Household Travel Survey ([[NHTS]]) - offers some more information on mode choice,  travel patterns, and habits.&lt;br /&gt;
&lt;br /&gt;
==Modeling Trips==&lt;br /&gt;
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]]. &lt;br /&gt;
 &lt;br /&gt;
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..&lt;br /&gt;
 &lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Case Study==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Comparison with an Activity-Based Model (ABM)==&lt;br /&gt;
'''See full [[Activity-Based Model]] page'''&lt;br /&gt;
===Transferability===&lt;br /&gt;
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.&lt;br /&gt;
 &lt;br /&gt;
===Complexity===&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=NHTS&amp;diff=4270</id>
		<title>NHTS</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=NHTS&amp;diff=4270"/>
		<updated>2017-06-23T18:12:53Z</updated>

		<summary type="html">&lt;p&gt;Leeor: Redirect to National Household Travel Survey&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;#REDIRECT [[National Household Travel Survey]]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=National_Household_Travel_Survey&amp;diff=4269</id>
		<title>National Household Travel Survey</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=National_Household_Travel_Survey&amp;diff=4269"/>
		<updated>2017-06-23T18:11:54Z</updated>

		<summary type="html">&lt;p&gt;Leeor: Create page&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{edit queue&lt;br /&gt;
|editor = Leeor&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
From the [http://nhts.ornl.gov/ National Household Travel Survey] website:&lt;br /&gt;
&amp;quot;The 2009 National Household Travel Survey (NHTS) provides information to assist transportation planners and policy makers who need comprehensive data on travel and transportation patterns in the United States. The 2009 NHTS updates information gathered in the 2001 NHTS and in prior Nationwide Personal Transportation Surveys (NPTS) conducted in 1969, 1977, 1983, 1990, and 1995.&amp;quot;&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=CityCast&amp;diff=4268</id>
		<title>CityCast</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=CityCast&amp;diff=4268"/>
		<updated>2017-06-23T18:08:38Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox&lt;br /&gt;
|title=CityCast&lt;br /&gt;
|image= &lt;br /&gt;
|vendor= [https://transportfoundry.com/ Transport Foundry]&lt;br /&gt;
|license= Proprietary&lt;br /&gt;
|documentation= Not yet available&lt;br /&gt;
|data_in= Consumer data (e.g. Acxiom, Epsilon, Experian, Merkle), firm data (e.g. Dun &amp;amp; Bradstreet, InfoUSA), origin-destination data (e.g. AirSage, StreetLight Data), road network (e.g. [[Google Maps]], HERE, [[OpenStreetMap]]), [[GTFS]], [[NHTS]]&lt;br /&gt;
|data_out= Mode-split road network usage spreadsheet&lt;br /&gt;
|website= Coming soon&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Data Inputs==&lt;br /&gt;
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.&lt;br /&gt;
*Consumer data - data from marketing data-services firms that offer various demographic characteristics matched with home locations (e.g. Acxiom, Epsilon, Experian, Merkle)&lt;br /&gt;
*Firm data - data that details where employers are, how many people they employee, and what sector they operate in (e.g. Dun &amp;amp; Bradstreet, InfoUSA)&lt;br /&gt;
*Origin-destination data - aggregated cell phone location data (e.g. AirSage, StreetLight Data)&lt;br /&gt;
*Network data&lt;br /&gt;
**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, [[OpenStreetMaps]])&lt;br /&gt;
**Transit network information, imported from [[General Transit Feed Specification]] datasets&lt;br /&gt;
**Parking information is not currently imported, but this is supported by MATSim (see notes below on the role of [[MATSim]]) using an extension&amp;lt;ref&amp;gt;http://www.ubiquitypress.com/site/books/10.5334/baw/read/#epubcfi(/6/54[Chapter_13]!/4/2/2/1:0)&amp;lt;/ref&amp;gt;, so this capability could be feasibly added&lt;br /&gt;
*National Household Travel Survey ([[NHTS]]) - offers some more information on mode choice,  travel patterns, and habits.&lt;br /&gt;
&lt;br /&gt;
==Modeling Trips==&lt;br /&gt;
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]]. &lt;br /&gt;
 &lt;br /&gt;
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..&lt;br /&gt;
 &lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Case Study==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Comparison with an Activity-Based Model (ABM)==&lt;br /&gt;
'''See full [[Activity-Based Model]] page'''&lt;br /&gt;
===Transferability===&lt;br /&gt;
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.&lt;br /&gt;
 &lt;br /&gt;
===Complexity===&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=CityCast&amp;diff=4267</id>
		<title>CityCast</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=CityCast&amp;diff=4267"/>
		<updated>2017-06-23T18:07:22Z</updated>

		<summary type="html">&lt;p&gt;Leeor: Create page&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox&lt;br /&gt;
|title=CityCast&lt;br /&gt;
|image= &lt;br /&gt;
|vendor= [https://transportfoundry.com/ Transport Foundry]&lt;br /&gt;
|license= Proprietary&lt;br /&gt;
|documentation= Not yet available&lt;br /&gt;
|data_in= Consumer data (e.g. Acxiom, Epsilon, Experian, Merkle), firm data (e.g. Dun &amp;amp; Bradstreet, InfoUSA), origin-destination data (e.g. AirSage, StreetLight Data), road network (e.g. [[Google Maps]], HERE, [[OpenStreetMaps]]), [[GTFS]], [[NHTS]]&lt;br /&gt;
|data_out= Mode-split road network usage spreadsheet&lt;br /&gt;
|website= Coming soon&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Data Inputs==&lt;br /&gt;
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.&lt;br /&gt;
*Consumer data - data from marketing data-services firms that offer various demographic characteristics matched with home locations (e.g. Acxiom, Epsilon, Experian, Merkle)&lt;br /&gt;
*Firm data - data that details where employers are, how many people they employee, and what sector they operate in (e.g. Dun &amp;amp; Bradstreet, InfoUSA)&lt;br /&gt;
*Origin-destination data - aggregated cell phone location data (e.g. AirSage, StreetLight Data)&lt;br /&gt;
*Network data&lt;br /&gt;
**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, [[OpenStreetMaps]])&lt;br /&gt;
**Transit network information, imported from [[General Transit Feed Specification]] datasets&lt;br /&gt;
**Parking information is not currently imported, but this is supported by MATSim (see notes below on the role of [[MATSim]]) using an extension&amp;lt;ref&amp;gt;http://www.ubiquitypress.com/site/books/10.5334/baw/read/#epubcfi(/6/54[Chapter_13]!/4/2/2/1:0)&amp;lt;/ref&amp;gt;, so this capability could be feasibly added&lt;br /&gt;
*National Household Travel Survey ([[NHTS]]) - offers some more information on mode choice,  travel patterns, and habits.&lt;br /&gt;
&lt;br /&gt;
==Modeling Trips==&lt;br /&gt;
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]]. &lt;br /&gt;
 &lt;br /&gt;
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..&lt;br /&gt;
 &lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Case Study==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Comparison with an Activity-Based Model (ABM)==&lt;br /&gt;
'''See full [[Activity-Based Model]] page'''&lt;br /&gt;
===Transferability===&lt;br /&gt;
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.&lt;br /&gt;
 &lt;br /&gt;
===Complexity===&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Visum&amp;diff=4259</id>
		<title>Visum</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Visum&amp;diff=4259"/>
		<updated>2017-06-13T21:05:27Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox&lt;br /&gt;
|title= Visum&lt;br /&gt;
|image= Ptvvisum-logo.png&lt;br /&gt;
|vendor= [http://www.ptvgroup.com/en/ PTV Group]&lt;br /&gt;
|license= Proprietary &lt;br /&gt;
|documentation= None found online&lt;br /&gt;
|data_in= TomTom, HERE. [[OpenStreetMap]], INRIX, Shape files, GTFS, HAFAS, VDV 452, DIVA, railML&lt;br /&gt;
|data_out= Shape files, SVG&lt;br /&gt;
|website= http://vision-traffic.ptvgroup.com/en-us/products/ptv-visum/&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
PTV Visum is a transportation modelling software developed by PTV Group. It is a part of a larger software suite that PTV group offers that offer other types of analysis. Visum models transport networks and travel demand, generating forecasts for traffic flows upon which policy and project decisions can be made.&lt;br /&gt;
&lt;br /&gt;
==Functions==&lt;br /&gt;
Visum offers a supply side model of transportation networks. These can include a number of different transportation modes and types of users. The model allows for user-defined objects that adapt the model to meet the specifications of the area being studied. The demand on these networks can be generated using a 4-step model or a tour-based model (powered by Visem). The models include nest modelling and mode choice calculations. In trip assignment, Visum offers a number of options for road and transit assignment. These include dynamic assignment, static models such as toll and node impedance, time-table assignment, headway assignment, etc. These assignments can be run on multiple user classes simultaneously.&lt;br /&gt;
&lt;br /&gt;
Visium is preset to develop a number of reports to visually illustrate model outcomes. Report output includes:&lt;br /&gt;
*Scenario comparison&lt;br /&gt;
*Matrix histograms&lt;br /&gt;
*Flow bundle calculation&lt;br /&gt;
*Interactive shortest path search&lt;br /&gt;
*Isochrones&lt;br /&gt;
*Environmental analyses (noise, emissions)&lt;br /&gt;
*Analysis of accident data&lt;br /&gt;
&lt;br /&gt;
===Modules===&lt;br /&gt;
Some of the functions of Visum are not available in the base software but added as modules. Examples include timetable management and line costing. For a full list of module functionalities see the [http://vision-traffic.ptvgroup.com/fileadmin/files_ptvvision/Downloads_N/0_General/2_Products/1_PTV_Visum/EN_PTV_Visum_Modules.pdf Module Fact Sheet].&lt;br /&gt;
&lt;br /&gt;
==Potential Uses==&lt;br /&gt;
===Transportation Master Plan===&lt;br /&gt;
Visum lets users import PrT and PuT networks from a variety of courses. These are used to generate demand models using a variety of methods, including a 4-step algorithm. Various scenarios can then be tested on top of the base case to determine their impact on demand assignment. These scenarios can include changes to roadway, transit, or development.&lt;br /&gt;
[[File:Visum-Transportationmasterplan.jpg|thumb|Result of a PrT assignment: Link bars correspond to volumes by user class Car and HGV, respectively&amp;lt;ref&amp;gt;PTV Visum Use Cases http://vision-traffic.ptvgroup.com/en-us/products/ptv-visum/use-cases/&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
&lt;br /&gt;
===Public Transit Analysis===&lt;br /&gt;
Visum allows users to generate networks based on supply and demand data and then verity the network against an existing timetable. The model allows for a graphical representation of each line and for a depiction of the volumes along lines and within the entire network. Demand along specific routes can offer revenue projections and support decisions for changing supply. Since Visum calculates revenue it can also model the changes to revenue as a result of changes to fare and fare structure.&lt;br /&gt;
&lt;br /&gt;
===Project Specific Analysis===&lt;br /&gt;
Visum can model the effects implementing a project will have on a system. This can include the diversions caused by construction and the total traffic flow implications of the project itself. The details from these models can be used as input in cost-benefit analyses of projects and in analyses of environmental impacts. These projects can include changes to roadways, transit, or development.&lt;br /&gt;
&lt;br /&gt;
==Runtime==&lt;br /&gt;
Visum allows for distributed computing among several computers to improve the runtime of its processes. &lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
*PTV Visum Public Transport Planning Borchure http://vision-traffic.ptvgroup.com/fileadmin/files_ptvvision/Downloads_N/0_General/2_Products/1_PTV_Visum/EN_PTV_Visum_PuT_Brochure.pdf&lt;br /&gt;
*Presentation by PTV Group. State of the Art of Multimodal Macroscopic Transport Modelling. 2012 Sep. 28. http://www.uni-stuttgart.de/fovus/NfM/presentations/NfM2012_Heidl_State_of_the_Art_Multimodal_Macroscopic_Transport_Modeling.pdf&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Visum&amp;diff=4258</id>
		<title>Visum</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Visum&amp;diff=4258"/>
		<updated>2017-06-13T21:04:27Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox&lt;br /&gt;
|title= Visum&lt;br /&gt;
|image= Ptvvisum-logo.png&lt;br /&gt;
|vendor= [http://www.ptvgroup.com/en/ | PTV Group]&lt;br /&gt;
|license= Proprietary &lt;br /&gt;
|documentation= None found online&lt;br /&gt;
|data_in= TomTom, HERE. [[OpenStreetMap]], INRIX, Shape files, GTFS, HAFAS, VDV 452, DIVA, railML&lt;br /&gt;
|data_out= Shape files, SVG&lt;br /&gt;
|website= http://vision-traffic.ptvgroup.com/en-us/products/ptv-visum/&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
PTV Visum is a transportation modelling software developed by PTV Group. It is a part of a larger software suite that PTV group offers that offer other types of analysis. Visum models transport networks and travel demand, generating forecasts for traffic flows upon which policy and project decisions can be made.&lt;br /&gt;
&lt;br /&gt;
==Functions==&lt;br /&gt;
Visum offers a supply side model of transportation networks. These can include a number of different transportation modes and types of users. The model allows for user-defined objects that adapt the model to meet the specifications of the area being studied. The demand on these networks can be generated using a 4-step model or a tour-based model (powered by Visem). The models include nest modelling and mode choice calculations. In trip assignment, Visum offers a number of options for road and transit assignment. These include dynamic assignment, static models such as toll and node impedance, time-table assignment, headway assignment, etc. These assignments can be run on multiple user classes simultaneously.&lt;br /&gt;
&lt;br /&gt;
Visium is preset to develop a number of reports to visually illustrate model outcomes. Report output includes:&lt;br /&gt;
*Scenario comparison&lt;br /&gt;
*Matrix histograms&lt;br /&gt;
*Flow bundle calculation&lt;br /&gt;
*Interactive shortest path search&lt;br /&gt;
*Isochrones&lt;br /&gt;
*Environmental analyses (noise, emissions)&lt;br /&gt;
*Analysis of accident data&lt;br /&gt;
&lt;br /&gt;
===Modules===&lt;br /&gt;
Some of the functions of Visum are not available in the base software but added as modules. Examples include timetable management and line costing. For a full list of module functionalities see the [http://vision-traffic.ptvgroup.com/fileadmin/files_ptvvision/Downloads_N/0_General/2_Products/1_PTV_Visum/EN_PTV_Visum_Modules.pdf | Module Fact Sheet].&lt;br /&gt;
&lt;br /&gt;
==Potential Uses==&lt;br /&gt;
===Transportation Master Plan===&lt;br /&gt;
Visum lets users import PrT and PuT networks from a variety of courses. These are used to generate demand models using a variety of methods, including a 4-step algorithm. Various scenarios can then be tested on top of the base case to determine their impact on demand assignment. These scenarios can include changes to roadway, transit, or development.&lt;br /&gt;
[[File:Visum-Transportationmasterplan.jpg|thumb|Result of a PrT assignment: Link bars correspond to volumes by user class Car and HGV, respectively&amp;lt;ref&amp;gt;PTV Visum Use Cases http://vision-traffic.ptvgroup.com/en-us/products/ptv-visum/use-cases/&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
&lt;br /&gt;
===Public Transit Analysis===&lt;br /&gt;
Visum allows users to generate networks based on supply and demand data and then verity the network against an existing timetable. The model allows for a graphical representation of each line and for a depiction of the volumes along lines and within the entire network. Demand along specific routes can offer revenue projections and support decisions for changing supply. Since Visum calculates revenue it can also model the changes to revenue as a result of changes to fare and fare structure.&lt;br /&gt;
&lt;br /&gt;
===Project Specific Analysis===&lt;br /&gt;
Visum can model the effects implementing a project will have on a system. This can include the diversions caused by construction and the total traffic flow implications of the project itself. The details from these models can be used as input in cost-benefit analyses of projects and in analyses of environmental impacts. These projects can include changes to roadways, transit, or development.&lt;br /&gt;
&lt;br /&gt;
==Runtime==&lt;br /&gt;
Visum allows for distributed computing among several computers to improve the runtime of its processes. &lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
*PTV Visum Public Transport Planning Borchure http://vision-traffic.ptvgroup.com/fileadmin/files_ptvvision/Downloads_N/0_General/2_Products/1_PTV_Visum/EN_PTV_Visum_PuT_Brochure.pdf&lt;br /&gt;
*Presentation by PTV Group. State of the Art of Multimodal Macroscopic Transport Modelling. 2012 Sep. 28. http://www.uni-stuttgart.de/fovus/NfM/presentations/NfM2012_Heidl_State_of_the_Art_Multimodal_Macroscopic_Transport_Modeling.pdf&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Visum&amp;diff=4257</id>
		<title>Visum</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Visum&amp;diff=4257"/>
		<updated>2017-06-13T20:46:31Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox&lt;br /&gt;
|title= Visum&lt;br /&gt;
|image= Ptvvisum-logo.png&lt;br /&gt;
|vendor= [[PTV Group]]&lt;br /&gt;
|license= Proprietary &lt;br /&gt;
|documentation= None found online&lt;br /&gt;
|data_in= TomTom, HERE. [[OpenStreetMap]], INRIX, Shape files, GTFS, HAFAS, VDV 452, DIVA, railML&lt;br /&gt;
|data_out= Shape files, SVG&lt;br /&gt;
|website= http://vision-traffic.ptvgroup.com/en-us/products/ptv-visum/&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
PTV Visum is a transportation modelling software developed by PTV Group. It is a part of a larger software suite that PTV group offers that offer other types of analysis. Visum models transport networks and travel demand, generating forecasts for traffic flows upon which policy and project decisions can be made.&lt;br /&gt;
&lt;br /&gt;
==Functions==&lt;br /&gt;
Visum offers a supply side model of transportation networks. These can include a number of different transportation modes and types of users. The model allows for user-defined objects that adapt the model to meet the specifications of the area being studied. The demand on these networks can be generated using a 4-step model or a tour-based model (powered by Visem). The models include nest modelling and mode choice calculations. In trip assignment, Visum offers a number of options for road and transit assignment. These include dynamic assignment, static models such as toll and node impedance, time-table assignment, headway assignment, etc. These assignments can be run on multiple user classes simultaneously.&lt;br /&gt;
&lt;br /&gt;
Visium is preset to develop a number of reports to visually illustrate model outcomes. Report output includes:&lt;br /&gt;
*Scenario comparison&lt;br /&gt;
*Matrix histograms&lt;br /&gt;
*Flow bundle calculation&lt;br /&gt;
*Interactive shortest path search&lt;br /&gt;
*Isochrones&lt;br /&gt;
*Environmental analyses (noise, emissions)&lt;br /&gt;
*Analysis of accident data&lt;br /&gt;
&lt;br /&gt;
===Modules===&lt;br /&gt;
Some of the functions of Visum are not available in the base software but added as modules. Examples include timetable management and line costing. For a full list of module functionalities see the [http://vision-traffic.ptvgroup.com/fileadmin/files_ptvvision/Downloads_N/0_General/2_Products/1_PTV_Visum/EN_PTV_Visum_Modules.pdf | Module Fact Sheet].&lt;br /&gt;
&lt;br /&gt;
==Potential Uses==&lt;br /&gt;
===Transportation Master Plan===&lt;br /&gt;
Visum lets users import PrT and PuT networks from a variety of courses. These are used to generate demand models using a variety of methods, including a 4-step algorithm. Various scenarios can then be tested on top of the base case to determine their impact on demand assignment. These scenarios can include changes to roadway, transit, or development.&lt;br /&gt;
[[File:Visum-Transportationmasterplan.jpg|thumb|Result of a PrT assignment: Link bars correspond to volumes by user class Car and HGV, respectively&amp;lt;ref&amp;gt;PTV Visum Use Cases http://vision-traffic.ptvgroup.com/en-us/products/ptv-visum/use-cases/&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
&lt;br /&gt;
===Public Transit Analysis===&lt;br /&gt;
Visum allows users to generate networks based on supply and demand data and then verity the network against an existing timetable. The model allows for a graphical representation of each line and for a depiction of the volumes along lines and within the entire network. Demand along specific routes can offer revenue projections and support decisions for changing supply. Since Visum calculates revenue it can also model the changes to revenue as a result of changes to fare and fare structure.&lt;br /&gt;
&lt;br /&gt;
===Project Specific Analysis===&lt;br /&gt;
Visum can model the effects implementing a project will have on a system. This can include the diversions caused by construction and the total traffic flow implications of the project itself. The details from these models can be used as input in cost-benefit analyses of projects and in analyses of environmental impacts. These projects can include changes to roadways, transit, or development.&lt;br /&gt;
&lt;br /&gt;
==Runtime==&lt;br /&gt;
Visum allows for distributed computing among several computers to improve the runtime of its processes. &lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
*PTV Visum Public Transport Planning Borchure http://vision-traffic.ptvgroup.com/fileadmin/files_ptvvision/Downloads_N/0_General/2_Products/1_PTV_Visum/EN_PTV_Visum_PuT_Brochure.pdf&lt;br /&gt;
*Presentation by PTV Group. State of the Art of Multimodal Macroscopic Transport Modelling. 2012 Sep. 28. http://www.uni-stuttgart.de/fovus/NfM/presentations/NfM2012_Heidl_State_of_the_Art_Multimodal_Macroscopic_Transport_Modeling.pdf&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Visum&amp;diff=4256</id>
		<title>Visum</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Visum&amp;diff=4256"/>
		<updated>2017-06-13T20:32:09Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox&lt;br /&gt;
|title= Visum&lt;br /&gt;
|image= Ptvvisum-logo.png&lt;br /&gt;
|vendor= [[PTV Group]]&lt;br /&gt;
|license= Proprietary &lt;br /&gt;
|documentation= None found online&lt;br /&gt;
|data_in= TomTom, HERE. [[OpenStreetMap]], INRIX, Shape files, GTFS, HAFAS, VDV 452, DIVA, railML&lt;br /&gt;
|data_out= Shape files, SVG&lt;br /&gt;
|website= http://vision-traffic.ptvgroup.com/en-us/products/ptv-visum/&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
PTV Visum is a transportation modelling software developed by PTV Group. It is a part of a larger software suite that PTV group offers that offer other types of analysis. Visum models transport networks and travel demand, generating forecasts for traffic flows upon which policy and project decisions can be made.&lt;br /&gt;
&lt;br /&gt;
==Functions==&lt;br /&gt;
Visum offers a supply side model of transportation networks. These can include a number of different transportation modes and types of users. The model allows for user-defined objects that adapt the model to meet the specifications of the area being studied. The demand on these networks can be generated using a 4-step model or a tour-based model (powered by Visem). The models include nest modelling and mode choice calculations. In trip assignment, Visum offers a number of options for road and transit assignment. These include dynamic assignment, static models such as toll and node impedance, time-table assignment, headway assignment, etc. These assignments can be run on multiple user classes simultaneously.&lt;br /&gt;
&lt;br /&gt;
Visium is preset to develop a number of reports to visually illustrate model outcomes. Report output includes:&lt;br /&gt;
*Scenario comparison&lt;br /&gt;
*Matrix histograms&lt;br /&gt;
*Flow bundle calculation&lt;br /&gt;
*Interactive shortest path search&lt;br /&gt;
*Isochrones&lt;br /&gt;
*Environmental analyses (noise, emissions)&lt;br /&gt;
*Analysis of accident data&lt;br /&gt;
&lt;br /&gt;
===Modules===&lt;br /&gt;
Some of the functions of Visum are not available in the base software but added as modules. Examples include timetable management and line costing. For a full list of module functionalities see the [http://vision-traffic.ptvgroup.com/fileadmin/files_ptvvision/Downloads_N/0_General/2_Products/1_PTV_Visum/EN_PTV_Visum_Modules.pdf | Module Fact Sheet].&lt;br /&gt;
&lt;br /&gt;
==Potential Uses==&lt;br /&gt;
===Transportation Master Plan===&lt;br /&gt;
Visum lets users import PrT and PuT networks from a variety of courses. These are used to generate demand models using a variety of methods, including a 4-step algorithm. Various scenarios can then be tested on top of the base case to determine their impact on demand assignment. These scenarios can include changes to roadway, transit, or development.&lt;br /&gt;
[[File:Visum-Transportationmasterplan.jpg|thumb|Result of a PrT assignment: Link bars correspond to volumes by user class Car and HGV, respectively&amp;lt;ref&amp;gt;PTV Visum Use Cases http://vision-traffic.ptvgroup.com/en-us/products/ptv-visum/use-cases/&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
&lt;br /&gt;
===Public Transit Analysis===&lt;br /&gt;
Visum allows users to generate networks based on supply and demand data and then verity the network against an existing timetable. The model allows for a graphical representation of each line and for a depiction of the volumes along lines and within the entire network. Demand along specific routes can offer revenue projections and support decisions for changing supply. Since Visum calculates revenue it can also model the changes to revenue as a result of changes to fare and fare structure.&lt;br /&gt;
&lt;br /&gt;
===Project Specific Analysis===&lt;br /&gt;
Visum can model the effects implementing a project will have on a system. This can include the diversions caused by construction and the total traffic flow implications of the project itself. The details from these models can be used as input in cost-benefit analyses of projects and in analyses of environmental impacts. These projects can include changes to roadways, transit, or development.&lt;br /&gt;
&lt;br /&gt;
==Runtime==&lt;br /&gt;
Visum allows for distributed computing among several computers to improve the runtime of its processes. &lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
*PTV Visum Public Transport Planning Borchure http://vision-traffic.ptvgroup.com/fileadmin/files_ptvvision/Downloads_N/0_General/2_Products/1_PTV_Visum/EN_PTV_Visum_PuT_Brochure.pdf&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Visum&amp;diff=4255</id>
		<title>Visum</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Visum&amp;diff=4255"/>
		<updated>2017-06-13T20:31:32Z</updated>

		<summary type="html">&lt;p&gt;Leeor: create content in page&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox&lt;br /&gt;
|title= Visum&lt;br /&gt;
|image= Ptvvisum-logo.png&lt;br /&gt;
|vendor= [[PTV Group]]&lt;br /&gt;
|license= Proprietary &lt;br /&gt;
|documentation= None found online&lt;br /&gt;
|data_in= TomTom, HERE. [[OpenStreetMap]], INRIX, Shape files, GTFS, HAFAS, VDV 452, DIVA, railML&lt;br /&gt;
|data_out= Shape files, SVG&lt;br /&gt;
|website= http://vision-traffic.ptvgroup.com/en-us/products/ptv-visum/&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
PTV Visum is a transportation modelling software developed by PTV Group. It is a part of a larger software suite that PTV group offers that offer other types of analysis. Visum models transport networks and travel demand, generating forecasts for traffic flows upon which policy and project decisions can be made.&lt;br /&gt;
&lt;br /&gt;
==Functions==&lt;br /&gt;
Visum offers a supply side model of transportation networks. These can include a number of different transportation modes and types of users. The model allows for user-defined objects that adapt the model to meet the specifications of the area being studied. The demand on these networks can be generated using a 4-step model or a tour-based model (powered by Visem). The models include nest modelling and mode choice calculations. In trip assignment, Visum offers a number of options for road and transit assignment. These include dynamic assignment, static models such as toll and node impedance, time-table assignment, headway assignment, etc. These assignments can be run on multiple user classes simultaneously.&lt;br /&gt;
&lt;br /&gt;
Visium is preset to develop a number of reports to visually illustrate model outcomes. Report output includes:&lt;br /&gt;
*Scenario comparison&lt;br /&gt;
*Matrix histograms&lt;br /&gt;
*Flow bundle calculation&lt;br /&gt;
*Interactive shortest path search&lt;br /&gt;
*Isochrones&lt;br /&gt;
*Environmental analyses (noise, emissions)&lt;br /&gt;
*Analysis of accident data&lt;br /&gt;
&lt;br /&gt;
===Modules===&lt;br /&gt;
Some of the functions of Visum are not available in the base software but added as modules. Examples include timetable management and line costing. For a full list of module functionalities see the [http://vision-traffic.ptvgroup.com/fileadmin/files_ptvvision/Downloads_N/0_General/2_Products/1_PTV_Visum/EN_PTV_Visum_Modules.pdf | Module Fact Sheet].&lt;br /&gt;
&lt;br /&gt;
==Potential Uses==&lt;br /&gt;
===Transportation Master Plan===&lt;br /&gt;
Visum lets users import PrT and PuT networks from a variety of courses. These are used to generate demand models using a variety of methods, including a 4-step algorithm. Various scenarios can then be tested on top of the base case to determine their impact on demand assignment. These scenarios can include changes to roadway, transit, or development.&lt;br /&gt;
[[File:Visum-Transportationmasterplan.jpg|thumb|Result of a PrT assignment: Link bars correspond to volumes by user class Car and HGV, respectively&amp;lt;ref&amp;gt;PTV Visum Use Cases http://vision-traffic.ptvgroup.com/en-us/products/ptv-visum/use-cases/&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
&lt;br /&gt;
==Public Transit Analysis==&lt;br /&gt;
Visum allows users to generate networks based on supply and demand data and then verity the network against an existing timetable. The model allows for a graphical representation of each line and for a depiction of the volumes along lines and within the entire network. Demand along specific routes can offer revenue projections and support decisions for changing supply. Since Visum calculates revenue it can also model the changes to revenue as a result of changes to fare and fare structure.&lt;br /&gt;
&lt;br /&gt;
===Project Specific Analysis==&lt;br /&gt;
Visum can model the effects implementing a project will have on a system. This can include the diversions caused by construction and the total traffic flow implications of the project itself. The details from these models can be used as input in cost-benefit analyses of projects and in analyses of environmental impacts. These projects can include changes to roadways, transit, or development.&lt;br /&gt;
&lt;br /&gt;
==Runtime==&lt;br /&gt;
Visum allows for distributed computing among several computers to improve the runtime of its processes. &lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
*PTV Visum Public Transport Planning Borchure http://vision-traffic.ptvgroup.com/fileadmin/files_ptvvision/Downloads_N/0_General/2_Products/1_PTV_Visum/EN_PTV_Visum_PuT_Brochure.pdf&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=File:Visum-Transportationmasterplan.jpg&amp;diff=4254</id>
		<title>File:Visum-Transportationmasterplan.jpg</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=File:Visum-Transportationmasterplan.jpg&amp;diff=4254"/>
		<updated>2017-06-13T19:41:35Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Result of a PrT assignment: Link bars correspond to volumes by user class Car and HGV, respectively&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Activity-Based_Model&amp;diff=4233</id>
		<title>Activity-Based Model</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Activity-Based_Model&amp;diff=4233"/>
		<updated>2017-05-24T06:09:54Z</updated>

		<summary type="html">&lt;p&gt;Leeor: added some links&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{edit queue&lt;br /&gt;
|editor=Leeor&lt;br /&gt;
}}&lt;br /&gt;
=Further Reading=&lt;br /&gt;
*Travel forecasting resource's Activity-based models page http://tfresource.org/Category:Activity-based_models&lt;br /&gt;
*Activity-Based Travel Demand Models: A Primer. The Second Strategic Highway Research Program. published by TRB 2015 http://onlinepubs.trb.org/onlinepubs/shrp2/SHRP2_C46.pdf&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Sugar&amp;diff=4223</id>
		<title>Sugar</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Sugar&amp;diff=4223"/>
		<updated>2017-05-13T00:29:45Z</updated>

		<summary type="html">&lt;p&gt;Leeor: Reorganized, added information on run time, clarified transit network needs&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox&lt;br /&gt;
|title=Sugar&lt;br /&gt;
|image= Sugar-logo.png&lt;br /&gt;
|vendor= [[Citilabs]]&lt;br /&gt;
|license= Proprietary [http://www.citilabs.com/end-user-license-agreement/ http://www.citilabs.com/ end-user-license-agreement/]&lt;br /&gt;
|documentation= None found online&lt;br /&gt;
|data_in= ACS/Census, HERE, LODES, [[GTFS]], GIS shapefiles&lt;br /&gt;
|data_out= GIS database, Microsoft Access Database, maps, Access Score&lt;br /&gt;
|website= [http://www.citilabs.com/software/sugar/ http://www.citilabs.com/ software/sugar/]&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
Sugar offers tools for managing, analyzing, and visualizing transportation networks and accessibility in any community. Sugar has two main components:&lt;br /&gt;
* Sugar Access&lt;br /&gt;
* Sugar Network Editor&lt;br /&gt;
&lt;br /&gt;
=Sugar Access=&lt;br /&gt;
'''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. This allows for accessibility measures by different modes and also means that when calculating travel time for transit, Sugar calculates the entire trip length, including walking to and from the station and wait time. Because street and transit data is incorporated in the analysis, accessibility analysis takes into account physical barriers in the street network that may hinder walking to a station. The software comes pre-loaded with data for many communities, but data can also be edited using Sugar's network editor. This allows a user to analyze the impact of non-transit projects on the transit network if it affects accessibility to stations. In order give accurate access scores for transit, Sugar calculates exact travel times, and so requires complete transit network information, include station locations and stop to stop travel times.&lt;br /&gt;
&lt;br /&gt;
Sugar Access can provide the following indicators:&lt;br /&gt;
* Travel times from single origin to many destinations&lt;br /&gt;
* Destination summation for a particular location (number of destinations of a particular type), e.g. parks by walking, jobs by transit&lt;br /&gt;
* Comprehensive accessibility analysis: For an entire population, what % of (jobs, etc.) can be accessed in 10 min, 20 min, 30 min, etc.&lt;br /&gt;
* &amp;quot;Access Score&amp;quot;: A weighted score that represents the accessibility implications of a transit scenario (see further discussion below).&lt;br /&gt;
&lt;br /&gt;
===Access Score===&lt;br /&gt;
The software can generate an &amp;quot;Accessibility Score&amp;quot; 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.&amp;lt;ref&amp;gt;See slide 6, Eric Sundquist, TCS 2016, https://www.slideshare.net/otrec/eric-sundquist-tcs-2016/1&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:Calculating accessibility.png|100px|frame|none]]&lt;br /&gt;
&lt;br /&gt;
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 &amp;quot;cliff effect&amp;quot; where a job that is 31 minutes away is not factored into an indicator of &amp;quot;Jobs within 30 min&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
===Run time===&lt;br /&gt;
The accessibility measurements are very computationally intensive, and so can take a long time, depending on a number of factors such as mode choice, network size, number of zones, and computing power. An estimates average run time is 2-4 hours&amp;lt;ref&amp;gt;Personal email contact with Matthew Pettit, Product Applications Engineer at Citilabs&amp;lt;/ref&amp;gt;. Measuring transit accessibility tends to take longer than walking or driving.&lt;br /&gt;
&lt;br /&gt;
===Case study===&lt;br /&gt;
Sugar Access was used in [http://smartscale.org/ Virginia DOT's Smart Scale project].&lt;br /&gt;
&lt;br /&gt;
=Sugar Network Editor=&lt;br /&gt;
'''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 with transportation software products such as Citilabs Cube and Trafficware® Synchro.&lt;br /&gt;
&lt;br /&gt;
===Transit data===&lt;br /&gt;
'''Transit data''' can be imported from [[GTFS]]:&lt;br /&gt;
* Route alignments&lt;br /&gt;
* Stop locations&lt;br /&gt;
* Schedules&lt;br /&gt;
&lt;br /&gt;
The SNE allows editing of all of the above features.&lt;br /&gt;
&lt;br /&gt;
===Street network===&lt;br /&gt;
'''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].&lt;br /&gt;
&lt;br /&gt;
===Points of interest (POI) / Destinations===&lt;br /&gt;
'''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.&lt;br /&gt;
&lt;br /&gt;
=Technical Specifications=&lt;br /&gt;
&lt;br /&gt;
===Data outputs===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Requirements===&lt;br /&gt;
Sugar requires [http://arcgis.com ArcGIS].&lt;br /&gt;
&lt;br /&gt;
===Cost / Licensing===&lt;br /&gt;
This software is generally licensed on an annual basis, but shorter subscriptions are available with a premium fee. Costs are negotiated on a case by case basis, depending on clients needs.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Category:GTFS-consuming applications]]&lt;br /&gt;
[[Category:Network planning software]]&lt;br /&gt;
[[Category:Scenario planning tools]]&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Accessibility&amp;diff=4222</id>
		<title>Accessibility</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Accessibility&amp;diff=4222"/>
		<updated>2017-05-12T22:42:57Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;quot;Accessibility&amp;quot; may also refer to [[accessible design]] of transit vehicles and stations to provide mobility for all, including people with disabilities.&lt;br /&gt;
&lt;br /&gt;
In this article, accessibility (or just access) refers to the ability to reach goods, services, activities, and destinations, which together are called opportunities.&amp;lt;ref&amp;gt;&amp;quot;Accessibility for Transportation Planning: Measuring People’s Ability to Reach Desired Goods and Activities.&amp;quot; 27 February 2017. Todd Litman. Victoria Transport Policy Institute. http://www.vtpi.org/access.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Accessibility is nearly always 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. &lt;br /&gt;
&lt;br /&gt;
==Accessibility vs. Mobility==&lt;br /&gt;
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 unreasonably long. Accessibility directly addresses these questions by measuring people's ability to reach desired destinations.&lt;br /&gt;
&lt;br /&gt;
==Decay vs. Cut-offs==&lt;br /&gt;
One major distinction in measuring accessibility is how parameters are set for determining whether a destination is accessible. One method is to create a time cut-off. For example, one can ask &amp;quot;how many jobs can be reached in 30 minutes using transit from a given location?&amp;quot; or &amp;quot;how many household/job combinations are there within 30 minutes of each other along a transit line or within a transit system?&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
===Time cut-off===&lt;br /&gt;
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.&lt;br /&gt;
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, one can observe the change as travel time increases.&lt;br /&gt;
&lt;br /&gt;
===Decay===&lt;br /&gt;
[[File:Decay function.png|thumb|A decay function showing the change in weighted values for different modes and destination as travel time increases&amp;lt;ref&amp;gt;&amp;quot;Operationalizing Accessibility: Tools and Practices.&amp;quot; State Smart Transportation Initiative. 30 March 2017. http://www.ssti.us/Events/operationalizing-accessibility-part-1-tools-and-practices/&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
Decay functions offer a more fine-tuned assessment of accessibility by weighting destinations based on how far away they are. A job that is 5 minutes away contributes more to accessibility than one that is 30 minutes away, and a job that is 30 minutes away contributes about the same as one that is 31 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 no longer contribute to accessibility at all.&lt;br /&gt;
Using decay is challenging for a number of reasons. A meaningful and reliable decay function has to be developed. The computational effort of calculating the exact travel time to each location and weighting the location is intense and often slow. Finally, because locations are weighted, the final output is unit-less; it cannot be explained as the number of jobs within a 30 minute travel time window. This may allow for internal comparisons but may be difficult to convey conceptually at public presentations. One solution to improve presentation is to develop a clear scale and to create references as explanations for various points on the scale. (ex. a 1-100, where 80-100 is considered &amp;quot;excellent accessibility&amp;quot;, etc.)&lt;br /&gt;
&lt;br /&gt;
==First and Last Mile==&lt;br /&gt;
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 a 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 within a certain distance of stations and therefore considered accessible. Other tools incorporate travel time to and from the stations by using circular buffers and calculate an average travel time to the station within the buffer, or by calculating travel time on the street network.&lt;br /&gt;
&lt;br /&gt;
===Buffers===&lt;br /&gt;
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.&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Using the street network===&lt;br /&gt;
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 yields 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 preforming calculations only between stations, hence a much more computationally intensive process. It also requires an accurate street network that includes pedestrian paths.&lt;br /&gt;
&lt;br /&gt;
==Destinations==&lt;br /&gt;
Accessibility analysis measures how long it takes to arrive at certain types of destinations. The most common destination measured is jobs. Access to jobs is crucial for employers and employees and to maintain a robust economy. Peak commute hours tend to be the most congested times of the week, so increasing accessibility to jobs via transit is particularly important when seeking solutions to congestion. Data sources for jobs are also easy to acquire through the publicly available LODES and LEHD data.&lt;br /&gt;
Other destinations are also often sought. 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. Since only 20% of trips are for a home-to-work commute&amp;lt;ref&amp;gt;&amp;quot;Commuting in America 2013:​​ The National Report on​ Commuting Patterns and Trends​.&amp;quot; American Association of State Highway and Transportation Officials. http://traveltrends.transportation.org/Pages/default.aspx&amp;lt;/ref&amp;gt;​, factoring other trip destinations has a significant 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.&lt;br /&gt;
&lt;br /&gt;
==Population Analysis==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Example Tools==&lt;br /&gt;
Some tools that measure accessibility are discussed below&lt;br /&gt;
&lt;br /&gt;
*[[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 types. Sugar allows for easy layering of demographic data, but does not include demographic based calculations. &lt;br /&gt;
[[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.&amp;lt;ref&amp;gt;Conveyal analysis-ui documentation. Accessed 20 April 2017. http://analysis-ui.readthedocs.io/en/latest/analysis/#spectrogram&amp;lt;/ref&amp;gt; ]]&lt;br /&gt;
*[[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.&lt;br /&gt;
*[[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.&lt;br /&gt;
&lt;br /&gt;
==Further Reading==&lt;br /&gt;
*&amp;quot;The Why and How of Measuring Access to Opportunity: A Guide to Performance Management.&amp;quot; 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 &lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Accessibility&amp;diff=4221</id>
		<title>Accessibility</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Accessibility&amp;diff=4221"/>
		<updated>2017-05-12T22:39:52Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;quot;Accessibility&amp;quot; may also refer to [[accessible design]] of transit vehicles and stations to provide mobility for all, including people with disabilities.&lt;br /&gt;
&lt;br /&gt;
In this article, accessibility (or just access) refers to the ability to reach goods, services, activities, and destinations, which together are called opportunities.&amp;lt;ref&amp;gt;&amp;quot;Accessibility for Transportation Planning: Measuring People’s Ability to Reach Desired Goods and Activities.&amp;quot; 27 February 2017. Todd Litman. Victoria Transport Policy Institute. http://www.vtpi.org/access.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Accessibility is nearly always 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. &lt;br /&gt;
&lt;br /&gt;
==Accessibility vs. Mobility==&lt;br /&gt;
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 unreasonably long. Accessibility directly addresses these questions by measuring people's ability to reach desired destinations.&lt;br /&gt;
&lt;br /&gt;
==Decay vs. Cut-offs==&lt;br /&gt;
One major distinction in measuring accessibility is how parameters are set for determining whether a destination is accessible. One method is to create a time cut-off. For example, one can ask &amp;quot;how many jobs can be reached in 30 minutes using transit from a given location?&amp;quot; or &amp;quot;how many household/job combinations are there within 30 minutes of each other along a transit line or within a transit system?&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
===Time cut-off===&lt;br /&gt;
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.&lt;br /&gt;
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, one can observe the change as travel time increases.&lt;br /&gt;
&lt;br /&gt;
===Decay===&lt;br /&gt;
[[File:Decay function.png|thumb|A decay function showing the change in weighted values for different modes and destination as travel time increases&amp;lt;ref&amp;gt;&amp;quot;Operationalizing Accessibility: Tools and Practices.&amp;quot; State Smart Transportation Initiative. 30 March 2017. http://www.ssti.us/Events/operationalizing-accessibility-part-1-tools-and-practices/&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
Decay functions offer a more fine-tuned assessment of accessibility by weighting destinations based on how far away they are. A job that is 5 minutes away contributes more to accessibility than one that is 30 minutes away, and a job that is 30 minutes away contributes about the same as one that is 31 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 no longer contribute to accessibility at all.&lt;br /&gt;
Using decay is challenging for a number of reasons. A meaningful and reliable decay function has to be developed. The computational effort of calculating the exact travel time to each location and weighting the location is intense and often slow. Finally, because locations are weighted, the final output is unit-less; it cannot be explained as the number of jobs within a 30 minute travel time window. This may allow for internal comparisons but may be difficult to convey conceptually at public presentations. One solution to improve presentation is to develop a clear scale and to create references as explanations for various points on the scale. (ex. a 1-100, where 80-100 is considered &amp;quot;excellent accessibility&amp;quot;, etc.)&lt;br /&gt;
&lt;br /&gt;
==First and Last Mile==&lt;br /&gt;
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 a 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 within a certain distance of stations and therefore considered accessible. Other tools incorporate travel time to and from the stations by using circular buffers and calculate an average travel time to the station within the buffer, or by calculating travel time on the street network.&lt;br /&gt;
&lt;br /&gt;
===Buffers===&lt;br /&gt;
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.&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Using the street network===&lt;br /&gt;
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 yields 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 preforming calculations only between stations, hence a much more computationally intensive process. It also requires an accurate street network that includes pedestrian paths.&lt;br /&gt;
&lt;br /&gt;
==Destinations==&lt;br /&gt;
Accessibility analysis measures how long it takes to arrive at certain types of destinations. The most common destination measured is jobs. Access to jobs is crucial for employers and employees and to maintain a robust economy. Peak commute hours tend to be the most congested times of the week, so increasing accessibility to jobs via transit is particularly important when seeking solutions to congestion. Data sources for jobs are also easy to acquire through the publicly available LODES and LEHD data.&lt;br /&gt;
Other destinations are also often sought. 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. Since only 20% of trips are for a home-to-work commute&amp;lt;ref&amp;gt;&amp;quot;Commuting in America 2013:​​ The National Report on​ Commuting Patterns and Trends​.&amp;quot; American Association of State Highway and Transportation Officials. http://traveltrends.transportation.org/Pages/default.aspx&amp;lt;/ref&amp;gt;​, factoring other trip destinations has a significant 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.&lt;br /&gt;
&lt;br /&gt;
==Population Analysis==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Example Tools==&lt;br /&gt;
Some tools that measure accessibility are discussed below&lt;br /&gt;
&lt;br /&gt;
*[[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. &lt;br /&gt;
[[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.&amp;lt;ref&amp;gt;Conveyal analysis-ui documentation. Accessed 20 April 2017. http://analysis-ui.readthedocs.io/en/latest/analysis/#spectrogram&amp;lt;/ref&amp;gt; ]]&lt;br /&gt;
*[[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.&lt;br /&gt;
*[[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.&lt;br /&gt;
&lt;br /&gt;
==Further Reading==&lt;br /&gt;
*&amp;quot;The Why and How of Measuring Access to Opportunity: A Guide to Performance Management.&amp;quot; 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 &lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Accessibility&amp;diff=4220</id>
		<title>Accessibility</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Accessibility&amp;diff=4220"/>
		<updated>2017-05-12T22:36:29Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;quot;Accessibility&amp;quot; may also refer to [[accessible design]] of transit vehicles and stations to provide mobility for all, including people with disabilities.&lt;br /&gt;
&lt;br /&gt;
In this article, accessibility (or just access) refers to the ability to reach goods, services, activities, and destinations, which together are called opportunities.&amp;lt;ref&amp;gt;&amp;quot;Accessibility for Transportation Planning: Measuring People’s Ability to Reach Desired Goods and Activities.&amp;quot; 27 February 2017. Todd Litman. Victoria Transport Policy Institute. http://www.vtpi.org/access.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Accessibility is nearly always 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. &lt;br /&gt;
&lt;br /&gt;
==Accessibility vs. Mobility==&lt;br /&gt;
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 unreasonably long. Accessibility directly addresses these questions by measuring people's ability to reach desired destinations.&lt;br /&gt;
&lt;br /&gt;
==Decay vs. Cut-offs==&lt;br /&gt;
One major distinction in measuring accessibility is how parameters are set for determining whether a destination is accessible. One method is to create a time cut-off. For example, one can ask &amp;quot;how many jobs can be reached in 30 minutes using transit from a given location?&amp;quot; or &amp;quot;how many household/job combinations are there within 30 minutes of each other along a transit line or within a transit system?&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
===Time cut-off===&lt;br /&gt;
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.&lt;br /&gt;
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, one can observe the change as travel time increases.&lt;br /&gt;
&lt;br /&gt;
===Decay===&lt;br /&gt;
[[File:Decay function.png|thumb|A decay function showing the change in weighted values for different modes and destination as travel time increases&amp;lt;ref&amp;gt;&amp;quot;Operationalizing Accessibility: Tools and Practices.&amp;quot; State Smart Transportation Initiative. 30 March 2017. http://www.ssti.us/Events/operationalizing-accessibility-part-1-tools-and-practices/&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
Decay functions offer a more fine-tuned assessment of accessibility by weighting destinations based on how far away they are. A job that is 5 minutes away contributes more to accessibility than one that is 30 minutes away, and a job that is 30 minutes away contributes about the same as one that is 31 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 no longer contribute to accessibility at all.&lt;br /&gt;
Using decay is challenging for a number of reasons. A meaningful and reliable decay function has to be developed. The computational effort of calculating the exact travel time to each location and weighting the location is intense and often slow. Finally, because locations are weighted, the final output is unit-less; it cannot be explained as the number of jobs within a 30 minute travel time window. This may allow for internal comparisons but may be difficult to convey conceptually at public presentations. One solution to improve presentation is to develop a clear scale and to create references as explanations for various points on the scale. (ex. a 1-100, where 80-100 is considered &amp;quot;excellent accessibility&amp;quot;, etc.)&lt;br /&gt;
&lt;br /&gt;
==First and Last Mile==&lt;br /&gt;
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 a 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 within a certain distance of stations and therefore considered accessible. Other tools incorporate travel time to and from the stations by using circular buffers and calculate an average travel time to the station within the buffer, or by calculating travel time on the street network.&lt;br /&gt;
&lt;br /&gt;
===Buffers===&lt;br /&gt;
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.&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Using the street network===&lt;br /&gt;
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 yields 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 preforming calculations only between stations, hence a much more computationally intensive process. It also requires an accurate street network that includes pedestrian paths.&lt;br /&gt;
&lt;br /&gt;
==Destinations==&lt;br /&gt;
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.&lt;br /&gt;
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&amp;lt;ref&amp;gt;&amp;quot;Commuting in America 2013:​​ The National Report on​ Commuting Patterns and Trends​.&amp;quot; American Association of State Highway and Transportation Officials. http://traveltrends.transportation.org/Pages/default.aspx&amp;lt;/ref&amp;gt;​, 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.&lt;br /&gt;
&lt;br /&gt;
==Population Analysis==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Example Tools==&lt;br /&gt;
Some tools that measure accessibility are discussed below&lt;br /&gt;
&lt;br /&gt;
*[[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. &lt;br /&gt;
[[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.&amp;lt;ref&amp;gt;Conveyal analysis-ui documentation. Accessed 20 April 2017. http://analysis-ui.readthedocs.io/en/latest/analysis/#spectrogram&amp;lt;/ref&amp;gt; ]]&lt;br /&gt;
*[[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.&lt;br /&gt;
*[[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.&lt;br /&gt;
&lt;br /&gt;
==Further Reading==&lt;br /&gt;
*&amp;quot;The Why and How of Measuring Access to Opportunity: A Guide to Performance Management.&amp;quot; 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 &lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Headway&amp;diff=4219</id>
		<title>Headway</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Headway&amp;diff=4219"/>
		<updated>2017-05-12T22:35:02Z</updated>

		<summary type="html">&lt;p&gt;Leeor: Create page&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;In transit speak, &amp;quot;headway&amp;quot; is the amount of time between transit vehicle arrivals at a stop. A suburban route that has a bus once an hour would have a 60 minute headway. Frequent service buses in the US often have 10-15 minute headways. Very high service transit, most often seen in subways or [[LRT]] and [[BRT]] can sometime reach headways of 2-5 minutes. &lt;br /&gt;
Headways have a significant impact on how desirable a transit service is because they effect:&lt;br /&gt;
*The time penalty for missing a train or bus&lt;br /&gt;
*The amount of planning and preparation needed to use transit and stay on schedule&lt;br /&gt;
*The amount of time lost when transit schedules do not directly conform to work, school, or activity schedules&lt;br /&gt;
*Average wait times&lt;br /&gt;
Despite advantages increasing headways is difficult. It is very expensive (because of the need to add vehicles and operators), and when headways get small enough, there is an increased risk of bunching or other disturbances and delays when route and stop capacity are hit.&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Accessibility&amp;diff=4218</id>
		<title>Accessibility</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Accessibility&amp;diff=4218"/>
		<updated>2017-05-12T22:21:50Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;quot;Accessibility&amp;quot; may also refer to [[accessible design]] of transit vehicles and stations to provide mobility for all, including people with disabilities.&lt;br /&gt;
&lt;br /&gt;
In this article, accessibility (or just access) refers to the ability to reach goods, services, activities, and destinations, which together are called opportunities.&amp;lt;ref&amp;gt;&amp;quot;Accessibility for Transportation Planning: Measuring People’s Ability to Reach Desired Goods and Activities.&amp;quot; 27 February 2017. Todd Litman. Victoria Transport Policy Institute. http://www.vtpi.org/access.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Accessibility is nearly always 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. &lt;br /&gt;
&lt;br /&gt;
==Accessibility vs. Mobility==&lt;br /&gt;
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 unreasonably long. Accessibility directly addresses these questions by measuring people's ability to reach desired destinations.&lt;br /&gt;
&lt;br /&gt;
==Decay vs. Cut-offs==&lt;br /&gt;
One major distinction in measuring accessibility is how parameters are set for determining whether a destination is accessible. One method is to create a time cut-off. For example, one can ask &amp;quot;how many jobs can be reached in 30 minutes using transit from a given location?&amp;quot; or &amp;quot;how many household/job combinations are there within 30 minutes of each other along a transit line or within a transit system?&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
===Time cut-off===&lt;br /&gt;
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.&lt;br /&gt;
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, one can observe the change as travel time increases.&lt;br /&gt;
&lt;br /&gt;
===Decay===&lt;br /&gt;
[[File:Decay function.png|thumb|A decay function showing the change in weighted values for different modes and destination as travel time increases&amp;lt;ref&amp;gt;&amp;quot;Operationalizing Accessibility: Tools and Practices.&amp;quot; State Smart Transportation Initiative. 30 March 2017. http://www.ssti.us/Events/operationalizing-accessibility-part-1-tools-and-practices/&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
Decay functions offer a more fine-tuned assessment of accessibility by weighting destinations based on how far away they are. A job that is 5 minutes away contributes more to accessibility than one that is 30 minutes away, and a job that is 30 minutes away contributes about the same as one that is 31 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 no longer contribute to accessibility at all.&lt;br /&gt;
Using decay is challenging for a number of reasons. A meaningful and reliable decay function has to be developed. The computational effort of calculating the exact travel time to each location and weighting the location is intense and often slow. Finally, because locations are weighted, the final output is unit-less; it cannot be explained as the number of jobs within a 30 minute travel time window. This may allow for internal comparisons but may be difficult to convey conceptually at public presentations. One solution to improve presentation is to develop a clear scale and to create references as explanations for various points on the scale. (ex. a 1-100, where 80-100 is considered &amp;quot;excellent accessibility&amp;quot;, etc.)&lt;br /&gt;
&lt;br /&gt;
==First and Last Mile==&lt;br /&gt;
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 a 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 within a certain distance of stations and therefore considered accessible. Other tools incorporate travel time to and from the stations by using circular buffers and calculate an average travel time to the station within the buffer, or by calculating travel time on the street network.&lt;br /&gt;
&lt;br /&gt;
===Buffers===&lt;br /&gt;
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.&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Using the street network===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Destinations==&lt;br /&gt;
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.&lt;br /&gt;
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&amp;lt;ref&amp;gt;&amp;quot;Commuting in America 2013:​​ The National Report on​ Commuting Patterns and Trends​.&amp;quot; American Association of State Highway and Transportation Officials. http://traveltrends.transportation.org/Pages/default.aspx&amp;lt;/ref&amp;gt;​, 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.&lt;br /&gt;
&lt;br /&gt;
==Population Analysis==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Example Tools==&lt;br /&gt;
Some tools that measure accessibility are discussed below&lt;br /&gt;
&lt;br /&gt;
*[[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. &lt;br /&gt;
[[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.&amp;lt;ref&amp;gt;Conveyal analysis-ui documentation. Accessed 20 April 2017. http://analysis-ui.readthedocs.io/en/latest/analysis/#spectrogram&amp;lt;/ref&amp;gt; ]]&lt;br /&gt;
*[[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.&lt;br /&gt;
*[[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.&lt;br /&gt;
&lt;br /&gt;
==Further Reading==&lt;br /&gt;
*&amp;quot;The Why and How of Measuring Access to Opportunity: A Guide to Performance Management.&amp;quot; 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 &lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Accessibility&amp;diff=4217</id>
		<title>Accessibility</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Accessibility&amp;diff=4217"/>
		<updated>2017-05-12T22:18:35Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;quot;Accessibility&amp;quot; may also refer to [[accessible design]] of transit vehicles and stations to provide mobility for all, including people with disabilities.&lt;br /&gt;
&lt;br /&gt;
In this article, accessibility (or just access) refers to the ability to reach goods, services, activities, and destinations, which together are called opportunities.&amp;lt;ref&amp;gt;&amp;quot;Accessibility for Transportation Planning: Measuring People’s Ability to Reach Desired Goods and Activities.&amp;quot; 27 February 2017. Todd Litman. Victoria Transport Policy Institute. http://www.vtpi.org/access.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Accessibility is nearly always 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. &lt;br /&gt;
&lt;br /&gt;
==Accessibility vs. Mobility==&lt;br /&gt;
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 unreasonably long. Accessibility directly addresses these questions by measuring people's ability to reach desired destinations.&lt;br /&gt;
&lt;br /&gt;
==Decay vs. Cut-offs==&lt;br /&gt;
One major distinction in measuring accessibility is how parameters are set for determining whether a destination is accessible. One method is to create a time cut-off. For example, one can ask &amp;quot;how many jobs can be reached in 30 minutes using transit from a given location?&amp;quot; or &amp;quot;how many household/job combinations are there within 30 minutes of each other along a transit line or within a transit system?&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
===Time cut-off===&lt;br /&gt;
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.&lt;br /&gt;
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, one can observe the change as travel time increases.&lt;br /&gt;
&lt;br /&gt;
===Decay===&lt;br /&gt;
[[File:Decay function.png|thumb|A decay function showing the change in weighted values for different modes and destination as travel time increases&amp;lt;ref&amp;gt;&amp;quot;Operationalizing Accessibility: Tools and Practices.&amp;quot; State Smart Transportation Initiative. 30 March 2017. http://www.ssti.us/Events/operationalizing-accessibility-part-1-tools-and-practices/&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
Decay functions offer a more fine-tuned assessment of accessibility by weighting destinations based on how far away they are. A job that is 5 minutes away contributes more to accessibility than one that is 30 minutes away, and a job that is 30 minutes away contributes about the same as one that is 31 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 no longer contribute to accessibility at all.&lt;br /&gt;
Using decay is challenging for a number of reasons. A meaningful and reliable decay function has to be developed. The computational effort of calculating the exact travel time to each location and weighting the location is intense and often slow. Finally, because locations are weighted, the final output is unit-less; it cannot be explained as the number of jobs within a 30 minute travel time window. This may allow for internal comparisons but may be difficult to convey conceptually at public presentations. One solution to improve presentation is to develop a clear scale and to create references as explanations for various points on the scale. (ex. a 1-100, where 80-100 is considered &amp;quot;excellent accessibility&amp;quot;, etc.)&lt;br /&gt;
&lt;br /&gt;
==First and Last Mile==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Buffers===&lt;br /&gt;
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.&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Using the street network===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Destinations==&lt;br /&gt;
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.&lt;br /&gt;
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&amp;lt;ref&amp;gt;&amp;quot;Commuting in America 2013:​​ The National Report on​ Commuting Patterns and Trends​.&amp;quot; American Association of State Highway and Transportation Officials. http://traveltrends.transportation.org/Pages/default.aspx&amp;lt;/ref&amp;gt;​, 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.&lt;br /&gt;
&lt;br /&gt;
==Population Analysis==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Example Tools==&lt;br /&gt;
Some tools that measure accessibility are discussed below&lt;br /&gt;
&lt;br /&gt;
*[[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. &lt;br /&gt;
[[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.&amp;lt;ref&amp;gt;Conveyal analysis-ui documentation. Accessed 20 April 2017. http://analysis-ui.readthedocs.io/en/latest/analysis/#spectrogram&amp;lt;/ref&amp;gt; ]]&lt;br /&gt;
*[[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.&lt;br /&gt;
*[[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.&lt;br /&gt;
&lt;br /&gt;
==Further Reading==&lt;br /&gt;
*&amp;quot;The Why and How of Measuring Access to Opportunity: A Guide to Performance Management.&amp;quot; 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 &lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Accessibility&amp;diff=4216</id>
		<title>Accessibility</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Accessibility&amp;diff=4216"/>
		<updated>2017-05-12T22:15:06Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;quot;Accessibility&amp;quot; may also refer to [[accessible design]] of transit vehicles and stations to provide mobility for all, including people with disabilities.&lt;br /&gt;
&lt;br /&gt;
In this article, accessibility (or just access) refers to the ability to reach goods, services, activities, and destinations, which together are called opportunities.&amp;lt;ref&amp;gt;&amp;quot;Accessibility for Transportation Planning: Measuring People’s Ability to Reach Desired Goods and Activities.&amp;quot; 27 February 2017. Todd Litman. Victoria Transport Policy Institute. http://www.vtpi.org/access.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Accessibility is nearly always 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. &lt;br /&gt;
&lt;br /&gt;
==Accessibility vs. Mobility==&lt;br /&gt;
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 unreasonably long. Accessibility directly addresses these questions by measuring people's ability to reach desired destinations.&lt;br /&gt;
&lt;br /&gt;
==Decay vs. Cut-offs==&lt;br /&gt;
One major distinction in measuring accessibility is how parameters are set for determining whether a destination is accessible. One method is to create a time cut-off. For example, one can ask &amp;quot;how many jobs can be reached in 30 minutes using transit from a given location?&amp;quot; or &amp;quot;how many household/job combinations are there within 30 minutes of each other along a transit line or within a transit system?&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
===Time cut-off===&lt;br /&gt;
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.&lt;br /&gt;
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, one can observe the change as travel time increases.&lt;br /&gt;
&lt;br /&gt;
===Decay===&lt;br /&gt;
[[File:Decay function.png|thumb|A decay function showing the change in weighted values for different modes and destination as travel time increases&amp;lt;ref&amp;gt;&amp;quot;Operationalizing Accessibility: Tools and Practices.&amp;quot; State Smart Transportation Initiative. 30 March 2017. http://www.ssti.us/Events/operationalizing-accessibility-part-1-tools-and-practices/&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
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.&lt;br /&gt;
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.)&lt;br /&gt;
&lt;br /&gt;
==First and Last Mile==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Buffers===&lt;br /&gt;
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.&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Using the street network===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Destinations==&lt;br /&gt;
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.&lt;br /&gt;
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&amp;lt;ref&amp;gt;&amp;quot;Commuting in America 2013:​​ The National Report on​ Commuting Patterns and Trends​.&amp;quot; American Association of State Highway and Transportation Officials. http://traveltrends.transportation.org/Pages/default.aspx&amp;lt;/ref&amp;gt;​, 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.&lt;br /&gt;
&lt;br /&gt;
==Population Analysis==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Example Tools==&lt;br /&gt;
Some tools that measure accessibility are discussed below&lt;br /&gt;
&lt;br /&gt;
*[[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. &lt;br /&gt;
[[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.&amp;lt;ref&amp;gt;Conveyal analysis-ui documentation. Accessed 20 April 2017. http://analysis-ui.readthedocs.io/en/latest/analysis/#spectrogram&amp;lt;/ref&amp;gt; ]]&lt;br /&gt;
*[[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.&lt;br /&gt;
*[[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.&lt;br /&gt;
&lt;br /&gt;
==Further Reading==&lt;br /&gt;
*&amp;quot;The Why and How of Measuring Access to Opportunity: A Guide to Performance Management.&amp;quot; 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 &lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
	<entry>
		<id>https://www.transitwiki.org/TransitWiki/index.php?title=Accessibility&amp;diff=4215</id>
		<title>Accessibility</title>
		<link rel="alternate" type="text/html" href="https://www.transitwiki.org/TransitWiki/index.php?title=Accessibility&amp;diff=4215"/>
		<updated>2017-05-12T22:12:52Z</updated>

		<summary type="html">&lt;p&gt;Leeor: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;quot;Accessibility&amp;quot; may also refer to [[accessible design]] of transit vehicles and stations to provide mobility for all, including people with disabilities.&lt;br /&gt;
&lt;br /&gt;
In this article, accessibility (or just access) refers to the ability to reach goods, services, activities, and destinations, which together are called opportunities.&amp;lt;ref&amp;gt;&amp;quot;Accessibility for Transportation Planning: Measuring People’s Ability to Reach Desired Goods and Activities.&amp;quot; 27 February 2017. Todd Litman. Victoria Transport Policy Institute. http://www.vtpi.org/access.pdf&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Accessibility is nearly always 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. &lt;br /&gt;
&lt;br /&gt;
==Accessibility vs. Mobility==&lt;br /&gt;
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 unreasonably long. Accessibility directly addresses these questions by measuring people's ability to reach desired destinations.&lt;br /&gt;
&lt;br /&gt;
==Decay vs. Cut-offs==&lt;br /&gt;
One major distinction in measuring accessibility is how parameters are set for determining whether a destination is accessible. One method is to create a time cut-off. For example, one can ask &amp;quot;how many jobs can be reached in 30 minutes using transit from a given location?&amp;quot; or &amp;quot;how many household/job combinations are there within 30 minutes of each other along a transit line or within a transit system?&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
===Time cut-off===&lt;br /&gt;
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.&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Decay===&lt;br /&gt;
[[File:Decay function.png|thumb|A decay function showing the change in weighted values for different modes and destination as travel time increases&amp;lt;ref&amp;gt;&amp;quot;Operationalizing Accessibility: Tools and Practices.&amp;quot; State Smart Transportation Initiative. 30 March 2017. http://www.ssti.us/Events/operationalizing-accessibility-part-1-tools-and-practices/&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
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.&lt;br /&gt;
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.)&lt;br /&gt;
&lt;br /&gt;
==First and Last Mile==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Buffers===&lt;br /&gt;
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.&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Using the street network===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Destinations==&lt;br /&gt;
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.&lt;br /&gt;
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&amp;lt;ref&amp;gt;&amp;quot;Commuting in America 2013:​​ The National Report on​ Commuting Patterns and Trends​.&amp;quot; American Association of State Highway and Transportation Officials. http://traveltrends.transportation.org/Pages/default.aspx&amp;lt;/ref&amp;gt;​, 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.&lt;br /&gt;
&lt;br /&gt;
==Population Analysis==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Example Tools==&lt;br /&gt;
Some tools that measure accessibility are discussed below&lt;br /&gt;
&lt;br /&gt;
*[[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. &lt;br /&gt;
[[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.&amp;lt;ref&amp;gt;Conveyal analysis-ui documentation. Accessed 20 April 2017. http://analysis-ui.readthedocs.io/en/latest/analysis/#spectrogram&amp;lt;/ref&amp;gt; ]]&lt;br /&gt;
*[[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.&lt;br /&gt;
*[[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.&lt;br /&gt;
&lt;br /&gt;
==Further Reading==&lt;br /&gt;
*&amp;quot;The Why and How of Measuring Access to Opportunity: A Guide to Performance Management.&amp;quot; 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 &lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
&amp;lt;references /&amp;gt;&lt;/div&gt;</summary>
		<author><name>Leeor</name></author>
	</entry>
</feed>