We currently have a point feature class representing our Meters in our Geometric Network (ArcMap/ArcFM), and a separate point feature class placed generally in the customers parcel representing they have Solar. What we are interested in find out is how other Electric Utilities model their Meters where the customer has solar, and if they use any other feature or object classes to store specific attribute information, if it's feature classes, do they model exact connection of meters true to how it's in the field. We are wanting to depict our solar customers with more "intelligence" in our GIS. We are at the beginning stages for UN, about to start our Data Readiness Assessment, so we are open to looking at either UN or GM modeling/schema ideas.
@PaulScipione Our setup is pretty simple. We only keep a handful of attributes on the end points/meters. That data actually comes from a central system, and we just ETL it into GIS. We also set up pop-ups with dynamic URLs so you can jump straight into the external system and see all the details for that end point.
When it comes to modeling distributed generation, I think it’s all about finding the right balance — what do you want people to see on the map, how accurate do you need it, and how much info is really required?
Since we’re running an operational Utility Network, here are the three options we played with:
Change the Symbology
Just symbolize by asset type + distributed generation flag. Quick, clean, and you can instantly spot which end points have DG.
Add a Non-Spatial Solar Unit
Create a Solar Unit as a non-spatial object and hook it up to the meter. This models things more accurately, but editing gets trickier, and because it’s not on the map, people don’t really see it. Map Viewer support is still pretty limited too.
Add a Spatial Solar Device
Make solar units their own asset type in the ElectricDevice layer and connect them to the meter. This gives you the best of both worlds:
You can trace downstream and pick up all the solar units
It shows up clearly on the map
You can store rich attributes on the asset itself
For us, Option 3 feels like the sweet spot — you get the visibility and the proper modeling without too many trade-offs.
I would also suggest using this community, it's much more active 🙂
Esri UN Community