ArcGIS中的Coverage，Shapefiles和Geodatabase有什么区别？

我想知道ArcGIS中Coverage，Shapefiles和Geodatabase使用的空间数据存储方法的差异。覆盖率是最初的格式，其次是形状文件，现在是地理数据库。那么，这些较新的Shapefile和Geodatabase格式有何改进？

如果有人可以举例说明，那就太好了。

这是一个很好的问题。从实现的角度以及从哲学的角度来看，Coverage，Shapefile和Geodatabase都是根本不同的地理空间数据存储。我将尝试进行总结而不至于太深。

1.覆盖范围：

覆盖范围是有趣的地理空间数据结构。他们专注于存储拓扑。因此，您将看到重点是首先存储几何元素，即构成所有几何的节点，边。然后，您将看到将这些几何与属性相关联的一组单独的表（因此它们“成为”要素）。

一个“干净”的覆盖面，保证一定的规则，例如，有在每一个节点路口的节点，你不会有两个（或更多）（或者甚至在一个模糊容差距离）在彼此的顶部节点，有没有两个边缘彼此重叠，等等。它们也具有方向感（从->到），可以区分其左侧和右侧。

对于需要了解拓扑关系的编辑（想像地块边界的编辑），覆盖范围确实非常有效。另外，覆盖范围压缩得很好，因为它们通过设计消除了几何冗余。实际上，您会发现，如今，像TopoJSON这样的现代格式开始使用我们几十年前从覆盖范围中学到的技术。

当您处理3D数据时（例如，对桥的上侧和下侧都在下面建模），覆盖范围的处理可能会更加复杂，因为我们过去用来处理它们的算法本质上是指用于2D 平面图数学。

那么为什么我们要离开它呢？那将需要更长的答案，但是也许我们应该更多地解释什么使ESRI Shapefile首先流行。

2. ESRI Shapefile：

Shapefile随之而来。它可能具有的最重要的特征是，它是（比较）易于实现的开放规范。这些属性利用了DBF文件，因此已经有很多库实现了规范的很大一部分。没有“干净”的概念，这意味着每个单独的几何图形都只需要担心表示自己而不考虑周围的几何图形或它们相交的几何图形。这意味着我们不必做任何复杂的数学运算即可确定shapefile是正确的（与coverage对应项不同）。

有多个相互交叉的几何？当然可以。彼此重叠两点？别客气。

有时，（可以说）“最佳”格式不是获胜的格式，而是被采用的格式。如果一种格式易于实现，则比复杂的格式更容易采用。那就是Shapefile。

突然之间，您有了几个支持它的库（开源和专有的）和软件供应商。所以一切都很好。

显而易见的问题是-为什么选择地理数据库？

3.地理数据库：

我相信地理数据库是最被误解的地理空间数据存储之一。人们通常认为它们只是“地理空间格式”。几年前，有人问“什么是ESRI地理数据库？” 。欢迎您首先阅读该内容，而不是重复我当时的回答。我会等 ：）

既然您已经阅读了该答案，并且知道了什么是地理数据库，那么我可以对该答案进行更多的扩展。当时，有许多研究对SQL进行优化，并编写了利用索引，列存储等（仍然存在）的查询优化器。通过在SQL数据存储的顶部构建地理数据库，我们可以免费利用所有这些研究。我们只需要关注地理空间概念，并且随着SQL数据存储变得越来越好，Geodatabase也变得免费了。不错的建议吧？

如今，出现了几种针对地理空间数据的规范。关于如何替代这些技术（如果有的话）的陪审团仍然存在。但是，如果您对此主题感兴趣，我建议阅读几年前在GIS.SE中提出的问题的答案：“是否有任何尝试替换形状文件的尝试”

我希望这有帮助！

大多数信息都可以在Esri帮助和一些搜索中找到，所以我已经汇编了一些不错的文章。

险种如何存储？由于它是专有格式，因此您不会找到有关算法实现方式的任何技术规范（除非@Vince会有所启发）。

Shapefile随后出现并被实现为提供一定程度互操作性的标准。ESRI Shapefile技术说明包含完整说明。

地理数据库将在稍后介绍。首先是个人地理数据库（MS Access），然后是文件地理数据库（二进制加密格式）和企业（或ArcSDE）地理数据库，它们利用了ArcSDE和DBMS技术。你可以阅读更多关于地理数据库的位置：地理数据库的类型和地理数据库的架构。

精读GIS.SE：是使用文件地理数据库（* .gdb），个人地理数据库（* .mdb）还是shapefile？

关于性能，执行了许多基准测试，文件地理数据库在读取/写入信息方面显示出最快的速度。个人地理数据库和shapefile的运行速度要慢得多，可能使用它们的唯一原因是支持旧系统，这些系统是在考虑了某些MS Access业务逻辑或shapefile读取/转换的情况下构建的。

调整DBMS时，基于ArcSDE的地理数据库的性能通常与文件地理数据库的性能几乎相同，但是这完全取决于存储的数据类型，网络和硬件。有关基准的更多信息，请参阅Esri系统设计策略资源（和此处）。

这些格式之间的主要区别在于要素与几何相关的方式。早在报道的鼎盛时期，编码语言就是FORTRAN，这意味着COMMON块中的缓冲区大小固定。其中最严格的限制是每条线图元（“ arc”）500个顶点。这一限制引入了“伪节点”（伪弧仅与另一个弧相连的地方）的概念，并使许多其他数据访问操作变得复杂。

覆盖模型使用“多边形弧列表”（PAL）来描述多边形，这需要一种多边形阴影算法来读取一个文件以获得弧列表，然后读取弧本身以获取顶点计数，然后分配足够的RAM来存储所有顶点，然后返回以再次读取弧，这次以正向或反向顺序复制顶点以组装完整的多边形。只有在两次访问ARC文件之后，才能充分描述多边形，然后才需要访问许多相同的弧（沿相反的方向）以对多边形邻居进行着色。

相比之下，shapefile和各种地理数据库格式将完整的几何图形存储为单个对象（具有有关如何物理实现对象的各种实现细节）。尝试编辑共享边界时，这具有缺点，但是该操作的频率远低于多边形着色。

“整体形状”存储模型是coverage格式和新格式之间的主要区别，而且这种区别是如此基础，以至于很难看到shapefile和各种地理数据库格式之间的任何实际区别。实际上，即使FGDB不使用确切的格式，也使用shapefile格式通过FGDB API来访问FGDB几何图形，只是因为它比引入新的顶点布局更简单。

格式之间的另一个区别是地理数据库可以对要素类之间的关系进行建模。正如拉吉指出的那样，

对于需要了解拓扑关系的编辑（想像地块边界的编辑），覆盖范围确实非常有效。

但是，这种意识仅存在于一个覆盖范围内 -如果您要对两个或多个覆盖范围之间的关系进行建模，则有责任编写代码来检查任何“非法”拓扑关系。

例如，如果宗地多边形不能有间隙，且宗地边界应与道路，coverage或shapefile完全对齐，则由您来验证情况是否如此，并手动修复不遵守这些规则的任何错误。

地理数据库可以选择支持拓扑对象，该对象可让您定义数据的允许拓扑规则。重要的是，这些规则可以在地理数据库中的要素类之内和之间发生。

ArcMap中的拓扑编辑工具可帮助您查找拓扑违规，在某些情况下还可以自动修复拓扑违规。

在引入地理数据库拓扑之前（“过去的美好时光”），通常编写冗长而复杂的AML脚本来检测拓扑违规，然后在ArcEdit中手动编辑coverage （并不是那么有趣）。