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.

[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]

Okay, I understand the problem, and I can reproduce it on my end.  It seems like a bug in the Calculate Locations tool that the Status field is coming back as 0 instead of 7 for those points.  I will log the issue, and we'll see about fixing it.

In the meantime, a workaround for you is to use the Add Locations tool instead of Calculate Locations.  You can create a dummy NA layer of any type and use Add Locations to load your points into it to calculate the network locations.  I just tested this, and this definitely works and returns the correct code of 7.

[MelindaMorang]

The Calculate Locations issue is now logged in our system as BUG-000170977.  If you need updates on this issue, you can contact Esri Support with this bug number.  I will also post an update here once we've fixed it.

[melisahansen]

Great, thank you. We will keep an eye out for the bug fix. 

[MelindaMorang]

We investigated this problem and found it to be a very simple bug.  We fixed it, and the fix will be available in the forthcoming ArcGIS Pro 3.4 release.  We also flagged the issue as something we can potentially fix in future patches of older versions of the software.

[melisahansen]

@MelindaMorang Thank you for looking into this and reporting the bug! Another question we had regarding the calculate locations tool is about the SourceID field. It calcs to 4, but we aren't sure where that comes from. Do you know what the 4 is and if there's a way to have the SourceID field be calculated to a specific field like a unique identifier we could connect back to our source data with? 

[MelindaMorang]

The SourceID field refers to the feature class ID of the network dataset source feature class the point was located on.  So if it locates on Streets OID 500 (I made that up), it will have a SourceID of 4 (or whatever the feature class ID of Streets is) and a SourceOID of 500.

Some networks have multiple edge sources (like Streets and Sidewalks, for instance), or sometimes your locate settings allow you to locate on both edges and junctions.  The SourceID field helps you distinguish which of these network source the point located on.

This documentation explains the meaning of the various network location fields: https://pro.arcgis.com/en/pro-app/latest/help/analysis/networks/locating-analysis-inputs.htm#ESRI_SE...

However, reading between the lines of your question, I'm guessing what you're actually wanting to know is how to relate the points loaded into your NA layer sublayer (Facilities, Incidents, etc.) back to the original dataset you loaded.  You are looking for a way to join the data using the ObjectID or some other unique identifier.  Is that right?

Here's the process I recommend for that:

1. Make sure your input points have some unique ID field.  You can use the ObjectID field if you want, but if you have some other unique ID field in the data that you use for your record keeping, that might work better.
2. After creating your NA layer, use the Add Field To Analysis Layer tool to add a field to the sublayer you're going to add the points to (Facilities, Incidents, etc.).  Give it whatever name and type make sense.  You are going to map your input data's unique ID field to this new field.
3. When you run Add Locations, use the field mapping control to map your input data's unique ID field to your newly added field.
4. After Add Locations runs, you can run Join Field or Add Join or whatever other procedure to transfer the information you need back to your original dataset.  You can use the field you added to the sublayer and the original data's unique ID field as the fields to join with since they should have corresponding values.

[melisahansen]

Thank you @MelindaMorang. We currently have a workaround until we upgrade to the next version that has the bug fix. Again, thank you for all the information you provided!