locationtech / locationtech/jts

Buffer with Flat endcap produces artifacts

Open
#1,028 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

type-bug
Dominant language
Java
Stars
2.2k
Forks
475
Avg merge
14d 10h
Merged PRs (30d)
1

Description

The buffer algorithm can produce poor-quality results in some cases when using Flat endcaps. This is due to internal segments of the generated buffer curve being exposed and treated as if they are segments in the "true" buffer result.

For example, buffering the following line with distance = 50 and a flat endcap produces artefacts at one end:

LINESTRING (808093.9995996356 1031226.9999978989, 808096.6118899562 1031232.5758711806, 808096.6812621497 1031232.7676136725, 808096.7511484332 1031232.968607878, 808096.8215785786 1031233.1792970612, 808096.8925499487 1031233.4013820443, 808096.9641096845 1031233.6356068694, 808097.0362306169 1031233.8847478939, 808097.1089589515 1031234.1500042612, 808097.1822851279 1031234.4341647908, 808097.2562624677 1031234.7389463335, 808097.3310746283 1031235.0641378247, 808097.4065454218 1031235.4157402441, 808097.4827179512 1031235.7963854591, 808097.5595853871 1031236.2097804327, 808097.6371261387 1031236.6600834155, 808097.7152993734 1031237.1519370684, 808097.7940396745 1031237.6904955043, 808097.8732507864 1031238.2814414294, 808097.9527984257 1031238.9309884636, 808098.0326264931 1031239.6450969164, 808098.1122589598 1031240.4324933587, 808098.1910600851 1031241.3025600321, 808098.2691304844 1031242.2604170654, 808098.3456951124 1031243.3157525676, 808098.420819779 1031244.4727475761, 808098.4934280474 1031245.7410656472, 808098.5625550003 1031247.1280863996, 808098.6276945042 1031248.6371819717, 808098.6877104894 1031250.2725644262, 808098.7413305002 1031252.0362104062, 808098.7879141825 1031253.9245093804, 808098.8256239427 1031255.9352548721)
image

In fact this can happen for any "non-round" endcap, including a round one with a low number of quadrant segments (e.g. 1).

It's not clear what the correct result should be in this case. Ideally "internal" linework should not be exposed. But a flat endcap may not entirely cover the buffer area generated by other segments in the input (which effectively have round end caps).

See also PostGIS 340, which is the same problem in a more obvious situation.
Buffering the following line with endcap = FLAT and distance = 50:

LINESTRING(2 7,3 5,5 4,7 5,8 7)

produces:
image

See #739 as well, although that may be a slightly different issue.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the buffer algorithm with the two WKT examples, using flat endcaps and the stated distances, then compare the generated geometry with the images and the related PostGIS 340 and JTS #739 reports. The intended result is not yet defined: determine how internal buffer linework should be handled without losing valid area, and establish tests for the chosen behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
computer-graphics
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.