create table corine00 as
select st_union(the_geom) as the_geom,
sum(area_ha) as area_ha,
substr(code_00,1,2) as code_00
from clc00_c31_forests
group by substr(code_00,1,2)
注意:所有森林代码均以'31开头',而我使用的是PostGIS 1.4,GEOS版本:3.2.0-CAPI-1.6.0
#1 楼
ST_MemUnion()将运行一个幼稚且对内存友好的进程。如果问题很小,您可以尝试这样做,它可能会在合理的时间内完成。您也可以将问题分成两半,然后一起进行。由于结果的点数比输入的点数少得多,因此您可以通过这种方式将整个问题拟合到内存中。或在两半上使用快速的内存饥饿例程,在最终合并时使用较慢的例程。#2 楼
我相信ST_Dump是您想要的:ST_Dump:
返回一组geometry_dump
(geom,path)行,这些行构成了
几何g1...。例如,它可以
用于将MULTIPOLYGONS展开为
POLYGONS ....
因此,您的情况是:
SELECT (ST_Dump( ST_Union( the_geom ) )).geom
FROM clc00_c31_forests
GROUP BY substr(code_00,1,2)
我不确定它如何与您尝试做的表创建交互,但是它应该为您提供几何形状作为单独的条目。然后,您将能够在两个表之间进行空间联接(使用&&和ST_Contains),以将数据收集到几何体上。
评论
注意:仅当您处理了ST_Union的内存问题时,这才有用! :)
– yhw42
2010年8月27日16:08
#3 楼
您的PostGIS是否针对GEOS 3.1.0+编译?对于该版本,实现了更快的级联联合,但是如果找不到,将使用旧代码,速度要慢几个数量级。更新:看起来您的PostGIS正在使用级联联合方法,但是内存匮乏是真实的。我会尝试增加Postgres实例的可用内存,这是Paul Ramsey在2007年FOSS4G PostGIS演讲中提出的一些建议:
磁盘访问速度很慢,因此可以通过使用更多磁盘来获得更高的性能。内存以缓存数据!
增加
shared_buffers
物理RAM-操作系统需要* 75%
内存中的排序速度更快
/>
增加
work_mem
磁盘清理更快,内存更多
增加
maintenance_work_mem
>按连接分配
也
增加
wal_buffers
增加
checkpoint_segments
减少
random_page_cost
在您的情况下,我尝试增加
shared_buffers
,一般建议是数据库服务器可用内存的25%,但尝试将其增加到当前值的3-4倍,看看是否完成。评论
postgis_geos_version()返回:3.2.0-CAPI-1.6.0 ...我想很好。会尝试ST_Collect,谢谢。
– Underdark♦
10年8月23日在7:49
好吧,ST_Collect似乎并没有消除任何边界,它还创建了一个巨大的Multipolygon。
– Underdark♦
10年8月23日在8:16
是的,我误读了ST_Collect的页面。我已经更新了答案,以提供更具体的建议来调整Postgres的内存使用情况。
– scw
10年8月23日在20:38
评论
Paul,谢谢您带给您无与伦比的专业知识,真是太好了。
–fmark
2010年8月26日在23:15
谢谢,看来我的问题还不够小。 ST_MemUnion()现在已运行24小时。我将尝试解决问题。
– Underdark♦
2010年8月30日在20:23