QGIS buffer of lines results in "random" vertex order in buffer polygon

Question

I tried this topic already on QGIS dev mailing list:

I have a fairly complex geometry-(and mind-)bending workflow where I'd ideally depend on the fact that buffering a line (regular buffer, flat cap, miter join with almost infinite limit) would result in a reproducible pattern for the vertex order in the resulting buffer polygon (s. [1] for details).

I found that in 99% of the cases the first vertex of the buffered polygon will be on the left side of the original line feature's second vertex (which is great). That's confusing, not sure how else to put it, but see this image for viz, showing the vertex order of the original line features and the resulting polygon features:

However, on a few occasions this assumption doesn't seem to hold and the first vertex of the buffer polygon will be anywhere with respect to the original line feature's first vertex and does not follow any pattern at all, s. [2] for a WKT example in EPSG:25832 and buffered with 0.3 m (it's too long for an image). On this feature, vertex 0 of the polygon feature is on the left side of vertex 14 of the line feature, not next to vertex 2 as for all other line features I buffered.

My question is: is that expected behavior that buffer feature vertices can start at a sorta random place with respect to the line feature's first vertex? Or can this be considered a minor bug?

[1] I want only one side of the buffered geometry and need to somehow rotate the buffer vertex list so that the first vertex is related to the first vertex of the line feature. I can't use singleSidedBuffer() because that is much more likely to produce weird artifacts on sharp kinks in the line geometry

[2] The WKT of a feature where it's not working as I'd expect (in EPSG:25832, buffered with 30 centimeters, flat cap, miter join and 100m miter limit): LineString (567128.05779425 5674382.50117657, 567124.28299077 5674385.77951107, 567121.44049412 5674387.67067814, 567113.39428435 5674393.02397452, 567089.71334818 5674408.77935169, 567075.32187873 5674418.35427, 567048.09794292 5674433.92388853, 567047.26883028 5674434.39806565, 567046.22311791 5674435.0838905, 567043.6035418 5674436.80192543, 567006.05562972 5674453.08412973, 566973.94524544 5674467.01295346, 566941.83486115 5674480.9417772, 566930.00051817 5674486.07016386, 566929.97872742 5674486.07960683, 566929.33462488 5674485.86262721, 566904.04808487 5674477.3443191, 566871.1140052 5674462.85053673, 566838.17992554 5674448.35675436, 566797.46760646 5674431.84405364, 566756.75528738 5674415.33135292, 566716.04296829 5674398.8186522, 566675.33064921 5674382.30595149)

Answer 1

There is a discussion about how to buffer polygons in https://stackoverflow.com/questions/1109536/an-algorithm-for-inflating-deflating-offsetting-buffering-polygons. Typically the algorithms create first new vertices with offset and in the second step the new polygon-like geometry is fixed into topologically correct polygon. The first phase may create self-intersections at concave parts of the geometry, holes may disappear etc. Order and number of vertices may change in the cleanup.

Order of vertices does not have an effect on how the simple feature geometries are used in GIS processes. A simple test with PostGIS shows that it considers

select ST_Equals(
ST_GeomFromText('POLYGON (( 450 450, 440 450, 440 462, 450 450 ))'),
ST_GeomFromText('POLYGON (( 440 462, 450 450, 440 450, 440 462 ))'));
Result:
true