GeoPackage(如下简称gpkg),内部使用SQLite实现的一种单文件、与操做系统无关的地理数据库。html
当前标准是1.2.1,该版本的html版说明书:https://www.geopackage.org/spec121/index.html。git
本文简单介绍一些最须要关注的特色,由于笔者也是菜鸡(刚开始学)github
版权没有,盗版随你。本文原文地址:http://www.javashuo.com/article/p-mmmybelp-ku.htmlsql
小专栏链接:https://xiaozhuanlan.com/topic/6573102849 (内附更多GIS相关技术介绍)数据库
做者:博客园 @秋意正寒编程
它在非编辑、非链接状态时,扩展名是*.gpkg;在数据链接或编辑状态时,会多出来两个同名不一样拓展名的文件:*.gpkg-wal、*.gpkg-shm。json
若是不肯定得到的gpkg文件是不是SQLite数据库,能够用二进制查看器看最开始的字节信息,前16个字节应为以null结尾的ASCII字符串“SQLite format 3”。有关更多二进制信息,请到OGC官网上查看说明书。安全
gpkg最大数据量为140TB(应该没多少项目用获得吧...)服务器
它能存储的数据有:网络
“其余”意味着能够扩展gpkg数据库,可是目前笔者没有这个能力。
由于单文件的特色,与ArcGIS家族中的Geodatabase模型的实现——mdb和gdb很像。它们同为本地数据库。
gpkg没有相似ArcGIS中要素数据集的概念,也没有PostGIS中模式的概念(可能我没发现,暂时作狗头处理)
gpkg能够直接被ArcGIS识别并增删改查数据(即ArcGIS内置了支持)
gpkg也能够被QGIS识别并增删改查数据。
由于SQLite“单文件”、“轻量化”的特色,因此gpkg特别适用于小规模的场景和移动场景。好比学生练习、手机等。
若是想多种途径建立gpkg,请阅读此文:点我
可是,一般使用GIS桌面客户端就能够了。
此外,SpatialLite 4.2.0以上也支持gpkg。
看你怎么想。能够替代,可是不必。像简单的交换数据和显示简单的数据,GeoJson就能够完成。(详细的看第二节)
gpkg只是SQLite的一种编码、规定,没有像其余DBMS同样的安全管理。不过,已经有人实践了SQLite的安全扩展模块,能够考虑一下或者换更安全的数据库管理系统,例如PostgreSQL。
由于原始的WKB标准不能知足gpkg,因此要扩展。PostGIS和SpatialLite都这么作了。
QGIS 3.X默认从shp文件切换到gpkg,所以,渲染变得很是快。使用gpkg比使用shp文件在加载,平移和缩放时更快。
优势:
缺点:
优势:
缺点:
原做者但愿更多人使用gpkg而不要再继续使用shp了(笔者注:旧事物还有利用的余地时,新事物的推进就会很是困难;除非使用政治或者垄断手段强行更改(好比当年Esri的Coverage格式被Esri本身干掉了)——不太可能,这些都很是符合马克思主义;并且,是否使用gpkg或者shp或者其余数据库,都要具体问题具体分析)
若是你有庞大的数据须要存储、管理,原做者建议使用PostGIS。若是您喜欢GeoPackage,请与您的同事和合做者分享这些信息!
彷佛有一小撮人,正在鼓吹shp必死论(多是受够了shp的缺点了吧!),我就简单翻译一下。
shp文件具体是什么我就不过多介绍了,它诞生于1990年,立刻就是它的30大寿了。
尽管shp文件是Esri维护的,可是它的规范是开放的,也就是说,若是你懂了shp文件的几大数据结构构成,会编程,你也能够手搓一个shp文件读写程序,不须要依赖任何第三方库。
可是,下面原文开始重点驳斥shp文件的坏处:
为何Shapefile这么糟糕?如下是Shapefile格式错误的几个缘由,您应该避免使用它:
不展开了,有兴趣的朋友到他们官网看便可
讲道理,如今没有任何一种矢量格式能彻底替代shp,可是不得不说其余的格式正在慢慢崛起,有他们的用户。
例如,kml、gml、geojson等
一些Shapefile替代品:
其中,第一位列的就是gpkg,并且通过近几年的迭代升级、修订,再加上它能够扩展的特性,使得gpkg更强大。
GeoPackage的一个缺点是,它底层SQLite数据库是一种复杂的二进制格式,不适合流式传输。它必须写入本地文件系统或经过中间服务访问。因此,在本地应用中,gpkg是shp文件的一个不错替代品(若是你有须要)
GeoJson并非shp文件的代替品,只是地理数据的一种json实现。它的一个特色就是支持流传输;存在的问题是,不是全部的几何均可以表示,高级的坐标系统支持也不算好。
因此,基于XML的GML格式(仅支持矢量数据)就有了用武之地。可是GML也有其缺点,就是数据结构定义标准复杂,较少软件愿意支持它,ArcGIS把它的支持丢进了数据互操做模块。若是GeoJson不能解决问题,能够试试GML。
SpatialLite和gpkg相似,也是一个开源数据库,也是基于SQLite,也是单文件,也支持SQL,可是不如gpkg普遍。究其缘由,是由于sl缺少扩展能力(比如世界之窗vsChrome),也不支持栅格数据。一样的,它也不支持流传输。
csv文件,估计有的同窗用过,最大的特色就是简单了。它就是个文本格式的二维数据表格。在非GIS行业中,csv很是受欢迎。做为属性表可能合适,可是它并不具有几何等复杂空间信息的存储能力,并且它没有一个标准。
kml是谷歌在谷歌地球中推荐的格式,基于XML,单文件。它有个特色就是,数据和样式同存在于一个kml文件中。缺点也有,仅支持wgs84坐标。因为它基于XML,因此数据量一大就很差用了。数据和样式存在耦合,这也是个缺点。
固然,除了以上开源格式外,还可使用更复杂的DBMS或者ArcGIS家使用的面向对象的地理数据库。
笔者的建议是,仍是具体问题具体分析。若是你要作真正的GIS项目,通用、标准化、性能高才是不二之选;因此,像kml等非主流可是又有其价值的数据,除了在它自己的平台用外,最好转换到更通用的格式上,例如,就GeoPackage——否则仍是老实点用shp文件吧~
项目大的,有高并发、安全要求的,不妨试试PostgreSQL的PostGIS拓展。或者用MySQL、其余商业数据库,那些就不在本文的讨论范围了。
[1]. OGC的GeoPackage官网:https://www.geopackage.org/
[2]. OGC的GeoPackage起步文档:http://www.geopackage.org/guidance/getting-started.html
[3]. OGC的GeoPackage标准(相似于白皮书)http://www.geopackage.org/spec120
[4]. 实现了GeoPackage的有关软件:https://www.geopackage.org/implementations.html
[5]. GeoPackage vs Shapefiles:https://www.gis-blog.com/geopackage-vs-shapefile/
[6]. Shp文件必须死!(这个网站有点偏激):http://switchfromshapefile.org/