Hi, To complete Hugues' answer, it may be due to the && operator that operates on geometry extents, which are an approximation, if I recall correctly. But when running a true contains test, the answer is correct:
select st_intersects(ST_MakeEnvelope(-105.17353271032549,39.798766541338225,-105.07765728967452,39.83016145866177,4326), st_setsrid(ST_MakePOint(-105.130637 ,39.830165),4326)); st_intersects --------------- f The && operator is mainly used to trigger geometric index use. Index over estimate the geometry a bit. Nicolas On 2 February 2013 09:14, Francois Hugues <[email protected]> wrote: > ** > Hi, > > I think this is a tolerance issue. If you try > > select > st_distance(ST_MakeEnvelope(-105.17353271032549,39.798766541338225,-105.07765728967452,39.83016145866177,4326), > st_setsrid(ST_MakePOint(-105.130637 ,39.830165),4326)) > > The distance is very short : 3.54133823066149e-06 > > And i you add the where clause, it is also true that your lat is not <= to > the given one, so the single line returned with the simple && query is now > excluded. > > Hugues. > > ------------------------------ > *De :* [email protected] [mailto: > [email protected]] *De la part de* Pavel Shub > *Envoyé :* samedi 2 février 2013 07:14 > *À :* [email protected] > *Objet :* [postgis-users] (no subject) > > Hi all, > > Please tell me if I'm doing something incorrectly, but I seem to be > getting wrong results for the following bounding box query: > > select * from geotest where geom && > ST_MakeEnvelope(-105.17353271032549,39.798766541338225,-105.07765728967452,39.83016145866177,4326) > > Given table with columns: name (varchar), lat (double), lon (double), geom > (geometry). geom having srid 4326 points > > A row with lat = 39.830165, lon = -105.130637 is returned. I find this > very peculiar because the latitude is greater than the maxiumum latitude in > the envelope (39.83016145866177). If I then add a 'and lat <= > 39.83016145866177' clause, the row is no longer returned. > I noticed this on postgres 9.1 with postgis 1.5 then when testing again > got the same results on postgres 9.2 and postgis 2.0 > > Is this intended and I missed some documentation somewhere, or is this an > issue? > > Thank you, > Pavel Shub > > _______________________________________________ > postgis-users mailing list > [email protected] > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users > >
_______________________________________________ postgis-users mailing list [email protected] http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
