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

#1 楼

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

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

我看到了一些有趣的解决方案。 。

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

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

#2 楼

到目前为止，元数据是这里最重要的问题。如果元数据回答了可接受的元数据记录是谁，何时，为什么，在何处。和权限。一方面可以通过大量记录数据（元数据）来解决问题，另一方面可以通过中央存储库解决其中的其他问题，而PostGIS正是在中央存储库中实现。 。解决中央存储库更加复杂，因为可能需要专门人员来设计/维护数据库。

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

#3 楼

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

之后，我们制定了一项政策，将我们在公司内部生产的任何派生数据集中分离源数据（格式与从供应商处获得的CD / DVD上的格式相同）。
文件系统可以非常轻松地从客户那里提取任何数据，并且在物理存储方面也具有一定的灵活性-我们将档案保存在较大，较慢的磁盘上，并且我们有特殊的文件服务器（透明地

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

是的，我们有一个负责整个过程的“策略”，因此不会太混乱。

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

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

#4 楼

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

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

#5 楼

Postgres就像其他人所说的一样，但是，如果您想使其易于携带并且易于移动，那么您总是可以考虑使用SQLite + Spatialite扩展。

不如Postgres易于使用就管理工具而言，但是QGis可以直接与启用了spacealite的GIS数据库对话。编写）来监视我的PGSql实例，并将我的GIS数据镜像到驻留在外部USB驱动器上的各种SQLite数据库中。

PG的另一个技巧也是，使用架构

我知道的人们只是将所有内容放到“公共”目录中并使用它来完成，但是如果您正确地组织数据库，则将与众不同。 br /> VectormapDistrict
VectormapLocal
Topo50
LookupGrids
CodePointWithPolygons
CodePointOpen

所有相关数据。

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

#6 楼

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

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

#7 楼

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

#8 楼

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

Postgres + PostGIS：支持地理空间索引以及您可以想象的各种查询。要管理数TB的数据，您将需要应用分片，查询优化等。如果您的写负载很重，那么我不建议这样做。非常适合简单的存储，检索和有限的地理空间查询。

文件存储：如果您实际上只是一个归档系统，并且仅使用部分数据进行查询，那么将数据存储为文件可能很经济。

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