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

在另一个主题(Shapefile技术规范中的“奇数”)中,geospatialpython评论说:“尽管shapefile格式存在缺陷,奇怪之处和局限性,但它在GIS领域及其周围仍然顽固地存在。试图替换它对于简单的向量存储而言太过膨胀或过于专有。”

这项活动加上Lawhead先生的评论让我感到纳闷:


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

作为GIS开发人员和用户,我们似乎可以为自己做些更好的事情。

评论

@Mapperz除了最近发布的Geodatabase API外,我看不到任何免费的用于编写地理数据库的工具。除了世界上的ESRI部分,我认为这不能算是替代品。

您可以使用resources.arcgis.com/content/geodatabases/10.0/file-gdb-api
使用GDAL gdal.org/ogr/drv_filegdb.html使用GDAL编写和读取地理数据库。
希望看到Python API在没有ArcGIS许可的情况下读取/写入文件地理数据库(至少是简单功能)-这将是开放的。

@PolyGeo您和其他所有人:)

@celenius from gdal.org/ogr/drv_shapefile.html“几何:Shapefile格式显式使用32位偏移,因此不能超过8GB(实际上使用32位偏移到16位字)。因此,建议不要使用文件大小超过4GB。属性:dbf格式中没有任何偏移量,因此可以任意大。”因此,您可以拥有相当大的dbfs,但是必须谨慎使用超过4GB的shp。那你在玩火。

#1 楼

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

之所以支持它们,是因为它们具有多个特征,所以让我列举一些。
/>

首先,有一个规范。我的意思是,我30多岁就已经存在了,因为这是我十几岁的时候就存在的东西。因此可以肯定地说,这个规范已经存在了一段时间。当然,还发布了其他几种格式,但是这种格式的区别在于...
它相对简单!它建立在DBF格式的基础上,该格式当时已经存在,并且在多个平台/ OS中得到了广泛的支持。已经有解析器可以读取这种格式的一半(DBF部分),因此它使得支持额外的添加更加容易。你有几何吗?当然可以序列化并编写它。大功告成将此与覆盖范围进行对比!尝试以简单的方式向某人解释拓扑清理的作用。编写拓扑上干净的覆盖并不是一件容易的事。
最重要的是,我认为shapefile仍然流行的#1原因是开放源代码系统和专有系统都支持它们。您知道哪些不支持shapefile的GIS?!?闻所未闻。

作为替代,我们听说了File GeoDatabases和Spatialite。与Shapefile相比,这两种格式在功能,灵活性,速度等方面都具有极大的优势。以它们自己的方式,它们具有某些使它们在不同区域彼此更好的东西,但是,对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是可行格式的已编辑答案。

评论


SQLite / Spatialite的问题在于它不是一种格式,而是一种关系数据库引擎,其上具有空间库。尽管它做得很好,但它会强制以关系方式存储数据,但这并不总是最合适的方式。同样,SQLite文件格式(sqlite.org/fileformat2.html)的复杂性使得没有SQLite引擎就很难访问数据,因此不适合作为开放且易于访问的文件格式进行数据交换。它并不是真的为此而设计的。

–伊戈尔·布雷耶克(Igor Brejc)
2012年2月21日在6:31

实际上,LGPL不是病毒许可-它是专门为避免这种情况而设计的。此外,Spatialite是根据MPL tri许可证(源)获得许可的,这意味着您可以选择Mozilla Public License作为最合适的许可证,并根据其(非常弱的copyleft)条款进行操作。至少我的阅读是,ESRI没有获得许可证支持不支持Spatialite的原因-他们是否会(考虑到与FileGDB竞争的空间几乎相同)是另一回事...

–om_henners
2012-02-21 13:49



@Ragi,您使用库进行混合并将其移植。当然,移植必须是LGPL,因为从本质上讲这是衍生产品。但是,如果您动态链接它,则它不被视为派生作品,而是“使用库的作品”,您可以保留许可证(en.wikipedia.org/wiki/GNU_Lesser_General_Public_License)。因此,在没有其他解释的情况下说“ LGPL具有病毒性”是不正确的。

–伊戈尔·布雷耶克(Igor Brejc)
2012年2月21日在20:34

但是,这又是一个有争议的问题,因为Spatialite是在树状许可的模式下(groups.google.com/forum/?fromgroups#!topic/spatialite-users/…)进行许可的,因此您可以选择适合的许可您最多-MPL允许静态链接。

–伊戈尔·布雷耶克(Igor Brejc)
2012年2月21日在20:34

@ bugmenot123很好,然后根据需要进行更正,但不要指责我散布有关操作系统的FUD,因为这是侮辱性的。我已经写了十多年的OS代码(对于您实际上使用了我的一些东西,我不会感到惊讶),这并不是生气。是的,现在仍然如此。 LGPL在iOS中进行动态链接(确切地说,在iOS 8中允许使用框架)。这从来不是技术问题,而是法律问题。在Appstore中进行分发需要代码签名-对于像我这样的所有OS爱好者来说,可悲的是-LGPL是对此的模糊许可。法庭上没有先例。

–拉吉·亚瑟(Ragi Yaser Burhum)
17年6月1日在15:27

#2 楼

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

评论


+1在DBF方面进行改进也不是一件困难的事情:它确实可以说服软件开发人员就某些事情达成共识。

– hu
2012年2月20日在21:57

有尝试过吗?

– canisrufus
2012年2月21日,下午1:28

我经常寄希望于Shapefile修正案,该修正案简单地将UTF-8 CSV文件替换为DBF。支持非常简单,并且只需对现有软件包进行最少的更改。

– scw
2012年2月21日在19:03

@canis Fox Software在80年代后期进行了较小的尝试(专有)。 MS购买了它们(大约在1990年)之后,就是这样。社区创建了DBF 3标准,几乎冻结了所有开发。 MS发布了Access; FoxPro淘汰了;世界在前进。

– hu
2012-2-22在17:38

相反,@ Uffe可以随机访问CSV文件:您只需要一个索引,就像DBF文件可以有效地进行搜索一样。我看到的最大问题是,对CSV文件自然发生的细微更改(如引用字符串或CR / LF转换)会破坏所有字节偏移量。 DBF文件的固定长度记录结构,尽管存储效率较低,但是没有这个问题。

– hu
2012-2-22在17:47

#3 楼

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

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

#4 楼

至少空间主义者有此意图,请参见本演示文稿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

评论


正如我认为的那样,spatiaLite很棒,在功能,参考系统等方面的开销约为3兆字节,这使其无法成为一种良好的全方位交换格式。

– Scro
2012-2-20在21:51

实际上,spacespaceite的许可并不理想-与工具无关。

–拉吉·亚瑟(Ragi Yaser Burhum)
2012年2月21日,下午1:53

@ Scro,3 MB太大了吗?对于台式机来说肯定不是太大。您必须考虑使用移动设备。另外,是否还有另一个Spatial API,具有与Spatialite相同的功能,且具有相同的功能?

– klewis
2012年2月21日14:14

@klewis-它本身并不太大,当您考虑到那里有很多小的(认为小于200kb)数据集时,它的效率非常低。这会产生很多开销,尤其是考虑到以下事实:一旦收到,您通常会将每个数据集保留在3mb文件中,或将其滚动到现有数据库中。明确地说,我<3 spatiaLite -但是我们正在谈论数据传输,在这种情况下,某种平面文件/ xml / wkb会更加高效。

– Scro
2012年2月21日在14:58

#5 楼

Esri多年来一直在推广File Geodatabase,以替代shapefile。

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

评论


我没有与地理数据库进行大量合作。维基百科说,它们是“封闭的”标准,例如地理数据库规范尚未发布。如果不发布该格式的内部内容,似乎很难获得广泛的采用。虽然我还不很了解历史,但我猜想shapefile在某种程度上如此受欢迎是因为该规范的公开部分。 API看起来确实是一个好步骤。

– canisrufus
2012年2月20日在21:10

@canis你是正确的。当时,没有人会采用shapefile,只是ESRI专门将它们推广为开放的GIS数据交换格式。即使当时可用的软件工具有限,但随着ESRI发布清晰的.shp / .shx规范(并坚持遵守),编写代码来阅读和阅读代码只需要花费几个小时的时间。编写shapefile:无需进行逆向工程。

– hu
2012年2月22日在17:41

只要API是黑盒二进制blob,FGDB就不会看到与SHP相同的采用。即使Esri说服所有客户从SHP转换为FGDB,该API仍与开放源代码实际上不兼容。

–德里克
15年7月1日在19:28

#6 楼

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

我认为许可没有任何问题(请参阅Ragi Yaser Burhum关于Spatialite病毒特性的帖子),并且如果需要的话,可以很容易地适应现有的解析器。

评论


我认为没有提到它仅仅是因为您提出的原因,它没有针对大型数据集进行优化。 XML膨胀。这里提到的格式是二进制的,其中GML将点存储为字符串。大小可能相差一个数量级。

– canisrufus
2012年2月21日在18:05

Canisrufus是正确的。 GML存在几个问题。可以使用XPath导航Infoset,但是任何尝试在XML之上实现空间索引的人都会告诉您,这是多么不合理,以及它映射到传统关系数据库的程度如何。无需赘述许多内容,如果像索引和查询这样的基本内容变得不那么琐碎,那么该格式就显得肿了,并且基本上需要您将整个数据集存储在内存中才能对其进行任何处理,那么这不是一个好选择。

–拉吉·亚瑟(Ragi Yaser Burhum)
2012年2月21日在18:56

xml以纯文本格式存储时会肿。有免费的(免费的,免费的修改和重新分发的)二进制xml库,可以作为xml读取器的替代品,使人们可以自由利用xml的可读性以及二进制文件的性能和存储效率。我无法想到的唯一原因就是它无法被大量使用,就像johandvw在上面观察到的那样:没有人在乎,.shp确实“足够好”。

–马特·威尔基
2012年2月21日在20:46

#7 楼

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

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

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

评论


这是有道理的。它们的优点是,只要具备英语知识,就能弄清楚这些领域的含义。

– canisrufus
2012年2月23日14:17在

这实际上就是数据集元数据的作用。 shapefile可以使用具有相同名称的XML文件来存储它。

– geoographika
2012年2月23日的18:00