Hi,
We're working on making small adjustments to the ESRI's Electric Asset Package/Solution to better fit our needs. For a little more context, we're starting with no previous GIS/Geometric Network data to migrate; this is a jump from paper maps to the UN.
At this point, we're focused on understanding and selecting the AssetGroups and AssetTypes that we need to model our infrastructure. Also, we're identifying additional attributes we would like to add to the selected AssetGroups.
Looking at the Naperville sample model we noticed some of the uses of the ElectricAssembly features that made us ask if there are benefits that we don't understand. For example:
We understand the benefit of an Assembly containing multiple features, like a transformer bank that contains individual feature representing transformers, fuses, arresters, and connector; or a pad mounted switch bank that contains elbows, busbars, switches, etc. But what are the benefits in the examples above? Why not just used the Assembly or the Device only?
Also, we noticed that only the Assembly has an attribute for "Subnetwork name" but not the Device inside (see picture below)
Subnetwork name is different than subnetwork controller name. The latter is only populated for Devices that have been enabled as controllers.
John Alsup for the data modeling questions
Hi Paul,
Thanks for the clarification.
Hi Billy.
One reason is consistency. Let's take the service point example. Let's say I have an apartment complex with 100 units and I will have 100 Device/LV Service Points. I would prefer to place all those in a Device/Service Points in to a single Assembly/LV Service Point. Now, I would only see these 100 features when i either enable view content or zoom in very close. But, for the user/editor, they want to be able to turn the service point Visibilty On and Off or change scale suppression. If you don't put all Device/Service Points in the Assembly/Service Point, then the user now has two places to change these settings.
Of course this is personal preference. I like consistency. Others may not.
Hi John,
Thanks for your answer. I think that the example of the Assembly/LV Service Point is one that shows what happens when you go to the other extreme (too many feature inside a container, the other extreme being just having one feature). Having tens of features inside a container doesn't seem to me practical to maintain or useful from the mapping standpoint. I would prefer to see on the map a single symbol that represent a point with multiple services and then have a table that associate the individual services' data to the map symbol. I think that is easier to maintain.
Now, what about the other examples in my question? Do you have any benefits that justify creating 2 item (container and content) when a single item can hold all the information needed and will be easier to maintain and easier to understand graphically?
Hi Billy. The purpose of the Assembly feature is to allow for a single point representation of multiple items. In cases where you have a three phase fuse and you want to be able to operate the fuses by phase, you must have one device (fuse) per phase. That gives you three fuses (devices) and two line end (junctions) where you really only want to see a single fuse symbol. All of the device and junction features are then put in to the fuse assembly feature. Now can you represent the three phase fuse as a single device, sure, but you will not be able to open a fuse on a single phase. This may not matter to you, but to others it will. When I worked a power company, we had many cases of switches and fuses where not all phases were operated the same way at the same time (mixed open and closed). Also, again, if you need to have the case I have described, then you would want to use the assembly. In that case, do you want your users to have to know when to work with an assembly vs a device?
Hi,
I suppose you are referring to this scenario:
I understand the consistency aspect. It possible that you need to operate a single fuse like you mentioned but I guess at the end it's a matter of how close you want to model the devices in the field versus the added work needed to create and maintain such a model.
Thanks again.