This page describes how to troubleshoot unexpected results received when solving a network analysis using a local network dataset in ArcGIS Pro, particularly a network dataset you or your organization has created using your own data.
Unexpected network analysis results can often be attributed to one of the following causes:
- A problem with the configuration of the network dataset used to solve the analysis
- A problem with the source data used in the network dataset
- A problem with the settings used for the analysis
- A misunderstanding of the solver's settings or functionality
The sections below describe many common unexpected network analysis results and their symptoms, common problems leading to unexpected results, and tools and techniques for troubleshooting unexpected results.
Common unexpected results and other symptoms
The sections below list many commonly occurring unexpected analysis results and other symptoms and their potential causes. Many of these symptoms have multiple possible causes. Links are provided to other sections in this document describing those possible causes in more detail, along with tips on how to investigate and resolve them.
Below is the list of possible unexpected results. Click each one to see the details:
- The solve failed with No solution found or ERROR 030212: Solve did not find a solution
- Route doesn't take the most direct path or makes a large diversion
- The reported closest facility isn't actually the closest facility
- The solve returned no Facilities found or no Destinations found warnings
- Some origins in an OD cost matrix don't find any destinations, but other nearby origins find many
- No solution is found when I apply a cutoff
- Route travels randomly all over the network
- Costs seem inaccurate
- Restrictions are ignored or roads are unexpectedly restricted
- The route goes the wrong way down a one-way street
- The route makes illegal turns or fails to make a legal turn when expected
- The route turns off the top of a bridge onto the road below
- The route makes a U-turn at a stop even though the U-turn policy is set to No U-turns
- The route path starts or stops at an unexpected location, not the street closest to the input point
- Inputs are unlocated
- Service area polygons are very small or very large
- Service area polygons are missing sections or have unexpected shapes
- Service area polygons cover areas outside the designated trim distance
- The travel times and times of day in the directions don't match the values in the attribute tables
- Rush hour and non-rush hour routes in a fleet routing analysis are the same
- An order or stop in a fleet routing solve wasn't included in a route
- The network models public transit, but the transit lines are never used
- Line barriers are ignored
- Route geometry doesn't match the geometry of the underlying streets
- Solve result doesn't reflect updates made after editing the network
- The Build Network tool returned build errors (WARNING 030116)
The solve failed with No solution found or ERROR 030212: Solve did not find a solution
The solve failed and returned an error message because the solver could not calculate a path connecting the input locations. It is not possible to travel between the points on this network dataset.
This result may be a valid and correct solution. For example, if the stops are located on disconnected islands, there may be no way to travel between them by road. Or, if barriers are used in the analysis, a barrier might obstruct the only path to one of the stops. Alternatively, this result may be an indication of one or more problems with the analysis settings or network dataset used for the analysis.
Problems affecting network connectivity are particularly likely. If streets aren't properly connected at intersections, it may not be possible to travel through those intersections, causing parts of the network to be cut off from others.
The following are common problems affecting network connectivity:
- Gaps or dangles at intersections
- Missing endpoints or vertices at specific intersections
- Incorrect turns
- Incorrect group connectivity policy
- Incorrect hierarchy values
- Incorrect network model
Other potential problems include the following:
Route doesn't take the most direct path or makes a large diversion
The route between points appears unreasonable, indirect, or suboptimal or makes a large diversion from the expected shortest path.
Problems affecting network connectivity are particularly likely. If streets aren't properly connected at intersections, it may not be possible to travel through those intersections, requiring large diversions to find a path.
The following are common problems affecting network connectivity:
- Gaps or dangles at intersections
- Missing endpoints or vertices at specific intersections
- Incorrect turns
- Incorrect group connectivity policy
- Incorrect hierarchy values
- Incorrect network model
Incorrect restrictions could also cause the route to make large diversions.
The reported closest facility isn't actually the closest facility
The result of a closest facility analysis seems inaccurate. The reported closest facility for a given incident isn't actually the closest facility. Another facility seems closer but wasn't found.
The facility that should be considered closest may be cut off or inaccessible due to problems with network connectivity or incorrect restrictions. See Route doesn't take the most direct path or makes a large diversion.
The solve returned No Facilities found or No Destinations found warnings
A closest facility analysis returned warnings like No Facilities found for <value> in Incidents. An OD cost matrix returned warnings like No Destinations found for <value> in Origins. The analysis returned WARNING 030025, warning about a partial solution being generated.
No path could be found between a subset of origins and destinations or incidents and facilities. This result may be a valid and correct solution. For example, if a cutoff was used in the analysis, some origins may not be within the cutoff limit of any destinations. Or, if the inputs are located on disconnected islands, there may be no way to travel between them by road.
Alternatively, this could be an indication of a problem with the network used for the analysis or the analysis settings. See The solve failed with No solution found or ERROR 030212: Solve did not find a solution as this problem usually has similar causes.
Some origins in an OD cost matrix don't find any destinations, but other nearby origins find many
An OD cost matrix analysis with many origins and destinations returns strange results. Some origins find many or all destinations, but other nearby origins that should have a similar result find none or few.
No path could be found between some origins and any or many destinations. Since other very nearby origins had a very different result, it's likely a problem with connectivity in the network dataset. Some origins are located on roads that are disconnected from the rest of the network.
The following are common problems affecting network connectivity:
No solution is found when I apply a cutoff
The solve fails when a cutoff is applied or no path is found between an origin-destination pair or incident-facility pair when a cutoff is applied. If the cutoff is removed, a reasonable solution is found.
This could be an indication that the units of the applied cutoff and the impedance attribute used by the travel mode for the analysis mismatch.
Learn how to check the units of the travel mode
Alternatively, it could be an indication of an incorrectly configured cost attribute, particularly if the overall cost seems incorrect even if the path is correct. See Costs seem inaccurate. If the path seems inaccurate, see Route doesn't take the most direct route or makes a very large diversion.
Route travels randomly all over the network
The route appears to travel randomly all over the network.
The solvers always calculate the shortest path using the provided network. A path that appears unreasonable usually indicates a problem with the underlying network.
If the route appears to travel randomly all over the network, this may be an indication that the cost attribute configuration is incorrect, resulting in cost attribute values of 0. If it costs 0 time or distance to traverse a network edge, it is impossible to calculate a shortest path. All paths are free. See Incorrect cost attribute configuration.
An unexpected and apparently random route could also be caused by various connectivity problems. See Route doesn't take the most direct route or makes a very large diversion for other potential causes.
Costs seem inaccurate
The calculated travel time, distance, or other cost seems wrong.
The Network Analystsolvers optimize a cost attribute on the network dataset. Costs may appear incorrect if the wrong cost attribute was used for the analysis. If the correct cost attribute was used, there may be a problem with that cost attribute's configuration. See the Incorrect cost attribute configuration section.
Restrictions are ignored or roads are unexpectedly restricted
The route travels on roads that should be restricted or avoids roads that should not be restricted.
This usually indicates a problem with the restrictions applied for an analysis. First, verify that the desired restriction attributes were applied for the analysis. If so, there may be a problem with that configuration of one or more restriction attribute. See the Incorrect restrictions section for tips on debugging and resolving restriction issues.
It's possible that restrictions aren't the cause of the problem. See also Route doesn't take the most direct route or makes a very large diversion for other possible causes of the behavior.
The route goes the wrong way down a one-way street
The route travels the wrong way down a one-way street.
One-ways are typically modeled as restrictions. Problems with one-ways usually indicate that either the one-way restriction wasn't applied for the analysis or that there's a problem with the configuration of the one-way restriction attribute. See the Incorrect restrictions section for tips on debugging and resolving restriction issues.
The route makes illegal turns or fails to make a legal turn when expected
The route makes a turn that should be forbidden, or it takes a seemingly longer path instead of making a turn at an expected location.
This is typically a problem either with modeling turns in the network or with network connectivity more generally.
The route turns off the top of a bridge onto the road below
The route made an impossible turn off the top of a bridge onto the road below, or vice-versa. The route traveled between underpasses and overpasses in a way that should not be allowed.
This type of behavior generally indicates a problem with the network's vertical connectivity policy.
The route makes a U-turn at a stop even though the U-turn policy is set to No U-turns
The route arrives at a stop and then departs it in the direction it arrived from, effectively making a U-turn, even though the U-turn policy for the travel mode is set to No U-turns.
The travel mode's U-turn policy controls whether and where U-turns are allowed while the vehicle is driving between locations. It does not control whether a vehicle can turn around at a stop along a route. Some stops may have a driveway or parking lot where it is possible to turn around. Other stops may require the vehicle to pull over on the roadside in a location where it is unsafe or impossible to make a U-turn. To control the U-turn behavior at individual stops, set the CurbApproach field value for the stop.
The route path starts or stops at an unexpected location, not the street closest to the input point
The route path doesn't start or stop on the street closest to the input point.
If the route path starts or stops near the input location but not at the closest point on the network, see Inputs are located on the wrong network feature.
If the route path starts or ends at a completely unexpected location far away from the inputs, and if you added the inputs using precalculated location fields, those fields may be outdated or for a different network dataset. See Invalid or outdated location fields.
Inputs are unlocated
The solve produced warnings about unlocated inputs. The solve failed or produced WARNING 030025 stating that a partial solution was generated.
The geographic locations of inputs used in a network analysis rarely intersect exactly with the network edges and junctions. For this reason, all inputs undergo a process to locate them on the network, which finds the closest routable network location.
Learn more about locating points on a network
If some points are unlocated, this means that valid network locations for those points could not be found given the constraints of the locate settings and the travel mode applied for the analysis. Unlocated points can be identified by checking the Status field in the input table for values of 2 (Network element not located) or checking the SourceID field for values of -1.
A common reason points may be unlocated is if they are very far from the network, beyond the search tolerance. See Wrong locate settings and Inputs are located on the wrong network feature.
Service area polygons are very small or very large
Service area polygons are unreasonably small or large for the cutoff used.
This could be an indication that the units of the applied cutoffs and the impedance attribute used by the travel mode for the analysis mismatch.
Learn how to check the units of the travel mode
Alternatively, it could be an indication of an incorrectly configured cost attribute. See Costs seem inaccurate.
Unreasonably small service area polygons could indicate a network connectivity problem or a problem with restriction attributes. See The solve failed with No solution found or ERROR 030212: Solve did not find a solution.
Service area polygons are missing sections or have unexpected shapes
Service area polygons don't appear to cover some expected streets or are missing large sections, resulting in strange shapes.
Service area polygons are generated around roads reachable from the facility within the specified cutoff limit. Strangely shaped polygons may be an indication of network connectivity problems. Try generating service area lines to see which streets were reached.
The following are common problems affecting network connectivity:
Service area polygons cover areas outside the designated trim distance
Service area polygons cover large areas with no roads in them, appearing to ignore the trim distance setting.
Service area polygons are an artistic representation of the area reachable within the cutoff limit, and the polygon output can vary significantly based on the user's settings. However, the service area trim distance is used only for buffering roads at the edges of the service area that are not surrounded by other reachable roads. It is not designed to influence interior parts of the reachable area. Areas that are fully surrounded by reachable roads are fully covered over, even if the area within is farther from the road than the trim distance.
To generate a polygon that includes only the area within the trim distance of reachable roads, configure the service area analysis to output lines instead of polygons and use the Buffer or Pairwise Buffer tool to create simple buffers.
The travel times and times of day in the directions don't match the values in the attribute tables
For a vehicle routing problem, last mile delivery, or waste collection solve, the travel times and times of day shown in the turn-by-turn directions don't match the values in the attribute tables.
This inconsistency is expected. The fleet routing solvers use a time-neutral origin destination cost matrix (OD) to determine the route assignment and sequencing. The values from this time-neutral OD are used to populate the time and distance costs reported in the attribute tables for consistency with the optimization logic used to solve the problem. After the sequence of stops is finalized for each route, the route solver is used to generate directions and uses the actual starting time of the route, allowing the directions fields to be populated with more accurate arrival times based on traffic for the times of day when they are visited.
Rush hour and non-rush hour routes in a fleet routing analysis are the same
Changing the time of day for a route for a vehicle routing problem, last mile delivery, or waste collection solve doesn't change the route, even though rush hour traffic should have an impact.
This is expected. The fleet routing solvers use a time-neutral origin destination cost matrix (OD) to determine the route assignment and sequencing. The values from this time-neutral OD are used to populate the time and distance costs reported in the attribute tables, for consistency with the optimization logic used to solve the problem.
Consequently, this portion of the result will be the same regardless of the time of day used for the route.
After the sequence of stops is finalized for each route, the route solver is used to generate directions and uses the actual starting time of the route, allowing the directions fields to be populated with more accurate arrival times based on traffic for the times of day when they are visited. Thus, the driving directions should change to reflect rush hour traffic.
An order or stop in a fleet routing solve wasn't included in a route
An order or stop in a vehicle routing problem, last mile delivery, or waste collection analysis wasn't included in a route. The solve returned warning messages saying not all orders or stops were routed.
This typically occurs because the stop violated one or more constraints of the analysis problem. Check the ViolatedConstraint_# fields to see which constraint prevented the order or stop from being included.
The network models public transit, but the transit lines are never used
The network includes public transit using the public transit data model tables and feature classes, but when you solve the analysis, the transit lines aren't used.
First, ensure that the impedance attribute for the travel mode used for the analysis is configured with the Public Transit evaluator. Learn how to check the impedance attribute for the travel mode used by a network analysis layer.
Next, check the date and time used for the analysis. If no date and time are set, the transit lines will never be used. If a date and time are set, but there is no transit service available at that date and time, the transit lines will not be used.
Learn more about the requirements for dates and times when using the Public Transit evaluator
If setting the date and time to an appropriate value still doesn't fix the problem, it's possible the network has a connectivity problem. If the transit lines are not connected to the streets, the traveler won't be able to enter and exit the transit system. See Gaps or dangles at intersections and Incorrect group connectivity policy. For information about connectivity policies more specific to public transit networks, review the relevant sections in the Create and use a network dataset with public transit data tutorial. If the StopsOnStreets features did not snap properly to the streets, it may indicate a problem with the spatial reference, and you must recreate the network from scratch following the tutorial, being sure to project the streets into the desired spatial reference before running the Connect Public Transit Data Model To Streets tool.
Line barriers are ignored
Line barriers are included in the analysis, but the route travels on roads that should be restricted by the line barrier. The route appears to travel right under the barrier or under part of the barrier. A scaled cost line barrier isn't scaling the entire street's cost value as expected.
Line barriers can be used to restrict travel through a particular area or scale the cost of that travel.
If the line barrier's geometry was constructed to follow the underlying street but doesn't match the street's geometry exactly, some parts of the street may be unrestricted or unaffected by the scaled cost barrier. Edit the line barrier so it matches the street geometry exactly. The Trace tool can be helpful when editing the feature.
Some workflows involve solving a route and then using the route path as a line barrier. For this type of workflow, turn off the travel mode's simplification tolerance to ensure the route shape exactly matches the underlying network.
Learn how to adjust the simplification tolerance
For a restriction barrier, sometimes making the line barrier match the street geometry is not the most effective way to restrict travel. Consider altering the line barrier to cross the street at the location where the restricted portion starts instead of making the line match the full street feature. Alternatively, use a polygon barrier or use a point barrier with the FullEdge field set to True to restrict travel along the entire street.
Route geometry doesn't match the geometry of the underlying streets
The route geometry doesn't match the geometry of the network dataset's source feature classes.
If the geometry is close but not exact, it could be because the travel mode used for the analysis applied a simplification tolerance. Learn more about travel mode settings. If this is the case, the small differences are expected.
If the geometry is completely different, it could be a sign that the network dataset has been edited but not rebuilt, and the geometry of the street features has changed. See Network dataset is unbuilt.
Solve result doesn't reflect updates made after editing the network
You edited the network dataset source features or their field values or the network dataset properties, and the analysis results don't reflect those changes.
The network must be rebuilt after it is edited. See Network dataset is unbuilt.
The Build Network tool returned build errors (WARNING 030116)
Common problems
Unexpected network analysis results are generally caused either by problems with the network dataset used for the analysis or incorrect settings used for the analysis. Or, if the network and the analysis settings are correct, you must determine why the results are the way they are.
Several common problems that can lead to unexpected analysis results are listed in this section along with suggestions for how to diagnose and fix them.
- Network dataset is unbuilt
- The network has unresolved build errors
- Gaps or dangles at intersections
- Incorrect group connectivity policy
- Incorrect vertical connectivity policy
- Missing endpoints or vertices at specific intersections
- Incorrect cost attribute configuration
- Incorrect restrictions
- Incorrect travel on one-way streets
- Incorrect or very restrictive U-turn policy
- Incorrect turns
- Incorrect hierarchy values
- Inputs are located on the wrong network feature
- Wrong locate settings
- Invalid or outdated location fields
- Incorrect network model
Network dataset is unbuilt
Whenever you update the network dataset properties or edit the network's source feature classes, the network dataset must be built before those changes will be used in a network analysis.
Learn more about the types of edits that requires a rebuild
Many types of unexpected results may occur if the analysis is solved when the network has been edited but not yet rebuilt. Routes may not use updated streets, the geometry may not match the underlying street features, costs may be inaccurate, and restrictions may be ignored.
Determine if the network needs to be rebuilt
To determine if the network needs to be rebuilt, complete the following steps:
- Open the  Network Dataset Properties dialog box.
- Click General.
The page displays general information about the network dataset.
- Check the information displayed under the Build Status section.
If the status is Not Built, the network dataset must be rebuilt. If the status is Built but the number of edges and junctions is 0, there is a problem with the network dataset, likely unresolved build errors.
The network has unresolved build errors
When you run the Build Network tool to build a network dataset, a warning message may appear (WARNING 030116) indicating that the build succeeded but there were some errors. Some build errors are safe to ignore, but others are serious and can cause incorrect or incomplete analysis results. Review build errors before doing analysis with the network.
Many types of unexpected results may occur if the network has unresolved build errors. Common major problems that must be fixed usually involve attribute evaluators and turns.
After running the Build Network tool, look for WARNING 030116. The warning message text includes a path to a build error text file. The text file is stored in a temporary location and is deleted when you close ArcGIS Pro. If you no longer have access to the build error text file, rerun the Build Network tool. Use the Do full rebuild option to do a full rebuild to ensure you see all the errors.
Open the build error text file and review the build errors.
Gaps or dangles at intersections
To model travel from one street to another in a network, the features must be properly snapped together at intersections. Digitization errors can produce small gaps between streets that should be connected at intersections or small dangles where a street overshoots an intersection by a small amount instead of snapping to the other street. These gaps and dangles will prevent travel from one street to the other in the network dataset.
Disconnected intersections may cause a route to fail because no path can be found, to make a large diversion to find an alternate path, or to make an unexpected turn.
To check for gaps and dangles, add the network's source feature classes to the map and zoom in to visually inspect a problematic intersection. Do the streets touch, or are there visible gaps or dangles? The Explore Network tool can also be used to click a specific street and identify which other streets are connected to it. Service area lines can be used to narrow in on problem spots. Topology can also be used to flag gaps and dangles for the entire network but may produce many false positives.
If you have a small number of gaps and dangles in specific locations, you can use the editing tools to manually correct them. It is recommended that you enable snapping to assist in editing. For features that participate in a network dataset, certain automatic behavior will assist in keeping streets well connected.
If you have widespread problems, the Extend Line tool can be used to remove gaps and the Trim Line tool can be used to remove dangles.
Several other problems may also be responsible for disconnected intersections:
Incorrect group connectivity policy
The network dataset's connectivity policy controls whether features that touch at intersections are considered logically connected in the network and therefore whether it is possible to travel between them. The group connectivity policy controls connections between coincident features from different source feature classes and connections between coincident features within the same source feature class.
Learn more about network connectivity
Although no group connectivity policy is inherently incorrect, a policy may be ill-suited to the configuration of the source feature classes in the network, leading to disconnected intersections. When this happens, it may cause a route to fail because no path can be found, to make a large diversion to find an alternate path, or to make an unexpected turn. This usually presents as a systemic problem across the entire network rather than a problem specific to a single intersection or area.
The most common cause of group connectivity policy problems is an incorrect choice of connectivity policy for edge sources. In particular, if the street features are long lines that intersect many other streets, use the Any Vertex edge connectivity policy instead of Endpoint. With Endpoint connectivity, features are only considered connected if they touch at endpoints. As a result, long lines that intersect at vertices will be considered disconnected.
Determine network connectivity
To determine if this is your issue, first check whether the network uses Endpoint connectivity for any of the edge sources:
- Open the Network Dataset Properties dialog box.
- Click Source Settings > Group Connectivity.
- Check the value of the Policy column for each edge source in the network.
If the edge sources already use Any Vertex connectivity, the problem could be another aspect of the connectivity policy or a different problem entirely. However, if the edge sources use Endpoint connectivity, continue investigating.
- Add the network's source feature classes to the map.
- Click or select a few street features, one at a time.
If the street features are long and cross over many other street features, Any Vertex is a more appropriate connectivity policy to use with this data instead of Endpoint, and the connectivity policy is likely causing the disconnections.
Several other problems may also be responsible for disconnected intersections:
- Gaps or dangles at intersections
- Incorrect vertical connectivity policy
- Missing endpoints or vertices at specific intersections
- Incorrect turns
If the connectivity policy is the source of the problem, you can fix it in one of two ways: change the connectivity policy to Any Vertex or break the source features at intersections.
Change the connectivity policy to Any Vertex
To change the connectivity policy to Any Vertex, complete the following steps:
- Open the Network Dataset Properties dialog box.
- Click Source Settings > Group Connectivity.
- For the edge source you want to change, use the combo box in the Policy column to change the policy from Endpoint to Any Vertex.
- Click OK.
The updated connectivity policy is saved to the network dataset.
- Use the Build Network tool to rebuild the network dataset with the new connectivity policy.
When using the Any Vertex connectivity policy, carefully check overpasses and underpasses. If there is a vertex at these locations, the streets will be incorrectly connected. You can fix this by removing the vertices or making other manual edits.
Break up the source features at intersections
Instead of changing the connectivity policy to Any Vertex, you can continue using Endpoint connectivity if you edit the source features, breaking them up to have endpoints at all intersection points.
- Review and configure the split and merge policies on your geodatabase domains.
This is needed if your streets have field values that must be updated whenever features are split (for example, precalculated travel time or distance fields).
- Add the network edge source feature class to the map.
- Select all the features in that source feature class.
- If your data selection contains bridges, tunnels, overpasses, or other locations where streets cross over or under each other but do not physically connect, remove these features from the selection.
Alternatively, you can fix these locations manually after you run the tool.
- If necessary, deselect streets features that cross other street features but do not physically connect.
- Use the Planarize editing tool to split them at points where they intersect one another.
Incorrect vertical connectivity policy
The network dataset's connectivity policy controls whether features that touch at intersections are considered logically connected in the network and therefore whether it is possible to travel between them. The vertical connectivity policy is used to model connections at overpasses and underpasses and vertically stacked features.
Learn more about network connectivity
Problems with vertical connectivity are often limited to specific intersections. For instance, a route makes a left turn off the middle of a bridge onto the road traveling beneath the bridge. Or, a route may fail to travel through an intersection because it is vertically disconnected even though it shouldn't be.
The Explore Network tool can be used to click a specific street or junction and identify which other streets are connected to it.
If the network uses X, Y, and Z geometry values to control vertical connectivity, any vertical connectivity problems are likely due to problems with the geometry of the source features. Use the editing tools in a map or scene to correct these geometry problems.
Learn more about using geometry for vertical connectivity
If the network uses elevation fields for vertical connectivity, the problem is likely due to the elevation field values of the features representing the intersection. If the elevation field values are the same, the features will be considered connected. If they're different, the features will be considered disconnected. Edit the field values to correct connectivity problems.
Learn more about using elevation fields for vertical connectivity
Several other problems may also be responsible for disconnected intersections:
Missing endpoints or vertices at specific intersections
The network dataset's connectivity policy controls whether features that touch at intersections are considered logically connected in the network and, therefore, whether it is possible to travel between them. With Endpoint connectivity, features must meet at endpoints to be considered connected. With Any Vertex connectivity, features must have either an endpoint or a vertex to be considered connected. If endpoints or vertices are missing at intersections, these intersections will be disconnected, and travel will not be possible through the intersection.
Learn more about network connectivity
Disconnected intersections may cause a route to fail because no path can be found, to make a large diversion to find an alternate path, or to make an unexpected turn. If you have widespread problems of this nature, first verify that you're using the correct connectivity policy for your data. If you are confident that you're using the correct connectivity policy and you have a few problem areas, you may need to manually investigate and edit features at specific intersections.
Use the Explore Network tool to click a specific street and identify which other streets are connected to it. You can also use network dataset layer symbology to symbolize the locations of junctions in the network dataset. If two edges cross each other but do not have a junction at the point of intersection, they are not connected. Service area lines can also be used to narrow in on problem spots.
Use the editing tools to manually correct features as needed.
If you're using Any Vertex connectivity, the Integrate tool can be used to automatically generate vertices at all points of intersection. Make a backup copy of your data first because the Integrate tool can cause unexpected changes to the feature geometry. Check underpasses and overpasses manually to remove any vertices for streets that shouldn't be connected.
Several other problems may also be responsible for disconnected intersections:
Incorrect cost attribute configuration
Solving a network problem involves minimizing or optimizing a value, usually travel time or distance. The value to be optimized is the impedance attribute for the travel mode used by the analysis. Unexpected analysis results can occur if the wrong cost attribute is used for the impedance, if the configuration of that attribute is incorrect, or the source data being referenced by the attribute has bad values.
Problems with cost attributes frequently manifest as travel times or distances with unreasonable values, even if the path traveled seems reasonable. Service area polygons that are very small or very large can also be a symptom. If the analysis uses a cutoff, sometimes no solution is found within the cutoff, but removing the cutoff allows the solve to succeed.
First, determine whether the correct cost attribute was used as the impedance for the analysis. Learn how to check the impedance attribute for the travel mode used by a network analysis layer. Also check the units of the impedance attribute. Many output travel cost fields are reported in these units, and input fields and settings, such as cutoffs, should be specified in these units.
If the correct cost attribute was used and the units were interpreted correctly, the next step is to check whether the cost attribute is configured correctly. You can use the Explore Network tool to examine the value returned for each network element for a given cost attribute and to debug problems.
Use the network dataset property pages to examine the cost attribute configuration. In particular, check the evaluators, which control how the cost value is calculated.
Learn more about cost attribute configuration on a network
Even if the cost attribute's configuration is correct, the calculated values may be incorrect if the attribute uses Field Script evaluators and the fields referenced have incorrect values. If this is the case, the network's source feature classes may need to be updated.
Learn more about Field Script evaluators and see examples
If you make any changes to the cost attribute, you must rebuild the network before retrying the analysis or using Explore Network to examine values.
Note:
Cost attribute values may be incorrect if the attribute or source feature field values were edited, but the network was not rebuilt, or if the network was rebuilt but has unresolved build errors.Incorrect restrictions
Restriction attributes are used to prevent travel on certain roads in a network. For example, a restriction can be configured to prevent tall trucks from traveling under low bridges or to prevent pedestrians from walking on highways. If restriction attributes aren't configured correctly, travel may be incorrectly allowed or forbidden on certain road segments.
If the route travels down a street that should be restricted or goes around a street that you expect to be traveled on, there might be a problem with the restriction attribute. A restriction attribute could be incorrectly preventing travel on streets that should be unrestricted. Widespread problems with restrictions could cause a route solve to fail if no path can be found.
First, determine whether the correct restrictions were applied for the analysis. Learn how to check the restrictions for the travel mode used by a network analysis layer. Also check any attribute parameter values for the restriction. For instance, a height restriction usually includes a parameter to specify the vehicle height.
To debug, turn off restrictions and rerun the analysis. If you get the expected results, turn the restrictions on one by one until the result changes. This indicates which restriction is causing the problem.
If the correct restrictions were used and the parameters had the intended values, the next step is to check whether the restriction attributes are configured correctly. The Explore Network tool can be used to examine whether a given road is restricted by each restriction attribute and can be used to debug problems. The network dataset layer symbology is valuable for visualizing the restricted status of roads across the entire network.
Use the network dataset property pages to examine the restriction attribute configuration. In particular, check the evaluators, which control how the restricted status is calculated.
Learn more about restriction attribute configuration on a network
Even if the restriction attribute's configuration is correct, the calculated values may be incorrect if the attribute uses Field Script evaluators and the fields referenced have incorrect values. If this is the case, the network's source feature classes may need to be updated.
Learn more about Field Script evaluators and see examples
If you make any changes to restriction attributes, you must rebuild the network before retrying the analysis or using Explore Network to examine values.
Note:
Restriction attribute values may be incorrect if the restriction attributes or source feature field values were edited, but the network was not rebuilt, or if the network was rebuilt but has unresolved build errors.
Incorrect travel on one-way streets
One-way streets in a network dataset are typically modeled as restriction attributes. If a route travels the wrong way down a one-way street or fails to travel down a one-way road in the correct direction, there is likely a problem with the one-way restriction attribute. See the Incorrect restrictions section for tips on debugging problems with restrictions.
Incorrect or very restrictive U-turn policy
The U-turn policy of the travel mode used for an analysis controls whether and where a vehicle can make a U-turn while driving between stops.
Learn more about U-turn policies
A restrictive U-turn policy can cause a solve to fail if it's not possible to travel between one stop and another without making a U-turn. Intermediate stops on a route located on dead ends are a frequent cause of this type of problem.
Change the U-turn policy to allow all U-turns and re-solve the route. If the solve succeeds, this is likely the cause of the failed solve. Travel is not possible between the stops while obeying the selected U-turn policy. You can ignore the problem if you're satisfied with the explanation for the failed solve. Otherwise, consider using a looser U-turn policy for your analysis. Learn how to check and update the U-turn policy for a network analysis layer.
The travel mode's U-turn policy controls whether and where U-turns are allowed while the vehicle is driving between locations. It does not control whether a vehicle can turn around at a stop along a route. Some stops may have a driveway or parking lot where it is possible to turn around. Other stops may require the vehicle to pull over on the roadside in a location where it is unsafe or impossible to make a U-turn. To control the U-turn behavior at individual stops, set the CurbApproach field value for the stop. Restrictive CurbApproach values in conjunction with a restrictive U-turn policy increase the likelihood of failed solves.
Incorrect turns
Turn restrictions prevent turns from one road to another or apply an added cost for making that turn. Turn features model turns at specific intersections, whereas global turns can be configured to control all turns of a specific type, such as left turns.
Learn more about turns in a network dataset
Turn configuration problems usually result in problems traveling through intersections. They may cause a route to fail because no path can be found, to make a large diversion to find an alternate path, or to make an unexpected turn at a location where one shouldn't be allowed. Problems with turn features usually affect only specific intersections, whereas problems with global turn configuration affect the entire network systemically.
Note that the purpose of turns in a network is to prevent illegal turns and to apply realistic travel time delays to turns. If a route doesn't turn at an intersection, this may be a correct result and not a problem. Examine the turn carefully to determine whether it is behaving as intended.
Turn features can be visualized in the map using network dataset layer symbology and examined individually using the Explore Network tool. Global turns cannot be visualized.
The cost attribute used as the impedance for an analysis may include turn delays for turn features and globally using the Turn Category evaluator. Each restriction attribute used for an analysis may additionally restrict specific turns. Use the network dataset property pages to examine the cost and restriction attribute configuration. In particular, check the evaluators, which control how the cost and restriction values are calculated, for turn feature classes and default turns.
Learn more about cost attribute configuration on a network
Learn more about restriction attribute configuration on a network
Turn feature class evaluators may be configured with Field Script evaluators, which reference the values of fields in the turn feature class. Even if the evaluator is configured correctly, the calculated values may be incorrect if the fields referenced have incorrect values. If this is the case, the values in the turn feature class may need to be updated.
Learn more about Field Script evaluators and see examples
Editing workflows may also result in problems with turn features. Turn features are linked to their associated edge features using a set of fields referencing the ObjectID values of the edge features. If the edges are edited, the ObjectID values may get out of sync. Use the Update By Geometry tool to resync the turn ID field values with the edges using the geometry of the turn and edge features. For future editing workflows, the Populate Alternate ID Fields and Update by Alternate ID Fields tools can be used to preserve IDs after edits.
If you make any changes to turn features or the configuration of cost or restriction attributes, you must rebuild the network before retrying the analysis or using Explore Network to examine values.
Note:
Turns may be incorrect if the turn features or cost or restriction attributes were edited, but the network was not rebuilt, or if the network was rebuilt but has unresolved build errors.
Several other problems may also be responsible for disconnected intersections:
Incorrect hierarchy values
Hierarchy is an order or rank assigned to network elements used to improve the performance of network analysis solves by limiting the number of streets that must be searched by the solver. Unexpected analysis results can occur if the hierarchy values assigned to edges are invalid (such as 0) or have gaps (not all hierarchy values are assigned to any edges in the network), or if the network is hierarchically disconnected (for example, level 1 edges are not connected at level 1).
Learn more about hierarchy in a network
Problems with hierarchy are subtle and can be hard to identify. Route paths may seem badly suboptimal. Sometimes a path cannot be found, but when stops are moved closer to each other a route is found, or a noticeably better route is found. Sometimes the costs between unchanged locations change after more points are added to or removed from the problem (particularly for OD cost matrix).
To determine if hierarchy is causing the problem, re-solve the analysis with hierarchy turned off.
Learn how to check whether hierarchy was used for the analysis and turn it off
If hierarchy seems to be the problem, use the network dataset property pages to examine the hierarchy attribute configuration. In particular, check the evaluators, which control how the hierarchy value for each edge is calculated, and check the hierarchy range values.
Learn more about hierarchy attribute configuration on a network
Hierarchy attributes are frequently configured to reference road class values. Even if the hierarchy attribute's configuration is correct, the calculated values may be incorrect if the attribute uses Field Script evaluators to reference road class values or other fields and the fields referenced have incorrect values. If this is the case, the network's source feature classes may need to be updated.
Inputs are located on the wrong network feature
The geographic locations of inputs used in a network analysis rarely intersect exactly with the network edges and junctions. For this reason, all inputs undergo a process to locate them on the network, which finds the closest routable network location.
Learn more about locating points on a network
Use the Explore Locations tool to visualize the network location for each analysis input point. To visualize all network locations at once, use the XY Table To Point tool with the SnapX and SnapY fields to create a layer of the inputs at their network locations. When loading inputs into the analysis, you can use the Snap to Network option in the Add Locations tool when importing inputs into a network analysis layer. This option creates the input points at their network locations (with some offset) instead of leaving them at their original locations.
If points are located on the wrong network feature, the route may appear to start and stop at an unexpected location. Usually, points are not actually located on the wrong network feature. They locate on the closest non-restricted network element, subject to the applied locate settings. It is necessary to understand the locating rules, and it may be necessary to adjust the locate settings or the geographic locations of the input points to ensure that points locate at the desired locations.
By default, inputs don't locate on network elements that are restricted or where travel is prevented by barriers. This ensures that each point can be reached even if it's not possible to access the closest network location. Input points in this situation can be identified by checking the Status field in the input; these points have a value of 7 (Not located on closest). Use the Explore Network tool and network dataset layer symbology to explore which network elements are restricted. If the restrictions seem incorrect, see Incorrect restrictions for more information.
Locate settings can be used to control where and how points get located, and incorrect locate settings could lead to undesired results. See Wrong locate settings for information about locate settings.
Points may locate along side streets instead of on the street their address is attached to or where their driveway entrance is. This typically happens because the point is geographically closer to the side street, which often occurs when using parcel centroids or rooftop address location points. These points can be manually corrected. However, preprocessing before locating the points on the network may be a better way to correct a large scale problem. Consider adjusting the locate settings and loading the inputs again using those updated settings. If the inputs were generated by geocoding addresses, try geocoding them again using the routing location instead of the rooftop location if the locator you're using has this option. You can use the Assign Streets To Points tool in generating address locations long the correct street.
If you precalculated network locations, the location fields may be outdated or invalid.
Wrong locate settings
The geographic locations of inputs used in a network analysis rarely intersect exactly with the network edges and junctions. For this reason, all inputs undergo a process to locate them on the network, which finds the closest routable network location.
Learn more about locating points on a network
Various locate settings control how inputs get located on the network. Locate settings control which network edge and junction sources points can locate on, whether to use a search query when locating, and the search distance to use. A setting also controls whether points can be automatically relocated at solve time if they are located on an element that becomes restricted by a barrier or change to the travel mode.
Learn more about locate settings and how to check their values for a network analysis layer
If the inputs for your analysis appear to be located in the wrong place, check the locate settings to make sure you're using the intended values.
Invalid or outdated location fields
The geographic locations of inputs used in a network analysis rarely intersect exactly with the network edges and junctions. For this reason, all inputs undergo a process to locate them on the network, which finds the closest routable network location. This network location is stored in a set of fields in the input's table.
Learn more about locating points on a network
You can precalculate network location fields and reuse them for different analyses. However, network location fields are only valid for the network dataset and travel mode that was originally used to calculate them. If the location fields are used for an analysis with a different network or travel mode, or if the network is edited after the location fields are calculated, the location fields are likely invalid and may cause unexpected behavior for the analysis. Routes may start and stop at unexpected locations, and some points may be unlocated.
Use the Calculate Locations tool to recalculate network locations for the analysis inputs using the network dataset and travel mode you plan to use for the analysis.
Incorrect network model
The network dataset source feature classes must include roads or other features that can be traveled upon, as well as junctions modeling intersections and turns modeling transitions through intersections. Once the network dataset has been created, it can be used to solve network analyses such as routes and service areas. The inputs for those analyses, such as stops, facilities, and barriers, should not be included in the network dataset. Those are specific to the analysis, and many different analyses can use the same network dataset.
Including the analysis inputs in the network dataset itself can result in many types of errors and unexpected behavior. Most commonly, routes may fail to solve because the inputs are located on junctions that are disconnected from the rest of the network. Additionally, building the network may generate build errors about stand-alone user-defined junctions.
Do not include analysis inputs as source features in the network dataset. Remove them from the network, rebuild the network, and try the analysis again.
Learn more about network dataset source feature classes and how to add or remove them
Troubleshooting tools and techniques
This section describes several tools and techniques that can be used to troubleshoot unexpected network analysis results.
- Explore Network
- Network dataset layer symbology
- Service area lines
- Topology
- Explore Locations
- Output layer packages or files from arcpy.nax solver object results
Explore Network
You can inspect network elements and attributes of a network dataset referenced by a network dataset layer or network analysis layer in the map display using the Explore Network tool. The tool can help identify the following:
- What network elements are associated with a source street feature
- What other network elements are adjacent to it
- The cost to traverse it
- Whether its attributes are configured properly to return the expected values
- Whether it is restricted by the active travel mode
The Explore Network tool is recommended as a first step for examining and diagnosing many types of unexpected analysis results.
Learn more about Explore Network
When using Explore Network to investigate unexpected analysis results, adjust the Explore Network settings to use the same travel mode as the network analysis layer you're investigating. This ensures that the values displayed for the attributes in the tool match those used in the analysis.
The Explore Network tool and network dataset layer symbology are complementary. While the network dataset layer symbology is valuable for visually assessing the overall correctness of the network and pattern of restricted streets, the Explore Network tool is valuable for investigating individual network elements or problem areas.
Network dataset layer symbology
The network dataset layer's symbology can be adjusted to assist with troubleshooting. In addition to basic rendering control of network edges, junctions, turns, traffic, and dirty areas, the network dataset layer's Symbology pane allows you to render network elements according to their restriction status for specific travel modes and show arrows on edge elements where traversal is allowed only in one direction (one-way roads).
Learn more about network dataset layer symbology
Network dataset layer symbology and the Explore Network tool are complementary. While the Explore Network tool is valuable for investigating individual network elements or problem areas, the network dataset layer symbology is valuable for visually assessing the overall correctness of the network and pattern of restricted streets.
When using network dataset layer symbology to investigate unexpected analysis results, adjust the Symbology options to use the same travel mode as the network analysis layer you're investigating. This ensures that the symbology displayed in the map matches the settings used in the analysis.
Service area lines
The service area solver is most commonly used to generate polygons showing the area reachable within a travel time or distance limit from a given location. However, the solver also has the ability to output line features representing the specific streets that could be reached within the travel time or distance limit. Service area lines can be a valuable tool for assessing and debugging network connectivity problems.
To use service area lines for network connectivity debugging, create a service area analysis layer, set the output type to Lines, add a facility near the area you want to investigate, and set a large cutoff value sufficient to reach the entirety of the area you want to investigate. If areas or individual streets aren't included in the service area output Lines, they may be disconnected. Use the Explore Network tool to investigate the connectivity further in specific problem spots.
Topology
Geodatabase topology can be used to identify, investigate, and correct line geometry problems that may cause problems in a network dataset that may, in turn, lead to unexpected network analysis results. You can use topology when first creating a network or when correcting widespread geometry problems in an existing network dataset's source features.
Use topology to identify and fix problems
Complete the following steps to use topology to identify and fix problems in network source features:
- Create a topology.
- Add one or more feature classes to the topology.
- Add rules to the topology.
- Validate the topology by applying the rules to the feature classes.
- Use the Error Inspector pane to investigate and correct the identified problems.
Many topology rules are available for line features. Recommended rules for network source features include 'Must Not Overlap (Line)', 'Must Not Self-Overlap (Line'), 'Must Not Self-Intersect (Line)', and 'Must Not Intersect Or Touch Interior (Line)'.
Explore Locations
The Explore Locations tool can be used to visualize the network locations of analysis inputs and examine their network location fields. Use the tool for troubleshooting where individual inputs are located on the network and experimenting with locate settings.
Learn more about locating points on a network
The Explore Locations tool can be found on the network analysis layer's ribbon. With the tool active, click the input feature in the map to see where it was located on the network and to view its location fields.
Output layer packages or files from arcpy.nax solver object results
If you're solving network analyses in Python using the arcpy.nax solver objects, use the saveAsLayerFile() method to analysis settings and results to a layer file or layer package so you can examine it and experiment with it in a map. Keep in mind, however, that the schema of network analysis layer inputs and outputs is different from the schema used by the arcpy.nax solver objects in many cases.
Learn more about saving a layer file or package from an arcpy.nax result
Troubleshooting tips for specific solvers
Each Network Analyst solver produces different types of results, and the types of problems described on this page can manifest differently. This section describes techniques for troubleshooting specific solvers.
Route
For a route with multiple stops, try removing the stops one by one until the result changes or the problem goes away. The most recently removed stop is likely the one causing a problem.
Service area
Service area polygons are an artistic representation of the area reachable within the cutoff limit, and the polygon output can vary significantly based on the user's settings. The actual algorithmic solution to a service area analysis is the streets that were reached. Configure the service area to return the lines output to see the streets that were reached. Service area lines are often valuable for finding problems with the network dataset used for the analysis.
OD cost matrix
Unexpected results in an OD cost matrix analysis can be difficult to identify and diagnose because the paths through the network from origins to destinations are not available. To investigate problems with a particular origin-destination pair, use the route solver so you can see the path taken.
If the analysis has a large number of origins and destinations, try to reduce the problem size to the minimum origins and destinations that reproduce the problem.
The Lines output includes one record for each origin-destination pair for which a path was found. If no record for an origin-destination pair exists in the Lines table, no path was found using the constraints of the analysis problem, such as the specified cutoff and the number of destinations to find.