How to add GTFS data to a network dataset

How to add GTFS data to a network dataset
Add GTFS to a Network Dataset – version 0.3.0
These instructions explain how to add GTFS public transit data to an ArcGIS network dataset.
Melinda Morang, ESRI
mmorang@esri.com
909-793-2853 x3315
Last updated: May 20, 2014
Please don’t hesitate to contact me with problems, questions, or comments about this tool. Esri is
researching ways to improve our public transit analysis capabilities, and your feedback on this tool will
help us in our future development efforts. Thanks!
Brief overview
In order to use GTFS routes, stops, and schedules in a network dataset, you must do the following steps,
which are explained in further detail in this document:
1) Download and install the tools
2) Acquire your data and prepare your feature dataset
3) Generate feature classes for transit lines and stops
4) Create connector features between the transit lines/stops and your other data
5) Create your network dataset using correct connectivity groups and configure your network
attributes
6) Generate a transit schedule table
7) Choose the correct analysis settings
1) Download and install the tools
Download Add GTFS to a Network Dataset from ArcGIS Online and unzip it.
First, you need to “register” a special GTFS transit evaluator. Run
Install_forArcGIS10.1.bat or Install_forArcGIS10.2.bat by simply double-clicking
on it. Choose the correct one for the version of ArcGIS you have installed on
your machine (use Install_forArcGIS10.2.bat for 10.2, 10.2.1, and 10.2.2). If the
installation succeeds, you will get a pop-up box saying so:
If the install fails for some reason, you can open the Install*.bat file (right-click it and click Edit). Make
sure the path on your computer to the file called ESRIRegAsm.exe matches what’s written in the file. If
it doesn’t, modify the file and see if that makes it work.
If you get the error message “Registration failed. Could not load file or assembly…Operation is not
supported.”: Your computer might have blocked the TransitEvaluator.dll file as a security risk because it
came from another computer. In the EvaluatorFiles folder, right click TransitEvaluator.dll and click
Properties. If there is an Unblock button at the bottom click it, and then try running Install*.bat again.
If you get an error saying “Registration failed. Could not write to disk”: You probably need to run the
.bat file as an administrator. Right click on Install.bat and choose “Run as Administrator”. If it fails again
and says it can’t find the specified path to the .dll file, open the .bat file for editing and change the
“%CD%” in the .dll path to the correct path on your machine.
If, at any point in the future, you wish to uninstall the special GTFS transit evaluator, you can use the
Uninstall*.bat file to clear it from your computer’s registry.
Note: If you create a network dataset that uses the GTFS transit evaluator and then uninstall the GTFS
transit evaluator, you will not be able to use or delete the network dataset from your machine unless you
reinstall the GTFS transit evaluator. Similarly, a network dataset created on a machine with the GTFS
transit evaluator installed will not work on a different machine that does not
have the GTFS transit evaluator installed. If you try to open or delete one of
these network datasets on a machine without the GTFS transit evaluator, you
will get an error message saying “Failed to edit the selected object(s). The item
does not have a definition. FDO error -2147212634”.
Note: Do not move TransitEvaluator.dll file from its current location or rename any of the folders in its
file path without first uninstalling it. Otherwise, it will break the file path in your computer’s registry,
and the evaluator may not work properly.
Note: If you upgrade ArcGIS from 10.1 to 10.2 (or 10.2.1 or 10.2.2), you should uninstall the 10.1 version
of the transit evaluator and install the 10.2 version to ensure that everything works properly.
2) Acquire your data and prepare your feature dataset
First acquire the GTFS data you plan to use.
 Obtain the GTFS data for the transit authority (or authorities) you wish to analyze. Check with
the transit authority directly or check the GTFS Data Exchange. You may use more than one
GTFS dataset if you want (e.g., for two different agencies operating in the same city).
 Unzip the GTFS data into a folder of your choice. The dataset should be a set of .txt files. You
do not need to do anything else with the data.
 GTFS datasets that use calendar.txt, calendar_dates.txt, and/or frequencies.txt for their
schedules are supported.
 Note: Some GTFS datasets give specific arrival_times and departure_times only for designated
time points in the network, leaving the times for intermediate stops blank. Although this is a
valid way to write a GTFS file, our tools currently require an explicit stop time for every stop visit.
If your GTFS dataset has blank stop times, you will not be able to use it in your network dataset.
The 1) Generate Transit Lines and Stops tool will check your data and give you an error message
if it has blank stop times.
Next, acquire a streets or sidewalks feature class for your area of interest and any other data you wish
to include in your network. You should, at minimum, have a streets feature class. If you try to create a
network dataset using only transit lines, the pedestrians will have no way to walk between transit stops
and their origins or destinations or to walk between nearby stops for transfers.
Finally, create a file geodatabase and feature dataset where you will put your new network dataset.
If you are unfamiliar with the procedure for creating file geodatabases or feature datasets, please
review the documentation:
Creating a file geodatabase
Creating a feature dataset
3) Generate feature classes for transit lines and stops
In the Add GTFS to network dataset toolbox, run the tool called 1) Generate Transit Lines and Stops.
This tool will take several minutes to run for a large dataset.
Tool inputs
 GTFS directories: Select the directory or directories where your GTFS data is stored. You may
select as many GTFS datasets as you wish to include in your network dataset.
 Feature dataset where network dataset will be created: Indicate the location of the feature
dataset where your network dataset will be created.
This tool produces the following output
 Stops: Points feature class containing your transit stops. Stop IDs have the GTFS directory
prepended to them. If you used multiple GTFS datasets, the stops from all of them will be
included in this feature class. This feature class will be located in the feature dataset you
selected as input.
 TransitLines: Lines feature class containing your transit lines. A line has been created between
each pair of stops that is directly connected by a transit trip (ie, has no other stops between
them). In cases where two stops are directly connected by multiple modes, such as both bus
and tram), a separate line will be created for each mode. The lines do NOT correspond to the
actual route taken by the transit vehicles. They are simply straight lines between connected
stops. This feature class will be located in the feature dataset you selected as input.

GTFS.sql: SQL database containing processed GTFS data. This database is located in the
geodatabase that houses the feature dataset you selected and will be used for further
preprocessing. You shouldn’t need to look at this for anything, but don’t delete it.
4) Create connector features between the transit lines/stops and your
other data
A well-constructed network dataset requires connectivity between the source features: streets, transit
lines, stops, etc. Two streets that do not touch one another will not be connected in the network, and
travelers will not be able to travel directly between these two streets. Two streets that touch each
other but do not share endpoints or vertices will also not be connected in the network. A street and a
transit line in different connectivity groups will only connect at the points you specify when you set up
your network.
When you create your network dataset, you want your pedestrians to be able to travel between the
streets and the transit lines, but you only want them to be able to transition between streets and transit
lines at the locations of stops. Pedestrians can only enter and exit the bus/train at stops. They cannot
jump off halfway between stops and start walking on the street to get to their destination. Later, you
will set up connectivity groups in your network to model the correct behavior. But first, you must create
connector lines to ensure that the GTFS stops connect to both the transit lines and the streets.
The GTFS stops probably do not fall directly on top of your streets data (or sidewalks, etc).
Consequently, you should make some small connector lines that bridge the gap between the stops and
the nearest street. Create a lines feature class of connectors, keeping in mind the following:
 Connector lines should attach to the streets in the location where pedestrians will enter the
transit system – the street location of the bus stop or the entrance to an underground or inside
station.
 Connector lines can be used in the network dataset to apply a time delay for boarding and/or
getting off the transit vehicles.
 Sometimes street data contains information about whether or not a street is traversable by
pedestrians. If it does, you want to make sure your stop does not get connected to a nontraversable street because then pedestrians will never be able to use that stop.
 When you create your network dataset, the network won’t connect overlapping lines unless
they overlap at a vertex or endpoint of both lines. Consequently, when you create connector
lines between the stops and the nearby streets, you will also need to generate vertices or
endpoints on your street features to ensure that the streets actually connect with the connector
lines.
For a simple way to generate connector lines, you can use the included tool called 2) Generate StopStreet Connectors. However, the method you use should be tailored to the data you are using. This
tool is only a rudimentary method.
This is what the Generate Stop-Street Connectors tool does:
 First, this tool creates a copy of your stops and snaps them to your street features. Each
snapped stop will land at the closest point of the closest street feature, as long as it falls within a



particular distance of that street. If you entered a SQL expression, the tool will first use this
expression to select street features by attributes so that stops will only be snapped to streets
that fit this criteria.
Next, the tool generates a line feature connecting the true location of each stop and its snapped
counterpart.
Next, the tool creates a “wheelchair_boarding” field to indicate whether or not the stop is
wheelchair accessible. The values used in this field are derived from the wheelchair_boarding
field in the GTFS stops.txt file. If the stop has a parent station and has a wheelchair_boarding
value of 0, the tool populates the field based on the wheelchair_boarding value for the parent
station.
Finally, the tool creates vertices in the street features at the locations of the snapped stops.
These vertices are necessary for establishing connectivity when you create your network
dataset.
If you have more complex data (e.g., multiple street or sidewalk datasets or information about station
entrances), you might want to invent your own method for connecting your streets and stops.
Note: In order to run the 2) Generate Stop-Street Connectors tool, you must have the Desktop Standard
(ArcEditor) or Desktop Advanced (ArcInfo) license. If you have only the Desktop Basic (ArcView) license,
you must find an alternate method to connect your streets and your transit stops because the Snap tool
is not available.
Tool inputs
 Feature dataset where network dataset will be created: Indicate the location of the feature
dataset where your network dataset will be created.
 Streets feature class to use in the network dataset: Select the streets (or sidewalks) feature
class you will use in your network dataset that you want your stops to be connected to.
 Only connect stops to streets where the following is true: (optional): If your streets contain a
fields indicating if features are traversable by pedestrians, you can use the SQL Query Builder to
create an expression to select only those features here. For example, if your data contains a
field called “AR_PEDEST” which has a value of “Y” if pedestrians are allowed and “N” if they
aren’t, your expression should read “AR_PEDEST” = ‘Y’. When the tool snaps the transit stops to
your street features, it will use only those street features that allow pedestrians. If, later, you
create a restriction attribute on your network dataset using this field in your street data, this
step ensures that no stops will be located on restricted portions of the network.
 Maximum distance from streets that stops might appear: Your GTFS stops are unlikely to be
directly on top of your street features. Enter the maximum distance from your streets that your
stops are likely to be, in meters or feet. This simply serves to limit the search distance and
speed up the run time of the tool. If you find yourself getting a lot of build errors when you
build your network, try rerunning this step with a larger distance here.
 Units of maximum distance value above: Indicate whether the distance you entered above is in
meters or feet.
This tool produces the following output
 Stops_Snapped2Streets: Points feature class containing your transit stops snapped to the
closest streets. This feature class will be located in the feature dataset you selected as input.
 Connectors_Stops2Streets: Lines feature class containing connector lines between your streets
and your GTFS transit stops. This feature class will be located in the feature dataset you selected
as input.
 Streets_UseThisOne: A copy of the streets feature class you selected as input, modified to have
vertices at the locations of your snapped GTFS stops. This is the streets feature class you should
use in your network dataset instead of your original streets feature class.
5) Create your network dataset using correct connectivity groups
Now you are ready to create your network dataset. If you have never created a network dataset, please
review the ‘Creating a multimodal network dataset’ tutorial in the ArcGIS Help before proceeding.
Look in your feature dataset. If you have any other feature classes you would like to include in your
network dataset that are not currently in the feature dataset, you should add them now.
Create a new network dataset in your feature dataset. Right-click the feature dataset in the Catalog
window, click New, and click Network Dataset. Note: If you have not enabled your Network Analyst
license, the New Network Dataset option will not be available. Enable your Network Analyst license in
the Customize toolbar.
Give your network dataset a name, and click Next.
Choose the feature classes from your feature dataset that you will include in your network dataset. You
should check all of the following:
If you have additional feature classes you want to include or if you used a different method for creating
connectors between your transit network and your streets, you should select whatever feature classes
are appropriate.
On the next page, choose whether or not you want to model turns. The transit network does not use
turns, but you can choose to do so if you have turn feature classes or want to use global turns in your
street data.
On the next page, click the Connectivity button. You need to set up your connectivity groups to tell the
network how pedestrians are allowed to travel between the different source features (streets, transit
lines, etc.). If you are unfamiliar with network connectivity concepts, please review the Understanding
connectivity page in the ArcGIS documentation. You should tailor your connectivity groups to your own
data, but you can use the following instructions as a guide for how to do it.
 Create three connectivity group columns. Group 1 is for your streets, Group 2 is for your stopstreet connectors, and Group 3 is for your transit lines. It is essential that the transit lines and
streets reside in different connectivity groups because pedestrians can only change between the
transit system and the streets network at stops.
 Check and uncheck boxes as necessary so that your street features are only checked for Group
1, your connector features are only checked for Group 2, and your transit features are only
checked for Group 3.
 Check and uncheck boxes so that Stops_Snapped2Streets resides in two groups: Group 1 and
Group 2. This makes the snapped stop points junctions between the street features and the
connector lines.



Check and uncheck boxes so that Stops resides in two groups: Group 2 and Group 3. This makes
the stop points junctions between the transit lines and the connector lines.
Leave the Connectivity Policy for TransitLines and Connectors_Stops2Streets as “End Point”
because these features should not connect to each other anywhere except endpoints. Choose
either “End Point” or “Any Vertex” for Streets_UseThisOne, depending on what is most
appropriate for your particular streets network. “End Point” is probably the correct setting.
Leave the Connectivity Policy for Stops as “Honor” because Stops should only connect to transit
lines and connectors at endpoints. If you used the Generate Stop-Street Connectors tool or
some other method that created vertices in your street features at the locations of snapped
stops, change the Connectivity Policy for Stops_Snapped2Streets to “Override”. This allows the
snapped stops to connect to the street feature vertices even if the street feature connectivity is
set to End Point.
After you have finished setting up your connectivity groups, click OK and then click Next to set up your
elevation information. The transit network does not contain elevation information. If you wish to
model elevation of your other source features, you may choose to do so. Otherwise, choose None.
Now you are ready to set up the network dataset’s attributes. Your network may have any attributes
you want. However, in order to use the GTFS transit evaluator, you should create a travel time cost
attribute with units of minutes. The next few paragraphs will guide you through this process. However,
if you don’t know what a network attribute is or want to better understand how cost, restriction, and
other attributes work, you should review the Understanding network attributes page before proceeding.
To create a travel time cost attribute that uses the GTFS transit evaluator, do the following:
 Click Add to create a new attribute.
 Give the new attribute a name, set the Usage Type to Cost, the Units to Minutes, and the Data
Type to Double. You will probably want this to be the default cost attribute, so check the box
that says Use by Default.




Now you need to tell the network
dataset how to determine the travel
time for each different source feature
class, in each direction. Click the new
attribute in your list of attributes and
click the “Evaluators” button. If you
are uncertain of what an evaluator is
or how they work, please review the
Types of evaluators used by a network
page before proceeding.
For your streets, it’s up to you how to determine travel time. If your data already contains a
field for pedestrian walk time, you can use that field. Otherwise, you will probably want to
reference the length of the feature and convert to time by assuming a walk speed (as I have
done in the example shown in the image). You could even define an attribute parameter for
walk speed so the user can change it without rebuilding the network. If you decide to add a
walk speed parameter, please review the Using parameters with network attributes page.
For Connectors_Stops2Streets: You can set these equal to a constant of 0 if you do not want
traveling between streets and transit lines to invoke any time penalty. However, you can use
these features to simulate a time delay for boarding or exiting a vehicle. For example, if you
want it to take 30 seconds to board a vehicle, you could set the To-From direction equal to a
constant of 0.5. You could leave the From-To direction at 0 if you don’t want to invoke a delay
for exiting a vehicle. Note that From-To indicates the direction traveling from the stops to the
streets, and vice-versa for the To-From direction.
Note: If you’ve done something fancy with your stop-street connections, you can ignore the
instructions above and do whatever you think most appropriate. You could, for instance, create
a connection feature class containing a field indicating an individual walk time between the
station entrance and the stop point (the platform). You could use this field as the value for travel
time.
For the TransitLines, you need to use the special GTFS transit evaluator you installed earlier.
This evaluator
queries the
GTFS transit
schedules to
figure out how
long it takes to
travel on your
transit lines at
the time of day
of your
analysis. In the
Type field for
TransitLines
From-To, click
to get a dropdown. There
should be an
entry in the

drop-down list that says “Transit Evaluator”. Select this value.
Because transit trips occur in only one direction along each transit line in this network, you
should set the TransitLines To-From direction entry equal to a constant of -1. This tells the
network that traversal is not allowed in the backwards direction.
Now that you have created your travel time attribute, you have the option to add parameters to it to
enhance your analysis. To create a parameter, return to the window where you can create new
attributes, select your travel time attribute from the list and click the Parameters button on the right.
Click Add to add a new parameter. If you are unfamiliar with parameters or need a refresher, please
review the Using parameters with network attributes page. Here are some parameters you might want
to add to your transit travel time attribute:
 Use Specific Dates - This parameter will allow you flip between two different analysis modes.
One will let you analyze a generic weekday, such as Tuesday, and the other will let you analyze a
specific date, such as Tuesday, April 9, 2013. When you create this parameter, give it the name
“Use Specific Dates”. It must have
exactly this name, or it will not work.
Give it a type of Boolean, and set the
default value to either True or False,
whichever you prefer. If you give it a
default value of True, the default
behavior will be to use the specific
date you select in your analysis settings. If you give it a default value of False, the default value
will be to ignore the specific date and use only the weekday you specify in the analysis settings.
You will be able to override the default behavior in the analysis settings later. If your GTFS data
does not use a calendar.txt file (i.e., only has a calendar_dates.txt files), you should set the
default value to True. Generic weekday analyses will not work with these datasets. If you do
not create this parameter, the transit evaluator’s default behavior is to not use specific dates.
 Walk speed – As mentioned above, you might want to add a pedestrian walk speed parameter
to help you calculate the travel time along your street features. If you add a walk speed
parameter, you can give it any name and units you want. Just make sure you adjust your street
features’ evaluators correctly to use this parameter. Unlike the other parameters mentioned
here, this one is not used internally by the transit evaluator. It’s up to you to configure this one
correctly with your other evaluators.
 Riding a bicycle – If you want to perform analyses for travelers riding bicycles, and your GTFS
data uses the bikes_allowed field in trips.txt, create a Boolean parameter called “Riding a
bicycle”. When this parameter is set to True, the transit evaluator will ignore trips that don’t
allow bicycles and return the best results using only trips that do allow bicycles (or trips that
have no data either way). If you plan to perform analyses for travelers riding bicycles, make
sure you correctly configure the evaluators for your street features as well to account for bicycle
travel speed. You might want to create separate pedestrian travel time and bicyclist travel time
attributes if you plan to analyze both.
 Traveling with a wheelchair – If you want to perform analyses for travelers in wheelchairs, and
your GTFS data uses the wheelchair_accessible field in trips.txt, create a Boolean parameter
called “Traveling with a wheelchair”. When this parameter is set to True, the transit evaluator
will ignore trips that can’t accommodate wheelchairs and return the best results using only trips
that do allow wheelchairs (or trips that have no data either way). If you plan to perform
analyses for travelers in wheelchairs, make sure you correctly configure the evaluators for your
street features as well to account for the generally slower travel speeds of people in

wheelchairs. A walk speed parameter, as described above, might be helpful for this type of
analysis. Additionally, if your stops.txt file contains a wheelchair_boarding field, you need to
create a separate restriction attribute for wheelchair travel, as described later.
Cache on every solve – The transit evaluator caches the transit schedules into memory the first
time you solve an analysis after opening ArcMap. It is done only on the first solve because it can
be time consuming. However, in special applications where you are manually updating your
transit schedules, you might want the schedules to cache on every solve. If you want to do this,
create a Boolean parameter called “Cache on every solve”. To understand caching behavior
better, read the description of caching toward the end of this document.
When you’re finished with your travel time attribute, review your other network attributes. You should
not use a hierarchy attribute, since the transit network does not use hierarchy, and hierarchy is not
helpful for pedestrian analysis. If a hierarchy attribute was automatically created, you can delete it. If
you have a length or distance attribute, note that the length of the TransitLines features is arbitrary
because it does not correspond to the actual route taken by the transit vehicle. Similarly, the length of
the stop-street connector lines is arbitrary. They simply represent the connection between the street
and the stop. You can assign a constant evaluator to these feature classes. You can set them equal to -1
if you want to be sure that transit lines and connectors are never used when an analysis with this
network is solved using this length or distance attribute.
Before continuing, you may also set up any network restriction attributes you like. The TransitLines
feature class contains fields indicating the GTFS route_type, or mode, such as bus, subway/metro, tram,
etc. You can create restriction attributes to prohibit riders from traveling on particular modes.
For example, to prohibit riders from traveling on
buses, create a new restriction attribute. In the
Evaluators dialog for that restriction attribute, use a
Field evaluator for TransitLines in the From-To
direction and click the button on the right showing a
finger pointing at a piece of paper. The image on
the right shows how you can set up your restriction
to prohibit travel on buses. The “route_type” field
uses numerical codes from the GTFS data. An
explanation of the codes is in the GTFS specification
document.
If you plan to perform analyses for travelers in
wheelchairs and your stops.txt file contains a
wheelchair_boarding field, you need to create a
restriction attribute to prevent these travelers from
using inaccessible stops. Create a new restriction
attribute (for example, “Traveling with a
wheelchair”), and for the Connectors_Stops2Streets
features, use a field evaluator to determine whether
or not the stop should be restricted. The “wheelchair boarding” field values follow the GTFS
specification. A value of “1” indicates that the stop is wheelchair accessible; a value of “2” indicates that
the stop is not wheelchair accessible; a value of “0” indicates that there is no information for this stop.
If your street or sidewalk data has information about wheelchair accessibility, you can configure that
here as well. Remember to create a “Traveling in a wheelchair” parameter on your travel time attribute
as described above if you want inaccessible GTFS trips to be restricted as well. This restriction only
handles the stops.
When you’re done setting up your attributes and parameters, continue on to the next page. On the
next page, choose No for driving directions. We currently do not support directions on a GTFS transit
network.
Finally, review your settings and click finish. When the box pops up, choose to Build the network
dataset now.
If there are build errors, click to view them. If anything looks serious, try to fix it before continuing on to
the next step. The most likely error you will see is “Geometry is empty” for features in the
Connectors_Stops2Streets source feature class. This occurs when connector lines were generated with
0 length, most likely because the stops were not successfully snapped to the streets network. This
happens for several reasons:
- Some of the stops fall in areas not covered by your street network. Since there are no streets
anywhere in the vicinity, the stops could not snap to a nearby street and simply got placed
directly on top of the original stop. The line connecting the two has 0 length. To fix this, you
need to get a street feature class that covers this area. Alternatively, you can just ignore these
areas if they are far away from the area you want to analyze.
- Your street network covers the area near the stop, but there were no traversable streets close
enough to the stop points to snap to. You might be able to fix some of these errors by running
the 2) Generate Stop-Street Connectors tool again with a larger search distance for snapping or
relaxed conditions for which streets can be snapped to (the SQL statement).
- Your original stop was actually directly on top of a street feature already. In this case, the
snapped stop doesn’t have to move anywhere to be snapped to the street feature, so the
resulting connector line has 0 length. To fix these, you might need to manually edit the
connector line to give it some length. You can create a little loop, since the geometry of these
connector lines is arbitrary anyway.
6) Generate a transit schedule table
An evaluator tells ArcGIS how to calculate the traversal time across elements in the network dataset
when solving a Network Analyst problem. The TransitEvaluator.dll file you installed is a special evaluator
that can read GTFS schedule data to determine the travel time along transit lines based on the transit
schedules and the time of day. In order to use the special GTFS transit evaluator, you must create a
table containing your GTFS transit schedules in a format the evaluator can read.
Before doing this step, you MUST Build your network dataset. If you rebuild your network dataset later,
you will have to re-run the second part of this step, the tool called 4) Get Network EIDs.
To create the tables, run the tools called 3) Generate Transit Schedule Table and 4) Get Network EIDs.
The tool called 3) Generate Transit Schedule Table generates three tables with transit schedule
information in them. Warning: The largest output table could be very large, on the order of several
hundred megabytes.
Tool inputs
 Network Dataset: The network dataset you just created that contains your transit data.
This tool produces the following output
 TransitSchedule_Calendar, TransitSchedule_CalendarExceptions, & TransitScheduleTable:
Three file geodatabase tables containing your GTFS schedule data formatted correctly for use in
the GTFS transit evaluator. These tables will be located in the geodatabase that houses the
feature dataset where your network dataset is located.
 TripRestrictions (optional): A file geodatabase table containing information about which trips
support wheelchairs and bicycles. The transit evaluator will read this table if your analysis is
configured for analyzing travelers with wheelchairs or bicycles. This table will only be created if
your GTFS trips.txt file contains a wheelchair_boarding or bikes_allowed field, and it will be
located in the geodatabase that houses the feature dataset where your network dataset is
located.
The tool called 4) Get Network EIDs fills in the EID field in TransitScheduleTable from information
gleaned from the network dataset. The special GTFS transit evaluator needs this information to run
successfully. Warning: every time you rebuild your network dataset, you will have to re-run this tool
because the network EIDs might change.
Note: Occasionally, the 4) Get Network EIDs will fail with a message saying “Error obtaining network
EIDs. Exception from HRESULT: 0x80040216”. This means that your network dataset or one of the
associated files has a schema lock on it, likely because you added it to the map or tried to edit it. Try
closing ArcMap, reopening a blank map, and running the tool again prior to adding any layers to the
map. Alternatively, you can run the tool from ArcCatalog.
7) Choose the correct analysis settings
Congratulations! Your network dataset is ready to use with the standard Network Analyst tools in
ArcGIS. If you are new to ArcGIS Network Analyst or need a refresher, please review the Network
Analyst tutorials before proceeding.
Recall that the basic workflow for running network analyses is as follows:
1) Make your network analysis layer (Service Area, OD Cost Matrix, Closest Facility, etc.)
2) Update the analysis layer properties as needed
3) Add locations (facilities, stops, origins, destinations, etc.) to your analysis layer
4) Solve your analysis layer
Please keep in mind the following tips when running analyses using your transit network dataset:
Network locations
Before adding or creating any inputs to your network analysis layer, such as stops, facilities, origins, or
destinations, you need to indicate that these inputs should not locate directly on transit lines or stopstreet connectors. In fact, you only want points to locate along the streets, since pedestrians can only
access the transit lines through the stops. To do this, open the layer properties and go to the Network
Locations tab. In the box at the bottom, uncheck everything except your streets source feature. You
can now add your input points.
If you have any restrictions on your network and want to use them for your analysis, be sure to check
the “Exclude restricted portions of the network” box to prevent your points from ending upon restricted
streets. In order for this to work properly, you need to check your restrictions in the Analysis Settings
tab before you load your Locations (Facilities, Stops, etc.).
Time of day
Before running your analysis, make sure to tell it to run at
a particular time of day. Transit lines will be ignored if you
run your analysis without a time of day. Time is under the
Analysis Settings tab in the layer properties.
Specific vs. generic dates
If you want to run your analysis for a generic day of the
week, such as Tuesday, click the Day of Week radio button
and choose the day from the drop-down list. Additionally,
if you have included a “Use Specific Dates” parameter,
make sure it is set to False. To do this, go to the Attribute Parameters tab in the Layer Properties and
adjust the “Use Specific Dates” parameter as needed. Note: If you select Day of Week but leave the “Use
Specific Dates” parameter as True, the analysis will run for the next calendar date that day of week falls
on. If today is Monday, April 8, 2013, and I select Tuesday and leave “Use Specific Dates” as True, my
analysis will be specifically for Tuesday, April 9, 2013. This might cause you problems if Tuesday, April 9,
2013 is outside the date range of your GTFS dataset or if there are holiday or other schedule changes for
that day.
If, on the other hand, you want to run your analysis for a specific date, click the “Specific Date” radio
button and enter the date. Additionally, make sure that you have created a “Use Specific Dates”
parameter and that it is set to True. To do this, go to the Attribute Parameters tab in the Layer
Properties and adjust the “Use Specific Dates” parameter as needed. Note: If you enter a specific date
but leave the “Use Specific Dates” parameter as False, the analysis will ignore the date you entered and
simply use the day of the week that date falls on.
A note on GTFS data containing non-overlapping date ranges: The GTFS calendar.txt file contains date
ranges indicating the range of dates when service runs. Some GTFS datasets have entries in this table
with date ranges that do not overlap one another. For example, one service_id in the table might be
used for trips occurring in the spring, and a different one might be for trips occurring during the
summer. Additionally, if you use multiple GTFS datasets in your network, the date ranges might be
different between the two datasets. You can get more information about service_ids and date ranges in
the GTFS data spec. If your data contains non-overlapping date ranges, you will have received a warning
message when you ran the 1) Generate Transit Lines and Stops tool. If you try to run analyses for
generic weekdays using this data, you could get inaccurate results. When you choose not to use specific
dates, the date ranges will be ignored, which could cause the GTFS transit evaluator to over-count the
number of trips available. If you have non-overlapping date ranges in your data, make sure you
understand how your data is constructed and how it might affect your analysis.
Excluding sources in service area polygon generation
If you are solving a Service Area analysis, you need to prevent service
areas from being drawn around transit lines. The service area polygons
should only be drawn around streets since pedestrians can’t exit the
transit vehicle partway between stops. To do this, open the layer
properties and go to the Polygon Generation tab. In the bottom left
corner, click to exclude TransitLines and Connectors_Stops2Streets (or
whatever is most appropriate for your network).
Analysis for travelers with wheelchairs
GTFS data contains some optional fields designating which stops and trips are wheelchair accessible
(wheelchair_boarding in stops.txt and wheelchair_accessible in trips.txt). If these fields are present in
your GTFS data, you can perform analyses for travelers with wheelchairs by correctly configuring your
network dataset and analysis settings.
If your stops.txt file contains the wheelchair_boarding field, you should create a network restriction for
pedestrians in wheelchairs as described above and make sure this restriction is checked on for your
analysis.
If your trips.txt file contains the wheelchair_accessible field, you should create a parameter on your
transit travel time attribute called “Traveling with a wheelchair” as described above and make sure this
parameter is set to True for your analysis.
Finally, make sure that your travel time attribute is configured to correctly calculate the travel time
along your street features. You might want to assume a slower travel speed for travelers in wheelchairs.
Analysis for travelers riding bicycles
GTFS data contains an optional field designating which trips allow bicycles (bikes_allowed in trips.txt). If
this field is present in your GTFS data, you can perform analyses for travelers with bicycles by correctly
configuring your network dataset and analysis settings.
If your trips.txt file contains the bikes_allowed field, you should create a parameter on your transit
travel time attribute called “Riding a bicycle” as described above and make sure this parameter is set to
True for your analysis.
Additionally, make sure that your travel time attribute is configured to correctly calculate the travel time
along your street features. You will probably want to assume a faster travel speed for travelers riding
bicycles than you would for travelers who are walking.
Caching the transit schedules
Each time you solve a network analysis for the first time with this
network dataset in a new map or in a geoprocessing model or
script tool, it will have to initialize the GTFS transit evaluator. It has
to read in and process the table of transit schedules. This process
will take a minute or two, depending on the size of your transit
network. Please be patient. This only happens on the first solve.
Subsequent solves will be quick. Caching might also occur the first
time you update your Network Location settings in the analysis
layer properties. If caching occurs here, it will not need to re-cache
on the first solve.
If you are performing a complex analysis in which you want to modify your transit schedule tables
between solves (for example, you are testing the effects of removing a particular bus route), you might
need the transit evaluator to re-cache the schedules prior to each solve. Otherwise, it will not read in
the changes you made to your transit schedule tables. You can override the normal caching behavior by
adding a parameter called “Cache on every solve”, as described above.
If you forgot to run Get Network EIDs
Note: If you forgot to run to tool 4) Get Network EIDs, you will receive an error message when the
evaluator caches saying “FAILURE: All EIDs were null in the transit schedule table. Please run the tool to
generate EIDs”. Just go back and run 4) Get Network EIDs.
Using your network dataset with ArcGIS Server
If you want to use your network dataset and the custom GTFS transit evaluator with ArcGIS Server, you
must install TransitEvaluator.dll on the machine hosting the service. Furthermore, you must register the
dll using the 64-bit Server registration utility. The registration you did when you ran the Install.bat file is
not sufficient.
To register TransitEvaluator.dll in server, open a command window as an administrator. Type the
following command:
"C:\Program Files\Common Files\ArcGIS\bin\ESRIRegAsm.exe" "[path to location where you saved the
Add GTFS to a Network Dataset files]\EvaluatorFiles\TransitEvaluator.dll" /p:Server
Note: The transit evaluator will not work with ArcGIS Server on Linux. It only works with Windows
Server.
Using your network dataset with 64-bit Background Geoprocessing
If you have ArcGIS Desktop and the 64-bit background geoprocessing extension, you must go through a
special registration procedure to make TransitEvaluator.dll work with the 64-bit background
geoprocessing. Follow the procedure outlined here:
http://support.esri.com/en/knowledgebase/techarticles/detail/40735
Limitations and weaknesses
Although these tools represent a significant step forward in transit analysis capabilities in ArcGIS, there
are several limitations you should be aware of:
 There is currently no way to separate walking portions and riding portions of the pedestrian’s
trip through the network. Travelers might be willing to travel for one hour, but they might not
be willing to walk more than a quarter of a mile. This behavior cannot currently be modeled.
 The evaluator does not track which transit trips the traveler has used. It simply chooses the
minimum possible travel time across a transit line segment at a given time of day, without
regard to the number of transfers being made.
 Although you can solve point-to-point routing problems using the GTFS transit evaluator, we
currently do not have a way to generate text directions for those routes for a trip planner.
 Sometimes information about fares is included in the GTFS data. We do not currently use this
data and consequently cannot calculate the fare for a route in this network.
Disclaimer
These tools are exploratory prototypes designed to help Esri further its development of useful and highquality public transit analysis tools. If you encounter bugs or other problems or you simply have ideas or
suggestions, please contact us and let us know!
Because these are prototype tools and have not been extensively tested, we cannot guarantee that the
results of your analyses will be accurate. Please keep this in mind if you plan to use your analyses your
research or publications. You are welcome to contact us to discuss questions or concerns or if you would
like more detailed information about how the tools work.
Contact information:
Melinda Morang, Esri
mmorang@esri.com
909-793-2853 x3315