我是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绝不会因这种常规操作而冻结或变慢。这些性能障碍令人失望，并且使我对FOSS GIS印象深刻。
这里是否缺少我想解决的瓶颈？ 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中的PostGIS属性表（记录约470万条）时也遇到了性能问题。在该线程中提出了一些建议并且没有解决问题之后，我最终向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需求。我发现后者令人难以置信。
#1 楼
如果要在QGIS中显示较大的栅格，则必须为文件系统上的tif图像或在Postgis中注册的图像构建金字塔。文件系统或Postgis中的栅格很小。用户不会注意到差异。但是-当且仅当-使用选项
-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
#2 楼
我在PostGIS的QGIS中渲染栅格时遇到了完全相同的问题（请参阅我最近的问题），我发现这篇文章很有用，并稍微增加了以下改进的栅格渲染： = 100MBmaintenance_work_mem = 100MB
但是，我完全同意，QGIS中PostGIS栅格的性能不是很好。我正在处理608个压缩的Geotiff，它们作为VRT可以很好地加载，但是在PostGIS中根本无法使用。尝试提高dbase服务器的性能，但是除此之外，我不能提供太多帮助。我也可能不得不依靠文件系统来为组织内的栅格提供服务。
评论
感谢您的评论，克里夫。我已经应用了您的一些更改，并将报告所有重大的性能改进。总的来说，我不得不说，对于可视化PostGIS栅格和加载/查询属性表，QGIS的性能令人失望。 PostGIS中的栅格性能也令人失望。文件地理数据库没有这些问题，所以我想知道这是什么问题？
–mbcaradima
15年8月16日在15:11
完全是我的观点。我花了整整一个星期的时间来尝试解决这个问题，但是却无法使其正常运行。我现在正在测试具有10个处理器和10GB内存的VM（Ubuntu服务器）。如果那仍然很迟钝，那我一定在做其他错误的事情。我也感到困惑，为什么QGIS中的WMS图层由于渲染速度较慢而基本上无法使用。因为我们俩在同一条船上，所以我们应该对此进行更多的联系。
–悬崖
15年8月16日在19:29
如果它们作为VRT加载得很好，为什么不停在那里呢？您希望这次伟大的光栅旅行有什么好处？
– Paul Ramsey
15年8月17日在22:14
我想我的答案是Paul，这正是OP在下一篇文章中所说的：“但是，那一刻，我质疑为什么要为我的GIS需求完全运行QGIS + PostGIS，尤其是当ESRI fileGDB启用栅格属性，镶嵌数据集时，以及地理数据库所促进的其他栅格操作。因此，也许我真的丢失了某些东西，或者QGIS和PostGIS无法满足我的GIS需求。我发现后者令人难以置信。”
–悬崖
15年8月18日在1:30
此外，我要说的是，我所做的分析中约有70％是基于栅格的，而我希望通过QGIS服务于我的组织的数据中约有40％是栅格数据。将所有栅格和矢量数据存储在一个数据库中才有意义，以便用户可以建立一个连接并可以访问我们整个组织的数据库。相反，我将不得不为dbase创建凭据，为文件共享创建凭据。另外，我正在认真考虑废弃QGIS并使用Geoserver构建Web应用程序（ps：始终愿意与感兴趣的人合作）。
–悬崖
15年8月18日在1:38
#3 楼
不确定是否是您的情况，但我发现-I不应与附加数据-a一起使用。 我将许多TIF文件导入到数据库中，而
-I实际上再次创建了索引，并在每个文件的表上执行analyse，这花费了10倍的时间。-I仅在创建表时使用-p选项。
评论
栅格必须在PostGIS中吗？您希望从中获得什么好处/附加功能？我发现PostGis矢量是可以接受的，并提供了多用户编辑功能，但PostGis栅格与基于文件（服务器存储）的栅格相比并没有真正的好处。很好的问题；我很有可能在评估中错过了一些好处...我认为PostGIS栅格可以通过栅格/矢量运算实现更快的栅格计算以及更好的性能。除此之外，它还具有空间数据库的优势：可靠性，可访问性，备份功能，更紧凑的存储等。在任何情况下，文件/平铺方法都不允许使用搜索功能，预先构建的金字塔，平铺和其他功能可以改善栅格的使用和可视化。
谁曾说过PostGIS栅格比什么都快？它们可能更方便（方便的SQL访问API），并且可以用于分析（同一存储桶中的栅格和矢量），但速度更快？从不。
我正在阅读有关PostGIS的书（PostGIS in Action，第二版），似乎很自然地认为在空间DB中存储shapefile的好处也会扩展到栅格。当然，考虑到他们不同的数据模型，我可以看到这种假设是完全直观的。尽管如此，栅格仍通常使用ArcGIS存储在地理数据库中，并允许构建金字塔，更快的地理处理和构建镶嵌图。在带有开源软件的工作流中，那么GIS用户应该如何使用栅格呢？顺便说一句，我会适当地打自己的脸。
GDAL驱动程序存在性能问题。因此，在2013年夏季完成了一些改进。这些改进已包含在GDAL 1.11.x中。您可以提供样本文件进行测试吗？