Opened 14 years ago
Closed 13 years ago
#962 closed defect (fixed)
ST_Within not using prepared geometries
Reported by: | strk | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.0.0 |
Component: | postgis | Version: | master |
Keywords: | Cc: |
Description
I've noticed (looking at code, not deeply testing it) that ST_Contains uses prepared geometries while ST_Within doesn't.
The two should really be the same function, only swapping args. Or am I missing something ?
Change History (4)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
I think mapping the opposite functions at the SQL level would be a good idea. We could try that and see if anything breaks or goes slower. Doing so we'd better if 0 out the C implementation to be sure we're not seeing old things in motion...
comment:3 by , 13 years ago
Confirmed with Martin that crosses/touches/relate don't figure into preparedgeometry. I'll ensure that within/crosses both are prepared.
I had a look and agree. Is there any reason to not just map within(x,y) to contains(y,x)? Either by a direct function call in the postgis C code or a change at the postgis SQL level... I wonder if there is other, similarly duplicate code in other predicates?
Are Disjoint and intersects also inverses? Because again, it looks like intersects is using prepared geoms and disjoint is not. I'm wondering if the prepgeom stuff was intentionally integrated into only half the functions, with the intention of eventually killing off the other half and remapping them over?
Save with covers (has prep) and coveredby (doesn't).
Also, overlaps, crosses, and the relate functions don't seem to use prepared geoms either, it seems like they could? Did we just not really finish implementing prepared geoms? Stopped after the first few most common cases to make sure it was actually helping?