BetterBusBuffers (version 0.3.

2 beta)
This is a users guide for the BetterBusBuffers Polygon Tool and the BetterBusBuffers Point Tool. Scroll
down to see the Point Tool part.

BetterBusBuffers Polygon Tool (version 0.3.2 beta)

Users Guide
Last updated: 18 December 2012
Created by Melinda Morang, Esri
e-mail: [email protected]
For examples and updates, see http://transit.melindamorang.com

This users guide for the BetterBusBuffers Polygon Tool gives simple instructions for how to calculate
your transit service buffers.

What this tool does

The BetterBusBuffers Polygon Tool provides a quantitative measure of access to public transit in your
city. It creates buffers around the transit stops and weights them by the number of trips that pass that
stop during the time window you select. Output can be shown as the total number of trips or the
average number of trips per hour during the time window. You can use the symbology settings of the
resulting feature class to highlight the frequency of service in different areas of town. Note that the tool
tells you nothing about the destination of the buses that pass by the stops, only how many of them
there are. BetterBusBuffers uses GTFS public transit data and ArcGIS Network Analyst.
Software requirements
ArcGIS 10.0 or 10.1 with a Desktop Advanced (ArcInfo) license. The tool is likely to run faster in
10.1. (Dont have the Desktop Advanced license? Im considering finding a way to make it work
with a Standard license. E-mail me if this is important to you!)
Network Analyst extension (for the full version of the tool). If you dont have Network Analyst,
you can still run the tool using the version that uses circular buffers instead of Service Areas.
Python 2.5 or higher (should be installed with ArcGIS)
Downloading GTFS_NATools
Download the zip file from
http://www.arcgis.com/home/item.html?id=42e57c5ff9a0497f831f4fced087b9b0. Save it
anywhere you like, and unzip it. The package contains a .tbx toolbox file, a folder of python
scripts needed to run the toolbox, and a copy of this users guide.
No installation is necessary. You can run the tool from ArcCatalog, or you can run it from
ArcMap. If running the tool from ArcCatalog, just navigate to the folder in which you saved the

toolbox. If running it from ArcMap, use the ArcCatalog panel or right-click in ArcToolbox and
click Add Toolbox. Navigate to where you saved the toolbox and add it.
Data preparation
GTFS data
Download GTFS data for the transit authority or authorities you wish to analyze. Check the
transit authoritys website or look at http://www.gtfs-data-exchange.com/. You can analyze
multiple GTFS datasets at a time, which makes the most sense if the transit authorities serve the
same geographic areas.
Unzip the GTFS data into folders of your choice. A GTFS dataset should be a set of .txt files. This
tool uses the following files: stops.txt, stop_times.txt, trips.txt, and calendar.txt. Note: Some
GTFS datasets use the calendar_dates.txt file instead of the calendar.txt file. This tool only
supports GTFS datasets that contain a calendar.txt file.
Before running the tool, you should open the calendar.txt file and make sure you understand it.
This file contains a service_id, a start and end date, and a column for each day of the week. See
https://developers.google.com/transit/gtfs/reference#calendar_fields for a description of
calendar.txt.
Check the start and end dates for each row. If you have non-overlapping date ranges in your
file, it will cause problems when you run the tool. The tool will count all trips that occur on the
day of the week you select, even if those trips occur in non-overlapping date ranges. Effectively,
it will be double-counting trips that should not be double-counted. If you have non-overlapping
date ranges, you need to make a copy of your calendar.txt file and modify the data in the file to
remove the non-overlapping date ranges. For example, if your file has a set of service_ids for
the summer months and a set for the winter months, and youre interested in analyzing the
summer months, delete all the rows with date ranges for the winter months. Make sure your
cleaned up file is still called calendar.txt.
If you are analyzing multiple GTFS datasets at a time, and the datasets have non-overlapping
date ranges, you will get the same error as you will if service_ids in one dataset have nonoverlapping date ranges. The date range problem is less of an issue (or not an issue at all) if it
occurs in different datasets, but you should double-check anyway to make sure you understand
your data.
You do NOT need to do anything else with the .txt files. If you want to look at the locations of
the stops, you can load the stops.txt file into ArcMap using Add XY Data, but you do not need to
do this in order to use BetterBusBuffers. BetterBusBuffers just needs to know the folder
containing the .txt files, and it will handle it from there.
Warning: GTFS datasets can be very large.
Network Dataset
You need an ArcGIS Network Dataset with a streets network for the area you plan to analyze. A
streets network for the entire United States should be available in the Data & Maps DVD you
received from ESRI with your ArcGIS software. Note: You do NOT need a network dataset that
contains transit information. You do not need a Network Dataset if you are using the circular
buffer version of the tool.

Workflow
This tool contains two parts. Step 1 need only be run once for a given geography and buffer size (eg,
Chicago and 0.25 miles). Step 1 simply creates some tables and feature classes to be referenced by Step

2. In Step 2, which generally runs much faster than Step 1, you select the time window you wish to
analyze and generate the actual output you will want to analyze.
You can run this tool from ArcCatalog or ArcMap. If running the tool from ArcCatalog, just navigate to
the folder in which you saved the toolbox. If running it from ArcMap, either use the ArcCatalog panel or
right-click in ArcToolbox and click Add Toolbox. Navigate to where you saved the toolbox and add it.
If you have a Network Analyst license, please use the regular version of Step 1. If you do not have a
Network Analyst license, please use the special version called Step 1 Preprocess GTFS and Buffers (No
Network Analyst).

Running Step 1 Preprocess GTFS and Buffers

Step 1 does the following:
Creates service areas around your transit stops
Runs some post-processing on those service areas to prepare them for further analysis
Turns the GTFS data into a set of SQL tables for use in further analysis
You should only have to run Step 1 once for the geography and buffer size you are analyzing. Step 1 will
take a while to run for larger transit systems. For instance, 0.25-mile buffers in Chicago took 19 minutes
to run on my computer.

Inputs
Output directory: Select a folder into which the geodatabase generated by Step 1 will be
placed.
Name for output geodatabase (created when the tool is run): A name for the file geodatabase
where Step 1 results will be stored. This geodatabase will be created when the tool runs, and all
Step 1 output will be placed inside it. You cannot overwrite an existing geodatabase. Filename
may not contain special characters. The .gdb extension is optional.
GTFS directory: The folder containing your (unzipped) GTFS .txt files. The tool uses the .txt files
directly, so you need not turn them into shapefiles or process them in any way. You can select
multiple GTFS datasets to analyze simultaneously.
Network Dataset: The network dataset to use. If you dont have your own Network Dataset,
check the Data and Maps DVD that came with your ArcGIS installation CDs.
Impedance attribute (Choose one that works for pedestrians.): The attribute from your
network dataset which you will use to calculate the network distance or time around transit

stops. Unless you have a pedestrian travel time attribute in your network dataset, choose an
impedance attribute with units of distance.
Buffer size (in the same units as your impedance attribute): The size of the buffers around your
transit stops. This indicates the maximum distance from your stops that will be shown as
accessible from those stops. This value must be in the same units as the impedance attribute
you selected above.
Network restrictions (choose ones appropriate for pedestrians) (optional): List of possible
restrictions from your network file that you can choose to impose. For example, checking the
restriction Toll prevents your pedestrians from walking on toll roads. The available
restrictions vary depending on your network dataset, and the list is dynamically loaded from the
streets network you select. Choose the restrictions that are the most sensible for pedestrians.

Outputs
All output files end up in a file geodatabase with the name you specified in the directory you selected.
Step1_Stops: A feature class version of the stops.txt GTFS file. This is just a points layer of your
transit stops that you can look at if you want to.
Step1_FlatPolys: The service area polygons for your entire network, broken up into pieces to
eliminate overlaps. This is a template for your Step 2 output. Step 2 fills this file with the
number of trips during your time window. You do not need to look at this template file for
anything.
Step1_StackedPoints: An intermediate file used in Step 2 for transferring attributes to the final
output. You do not need to look at this file for anything.
Step1_GTFS.sql: An sql database containing your GTFS data. Used in Step 2.
Step1_log.txt: A text file containing the run date, the input and output file paths, the settings
you selected for this run, and error or warning messages that occurred, for future reference.

Running Step 1 Preprocess GTFS and Buffers (No Network Analyst)

This version of Step 1 should only be used by people who do not have a Network Analyst license. It
creates circular buffers around your transit stops instead of real service areas that refer to the streets
network. Circular buffers generally overestimate the area reachable from the transit stop.
Step 1 does the following:
Creates circular buffers around your transit stops
Runs some post-processing on those buffer polygons to prepare them for further analysis
Turns the GTFS data into a set of SQL tables for use in further analysis
You should only have to run Step 1 once for the geography and buffer size you are analyzing.

Inputs
Output directory: Select a folder into which the geodatabase generated by Step 1 will be
placed.
Name for output geodatabase (created when the tool is run): A name for the file geodatabase
where Step 1 results will be stored. This geodatabase will be created when the tool runs, and all
Step 1 output will be placed inside it. You cannot overwrite an existing geodatabase. Filename
may not contain special characters. The .gdb extension is optional.
GTFS directory: The folder containing your (unzipped) GTFS .txt files. The tool uses the .txt files
directly, so you need not turn them into shapefiles or process them in any way. You can select
multiple GTFS datasets to analyze simultaneously.
Buffer units: Use the drop-down menu to select the length units you wish to use to indicate
your buffers size.

Buffer size (in the units you selected above): The size of the circular buffers around your transit
stops. This indicates the maximum distance from your stops that will be shown as accessible
from those stops. This value must be in the units you selected above.

Outputs
All output files end up in a file geodatabase with the name you specified in the directory you selected.
Step1_Stops: A feature class version of the stops.txt GTFS file. This is just a points layer of your
transit stops that you can look at if you want to.
Step1_FlatPolys: The buffer polygons for your entire network, broken up into pieces to
eliminate overlaps. This is a template for your Step 2 output. Step 2 fills this file with the
number of trips during your time window. You do not need to look at this template file for
anything.
Step1_StackedPoints: An intermediate file used in Step 2 for transferring attributes to the final
output. You do not need to look at this file for anything.
Step1_GTFS.sql: An sql database containing your GTFS data. Used in Step 2.
Step1_log.txt: A text file containing the run date, the input and output file paths, the settings
you selected for this run, and error or warning messages that occurred, for future reference.

Running Step 2 Create Weighted Service Areas

Step 2 does the following:
Calculates the number of bus trips that serve all areas within your transit stop buffers during the
time window and writes the results to a feature class
Step 2 uses Step 1 output as input. Re-run Step 2 for each time window you wish to analyze.

Inputs
Step 1 results geodatabase: The geodatabase produced when you ran Step 1. This
geodatabase must contain the following files: Step1_GTFS.sql; Step1_FlatPolys;
Step1_StackedPoints.
Output feature class: Create a feature class for your BetterBusBuffers. This is the final output
you will analyze. A feature class in a file geodatabase is highly recommended instead of a
shapefile.
Day of week: Choose the day of the week you wish to consider. Note: If you want to analyze
multiple days, you can run the tool once for each day, join the output files, and use Calculate
Field to sum the number of trips in each polygon.
Time window start (HH:MM) (24-hour time): The lower end of the time window you wish to
analyze. Must be in HH:MM format (24-hour time). For example, 2am is 02:00, and 2pm is
14:00. If you leave this blank, the time window will begin at 00:00 (12:00AM on the morning of
the day you select).
Time window end (HH:MM) (24-hour time): The upper end of the time window you wish to
analyze. Must be in HH:MM format (24-hour time). For example, 2am is 02:00, and 2pm is
14:00. If you leave this blank, the time window will begin at 23:59 (11:59PM on the night of the
day you select).
Travel direction (From=>Walking away from stop; To=>Walking toward stop): Select travel
direction. TRAVEL_TO indicates that the pedestrian walks toward the stop. Stop visits are
calculated using departure times. TRAVEL_FROM indicates that the pedestrian starts at the
stop and walks away from it. Stop visits are calculated using arrival times. These two settings
will probably make very little difference.

Outputs
[Output feature class]: The file you selected when running the tool. This is a polygon layer
covering your entire transit network. Your original buffers have been broken up to eliminate
overlapping polygons. The NumTrips field indicates the total number of unique transit trips
serving that area (within your buffers distance) during the time window you selected. The
NumTripsPerHr field indicates the average number of unique transit trips per hour serving that
area during your time window.
[Output feature class name]_log.txt: A text file containing the run date, the input and output
file paths, the settings you selected for this run, and error or warning messages that occurred,
for future reference.

Troubleshooting & potential pitfalls

Note: You can always check your log file to see the settings you used and any warning or error
messages that arose.
The tool takes forever to run: There are several reasons.
- Very large transit datasets simply take a long time.
- Very large time windows will slow Step 2 down considerably.
- The tool will run faster in ArcGIS 10.1 than it will in ArcGIS 10.0.
- The tool will run slower if you are writing to and from a network drive.
My GTFS data doesnt contain a calendar.txt file: Some GTFS datasets use the
calendar_dates.txt file instead of the calendar.txt file. BetterBusBuffers does not currently
support GTFS datasets that use that alternate method. If this feature is important to you, send
me an e-mail.
I got a warning message saying I had non-overlapping date ranges: This is because of the way
your GTFS data has constructed its calendar.txt file, or because your GTFS datasets (if you have
multiple datasets) do not cover the same date ranges. Open the calendar.txt file in each dataset
and make sure you understand it. This file contains a service_id, a start and end date, and a
column for each day of the week. See
https://developers.google.com/transit/gtfs/reference#calendar_fields for a description of
calendar.txt.
Check the start and end dates for each row. If you received a warning message, then your data
contains date ranges that do not overlap (ie, the start date of at least one service_id is later than
the end date of at least one other service_id). If you have non-overlapping date ranges in your
file, it can cause problems when you run the tool. The tool will count all trips that occur on the
day of the week you select, even if those trips occur in non-overlapping date ranges. Effectively,
it will be double-counting trips that should not be double-counted. If you have non-overlapping
date ranges, you need to make a copy of your calendar.txt file and modify the data in the file to
remove the non-overlapping date ranges. For example, if your file has a set of service_ids for
the summer months and a set for the winter months, and youre interested in analyzing the
summer months, delete all the rows with date ranges for the winter months. Make sure your
cleaned up file is still called calendar.txt so the tool recognizes it.
If you are analyzing multiple GTFS datasets at a time, and the datasets have non-overlapping
date ranges, you will get the same error as you will if service_ids in one dataset have nonoverlapping date ranges. The date range problem is less of an issue (or not an issue at all) if it

occurs in different datasets, but you should double-check anyway to make sure you understand
your data.
Maximum sample size reached when changing symbology: If you have a very large output
feature class, you might run into some problems changing the symbology. On the symbology
tab, if you set the symbology to Quantities and use NumTrips as the Value field, you might get
a warning message that says Maximum sample size reached. Not all records are being used.
Use this sample or change maximum sample size. This simply means that your output file is
large and that the classification and color ramp arent looking at all the values in your table, only
a certain sample of them. Its possible that it wont find the minimum or maximum value in your
table and that the color ramp will not include those values. This problem is easy to fix. First
open your attributes table and figure out how many rows are in your table. Then, in the
symbology window, click the Classify button. Click Sampling Change the Maximum
Sample Size to something larger than the number of entries in your table.
Polygon outlines are obscuring your color-coded polygons: On the Symbology tab, select all
the entries in your symbol menu by holding the Shift key. Right click, and choose Properties for
All Symbols. Under Outline Color, choose No Color.
If you are stuck, please e-mail me. If you are getting error messages, please send me your log
file.

Tool updates currently in progress or being considered

A version of the tool that does not require the Desktop Advanced (ArcInfo) license.
More complex time windows
Please contact me if you are interested in any of these updates or have ideas for other updates.

BetterBusBuffers Point Tool (version 0.3.2 beta)

Users Guide
Last updated: 22 March 2012
Created by Melinda Morang, Esri
e-mail: [email protected]
For examples and updates, see http://transit.melindamorang.com

This users guide for the BetterBusBuffers Point Tool gives simple instructions for how to calculate the
number of transit trips available to specific points on your map.

What this tool does

The BetterBusBuffers Point Tool provides a quantitative measure of access to public transit in your city.
You give the tool a set of points you wish to analyze, and the tool finds all the stops within a buffer
distance of those points and counts the number of trips that serve those stops during the time window
you select. The output shows the total number of trips and the average number of trips per hour during
the time window. You can use the symbology settings of the resulting feature class to highlight the
frequency of service for your points. Note that the tool tells you nothing about the destination of the
buses that pass by the stops, only how many of them there are. BetterBusBuffers uses GTFS public
transit data and ArcGIS Network Analyst.
Software requirements
ArcGIS 10.0 or higher with a Desktop Basic (ArcView) license. The tool is likely to run faster in
10.1.
Network Analyst extension
Python 2.5 or higher (should be installed with ArcGIS)
Downloading GTFS_NATools
Download the zip file from
http://www.arcgis.com/home/item.html?id=42e57c5ff9a0497f831f4fced087b9b0. Save it
anywhere you like, and unzip it. The package contains a .tbx toolbox file, a folder of python
scripts needed to run the toolbox, and a copy of this users guide.
No installation is necessary. You can run the tool from ArcCatalog, or you can run it from
ArcMap. If running the tool from ArcCatalog, just navigate to the folder in which you saved the
toolbox. If running it from ArcMap, use the ArcCatalog panel or right-click in ArcToolbox and
click Add Toolbox. Navigate to where you saved the toolbox and add it.
Data preparation
GTFS data
Download GTFS data for the transit authority or authorities you wish to analyze. Check the
transit authoritys website or look at http://www.gtfs-data-exchange.com/. You can analyze
multiple GTFS datasets at a time, which makes the most sense if the transit authorities serve the
same geographic areas.

Unzip the GTFS data into folders of your choice. A GTFS dataset should be a set of .txt files. This
tool uses the following files: stops.txt, stop_times.txt, trips.txt, and calendar.txt. Note: Some
GTFS datasets use the calendar_dates.txt file instead of the calendar.txt file. This tool only
supports GTFS datasets that contain a calendar.txt file.
Before running the tool, you should open the calendar.txt file and make sure you understand it.
This file contains a service_id, a start and end date, and a column for each day of the week. See
https://developers.google.com/transit/gtfs/reference#calendar_fields for a description of
calendar.txt.
Check the start and end dates for each row. If you have non-overlapping date ranges in your
file, it will cause problems when you run the tool. The tool will count all trips that occur on the
day of the week you select, even if those trips occur in non-overlapping date ranges. Effectively,
it will be double-counting trips that should not be double-counted. If you have non-overlapping
date ranges, you need to make a copy of your calendar.txt file and modify the data in the file to
remove the non-overlapping date ranges. For example, if your file has a set of service_ids for
the summer months and a set for the winter months, and youre interested in analyzing the
summer months, delete all the rows with date ranges for the winter months. Make sure your
cleaned up file is still called calendar.txt.
If you are analyzing multiple GTFS datasets at a time, and the datasets have non-overlapping
date ranges, you will get the same error as you will if service_ids in one dataset have nonoverlapping date ranges. The date range problem is less of an issue (or not an issue at all) if it
occurs in different datasets, but you should double-check anyway to make sure you understand
your data.
You do NOT need to do anything else with the .txt files. If you want to look at the locations of
the stops, you can load the stops.txt file into ArcMap using Add XY Data, but you do not need to
do this in order to use BetterBusBuffers. BetterBusBuffers just needs to know the folder
containing the .txt files, and it will handle it from there.
Warning: GTFS datasets can be very large.
Network Dataset
You need an ArcGIS Network Dataset with a streets network for the area you plan to analyze. A
streets network for the entire United States should be available in the Data & Maps DVD you
received from ESRI with your ArcGIS software. Note: You do NOT need a network dataset that
contains transit information.
Points to Analyze
You can use any points feature class, but it must have a Unique ID field. OBJECTID is acceptable
as a Unique ID field.

Workflow
This tool contains two steps. The first step, Step 1 - Preprocess GTFS, is a simple preprocessing step that
need only be run once for a given set of GTFS datasets. This step simply creates some SQL tables to be
referenced by Step 2 - Count Transit Trips. In Step 2, which generally runs much faster than Step 1, you
select points to analyze, select your time window, and generate the actual output you will want to
analyze. Note: If you have already run Step 1 of the BetterBusBuffers Polygon Tool and generated a
GTFS SQL file that way, you do not need to run the preprocessing step. You can use your existing SQL
file in Step 2.

You can run this tool from ArcCatalog or ArcMap. If running the tool from ArcCatalog, just navigate to
the folder in which you saved the toolbox. If running it from ArcMap, either use the ArcCatalog panel or
right-click in ArcToolbox and click Add Toolbox. Navigate to where you saved the toolbox and add it.
Running Step 1 - Preprocess GTFS
Step 1 - Preprocess GTFS does the following:
Turns the GTFS data into a set of SQL tables for use in further analysis
You should only have to run Step 1 - Preprocess GTFS once for the GTFS dataset(s) you are analyzing.
This step may take several minutes to run for larger transit systems. Note: If you have already run Step 1
of the BetterBusBuffers Service Area tool and generated a GTFS SQL file that way, you do not need to
run this preprocessing step. You can use your existing SQL file in Step 2.

Inputs
GTFS directories: The folder containing your (unzipped) GTFS .txt files. The tool uses the .txt
files directly, so you need not turn them into shapefiles or process them in any way. You can
select multiple GTFS datasets to analyze simultaneously.
Name and location for output SQL database: This is the output file the preprocessing step
creates. Navigate to a location where you will be able to find the file and give it a filename you
will remember. You will have to refer to this file when you run Step 2. The .sql file extension
is optional.
Outputs
[Your designated output filename]: A database containing your GTFS data. Used in Step 2.

Running Step 2 - Count Transit Trips

Step 2 - Count Transit Trips does the following:
Calculates the number of transit trips that serve the points you are analyzing.
Step 2 uses the SQL database you created in the Step 1. Re-run Step 2 - Count Transit Trips for each time
window and/or set of points you wish to analyze.

Inputs
Output feature class: Create a feature class for your output. This will be a points feature class
identical to your input points with three fields added. A feature class in a file geodatabase is
highly recommended instead of a shapefile.
SQL dbase of preprocessed GTFS data: The SQL file you created in Step 1 (or when running the
BetterBusBuffers Polygon Tool).

Points to Analyze: A set of point features in your city you wish to analyze. The tool calculates
the frequency of transit service available to these points.
Unique ID field for Points to Analyze: Field in your points layer that serves as a unique
identifier. The program needs this in order to correctly keep track of the transit trips available
to each point. This field is a drop-down list and is dynamically loaded with possible field choices
after you select your points file.
Day of week: Choose the day of the week you wish to consider. Note: If you want to analyze
multiple days, you can run the tool once for each day, join the output files, and use Calculate
Field to sum the number of trips in each polygon.
Time window start (HH:MM) (24-hour time): The lower end of the time window you wish to
analyze. Must be in HH:MM format (24-hour time). For example, 2am is 02:00, and 2pm is
14:00. If you leave this blank, the time window will begin at 00:00 (12:00AM on the morning of
the day you select).
Time window end (HH:MM) (24-hour time): The upper end of the time window you wish to
analyze. Must be in HH:MM format (24-hour time). For example, 2am is 02:00, and 2pm is
14:00. If you leave this blank, the time window will begin at 23:59 (11:59PM on the night of the
day you select).
Network dataset: Your network dataset of streets, sidewalks, etc.
Impedance attribute (Choose one that works for pedestrians.): The attribute from your
network dataset which you will use to calculate the maximum distance or time your pedestrians
can walk between the points you are analyzing and the transit stops. Unless you have a
pedestrian travel time attribute in your network dataset, choose an impedance attribute with
units of distance.
Max travel time or distance between points and stops (in the units of your Impedance
Attribute): Choose the maximum time or distance your pedestrians can walk between the
points you are analyzing and the transit stops. This MUST be in the same units as the
impedance attribute you select. For example, if you want to limit pedestrian walk distance to a
quarter of a mile, choose an impedance attribute in units of miles and enter 0.25. If your
network dataset has a pedestrian walk time attribute and you want to limit walk time to 10
minutes, select the pedestrian walk time impedance attribute and enter 10.
Network restrictions (Choose ones appropriate for pedestrians.) (optional): List of possible
restrictions from your network dataset that you can choose to impose. For example, checking
the restriction Toll prevents your pedestrians from walking on toll roads. The available
restrictions vary depending on your network dataset, and the list is dynamically loaded from the
streets network you select. Choose the restrictions that are the most sensible for pedestrians.
Travel direction (From=>Walking away from stop; To=>Walking toward stop): Select travel
direction. TRAVEL_TO indicates that the pedestrian walks toward the stop from the input
points. Stop visits are calculated using departure times. TRAVEL_FROM indicates that the
pedestrian starts at the stop and walks away from it, toward the input points. Stop visits are
calculated using arrival times. These two settings will probably make very little difference.

Outputs
[Output feature class]: The file you selected when running the tool. This points layer is simply a
modified version of your input points, containing three new fields. The NumTrips field indicates
the total number of unique transit trips serving the point (within the travel time or distance
limit) during the time window you selected. The NumTripsPerHr field indicates the average
number of unique transit trips per hour serving that point during your time window. The

NumStopsInRange field simply indicates the number of stops that were within the travel time or
distance limit of the input point.
[Output feature class name]_log.txt: A text file containing the run date, the input and output
file paths, the settings you selected for this run, and error or warning messages that occurred,
for future reference.

Troubleshooting & potential pitfalls

Note: You can always check your log file to see the settings you used and any warning or error
messages that arose.
The tool takes forever to run: Step 2 should finish in under 10 minutes or so. If it does not,
there might be some other problem. If everything is running correctly, the following conditions
will cause the tool to take longer to run:
- Very large time windows will take longer to process
- Very large transit datasets will take longer to process.
- A large number of input points will take longer to process.
- The tool will run faster in ArcGIS 10.1 than it will in ArcGIS 10.0.
- The tool will run slower if you are writing to and from a network drive.
My GTFS data doesnt contain a calendar.txt file: Some GTFS datasets use the
calendar_dates.txt file instead of the calendar.txt file. BetterBusBuffers does not currently
support GTFS datasets that use that alternate method. If this feature is important to you, send
me an e-mail.
I got a warning message saying I had non-overlapping date ranges: This is because of the way
your GTFS data has constructed its calendar.txt file, or because your GTFS datasets (if you have
multiple datasets) do not cover the same date ranges. Open the calendar.txt file in each dataset
and make sure you understand it. This file contains a service_id, a start and end date, and a
column for each day of the week. See
https://developers.google.com/transit/gtfs/reference#calendar_fields for a description of
calendar.txt.
Check the start and end dates for each row. If you received a warning message, then your data
contains date ranges that do not overlap (ie, the start date of at least one service_id is later than
the end date of at least one other service_id). If you have non-overlapping date ranges in your
file, it can cause problems when you run the tool. The tool will count all trips that occur on the
day of the week you select, even if those trips occur in non-overlapping date ranges. Effectively,
it will be double-counting trips that should not be double-counted. If you have non-overlapping
date ranges, you need to make a copy of your calendar.txt file and modify the data in the file to
remove the non-overlapping date ranges. For example, if your file has a set of service_ids for
the summer months and a set for the winter months, and youre interested in analyzing the
summer months, delete all the rows with date ranges for the winter months. Make sure your
cleaned up file is still called calendar.txt so the tool recognizes it.
If you are analyzing multiple GTFS datasets at a time, and the datasets have non-overlapping
date ranges, you will get the same error as you will if service_ids in one dataset have nonoverlapping date ranges. The date range problem is less of an issue (or not an issue at all) if it
occurs in different datasets, but you should double-check anyway to make sure you understand
your data.

If you are stuck, please e-mail me. If you are getting error messages, please send me your log
file.

Tool updates currently in progress or being considered

More complex time windows
Support for polygon input files (instead of just points). Think census blocks or city parks.
Please contact me if you are interested in any of these updates or have ideas for other updates.