Network Dataset: strange behavior with costs

[EspenFredrikGudevang]

Hi, my time- and distance-based costs is "changing places" after I have closed and opened ArcGIS Pro with my project.
The upper image is after I have created and built the network, and before I shut down ArcGIS Pro, and the lower image is the situation after I have opened ArcGIS Pro with the same project. As you can see in the lower image: my time-based cost now uses the distance attribute, and vice versa. 

A new, complete build removes this error, but I'd rather remove the cause instead of doing symptom treatment.

Any suggestions?

[MelindaMorang]

When you say "A new, complete build removes this error", do you mean that your network dataset was in an unbuilt state when you were using Explore Network initially?  Like maybe you edited the attributes or evaluators?  If that's the case, maybe the Explore Network tool was getting confused because of the change, and closing and reopening Pro refreshed some sort of cache.  Essentially, until the network is built, the changes to the attributes are not reflected on the internal, logical network that Explore Network reads, and the values might be incorrect.

If the problem is still reproducible after the network has been built, then I would consider it a bug of some sort that we would want to investigate.

[EspenFredrikGudevang]

No, it was not unbuilt, it was built in the very last step in a model builder "production line". And I have not changed any of the attributes and/or evaluators after that build. The only thing that I did after the build was to close (and reopen) Pro.

[RachelApplebaum]

Does this happen after every time you run the model? And would you be able to share your model (or a screenshot of it)?
Also, if you close and reopen Pro after seeing the issue, does it continue to flip the cost/impedance in Explore Network? Does it happen for every edge? Does it happen with junctions and/or turns as well?

Could you share a screenshot of the settings page from Explore Network? I'd like to see what travel mode settings it is using.

[Francisco_R]

I was assisting @EspenFredrikGudevang in the debugging.

We think the problem is the Build tool when is run in the Model Builder context. 
To complicate the things even more, it is somehow data related, as we couldn't trigger the problem with our own datasets, just the one Espen is using.

To reproduce the issue one has to create the Network Dataset and build it (Full Build) from within a Model Builder model. The result will compute correct routes, but will go crazy on the Directions section, by swapping time with distance and vice versa.

If the Network Dataset is built after Model Builder runs (either manually or f.e. with Python) the directions section will show correct values.

Calling the Build from a custom python script within the model does not help.

We observed this behavior in both Pro 3.2 and 3.3.

We suspect this is a bug therefore we will escalate the case to investigate further. 

For now our workarounds are manually build after model builder or replace the Model Builder model with a Python tool or notebook. 

I hope you find this information useful

[MelindaMorang]

Thank you Francisco.

I have been communicating with @EspenFredrikGudevang via private messages for more details on this issue, but I agree with your conclusion that the problem is with Build Network.  Using the network he sent me from the model output, I see the swapped time and distance when I examine a street using Explore Network or when solving a route.  This means that the bug is not in the solvers or in Explore Network, but rather the Build Network process has somehow mixed up these two attributes.  Doing a full rebuild of the network using 3.2.2 or 3.3 fixes the network.

The next step in investigating the problem is to find a workflow (via Model Builder or whatever) that reproduces the problem.  Hopefully you can share the model with us.

Go ahead and escalate your case to Esri, Inc. Support. It will come to me anyway, but through official channels.

[Francisco_R]

Thanks for your reply @MelindaMorang ,

The case was escalated to ESRI Inc. and the result is the following bug:
BUG-000167842 : Network dataset built with a model has incorrect results for direction and distances 

I paste it here in case other users experience similar issues.
Thank you.

[EspenFredrikGudevang]

Regarding the BUG-000167842, which i now understand is adressed in ArcGIS Pro 3.4:

Do you (@MelindaMorang?) have information about the trigger for this bug?
Is it anything I can do with my input data or model (in ArcGIS Pro 3.2.1) to avoid the wrong behaviour?

[MelindaMorang · Accepted solution]

Sure.  The ultimate cause of the issue was creating the network dataset from a template in which the ID values of the network attributes are out of order.  If you open the network dataset template, you'll see something like this in the XML:

If those ID numbers are out of order, you'll encounter the problem.  And, for some complicated and weird reason, the problem only occurs if you create and build the network in a model.

Our bug fix just makes the software ignore those ID numbers since they aren't important anyway.

To avoid or work around this problem in pre-3.4 software, you have two choices:

1. Don't use a model to create and build your network.  If you run the Create Network Dataset From Template and Build Network tools manually, it seems to work fine.
2. Manually edit the ID numbers for the EvaluatedNetworkAttribute items in the network dataset template.  Usually we don't recommend users to manually edit these templates since they aren't documented or intended for direct interaction, but in this case it seems like a reasonable workaround.

I think in our message exchange you had mentioned that you also resolved the problem by creating a new template from the messed-up network you created, and that subsequent networks created from the updated template worked fine.  If that's the case, then this would be a valid third option.

[MelindaMorang]

By the way, this was an extremely strange issue!  I'm sorry you encountered it, but it's certainly not something we had ever thought to test.  You found a very interesting challenge for our team.