Latest Contributions by RobertKrisher

If the device that is acting as a barrier is a subnetwork controller (is subnetwork controller = true), then the trace has gone too far, and you will get an inconsistent subnetwork name error. If you want the trace to stop at features that can be subnetwork controllers, but aren't enabled as subnetwork controllers you would set the condition barrier to be on the Subnetwork Controller category. ... View more

You should filter using network categories instead of asset types. It's easier to configure, provides more flexibility, and performs better. The issue is likely caused by the data model you are using, also remember that asset types are not only not guaranteed to be unique in the entire utility network, but they're not even unique within a feature class (so specifying a particular code could provide an inaccurate result if that code is used on a different type of features). For all these reasons, and the ones listed in the first paragraph, create and assign a network category for this. ... View more

Because you are opening the valve, that will only work if the area being analyzed is all within the same subnetwork (pressure zone or subnetwork). Another approach you could take, that allows you to operate across multiple subnetworks AND doesn't require you to edit the data, is to place additional starting locations on the other side of the valve you want to simulate as open. ... View more

@JohnGoat Filter barriers don't affect traversability, only the results that are returned. This means that the first controller is able to trace to the second controller, which is giving you that error. If you change th filter barrier to a condition barrier, it should work. ... View more

This is a known limitation of the way that subnetworks are modeled. To work around the issue you can model an open point (or other barrier) to separate the two subnetworks, which you have already discovered. Please log an issue and get yourself associated with BUG-000173401. ... View more

@Jens_Dalsgaard  Please log an issue 😉 ... View more

This is working as designed. If you cannot have two subnetworks with different names connected to each other. If in the field this area is always fed by the two sources, then they should have the same subnetwork name. If they are only fed by one or the other, then model the device as open to separate the networks. Trying to artificially separate the networks with a closed device won't really work, as you'll see below. A feature is only a subnetwork controller if it belongs to an asset type that has all the correct configuration (subnetwork category, directional terminal config, associated with a subnetwork definition in the controller role) AND you have used the modify subnetwork controller tool to enable it as a subnetwork controller. If you want that trace to stop at the "possible controller" when it's CLOSED and NOT a subnetwork controller you could add a condition barrier to stop at features that have the Subnetwork Controller network category (which may have unintended consequences) or you could use a network category specific to this situation. The problem with doing that is that if this 'possible controller' will ALWAYS stop tracing, regardless of state or configuration. Which means that if you ever wanted to feed the area from the yellow source instead of the blue source you'd need to remove the device. ... View more

Using or consuming services (step 4) does not require you to be the data owner. Can you clarify what specific tasks or workflows in step 4 require you to be data owner? However, I do know that publishing services (step 3) requires you to be the data owner. Is that what you intended with this request? ... View more

You can only have a single association role for an asset type. Instead of adding a second row, you should have updated the existing row in the asset package with the values you wanted. ... View more

If the asset package contains utility network features and attachments, and you just want to migrate the attachments, you will need to append the attachments directly. Be very careful to ensure that you don't double-load your network features. It is possible to load the same features with the same global ids multiple times, and it is painful to recover from this mistake. This can happen when you choose to preserve global ids during data loading. ... View more

We cannot allow you to snap devices/devices, devices/junctions, or junctions/junctions because these would create topology errors (stacked points). However, I could see allowing the snapping behavior when using a preset template or group template, because you would presumably be offsetting the features at the snapped location. ... View more

Subnetwork traces do not take the digitized direction of lines into account when traversing the network. This is why the digitized direction traces are producing a different result, and why many customers who manage sewer or storm networks often rely on those traces instead of subnetworks to perform analysis. Shortest path traces ignore both terminal directionality and digitized direction. If you feel that subnetworks should also support the option to use the digitized direction of lines, I encourage you (and other customers reading this) to log an issue with support and create an enhancement request for that functionality. It is something that was considered when we implemented digitized direction tracing, but we felt that customers who used those traces wouldn't want to also configure subnetworks to use the same logic. ... View more

@GaneshPremakumar the subnetwork controllers stay as is, but the manhole where these two subnetworks comes together will have this terminal configuration. The path for each subnetwork will be assigned to a different downstream terminal and you will use the "up to down" terminal path. This lets the system know that subnetworks 1 and 2 represent mutually exclusive downstream paths in the network (which fixes the inconsistent subnetwork name error) while still allowing the area upstream of the manhole to belong to both subnetworks. If the area upstream of the manhole should only belong to one of the subnetworks, with the second subnetwork only be accessible during high volume events, you would take a different approach that defines one the paths as only valid during high volumes. ... View more