Data structure for generated streets

[vvoovv]

Consider the data structure for a road created by offsetting its centerline.

The resulting polygons are shown on the image above. The polygon with sharp corners is on the left and the one with rounded corners is on the right.

(1) A list with coordinates for the resulting polygon is needed. The order of the coordinates: [1R, 2R, 3R, 4R, 4L, 3L, 2L, 1L]. Additional information is needed for the case of the rounded corners. If the number of additional vertices is the same for each vertex of the original centerline, then it's enough to store that number of additional vertices for each corner.

[polarkernel]

Consider the data structure for a road created by offsetting its centerline.

Offsetting of way centerlines is already produced (and stored) in the class NetSegment (in _waynetwork.py) for every way-section and used for the subtraction of the ways from the graph-cycles. PyGEOS provides a function buffer() to do that. But the result is a polygon, as shown below for different types of join styles, with a clockwise ordering of the vertices. Is there a special intention for the ordering you propose or could these already existing polygons be used?

[vvoovv]

Is there a special intention for the ordering you propose or could these already existing polygons be used?

1) The specific order is required to assign UV coordinates for the texture like this

2) The specific order is required to create a non-flat road profile for the given road section. An example of the non-flat road profile:

But there is no need to change the order of the vertices if it involves a reordering of Python lists. It would be enough to get the index offset.

[vvoovv]

as shown below for different types of join styles

Why isn't the join style bevel or round created for the vertices 7 and 6 (the bevel style) and for the vertices 9 and 8 (the round style)?

[polarkernel]

Why isn't the join style bevel or round created for the vertices 7 and 6 (the bevel style) and for the vertices 9 and 8 (the round style)?

Don't know, this is what PyGEOS provides. The only parameter to change is the resolution for the round join style (vertices per quadrant). There are also different cap-styles (flat, square, round), which may be helpful to join different sections, because the overlap may be better then. But these do not influence the inner turns.

[vvoovv]

It will be needed to assign UV-coordinates to the vertices of the road polygon.

The U-coordinate for the vertices located to the left from the road centerline is equal to zero. The U-coordinate for the vertices located to the right from the road centerline is equal to 1.

The V-coordinate for the vertices 1L and 1R from the first message is equal to zero.

To calculate the V-coordinate for the other vertices it's required to calculate the total length of the preceding segments of the road centerline. For example, for the vertices 3L and 3R the required length is equal to the sum of the lengths of the segments 1-2 and 2-3.

I can calculate that once the road polygon with its centerline is provided

[vvoovv]

Don't know, this is what PyGEOS provides.

Since the number of additional vertices created for each corner is variable, a more complex data structure is required.

The following Python list is proposed. The number of elements in the list is equal to the number of vertices in the road centerline. Each element of the list is a Python tuple with the following elements:

1) The index of the vertex that is the left counterpart of the centerline vertex. For example, the left counterpart of the centerline vertex 2 is 2L. 2) The number of additional vertices before that vertex. The additional vertices before and after are created for rounded or beveled corners. 3) The number of additional vertices after that vertex. 4) The index of the vertex that is the right counterpart of the centerline vertex. For example, the right counterpart of the centerline vertex 2 is 2R. 5) The number of additional vertices before that vertex. 6) The number of additional vertices after that vertex.