PostGIS中计算栅格统计数据的性能


9

我正在尝试使用PostgreSQL / PostGIS计算矢量层中每个多边形的栅格统计信息(最小值,最大值,平均值)。

这个GIS.SE答案描述了如何通过计算多边形和栅格之间的交点然后计算加权平均值来做到这一点:https : //gis.stackexchange.com/a/19858/12420

我正在使用以下查询(dem我的栅格在哪里,topo_area_su_region我的矢量在哪里,并且toid是唯一的ID:

SELECT toid, Min((gv).val) As MinElevation, Max((gv).val) As MaxElevation, Sum(ST_Area((gv).geom) * (gv).val) / Sum(ST_Area((gv).geom)) as MeanElevation FROM (SELECT toid, ST_Intersection(rast, geom) AS gv FROM topo_area_su_region,dem WHERE ST_Intersects(rast, geom)) foo GROUP BY toid ORDER BY toid;

这可行,但是太慢了。我的矢量层2489k的特点,周围每个人服用90毫秒到过程-这将需要几天来处理整个层。如果仅计算最小值和最大值(这避免了对ST_Area的调用),则计算速度似乎并没有明显提高。

如果我使用Python(GDAL,NumPy和PIL)进行类似的计算,则可以显着减少处理数据所需的时间,而不是对栅格进行矢量化处理(使用ST_Intersection),可以对矢量进行栅格化。在此处查看代码:https : //gist.github.com/snorfalorpagus/7320167

我真的不需要加权平均值-“如果碰到就行了”的方法就足够了-而且我有把握地确定这是放慢速度的原因。

问题:有什么方法可以使PostGIS像这样运行?即从多边形所接触的栅格中返回所有像元的值,而不是返回精确的交集。

我是PostgreSQL / PostGIS的新手,所以也许还有其他我做不正确的事情。我正在Windows 7(2.9GHz i7,8GB RAM)上运行PostgreSQL 9.3.1和PostGIS 2.1,并按照此处的建议调整了数据库配置:http : //postgis.net/workshops/postgis-intro/tuning.html

在此处输入图片说明


1
我已经编辑了答案。我忘了说答案中的交集不太准确。
Stefan 2014年

Answers:


11

您是对的,使用ST_Intersection会显着降低查询速度。

最好不要使用多边形(您的字段)ST_Intersection裁剪(ST_Clip)栅格并将结果转储为多边形(ST_DumpAsPolygons),而不是使用它。因此,每个栅格像元都将转换为具有不同值的小多边形矩形。

为了从转储中接收最小值,最大值或平均值,可以使用相同的语句。

这个查询应该可以解决这个问题:

SELECT 
    toid,
    Min((gv).val) As MinElevation,
    Max((gv).val) As MaxElevation,
    Sum(ST_Area((gv).geom) * (gv).val) / Sum(ST_Area((gv).geom)) as MeanElevation
FROM (
    SELECT 
        toid,
        ST_DumpAsPolygons(ST_Clip(rast, 1, geom, true)) AS gv
    FROM topo_area_su_region,dem 
        WHERE ST_Intersects(rast, geom)) AS foo 
            GROUP BY toid 
            ORDER BY toid;

在语句中ST_Clip,定义栅格,栅格带(= 1),多边形以及裁切为TRUE还是FALSE。

此外,您可以avg((gv).val)用来计算平均值。

编辑

您的方法的结果越精确,但速度越慢。的组合的结果ST_ClipST_DumpAsPolygons被忽略了与它们的大小小于50%(或51%)相交的栅格单元。

CORINE土地利用交叉点的这两张屏幕截图显示了两者的区别。第一张带有ST_Intersection,第二张带有ST_ClipST_DumpAsPolygons

在此处输入图片说明

在此处输入图片说明

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.