Introduction

The union of two network diagrams means combining all nodes and all connections from both diagrams into one graph. The idea is simple in graph theory, but practical work gets harder once you decide how to handle duplicates, direction, and conflicting metadata.

Define the Union Clearly

Treat each network diagram as a graph made of vertices and edges. The union keeps every vertex that appears in either input and every edge that appears in either input.

That definition raises a few design questions:

• Are the graphs directed or undirected?
• Are edges unique by endpoints alone, or do labels matter too?
• What happens if both diagrams contain the same edge with different weights or attributes?

Until those rules are explicit, "merge the diagrams" is underspecified.

A Pure Python Example

For many data-processing tasks, you do not need a graph library. A small amount of Python is enough to express the union operation.

1def normalize_edge(edge, directed=False):
2    a, b = edge
3    return (a, b) if directed or a <= b else (b, a)
4
5
6def union_graphs(g1, g2, directed=False):
7    nodes = set(g1["nodes"]) | set(g2["nodes"])
8
9    edges1 = {normalize_edge(edge, directed) for edge in g1["edges"]}
10    edges2 = {normalize_edge(edge, directed) for edge in g2["edges"]}
11
12    return {
13        "nodes": sorted(nodes),
14        "edges": sorted(edges1 | edges2),
15    }
16
17
18g1 = {
19    "nodes": ["A", "B", "C"],
20    "edges": [("A", "B"), ("B", "C")],
21}
22
23g2 = {
24    "nodes": ["B", "C", "D"],
25    "edges": [("B", "D"), ("C", "D"), ("A", "B")],
26}
27
28result = union_graphs(g1, g2)
29print(result)

Output:

1{
2    'nodes': ['A', 'B', 'C', 'D'],
3    'edges': [('A', 'B'), ('B', 'C'), ('B', 'D'), ('C', 'D')]
4}

The normalize_edge helper prevents undirected edges like ("A", "B") and ("B", "A") from being treated as different connections.

Preserve Meaning, Not Just Shape

In real network diagrams, edges often carry extra meaning: latency, bandwidth, dependency type, cost, capacity, or ownership. A plain set union loses that detail unless you define a merge rule.

Here is one simple approach that preserves edge attributes and lets the second graph override the first if both define the same edge:

1def union_with_attributes(g1, g2):
2    merged = {}
3
4    for a, b, attrs in g1:
5        merged[tuple(sorted((a, b)))] = dict(attrs)
6
7    for a, b, attrs in g2:
8        key = tuple(sorted((a, b)))
9        merged[key] = {**merged.get(key, {}), **attrs}
10
11    return merged
12
13
14g1 = [
15    ("A", "B", {"weight": 10, "source": "diagram-1"}),
16]
17
18g2 = [
19    ("B", "A", {"weight": 12, "status": "new"}),
20]
21
22print(union_with_attributes(g1, g2))

That override policy is not universally correct, but it is explicit. Other systems merge by maximum weight, minimum cost, or by keeping both values as a history list.

Diagram Union Versus Network Comparison

People sometimes ask for a union when they actually want comparison. If your real goal is to understand change between two network diagrams, union alone is not enough. You may also need:

• intersection, for links present in both diagrams
• difference, for links added or removed
• conflict detection, for nodes with the same identity but different metadata

This is especially common in infrastructure diagrams, where one network comes from production and another from a planned migration. The union shows the superset, but it does not tell you what changed.

Complexity and Scale

If nodes and edges are stored in hash-based sets or dictionaries, the union is usually linear in the size of the two graphs combined. That is efficient enough for most application-level tasks. The expensive part is usually not the union operation itself, but the preprocessing:

• normalizing node identifiers
• resolving duplicates
• parsing exports from different tools
• merging attributes with incompatible schemas

In other words, the algorithm is cheap; data cleanup is where most of the work lives.

Common Pitfalls

• Forgetting whether the graph is directed. In directed networks, an edge from A to B is not the same as an edge from B to A.
• Merging nodes by label when labels are not unique across systems.
• Dropping edge attributes during the union and discovering later that the output lost operational meaning.
• Assuming union reveals change. It only shows everything present anywhere.
• Treating duplicate edges as errors in multigraph scenarios where multiple parallel links are valid.

Summary

• The union of two network diagrams keeps all nodes and all edges from both inputs.
• Before merging, define whether the graph is directed and how duplicate edges are identified.
• A small set-based implementation is enough for many workloads.
• Real-world unions usually need an explicit policy for merging edge attributes.
• If the actual goal is change analysis, combine union with intersection or difference operations.