Latest Contributions by RobertKrisher

@BrandoCrozier note, if your original asset package used a D_Rename table to rename asset groups/types then the final asset types in your deployed utility network will be different and you will need to un-rename your asset types in the new rule table.

@MarkWasdahl1 after you've created the feature, you can go back into the attributes and update the elevation values of pipes that you know the elevation for. If that's the workflow you want then you can either disable the attribute to fire on update (i.e. on have it fire on create) or modify the rule so that if the elevation values of a feature are already populated that they won't be overwritten. This would allow you to manually specify an elevation when you know one without it being overwritten, and to null out the elevation and edit the feature to trigger the system to recalculate it.

We have made several optimizations to how we handle disable network topology in the latest release to address this performance problem, and are planning on patching this according to the network management release plan. If you want to log a bug with support on the issue, they can take a look at whether something else is happening.

@Yeaton have you confirmed that your lines are connected to the right terminal on the subnetwork controller? If the subnetwork doesn't have any lines, then this is likely the case. If your subnetwork consists of a single line, then it is likely that your first line is acting as a barrier. Check the fields used as condition barriers, like lifecyclestatus, and ensure its marked as in service.

The attribute rule should only fire on create, giving you initial elevation values to drive your slope/analysis. If you are blessed with having more detailed information about each invert that you can use to fine-tune the elevation data on your pipes after that then you should absolutely capture it. @MikeMillerGIS thoughts?

That query is happening because when you disable the network topology, we mark all the subnetworks (and subnetwork lines) as dirty. If your subnetworks are already dirty and you are seeing that query, this is a known issue that is being patched through the network management release plan. BUG-000180226.

@EdwardBlair Customers often adapt the model to suit their requirements. In the case of rectifiers/anodes, because the Domain Network is defined as being source-based and because anodes aren't always physically connected to pipes you'll likely want to use rectifiers as sources (see article 2 for examples). I have seen some customers use the existing tier to manage this, foregoing the importance of test points. I have also seen one customer add a new tier so they could trace and manage the electrical conductivity of the cathodic protection system separate from the regulatory requirement. It comes down to what are the requirements that you are trying to solve with your GIS and what configuration best meets that need. This is why I linked to the first article, because it lays out the requirements and business case for the original design and configuration of cathodic protection in the UPDM model.

@Andy_Morgan You can mitigate the risks of pressure zone boundaries breaking if you have editors work in a version, instead of defaulting directly, and ensure they validate all their dirty areas, fix all their edits, and trace or update their subnetworks before posting their versions. This will flag any inconsistent subnetworks before they are posted to default and become everyone's problem.

As always, I defer to @TomDeWitte on all Gas and Pipeline matters, but this is my understanding based on my time spent implementing cathodic protection in GIS for gas utilities. From an electrical perspective, you are correct that it would make sense to model the rectifier (source) or anodes (sink) as subnetwork controllers. However, from a regulatory perspective each zone is considered a cathodic structure and is typically associated with a set of specific test points. Because of this many of these gas companies already have a database that lists out the structures and test points for each cathodic structure, which makes it easier to create and validate this information in the utility network, as well as integrate it for compliance purposes. For more information on the compliance side of things, read Tom's One Source of Truth for Cathodic Protection. For more general information on how CP works, read Tm's Understanding Cathodic Protection for GIS & IT Professionals. @EdwardBlair you probably already know all the info in those two articles, but others reading this comment or post in the future may benefit from the information.

If you ever want to turn that attribute rule back on, while still supporting the workflow of manually entering attributes. You would want to add logic to skip over updating the fields if they're already populated.

The sewer model features a directional manhole channel with four terminals whose purpose is to manage this. In practice, it can take a bit of work to get all the terminal connections correctly populated so customers who want to use subnetworks tend to rely on digitized direction tracing until they get the terminals sorted.

@VishApte_NGIS if you do keep the utility networks in the same database, but put them in separate schemas you avoid the StructureJunction_1 type issue.

The subnetworks table is the more reliable way of determining status, especially in networks with multiple subnetwork controllers.

If the domain isn't associated with one of the system fields of the utility network (including asset group or asset type), you should be able to rename it using the Domains Design view pane.

The Geometry method takes a $feature and returns its geometry. I recommend you test out this method by putting it in a popup expression on the line layer (have one for the upstream elevation and another for the downstream elevation), then click a few features and see what its outputting. I'd defer to the data dictionary and @MikeMillerGIS about the elevation field.

Online Status	Offline
Date Last Visited	Monday

My Ideas

Latest Contributions by RobertKrisher

Re: Adding Rules to my Asset Package in Pro 3.5+ for UN Migration

Re: Stormwater Utility Network Elevations not saving

Re: Disable Network Topology takes too long, up to 10 hours

Re: Subnet Lines

Re: Stormwater Utility Network Elevations not saving

Re: Disable Network Topology takes too long, up to 10 hours

Re: Gas CP Subnetwork Controllers

Re: Utility Network Bulk Tracing (Looping Records) with Python

Re: Gas CP Subnetwork Controllers

Re: Stormwater Utility Network Elevations not saving

Re: Subnetworks vs. Digitized Direction

Re: Regardingh Combined domain network of Water and electric utility in a single Enterprise SQL database

Re: Inconsistency between Subnetline et Subnetwork status

Re: Modifying Asset Package directly vs using D_Rename Table

Re: Stormwater Utility Network Elevations not saving

Re: Adding Rules to my Asset Package in Pro 3.5+ f...

Re: Can you show Flow Direction in Utility Network...

Re: Can you show Flow Direction in Utility Network...

Re: UN version 7, ArcGIS Pro 3.5.4 validation erro...

Re: Regardingh Combined domain network of Water an...