Associations or Direct Connectivity?

[SSMIC3038]

For GN > UN migrations, clients with a large volume of data naturally balk at the resources needed to take existing data and implement associations in place of direct connectivity.

Are there any opinions on the impacts (if any) of not using associations as part of UN and using the 'low fidelity' approach. I appreciate with electrical datasets there is a greater degree of modeling that associations enable. But for storm water, sanitary sewer and water distribution are there any significant limitations that a client can expect across the life of  UN if they don't use associations?

[JohnAlsup]

If you are attempting to model an unbalanced three phase system and use propagation to manage phase, you will have to use associations to some degree.  However, we recently released our updated Electric Foundation model which includes representing the units as non-spatial, reducing the complexity of migration.  I encourage you to look at how this is modeled in the Electric Foundation found on the Esri Solutions site.

[SSMIC3038]

Thanks for the comments, but I'm interested in datasets outside of electrical, I'm referring primarily to the storm water, sanitary water and water distribution genres. For a client with extensive datasets in these genres, what are the anticipated or perceived impacts (if any) in a UN migration to retaining low fidelity direct connectivity and foregoing associations. 

[MichaelParma]

We have deployed a number of water, wastewater, and stormwater UNs both with and without associations. Certainly, you can model the UN connectivity similar to the present GN coincidence. I think that works reasonably well for the water and even the wastewater system. You naturally lose some modeling fidelity and accuracy of pipe length when taking this approach.

However, I really like the flexibility associations offer on the stormwater side, particularly around retention ponds, outfalls to streams, and indefinite "sheet" runoff. We've been replacing the GN's "vritual drainlines" with associations and it works nicely. In the end, it's about modeling what's going to work well for you.

I might add that I do think associations are going to play a significant role in eventually extending the network into the vertical assets. So if you choose not to use associations now, at least keep them in the back of your mind.

[SSMIC3038]

Helpful comment, thank you.

You migrated existing geometric network (connected/snapped) data into utility network and utilized associations. Generally speaking this must have added additional costs and effort to the migration, not to mention I have to assume at least some of the clients were not up to speed on these GIS data concepts.

So how did you approach educating the client in why the data needed to be transformed from snapped connectivity to associations and how was the cost approached.

Any insight greatly appreciated, most of the potential clients we interact with are not aware of associations or the need to transform their data builds to accommodate associations.

[MichaelParma · Accepted solution]

Everyone is new to the UN so it's a healthy dose of user education along the way. Plan to explain the use cases and potential benefits during the initial design stages. Then the decision is primarily a business decision rather than technical (i.e. associations are not -required- for the UN to work). 

Cost can be mitigated through scripts or tools during the ETL process. In many cases, associations can be configured but not immediately implemented (such as meter pits), leaving it to organizations to do as part of data cleanup later. One situation I would recommend not waiting would be on the sewer mains-to-manholes given the sheer number of them. 

[SSMIC3038]

Good example, because the flip flopping on the sewer mains to manholes needing association or not is what is driving the initial post, and like you mentioned the volume of effort (even with automation) and explanation to client on rationale behind it all. Hydrant assemblies being another good one.

Thanks for the feedback, much appreciated.