Thanks, that solved the problem but I'm guessing that very large numbers do not get indexed properly but then again if we're working with long/latitute ranges normally I guess it's not really a concern. > Add an "AND" clause that tests containment of the point > against a rectangular polygon. Or that does explict > ST_X(point) ST_Y(point) against your box. There's no way to > change the box2d behavior, and it's a feature, not a bug > (small boxes work better for large data sets, and spatial > index results are expected to be over-determined). > > P. > > On Mon, Feb 23, 2009 at 3:58 PM, Kemal Bayram > <[email protected]> wrote: > > Hello all, > > > > I'm a using PostGIS working with mainly points testing against 2d > > bounded boxes, I recently came across a problem that is > driving me nuts whereby: > > > > select makebox2d(makepoint(32.25, 34.9375), > makepoint(32.31249, 35)) > > && makepoint(32.3125, 34.996448); > > > > returns false (as expected), where as: > > > > > > select makebox2d(makepoint(32.25, 34.9375), > makepoint(32.312499, 35)) > > && makepoint(32.3125, 34.996448); > > > > returns true. > > > > 32.312499 cast as float4 is 32.3125, so I'm assuming that > internally > > single precision is being used. Is there any way change > this behaviour? > > > > Regards > > Kemal > > _______________________________________________ > > postgis-users mailing list > > [email protected] > > http://postgis.refractions.net/mailman/listinfo/postgis-users > > > > > _______________________________________________ > postgis-users mailing list > [email protected] > http://postgis.refractions.net/mailman/listinfo/postgis-users >
_______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
