Developer/Network Building Process
NETCONVERT, NETGEN, and NETEDIT share the same process of building networks which is started as soon as data are read (in NETCONVERT) or after an internal description is generated (in NETGEN).
The process requires that at least nodes and edges are given, optionally also connections between edges and/or lanes and other optional information. Hints about how the network shall be built - whether turnarounds or highway on/off-ramps shall be added, traffic lights or roundabouts shall be guessed, etc. are retrieved from the options.
Below, you may find a list of all steps performed while building the network, of which some are optional.
- Building node clusters
- Adapting the input
- '
Removing dummy edges' - '
Joining double connections' - '
Finding isolated roads' - '
Removing unwished edges' - '
Removing empty nodes and geometry nodes' or 'Removing empty nodes' - '
Splitting geometry edges'
- '
- Moving network to origin
- Guessing and setting on-/off-ramps
- TLS position computation
- Assigning nodes to traffic lights
- Joining traffic light nodes
- Computing connections between lanes
- Computing turning directions
- Sorting nodes' edges
- Computing Approached Edges
- Computing Approaching Lanes
- Dividing of Lanes on Approached Lanes
- Appending Turnarounds (optional)
- Rechecking of lane endings
- Geometry computation
- Computing node shapes
- Computing edge shapes
- Computing right-of-way and traffic light programs
- Computing tls logics
- Computing node logics
- Computing traffic light logics
- Transposing network (optional)
These computation steps are perfomed within void NBNetBuilder::compute(OptionsCont &oc). These steps are described more detailed in the following.
#1: Building node clusters
- Purpose: Join network graph nodes which form a single intersection.
- code: tbd
#2: Adapting the input
- Purpose: Remove unwished edges/nodes from the internal representation; add geometry nodes if wished
The following sub-steps are done:
- removeDummyEdges ('
Removing dummy edges'): remove all edges where the from-node is the same as the to-node
- post-condition: Each edge is a uni-directional connection between two different nodes (ok)
- code: green for me, though a) the involved methods should probably be renamed, b) I am not sure why lists of edges are built which are then given to remapping methods; wouldn't it be enough to check within the remapping method whether a connection exists?
- joinDoubleNodeConnections ('
Joining double connections'): "join" edges which connect the same nodes
- post-condition: No two edges with same geometry connecting same nodes exist
- code: yellow, as there are two comments in the code, one about a bug, a second one about a missing check for vclasses; should be revisited (why it's here, what would happen if not)
- comment: ? Earlier, only one road could connect same intersections; not now. Why, explain, how does it work?
- removeIsolatedRoads ('
Finding isolated roads'): remove edges which are isolated (not part of the network)
- post-condition: ? not defined somewhere
- code: yellow; the method is pretty large, and there is no removal of edges within the tls control; how does it work?
- comment: Should be revisited
- removeUnwishedEdges ('
Removing unwished edges'): Removes edges not in myEdges2Keep
- post-condition: not wanted edges are no longer in the internal containers (ok)
- code: yellow; the complete keep/remove/keep-postload - stuff should be revisited
- removeUnwishedNodes ('
Removing empty nodes and geometry nodes' or 'Removing empty nodes'): Removes useless nodes
- post-condition: empty nodes, nodes with no incoming/outgoing edges, are removed (ok)
- post-condition: nodes which only affect the geometry of an edge are removed if wished (ok)
- code: yellow; should be done in two steps for a cleaner code; additionally, we had the bug that empty acosta nodes where still in the network; is this solved?
- splitGeometry ('
Splitting geometry edges'): Splits edges at geometry positions
- post-condition: If wished, edges have a line-geometry only
- code: yellow; the naming of built nodes is not proper
As a result, the internal representation of the read/generated network contains the sets of nodes/edges the user wanted.
#3: Moving network to origin
- Purpose: Let network coordinates start at 0,0
- code: green
#4: Guessing and setting on-/off-ramps
- Purpose: Add missing on-/off-ramps
- code: tbd
#5: TLS position computation
- Purpose: Let nodes know whether they are controlled by traffic lights
- guessTLs ('
Assigning nodes to traffic lights')
- post-condition: empty nodes, nodes with no incoming/outgoing edges, are removed (ok)
- code: tbd
- joinTLS ('
Joining traffic light nodes')
- post-condition: empty nodes, nodes with no incoming/outgoing edges, are removed (ok)
- code: tbd
Steps #9-#10: Computing certain signalling/right-of-ways
Steps #11-#17: Computing and setting lane-to-lane connections
Steps #18-#19: Computing geometries
I am currently concerned with the edge shapes, because even a eworld or a TrafficModeler export stops here in debug mode. It is in NBEdge::computeEdgeShape. (Actually, as far as I understand this method, it is about the lane shapes of this edge.) In this algorithm, the following three cases must be distinguished:
 | The edge shape intersects with the node shape. Then, the shape is trimmed to the intersection point. This looks quite reasonable. |
 | The edge shape is outside the node shape. The the present algorithm extrapolates the last line of the edge shape and enlarges the edge to the new intersection point. This looks reasonable to me as well. |
 | The edge shape is completely within the node shape. What should happen here? (The red dots show, what netconvert does at present.) |
So I am wondering, what the right behaviour of netconvert would be in the third case.