Water storage tanks can sometimes be 50' or more in diameter. Since TKs were modelled as points in the Geometric Network, and we didn't want to add non-existent linear footage of Main from the edge of the tank perimeter to the centroid where the point lives, we created Virtual Edges to maintain connectivity. Occasionally with multiple connections to the tank, adding true main could add several 100 feet of non-existent Main. With the UN, I was looking forward to addressing this by either using the Tank perimeter structure as the connection (I found out not how it works) or replacing the virtual pipes with an association (adds its own complexity). Looking at the Naperville model, I see that the TKs are represented as both WaterDevice and StructureBoundary. However, i also noticed that the point, which connects the network, still had the Mains going right through the tank perimeter to the centroid. Is the standard just to ignore the fact that it adds overall length of Main to the system? How are others addressing this? Has anyone used associations for this? Thanks, Gavin
Solved! Go to Solution.
This question hasn't come up in our implementations. Generally, I doubt with the limited number of tanks in a system the cumulative impact is as significant as say manholes in the wastewater system. I'd argue it's a business decision. For simplicity sake, take the WaterLine all the way to the central WaterDevice point as per the base model. For accuracy, you could stop the main at the point where it connects to the tanks' inlet/outlet pipe, which varies by tank design, and create an association with a pipe connection on the main. I would look the the wastewater main/manhole design as an example.
In practice, running the line to the tank centroid has not been problematic for our systems.
Hope this helps,
Mike
This question hasn't come up in our implementations. Generally, I doubt with the limited number of tanks in a system the cumulative impact is as significant as say manholes in the wastewater system. I'd argue it's a business decision. For simplicity sake, take the WaterLine all the way to the central WaterDevice point as per the base model. For accuracy, you could stop the main at the point where it connects to the tanks' inlet/outlet pipe, which varies by tank design, and create an association with a pipe connection on the main. I would look the the wastewater main/manhole design as an example.
In practice, running the line to the tank centroid has not been problematic for our systems.
Hope this helps,
Mike
This sounds reasonable, but seeing that we've already separated these virtual pipes, I can calculate that we have over 13 miles of virtual pipe in our system that is associated with tanks. That's from about 200 miles total. That ends up being pretty significant if ignored, or factored into the overall real piping that needs to be managed.
I'm still deciding on whether to keep our virtual edges in the UN or use associations, but at least for us, it's not trivial to ignore, which is why we undertook creating them in the first place. I was just curious what others are doing. Anyway, thanks for the feedback!
cheers, Gavin
I agree - 13 miles out of 200 is significant. In that case, I would lean towards an association, though your existing virtual edges would be easier to migrate and edit.
May be a bit past it at this point, maybe give the 13 miles of virtual pipe all tank sites a second glance. At most I'd estimate in a single site design, including 1 riser pipe going up center of tank bas 75' in the air (elevated tank), each site having no more than 300 ft under/through or up to an elevated tank volume. 13 mi would ~roughly mean 225 tank site's worth of pipe. If the 13 miles also includes process piping at treatment plants and facilities then that starts certainly can add up to 13 mi. Agree with earlier poster, layout would vary by design, some pipes stop at face of tank, some run up to the bottom of an elevated tank, just depends on site design and layout.
Pretty much the same two options that came to my mind as well.