正在实施地理空间数据的版本控制系统？ [关闭]

#1 楼

我们目前正在对地理数​​据库进行全面的重新设计。我不得不说，到目前为止，它们的演变已花费了20多年。我们确定了地理空间数据管理中的以下关键功能：


同时编辑
读取或写入部分数据的权限
在运行依赖数据的服务时进行热更新（事务和ACID范例）
内部和外部模式（修改内部模式不应影响服务）
存储和访问大量数据（栅格数据的千兆字节和千兆字节的矢量数据的容量）的能力
不同层之间的数据一致性（每个宗地都属于一个区域，依此类推）

我们评估了以下方法，这是我可以说的：
ESRI企业级地理数据库（ArcGIS 10.1）；与以前（SDE）几乎相同，但是大量使用了版本控制功能来处理事务。但这根本不是一个真正的企业级地理数据库，我认为SDE仅在工作组中作为地理数据服务器工作，人们在8:00 AM至8:00 PM之间工作，您可以将其脱机，然后执行维护任务，事务提交（版本协调和ESRI语音发布），复制等...如果在此数据之上构建服务，则必须处理临时数据库（已完成工作）和复制的生产数据库。这与在编程中进行构建/测试和部署几乎相同。 ESRI提供的功能丰富的软件包相当不错，但缺乏灵活性（例如，在人们工作时更改架构或进行维护任务，例如创建索引）。在我看来，它抑制了许多对我作为管理员有意义的事情。
平面文件和版本控制系统，我们选择Git（不知道已经有一个GeoGit）。哦，是的，我和我的一些朋友也来自软件工程。一切可能是如此简单。我认为这就是问题所在：就像汽车修理工在造汽车一样。对他来说，维护起来很简单，但开车去看肯定会令人讨厌，这也很烦人。我认为它还有一些主要的缺点：如何对2 TeraByte（或什至更多的二进制）Rasterdataset进行版本控制？以及哪种格式？如果您使用基于文本的格式（例如GML），则可以轻松地控制矢量数据的版本，但那时它也很难处理十亿行数据集。我仍然不确定我们是否可以进行有效的用户权限管理，因为不应该允许所有人编辑甚至查看所有内容。以及如何合并由4个用户同时编辑的矢量数据集？至少您必须是一位真正的计算机科学家/程序员才能有效地完成所有这些工作……我们的GIS用户是计划人员，勘测人员，地质学家等等。对于他们来说，像程序员一样思考版本沿袭，或者按照其预期的方式使用分支，这只是一个问题。但是，将数据存储库视为共享存储库是一个有趣的想法。
将表数据库作为简单的容器。和SDE一样，但是没有SDE东西。仍然很难维护，因为您实际上没有利用RDBMS为您提供的优势。是的，仅将所有内容加载到数据库中非常简单，但这根本不是数据管理。
Bigdata和NoSQL。与平面文件和表相同的问题。我认为一个简单的文件系统API可以在网络上使用。是的，它可以很好地在网络上运行，并且可以轻松地将文档放入其中，但是我想，如果我想对TB级（可能是栅格）数据进行空间数据分析，我希望不要序列化和反序列化通过HTTP接口。

2018年更新：这里有很多新东西创造了很多动力。仅举几例：


云块存储和HDFS
Python / shapely / Dask Stack

Apache Spark


GeoMesa / GeoWave用于矢量数据
GeoTrellis用于栅格数据









全面的经典数据库建模（带有RDBMS）。主要问题是，很难将数据简单地拖放到任何地方，并希望它能够满足当时的所有需求。但是，如果您花大量时间在数据库中指定健壮的数据模型（实际上OSM也这样做），则可以利用其所有优点。我们可以在分布式事务中编辑和更新数据，也可以修改其核心架构，而服务仍依赖于同一数据的外部架构，我们可以对其进行维护，可以检查其一致性，可以允许和拒绝权限，能够存储大量数据，而我们仍然可以快速访问它，我们能够构建历史数据模型并透明地触发它，依此类推。因为我们使用sql server，所以我们仍然缺少本机栅格类型，但是其他数据库供应商已经提供了这种类型。


我认为关系数据库模型刚刚起步最近几年（在BLOB Containers之前的年代）具有空间数据类型的空间世界，并且仍然是存储数据的最灵活，最专业的形式。这并不意味着不应使用VCS方法或NoSQL对其进行补充，但我认为这些方法更有可能是按用户组分布数据的形式，而不是作为专业的集中空间数据管理的形式。 OSM还集中了很多人无法提供的任务，例如导入大量数据（奥地利的大多数OSM数据是一天内导入，而不是众包）和切片生成。协作（众包）部分确实非常重要，但仅占业务的一半。

我认为我必须对此重新措辞，并提供更多的事实。像这样的问题很难在几个小时内得到全面回答，我将在第二天尝试提高答案的质量