聊聊GIS数据的四个分层与GIS服务

本篇不讨论矢量栅格数据的结构,也不讨论矢量与栅格的区别(即设定读者有这方面的基础)。

版权声明:原创。博客园/B站/小专栏/知乎/CSDN @秋意正寒

转载请标注原地址并声明转载: https://www.cnblogs.com/onsummer/p/12082568.html

本文系概念性很强的博客,但对GIS项目有帮助,对在读的学生也有一定帮助。

尽管从物理的角度,只有独立数据文件(shp、geojson、tif等)或者数据库(esri geodatabase的gdb、geopackage等)这两种

但是,从学科角度,即从GIS的视角看,地理数据并没有那么简单。

为解释简便,使用shapefile、geojson、tif栅格和gdb、postgis,辅助ArcMap/QGIS 3.10做解说。

1. 术语及概念定义

① 地理数据

地理数据=空间数据+非空间数据;也叫地理信息。例如:一座医院;一所学校;一条道路;一条河流

② 空间数据

即几何数据,描述坐标、形状的数据;也叫空间信息。例如:形状、坐标

③ 非空间数据

即属性数据,描述与空间位置无关的一类数据。例如:成绩单、医院名称列表

这类数据的特点是,如果脱离了地理位置也有它本身自己的含义。

2. 矢量数据的四个分层

不妨这样想:每一层均为子一层的容器。大鱼吃小鱼,小鱼吃虾米。

2.1. 几何/属性层

这是矢量数据的最底层,有两个类别:几何层或者属性层。

前阵子写了一系列坐标系有关的博客,我们假定在某个坐标系下,存在某个点P(x0,y0),这个点在这个确定的坐标系下,就是独一无二的。

那么,如果这个点代表的是一个咖啡店,仅仅知道这个点的坐标(x0,y0)是不够的。

不同的用户关心不同的信息,有人关心这个店的电话号码,有的人关心它所在的城市和行政区,有的人关心它的地址,有的人关心它的人均消费。

这个时候,信息就可以分化成两个种属:几何的,属性的。

  • 我们说表征位置信息的坐标数据(或者多个坐标构成的线、面),叫几何数据。
  • 除了几何数据,都叫属性数据。

上大学的时候,系主任说:地理数据区别于其他行业的数据,最大的区别是它具有空间数据!

我们刚明确了几何数据是什么,属性数据是什么,那么多出来的一系列名词又是什么?

做以下规定:

  • 地理数据=几何数据+属性数据=空间数据+非空间数据
  • 几何数据=空间数据
  • 属性数据=非空间数据

这样就不乱了。默认使用“地理数据=几何数据+属性数据”这个表达。

2.1.1. 案例讲解--geojson

现在讲概念其实很枯燥,那么一个具体的矢量数据文件,比如geojson或者shp,如何判断哪些是几何数据,哪些是属性数据呢?

我们取一个geojson文件,只有一个点,没有属性数据。它在QGIS里长得像这样:

它数据长这样:

是WGS84下的一个点,在广州城区。

我们可以很快聚焦到"geometry"这个键上,它下列有两个子键"type"和"coordinate",这两个子键的值就是这个geojson矢量数据的几何信息。

读者可以想象得到,如果type是“LineString(即多折线)”,那么coordinate将是一堆折线段的集合。

如果是Polygon:

 

 geometry的值的的确确就是上面提及的“表征位置信息的坐标数据”。

我编辑了一下只有一个点的geojson,使其拥有三个属性数据:所在城市是"Guangzhou",编辑者是"秋意正寒",邮政编码是"510000".

属性表长这样:

文本变成了这样:

我们不难看到,和geometry键并列的多了一个键:"properties"。

它翻译过来就是属性的意思(别的数据格式可能叫“attributes”)

我们看到了在geojson中,“几何层”、“属性层”是如何组织的。

2.1.2. 案例讲解--shapefile

shp文件至少要有3个文件构成,*.shp、*.shx、*.dbf

因为这些是二进制文件,不能用文本格式查看,所以直接给出结论:

*.shp文件记录的是几何数据

*.dbf文件记录的是属性数据

*.shx链接二者是索引数据

我们将2.1.1中的geojson文件在QGIS中导出shp并在ArcMap里打开其属性表:

发现多了两列属性,其中Shape属性无论给这个shp文件加多少个点,它的值在ArcMap属性表里的都是一个汉字“点”。

而且,FID和Shape属性是无法在属性表里编辑的。

实际上,这个Shape属性列,就是几何数据,ArcMap把它“写”在了属性表而已。我们编辑它还是得靠编辑工具。

ArcMap的属性表通过“显示”Shape列,告诉用户几何数据和旁边city、editor、adcode三列是并排的。

也即“几何数据”、“属性数据”是同级别的数据,只不过几何数据可能很复杂,在属性表上一个格子写不完,就干脆写个汉字。

实际在ESRI的体系中,几何的表达比OGC的表达更为精妙复杂。

因为深入需要研究ArcPy或AO代码,有一定难度,故不展开。读者只要能读懂“几何”“属性”是并列的两个数据层即可。

2.2. 要素层

要素层很简单。

先下定义:一个要素表示一个地理实体,一个要素有其自己的几何数据和属性数据。

我们依旧是上面的点json来讲解。

不难看到,properties和geometry键都是"features"这个数组的某个元素下的子键,这里的某个元素,就是要素。

也即,{"type": “Feature”, ...}就是一个"feature",一个要素。

由于有了几何和属性的分割,一个要素当然可以有n个属性,一个要素的几何也可以是n个点/线/面构成的复杂几何图形。

n个属性好理解,n个点/线/面构成的复杂几何图形又是什么意思呢?

这里不再展开描述,有兴趣的朋友可以去参考ogc的Geometry标准,它规定了几何体的复杂构成。以后有机会一定会写一篇ogc标准下的geometry标准。

我们注意到了,"features"下的每个要素的properties的子键都是一样的(名称、类型)。

2.3. 数据层

还是以上文的geojson为例。

我们说,

n个具有共同类型和数量属性的"feature"(即每一个feature的"properties"的子键名称一致,类型一致),加上一些元数据(坐标系信息,四至等,每种数据格式不太一样),构成一个矢量数据。

这个矢量数据已经上升到磁盘文件级别了,我们为了复用,不可能一个一个要素分别存在独立的文件里的,因为属性的数量、类型一致,所以要素可以存在一个文件(或者容器)里。

我们把这个容器所在的级别,叫做“数据层”。

我为什么不说一个矢量数据文件(例如一个json文件,一份shp文件)就是一个“数据层”的实现呢?

因为,一个矢量数据固然可以是一个geojson文件,一个shp文件(由多个同名子文件组成),一个gml文件,一个csv文件...当然一个矢量数据也可以是数据库里的一个表,或者一个要素类(ArcGIS里的gdb)。

我们讨论的是“分层”,而不是物理文件构成。

通常来说,我们传递的数据大多数处于数据层。比如,我们传递一个“中国省级行政区划”的shp文件,或者传递一个“广州市医疗机构点位”的geojson文件。

我们很少传递一个“要素”,传递一个“几何面”——代码层面除外。

plus 数据层(Data)为什么不叫图层(Layer)

我们把一个矢量数据(geojson/shp/数据库里某张地理数据表等)拖到任何一个GIS客户端软件中,一定能看到它的样子,软件会给我们画出来,它这个时候,叫做“图层”。

因为数据和图层分担着各自不同的任务,图层负责渲染、显示数据,数据被图层引用。一个数据是可以被多个图层引用的。

这就好比,账本专心管理财务流水,报表ppt专心负责回报财务流水的各种趋势比例。

我们GIS软件依靠图层将数据符号化,比如给某个点数据设定了符号是一个尺寸是15的红色五角星,给某个线数据设定了标注是它的“name”字段,通过图层查看一个数据的元数据等...

2.4. 地图层

什么是地图层?

我们有了数据层,就可以进行地理数据的分析、展示、交互了。

我们为了组织起地理数据,需要将数据排列顺序,符号化,设计出一张地图。

地图这一层包括了n个数据(也即n个图层,每个图层引用一份数据)。

当然,我们还可以为数据做分组。

我们知道ArcMap中,有个“数据框”的概念,其实一个数据框就是一个地图,数据框就是地图层这一级别的容器。

大家可能看中国地图会观察到右下方通常会有一个“南海诸岛图”,其实中国大陆主体地区和右下方的“南海诸岛图”用两个数据框就可以表示了。

事实上,QGIS也有一样的概念,在布局窗口中,我们可以插入一个地图:

同样能做到“南海诸岛图”和大陆图在同一个布局里显示的效果。这里插入的“地图”就是“地图层”的一个活生生的案例。

plus:

GIS客户端软件会使用“工程文件”的手段,把n个“地图”包裹在一起。QGIS使用*.qgz文件,ArcMap使用mxd文档,ArcGISPro使用arpx文件。

3. 栅格数据的四个分层

栅格数据和矢量数据当然是有区别的,但是,在概念上可以归一。

3.1. 位置/属性

在栅格中,几何图形所代表的空间数据被像元的中心坐标值代替了,该像元的像元值即属性值。

我们知道,栅格数据可以是单波段也可以是多波段,可以是浮点数栅格也可以是整数栅格。

栅格数据可以代表的地理数据种类比较多,以单波段数据为例,整数栅格有属性表,可以添加多列属性(即给不同的像元值赋予不同的意义),浮点栅格则不行。

多波段则能实现“同一个像元坐标”“n个像元值”,并且每个像元值独立,不受整数或者浮点数影响。

3.2. 像元层

像元,包括像元分辨率、像元中心坐标和像元值三大主要数据。

像元层并不像矢量中的要素层表意那么直接,因为单像元表达的地理实体不如一个要素强。但是,多个像元是可以做到一个要素的表达效果的。

比如,在DEM栅格数据中,一个像元可以概括表达这个像元面积这么大的地方的海拔高度。多个连片的像元可以构成一块地区的地形。

但是,和要素层的核心要义是一样的,像元层和要素层都能表达地理实体,把像元的三大主要数据孤立讨论,是不能表达地理实体的。

3.3. 数据层

数据层和矢量数据的数据层类似,为n个呈矩阵排列的像元构成的图像。

这个图像可以是一层,也可以是多层叠加,只要保证像元中心坐标一致、像元分辨率一致即可。

数据层的物理形式比较简单,除了一些元数据外(坐标系什么的),就是一个体积比较大的数据文件,或者在数据库里的一张表或者一个栅格数据集(Esri gdb)。

若为一个单文件,常见的GIS数据格式为tif,尽管jpg/png/bmp等传统图片格式也可以称作栅格数据,但是它们设计的初衷并不是GIS应用。

在GIS数据服务中,栅格数据切片可以是jpg/png,因为便于网络传输和显示。

3.4. 地图层

地图层与矢量数据的地图层一致,都为n个栅格数据按一定顺序、符号化构成。

4. GIS数据服务是什么

4.1. GIS服务器

GIS服务,与普通网络服务是一样的。

  • 普通Web服务器提供网络服务,使得我们可以上网冲浪
  • GIS服务器提供GIS数据服务,使得我们可以遵循某些规范访问地理数据或者地理服务

我们常见的Web服务器软件,有IIS、Apache、Nginx、tomcat等,也可以用Java/nodejs等工具语言编写自己的服务器后台软件。

GIS服务器软件基于HTTP等协议(做webgis的,如果连http协议都不知道,建议先补补课),也有一些受欢迎的:开源的GeoServer、MapServer,商用的Esri的ArcGIS Enterprise套件等。

GIS服务器可以是独立的软件,也可以是某个Web服务器的一个插件。例如,ArcGIS Enterprise套件就是自成一家,GeoServer就是Tomcat的一个war包插件。

Q:GIS数据一定要放在GIS服务器上吗?

A:不一定。诸如geojson这样的文本类型数据,可以直接放到普通web服务器上,通过http的get或post请求交换数据;诸如gltf、3dtiles三维数据,开源服务器尚未支持三维服务,OGC组织也没有3DGIS服务规范,只好放在普通web服务器上。但是,成熟的二维数据,做成GIS数据服务是有利于前端开发者进行调用、渲染、数据查询、云处理的。

4.2. GIS数据服务

扯了半天,那什么是GIS服务呢?

通常来说,我们说的GIS服务就是GIS数据服务。但是,其实GIS服务还可以提供计算服务,也即GIS处理服务,作为4.3的内容讲解。

OGC中数据服务有很多,只挑一些常见的带过,具体怎么用还是得靠读者进一步阅读更多的资料,本文的重点仍旧是上面的四层概念。

GIS服务扮演的角色,更像是WebGIS中对GIS数据和用户交互之间的一个桥梁,它规范并限制了请求端的操作。

GIS数据服务应该属于“地图层”这一层级,因为它可以包括多个数据(图层)。

4.2.1. 提供访问地理数据的网络地图服务——WMS

WMS,Web Map Service,网络地图服务。

一个WMS是一个“地图层”的实现,只不过限制了网络请求的功能。

它允许将n个数据发布成一个“GIS服务”,1个数据被叫做1个图层,因为要对web提供访问,所以用图层这种带符号化的形式来描述“数据层”比较合适。

它提供了以下几大功能,有兴趣的朋友可以参考博客园李晓晖的博客,或者直接查阅OGC官方文档(列在参考文档中了):

 

  • GetCapabitities(返回服务级元数据)
  • GetMap(获取地图图像)
  • GetFeatureInfo(返回识别的要素信息)

第一个没什么好说的。

第二个获取的是给定参数(比如范围、返回图像的格式等)的地图图像,和截图差不多。

第三个功能,说大白话就是“点击地图,根据点位获取指定图层上的要素”。

 

4.2.2. 提供增删改查矢量数据的网络要素服务——WFS

WFS,Web Features Service,网络要素服务。

WFS强化了WMS中关于矢量数据的访问,提供了增加、修改、删除、查询矢量要素的功能。

WMS对矢量数据的查询,局限在了“识别”这一功能上。

我们从功能上就能看出,WMS有一个功能是“getFeaturesInfo”,而WFS直接给出了"getFeature"、“Transaction”等功能。

WFS的主要功能如下:

  • GetCapabitities(获取这个服务的元数据)
  • DescribeFeatureType(获取这个服务上要素的元数据)
  • GetFeature(获取要素)
  • Transaction(对要素进行增删改)

GetCapabitities和DescribeFeatureType的区别在于,前者描述整个服务,后者聚焦于矢量数据的元数据。

GetFeature既可以使用get请求,也可以使用post请求。无论get请求还是post请求,都可以使用过滤条件,过滤一些不满足给定条件的矢量数据。

Transaction使用post请求,将指定格式的xml请求到gis服务器上。

WFS要求服务的接口必须由XML描述,另外数据交互必须由GML(一个OGC矢量数据格式规范)迚行,数据过滤采用CQL语言。

4.2.3. 网络覆盖服务——WCS

WCS标准定义了一些操作,这些操作允许用户访问“Coverage”数据,如卫星影像、数字高程数据等,也就是栅格数据。

有矢量就有栅格,与WFS形成对比,WCS的C,就是栅格数据的意思。

WCS也有几个功能:

  • GetCapabilities(获取服务的元信息)
  • DescribeCoverage(获取Coverage的描述信息)
  • GetCoverage(获取Coverage)

4.2.4. WMS的变种:网络地图切片服务——WMTS

WMS能给前端返回一张位图,和我们在GIS软件里对一个地图直接截个图(不经过制图)类似。

如果这张位图体积过大或者网络传输不好,那么极有可能前端是拿不到的,就渲染不出来。

分治思想刺激WMS演进,即WMTS,原理很简单,即把这张位图实现按网格切好,在不同的分辨率下,把这些切好的图(都缓存在地理服务器上)按前端指定的范围,挨个传递。

这样,一张小图可能体积并不大,保证了前端的体验。

4.2.5. 三维场景服务

迄今为止并未有三维地理数据服务标准,只有三大地理三维数据格式标准:

  • i3s
  • 3dtiles/gltf
  • s3m

其中,前两个被ogc承认,且主推i3s。

i3s由Esri(就arcgis家)主推,以slpk文件为交互文件,在自家的ArcGIS Enterprise服务器生态中,已经研发出“SceneService”这种GIS商业数据服务了。

3dtiles是ogc的一个标准,是i3s的主要竞争对手。

gltf,号称是三维数据界的jpg,目前(发文时间2020年初)开源的商业的gis服务器尚未支持三维服务,cesium自己是直接前端调用gltf文件创建视图。

s3m是国内北京超图主推的一个标准。

i3s、gltf、s3m三者共同的特点是用树结构来组织数据,用json文件描述数据,用二进制文件来存储具体数据。

4.3. GIS处理服务

遵循一种规范,可以将繁重的处理任务交由服务器运行,然后根据规范,将处理结果返回给前端。这在普通的web服务中是理所当然的事情,只不过加上GIS数据这个壳儿,事情就变得有点复杂了起来。

其实OGC组织是有这么一个规范的,叫WPS——Web Process Service。

Web 处理服务 (WPS) 是用于发布地理空间过程、算法和计算的 OGC 服务。

WPS 服务可作为GIS服务器的扩展,为数据处理和地理空间分析提供执行操作。

默认情况下,WPS 不是 GeoServer 的一部分,但可作为扩展提供。

Esri ArcGIS Enterprise中的Server和Portal都原生支持了WPS,并且有比WPS更强大的GP服务。

有关WPS在GeoServer上的资料,参考各大博客和文末的参考文档。

 

==============分割线==============

GIS服务器有商业也有开源,对OGC的多个服务支持也各有千秋,本文仅作简略介绍,而且有标准文档、各路案例博客资料,想必可以不再发文描述。

读者更应该关注的是本文提出的“四层概念”,多思考多比对。

在本篇中的四层概念合适套用在二维数据或者三维数据上,至于i3s标准下的slpk和3dtiles、gltf数据并不太适用,那些更合适网络分发,毕竟官方提及,slpk不适合再进行编辑。

 

参考文档

[1] GeoServer中WMS、WFS的请求规范 . 李晓晖. https://www.cnblogs.com/naaoveGIS/p/5508882.html

[2] OGC标准介绍. 吴泳锋 [M] warrenwyf@gmail.com

[3] GeoServer WPS文档 https://docs.geoserver.org/latest/en/user/services/wps/index.html

[4] OGC标准介绍 5 . https://blog.csdn.net/warrenwyf/article/details/5717612

[5] OGC标准介绍. https://blog.csdn.net/lavanana/article/details/93975949

posted @ 2020-01-13 04:32  岭南灯火  阅读(6718)  评论(1编辑  收藏  举报