Opened 4 years ago
Last modified 3 years ago
#1025 new defect
RelateOp producing incorrect DE-9IM Matrix
Reported by: | gleng | Owned by: | strk |
---|---|---|---|
Priority: | minor | Milestone: | 3.11.0 |
Component: | Core | Version: | main |
Severity: | Unassigned | Keywords: | DE-9IM, Relate |
Cc: |
Description
It seems like geos::operation::relate::RelateOp does not respect the specified curve boundary rule when given LineStrings whose bounding boxes are disjoint, and instead uses the default Mod2 rule. If the bounding boxes intersect, the specified curve boundary rule will be correctly used.
I have attached a modified example.cpp that demonstrates the issue in GEOS 3.8.1. It can be easily run by replacing the example.cpp file located in the doc folder.
I have also tested this in PostGIS and seen the same behaviour.
Attachments (1)
Change History (4)
by , 4 years ago
Attachment: | example.cpp added |
---|
comment:2 by , 3 years ago
Milestone: | → 3.10.0 |
---|
Note:
See TracTickets
for help on using tickets.
Here are the queries needed to show this behaviour in PostGIS. The first three queries produce the correct DE-9IM matrix, but the last query does not.
Correctly Produces FF1FFF1F2:
SELECT ST_Relate(ST_GeometryFromText('LINESTRING(0 0, 1 2, 2 0, 0 0)'), ST_GeometryFromText('LINESTRING(1.5 1.5, 2.5 3.5, 3.5 1.5, 1.5 1.5)'),1);
Correctly Produces FF1FF0102:
SELECT ST_Relate(ST_GeometryFromText('LINESTRING(0 0, 1 2, 2 0, 0 0)'), ST_GeometryFromText('LINESTRING(1.5 1.5, 2.5 3.5, 3.5 1.5, 1.5 1.5)'),2);
Correctly Produces FF1FFF1F2:
SELECT ST_Relate(ST_GeometryFromText('LINESTRING(0 0, 1 2, 2 0, 0 0)'), ST_GeometryFromText('LINESTRING(3 3, 4 5, 5 3, 3 3)'),1);
Incorrectly Produces FF1FFF1F2 (expect FF1FF0102):
SELECT ST_Relate(ST_GeometryFromText('LINESTRING(0 0, 1 2, 2 0, 0 0)'), ST_GeometryFromText('LINESTRING(3 3, 4 5, 5 3, 3 3)'),2);