管理大量的地理空间数据？[关闭]

您如何管理地理空间数据？我有数TB的数据散布在数百个数据集中，并且有一个临时的解决方案，该解决方案使用了项目内的符号链接，这些链接链接回每个数据集的基于域名的存档目录。这在大多数情况下都有效，但是有其自身的问题。

我也非常想知道是否有人在版本控制系统中管理其地理空间数据；我目前将一个用于我的代码和小型数据集，但不用于完整数据集。

我认为最明智的选择是将空间数据库（PostGIS，Oracle，SDE，MSSQL Spatial等）与元数据服务器（例如esri的GeoPortal或开源的GeoNetwork应用程序）结合使用，总的来说，我认为这通常是最好的解决方案。但是，您可能总是需要基于项目的快照/分支/标签。一些更高级的数据库具有管理这些数据库的方法，但是它们通常不那么容易被用户/管理。

对于您存储在数据库外部的内容（大图像，基于项目的文件），我认为关键是要具有一致的命名约定，并再次具有元数据注册表（甚至是诸如电子表格这样的低端技术）也可以跟踪它们并确保对其进行适当的管理。例如，对于基于项目的文件，这可能意味着在记录管理策略要求时将其删除，或者在项目完成时将其滚动到中央存储库中。

我已经看到了一些有趣的解决方案...

早在BC省环境部在Arc / Info范围之外运行时，他们就已经有了一个非常酷的基于rsync的双向同步过程。每天晚上将受中央控制的覆盖范围推送到各个区域，然后将区域数据推送回去。即使在超过56k的链接上，这种块级差分传输也非常有效。复制基于Oracle的属性数据库有类似的过程，但我认为它们通常在拨号方面效果不佳：)

我当前的工作场所使用类似的混合解决方案。每个数据集都有其权威副本（某些副本在Oracle中，其他副本在MapInfo中，其他副本在个人地理数据库中），并且每晚使用FME进行交叉ETL。但是，在维护方面，这里有一些相当大的开销。努力创建任何新数据集并确保组织可视性明显高于应有的水平。我们正在审查中，目的是寻找某种合并方法来避免这种开销。

到目前为止，元数据是这里最重要的问题。如果元数据回答了谁，何时何地，何处是可接受的元数据记录。

在大型公司中只有少数GIS用户（大约30名）的工作经验，我们在控制数据（特别是版本和权限）方面遇到了重大问题。一方面可以通过大量记录数据（元数据）来解决问题，另一方面可以通过中央存储库来解决其他问题，而PostGIS可以在其中存储。

GeoNetwork是处理元数据问题的良好起点。解决中央存储库更加复杂，因为可能需要专门人员来设计/维护数据库。

复杂的问题是谁将负责这些数据集及其元数据的质量检查/质量控制。尽管计算机驱动的流程效果很好，但它们不能像我在这家公司工作的那样，像一个好的数据管理器/数据保持器那样严格。现在，只有一个人可以在那里查看/提交元数据并组织不在DBMS中集中的地理空间数据。

我们使用的文件系统是按以下层次结构组织的：-地理范围（国家或大洲）-数据提供者，许可人-域/数据集-日期/版本

之后，我们制定了一项政策，将源数据（与从供应商处获得的CD / DVD格式相同的格式）与公司内部产生的任何衍生数据集区分开。

文件系统非常容易从客户那里提取任何数据，并且在物理存储方面也具有一定的灵活性-我们将档案保存在较大，较慢的磁盘上，并且我们有专用的文件服务器（透明地链接到层次结构中）用于更常用的数据集。

为了促进项目内的管理，我们使用符号链接。我们将向量保存在数据库（Oracle）中，并且每位客户至少要有一个数据库实例（以及项目的多个用户/方案）是一个规则。但是，我们并没有在数据库中保留许多栅格，因为即使在栅格外部它们也会占用太多空间。另外，我们希望数据库实例尽可能轻便。

是的，我们让某人负责整个事务的“监管”，以免混乱。

当前，使用此设置的最大问题是缺少一个不错的用户界面，这将有助于我们对整个过程有一个更好的了解，并且我们一直计划在所有内容之上包括一个元数据存储。我们仍在这里考虑我们的选择。

我们在代码中使用版本控制，并在文档中使用了版本控制，但是事实证明，版本控制并不是真正针对大型数据集的，尤其是当它们主要是二进制文件时，因此我不建议这样做，除非您要使用GML或类似类似文本的内容（问题包括服务器端磁盘使用上的巨大开销以及检出巨大存储库时客户端崩溃）。

正如@JasonBirch所说，版本控制是一个巨大的问题。

我们还发现合适的工作流程非常重要。例如，当我们收集现场数据时，我们倾向于使用登台数据库，在此数据库中，可以对现场数据进行质量检查，然后再将其合并到主数据集中。但是，根据需要进行质量检查的数据量，这总是会产生一些开销。

另外，如果您还没有看过，我建议您看一下Lars Brodersen撰写的《地理通信和信息设计》电子书，至少要了解他在数据建模方面的一些看法。

就像其他人所说的，Postgres一路走来，但是，如果您想保持它的可移植性和易于移动性，那么您总是可以考虑使用SQLite + Spatialite扩展。

就管理工具而言，它不像Postgres那样易于使用，但是QGis可以直接与启用了Spaceiteite的GIS数据库对话。

我实际上使用SQLite + Spatialite进行备份，我有一个Windows服务在后台运行（自定义编写），该服务监视我的PGSql实例，并将GIS数据镜像到驻留在外部USB驱动器上的各种SQLite DB。

PG的另一个技巧也是，使用模式

我认识的许多人只是将所有内容放到“公共”中并使用它来完成，但是如果您正确地组织数据库，则将与众不同。

例如，我的“ Ordnance_Survey”数据库具有用于VectormapDistrict VectormapLocal Topo50 LookupGrids CodePointWithPolygons CodePointOpen的架构

我将所有相关数据保存在这里。

同时，元数据表（例如几何列等）都只存在于Public中，Postgis扩展也仅在公共模式中启用，但可以从使用中的所有其他模式访问。

如前所述，空间数据库和元数据服务器是通常的设置。我认为要记住的关键一件事是“一种尺寸不能适应所有尺寸”。您最终将获得最适合Oracle，文件服务器，SQL Server等数据。我曾尝试将所有数据需求整合到一个解决方案中，但通常会失败。

期望使用适合数据的不同解决方案并为其计划。这是真正的地理门户（元数据服务器）出现的地方。

我必须同意上面的“乔治”，即元数据应该在管理地理空间数据中发挥重要作用。实际上，对于任何数字数据而言，元数据都是关键-想像一位摄影师尝试不使用适当的元数据来管理其数码照片文件。如果您虔诚地标记事物，并拥有可以利用这些数据的优质软件，那么生活将会变得更加轻松。现在，有关“管理地理空间数据”的原始问题非常广泛-可能是要存储的数据格式，命名约定，数据集和要素的层次结构，编辑角色和权限等，等等。

地理空间数据的存储模式取决于您要查询的方式/要使用的方式。以下是您可以考虑的一些工具：

Postgres + PostGIS：支持地理空间索引以及您可以想象的各种查询。要管理TB级的数据，您将需要应用分片，查询优化等。如果您的写入负载很重，那么我不建议这样做。

MongoDB：这支持大量数据。非常适合简单的存储，检索和有限的地理空间查询。

文件存储：如果您实际上只是一个归档系统，并且仅使用部分数据进行查询，那么将数据存储为文件可能是经济的。您的版本控制要求对此可能会很满意。

Redis：您可以将以上任何选项与Redis Geo支持结合使用，以在Redis中存储少量经常需要访问的“热”数据。将此视为您的缓存。