在PostGIS中执行边界框查询？[关闭]

22

我有一个PostgreSQL表，几乎有200万行，coordinates其形式为long 字段POINT(-73.4938 33.2405)。

假设在该字段上有一个地理空间索引，那么在任意边界框内选择所有行的最有效，最快的方法是什么？

盒子就像SW long-lat: -74.0042 40.7688，NE long-lat: -73.8809 40.7984。

postgis performance geography-data-type

— Avishai
source

您存储的坐标已经是长期纬度还是网格（X，Y）？

— 马丁F

1

简单的数学就可以在这里做...如果同时point.x大于SW.x且小于NE.x，并且point.y大于SW.y且小于NE.y，则该点位于内部MBR。我不知道它是否比使用空间查询更快。你介意尝试吗？

— Michal Zimmermann 2014年

@zimmi：他实际上并没有状态的项目是刚刚点; 它们可能是复杂的几何体。

— Martin F

他们都只是点，虽然;-)。它们以存储为WKB的POINT（-73.4938 33.24059）的形式长期存在。

— Avishai

我编辑了Q（和我的A）以反映该信息。:-)

— 马丁F

24

假设给定的边界框限制与所存储的坐标位于同一空间参考系统中，并且您知道需要哪个空间算子（相交或包含）？

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)

或者，如果您更喜欢“ contains”（而不是“ contained by”）的声音，则该WHERE子句应翻转：

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

PS：鉴于（发布上述内容后，OP给出的）记录是简单的点，我认为“相交”和“包含”之间的差异变得非常微妙，仅影响边界框边缘上的点。

— 马丁·F
source

那是个很好的观点。包含应该是很好的，因为你不会真的能够看到的地图标记，如果它是在边界（即，chrome浏览器可能）。

— Avishai 2014年

What's the fastest ...?：OP

— Magno C

注意：&&和@与多边形几何相交时，似乎没有工作。在这种情况下，请使用ST_Intersects(latlng_column,ST_GeomFromText('Polygon ((...))',4326))或替代ST_Contains

— 亚历克斯（Alex）

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)

— 玛格诺C
source

1

不必说4326是SRID。

— Magno C

2

显然，我没有足够的分数来添加评论，所以我使用此答案只是说我同时尝试了ST_MakeEnvelope和“ x> min_x和x <max_x和y> min_y和y <max_y”的数学比较。 ..在我的特定bbox查询中，平均ST_MakeEnvelope花费了60ms，数学比较花费了155ms。

因此空间搜索ST_MakeEnvelope应该比数学比较快！

— 杰森
source

1

实际上，如果创建正确的索引min_x，max_x，min_y和max_y会更快。我有一个非常大的数据集（超过300万个多边形），并且都INDEX在ST_MakeEnvelope和（ST_XMax，ST_XMin，ST_YMax，ST_YMin）上进行了处理，并且两者之间的差异极大地促进了数学运算。数学花费了我不到20秒的时间（索引+查询），而信封交集花费了2分钟的时间（当到达2

— 分钟