I usually made a random rotation between 5 and 10 degrees and used the accumulated angle in a while-less-than-360 loop. So the maximum gap would have been close to 10 deg and give me between 36 and 72 vertices…
Thats too much overhead. Take into account that if you connect two points of different splines this way, you may create new crossings. So this would have to deone recursively.
On the other hand, if you just create some splines (simple operation, just repeat it). Then process the splines linearly for overlaps. Also done very simple (crossing of line segments test). And because you only add the intersection vertices and dont add new lines, you dont create new crossings in the process.
The next step, if needed, would be an associative list with all vertices (individual splines are no longer relevant at this point) that map the neighborhood relation of them.
This provides then also a basis for efficient path finding on the roads. (You could store the travel costs as edge weights of the graph).
EDIT:
here is a little graph to illustrate:
(forgot one red-blue crossing…)
First all colored polygons are created with the circular-random-sweep method from above.
Then all polygons are tested and the new vertices (black) are creted and the colored polygons subdivided at these points. So per intersection, the number of two polygons increases by 2.
Then, we can view it as one connected graph now.
PS: This way, you will only get vertices with max 4 connected edges, unless 3 or more polygons cross the same point. it is more likely to have intersections that are not exactly congruent, but very close.
You can then still collapse vertices by averaging them and connecting all edges to the new vertx. For example the red/blue/purple triple near the conter of the graph could be merged to a 6-roads crossing…
this way you avoid super short edges if intersection are too close…