是否有任何尝试替换shapefile？[关闭]

最近，我花了很多时间将诸如“ 25岁及以上学历或更高学历的公民百分比”这样的完美字段名称转换为“ edbchogtr”这样的名称，以满足DBF的10个字符的字段名称限制。

在另一个线程中（Shapefile技术规范中的“奇数”），geospatialpython评论说：“尽管shapefile格式存在缺陷，奇异之处和局限性，但它在GIS领域及其周围仍然顽固地存在。其他任何替换它的尝试都过于肿简单的矢量存储或过于专有。”

这项活动加上劳德黑德先生的评论使我感到奇怪：

• 是否曾做过任何明确的尝试来替换shapefile作为GIS的无处不在的数据存储和交换格式？
• 有竞争者吗？
• 如果有竞争格式，为什么会失败？
• Esri是否拒绝支持他们，还是这个故事只是技术惯性之一？
• 如果没有尝试...为什么不呢？

看来我们作为GIS开发人员和用户都可以为自己做得更好。

这是一个经常出现的话题。我可能没有正确的答案，但是我可以给我我的个人意见。

支持它们的原因可以归因于它们的几个特征，所以让我列举一些。

• 首先，有一个规范。我的意思是，我30多岁就已经存在了，从我十几岁开始就存在。因此可以肯定地说，这个规范已经存在了一段时间。当然，还发布了其他几种格式，但是这种格式的不同之处在于...

• 比较简单！它建立在DBF格式的基础上，该格式当时已经存在，并且在多个平台/ OS中得到了广泛的支持。已经有解析器可以读取这种格式的一半（DBF部分），因此它使得支持额外的添加更加容易。你有几何吗？当然可以序列化并编写它。大功告成 将此与覆盖范围进行对比！尝试简单地向某人解释拓扑清理的作用。编写拓扑干净的覆盖范围并非易事。

• 最重要的是，我认为shapefile仍然受欢迎的第一原因是开放源代码系统和专有系统都支持它们。您知道哪些不支持shapefile的GIS？！？闻所未闻。

作为替代，我们听说了File GeoDatabases和Spatialite。与Shapefiles相比，这两种格式在功能，灵活性，速度等方面都极为优越。以它们自己的方式，它们具有某些使它们在不同区域彼此更好的东西，但是，对spacespaceite和FileGDB的比较肯定不在这个问题的范围内。

我是否认为这两种格式都可以替代Shapefile？不在他们当前的化身中。

为什么？

并不是因为技术上的争论（我确实说过它们在这方面要优越），而是因为其他原因：许可。

那么他们有什么问题呢？

FileGDB：

FileGDB通过新的FileGDB API提供了互操作性。但是，此API以二进制格式提供由ESRI。这不是规范。过去，我曾在GeoDatabase团队工作过，与所有戴着锡箔帽的阴谋理论家相反，我可以告诉你，这根本不是恶意的。这是因为GeoDatabase的内部在每个版本上都会更改。要发布完整的规范，基本上需要提供应该如何维护所有内容的所有详细信息，然后在每年发布的版本中仔细记录格式的更改。这没有道理。因此，尽管FileGDB API并非规范，但它会抽象出所有这些小的更改。现在可以跨平台使用了！请注意，这是向前迈出的一大步！考虑到ESRI的保守性，这绝对是正确方向的反应。

但是，仅二进制支持并不能使开源世界中的任何人都感到高兴。如果ESRI不支持，则如何利用将一些代码移植到其他类型的Linux上的优势。你不能 这就是使开放源代码功能强大的原因，现在，您无法利用此功能。如果ESRI决定停止支持Debian，就是这样。大功告成 您无能为力地对其进行更改。

Spatialite：

Spatialite很棒，因为它从SQLite获得了所有免费功能。SQLite无处不在。它可以在您的Android手机，iPhone / iPad，Firefox，Google Chrome和几种商用嵌入式设备上使用-可以永久使用。为了真正地使其成为一种地理格式（而不只是执行哑边界框操作），它需要利用PostGIS使用的同一几何库：GEOS。可悲的是，GEOS基于另一个更强大的几何库JTS。JTS中的所有算法都非常强大，那么问题出在哪里呢？

好吧，JTS已获得开源LGPL的许可，LGPL是病毒许可。JTS是LGPL，表示GEOS是LGPL，表示与GEOS静态链接的spacespaceite是LGPL。糟透了 为什么？在不过多解释开源许可证的情况下，我可以告诉您，例如，我不能在iPhone应用程序上使用spacespaceite，因为这会使我的整个应用程序自动开源（iOS仅允许静态链接）。任何类型的GPL许可证（合理地）都会吓倒ESRI，所以他们不会用10英尺长的杆触碰它。因此，ArcGIS，世界上最流行的GIS系统，不会（也可能永远不会）原生地支持spacespaceite。这会自动将其杀死为可行的格式。

因此，我们返回到各处都支持的糟糕的shapefile。

更新：

显然我的答案引起了很大争议，以至于有人认为可以自由编辑和更改我的答案的全部含义以表达他们的观点是可以的。请不要那样做。如果您不同意我的意见，那完全可以，只需将您的意见发表在其他答案中，然后让社群做出决定。我将修改返回到我的答案，以显示原始含义。我正在添加此更新，以防您阅读声称sqlite是可行格式的已编辑答案。

SHP + SHX部件本身还不错。真正的问题在于DBF部分。可以使用支持Unicode和各种现代字段类型的新格式来实现。问题是那里的所有软件都很好地支持它。

GeoPackage是一个有前途的继任者。它类似于Spatialite，但来自OGC，并且已被许多软件采用，包括ArcGIS和OGR。

参见官方主页http://www.geopackage.org/，例如此演示文稿：http : //www.slideshare.net/JeffYutzler/geopackage-swg-overview

至少空间主义者有此意图，请参见此演示文稿，例如http://www.sourcepole.ch/assets/2010/9/10/foss4g2010_spatialite.pdf

另一方面，我确实相信它失败的主要原因是shp得到了许多应用程序的良好支持，并且只有很少的缺陷。

其他人也有这样的看法：

这不是因为SpatiaLite项目没有为我们提供实施工具，而是社区可以减少对此的关心。SHP为他们工作，没有任何理由要改变。

http://www.spatiallyadjusted.com/2010/09/16/spatialite-is-not-the-shapefile-of-the-future/

有关Esri文件地理数据库，spatialite和Autodesk SDF的更多想法，请访问：http : //www.spatialdbadvisor.com/blog/121/the-shapefile-manifesto

Esri多年来一直在推广File Geodatabases，以替代shapefile。

最近，他们提供了隐藏任何奇怪之处的API。

像GML这样的XML方言绝对不是针对操作大型数据集而进行优化的，但是可以用作软件之间或平台之间的交换格式。

我不认为许可有任何问题（请参阅Ragi Yaser Burhum关于Spatialite病毒特性的帖子），并且如果需要，可以很容易地调整现有的解析器。

仅仅从不同的角度来看，我不确定使用 “ 25岁及以上学历或更高学历的公民百分比”是否是一个很好的领域名称。虽然可以处理空格和撇号，但是如果您正在编写代码或查询，则很可能会引入错误。

在我看来，空间数据分发的未来应该集中在Web和Web服务上，并且WFS规范（使用GML）已经公开并建立。 GeoJSON较小，可以更轻松地在JavaScript中使用。但是，压缩后的尺寸是可比的。

我也想对ESRI的Personal Geodatabases进行投票。它可能是经常使用的Microsoft格式，但它支持ODBC，SQL查询和视图，并允许非开发人员创建简单的数据输入表单，并至少包括某些级别的数据完整性检查（数据类型，长度，唯一值） 。