Latest Contributions by GavinMcGhie

Hi all- This thread sounds related to a thread I started, so i wanted to link the 2. It seems to me that Esri missed the ball on this one. Why would we want to have a lifecycle status of abandoned if those features are still going to be included in topology? I can't figure how that makes any sense to use. It sure seems like abandoned, retired, design should either be excluded, or made optional. for topology.  Esri- please note that all we have are work-arounds to this major issue, like offsetting with Z-values, which has its own problems (i.e. 3D), or creating a dataset outside of the UN to store this info. That seems to defeat the purpose of the UN functionality. I sure hope this is on the development radar. I stopped working on a plan B in hopes that Esri will address it with a proper UN based solution. Thanks   Remove abandoned features from active UN - Esri Community ... View more

Just FYI- this is the response from our Corrosion dept. (I summarized). He was guessing that the examples were more in line with oil/gas who rely on rectifiers more than we do. "At our water district where cathodic protection was added in later, and where we don’t always have the ability to install a rectifier, we use our galvanic test stations. In our galvanic test stations we make the connection with the galvanic anode at the test station so we can test the anode directly, and monitor its output. In our galvanic test stations we have a wire off the pipe, and a wire off the anode."   In summary, I will add a new rule. ... View more

Thanks to both of you for the feedback. I see the logic in testing the pipe and not the anode, so am going back to our Corrosion team to see why we have a wire from Test Station to the Anode. I think that also explains why in the Naperville sample, associations are used to connect the anodes. I realize everyone does things differently, but it would be nice if there were more detail around how best to configure these subsystems for the UN. With this major data migration, now would be the time to adjust the business processes to align with standardization within the UN domain. Anyway, thanks again for the answer and I will update if I get any useful feedback.     Thanks, Gavin ... View more

Thanks again Robert The only case I could think of for not automatically stopping a PZ trace at a PR valve would be when a utility has pressure zones that span across PR valves. This seems illogical, but I'm sure it happens. I guess I was just arguing logically for the PR valves to automaticaly work as a barrier since this is what I had expected, but I do now understand what is required to make it work within the current constraints and have successfully delineated the test pressure zone with this new info! Thanks, Gavin ... View more

Hi Robert- Thanks for the feedback, and agreed that if I were working from lower to upper systems, this might not have come up since I would have set that PR as a controller before getting to the upper system. However, in our system, the high systems tend to be the smaller and easier systems to work with, so i started there. It sounds like the Pressure Reducing Valve needs to be set as a controller for the lower network in order for it to stop the trace on the higher zone? I have already reviewed both of those links thanks. This seems wrong to me for a pressure zone trace? In what case would a PZ trace NOT stop at a PR valve (from either subnet), when in fact the whole point of that valve is to change the pressure? I see that in other trace types this might not be the case, but for a PZ trace, a PR valve seems to be an obvious asset to stop at (and what we have used with the GN for decades). I'm guessing that the reason the PZ trace stops at the check valves and not the PR is related to flow since both are directional? As I think you indicated, flow for a check valve moves toward this upper subnet, while flow for an RG moves out of the subnet. That said, I can make it work, but it sure seems like a limitation to the PZ trace process. If the PR was honored, all I'd need to do is set the controller(s), run the trace, and be able to tell immediately if a PR valve was missing or configured wrong for that subnet. I guess I don't understand the "why" of it since it seems like a limitation. Anyway, thanks again for the feedback! cheers, Gavin ... View more

Thanks for confirming the UN is moving away from that field/domain rather than towards it! ... View more

Perhaps a bit late to answer, but... If I recall correctly, I got this error when I added a new custom Asset Type value and integer simply because the integer I chose was already in use in the domains. I picked a new integer for the custom AT that was far outside the range in use, reloaded the AP, and then I was able to apply AP. ... View more

Correct. And there is no domain associated in the AP, or the UN created from the AP, for that subtype/field, so the system only knows that it's an integer with no meaning beyond symbology. cheers, Gavin ... View more

Hi Mike Thanks for the hint, and I would agree that appears to be the domain that is in use for symbology. However, in the Data Dictionary, under Devices>Fire Hydrants>Fields> presentstatus, there is no associated domain and there is no associated domain for that subtype/field in the asset package, so it's not documented. I always worry about making assumptions on these like this for fear that Esri changes direction and I have to unwind things, which is why I was hoping Esri might weigh in. Thanks, Gavin ArcGIS Solutions Utilities Data Dictionary ... View more

Just to further the topic, using Z values may not only disrupt future 3D plans, but those features would still show (I believe) up in a find-disconnected trace when checking the integrity of the entire network. Plus once that -10 Z plane gets cluttered with assets, there may be rules broken anyway. Great points on the approved and proposed data! Our planning is still done in CAD, so that hasn't come up for us. Finally, I think moving the abandoned assets into the structure classes is not much different from adding new FCs into the UN GDB to store abandoned. That invalidates the whole lifecyclestatus attribute IMO. Then we have to tell users not to use lifecyclestatus to abandon, but instead use our custom process. Plus, I assume Esri built functionality into that field, and to avoid using that for abandoned, inevitably we lose out on any future benefits. Sadly, if I was forced to move the UN to production today, I'd just store abandoned where they are today and leave the assets out of the UN. It seems reasonable to ignore any non-active status objects out of the network. That said, I think there still needs to be a way to test the connectivity of proposed assets with the greater network before making them active... ... View more

This sounds reasonable, but seeing that we've already separated these virtual pipes, I can calculate that we have over 13 miles of virtual pipe in our system that is associated with tanks. That's from about 200 miles total. That ends up being pretty significant if ignored, or factored into the overall real piping that needs to be managed. I'm still deciding on whether to keep our virtual edges in the UN or use associations, but at least for us, it's not trivial to ignore, which is why we undertook creating them in the first place. I was just curious what others are doing. Anyway, thanks for the feedback! cheers, Gavin ... View more