我有一个查询:(此查询使用ST_Covers函数的地理实现)

SELECT ST_Covers(ST_GeoGraphyFromText('MULTIPOLYGON(((179 -89,179 89,-179 89,-179 -89,179 -89)))'),ST_GeographyFromText('POINT(20 30)'));

当我运行这个查询时,它应该返回true,但它返回false。我不知道PostGIS(或者这个查询)有什么问题
当我将地理实现更改为几何实现时,将查询重新排列为如下所示:
SELECT ST_Covers(ST_ASTEXT(ST_GeoGraphyFromText('MULTIPOLYGON(((179 -89,179 89,-179 89,-179 -89,179 -89)))')),text('POINT(20 30)'));

它正常工作,返回真值:
我可以使用下面的查询作为内容,但问题是当数据库太大时,需要花费太多时间
有人能告诉我吗
如何使查询1正常工作(按预期,返回true),或
如何使查询2快速处理大型表
(请不要建议我删除*STúU GeoGraphyFromText('MULTIPOLYGON((179-89179 89,-179 89,-179-89179-89)*),因为它只表示将被表列中的数据替换的地理数据)
查询1不起作用的其他值有(55)(1010)(10-10)等等

最佳答案

第一个查询失败,因为您使用的是geography类型,其宽度大于180°。如果它是更现实的东西,例如'MULTIPOLYGON(((100 0,100 50,0 50,0 0,100 0)))',它将返回TRUE。
没有直接的方法来找到多多边形地理类型的外圈的最大直径,但是你可以尝试用类似的东西捕捉这些特定的情况:

SELECT ST_XMax(geog::geometry) - ST_XMin(geog::geometry) AS width,
       ST_YMax(geog::geometry) - ST_YMin(geog::geometry) AS height
FROM polygons

检查那些大于180的部分,看看每个部分是否也大于180。如果是,则应视为无效地理位置。
第二个查询返回TRUE的唯一原因是,ST_AsText转换为WKT,然后将WKT重新解释为geometry类型(并隐式调用ST_Covers(geometry, geometry),而不是ST_Covers(geography, geography))。此查询速度很慢,因为它从WKB转换到WKT再转换到WKB,转换之间可能会丢失精度。更快的版本是使用::geometry将geography列转换为geometry,例如:
SELECT ST_Covers(geog::geometry, ST_SetSRID(ST_MakePoint(20, 30), 4326))
FROM polygons

几何类型使用简单的“平面地球”笛卡尔逻辑来表示STúu覆盖,这就是为什么你看到的是你所期望的。地理类型使用不同的“圆形地球”逻辑,它使用更复杂的球形逻辑,但很容易看到是否有一个地球仪方便。

关于postgresql - ST_Covers:地理实现不起作用,几何实现花费的时间太长,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/14401395/

10-16 00:49