Gas Stacked Meters in Utility Network

[LindseyStone]

I was curious if anyone has any recommendation for a configuration of Gas meter banks in the Gas Utility Network.  We have situations where we have one service line that has multiple meters on it (ex. apartments).  So we would need all those meters associated to that one line.  Right now we can snap one meter to the end of the line, but are stuck after that.  In the electric network we put a Junction line end at the end of the service line at z=0 and then the rest of the meters we changed the z values.  Then we did a junction to junction association between the line end and the meters so the subnetwork would propagate to all the meters.  In Gas I'm not even seeing any Junction to Junction rules set up for Customer Meters or possibly any junctions that make sense to use to add a rule.

[RichardKoch]

Lindsey,

We are Electric but services are services. Not knowing your setup I will say this is how we did it and maybe it gives you a direction to work towards. For us most things were always a PARENT>CHILD relationship in the database. This included customers. We in our original system only had a single unit on the map and upon selecting it you were given a drop down in the data window to see the information on the child records. 

Upon moving toward the UN things worked differently. In the UN they map the Children and then contain them in the Parent (BANK) records. Our integrator/migrator auto generated the children at predefined intervals from the bank placement. Created the containment, structural, and electrical associations.  Attaching a picture of what this looks like. After seeing it the idea came to me that in an apartment or mall I could place the bank at an entrance location and the meters more where the actual customers are located. In the attachment the unit between the two uppermost rows is the BANK. I adjusted the scaling so it is on at the same level as the meters. Typically we have the banks on at higher zoom levels and then the banks go off and meters come on after you cross a certain threshold. 

hope this helps some. 

Richard Koch
FEU GIS Specialist
kochr@firstenergycorp.com

[JSchroeder · Accepted solution]

Hi @LindseyStone,

The Gas Utility Network functionality and intent is to model the Distribution system as close to real world as possible, but realizing that one size does not fit all, how about these two options:

1. Model the pipes between the bank of meters by utilizing Service Pipe or Riser Pipe to connect each meter to maintain connectivity.
2. Create a new Pipeline Junction Asset Type called Service Connection. This could be connected to the Service Pipe Endpoint and would allow tracing through Associations to a bank of meters in addition to the more common '1 Service Pipe to 1 Meter' customers (no need for Service Connection junction for 1:1 customers, just connect meter to end of Service Pipe as is typically done now).
   • Add new Junction-Edge rule for Service Pipe to Service Connection
   • Add new Junction-Junction rule rule from Service Connection to Meter 

I'm interested to hear some feedback on this as we want to provide the most realistic and useful configuration. While it is not possible to account for every scenario from all gas operators, the model should be flexible to adapt to your unique workflow(s) and modeling.

[LindseyStone]

@JSchroeder 

For an update on this...I took a process very similar to option number 2 that you outlined.  Except I didn't create a new Pipeline Junction.  I utilized the existing junction - Connection Point and just added a new Junction-Junction rule from Connection Point to Meter.  I choose to do this since the Connection Point was already being allowed as Junction-Edge to the Service Pipe.

The only other thing I'm noticing is that the subnetwork name is not propagating to the the Meter Setting Assembly.  I have the meters contained within the Assembly just like it is on the downloaded Naperville Data but the System Subnetwork Name still says Unknown on the Assembly.  Everything else (service line, meters, and connection point) has it filled out.

Also to answer someone else's comment on this thread we do stack our meters at locations with multiple meters, so that means I change the Z values of each meter to 1-#.  We do this because the end users doesn't like the meters spread about if there is only one service line and they just want to click once on the map and be able to scroll through on the attributes to see all the meters.  Yes in the 2D model (which is how we view all of our data) you can only see one, but this is also the only place we add a meter assembly, so we can quickly tell where there are multiple meters as we see the assembly.  We do this same thing in Electric, and will eventually in Water.

[Anonymous User]

For our Gas UN migration we modelled the individual gas meters (Asset Type Meter, Asset Group Pipeline Device) to be contained by the Meter Setting Asset Type under Pipeline Assembly. @RichardKoch has a screen shot which resemble our results for the gas meters.

[LorenMueller]

Hi @LindseyStone ,

As connectivity associations was the first thing to come to mind I would agree most with option 2 from @JSchroeder .  That would take care of your connectivity and tracing. Display of the associations could even be enhanced for users via the 'Create Association Lines' tool in the Utility Data Management Support Tools.

The title of your post implies that your meters points are stacked? If that is also the case you will need to offset them in either the Z, XY, or both.  Z is less appealing of a solution IMO because 2D maps still show them as a single point.  I have seen both grid and spiral offset solutions implemented to unstack the meters. Keep in mind visual display needs when looking at options.  FME is a great tool for implementing this type of offsetting if looking at automating it. Depending on the number of meters it can get quite 'busy' visually.