[postgis-devel] [PostGIS] #253: Gist causes wrong result from ~=
PostGIS
trac at osgeo.org
Thu Oct 1 04:37:56 PDT 2009
#253: Gist causes wrong result from ~=
----------------------+-----------------------------------------------------
Reporter: nicklas | Owner: pramsey
Type: defect | Status: new
Priority: medium | Milestone: postgis 1.5.0
Component: postgis | Version: 1.4.X
Resolution: | Keywords:
----------------------+-----------------------------------------------------
Comment (by robe):
Well it does appear to be something amiss in our PostGIS 1.4. I tried
your example on a PostgreSQL 8.2 windows install. The 1.3 returns no
results as expected but the 1.4 returns the same absurd results you have
just described.
One database running 1.3 and another running 1.4. I think its our removal
of RECHECK that is doing it. So maybe its not a bug in postgis, but our
removal of RECHECK may be exposing a bug in GIST.
I haven't tried yet on PostgreSQL 8.4, but on my PostgresSQL 8.2, if I
create a new spatial database with 1.4, but instead switch the operator
classes definition to this
{{{
CREATE OPERATOR CLASS gist_geometry_ops DEFAULT
FOR TYPE geometry USING gist AS
OPERATOR 1 <<,
OPERATOR 2 &<,
OPERATOR 3 &&,
OPERATOR 4 &>,
OPERATOR 5 >>,
OPERATOR 6 ~= RECHECK,
OPERATOR 7 ~,
OPERATOR 8 @,
OPERATOR 9 &<|,
OPERATOR 10 <<|,
OPERATOR 11 |>>,
OPERATOR 12 |&>,
FUNCTION 1 lwgeom_gist_consistent(internal, geometry, integer),
FUNCTION 2 lwgeom_gist_union(bytea, internal),
FUNCTION 3 lwgeom_gist_compress(internal),
FUNCTION 4 lwgeom_gist_decompress(internal),
FUNCTION 5 lwgeom_gist_penalty(internal, internal, internal),
FUNCTION 6 lwgeom_gist_picksplit(internal, internal),
FUNCTION 7 lwgeom_gist_same(box2d, box2d, internal)
}}}
Then the problem goes away.
--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/253#comment:2>
PostGIS <http://trac.osgeo.org/postgis/>
PostGIS
More information about the postgis-devel
mailing list