UN Foundation upgrade to 2.1: Is it really worth the effort?

[Andy_Morgan]

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.  

[PatrickGCowan · Accepted solution]

You would only need to move to version 2+ of the models, if you want to utilize the features that were added. If you are satisfied with the design of the 1.2 model, you can proceed with using that one. The biggest thing that was added in version 2+ was the addition of the essentials model.

Release notes:
Sewer: Sewer Utility Network Foundation - Release Notes 
Water: Water Utility Network Foundation - Release Notes 

Something to note. You mention removing things from the model. It would be suggested that anytime that you remove something you utilize the D_Configuration table in the asset package to do so. Using this table to remove features has a lot of quality checks to ensure things are not removed that will break the utility network.
Create Asset Package Configuration Table 

Models version 2+, did move to the lifecycle status / construction status combination. This was done to simplify the lifecycle status and capture the state of a feature more accurately. Lifecycle status is used to control traversability in the utility network subnetwork definition. The construction status field is used to capture the different stages of a project's construction process.

A few more tips for migrating data. Check out the new migration tutorial. The tutorial utilizes some new tools in the Utility Data Management Support toolbox that make migration and data model modification simpler. The tutorial covers migrating your data as well as modifying the model. The sewer tutorial is out right now. A water tutorial will be out soon, but it utilizes the same workflows as sewer. So all the concepts would apply.

Sewer tutorial: Sewer Migration Tutorial 

Overall, I would look at the new Essentials model (it has been significantly simplified) and some of the new tooling in the UDMS toolbox to help with model modification and data migration. It is often easier to add to a model, rather than take away. Ultimately if you are satisfied with your current model and its modifications, and don't need any of the new features that were added, you can proceed as you currently are.

[Andy_Morgan]

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

[PatrickGCowan]

The attribute rules included with each model are different. The attribute rules that are included with the essentials model are actually data reviewer rules to help you with assessing your data when you migrate. The attribute rules in the expanded are calculation and constraint rules to help you auto-populate attributes like asset id, symbol rotation, etc and constrain input values.

The expanded model only contains the calculation and constraint rules, and the essentials model only contains the data reviewer rules (validation attribute rules).

The essentials model is "essential" components only. Since auto population of attributes such as asset id, symbol rotation, etc are not what would be considered essential, they are not included with that model. If you need to implement those sort of attribute rules, Pro 3.4 has introduced templated attribute rules, which will help you in setting the most common ones.

Template Attribute Rules 

We also have a GitHub page that has code for configuring specialized industry specific attribute rules.

Attribute Rules 

[Andy_Morgan]

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"

[PatrickGCowan]

Using Export AP will give you an asset package representation of your current Utility Network, and ensure that the Utility Network can be recreated as-is. It doesn't mean that the model is correct, just that it can recreate that specific UN. 

While you can remove things manually through the AP tables, there are lots of little intricacies to think about. The cleanest way to do it is definitely with the D_Configuration table.

If you want to have an asset package to work off that does not have CP related features, I would suggest that you use the D_Configuration table to remove all things CP related. Then create a UN, and then export back to an asset package. At that point you will have an asset package that has all CP feature removed.