如何使用PostGIS处理复杂的地理处理工作流程？

12

我们的组织正在考虑将地理处理工作流移至PostGIS。我们目前正在使用ArcGIS，并在ModelBuilder中使用了大量自定义Python工具。我们正在将大部分数据移至PostGIS中，以供各种应用程序使用，现在我们要问的是，在该处执行数据处理是否也有意义。

我们处理数据以使其与我们的软件兼容。客户购买了我们的软件，向我们提供了他们的数据，然后我们对其进行处理以进行优化以用于我们的软件。这就要求我们构建各种工具来处理各种质量的输入数据。我们不能期望以特定的格式或架构接收数据，因此我们构建了将输入字段映射到输出字段，将单个字段解析为多个字段，合并多个数据集等的工具。我们还执行空间连接，相交，修剪空白和连接字段以及许多其他常见操作。PostGIS似乎完全能够满足我们的所有处理需求。

对于那些使用PostGIS进行数据处理的人，您是否对组织，使用工具等有任何建议？

结合QGIS python处理使用它吗？
人们使用Python ORM进行非Web处理吗？我一直倾向于使用GeoDjango，因为它具有适用于PostGIS的Python ORM。我们使用PostGIS处理数据的初步测试在Python代码中包含许多大型SQL文本块，并且我们认为GeoDjango ORM可能有助于创建更易管理和可读的代码。还有一个GeoAlchemy ORM与PostGIS类似地交互，并且似乎不像Django那样特定于Web。

我没有听说像使用QGIS或ArcGIS的人那样使用PostGIS进行地理处理，所以我想知道它是否是可比的替代方案。

— 皮匠
source

1

您的所有流程都是“后端”吗？我不是Django或GeoDjango的用户，但我认为这些产品仅用于开发网站（恕我直言，这比他们值得的麻烦还要多）。为什么不只是一堆shell或python脚本在（当然是Unix）命令行上运行，还是定期通过“ cron”运行？（在我看来，clickey-clickey总是比较好。）您可能希望系统地组织这些活动，至少通过传入的数据流进行组织。此外，Postgis可能无需QGIS就可以对数据进行切片和切块-您要考虑哪种特定类型的操作？

— forkandwait 2013年

1

是的，我们的处理是后端。但是，我们最终将拥有一个OpenLayers网络地图，供客户查看和编辑其数据。我们可能将Django用于该应用程序的用户和管理员帐户。如果是这样的话，即使Django主要是为网站构建的，我认为这可能是研究GeoDjango进行处理的另一个原因。这个使用Django进行大规模处理的演示表明Django不仅适用于网站：slideshare.net/dibau_naum_h/large-scale-processing-with-django

— Tanner，

1

对于后端工作，我将使用PostGIS，一点点的ogr2ogr，一种脚本语言（Python，Ruby，Tcl等）和一个unix命令行。我将避免尝试将Django混入其中，除了使您的数据库尽可能与之兼容。然后，如果需要，可以在其前端放置一个前端。我的规则是：clickey更少=更高的生产率（尽管GIS分析师对clickey-clickey废话感到更满意...我的意思是“直观界面”）。

— forkandwait

关于幻灯片共享-看起来非常复杂，如果要加重处理能力以试图跟上进度，这可能是适当的，否则会带来噩梦。

— forkandwait

1

您可能会发现几个通用的etl问题会有所帮助：“ 空间ETL比较 ”和“ 是否有安全的

— fme

8

我真的很喜欢使用PostGIS进行地理处理。

我的两个主要观点是：

1）在数据库中执行复杂的任务通常会非常快，因为您可以在查询计划器的帮助下以正确的顺序执行操作。

2）只需保存您在文本文件中使用的sql行，您就可以很好地了解所做的工作。

我的工作流程（如果任务涉及很多“步骤”）通常是这样的：
1-根据任务的性质来构建查询的一部分或全部内容
2-在数据集的一小部分上测试查询以查看其性能
3-必要时进行一些调整
4-在整个数据集上运行查询
5-将带有注释的行保存在文本文件中。
所有这些通常与启动ArcGIS并等待许可证服务器中的许可证一样快。

— 尼克拉斯·阿文
source

5

我们将PostGIS和某种Python编程环境用于我们开发的许多生产地理处理Web服务。没怨言！

如果您主要（或专门）使用Web应用程序的功能，则GeoDjango是一个不错的选择。它不支持PostGIS Raster或PostGIS 2.0的栅格数据类型。现在，它确实与最新版本的Django一起提供。您可以通过在Django中使用自定义的原始SQL查询来弥补对栅格支持和整体稳定性的缺乏。

对于更强大的地理处理应用程序，特别是如果您要使用对象关系模型，请尝试使用GeoAlchemy2。原始的GeoAlchemy库扩展了SQLAlchemy，提供了对要素数据的支持。GeoAlchemy2通过为PostGIS 2.0中的新栅格数据类型提供（有限）支持来扩展它。

然后，总是存在GDAL和OGR的Python绑定！

— 亚瑟
source

YMMV，但我发现对象关系库实际上并未向普通的旧SQL添加任何内容。正如我在另一条评论中所说，听到具体情况将是最有趣的。

— forkandwait 2013年

4

我可以描述一个案例研究：一个Web服务，用于为火灾后侵蚀模型生成栅格输入。基本上，许多栅格需要成为子集并相互添加。我选择了GeoAlchemy2（GA2）来与存储数据的PostGIS接口。使用GA2，我可以创建紧凑的，可重复使用的PostGIS查询。一个查询将创建“已烧土地覆盖”产品（土地覆盖的重分类，子集）。某些建模需要单独使用此产品，但也需要将其添加到另一个栅格（土壤层）中，以生成第三种输出产品。GA2让我可以在Python中混合，匹配和序列化。

— 亚瑟

3

尽管可能，但很难想象您会在数据库引擎或Web框架内进行大量地理处理。我建议您查看基础代码库-geos，proj.4和gdal。这三个都有Python绑定或库。另一个可供选择的选择是用于QGIS的Sextante地理处理插件，因为它允许构建模型/工作流。

其他一些想法：

不排除使用PostGIS。它提供了良好的存储和服务器功能，并通过SQL公开了一些geos和proj.4功能。它也可以与提到的其他工具配合使用：Django，QGIS和Python。

除了可能使用上述Sextante插件外，QGIS还具有很好的可视化效果，具有一些用于postgres的工具，并且还包括Python控制台。

如果您正在寻找ORM并需要Web前端，那么Django会做。如果您不介意界面不那么性感，那么管理页面将为您提供一个CRUD界面，而且工作量相对较小-如果您使用GeoDjango，甚至可以进行几何编辑。

— cro
source

2

虽然我同意一个人不使用Web框架进行地理处理，但我强烈反对一个人不使用PostGIS（或另一个数据库引擎）进行地理处理。我们需要一些细节来推动讨论，但是我使用PostGIS和SQL进行了大量的几何切片/切块和多边形点分析。

— forkandwait 2013年

2

@forkandwait哦，我同意PostGIS。但是，我给他们的印象是，他们使用许多小的脚本，它们可能会针对每个项目以不同的方式进行链接。我的目标是让他们研究基础库，以便他们可以选择最合适的环境。

— Scro 2013年

3

看一下ETL，特别是用于空间操作的FME（或开源的GeoKettle）。

我真的很喜欢使用FME，因为它创建了可视的工作流程，您可以分离出空间操作，联接，合并...的逻辑……所有内容，并且可以使用非数据库格式和不同的数据库...您可以做很多，容易，快捷。如果您有模型构建者的经验，那么您将很快找到它，此外，还有许多在线文档。

FME的唯一缺点是它要花钱。但是我认为这是值得的。

使用FME的替代方法可能是GDAL和OGR以及可能是Python将其结合在一起的方法。或者，正如您所说的，全部在PostgreSQL中完成。我认为ETL在空间数据争用中具有很强的作用，它做了很多您不能仅仅在数据库中做的事情。

我没有使用过，但是GeoServer提供了WPS的实现，但我没有使用过，但是其他人可能会评论这对您有什么用？

我无法评论使用GeoDjango，但我认为它更像是CMS，就像用于查看数据的前端一样。

— 亚历克斯·莱思
source