Utility Network--how to determine what codes to use for new coded values in a domain?

[CherylTrine]

Looking at the Lifecyle_Status domain in the StormWater Utility Network model, I see the codes skip numbers:

Lifecycle_Status -- Valid lifecycle states for the assets.

Code    Value
0    Unknown
1    Proposed
2    Proposed - Approved
4    Under Construction
8    In Service
16    In Service - To Be Retired
32    Abandoned

There is an expanded list in Lifecycle_Combined, but still a lot of numbers are missing:

Lifecycle_Combined -- Bitwise combination of lifecycle states for subnetwork management

Code     Value
0     Unknown
1     Proposed
2     Proposed - Approved
3     Proposed and Approved
4     Under Construction
6     Approved and Under Construction
7     Proposed, Approved and Under Construction
8     In Service
12     In Service and Under Construction
14     In Service, Under Construction, and Approved
15     In Service, Under Construction, Approved and Proposed
16     In Service - To Be Retired
32     Abandoned

However, I presume that the intervening numbers are used somewhere else (perhaps in a different utility domain) and the attempt is to keep the same numbering across domains for ease of use.  In the future, our UN will have several different utility domains because many of the assets in our structural domain will be shared across utilities (we are a university campus that manages most of our own utilities). 

That said, I need to add a code for "Removed" (it's not the same as "Abandoned") to let our utility locating people know, "That line you remembered from 5 years ago? It's no longer there, so you don't need to worry about marking it!").  Is there someplace where I can find out what the "missing" values are?  There may be one for "Removed", in which case I would like to use that, and I don't want it to choose a number that is used in a different manner in similar domain in some other place/utility domain. 

For example, if I hadn't looked in the Lifecycle_Combined domain and just assumed the "missing" numbers were vacant, I might have chosen "3 = Removed".  Then later, if I used the Lifecycle_Combined domain, I would have a conflict because in Lifecycle_Status,  3 = Removed, whereas in Lifecycle_Combined, 3 = Proposed and Approved.  This is the kind of conflict I want to avoid.

Cheryl

[DamienPyne · Accepted solution]

Cheryl

In the updated documentation for the Electric Utility v3, there is a section discussing subnetwork management.  This explains these codes and their use.  

https://solutions.arcgis.com/electric/help/electric-utility-network-foundation/design-pattern/advanc...

Lifecycle_Status is a domain whose codes and descriptions represent the life cycle phases of a feature and is applied at the subtype level. Each code represents one bit in base 2 binary. The Lifecycle_Status domain has a bit sequence of:

Domain code (Base 10)	Domain description	Base 2 value
0	Unknown	000000000
1	Proposed	000000001
2	Approved	000000010
4	Under Construction	000000100
8	In Service	000001000
16	To Be Retired	000010000
32	Abandoned	000100000
64	Retired	001000000
128	Removed	010000000
256	Out of Service	100000000

The Lifecycle_Combined domain is applied at the feature class level and includes all the values in the Lifecycle_Status domain, along with bit combinations. The following example shows bit addition which are used in the trace framework and subnetwork definition. This is just a subset of values in the domain and does not include every value.

Domain code (Base 10)	Domain description	Base 2 value
0	Unknown	000
1	Proposed	001
2	Approved	010
3	Proposed and Approved	001 + 010 = 011
4	Under Construction	100
6	Approved and Under Construction	010 + 100 = 110

Network attributes use the Lifecycle_Combined domain assigned at the feature class level to present valid options in a trace or subnetwork definition. The subnetwork definition has bitwise operators that can leverage the addition of bits. For example, the domain value 3—Proposed and Approved, is the addition of two domains, 1—Proposed and 2—Approved.

Hopefully this helps. 

[CherylTrine]

Thank you.  I just now had time to digest your response and the link.  I did not think to check what information was provided for other utilities . . . .  and I see there is even a code for Removed (couldn't find that anywhere in the Stormwater Network documentation).  I guess I need to examine the documentation for several utilities to get my head wrapped around all this.

Very helpful. 

Cheryl

[AllysonReynolds]

Damien,

This answers the question about the "Removed" value and how LifeCycle_Status and Lifecycle_Combined are related. But it still leaves the question: if I need to add a new value, "Transferred", how would I do that? Are all the bit-values taken and if I added this value, it would break the LifeCycle_Combined calculation/domain? Could I just set it to 257 (this seems wrong)?

Thanks for any guidance you can provide,

Ally

[GavinMcGhie]

If anyone ever got an answer to how to determine what code to use for random "new" values, that would be helpful for those of use suffering through the UN now! 🙂

Thanks, Gavin

[Andy_Morgan]

To follow with Allyson and Gavin above, I too need an immediate answer on whether it's safe to add a couple of new values to the Lifecycle_Status domain. Will anything break if I created a code 257 (description = "Pipe Bursted") and code 258 (description = "Deleted")? We have been assuming we can borrow the Lifecycle Status field for these other, less used but important, options that will take it out of the "In Service" state for tracing and symbology purposes. (I realize we also need to adjust z-values for being omitted in the network validation.)  

Our use of the Lifecycle Status field for tracking abandoned / removed / bursted will replace the need for maintaining a bunch of separate feature classes like we do now in the Geometric Network: WaterLineAbandonedRemoved, WaterValveAbandonedRemoved, etc.