聊聊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] [email protected]

[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