Latest Contributions by Andy_Morgan

I did add a System Valve / Isolation Zone feature and set it to be a subnetwork controller. It does show as Is Subnetwork Controller = True for Water Isolation tier. Nothing changes, though. My questions keep multiplying, it seems. Here are all the interrelated things that I'm wondering about: We don't have any System Valve / Isolation Zone features that carry over from our Geometric Network. I created one for testing, as mentioned above, but how does this relate to running a single trace for any random main within our system? Surely you don't have to define a subnetwork controller for every possible place you'd trace. That would be hundreds of thousands of controllers, in our case. It wouldn't make sense that's how it works. Most of our valves along mains are System Valve / System type. My simple desire in performing an isolation trace is to place a starting point on any random main and then have it trace out one level to stop at all the system valves (+ maybe one or two other types of valves to consider). We don't keep track of open/closed status. We just want to simply stop the trace where System Valve is found. Can I not somehow define a trace to use System valve as a barrier and ignore the need for using Isolating Subnetwork Controllers?   As mentioned, @RobertKrisher wrote, "You can always run an isolation trace by using a filter function barrier to define criteria for isolation." I thought he was implying there is a way around using Water Isolation tier and isolation zone features for this type of trace. There must be something fundamental I'm not understanding, but there's nothing complicated about my goal. It's sort of a stripped down version of the default (UN foundation) barrier conditions. I just want to say stop at this type of valve. I can include a condition of LifeCycle Status = In Service, but that's probably the only other attribute that matters.  ... View more

Oh my gosh, thanks @gis_KIWI4. I'm sure they mentioned this simple fact in the training course. Connectivity relies on relationships with edges and junctions. In this case of a crossing it cannot detect. Thanks for saving me time!    ... View more

Hi @PierreloupDucroix, thanks for the tip. While that certainly does help for accomplishing the goal of changing the barrier criteria, I guess my final question for anyone reading this is about defining the subnetwork boundaries. Putting aside the where clause syntax and thinking from an overall best practice for UN design, is there any important reason we cannot change our condition barriers to be dependent on asset group / type combinations (more static in nature) instead of open/closed status of the valves (more dynamic)? I assume it's just a question of how realistic you want to be, right? If our engineers define the pressure planes by valve function rather than what's closed/open at any given second, then it seems like I need to define it by Water Device belonging to certain Asset Group / Asset Type values.  This is a totally subjective call by the organization, right? We may be limiting ourselves somewhat, but that's how our engineers have delineated it for us until now. Some of our Geometric Network "Division / Pressure Plane" valves are showing as CurrentPosition = "Open". Whether the valve is open or closed in real-life right now doesn't matter. Neither does the attribute value. I just know we've been told where one pressure plane stops and another begins, and it's dependent on the location of "Division / Pressure Plane" valves, nothing to do with open/closed status of valves. I need to be consistent when moving to the UN. ... View more

Right, I understood how to set subnetwork controllers and the general concept of barriers, but my problem was that I didn't know specifically where/how exactly it was defined and how it could be updated. I was expecting the barriers to be defined in the network properties with explicit references to System Valve / Pressure Zone (and maybe a few other asset group/type combos), whereas after reading more documentation and digging around I now realize the P: Device Status attribute ("presentstatus" field) being set to "Closed" is how the pressure subnetwork's configuration is defined. Maybe these things are obvious if you already know every in and out of a UN, but it took some piecing together for me. It's so easy to forget such details if you took a training course 6 months ago and are just now focused on this part of UN design. I removed the normal and present status fields, so I guess those should be added back into my UN. At least present status. Is there an alternative way to define the barriers that might make things simpler if we don't want to track current valve status of open/closed?  Instead of "P:Device Status = Closed..." what about this type of where clause below? (Asset Group = System Valve and Asset Type = Pressure Zone) or (Asset Group = Pressure Valve and Asset Type = Pressure Reducing) Is that a terrible idea? Here's my rationale. We know the System Valve / Pressure Zone valves are pretty much always closed. Sure, they might be opened temporarily for a rare emergency, but I'm thinking our subnetworks are better off being defined with the normal case (99.9% of the time) as a static type definition. We aren't using the UN for water modeling level accuracy. As long as we can build the subnetworks to delineate pressure planes and run isolation traces, that's the main goal.    ... View more

One last question under this thread, if I may, as it relates to my removal of the below items without (regrettably) using a D_Configuration table. I was pretty careful to cross check everything and make sure no errors arose during Apply Asset Package and then with edit tests in the UN. However, just to put my mind at ease, isn't it correct to say that if I were to take a populated FGDB UN and use "Export Asset Package" tool (with "Include data" unchecked) that the resulting empty asset package would be a 100% safe asset package which I may consider to be a clean slate? I'm not aware of any issues at present, but I think this full reset cycle should further guarantee I'm in the clear, right?          Sewer UN items that were manually removed B_AttributeRules (SewerDevice, SewerJunction, SewerLine) - cptraceability field B_NetworkAttribute - Cathodic Protection Traceability B_NetworkAttributeAssignment (SewerDevice, SewerJunction, SewerLine) - Cathodic Protection Traceability B_NetworkCategory - CP Only B_NetworkCategoryAssignment (SewerDevice, SewerLine for various fields) - CP Only B_Subnetwork_ConditionBarriers - Tier Name = Sewer Cathodic Protection B_Subnetwork_Junctions - Tier Name = Sewer Cathodic Protection B_Subnetwork_Lines - Tier Name = Sewer Cathodic Protection B_Tier - Sewer Cathodic Protection B_TierGroup - Sewer Cathodic Protection Coverage Attribute Rules - SewerLine - "Validate Domains-SwL"   ... View more

Hi Patrick, Thanks for the feedback. Yes, I was aware of the D_Configuration table but simply forgot when removing CP references. I'll try to go back and maybe it can still be applied? My fault there. So much to remember and track, it's overwhelming. Your general message of use what works best is not surprising. That's how I understood from the beginning, but wanted to make sure nothing really important might be missed with v1.2. I don't think the construction status matters, so I'm leaning towards staying with 1.2. If I do find upgrading to 2.1 is worth the effort, here's where I'm now stuck as it relates to attribute rules.  All of the Essential version's attribute rules have Script Expression = “return true;”, not a true script doing anything. This must surely be a mistake, right? I say this because the “Expanded” version of Water UN Foundation v2.1 has full Python scripts like you'd expect. Also, the Essential version has 66 attribute rules, while Expanded offers 23 rules. It seems like you’d have the exact opposite, proportionally speaking. So I’m not sure what’s correct and offered as intended with the 2.1 Water UN Foundation. Essential version   Expanded version   ... View more

Mike, first of all thanks for offering these two design types. This was new to me. I'm pretty certain our organization will use the simpler "Essential Design". However, this still doesn't answer my question about how to draw a new Manhole Channel. Using the Sewer UN Foundation, a Manhole Channel cannot (or isn't meant to) be drawn directly. The workflow, via attribute rules, that ESRI offers is to have the channel point auto-generated when adding a Sewer Storm Vault point. If I cannot insert a point to snap on the sewer main because it's in the structure network, there is no way this can work. How did ESRI design something that won't function properly in the network? Surely, I am missing something in my understanding or ESRI made a mistake...? Thanks so much. There are few people out there who can answer these questions. We depend on experts for understanding the fundamentals of design.     ... View more

To follow with Allyson and Gavin above, I too need an immediate answer on whether it's safe to add a couple of new values to the Lifecycle_Status domain. Will anything break if I created a code 257 (description = "Pipe Bursted") and code 258 (description = "Deleted")? We have been assuming we can borrow the Lifecycle Status field for these other, less used but important, options that will take it out of the "In Service" state for tracing and symbology purposes. (I realize we also need to adjust z-values for being omitted in the network validation.)   Our use of the Lifecycle Status field for tracking abandoned / removed / bursted will replace the need for maintaining a bunch of separate feature classes like we do now in the Geometric Network: WaterLineAbandonedRemoved, WaterValveAbandonedRemoved, etc.     ... View more

Ah, it's that simple. OK, thanks, I was focused on input rather than "output" conditions. Does this mean we're filtering only the lines being traced? What about the water valves, in this case? What if we have a few LifecycleStatus = Removed valves, will those be ignored, too?  ... View more