Opened 14 years ago
Closed 14 years ago
#558 closed defect (invalid)
ST_Intersects with Large Number of Points
Reported by: | jabts | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 1.5.2 |
Component: | postgis | Version: | 1.5.X |
Keywords: | intersects slow | Cc: |
Description
When using a simple square polygon as one of the arguments, and a linestring or multilinestring with > 15000 points as the other argument, if the query is to return true, it takes a very long time and/or doesn't return properly. Whereas if the query should return false, it returns "immediately".
This problem seems two fold, a) why it would return false quickly and not true (seems to me it should be reverse of that) and b) there is a definite scaling problem as the number of points go up.
Attached is a file with some sample linestrings and issues that led to this.
Attachments (1)
Change History (2)
by , 14 years ago
Attachment: | postgisBug.txt added |
---|
comment:1 by , 14 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
The function can return false immediately if the bounding boxes to not intersect. Unless you have a suggestion on how to improve performance, this doesn't seem like a bug to me, it seems expected: more points to test take longer to test. If you have large linestrings (geographically) and small boxes, a simple way to improve performance is to "denormalize" your lines: chop them into about 400-vertex segments per object and duplicate the attributes or provide a look-up table between them. That way the index can have more effect in choosing the "right" line segments to test with a particular box.