locationtech / locationtech/jts
Buffer with Flat endcap produces artifacts
Nobody has claimed this yet.
- 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)
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:
See #739 as well, although that may be a slightly different issue.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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