What is a geometric network?
Last modified February 1, 2008
Print all topics in : "Analyzing geometric networks"
NOTE: Although geometric networks can be created and edited in ArcInfo and ArcEditor, they are read-only in ArcView.
When a geometric network is created ArcGIS also creates a corresponding logical network, which is used to represent and model connectivity relationships between features. The logical network is the connectivity graph used for tracing and flow calculations.
An edge or junction element in the geometric network corresponds to one or more edges or junctions in the logical network. All connectivity between edges and junctions is maintained in the logical network.
The logical network is managed as a collection of tables that are created and maintained by ArcGIS. These tables record how the features involved in a geometric network are connected to one another. The logical network allows ArcGIS to quickly discover and model the connectivity relationships between connected edges and junctions in a geometric network during editing and analysis. This allows for fast network tracing and facilitates the generation of on-the-fly connectivity while editing.
When edges and junctions are edited or updated in the geometric network the corresponding logical network is automatically updated and maintained as well.
The following graphic shows how a water main, represented by a single complex edge in the geometric network, is comprised of multiple elements in the logical network. The water mains corresponding tables in the logical network are created and maintained by ArcGIS. When edits are made to the water main in the geometric network, ArcGIS automatically updates the corresponding elements in the logical network and connectivity between features in the geometric network are maintained.
Networks are often used to model real-world systems where the direction of movement through the network is well-defined. For example, the flow of electricity in an electrical network is from the power generation station to the customers. In a water network, the flow direction may not be as well-defined as in an electric network, but the flow of water may be from a pump station to a customer or from customers to a treatment plant.
Flow direction in a network is calculated from a set of sources and sinks. In the above examples, electricity and water flow are driven by sources and sinks. Flow is away from sources, such as the power generation station or a pump station, and toward sinks, such as a water treatment plant (in the case of a wastewater network).
Junctions in geometric networks can act as sources or sinks. When you create a new junction feature class in a network, you can specify whether the features stored in it can represent sources, sinks, or neither in the network. If you specify that these features can be sources or sinks, a field called AncillaryRole is added to the feature class to record if the feature is a source, sink, or neither a source nor a sink. When you calculate the flow direction for a geometric network in ArcMap, the flow direction will be calculated based on the sources and sinks in the network.
For example, you may have a tank in your water network that is down for maintenance, so its role in the network will be changed (temporarily) from source to none. The flow for the network is recalculated by the system, and any traces on the network will be affected by the change in flow direction caused by the state of the tank.
Learn more about network tracing
A network can have a set of weights associated with it. A weight can be used to represent the cost of traversing an element in the logical network. For example, in a water network, a certain amount of pressure is lost when traveling the length of a transmission main due to surface friction within the pipe.
Network weights apply to all elements in the network. Weight values for each network element are derived from attributes on the corresponding feature. In the transmission main example above, the weight value is derived from the length attribute of the feature.
A network can have any number of weights associated with it. Each feature class in the network may have some, all, or none of these weights associated with its attributes. The weight for each feature is determined by an attribute for that feature. A network weight can be associated with only one attribute in a feature class. The weight can also be associated with multiple feature classes. For example, a weight called Diameter can be associated with the attribute Diameter in the water main feature class and also associated with the attribute Pipe_dia in the water lateral feature class.
A network weight value of zero is reserved and is assigned to all orphan junctions. Also, if a weight is not associated with any attributes of a feature class, then the weight values for all network elements corresponding to that feature class will be zero.
Any edge or junction in a geometric network may be enabled or disabled in the logical network. A feature that is disabled in the logical network acts as a barrier. When the network is traced, the trace will stop at any barriers it encounters in the network including disabled network features.
The enabled or disabled state of a network feature is a property maintained by an attribute field called Enabled. It can have one of two values: true or false. When building a geometric network from simple feature classes, this field is automatically added to the input feature classes. When you use ArcCatalog to create a network feature class, Enabled is a required field for the feature class.
When adding new features to a network, they are enabled by default.
Values stored in the network weight, ancillary role, and enabled fields are the user's view of the state of the feature in the logical network. When analysis—such as tracing and flow direction calculation—is performed against a network feature, the value of these fields within the feature is not directly referenced to determine the enabled, ancillary role state of the feature or its weight. Instead, these states of the feature are stored in the logical network, which is queried during these operations. This is done for performance reasons.
When you edit a network feature and change the value of the enabled, ancillary role, or weight field, the state of the feature in the internal topology tables is modified to remain in sync with the field values of the feature.
Geometric networks can be composed of a number of edge and junction feature classes. When editing geometric networks in ArcMap, connectivity relationships between features are maintained while editing on the fly. The benefit of this model is that there is no need to perform a postediting process to build connectivity. The cost of continually maintaining network connectivity imposes overhead on the time it takes to add or modify features in network feature classes.
Connectivity in a network feature class is based on geometric coincidence. If a junction is added along an edge, the edge and junction will become connected to one another. When a new feature is added to a network feature class, this geometric coincidence must be discovered. So each feature class in the network must be analyzed by performing a spatial query against it to determine if the new feature is coincident with network features. If coincidence is discovered, then network connectivity is established.
When discovering connectivity, a separate spatial query must be executed on the server for each feature class in the network. If you use the map cache while editing the network, these spatial queries do not need to go against the server and are much faster. You will not pay as much of a penalty in performance for having a large number of feature classes in your network if you use the map cache. Using the map cache when editing your network features will significantly improve performance when adding new features or connecting and moving existing features.
Learn how to edit geometric network features
Learn more about working with the map cache
Try to reduce the number of feature classes you have in your geometric network by lumping feature classes together using subtypes. If your feature classes carry different attributes, you can use relationships to manage subtype-specific attributes in different tables in the database, or you can keep all the attributes in the same table using nulls for those that don't apply to a particular subtype.