I'm working with an electric UNv7 in an MGDB using Pro 3.5.5. I am attempting to add a summary attribute to my subnetwork definition that provides a count of how many different types of service locations are on each subnetwork (i.e., residential vs commercial). However that differentiation is at the asset type level and when i attempt to create a new summary attribute using Asset Type I get "Error 000800: The value is not a member of <Unknown>.
Comparing using the Asset Group vs Asset Type as the attribute, i notice that the filter value changes from free text to a drop down, and with asset type the drop down only includes an Unknown value. Is this potentially the tool having an issue aggregating the possible asset types across all the asset groups?
It reminds me of when we used to notice similar behavior in the Select by Attribute tool when viewing non-subtype group layers; Unknown was the only option that would appear for asset type because it was the only one every group had in common.
You should filter using network categories instead of asset types. It's easier to configure, provides more flexibility, and performs better.
The issue is likely caused by the data model you are using, also remember that asset types are not only not guaranteed to be unique in the entire utility network, but they're not even unique within a feature class (so specifying a particular code could provide an inaccurate result if that code is used on a different type of features). For all these reasons, and the ones listed in the first paragraph, create and assign a network category for this.
We have made sure that all of our asset type domain code values are unique across the UN for exactly the reason you state (so a code can not be used for queries and return inaccurate results) but I will try the network category method you're suggesting.
Out of curiosity, are there any drawbacks/limitations to consider when creating and managing network categories like there are for network attributes? Or can you make as many as you want without having to worry about downstream considerations?
Based on my experience and testing, I have seen there to be less consequences associated with using network categories for this kind of workflow, but you're constrained to identifying features at an asset type level. This works well when you're trying to identify types of equipment, but I wouldn't recommend that you try and replace all your network attributes with asset types, just so you can avoid network attributes.
I have seen customers use this approach for representing open/closed equipment as different asset types, and any potential flexibility/performance gain you would have gotten is eclipsed by the overhead of maintaining the extra asset types and the exponential increase in rules you have to maintain. This is both the administrative and performance overhead.