22

I have a PostgreSQL table, with almost 2 million rows, with a long-lat coordinates field in the form POINT(-73.4938 33.2405).

Supposing there's a geospatial index on that field, what's the most efficient, fastest way to select all the rows within an arbitrary bounding box?

The box is like SW long-lat: -74.0042 40.7688, NE long-lat: -73.8809 40.7984.

closed as off-topic by PolyGeo May 24 '18 at 6:34

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking help to debug/write/improve code must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Providing a clear problem statement and evidence of a code attempt will help others to help you. See: How to create a Minimal, Complete, and Verifiable example." – PolyGeo
If this question can be reworded to fit the rules in the help center, please edit the question.

  • Are your stored coordinates already long-lat or are they grid (X, Y)? – Martin F Jan 17 '14 at 21:38
  • 1
    Simple mathematics would do here... If point.x is bigger than SW.x and smaller than NE.x and point.y is bigger than SW.y and smaller than NE.y at the same time, the point lies inside the MBR. I do not know whether it is faster than using spatial query though. You mind to try? – Michal Zimmermann Jan 18 '14 at 8:44
  • @zimmi: He doesn't actually state that the items are just points; they could be complex geometries. – Martin F Jan 18 '14 at 18:00
  • They are just points, though ;-). They're long-lat in the form POINT(-73.4938 33.24059) stored as WKB. – Avishai Jan 19 '14 at 18:40
  • I edited the Q (and my A) to reflect that info. :-) – Martin F Jan 20 '14 at 18:19
24

Assuming the given bounding box limits are in the same spatial reference system as the stored coordinates, and you know which spatial operator (intersects or contained by) you need:

SELECT *
FROM   my_table
WHERE  coordinates 
    && -- intersects,  gets more rows  -- CHOOSE ONLY THE
    @ -- contained by, gets fewer rows -- ONE YOU NEED!
    ST_MakeEnvelope (
        xmin, ymin, -- bounding 
        xmax, ymax, -- box limits
        my_srid)

Alternatively, if you prefer the sound of "contains" (instead of "contained by") the WHERE clause should be flipped:

WHERE  ST_MakeEnvelope (...)
    ~ -- contains, gets same fewer rows 
    coordinates 

PS: Given (by OP after the above was posted) that the records are simple points, I think that the difference between "intersects" and "containment" becomes very subtle, affecting only the points on the edges of the bounding box.

  • that's a good point. Contains should be fine, since you won't really be able to see a map marker if it's on the boundary (ie, the browser chrome probably). – Avishai Jan 20 '14 at 18:36
  • What's the fastest ...? : OP – Magno C Dec 12 '16 at 15:53
  • Be aware: && and @ don't seem to work when intersecting with polygon Geometry. In this case, use ST_Intersects(latlng_column,ST_GeomFromText('Polygon ((...))',4326)) or alternatively ST_Contains – Alex Feb 1 '18 at 11:50
4
SELECT ST_Y(the_geom) AS latitude, ST_X(the_geom) as longitude
from units u where the_geom && ST_MakeEnvelope(left, bottom, right, top, 4326)
  • 1
    Not necessary to say 4326 is the SRID. – Magno C Jan 17 '14 at 17:01
2

Apparently, I don't have enough points to add a comment so I am using this Answer just to say that I tried both ST_MakeEnvelope vs the maths compare of "x > min_x and x < max_x and y > min_y and y < max_y" ...on average ST_MakeEnvelope took 60ms and maths compare took 155ms on my particular bbox query.

So the spatial search ST_MakeEnvelope should be faster than maths compare!

  • 1
    Actually, if you create the right indexes min_x, max_x, min_y and max_y will be much faster. I have a very large dataset (over 3 million polygons) and did both INDEX over ST_MakeEnvelope and (ST_XMax, ST_XMin, ST_YMax, ST_YMin) and the difference is hugely in favor to math. Math took me less than 20s (INDEX + Query) while Envelope intersection took over 2min (I gave up when it reached 2min, 40s only for Spatial indexing) – caiohamamura Jul 3 '17 at 18:15

Not the answer you're looking for? Browse other questions tagged or ask your own question.