This section introduces some concepts which are fundamental in order to understand how the extension works.
Network Traces can be useful to solve problems related to the network geometry. For example, it's possible to check the connectivity of the network features in a model. Through specifying network features at which the trace should stop, it's possible to isolate supply zones.
In the EPANET hydraulic model, pumps and valves are represented as lines. From the hydraulic modeling point of view this makes sense, as the orientation of the valves and pumps is important information. In GIS data, pumps and valves are typically represented as points, as they are also symbolized with point symbols. Point data is lacking the orientation information. Because of the pipe-node duality pipes and valves will be referred to as virtual lines in this section.
The pipe-node duality complicates the creation of hydraulic models from the GIS data. It is possible to overcome the problem with one of the following solutions:
Storage of orientation information for each virtual line in the GIS
Take over the orientation of connected pipes
The second possibility has some advantages, as it does not require additional data storage - it was applied in the described application. However, it imposes some restraints on the data. The concept to model virtual lines as points in the GIS can be summarized as follows:
Each virtual line needs to have exactly two pipes connected
Both connected pipes must be oriented in the same way: One pipe has to start at the virtual line and the other pipe has to end at the virtual line
Figure 1.1, “Virtual Line Validity” shows examples of different
pipe orientations
at a virtual line. The case a shows a pump with two
pipes connected that are oriented in the same way. This
allows the creation of the hydraulic model and is
therefore considered valid. Case b shows pumps with
pipes connected that are not oriented in the same way.
This is invalid as is does not allow the creation of
the hydraulic model. Case c is invalid because the pump
has more than 3 pipes connected to it. Note that the
orientation information of the pump symbol is not
necessarily contained in the GIS data.
Figure 1.2, “Virtual Line Creation”
depicts the conversion process of virtual
lines:
Number and orientation of the pipes connected to the virtual line are checked for validity
The virtual node is replaced with a junction (PJ1).
An additional junction is added (PJ2).
The pipe from the virtual line to the next node starts at the additional junction. (PJ2 -> J2).
The pump or valve is created. It connects the two new Junctions (PJ1 -> PJ2).
The DC Water Design Extension follows this conversion process when it is creating EPANET models. Additional considerations used in the process are:
The length of the virtual line is one metre. Figure 1.2, “Virtual Line Creation”
If the pipe starting at the virtual line is shorter than one metre, the virtual line length is set to half of the pipe length.
Virtual Lines provide a concept to convert GIS point data (pumps or valves) into the lines used by the hydraulic analysis software. The conversion is done automatically when the GIS data is exported to the hydraulic model. Virtual Lines require exactly two pipes connected to each pump or valve. In Addition, the two pipes have to have the same digitizing direction (which will be the flow direction in the hydraulic model).
Byte codes make it possible to store fields of yes-no information in 'normal' text. Every byte in the number having the value "1" is considered set, every byte of value "0" is not set. Thus making it possible to code several independent pieces of information in one ArcView string.
As ArcView shapefiles allow to store strings of up to 255 characters length, it is possible to store up to 255 pieces of information.
The following example shows how this concept allows storing the network information in one seamless data set and utilizing the same network features in different hydraulic models:
In Figure 1.3, “Byte-coding Supply Zones” the nodes of three hydraulic models are byte-coded for storage in the GIS. Each zone has its own byte in the byte code, indicating if the node is used in the model or not.
Byte codes are stored as strings in GIS data. They provide a powerful method to store hydraulic models in GIS data. The underlying principle is very simple:
The models are numbered
Each byte represents one supply zone
If the byte is set ("1") than the network feature is used in the respective model. Otherwise ("0"), the feature is not used in the model.
The different values are assembled by the following functions:
DCWatDes.Bitcode.and DCWatDes.Bitcode.or DCWatDes.Bitcode.xor See the section called “API Documentation” for details regarding these functions.
![[Note]](images/note.png) | Note |
|---|---|
Note that the byte numbering starts at 1. You should use a temporary field in order to perform the addition of two byte codes correctly. |
| Note |
|---|---|
Note that you should use a different concept if you want to split up your model for editing purposes. The byte code concept models a one to many relationship, but for editing purposes, a one to one relationship should be used. This makes the automatic assembly of the model after editing easier. |