在PostGIS中存储大型栅格并在QGIS中进行可视化会降低性能

我的问题是与PostgreSQL，PostGIS，QGIS和GDAL一起使用的几种软件工具的使用和性能有关。

我是ArcGIS，Python和R的长期用户，他对使免费开源GIS生态系统和Linux多样化感兴趣。最近，我对将QGIS（版本2.8）与PostgreSQL（版本9.4）和PostGIS（版本2.1）一起使用非常感兴趣，并且我已在装有Windows 8.1 x64的计算机上安装了该软件（简要的计算机规格：ThinkPad配备2.1GHz核心2、8GB RAM和240GB SSD的X200）。学习了如何管理空间数据（价值约100GB）后，我想在此计算机上运行Ubuntu。

目前，我只是试图可靠地存储和检索shapefile和栅格。到目前为止，我已经成功地将shapefile加载到PostGIS中，但是栅格被证明存在更多问题。我已经成功完成了小的geoTIFF和GRID文件的单次和批量导入，但是较大的栅格（例如，磁盘上大小为870MB的15619x14655单元IMG或TIFF文件）需要永久加载到PostGIS中。我已经阅读并配置了raster2pgsql工具，以使用以下参数构建空间索引并通过图块加载栅格：

raster2pgsql -s 3161 -C -I D:\PostGIS_data\dem.img -t auto raster.dem | psql -h localhost -U postgres -p 5432 -d postgres

导入性能仍然很差，并且硬件不是问题。QGIS中PostGIS栅格的可视化甚至更糟，充其量只能缓慢加载小栅格或完全冻结。像我提到的那样的大型栅格无法在QGIS中可视化。从文档和论坛讨论中，该缺陷似乎是由于GDAL的PostGIS栅格驱动程序而不是QGIS本身引起的。论坛讨论中简要提到了这个问题，甚至有人建议不应将栅格存储在PostGIS中（空间数据库中不能平滑处理栅格的意义是什么？）。但是，我通常使用ESRI的文件地理数据库来快速，轻松地存储，可视化和分析相当大的栅格（〜70GB），而ArcGIS 10.1绝不会因这种常规操作而冻结或变慢。

这里有我想念的东西吗？我还没有解决瓶颈？PostgreSQL是否需要进行调整以实现PostGIS的性能优势？我是否缺少寻找和编译所需的GDAL版本？如何改善Shapefile和栅格的QGIS中的PostGIS性能和可视化？如何通过Linux终端享受全面，快速的空间数据管理的荣耀？在这个问题上的任何帮助都将受到欢迎！

我按照Duncan Golicher的指南进行操作：https：//duncanjg.wordpress.com/2012/11/20/the-basics-of-postgis-raster/

我最初使用的是具有自动设置的图块，但我将图块重置为每行100x100个像元，然后按照指南中的说明添加了金字塔，如下所示：

raster2pgsql -s 3161 -d -C -I -M -l 4 D:\PostGIS_data\dem.img -t 100x100 raster.dem100 | psql -h localhost -U postgres -p 5432 -d postgres

我能够在适当的时间成功导入870MB IMG栅格并将其显示在QGIS中，而不会减慢或崩溃应用程序。渲染时间没有我期望的那么快，但是可以接受。我将进一步阅读-l参数以正确使用它。

顺便提及，在将dem.img文件作为dem100表导入时，创建了另一个栅格表，称为“ o_4_dem100”。当我将其导入为QGIS中的图层时，它的值范围在201到524之间，而dem100图层的值范围在36到524之间。我是否正确地假设这个额外的表是金字塔表，该表的范围更窄聚合到较低分辨率会导致值范围变大？

我不认为硬件不足是问题所在。这是到目前为止我发现的简短摘要。

GDAL的PostGIS栅格驱动程序存在过往的性能问题（另请参见此处）。尽管在2012年注意到了这些问题，但我想知道QGIS 2.8中发现的GDAL 1.11.2是否仍然存在此问题。当然还有其他人使用QGIS和PostGIS进行栅格可视化和存储吗？

关于一个可能的相关注释，在QGIS中打开具有约470万条记录的表的PostGIS属性表时，我也遇到了性能问题。在该线程中提出了一些建议并且没有解决问题之后，我最终向QGIS提交了一个错误报告，该报告最终被关闭并链接到以下类似的错误报告。尽管错误报告已关闭，但似乎尚未修复...

总结到目前为止的工作：

我已经针对空间数据优化了PostgreSQL服务器。
我为几何表建立了空间索引并执行了VACUUM。
打开大型属性表（约470万条记录）的QGIS行为似乎尝试读取所有记录，而不是返回子集以进行即时查看。这导致性能不佳。
呈现大型PostGIS几何表的性能似乎不是问题。
使用raster2pgsql，可对栅格进行索引，平铺和导入为PostGIS中带有金字塔的栅格表。
任意大小的栅格导入PostGIS的速度仍然非常慢，更不用说在QGIS中打开和平移了。

还值得注意的是，当导入大型栅格或使用PostGIS打开大型属性表时，raster2pgsql和qgis-bin的内存消耗超过1GB。正如@Michael和@Paul在回答我的第一个问题时提到的那样，似乎PostGIS并不意味着给存储栅格带来很多好处。但是，在那一点上，我质疑为什么要为我的GIS需求而全部运行QGIS + PostGIS，尤其是当ESRI fileGDB启用栅格属性，镶嵌数据集以及地理数据库所促进的其他栅格操作时。因此，也许我确实缺少某些东西，或者QGIS和PostGIS无法满足我的GIS需求。我发现后者难以置信。

— mbcaradima
source

栅格必须在PostGIS中吗？您希望从中获得什么好处/附加功能？我发现PostGis矢量是可以接受的，并提供了多用户编辑功能，但是PostGis栅格与基于文件（服务器存储）的栅格相比并没有真正的好处。很好的问题；我很有可能在评估中错过了一些好处...

— Michael Stimson

我认为PostGIS栅格可以通过栅格/矢量运算实现更快的栅格计算以及更好的性能。除此之外，它还具有空间数据库的优势：可靠性，可访问性，备份功能，更紧凑的存储等。在任何情况下，文件/平铺方法都不允许使用搜索功能，预先构建的金字塔，平铺和其他功能可以改善栅格的使用和可视化。

— mbcaradima

我没有看到任何度量标准可以说PostGIS栅格在栅格计算上更快。.在任何情况下，使用240GB SSD（不错的选择BTW，比RAID都要快，而成本/工作量却很少），您会很快用栅格填充数据...具有LZW / Deflate压缩功能的8bit ECW / JP2或GeoTIFF可以打勾其中的大多数框，预构建的金字塔，平铺（通过VRT），文件备份等，唯一的好处就是搜索功能。我意识到我的话题有点过头了，但是如果PostGIS栅格没有按照您的期望做，那么为什么不坚持使用文件栅格进行显示呢？

— Michael Stimson

谁曾说过PostGIS栅格比什么都快？它们可能更方便（方便的SQL访问API），并且可以用于分析（同一存储桶中的栅格和矢量），但速度更快？决不。

— Paul Ramsey

我正在阅读有关PostGIS的书（PostGIS in Action，第二版），似乎很自然地认为在空间DB中存储shapefile的好处也会扩展到栅格。当然，考虑到他们不同的数据模型，我可以看到这种假设是完全直观的。尽管如此，栅格仍通常使用ArcGIS存储在地理数据库中，并允许构建金字塔，更快的地理处理和构建镶嵌图。在带有开源软件的工作流中，GIS用户应该如何使用栅格？顺便说一句，我会适当地打自己的脸。

— mbcaradima

Answers:

如果要在QGIS中显示大栅格，则必须为文件系统上的tif图像或Postgis中注册的图像构建金字塔。

文件系统或Postgis中大型栅格之间在QGIS渲染中的性能差异很小。用户不会注意到差异。但是-当且仅当-您使用选项构建金字塔-l。

如果仅导入不带-l选项的图像，或者仅导入图像-l 4 将不起作用。

例如，如果使用，-l 2,4,8,16则会创建四个金字塔等级，如下面的图层所示：

如果您希望获得更好的用户体验，则应添加更多等级的金字塔，例如-l 2,4,8,16,32,64,128,256。这将创建八层金字塔。

概括而言，此问题的答案是：导入带有选项的栅格，-l并使用与在文件系统上用于相同栅格的相同金字塔等级数。

例如：

raster2pgsql -s 3161 -d -C -I -M -l 2,4,8,16,32,64,128,256 D:\PostGIS_data\dem.img -t 100x100 raster.dem100 | psql -h localhost -U postgres -p 5432 -d postgres

— 格罗查
source

我在PostGIS的QGIS中渲染栅格时遇到了完全相同的问题（请参阅我最近的问题），我发现这篇文章很有帮助，并稍微增加了以下改进的栅格渲染：

shared_buffers = 5000MB work_mem = 100MB maintenance_work_mem = 100MB

但是，话虽如此，我完全同意QGIS中PostGIS栅格的性能不是很好。我正在处理608个压缩的Geotiff，它们作为VRT可以很好地加载，但是在PostGIS中根本无法使用。尝试提高dbase服务器的性能，但是除此之外，我不能提供太多帮助。我也可能不得不依靠文件系统为组织内的栅格提供服务。

— 悬崖
source

感谢您的评论，Cliff。我已经应用了您的一些更改，并将报告所有重大的性能改进。总的来说，我不得不说，对于可视化PostGIS栅格和加载/查询属性表，QGIS的性能令人失望。PostGIS中的栅格性能也令人失望。文件地理数据库没有这些问题，所以我想知道这是什么问题？

— mbcaradima 2015年

完全是我的观点。我花了整整一个星期的时间来尝试解决这个问题，但是却无法使其正常运行。我现在正在用10个处理器和10GB的RAM测试我的VM（Ubuntu服务器）。如果那仍然很迟钝，那我一定在做其他错误的事情。我也感到困惑，为什么QGIS中的WMS图层由于渲染速度较慢而基本上无法使用。因为我们俩在同一条船上，所以我们应该在这方面进行更多的联系。

— 悬崖

如果它们作为VRT加载得很好，为什么不停在那里呢？您希望这次伟大的光栅旅行有什么好处？

— 保罗·拉姆齐

我想我的答案是Paul，这正是OP在下一篇文章中所说的：“但是，那一刻，我质疑为什么要为我的GIS需求而全部运行QGIS + PostGIS，尤其是当ESRI fileGDB启用栅格属性，镶嵌数据集时，以及地理数据库所促进的其他栅格操作。因此，也许我真的丢失了某些东西，或者QGIS和PostGIS无法满足我的GIS需求。我发现后者令人难以置信。”

— 悬崖

此外，我要说的是，我所做的分析中约有70％是基于栅格的，而我希望通过QGIS服务于我的组织的数据中约有40％是栅格数据。将所有栅格和矢量数据存储在一个数据库中是有意义的，以便用户可以建立一个连接并可以访问我们整个组织的数据库。相反，我将必须为dbase创建凭据，并为文件共享创建凭据。另外，我正在认真考虑废弃QGIS并使用Geoserver构建Web应用程序（ps：始终愿意与感兴趣的任何人合作）。

— 悬崖

不知道这是否是您的情况，但我发现-I不应与附加数据一起使用-a。

我将许多TIF文件导入到数据库中，然后-I实际上再次创建了索引并analyse在每个文件的表上执行，这花费了10倍的时间。

-I仅在创建带-p选项的表时使用。

— 拉斐尔·乔利维特（Raphael Jolivet）
source