nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Pro creating routes along closed segments by jumping to nearest routable segment

melisahansen

When routing on the same network different results are generated between ArcMap and ArcPro. In the below images, the highlighted segment is closed for routing, however in ArcPro, it jumps to the nearest routable segment and creates a route, which is not the desired result. The same routes in ArcMap produce the following error:

“Warning: Location "Graphic Pick 2" in "Stops" is on a non-traversable network element position.

Warning: Need at least 2 valid stops.

Error: "Stops" does not contain valid input for any route.”

How can we get ArcPro to behave in a similar way to ArcMap? In route properties, the Network Locations tab, the options are not the same between ArcMap and ArcPro so finding out how to get them to behave the same is not straight forward. We can set a search tolerance in Pro, but we don’t have to do this in ArcMap to get the desired result. Any ideas?

Figure 1: Routing jumping to nearest routable segment when attempting to route to a closed segment in ArcPro.

Figure 2: Routing jumping to nearest routable segment when attempting to route from a closed segment in ArcPro.

Figure 3: Routing error as expected when attempting to route to a closed segment in ArcMap.

Figure 4: Routing error as expected when attempting to route from a closed segment in ArcMap.

Find more posts tagged with

Accepted answers

All comments

melisahansen

@MelindaMorangThank you for this. We have been working through the steps you provided using the calculate locations tool. When we use a broad search tolerance, like the default, it ensures all points are located regardless of being on a restricted segment. It locates them based on the nearest routable segment as expected, however, we do not get a status flag of 7 we get 0. If we use a more restrictive tolerance more appropriate to the distance between point and segment, we only get status flags of 0 or 1, this however will give us a lot of 1 flags to go through, which is not feasible as we are searching through many points. There has been no configuration that we have seen that gives us a status flag of 7, which would be a more useful flag for us. The image below shows the result of the calculate locations tool with a broad tolerance. These 3 points are on a restricted segment, so they locate to the nearest routable segment, but we get a flag of 0.

MelindaMorang

I recommend approaching this using two major steps:

First locate all the points on the network and identify the ones that don't locate on the closest network element.
Then, using the remaining good records, do your Closest Facility analysis to identify any points that can't be reached for some other reason (disconnected network, other weird situations).

Here is a more detailed breakdown of how you would do this:

Add a field named "Status" of type Long to your feature class of input address points.
Run the Calculate Locations tool on your feature class of input address points.
1. Set whatever search tolerance and other locate settings make sense for your use case.
2. Be sure to set the travel mode you intend to use for your Closest Facility analysis.
Post-process the updated feature class of input address points. The Status field will have been updated to reflect the point's locating status. Select all features that have a Status field value of 1 (Not Located) or 7 (Not located on closest). (Alternatively, select all features with a value not equal to 0, which is the normal code for OK.)
1. Read more about the Status field codes here: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/closest-facility-analysis-layer.htm
The selected features are the ones that did not snap to the closest network element and are therefore invalid/not routable according to your rules. Do whatever you normally do to update your records with this information.
Switch the selection so only the good records are selected.
Create your Closest Facility layer and configure the settings as needed
Use the Add Locations tool to add the selected address points (the good records). You can use the field mappings to use the pre-existing location fields that you already calculated, and this will save you some time.
Add your fire stations as Facilities.
Solve the analysis.
Post-process the results to check for any address points that could not be reached using your normal method or by looking at the Status field, and update your records.

I'm still not sure what problems you're having with Search Tolerance, but if you continue to have them, feel free to add screenshots or specific steps, and maybe I can see where the problem is.

melisahansen

@MelindaMorang

Basically, we like to check our network for errors using a closest facility analysis. We do this to ensure our 911 network is routable to all addresses in our jurisdiction. We use this method to make sure every fire station etc, can get to every address without issue. In ArcMap, this process was easy and all addresses that are on restricted segments are caught as errors (we know we can just verify what segments we have restricted), but this method also allows us to find things that should not come in as errors. This allows us to then put notes in the 911 system so that dispatchers know of any current issues that might occur when they are trying to route emergencies.

When trying to duplicate this in Pro we are seeing snapping to the nearest routable segments, as there is not a search tolerance to account for all distance possibilities, so if there is indeed a routing issue, Pro is not catching them, meaning we are unable to alert Public Safety of these for them to put notes into the 911 system.

We have tried reconfiguring the settings and tolerances in every possible combination we can think of for loading facility/incident locations and for running the analysis. We assumed that snapping the locations to the network lines during loading and dropping the search tolerance for running would result in solutions more similar to what we were seeing in arcmap (not failing to locate points or jump to the nearest routable segments), but it doesnt seem as straightforward as expected

MelindaMorang

I'm sorry you're having trouble migrating this workflow from ArcMap. I'm happy to help you find a way to do this in Pro, which may be different from the way you did it in ArcMap. However, I still don't have a very clear picture of exactly what you're trying to do. What data are you starting with, and what information do you want to get from it?

"finding a lot of issues with changing the settings like the search tolerances etc. There does not seem to be a lot of consistency in results."

Can you describe these problems in more detail? What is your overall workflow? Maybe we just need to find the right set of steps for you, and we can resolve these issues.

Another idea for you: Have you tried symbolizing the network dataset in the map by restriction status? You can adjust the network dataset symbology to symbolize a particular travel mode, and it will visually show you which streets are restricted, etc. Some documentation on how to set this up: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/network-dataset-layer-symbology.htm

melisahansen

Is this behavior in Pro, version specific or is this how routing was designed in all of Pro?

MelindaMorang

Okay, I understand.

I think you may be able to achieve at least part of your goal by simply running the Calculate Locations tool or the Add Locations tool and checking the Status field or the network location fields afterwards. You don't actually need to do a solve operation to determine if the points are not routable.

You can also set the Search Tolerance property to something fairly small to reduce the likelihood of the point getting snapped to another street that's far away.

Does this help at all?

melisahansen

This is an important function to us as we use this to test areas that are not routable to public safety and many other purposes. For example, if a road is closed, we want it to fail - not jump to a near segment that does not actually have any connection or access to the closed segment. We want to know that a specific address is not routable, we do not want it to jump to a near segment and suggest routing to a non routable address via something nearby like the behavior exhibited. We also like to use this to determine sections of communities that may be impacted from proposed construction closures, floods, etc.

MelindaMorang

Hello Melisa. The behavior you're seeing in Pro is as designed. Points will always locate on the closest routable and non-restricted point on the network according to the specified locate settings and travel mode. In your case, the closest edge is restricted, so it locates on the next-best option.

When designing this behavior, our assumption is that there was no benefit to locating on a restricted edge or junction because this would just cause the route to fail or be unable to reach the point. Could you tell me what you're trying to do and why you want to see the solve failure?

A couple of other things that may be useful to you (just a guess, since I don't know what you're really trying to do):

When a point locates somewhere that isn't the closest option because the closest option is restricted, the Status field in the attribute table will be set to 7, or "Not located on closest". If you just need to determine which points aren't located where expected, you can filter the inputs to find rows with this value.
You might be able to achieve your goals by adjusting various locate settings, such as setting a search query, adjusting search tolerance, etc. This documentation may help: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/locating-analysis-inputs.htm

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.