Latest Contributions by Andy_Morgan

Nevermind, I realized the output was too large for my target field. This solved it:  Left(GdbVersion($feature), 16)   How do I delete a post in Esri Community? Under Post Options for my reply I only see Edit Reply but not a Delete option. ... View more

The GdbVersion doesn't seem to work with a text field. I'm using ArcGIS Pro 3.3.3 The "G" is uppercase compared to the video tutorial: GdbVersion($feature) In any case, I've tried all case combinations. With only 2 lines of code, I cannot get it working. var CurVersion = GdbVersion($feature) return CurVersion   Result of above on field calculate (for a simple text field of 16 characters) for a versioned layer in a Utility Network: ERROR 999999: Something unexpected caused the tool to fail. Contact Esri Technical Support (http://esriurl.com/support) to Report a Bug, and refer to the error help for potential solutions or workarounds. Message: Unable to complete operation. Details: Unable to perform applyEdits operation. Error: Invalid column value [UT_GISID]. Failed to execute (CalculateField).   Is there a bug with 3.3.3 or is the documentation wrong? https://developers.arcgis.com/arcade/function-reference/feature_functions/#gdbversion   ... View more

Thanks. Unfortunately, using grid snapping won't actually save time/clicks. Moving individual service line features (by dragging junction points), without referencing the snapping grid, was already one option we considered, but the reason it's more efficient to delete all vertices in between the end points is because ultimately the Technicians will still be re-drawing the geometry of each service line. They might get shortened, along with snapping to the realigned main geometry. So the most efficient route for our situation seems to be: 1. Realign start/end nodes for water main. 2. Mass delete all intermediate vertices. The main feature is shifted and all service lines are then disconnected.  3. For each service line, use "Replace Geometry" to redraw the service line at a more realistic length. While doing this part I realized we can use the [right click] Snap to Feature -> Edge option to snap to the water main midspan. I guess it's because we're shortening service lines while also repositioning them with the realigned main that we are in a somewhat rare situation. In any case, we do see that the Geometric Network handled this one with less clicks, since it auto carried the service lines over with the re-aligned main feature and kept them snapped. Oh well, we'll adapt.     ... View more

@gis_KIWI4, thank you so much for this simple point about needing to traverse the entire network! I only wish I had focused on it sooner. @MichaelParma, I also owe you thanks, since you sort of wrote the same thing. It was the words above, "needs to traverse the network before", that stuck with me, though. I've finally realized that on the Water System tier I hadn't established a subnetwork controller, since we didn't carry in a point for treatment plants or bulk meter. Using a FGDB copy, I've managed to get things working by... 1) Creating a Transmission Main that connects to a new point of Supply / Treatment Plant. 2) Defining the treatment plant as a subnetwork controller (port 2). 3) Tracing the entire system (Tier = Water System) using a Connected Trace. 4) Running an Isolation Trace using a random starting point, with Tier = Water System and for Filter Barriers I used Category = Isolating. It successfully stopped on the first set of valves going outward from the starting point. Woohoo!  ... View more

I've used something very close to what's shown in the article you mentioned. No matter what I try, it always fails with "No valid subnetwork controllers found."  I'm using Water Pressure tier. I don't have P:Device Status (intentionally removed, using D_Configurations), but my Condition Barriers should be fine with Lifecycle Status check of does not include "In Service and To Be Retired". Filter Barrier is Category = Isolating. Somehow the 3 water storage tower subnetwork controllers aren't recognized with Isolation traces, but they work fine when running subnetwork traces to update my 3 pressure planes. Hmm. Would Esri Tech Support be my best chance for troubleshooting at this point? I'm concerned if nobody here has a good suggestion and this hasn't ever been observed. Is my UN "corrupted" somehow? I used D_Configurations to properly remove certain fields/subtypes/properties, but nothing crazy.  Update: I noticed my subnetworks aren't showing under Find Subnetworks pane, so I'm going to first rebuild the topology and then run Update Subnetworks to make sure they're listed (and not dirty), and then I'll re-try the isolation trace. Maybe that was my problem all along? Controllers aren't detected because subnetwork wasn't fully built. This is a new round of creating UNs, so I must have forgot to complete this step. Hopefully that's it. More to come... ... View more

Hi Michael, I have three WaterDevice points that are Storage / Tower features with Is Subnetwork Controller = True. These are for the Pressure tier and the pressure subnetworks have been tracing fine. This was the first thing I confirmed. As for isolation tracing, nothing has resolved it yet.  I figured maybe I'll focus on trying to make it work with Water Pressure rather than Water Isolation tier, as you point out. I know Pressure traces with Trace Type = Subnetwork.  I guess if the trace type is isolation then the problem is about the subnetwork controller for isolation. I don't understand how to use Isolation Zone, it seems. I'll move on to gis_KIWI4's thoughts next, unless you have other ideas? Thanks.  ... View more

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