Skip to content

Fix boundary point classification in computeLineEnds optimization (#1175)#1200

Open
grootstebozewolf wants to merge 1 commit into
locationtech:masterfrom
grootstebozewolf:bugfix/RelateNg-Boundary-Skip-1175
Open

Fix boundary point classification in computeLineEnds optimization (#1175)#1200
grootstebozewolf wants to merge 1 commit into
locationtech:masterfrom
grootstebozewolf:bugfix/RelateNg-Boundary-Skip-1175

Conversation

@grootstebozewolf

Copy link
Copy Markdown

… disjoint line components

The optimization in computeLineEnds() that skips processing of line components whose envelopes are disjoint from the target after finding one exterior intersection was incorrectly skipping boundary point classification.

Track hasInteriorExteriorIntersection and hasBoundaryExteriorIntersection separately so that we only skip when both kinds of exterior line-end intersections have been recorded. This ensures boundary endpoints on later disjoint components (e.g. odd-valence ends in a MultiLineString) are still processed and reported in the DE-9IM matrix (position 7, EB).

  • Refactor computeLineEnds() + computeLineEnd() to use two booleans and return the line-end location (INTERIOR/BOUNDARY/NONE) instead of a simple boolean.
  • Add the exact reproduction case from the issue as testLineDisjointMultiLineWithBoundaryInExterior_JTS1175() exercising relate() + the various predicate helpers.
  • Update history.

Reported by peterstace; reproduction:
g1 = LINESTRING(10 10,20 20) g2 = MULTILINESTRING((0 0,1 0),(1 0,2 0),(-1 0,0 0)) Expected: FF1FF0102 (EB='0'), was FF1FF01F2 (EB='F')

(cherry picked from commit 2991049,
isolated to just the RelateNG boundary skip changes)

… disjoint line components (locationtech#1175)

The optimization in computeLineEnds() that skips processing of line components
whose envelopes are disjoint from the target after finding one exterior
intersection was incorrectly skipping boundary point classification.

Track hasInteriorExteriorIntersection and hasBoundaryExteriorIntersection
separately so that we only skip when both kinds of exterior line-end
intersections have been recorded. This ensures boundary endpoints on
later disjoint components (e.g. odd-valence ends in a MultiLineString)
are still processed and reported in the DE-9IM matrix (position 7, EB).

- Refactor computeLineEnds() + computeLineEnd() to use two booleans
  and return the line-end location (INTERIOR/BOUNDARY/NONE) instead of
  a simple boolean.
- Add the exact reproduction case from the issue as
  testLineDisjointMultiLineWithBoundaryInExterior_JTS1175() exercising
  relate() + the various predicate helpers.
- Update history.

Reported by peterstace; reproduction:
  g1 = LINESTRING(10 10,20 20)
  g2 = MULTILINESTRING((0 0,1 0),(1 0,2 0),(-1 0,0 0))
  Expected: FF1FF0102 (EB='0'), was FF1FF01F2 (EB='F')

(cherry picked from commit 2991049,
 isolated to just the RelateNG boundary skip changes)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant