|
POST
|
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
06-30-2025
12:48 PM
|
0
|
6
|
750
|
|
POST
|
Before I deploy our Water UN to production, I'd really like to understand what's needed to get isolation traces working. No matter what Tier I try (Water System, Pressure or Isolation), it always fails with "ERROR 001797: No valid subnetwork controllers found." Same thing happens even with the ESRI Foundation GDB (v 4.1) that I used as a starting point to build our UN. It should be simple: System Valve / System is assigned "Isolating" Category, so all of those systems valves should act as barriers for such a trace if Filter Barrier is Category = Isolating, right? I see the Subnetwork Controller for the Water Isolation Tier is System Valve / Isolation Zone (which I do have some in our system), but how does this relate to running isolation traces anywhere throughout the network? @RobertKrisher wrote this: "You can always run an isolation trace by using a filter function barrier to define criteria for isolation." (https://community.esri.com/t5/arcgis-utility-network-questions/a-few-subnetwork-questions/m-p/1474082#M3893) What does that mean? I tried adding this: Filter Barrier: Category = Isolating Filter Function Barrier: Count, Asset Group = 2 ...but it still throws the same error message.
... View more
06-30-2025
08:24 AM
|
0
|
10
|
886
|
|
POST
|
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
04-16-2025
02:27 PM
|
0
|
0
|
798
|
|
POST
|
I'm sure this is mentioned somewhere in all the UN documentation and best practices, but when it comes to water lines crossing over each other perpendicularly is the easy solution for having an accurate network to elevate either the whole line or part of the line to make sure it's not the same Z-Value as the one it's crossing? See screenshot below. If we add a new vertex with higher Z-value to each side of the crossing (shown in red), I assume this will cover our need to have different Z-values. Here's a vertical profile to illustrate how it would look. We're not worried about vertically depicting the line perfectly. We don't track Z-Values in our Geometric Network data that will be migrated. Our only concern is making sure there isn't an intersection in the GIS when in real life it crosses over and doesn't actually intersect (i.e. a cross fitting).
... View more
04-16-2025
09:49 AM
|
1
|
4
|
869
|
|
POST
|
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
04-14-2025
12:02 PM
|
0
|
1
|
650
|
|
POST
|
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
04-14-2025
06:27 AM
|
0
|
3
|
668
|
|
POST
|
I have not yet deployed a UN to production environment. Currently working in test environment and trying to establish the subnetworks for our Water UN (Hierarchical tier). In many ways, the schema is very close to the ESRI Water UN Foundation database, which is what I'd like to point to for this question. For creating subnetworks, I realize you must assign one or more subnetwork controllers as the point of entry, but what I'm not understanding with the ESRI UN foundation shown below is how System Valve / Pressure Zone features are the barrier points for defining a pressure plane subnetwork. In the network properties (2nd screenshot), it's Pressure Valve / Pressure Reducing features that are controllers. So where is it defined in the network to indicate that System Valve / Pressure Zone can also be a start/end subnetwork barrier? I don't think "Isolating" category is relevant for a pressure subnetwork. I don't see anything else, and cannot find any documentation, to know exactly how this works.
... View more
04-11-2025
02:37 PM
|
0
|
5
|
771
|
|
POST
|
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
01-29-2025
11:54 AM
|
0
|
1
|
713
|
|
POST
|
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
01-29-2025
07:02 AM
|
0
|
1
|
740
|
|
POST
|
All this time, while preparing my water and sewer UNs, including data loading workspaces and customizing asset packages, I've been using the Foundation version 1.2 for each. Should I be concerned with upgrading to version 2.1 for water and sewer, now that I'm getting closer to having the schema finalized? It seems like a lot of work that'll slow me down. I have already carefully removed all references to cathodic protection, since we don't have any data in our system that applies and I wanted to avoid extra CP related fields if they're not being used. I may experiment with the v 2.1 Essential Water Foundation asset package on the side, since we have more custom attributes than using ESRI's out-of-the-box fields (like operable, lastmaint, bondedinsulated, installdate, etc.). One of the main differences appears to be the LifeCycle_Status and Construction_Status split out as separate fields and domains, but that doesn't really matter much in our case. Any advice from the experts? This seems important to not start off on the wrong foot. Does it sound like I'm safe enough with my version of Fdn 1.2, or do you strongly recommend Essential 2.1? We mainly just need pressure and isolation subnetworks for tracing. Not all the bells and whistles, per se.
... View more
01-28-2025
07:12 AM
|
0
|
5
|
801
|
|
POST
|
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
12-26-2024
07:03 AM
|
0
|
1
|
777
|
|
POST
|
As we get closer to deploying both a water and sewer UN, I'm suddenly very concerned that I am misunderstanding the way ESRI designed the Sewer UN Foundation. There is an attribute rule for Sewer Storm Vault (Structure Junction) to automatically generate a Manhole Channel (Sewer Device) point with identical geometry. That's fine, we must edit the Sewer Storm Vault and not deal with the Manhole Channels. However, it doesn't make any sense that ESRI is missing all the connectivity rules that are needed to snap these Sewer Storm Vault points to the main and service lines. Why are there only rules for SewerDevice -> Manhole Channel? Those are the secondary features that you don't edit. Did ESRI forget about the other side where the edits are made? I can manual add the rules in the asset package, but I want to make sure I didn't miss something fundamental here.
... View more
12-23-2024
06:05 AM
|
0
|
3
|
836
|
|
POST
|
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
10-04-2024
06:28 AM
|
0
|
0
|
1479
|
|
POST
|
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
09-17-2024
05:46 AM
|
0
|
1
|
1250
|
|
POST
|
I must admit I'm confused on how to design trace configurations if you only want them to apply to water lines/devices/junctions that have LifecycleStatus = "In Service". I see you can filter Condition barriers, but what about simply filtering the whole set of what's used for the trace by an attribute? Is there any way to exclude all the Abandoned/Removed/Out of Service and other Lifecycle status features, or are they somehow already excluded and I don't need to do anything? We were hoping to add a new Lifecycle status domain value for "Deleted". This would store special cases where we want to know historically that it was deleted. In any case we don't want trace to run on anything other than "In Service" features.
... View more
09-16-2024
02:58 PM
|
0
|
5
|
1323
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 2 weeks ago | |
| 3 | 2 weeks ago | |
| 1 | 07-01-2025 10:14 AM | |
| 1 | 04-16-2025 09:49 AM | |
| 1 | 11-17-2020 03:34 PM |
| Online Status |
Offline
|
| Date Last Visited |
2 weeks ago
|