Remove abandoned features from active UN

[GavinMcGhie]

When an asset's lifecyclestatus value is set to abandoned, removed, etc., that asset should no longer be included (or at least ignored) in the network tracing, error inspection, etc. Loading our abandoned asset history into the UN resulted in 1000s of new topology errors. It's not cost effective to spend staff time cleaning abandoned data to honor the rules, nor does it make sense to change network rules for abandoned data. However, this data has great importance for asset management. Example- Long ago, before we digitized laterals, our Hydrants were on the Main. Even back then, we maintained abandoned features. So now we have Hydrants connecting 2 Mains in our abandoned data. Clearly we don’t allow this anymore and do not want to add a rule to allow this. We also don't want to start adding laterals and valves to abandoned data just to comply with the rule. Storing our pre-UN abandoned assets in a separate GDB then means we need to make sure any functions using abandoned assets parse both this separate GDB and the abandoned data in the UN. Plus this defeats the purpose of using the lifecyclestatus field. I suggest that the non-active network features, based on lifecyclestatus, be ignored in all network functionality.

[JimmyBowden]

I agree that there's a need to exclude features from validation based on lifecyclestatus.  We have similar issues with Approved features. 

The work around that I came up with was to apply a uniform Z value (-10 for instance) to the abandoned/removed features.  This isn't a perfect solution we still had errors to review, but it was preferred to having 1,000s more errors to review. Also note that this may not be a great solution if you desire view your data in 3D.

[MichaelParma]

A similar issue arises with proposed features (in reverse). For instance, when I am planning to replace a line with a larger diameter at the same junction... I want the active feature to participate in the trace and have the proposed line "preconnected" in the proper place, rather than having to mess with Z-values. It's almost as if we could apply validation rules to only consider active features, or features of the same lifecycle status.

For consistency, I've recommended my clients not to migrate existing abandoned features into the UN, but rather migrate them into a new separate "archive" feature class with the same schema. This allows a simpler copy/paste/delete type of workflow when creating new abandoned features.

-Mike Parma
Axim Geospatial

[BillBott]

Probably a dumb idea, but could you move your abandoned features into a representative structure class? Then you could still track them as associated structures (if you wanted to) in traces, but none of the side-effects of disrupting traces, etc.

[GavinMcGhie]

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...

[MichaelParma]

Agreed. I'd like to see the ability to somehow test the connectivity of the proposed assets though while at the same time not conflicting with the active assets.

As a point of clarification, I've always thought of using abandoned to mark the features and then manually or programmatically remove them into the separate archive. So still a useful field.

[JakeJacobsAVA]

Agree that the association rules should definitely be lifecyclestatus dependent. It is very frustrating.

When migrating our abandoned pipe data we ended up generating tens of thousands of generic connection points where we had historical data about abandoned pipes but not the old abandoned fittings, to meet the strict edge-junction-edge rules.

We used a similar strategy of using a -.5ft offset in the z plane for our abandoned features for now. In the real world there are mere inches between the abandoned and live features, so I am not sure what we'll do when we move to high precision GPS field as-builting. Especially since the z-plane is not as accurate.

I use the Update IsConnected geoprocessing tool a lot and then create a layer that filters the IsConnected = False and lifecyclestatus = In Service  to identify the disconnected features I care about.

For proposed features and tracing - has anyone thought about creating some sort of "design take-off" connector feature and creating connectivity rules that allow it to connect to pretty much anything? So you would start your design incorrectly slightly disconnected from the existing facility but put a take-off point there that has connectivity back to the existing facility to allow tracing validation but not have geometrically coincident features. And then when you as-built, you'd remove the take-off point and connect with the correct fitting to the existing facility. 

[CarlVon_Stetten1]

We've done the whole "move the abandoned features to secondary feature classes" thing for a long time (we did it in the old Geometric Network too), and frankly, it's a pain in the neck.  Being able to have the UN topology "ignore" features based on configurable lifecycle status values would make things so much easier for us.

[GavinMcGhie]

I'm linking another replated thread here:

https://community.esri.com/t5/arcgis-utility-network-questions/how-to-exclude-the-abandoned-or-retir...