polarkernel
commented
2 years ago Way-Sections
Starting point of the process is the section-network. It contains way-sections, which have been constructed from one or more OSM way-segments or parts of them. Their endpoints are intersections, end-points of dead-end ways or vertices, where the category tag changes. They are stored in instances of the class NetSegment. This class stores not only start- and endpoints of the way-section but also the paths built by all original vertices provided by OSM. Way-sections may have identical start- end endpoints, but different paths. Here, as an example, is an extract from a network:
Graph-Cycles
Graph-cycles are derived from the section-network by following the sections in counter-clockwise order. In most cases they are single simple polygons with edges formed by the way-segments of the paths of the way-sections (see left image below). When they are triangulated, all their vertices belong to a triangle. Large graph-cycles may be dissolved to smaller parts, which I called slices (right image below). In both cases, the class GraphCycle stores them as a list of polygons, containing only one in the former case. After the triangulation of graph-slices, not all triangle vertices belong to a way vertex.
Dead-Ends (Spurs)
Following dead-ends in counter-clockwise order, as depicted in the left image, lead to degenerated polygons which can't be processed any more. These segments are eliminated from the graph-cycle and stored separately in the instance of GraphCycle. I called them spurs. They are not involved in the process of triangulation and are currently unused. The red lines in the right image show examples of such spurs.
Way-Islands
Within graph-cycles, there may be way-islands. Two situations can produce them. The first occurs, when inner cycles within graph-cycles are only connected to the outer cycle by a single way. This single way again produces a degenerated polygon and is eliminated by the spurs removal. In the image below, the white areas were only connected to the outer polygon by the red spurs, which produced islands, the white holes in the polygon. These holes form other graph-cycles, which are processed separately. These holes are way-sections that are stored as holes in the slices of the cycle polygon and, again, the spurs connected to the holes are stored in the instance of GraphCycle
However, in rare cases, there may exist inner cycles that have never been connected to the outer graph-cycle. These are detected as cycles in clockwise order in the section-network. After a search for their smallest enclosing graph-cycle, they are integrated as a hole into this. Here an example, where the graph-cycle has been splitted into slices after that.
Solitaires
Way-sections that are not connected to graph-cycles and do not form a cycle are detected in the section-network as polygons that have zero area. I called them solitaires. Sometimes they are only single straight segments. They are currently detected, but not processed at all. Here two examples (blue lines):
Object Subtraction
Finally, the polyline objects within the graph-cycle are subtracted and produce additional holes in the polygon. The subtraction is done individually for every slice of a graph-cycle, if it has been splitted. Object polygons never touch a way-segment of the graph-cycle, but this is not tested for spurs. After the subtraction, every cycle slice is triangulated separately. All the triangles are stored in the instance of GraphCycle. Here some examples:
Relation of Ways to Triangles
With the exception of solitaires, all way-sections of a graph-cycle are held together in its instance of the class GraphCycle. However, for a given way-section, there are triangles on both sides of the way, in two different graph-cycles.
vvoovv
In the current version of _roadpolygons.py there exists a mixture of different approaches, where and how way-sections are stored. These are the result of the development history and certainly need to be refactored, so that finally the triangles can be related to these sections. Within this issue I will try to explain the current state in detail. Based on this knowledge the discussion can be opened about how finally the triangles and the way-sections have to be related to get the desired result for the rendering of the streets. Since we do not yet know how this final result will be derived from the triangles, this topic may possibly also be a starting point for ideas on this topic.