How to add GTFS data to a network dataset Add GTFS to a Network Dataset version 0.4

Transcription

1 How to add GTFS data to a network dataset Add GTFS to a Network Dataset version 0.4 These instructions explain how to add GTFS public transit data to an ArcGIS network dataset. Melinda Morang, ESRI mmorang@esri.com x3315 Last updated: December 30, 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 and a SQL database of the schedules 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) Finalize your transit network using the Get Network EIDs tool 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.bat by simply double-clicking on it. If the installation succeeds, you will get a popup box saying so: If the installation fails for some reason, you can open the Install.bat file (rightclick 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.

2 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 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. 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 dataset, Add GTFS to a Network Dataset requires 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.

3 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.

4 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 because it will be used by the network dataset during analysis. 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 Stop- Street 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:

5 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.

6 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 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.

7 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.

8 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. You will create a travel time cost attribute that uses a special evaluator to read and interpret the transit schedules. 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

9 the time of day. The next few paragraphs will guide you through the process of setting up a travel time cost attribute that uses the transit evaluator. 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). Be sure to use the correct units for your input data. You could also 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

10 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 drop-down. 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, 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

11 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 with 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 with wheelchairs, make sure you correctly configure the evaluators for your street features as well to account for the generally slower travel speeds of people with 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. Exclude route_ids or Exclude trip_ids If you would like the option to turn off service for particular routes or trips temporarily in your analysis, you can add a parameter called Exclude route_ids (for routes) or Exclude trip_ids (for trips). These parameters must have exactly these names, and they must be type String. Entering GTFS trip_id or route_id values for these parameters will allow you see how changing transit service affects your analysis, without having to rebuild the entire network dataset. More details about using these parameters are 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.

12 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. If you re using ArcGIS 10.3, you will be given an option on the next page to build a service area index. If you are planning to make service areas, building a service area index is a good idea, as the index makes service area generation faster and the resulting service areas nicer-looking. 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.

13 - 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) Finalize your transit network using the Get Network EIDs tool The special GTFS transit evaluator references a SQL database containing your GTFS transit schedule data. This database is created and processed when you run the 1) Generate Transit Lines and Stops tool. However, the database needs one further piece of information, a list of network EIDs, which can only be added after the network dataset has been created and built. Consequently, you need to run one further tool before your network dataset is ready to use, 3) Get Network EIDs. 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 3) Get Network EIDs will fail with a message saying Error obtaining network EIDs. Exception from HRESULT: 0x 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. The input for this tool is just your network dataset. There is no output. It simply updates the SQL database associated with your network. 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

14 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, 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

15 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.

16 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. Excluding specific routes or trips If you wish to assess the impact of cutting transit service, you can turn off specific GTFS routes and/or trips in your analysis without rebuilding your network dataset. For instance, if you want to assess whether a neighborhood experiences a significant decrease in access to grocery stores if you eliminate a particular bus line, you could run your analysis with the existing schedules and then re-run it after temporarily turning off that bus line. To do this, you first need to create the appropriate parameters on your transit travel time attribute. If you plan to exclude GTFS routes (an entire bus or train line), create an attribute called Exclude route_ids. If you plan to exclude specific GTFS trips (an instance of a bus or train traveling on a bus/train line at a particular time of day), create an attribute called Exclude trip_ids. The procedure for creating these parameters is described above. The value for these parameters can be a list of one or more GTFS route_ids or trip_ids, which you can look up in your original GTFS text files. You can also use the Transit Identify tool (in the Transit Analysis Tools toolbox included with the Add GTFS to a Network Dataset download) to determine which routes and trips serve a particular network transit line. The route_id and trip_id values must additionally include a prefix indicating which GTFS dataset they are from (because a network containing data from multiple GTFS datasets may have some routes or trips with the same route_id or trip_id). In the image shown here, my GTFS dataset was in a folder called SORTA (which stands for Southwest Ohio Regional Transit Authority, in case you re curious), and I am excluding route_id 9501 and route_id 9502, and trip_id If you can t remember what your

17 GTFS data s folder name is/was, the quickest way to figure out the correct prefix is to use the Transit Identify tool. If you wish to exclude multiple routes or trips, enter them in a list separated by a comma and a space, as shown in the image here. 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 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 data between solves (for example, you are testing the effects of adding an extra trip and are directly modifying the SQL database of GTFS data), 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 schedules. 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 3) 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 3) 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.

18 If you are hosting a service using your transit-enabled network dataset, and you copy the service s data to the server, you must additionally copy the GTFS.sql file located in the geodatabase where your network dataset is stored. Without this SQL database, the transit evaluator will not run. 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: 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 x3315