如果有人可以举例说明，那就太好了。
#1 楼
这是一个很好的问题。从实现的角度以及从哲学的角度来看，Coverage，Shapefile和Geodatabase都是根本不同的地理空间数据存储。我将尝试进行总结，而不必太深入。1。覆盖范围：
覆盖范围是有趣的地理空间数据结构。他们专注于存储拓扑。因此，您将看到重点是首先存储几何元素，即构成所有几何的节点，边。然后，您将看到一组单独的表，这些表将这些几何与属性相关联（因此它们成为“特征”）。
“干净”的覆盖范围可确保规则，例如，每个节点相交处都存在节点，则彼此之间将不会有两个（或更多）节点（甚至在模糊容差范围之内），彼此之间不会有两个边等等。它们还具有方向感（从-到），并且可以区分左右方向。
覆盖范围确实很好用于需要了解拓扑关系的编辑（例如，编辑宗地边界）。此外，覆盖范围压缩得非常好，因为它们通过设计消除了几何冗余。实际上，您会发现，如今，像TopoJSON这样的现代格式开始使用了几十年前我们从覆盖范围中学到的技术。
在处理覆盖时，处理起来可能会更加复杂。 3D数据（例如，对下面具有上侧和下侧的桥进行建模）是因为我们用来处理它们的算法本质上是用于2D平面图数学的。
因此我们为什么要离开它？那将需要更长的答案，但是也许我们应该更多地解释什么使ESRI Shapefile首先流行。
2。 ESRI Shapefile：
Shapefile随之而来。它可能具有的最重要的特征是，它是（比较）易于实施的开放规范。这些属性利用了DBF文件，因此已经有许多实现该规范很大一部分的库。没有“干净”的概念，这意味着每个单独的几何图形都只需要担心表示自己而不考虑周围的几何图形或它们相交。这意味着我们不必做任何复杂的数学运算即可确定shapefile是正确的（与coverage对应项不同）。
有多个相互交叉的几何图形吗？当然不能。
两点互相重叠？成为我的客人。
有时，（最好）“最佳”格式不是获胜的格式，而是被采用的格式。如果一种格式易于实现，则采用它的机会比复杂的格式要好。那就是Shapefile。
突然之间，您有了几个支持它的库（开源和专有）以及软件供应商。所以一切都很棒。
然后显而易见的问题是-为什么选择地理数据库？
3。地理数据库：
我相信地理数据库是最被误解的地理空间数据存储之一。人们通常认为它们只是“地理空间格式”。几年前，有人问“什么是ESRI地理数据库？”。欢迎您首先阅读该内容，而不是重复我当时的回答。我会等:)
既然您已经阅读了该答案，并且知道了什么是地理数据库，那么我可以对该答案进行更多的扩展。当时，有很多研究对SQL进行优化，并编写了利用索引，列存储等（仍然存在）的查询优化器。通过在SQL数据存储的顶部构建地理数据库，我们可以免费利用所有这些研究。我们只需要关注地理空间概念，并且随着SQL数据存储变得越来越好，地理数据库也变得越来越免费。命题还不错吗？
如今，已经出现了一些针对地理空间数据的规范。关于如何替代这些技术（如果有的话）的陪审团仍然存在。但是，如果您对此主题感兴趣，我建议您阅读几年前在GIS.SE中提出的问题的答案：“是否有任何替换形状文件的尝试”
我希望这样做帮助！
#2 楼
大多数信息可以在Esri帮助和一些搜索中找到，因此我已经汇编了一些不错的文章。如何存储coverage？由于它是专有格式，因此您不会找到有关算法实现方式的任何技术规范（除非@Vince会为您提供一些启示）。
Shapefile后来出现并作为标准实现。提供了一定程度的互操作性。 《 ESRI Shapefile技术说明》包含完整的说明。
稍后将介绍地理数据库。首先是个人地理数据库（MS Access），然后是文件地理数据库（二进制加密格式）和企业（或ArcSDE）地理数据库，它们利用了ArcSDE和DBMS技术。您可以在此处阅读有关地理数据库的更多信息：地理数据库的类型和地理数据库的体系结构。
在GIS.SE上有不错的读物：是否使用文件地理数据库（* .gdb），个人地理数据库（*。 mdb）或shapefile？关于性能，执行了许多基准测试，文件地理数据库在读取/写入信息方面显示出最快的速度。个人地理数据库和shapefile的运行速度要慢得多，可能使用它们的唯一原因是支持使用某些MS Access业务逻辑或shapefile读取/转换构建的旧系统。调整DBMS时，其性能几乎与文件地理数据库一样好，但是这完全取决于存储的数据类型，网络和硬件。有关基准的更多信息，请参阅Esri系统设计策略资源（和此处）。
评论
覆盖率文件格式记录在FORTRAN SDK文档中（LAB，ARC和TXT原语，以及PAT，AAT，PAL，RAT和许多字母拼音）。大多数“算法”与文件格式无关，因此未在SDK中进行记录。
–文斯
2014年9月15日19:51
我认为个人地理数据库位于ArcSDE / SDE / SDBE地理数据库之后，而在文件地理数据库之前。
– PolyGeo♦
2014-09-15 20:14
当然在SDBE和SDE之后，但是ArcSDE的名称更改与PGDB格式发布同时进行。 FGDB后来出现了。
–文斯
2014年9月15日20:49在
丹尼尔·莫里塞特（Daniel Morisette）对覆盖率格式进行了反向工程，以使其有用，它现已成为GDAL / OGR套件的一部分。 avce00.maptools.org/docs/v7_bin_cover.html
–马特·威尔基
2014-09-17 3:36
@PolyGeo你是对的。有趣的事实：SDE支持Access数据库。您可以在ArcSDE API中看到该信息以获取连接信息：help.arcgis.com/en/geodatabase/10.0/sdk/arcsde/api/capi/…SE_DBMS_IS_JET用于MS Jet引擎en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine
–拉吉·亚瑟（Ragi Yaser Burhum）
2014-09-20 14:07
#3 楼
这些格式之间的主要区别在于要素与几何相关的方式。早在报道的鼎盛时期，编码语言就是FORTRAN，这意味着COMMON块中的缓冲区大小固定。其中最严格的限制是每线图元（“ arc”）500个顶点。这种限制引入了“伪节点”（弧仅与另一个弧连接的地方）的概念，并使许多其他数据访问操作变得复杂。覆盖模型使用了“多边形弧列表”（ PAL）来描述多边形，这需要一种多边形着色算法来读取一个文件以获得弧的列表，然后读取弧本身以获取顶点数，然后分配足够的RAM来存储所有顶点，然后返回以读取多边形再次弧，这次以正向或反向顺序复制顶点以组装完整的多边形。只有在两次访问ARC文件之后，才能充分描述多边形，然后才需要访问（沿相反方向）许多相同的弧以遮挡多边形邻居。
通过比较， shapefile和各种地理数据库格式将完整的几何图形存储为单个对象（具有有关如何物理实现对象的各种实现详细信息）。尝试编辑共享边界时，这样做有缺点，但是操作的频率明显低于多边形着色。
“整体”存储模型是coverage格式和新格式之间的主要区别，这差异是如此基础，以至于很难看到shapefile与各种地理数据库格式之间的任何真正差异。实际上，即使FGDB不使用确切的格式，也使用shapefile格式通过FGDB API访问FGDB几何，只是因为它比引入新的顶点布局更简单。
#4 楼
格式之间的另一个区别是地理数据库可以对要素类之间的关系建模。正如Ragi所指出的，覆盖对于需要了解
拓扑关系（想像地块边界）的编辑工作非常有效。
但是，这种意识只存在于一个覆盖范围内-如果您要对两个或多个覆盖范围之间的关系进行建模，则有责任编写代码来检查任何“非法”拓扑关系。
例如，如果宗地多边形不能有间隙，且宗地边界应与道路，coverage或shapefile完全对齐，则由您来验证情况是否如此，并手动修复不遵守这些规则的任何错误。
地理数据库可以选择支持拓扑对象，该对象使您可以定义数据的允许拓扑规则。重要的是，这些规则可以在地理数据库中的要素类之内和之间发生。
ArcMap中的拓扑编辑工具可帮助您查找拓扑违规，并在某些情况下自动修复它们。
在引入地理数据库拓扑之前（“好日子”），通常编写冗长而复杂的AML脚本来检测拓扑违规，然后在ArcEdit中手动编辑coverage（不是那么有趣）。 br />
评论
我认为shapefile总是用于数据共享，而不是用于主存储。在我的经验中，肯定是使用它们。一点也不。 Shapefile是ArcView 1/2 / 3.x的主要数据格式。它们肯定是一种使用格式（如果它们是传输格式，则不会在多个文件中）