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

并不是我现在急需一个正确的答案，而是我最近看到了一些努力来引入地理数据的“（分布式）版本控制系统”的概念。一些例子（据我所知）都是从OpenGeo（三白皮书1，2＆3）和“ Geosynkronisering（geosyncronization）”由挪威GIS软件厂商的项目和挪威测绘局。我还发现了地理空间数据的分布式版本控制？，其中提到了GeoGit（由OpenGeo提供），以及将版本控制应用于ArcGIS ModelBuilder模型？关于ArcGIS中的版本控制。

作为开发人员，我知道（至少足以使用它们）源代码的版本控制系统（例如SVN和Git）如何工作，而我在地理学方面的背景告诉我，地理数据存在一些独特的挑战，这使得这种方法与源代码（基本上是文本）的处理方式不完全相似。

在处理（d）VCS地理数据时会遇到哪些挑战，您将如何解决它们，我们是否需要它们，还有其他尝试解决这些问题的尝试，而我没有提到过？

我知道OpenGeo白皮书将回答我的一些问题，但是我真正追求的是一个更具“教学性”的答案，其风格为“告诉我我已经十岁了”，这样我可以让人们很好地解释地理数据给混合带来的挑战和解决方案。

我希望有见识的人能花点时间对此事发表一些想法，因为我说我目前不打算解决一个特定的问题，但是这个话题让我很感兴趣。

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

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

我们评估了以下方法，这是我可以说的：

1. ESRI企业级地理数据库（ArcGIS 10.1）；与以前（SDE）几乎相同，但是大量使用了版本控制功能来处理事务。但这根本不是真正的企业级地理数据库，在我看来，SDE仅在工作组中作为地理数据服务器工作，人们在8:00 AM至8:00 PM之间工作，您可以将其脱机，然后执行维护任务，事务提交（版本协调和ESRI语音发布），复制等...如果在此数据之上构建服务，则必须处理临时数据库（已完成工作）和复制的生产数据库。这与在编程中进行构建/测试和部署几乎相同。ESRI提供的功能丰富的软件包相当不错，但缺乏灵活性（例如，在人们工作时更改架构或进行维护任务，例如创建索引）。

2. 平面文件和版本控制系统我们选择Git（不知道已经有一个GeoGit）。哦，是的，我和我的一些朋友也来自软件工程。一切可能是如此简单。我认为这就是问题所在：就像汽车修理工在造汽车一样。对他来说，保养起来很简单，但是开车去看肯定会令人讨厌。我认为它还有一些主要的缺点：如何对2 TeraByte（或什至更多的二进制）Rasterdataset进行版本控制？以及哪种格式？如果您使用基于文本的格式（例如GML），则可以轻松地控制矢量数据的版本，但那时它也很难处理十亿行数据集。我仍然不确定我们是否可以进行有效的用户权限管理，因为不应该允许所有人编辑甚至查看所有内容。以及如何合并由4个用户同时编辑的矢量数据集？至少您必须是一位真正的计算机科学家/程序员才能有效地完成所有这些工作……我们的GIS用户是计划人员，勘测人员，地质学家等等。对于他们来说，像程序员一样思考版本沿袭，或者按照其预期的方式使用分支，这只是一个问题。但是，将数据存储库视为共享存储库是一个有趣的想法。

3. 平面表数据库是一个简单的容器。和SDE一样，但是没有SDE东西。仍然很难维护，因为您实际上没有利用RDBMS为您提供的优势。是的，仅将所有内容加载到数据库中非常简单，但这根本不是数据管理。

4. Bigdata和NoSQL。与平面文件和表相同的问题。我认为一个简单的文件系统API可以在网络上使用。是的，它可以很好地在网络上运行，并且可以轻松地将文档放入其中，但是我想，如果我想对TB级（可能是栅格）数据进行空间数据分析，我希望不要对它进行序列化和反序列化通过HTTP接口。

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

• 云块存储和HDFS
• Python / shapely / dask堆栈

• Apache Spark

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

• 以及更多

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

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

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