3

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:

enter image description here

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)

2

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
3
  • Thanks for chiming in. However, that's not what I'm "worried" about. It's about the specific process of simple buffering in QGIS and how the vertex order of the resulting polygon is derived from the buffered line feature. I think there should be a pattern to it, like in the image above. The WKT in [2] is an example where that pattern from the image doesn't hold and I wonder why.. Or if it's a tiny bug. – nnolde Aug 12 '20 at 7:34
  • 1
    There is no need to care about the order of vertices in the buffered geometry because they are the same geometries anyway. I guess that QGIS starts building the buffered geometry in the same way always, but for some source geometries the first draft of the buffered geometry may have topology errors and the later process that fixes the topology can change the order of vertices. – user30184 Aug 12 '20 at 7:52
  • For my specific use case I do need to know about the order of vertices (though first time for that..). The effect of a post-fixing algo to repair first buffer drafts is a very good point though! That'd totally explain the phenomenon. Thanks! If you replace your current answer witht the comment, I'll mark as accepted. – nnolde Aug 12 '20 at 7:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.