Create and use a network dataset with public transit data

Available with Standard or Advanced license.

Available with Network Analyst license.

Public transit, such as buses and subways, serves the people of a city by providing access to jobs, education, shopping, health care, recreation, and more. You can use the ArcGIS Network Analyst extension to answer questions such as the following:

• How easily can people access important destinations when using public transit?
• How well does the public transit system serve its riders?
• Where should I locate my new facility if I expect my customers, patients, or employees to ride public transit?

You can incorporate public transit schedule data into analyses of dense urban areas where public transit is an important mode of travel.

In this tutorial, you will create a public transit-enabled network dataset from GTFS public transit data and street centerlines. You will use this network dataset to create service areas showing the area reachable within a time limit from a starting location by public transit and walking.

You can use your own GTFS data and street centerlines as you follow the steps of this tutorial, or you can use the provided sample data for the Cincinnati metropolitan area. If you use your own data, your street centerlines should cover the same geographic area as your GTFS data. Various notes and tips throughout this tutorial highlight special considerations when you're using your own data, including additional tips if you’re using data from the Routing_Streets feature class from the StreetMap Premium Custom Roads product.

A completed network dataset is included in the tutorial data as an example.

Get the data

The data for this tutorial is available for download.

1. Go to the data download page.
2. Click the Download button, and save the file locally.
3. Unzip the downloaded file.

Examine the input data

Assemble the input data and examine it.

Examine the GTFS public transit data

GTFS is a worldwide standardized format for public transit data. It includes the locations of transit lines and stops as well as the transit schedules. A GTFS dataset consists of a set of CSV text files with specific names and fields. If you are unfamiliar with GTFS, read a little more about it.

You can use GTFS data in a network dataset by transforming it into the Network Analyst public transit data model. Later in this tutorial, you'll learn how to do that. First, you'll examine the GTFS data to identify potential problems and to make good analysis decisions later.

Network Analyst allows you to solve network analysis problems using an analysis date and time. In general, you can choose either a generic weekday, such as Wednesday, or a specific date, such as Wednesday, May 22, 2019. However, depending on the configuration of your GTFS data, you may not be able to use a generic weekday. In this section, you will examine the date configuration of the GTFS datasets to determine whether you can perform network analysis with generic weekdays or whether you will need to use specific dates.

You will also examine the stop_times.txt files in your GTFS datasets to determine whether all arrival and departure times are explicitly included.

1. Find the GTFS data on disk.

   Two GTFS datasets for the Cincinnati metropolitan area are provided with the tutorial data. They are from the Southwest Ohio Regional Transit Authority (SORTA) and the Transit Authority of Northern Kentucky (TANK). These GTFS datasets are in the unzipped tutorial data folder in Tutorial > PublicTransit > GTFS. The SORTA and TANK folders contain a set of text files.

   Note:

   If you are using your own GTFS data, find the set of GTFS text files on disk.

2. Examine the stop_times.txt file for each GTFS dataset.

   The stop_times.txt file defines the exact times of day when a public transit service visits each public transit stop.

   1. Open the stop_times.txt file in a text editor.

      Note:

      Sometimes the stop_times.txt file is very large. It may exceed the maximum file size allowed by some text editors.

   2. Examine the arrival_time and departure_time fields and determine whether there are any blank values for these fields.

      Note:

      Although GTFS allows blank values for these fields, the Network Analyst public transit data model requires explicit times for all stop arrivals and departures. The GTFS To Public Transit Data Model geoprocessing tool, which you will use later in this tutorial, can estimate blank arrival and departure times using simple linear interpolation. If there are any blank values in the data, you must use the tool's interpolation option later, fill in the blank values in the GTFS data prior to running the tool, or use a different GTFS dataset for your analysis.

      The GTFS datasets provided in this tutorial do not have any blank values for these fields.

   3. Close the stop_times.txt file.
3. Determine whether you have a calendar.txt file, a calendar_dates.txt file, or both for each GTFS dataset.

   The calendar.txt file defines regularly occurring transit service, and the calendar_dates.txt defines exceptions to the regular service, such as holidays and special events. Some transit agencies choose to use only one of the files, and this is valid. Each GTFS dataset you intend to use must have at least one of these files.

   If the GTFS dataset has only the calendar_dates.txt file and not the calendar.txt file, the dataset does not define regularly occurring service; all service is defined explicitly for specific dates. In this case, you cannot use generic weekdays in your analysis. You must use a specific date.

   If the GTFS dataset has only the calendar.txt or if it has both files, you have the option to use a specific date, and you may be able to use a generic weekday. You will inspect the files further in the next step.

   If the GTFS dataset has neither the calendar.txt file nor the calendar_dates.txt file, you cannot use this GTFS dataset because it is invalid.

   The GTFS datasets provided in this tutorial have both files.

4. Examine the calendar.txt file for each GTFS dataset that has one.
   1. Open the calendar.txt file in a text editor.
   2. Examine the date ranges shown in the start_date and end_date fields.

      These fields indicate the range of dates when the GTFS data is valid. If you use a specific date in your analysis, it must fall within this date range.

      Note:

      If you're using the sample data, these date ranges may have passed, but that will not impact the tutorial.

   3. Determine whether there are any nonoverlapping date ranges, rows where the date range does not overlap at all with the date range of another row.

      This can occur when data from multiple agencies has been merged into one file or when the agency has included service for multiple seasons, such as fall and winter, in the same file.

      If there are any nonoverlapping date ranges, you should use a specific date in your analysis instead of a generic weekday. A generic weekday includes service without regard for the date ranges, so in this situation, service from these nonoverlapping date ranges would all be included in the same analysis. In the example of an agency that has included separate fall and winter service in the same dataset, the fall service and the winter service would both be included in your analysis, leading to the available service being counted twice.

      Neither of the GTFS datasets provided in this tutorial has nonoverlapping date ranges.

   4. Examine the weekday fields (monday, tuesday, and so on).

      These fields define the days of the week when specific transit service runs. The service runs on that weekday if the value is 1 and does not run on that weekday if the value is 0.

      If all the weekday fields are populated with 0 for all rows, it is likely that the agency is using the calendar_dates.txt file to define specific dates when service is running, so you will need to use a specific date in your analysis instead of a generic weekday. If this dataset does not have a calendar_dates.txt file, the GTFS dataset is likely invalid, since it effectively has no service.

      The GTFS datasets provided in this tutorial contain a mixture of 1 and 0 in the weekday fields. They define regular weekday service.

   5. Close the calendar.txt file.

Examine the street data

Pedestrians must be able to walk to the transit stops, ride the transit, and walk to their destinations, so you will include streets in the network dataset in addition to the public transit stops and lines. The street data you use in the network dataset should be of good quality and should contain attributes that indicate whether pedestrians are allowed to travel on the street.

1. Open ArcGIS AllSource and create a project with a map.
2. Add the street data to the map.

   The provided street data is in the unzipped tutorial data folder in Tutorial > PublicTransit > StreetData.gdb > Streets.

3. Open the attribute table of the streets layer and familiarize yourself with the fields and values in the data.
4. Find the RestrictPedestrians field.

   This field indicates whether pedestrians are allowed to travel on the street segment. A value of N means that pedestrians are not restricted from traveling on the street; they can travel on the street. A value of Y means that pedestrians are restricted; they cannot travel on the street. This field will be used in the network dataset to construct a restriction attribute preventing pedestrian travel on highways and other streets where pedestrians are not allowed.

   Note:

   If you are using your own data, you must add a text field called RestrictPedestrians. Otherwise, the template you will use later to create the network dataset will not work. After creating the field, populate it appropriately with the N and Y values. You can also leave the field values null; streets with a null value will be interpreted by the network dataset as not restricted (the same as a value of N).

   If you're using the Routing_Streets feature class from the StreetMap Premium Custom Roads product, the field is called RST_PEDESTRIANS. You should leave this field as is. Later, you will use a separate network dataset template designed specifically for this data.

5. Find the ROAD_CLASS field.

   This field indicates the type of road and is used in the network dataset for configuring walking directions. The possible values are defined in Configure directions.

   Note:

   If you are using your own data, you must add a short integer field called ROAD_CLASS. Otherwise, the template you will use later to create the network dataset will not work. After creating the field, populate it appropriately with road class values. You can also leave the field values null, and the network dataset will use default behavior when generating directions.

   The Routing_Streets feature class from StreetMap Premium Custom Roads already contains an appropriate ROAD_CLASS field.

6. Close the attribute table.
7. Use the Explore tool to examine the street data in the map. Click a few street features and note where they start and end and how they intersect with other features.

   Sometimes street data is split into separate features at each intersection. Other street datasets contain long contiguous street features that are not split each time they intersect another feature but instead have vertices at those points. Note how your street data is constructed because this will impact how you configure the network dataset's connectivity policy later.

   The provided street data is split into separate features at every intersection.

   Note:

   The Routing_Streets feature class from StreetMap Premium Custom Roads is not split at intersections.

8. Remove the street data from the map.

Prepare the network dataset source feature classes and tables

You will create and prepare the feature classes and tables you will use in the network dataset. You will convert the GTFS data to the set of feature classes and tables that comprise the Network Analyst public transit data model, and you will prepare the street centerlines for use in the network dataset.

Create a file geodatabase and feature dataset

In this section, you will create the file geodatabase and feature dataset. Later, you will create the network dataset in this feature dataset.

1. Create a file geodatabase and place it anywhere on your computer.
2. Create a feature dataset in the new geodatabase using the spatial reference of your choice.

Create transit stops, lines, and schedules from GTFS

In this section, you will use the GTFS To Public Transit Data Model geoprocessing tool to convert the GTFS data to a set of feature classes and tables that will be used in the network dataset.

1. In the Geoprocessing pane, open the GTFS To Public Transit Data Model tool.

   You can find this tool in the Public Transit Tools toolbox in the Conversion toolset or through the tool search bar.

2. For the Input GTFS Folders parameter, choose one or more folders containing GTFS text files. If you are using the provided data for the tutorial, choose both the SORTA and TANK folders.

   The data from all input GTFS datasets will be combined into the same set of output tables and feature classes, which is useful when you want to model a metropolitan area in which multiple transit service providers operate in the same geographic area. The SORTA dataset serves the part of the Cincinnati metropolitan in the state of Ohio, and the TANK dataset provides service in the part of the Cincinnati metropolitan area to the south across the river in the state of Kentucky.

3. For the Target Feature Dataset parameter, choose the feature dataset you created earlier.
4. Leave the Interpolate blank stop times check box unchecked.

   Note:

   If you're using your own GTFS data and you determined that the stop_times.txt file has blank values in the arrival_time and departure_time fields, check the Interpolate blank stop times check box.
5. Leave the Append to existing tables check box unchecked.

   You are creating a new set of output public transit data model tables and feature classes, not appending to an existing set.

6. Leave the Make LVEShapes from shapes.txt check box unchecked.

   The optional LVEShapes feature class defines cartographic polylines representing the public transit lines for visualization in the map, but it is not used in the network dataset.

   Note:

   The LVEShapes feature class is not needed for this tutorial or for a transit-enabled network dataset, but it may be useful for other purposes. If you plan to run the Calculate Transit Service Frequency tool using the public transit data model feature classes and tables created in this tutorial and want an enhanced visual output when calculating transit frequency statistics for transit lines, check the Make LVEShapes from shapes.txt check box.
7. Run the tool.

   The tool should complete successfully with no errors or warnings, and several feature classes and tables are added to the map contents.

   Note:

   If you're using your own GTFS data, review the tool messages for errors and warnings to ensure that your GTFS data is adequate for use in a network dataset. The tool performs some data validation, and sometimes GTFS datasets have data problems that must be corrected before the data can be used in a network dataset.

8. Examine the output in the map and in the Contents pane.

   Two feature classes, Stops and LineVariantElements, and several tables are shown. The tables represent the public transit schedules. The Stops feature class represents the locations of the transit stop. The LineVariantElements feature class represents the transit line segments.

   

   The transit lines in the map do not follow the streets and do not look like a typical visual representation of the transit system. The LineVariantElements features are not intended to represent the actual geographic paths taken by buses, trains, or other public transit vehicles but are instead representative of logical connections in the transit system. The Public Transit evaluator in the network dataset will use the public transit schedules to determine the travel time required to traverse the LineVariantElements features, so their shape and length are irrelevant. These feature classes and tables are described in more detail in the Network Analyst public transit data model documentation.

   You may notice that the LineVariantElements feature class contains several long, straight lines. These represent express routes that connect the center of the city to stops in the outskirts, with no intermediate stops.

   Note:

   If you checked the Make LVEShapes from shapes.txt check box, the LVEShapes feature class is also created and included in the map. The LVEShapes feature class shows a cartographic representation of the paths traveled by vehicles in the transit system instead of the straight lines in the LineVariantElements feature class.

Copy the streets feature class into the feature dataset

Because the streets will participate in the network dataset, you must put the streets feature class in the feature dataset where you will create the network dataset.

1. Locate the streets feature class. Recall that the provided street data is in the unzipped tutorial data folder in Tutorial > PublicTransit > StreetData.gdb > Streets.
2. If the streets feature class and the feature dataset you created earlier have different spatial references, use the Project tool to project the streets into the spatial reference of the feature dataset. Otherwise, simply copy the streets feature class into the feature dataset.

   Note:

   If you're using your own data, you must rename the feature class Streets so it will work with the provided network dataset template.

   If you're using the Routing_Streets feature class from the StreetMap Premium Custom Roads product, keep the name Routing_Streets. Do not rename it to Streets.

   For the Routing_Streets feature class, some additional considerations apply. The Copy and Project tools do not work with feature classes that participate in a network dataset. Additionally, you will likely want to clip the Routing_Streets feature class to include only streets in the metropolitan area you are analyzing. Finally, you need to additionally clip and copy the Routing_Streets_Override feature class into the target feature dataset to ensure proper connectivity later.

   The easiest method to copy and clip Routing_Streets and Routing_Streets_Override is to add them to the map, select all the features within the area the new public transit network will cover, and run the Feature Class To Feature Class tool for each layer to export the selected features.

   If the original feature classes and the target feature dataset have different spatial references, you should either create intermediate output feature classes and run the Project tool, or you should set the Feature Class To Feature Class tool's Output Coordinate System and Geographic Transformations environment settings.

   If you didn't select the relevant Routing_Streets_Override points at the same time you selected the relevant Routing_Streets features, you can do so by selecting all Routing_Streets_Override points that intersect your extracted and copied Routing_Streets features using the Select Layer By Location tool.

Connect the transit stops to the streets

In the network dataset, you want to ensure that a traveler can walk along the streets, use the transit system by entering or exiting the transit vehicles at stops (and nowhere else), and walk from the final stop to their destination. Thus, you must ensure that there is a well-controlled connection between the streets, the transit stops, and the transit lines. In this section, you will use the Connect Public Transit Data Model To Streets tool to form such a connection. The tool snaps a copy of the transit stops to the streets and generates a straight line connecting each stop's original location with the location where it snapped to the street. These connectors are used in the network dataset to model travel between the streets and the transit lines.

1. In the Geoprocessing pane, open the Connect Public Transit Data Model To Streets tool. You can find this tool in the Public Transit Tools toolbox in the Conversion toolset or through the tool search bar.
2. For the Target Feature Dataset parameter, choose the same feature dataset you've been using for the rest of this tutorial.
3. For the Input Streets Features parameter, choose the streets feature class in the feature dataset.
4. For the Search Distance parameter, either accept the default or enter a value of your choice.

   Stops that are outside the search distance will not be snapped to street features and will consequently not be connected to the streets. A small search distance will ensure that stops do not snap incorrectly to streets that are very far away, but it increases the likelihood of stops failing to snap when they should. A large search distance increases the number of stops likely to snap but may lead to errors that should instead be corrected by editing the street data.

   Tip:

   Use the Select Layer By Location tool to quickly determine in advance which stops will fall outside of your designated search distance. Use this information to make necessary edits to your streets or to adjust the search distance to your needs before running the Connect Public Transit Data Model To Streets tool.

5. For the Expression parameter, add an expression so that transit stops will not be snapped to streets that are restricted to pedestrians. Use the expression builder to construct the expression. Set the field to RestrictPedestrians, the where clause to is not equal to, and the value to Y. Alternatively, use the SQL editor to write RestrictPedestrians <> 'Y'.

   As discussed previously, a value of Y in the RestrictPedestrians field indicates that a street is restricted to pedestrians. The expression constructed in this step ensures that public transit stops will not be snapped to restricted streets. This in turn ensures that all transit stops are accessible to pedestrians.

   Note:

   If the Streets feature class does not have a RestrictPedestrians field, you need to add one or you will not be able to successfully create the network dataset from the provided template later.

   If you're using your own data and the RestrictPedestrians field has any null values, add a second clause to the Expression parameter to ensure that nulls are handled correctly. Set the operator to Or, the field to RestrictPedestrians, and the where clause to is null. Alternatively, use the SQL editor to write RestrictPedestrians <> 'Y' Or RestrictPedestrians IS NULL. This ensures that public transit stops can be snapped to streets with null values in the RestrictPedestrians field because null is interpreted to mean that pedestrians are allowed.

   If the RestrictPedestrians field is null for all rows, you don't need to use a value for the RestrictPedestrians parameter because pedestrians are allowed on all streets.

   If you're using the Routing_Streets feature class from the StreetMap Premium Custom Roads product, use the RST_PEDESTRIANS field for the Expression parameter instead of RestrictPedestrians.

6. Run the tool.

   The tool should complete successfully with no errors or warnings, and additional feature classes are added to the map.

   Note:

   If you're using your own data, review the tool messages for errors and warnings to ensure that everything worked properly.

7. Examine the output in the map and in the Contents pane.

   Two new feature classes, StopsOnStreets and StopConnectors, are added to the map. The streets feature class may also have been added to the map if it wasn't in the map already.

8. Zoom in to the area around one of the public transit stops and examine it.

   You should see the Stops feature, a short straight line segment (a StopConnectors feature) connecting that Stops feature to a street, and a StopsOnStreets feature at the intersection of the street and the StopConnectors line feature. This combination of features allows you to define good, well-controlled connectivity between the streets and public transit lines in the network dataset. These feature classes are described in more detail in the documentation for the Network Analyst public transit data model.

   

   Note:

   If the Stops feature class includes parent stations or station entrances, you may see a slightly more complex connection structure. The connection rules for these situations are described in more detail in the Connect Public Transit Data Model To Streets tool documentation.

Create the network dataset

In this section, you will create the network dataset using the provided network dataset template. The provided template ensures a well-structured network dataset with the most important settings configured for you. In later steps, you will review some of these settings, and you will have the opportunity to change them to suit your needs and data.

Create the network dataset from a template

Use the provided XML template to automatically create a network dataset with a particular schema.

1. Open the Create Network Dataset From Template tool.

   You can find this tool in the Network Analyst Tools toolbox in the Network Dataset toolset or through the tool search bar.

2. For the Network Dataset Template parameter, choose the provided XML template file in the unzipped tutorial data folder in Tutorial > PublicTransit > TransitNetworkTemplate.xml.

   Note:

   Even if you're using your own data instead of the provided tutorial data, this network dataset template should work, as long as you followed the tutorial instructions to rename your street data Streets and added the RestrictPedestrians and ROAD_CLASS fields.

   If you're using data from the StreetMap Premium Custom Roads product, use the TransitNetworkTemplate_SMP_Custom_Roads.xml network dataset template instead of TransitNetworkTemplate.xml. This alternate template accounts for the special considerations needed for this data.

3. For the Output Feature Dataset parameter, choose the same feature dataset you've been using for the rest of this tutorial.

   The network dataset will be created in this feature dataset.

4. Run the tool.

   A network dataset is created in the feature dataset.

   Note:

   You may need to refresh the feature dataset in the Catalog pane to see the new network dataset.

Examine the network dataset's properties

The network dataset has been created, but you should examine its properties to ensure that you understand how it works and that it is suitable for your needs. In this section, you will examine the network dataset's connectivity policy and travel attributes.

1. Remove the network dataset from the map if it is there.

   You will not be able to edit certain network dataset properties if it is in the map.

2. Open the network dataset's properties dialog box.
3. Examine the network dataset's connectivity policy.

   The connectivity policy of the network dataset is configured to prevent unintended transfers between public transit lines and streets. To transfer between a street and a public transit line, the traveler must use a designated public transit stop. Consequently, streets and public transit lines are in separate connectivity groups.

   Learn more about network dataset connectivity groups and policies

   1. On the network dataset properties dialog box, select Source Settings > Group Connectivity.

      The Group Connectivity tab appears.

      

   2. Examine the list of feature classes.

      The transit lines (LineVariantElements), streets, and connector features (StopConnectors) are included in the network as edge sources. The transit stops (Stops) and the copy of the stops that is snapped to the streets (StopsOnStreets) are included in the network as junction sources.

      Note:

      If you're using data from the StreetMap Premium Custom Roads product, you will see Routing_Streets instead of Streets, and Routing_Streets_Override is included as an additional junction source.

   3. Examine the connectivity groups.

      The network dataset has three connectivity groups. The streets are in the first group, the connector lines are in the second group, and the transit lines are in the third group. The StopsOnStreets feature class participates in both the first and second groups, providing a way for the traveler to transition between the streets and the connector lines. The Stops feature class participates in the second and third groups, providing a way to transition from the connector lines to the transit lines.

      Note:

      If you're using data from the StreetMap Premium Custom Roads product, Routing_Streets_Override participates in the same connectivity group as Routing_Streets.

   4. Examine the connectivity policies for the edge sources.

      All three edge sources have Endpoint connectivity, which means that line features are only considered connected in the network if their endpoints are coincident. If they touch or overlap at other points, they are not considered connected.

      LineVariantElements and StopConnectors should always use Endpoint connectivity.

      Earlier in this tutorial, you examined the street data in the map to determine whether it was split into separate features at each intersection or whether it had long contiguous street features that went through several intersections with other streets. For street data that is split at every intersection, Endpoint connectivity is the correct choice. The provided street data is split into separate features at every intersection, so leave the connectivity policy for Streets as Endpoint.

      Note:

      If you are using your own street data, and your streets include long contiguous street features that are not split at each intersection, switch the Streets connectivity policy to Any Vertex.

      If you're using data from the StreetMap Premium Custom Roads product, leave the connectivity policy of Routing_Streets set to Endpoint, even though this street data is not split at each intersection. The Routing_Streets_Override junction source, with its connectivity policy of Override, serves to ensure proper connectivity at these intersections.

   5. Examine the connectivity policies for the junction sources.

      The Stops junction source has a connectivity policy of Honor, which means that transit stops obey the connectivity policy of the edge source to which they are connected.

      The StopsOnStreets junction source has a connectivity policy of Override, which means that these junctions will override the connectivity policy of the edge source to which they are connected. In this case, StopsOnStreets features will connect to Streets features at junctions even if the Streets connectivity policy is Endpoint. This is important because it means that you do not need to split the street features at the locations of transit stops to ensure connectivity in the network.

      Leave the junction source connectivity policies as they are.

4. Examine the network dataset's cost attributes.

   Cost attributes are used to measure the cost, or impedance, to travel along an edge in the network. For example, a cost attribute can define the travel time it takes to walk along a street segment or travel along a transit line.

   Learn more about cost attributes

   1. On the network dataset properties dialog box, select Travel Attributes > Costs.
   2. Examine the list of cost attributes shown in the upper section of the dialog box.

      The network dataset has three cost attributes, PublicTransitTime, WalkTime, and Length.

   3. Select the PublicTransitTime cost attribute.

      The properties of the PublicTransitTime cost attribute appear in the lower section of the dialog box.

   4. Examine the Evaluators section.

      An evaluator defines a calculation that determines the cost to traverse a particular edge, junction, or turn in the network. Each edge, junction, or turn source can use a different type of evaluator. For example, you can use different evaluators to calculate the travel time of a pedestrian along streets and along transit lines.

      Learn more about the types of evaluators used by a network

      The LineVariantElements edge source uses the Public Transit evaluator. This evaluator calculates the travel time along a public transit line segment based on the scheduled public transit service. The travel time returned includes the wait time until the next scheduled transit trip begins plus the travel time along the transit line segment from one end to the other.

      Learn more about the Public Transit evaluator

      The StopConnectors edge source uses the Constant evaluator with a value of 0. This means that no travel time is incurred when a pedestrian uses a StopConnectors feature to travel between a street and a transit line. Since the StopConnectors features created by the Connect Public Transit Data Model To Streets tool represent logical connections to control network connectivity rather than actual geographic paths, it makes sense not to incur any travel time. However, if you want to model paths through large stations or have information about typical boarding or exiting delays for the transit stops, you can change the evaluator type or value.

      The Streets edge source uses the Function evaluator to set the travel time equal to the walk time along streets calculated for the WalkTime cost attribute. The WalkTime attribute, in turn, calculates the walk time based on the length of the street and a configurable walk speed parameter.

      Note:

      You can examine the evaluators for the WalkTime cost attribute by selecting it in the upper portion of the dialog box. This will switch the lower portion of the dialog box to show the properties of the WalkTime attribute.

   5. Examine the Parameters section of the dialog box. Click it to expand it if necessary.

      The PublicTransitTime cost attribute is configured with several attribute parameters that can be used to further control the behavior of the Public Transit evaluator.

      Learn more about the Public Transit evaluator's supported parameters

5. Examine the network dataset's restriction attributes.

   Restriction attributes are used to prevent travel along certain portions of the network under particular circumstances. For example, a restriction attribute can define streets where pedestrians are not allowed to walk, such as highways.

   Learn more about restriction attributes

   1. On the network dataset properties dialog box, select Travel Attributes > Restrictions.
   2. Examine the list of restriction attributes shown in the upper section of the dialog box.

      The network dataset has two restrictions, PedestrianRestriction and WheelchairRestriction.

   3. Select PedestrianRestriction.

      This restriction prevents pedestrians from walking on streets where pedestrians are prohibited.

      The PedestrianRestriction properties appear in the lower section of the dialog box.

   4. Examine the Evaluators section.

      For the Streets edge source, whether a particular edge is restricted is determined based on the value of the RestrictPedestrians field. If the field value is Y, the street is considered restricted. Otherwise, pedestrian travel is allowed.

      Note:

      If you're using the Routing_Streets feature class from the StreetMap Premium Custom Roads product, the field used by this restriction is RST_PEDESTRIANS instead of RestrictPedestrians.

      The other edge and junction sources do not define any behavior for this restriction. Pedestrian travel on these other features is always allowed.

   5. Select WheelchairRestriction from the list of restriction attributes in the upper section of the dialog box.

      This restriction prevents travelers with wheelchairs from traveling in places that cannot accommodate wheelchairs.

      The WheelchairRestriction properties appear in the lower section of the dialog box.

   6. Examine the Evaluators section.

      For the StopConnectors edge source, whether a particular edge is restricted is determined based on the value of the GWheelchairBoarding field according to the rules defined by the public transit data model. This prevents travelers with wheelchairs from boarding transit vehicles at stops that are not wheelchair accessible.

      The other edge and junction sources do not define any behavior for this restriction. Wheelchair travel on these other features is always allowed. If the streets contain information about wheelchair accessibility, you can incorporate that information into this restriction by configuring the evaluators for the Streets edge source.

      Note:

      Wheelchair accessibility of the transit lines is handled separately using the Traveling with a wheelchair parameter on the PublicTransitTime cost attribute. When this parameter is set to True, the Public Transit evaluator will ensure that transit service that is not wheelchair accessible is not used in the calculation that determines the travel time. A parameter on the cost attribute is used instead of a restriction because the wheelchair accessibility of the transit lines is often related to the particular vehicle being used rather than the line itself.

6. Examine the network dataset's travel modes.

   Travel modes represent a collection of network dataset settings, such as cost and restriction attributes, that can be applied for an analysis. Travel modes usually represent a particular mode of travel, such as pedestrians walking and taking transit.

   Learn more about travel modes

   1. On the network dataset properties dialog box, select Travel Attributes > Travel Modes.
   2. Examine the list of travel modes in the drop-down list in the upper section of the dialog box.

      The network dataset has two travel modes, Public transit time and Public transit time with wheelchair.

   3. Select Public transit time from the list.

      This travel mode represents the travel time of pedestrians walking on streets and taking public transit.

      The Public transit time properties appear in the lower section of the dialog box.

   4. In the Costs section, examine the Impedance property.

      The PublicTransitTime cost attribute is selected as the travel mode's impedance attribute, meaning that this attribute will be used to perform the travel time calculation when the travel mode is used for analysis.

   5. In the Costs section, examine the Cost Parameters section.

      The attribute parameters associated with cost attributes are displayed. You can select any of the attributes shown in the list to expand the relevant parameters and examine their values. The walk speed is set here.

   6. In the Restrictions section, examine the list of restrictions that are applied when using this travel mode in an analysis.

      PedestrianRestriction is turned on, but WheelchairRestriction is not, since this travel mode is not intended to model travelers with wheelchairs.

   7. Select Public transit time with wheelchair from the list of travel modes in the upper section of the dialog box.

      This travel mode represents the travel time of travelers with wheelchairs along streets and public transit lines.

      The Public transit time with wheelchair properties appear in the lower section of the dialog box.

   8. In the Costs section, examine the Cost Parameters section.
   9. Select PublicTransitTime in the box to expand the attribute parameters associated with that cost attribute.

      For this travel mode, the Traveling with a wheelchair parameter value is set to True, overriding the default value.

   10. In the Restrictions section, examine the list of restrictions that are applied when using this travel mode in an analysis.

       Both PedestrianRestriction and WheelchairRestriction are turned on for this travel mode.

7. On the network dataset properties dialog box, select Directions > General to examine the network dataset's directions configuration.

   The ArcGIS Network Analyst extension does not currently support turn-by-turn directions for travel by public transit that would be suitable for a passenger-facing application.

   The Support Directions check box is unchecked. This network dataset is not currently configured to support directions. If desired, you can check this box and configure directions for walking.

   Learn more about configuring directions

8. Close the network dataset properties.

Build the network dataset

A network dataset can't be used for analysis until it has been built.

1. Open the Build Network tool.

   You can find this tool in the Network Analyst Tools toolbox in the Network Dataset toolset or through the tool search bar.

2. Choose the new network dataset and run the tool.

   You may get a warning message saying that build errors were encountered.

3. If build errors were encountered, open the build error message file shown in the message text and examine the build errors.

   Build errors indicate problems or potential problems with the network dataset. Some are serious and must be corrected for the network dataset to function. Others are minor and can be ignored.

   Learn more about network dataset build errors

   The most likely build errors you may encounter are those indicating that StopConnectors features have an empty geometry. Messages like SourceName: StopConnectors, ObjectID: 232, Geometry is empty are common in this scenario. This typically occurs when one of the Stops features and its associated StopsOnStreets feature are spatially coincident because the StopsOnStreets feature did not successfully snap to a nearby street. Consequently, the connector line generated between the two has no length.

   If you have build errors of this type, examine the affected StopConnectors features. You can find the associated Stops and StopsOnStreets features using the StopID field in StopConnectors, which refers to the ID field in Stops and StopsOnStreets. The most likely cause of the error is that the stop was farther from the closest street than the Search Distance you used in the Connect Public Transit Data Model To Streets tool. The stop may be in the wrong place, which indicates an error in the original GTFS data, or the street data may be missing some roads or driveways that service the stop.

   If there are only a few errors, and they are not in an area that is important for your analysis, you can safely ignore them.

   If you want to correct the problem, you need to manually move the StopsOnStreets feature and snap it to the correct point along a street and edit the StopConnectors feature to connect to it. The easiest way to correct a null geometry is to use the Replace Geometry editing tool. The direction of digitization of the StopConnectors features should be from the stops toward the streets. You should not move the Stops feature in case it becomes disconnected from the transit lines. You can also edit the street data to add missing roads or driveways before editing StopsOnStreets.

   Instead of editing, you can rerun the Connect Public Transit Data Model To Streets tool with a larger Search Distance value.

   Another build error you may encounter occurs when the original stop location is already spatially coincident or nearly coincident with a street. In this case, the Stops feature and its associated StopsOnStreets feature are spatially coincident or nearly spatially coincident because the snapping process did not move the StopsOnStreets feature from its original location, and the line generated between them has no length or a very tiny length that is too small for use in a network dataset. Messages like SourceName: StopConnectors, ObjectID: 232, The edge feature is too small to participate in snapping and may not be connected to other features are common in this scenario.

   As long as the Stops feature and its associated StopsOnStreets feature are spatially coincident, proper network connectivity will be maintained, and the network will be able to model travelers boarding and alighting at this stop. However, if you plan to model a time cost for boarding and alighting by adding an impedance to the StopConnectors features, boardings and alightings at this stop will likely not incur the desired time cost impedance since it is not necessary to traverse the connector or the connector is not included in the network dataset.

   If you want to correct the problem, you need to manually move the Stops feature and the endpoints of all LineVariantElement features connected to it so that they are no longer spatially coincident with a street. Afterward, if necessary, edit the StopConnectors feature to properly connect the Stops feature and its associated StopsOnStreets feature. The direction of digitization of the StopConnectors features should be from the stops toward the streets.

   Learn how to use map topology to maintain connections between features when moving them

   Caution:

   If your problems are very widespread or you have other build errors, you may need to spend time editing the streets feature class or use a different one entirely.

Run a service area analysis

In this section, you will create a service area that shows the area reachable by public transit and walking within 30 minutes of a starting location at a particular time of day using the network dataset you created in the previous sections.

Learn more about service area analysis

Create and configure the service area layer

A service area layer provides the structure and properties needed to set up and solve service area problems. It also contains the results after solving.

1. On the Analysis tab, in the Workflows group, click Network Analysis > Service Area .

   The Service Area layer is added to the Contents pane. It includes sublayers that contain the inputs and outputs of the analysis.

2. In the Contents pane, click Service Area to select the group layer.

   The Service Area Layer tab appears.

3. Click Service Area Layer to see the available settings on the ribbon.

   

   You'll use these controls to define the service area you want to generate.

   Tip:

   The Service Area Layer tab appears only when you select a service area layer in the Contents pane. Also, if you have multiple service area layers, you can change the settings of the layers individually or select the multiple layers to edit the settings for all the selected layers if they share the same network data source. each has its own tab.

4. On the Service Area Layer tab, in the Travel Settings group, notice that the Mode control is set to Public transit time.

   This travel mode is the default travel mode of the network dataset. This travel mode represents travel by public transit and walking.

5. On the Service Area Layer tab, in the Travel Settings group, change the Cutoffs value to 30.

   This change causes the output service area polygon to represent the area reachable within a 30-minute travel time.

   Learn more about the service area Cutoffs option

6. In the Date and Time group, change the Arrive Depart Date-Time Type drop-down value to Day of Week.

   You must specify a time of day for the service area analysis to use the public transit schedules in the network dataset. Without a time of day, all transit lines are treated as restricted because the Public Transit evaluator cannot calculate the travel time without a specific time of day.

   Learn more about the Arrive Depart Date-Time Type options

   Note:

   If you are using your own GTFS data and you determined earlier that you need to use specific dates for your analysis instead of generic weekdays, select Date & Time instead of Day of Week.

   The Time of Day and Date controls are now available.

7. Change the Date value to a weekday of your choice.

   Note:

   If you specified Date & Time instead of Day of Week, change the Date control to a date of your choice that falls within the date range of the GTFS data's calendar.txt and calendar_dates.txt files.

8. Change the Time of Day value to a time of day of your choice when transit service is likely to be running, such as 5:15 PM.
9. In the Output Geometry group, click the Exclude Edge Sources button to show a drop-down menu.

   The LineVariantElements edge source is excluded from polygon generation by default. This means that service area polygons will not be generated around LineVariantElements features even though those features may be traversed in the analysis. This is the desired behavior. Travelers taking public transit can only exit the vehicle at stops, so the area surrounding the transit lines should not be shown as reachable by the service area polygons unless the traveler can exit at a stop and walk along the streets to reach that area.

10. Close the Exclude Edge Sources drop-down menu without making any changes.

Draw a facility

A service area facility is the starting point of your analysis. The service area polygon will show the area reachable from this facility within the time limit you specified in the Cutoffs control on the Service Area Layer tab. In this section, you will draw a service area facility in the map.

Note:

You can also import existing points as facilities by clicking the Import Facilities button on the Service Area Layer tab.

1. In the Input Data section, click the Create Features button.

   The Create Features pane appears, showing a list of layers that can be edited.

2. Under Service Area: Facilities, click Facilities to activate the default editing template.
3. Use the Point tool to create a facility on the map in the area near a lot of public transit stops, such as in the city's downtown.
4. On the Edit tab, click Save to save your edits.

Solve the service area and examine the results

Now that you have created and configured the service area layer and added a facility, the service area is ready to solve. In this section, you will solve a service area and examine the results.

1. On the Service Area Layer tab, in the Analysis group, click Run .

   A service area polygon is generated in the map. This polygon represents the area reachable from the facility by public transit and walking within 30 minutes of travel time if the traveler starts at the time of day you specified. It should extend from the facility along some of the public transit lines in your system.

   Your output service area polygons may include multipart features showing seemingly disconnected areas around transit stops or stations. This is expected and correct. If you're creating a 30-minute service area, your traveler could exit the train at a station after traveling for 25 minutes and walk for 5 minutes, or they could continue traveling and exit the train at the next station after 28 minutes and have only 2 minutes remaining for walking. However, since trains typically go faster than people walk, the walking traveler could not reach all the areas between the two stations without exceeding the 30-minute travel time limit. Consequently, a small area around each station is reachable within 30 minutes, but much of the area between the stations is not, and the 30-minute Service Area polygon will contain each of these disconnected areas surrounding the reachable stations.

   

2. On the Service Area Layer tab, in the Arrive/Depart Time group, change the Time value to a different time of day of your choice. For example, choose a time of day during off-peak hours when there is less public transit service available, such as 2:00 PM.

   Note:

   If the Service Area Layer tab is not visible, in the Contents pane, click Service Area to select the group layer.

3. On the Service Area Layer tab, in the Analysis group, click Run .

   The service area polygon is altered. The service area now represents the reachable area if the traveler starts at the new time of day you specified. Because the available public transit service is different at different times of day, the area reachable by a traveler using that public transit service will be different.