I have created a river network as polyline shapefile for training purposes. No I wanted to integrate undershoots/overshoots that needs to be detected and corrected from the participants.
I have used the snapping option to generate the polyline shapefile. I used as rule within the Topology Checker Plugin: "must not have dangles". The QGIS User Guide is saying (QGIS User Guide) that this rule is "show the overshoots in the line layer". Actually all end- and strating points are detected as error, even if they share a vertex and are connected to each other.
I think dangles are per definition something else. Have a look to the definition of GIS-Lounge, dangles are: "Dangles or dangling nodes are lines that are not connected but should be. With dangling nodes, gaps occur in the linework where the two lines should be connected. Dangling nodes also occur when a digitized polygon doesn’t connect back to itself, leaving a gap where the two end nodes should have connected, creating what is called an open polygon."
I am right, that Topology Checker Plugin is not able to detect undershoots/overshoots? If yes, is there any other possibility how to easily to it within the QGIS environment?
Best Answer
I think this is correct behavior. In logical (network) topology all lines must end (or start) at the end (or start) of another line. You have to physically split lines at the location (vertex) where other line touches. You can visualize this as water pipes. If you need to create T join on existing pipe, you have to split that pipe first, then add fitting and then connect another pipe to fitting. I hope that sound clear. This behavior led to another problem - one logical entity divided to multiple pieces. So you ends up with many features with same attributes, which is not good for maintenance. Imagine you need to change river name... Now you have to change it for each corresponding segment. Often this is not big deal. But if you want to solve this elegantly, you can model rivers as two separate tables (feature classes). One with attributes only and one with geometries. Attribute table will hold unique list of all rivers. Geometry table will hold river segments and one extra attribute(say id_river) with relation to river attribute table. In this setup one river can have multiple geometry segments, but you maintain only one river record.