Subnetwork name does not propagate to Containers

556
4
10-11-2022 10:50 AM
JakeJacobsAVA
New Contributor III

I have a gas utility network. My network topology is all correct and I am successfully updating all of my subnetworks in all the tiers. I have noticed that the different attributes of the subnetwork names on the PipelineAssembly featureclass are a single space ' ' when the contained assets are connected to the network and have a correct subnetwork name on them (the containment association is also valid).  In my subnetwork definitions, the trace configuration is set to "include containers".

Any other configurations I should check?

Is this a known issue or should I open a support ticket about this?

0 Kudos
4 Replies
GIS_Solutions
Occasional Contributor II


Hi Jake

if you define container rule and configure container relationship (modify association) , subnetwork name field will be updated.

 

0 Kudos
JakeJacobsAVA
New Contributor III

If I understand your comment correctly, that step is already done. There is a containment association between the Meter Set Assembly and the Customer Meter Device. I can see it in the "View Associations" as well as traverse the association in the Attributes pane tree.

The assembly is at the lower left with the label and the device is at the upper right.

JakeJacobsAVA_0-1665520690216.png

 

 

Here is the attributes of the meter device 

JakeJacobsAVA_1-1665520750143.png

 

 

Here is the attributes of the meter setting assembly

JakeJacobsAVA_2-1665520787755.png

 

0 Kudos
LindseyStone
Occasional Contributor III

I'm having the exact same issue in my GAS utility network and yet to figure out why.  I also have an electric UN deployed and it works as expected.  So my initial thought it is a Bug somewhere in the Gas schema, now that I know it is more than me having an issue. 

0 Kudos
JakeJacobsAVA
New Contributor III

I consulted with an Esri analyst and they pointed me to how the behavior is supposed to work. The Assembly featureclass should have an attribute called supportedsubnetworkname and this will get a list of the subnetworks that the contained features have in them. If a contained feature has more than one subnetwork in a given tier, that gets tacked on in the container as well.

So you get a big long list of different kinds of subnetwork names in this one attribute. It's not immediately obvious which name goes to which tier, although I suppose they are probably in tier order.

The way this functionality gets enabled is on the Set Subnetwork Definition gp tool. The check box is supposed to be checked on by default, but I suspect that ours was not because we upgraded from an older utility network version and didn't realize where to enable the functionality. 

Based on this behavior, I'm not sure if we will enable this functionality or not. It seems odd to have cathodic and pressure and system and isolation names all mixed in together. 

Here are some other notes from the analyst:

  • Review your workflows and determine whether changes are needed to the default update subnetwork policy. The Update Structure Network Containers and Update Domain Network Containers options can be modified in the subnetwork definition to prevent issues where the supported subnetwork name field may be overloaded for structure and domain network containers. This can be helpful in situations where there is nested containment. 
  • Update Structure Network Containers—Specifies whether the update subnetwork process will update the supported subnetwork name attribute for structure network containers. This option is checked by default.
  • Update Domain Network Containers—Specifies whether the update subnetwork process will update the supported subnetwork name attribute for domain network containers. This option is checked by default.
  • https://pro.arcgis.com/en/pro-app/latest/help/data/utility-network/update-subnetworks.htm

 

0 Kudos