Summary :: Usage :: Parameters :: Outputs :: Warnings :: Limitations :: Code sample


Checks for disconnected polylines, any found are logged in the error log table.


A common digitising error is to snap the polyline to another polyline; but not to the end node.  These polylines intersect and visually appear to be a complete network.  The golden rule for networks is that polylines must join each other at their ends. So a polyline intersecting another somewhere along it's length is break this rule and consequently the topology of the network. 

Disconnections can have a severe affect on your river network.  Imagine the polyline that is causing a disconnection is the main course of a large tributary flowing into a much large river.  Any network processing (including stream ordering) will interpret this as a new catchment and not part of the whole network.  With regards to stream ordering, the order the tributary achieves when it joins the larger river is not added to the overall stream order of the river, as the GIS interprets it as a separate catchment. This is best described in the sequence of images below:

A river network; visually it appears to be an acceptable topologically correct network

Disconnect 1

The same network now displaying it's nodes. It still appears to be topologically correct.

Disconnect 2

The same network displaying it's nodes but now with each whole polyline uniquely coloured.

Disconnect 3

The red circle indicates the disconnection.  If this network was topologically correct then the polyline which is currently displaying as yellow would actually be two colours because there should be two polylines.  Thus the red circle indicates that the blue polyline is simply "touching" the yellow polyline and not actually snapped to a node.

Disconnect 4

A disconnected polyline can visually look like a valid tributary junction but is in fact a topological error that needs fixing. Typically fixing requires either initially splitting a polyline then moving the end of the disconnected line so it snaps to the junction.  Be aware that you don't simply snap the intersecting polyline node to a vertex very near the node you created by splitting the polyline.  This can happen if the snapping search tolerance is too big.  You will simply end up creating a new disconnection! 

Any found to be disconnected have their polyline ID written to an error log table called tblDisconnected. If the table already exists then a new table name is created with a simple numeric suffix.

The tool optionally adds the error log table to the map (default) and if selected builds a standard relate between river network layer and error log table. You can use the relate to select and jump to the polyline to streamline your editing experience.




Data type

River Network

The river network. For best results the network should be within a File GeoDatabase

Feature Layer

Add Error Log Table to Map

If this is ticked (default) the error log table will be added to the map for your convenience if any errors were found.


Build a Relate for Error Log

If this tick box is checked then the error log table must be loaded into the map and RivEX builds a standard relate between the Error Log table and the river network layer. You can use the relate to help you jump to and review the error.



This tool creates a stand alone table named tblDisconnected, if any disconnections are encountered within the river network.  The table is created in the RivEX workspace folder and stored in the File GeoDatabase found in ..\RivEX_Workspace\ErrorLogs\fGDB_RivEXErrorLogs.gdb

Advice on the structure of the error log table and how it can be used is found within this section of the manual. Take note of the warning if you plan to construct a model using the error log output in subsequent processing.


Having identified disconnections and corrected them, you will have changed the topology of the network.  You must re-run your network through the Extract Network Topology and write to Workspace tool to rebuild and correctly attribute the node and polyline fields in your river network.

With the release of ArcGIS Pro 3.2.1 a switch control appears on parameters that accept tables\feature classes, do not interact with it! More advice here.


Any selection on the input layer is cleared and then the tool checks all polylines in the river network.  Disconnected polylines may be identified when a polyline's TO end is so near to a line that it falls below the XY tolerance of the data and is seen as a touching line.

Code sample

A minimum code example showing how to call this tool in a python script. This can be run in console or your preferred IDE. If you right click on the tool in the RivEX toolbox and select properties you can view parameter order.

import arcpy

# Import RivEX toolbox

    # Input river Feature Class
    fc = r"C:\Temp\ORN\ORN.gdb\ORN"

    # Run RivEX quality control tool
    res = arcpy.scrQCDisconnected_RivEX(fc, False, False)
    # The rivers Feature Class, a derived output
    fcRivers = res.getOutput(0)
    # Get error table
    tblError = res.getOutput(1)

    # Check if error table exists
    if arcpy.Exists(tblError):
        # Count number of rows
        res = arcpy.GetCount_management(tblError)
        n = int(res.getOutput(0))
        if n > 0:
            print(str(n) + " error(s) were recorded")
        print("No error table created!")
except arcpy.ExecuteError:
    print("FAILED to quality control network")

Return to top of page