1. 前言

1.1. 經典的 OGC 標準回顧

直至今日，GeoServer 仍在發揮作用，WebGIS 的幾大服務標準仍在應用：

WMS，網路地圖服務
WMTS，網路瓦片地圖服務
WFS，網路要素服務

這三個應該是耳熟能詳的了，還有其它的就不列舉了，本篇的重點並不是介紹這些現行標準，上面三個標準的速查可參考我往期的文章。

1.2. 共同特點與時代變化

現有標準，有一些共同的特點。比如，請求行為較為依賴 XML —— 原因之於「大前端」還未盛行的年代，後端常用 XML，前端就只能用瀏覽器 API 解析返還的 XML。譬如，WFS 的修改要素的事務操作（Transaction，一般稱之為 WFS-T），那寫在請求體中的 XML 使用 JavaScript 來編寫，就顯得比較枯燥冗長。

而現在，前後端職能分離，前端發展也有目共睹，地圖開發中，前端大多數時候更希望傳送、得到的是 JS 引擎更容易解析的 JSON，而不是 XML。

今天要介紹的這一套 OGC API，是 OGC 組織在 2 年前就一直在努力、下功夫的，他們把原來的 OGC 官網域名改了，LOGO 換了，甚至為這套 API 開闢了一個新的網站。

1.3. 免責宣告

本文書寫於 2022 年 7 月，這套 API 仍未完全落地，本文僅作為引導作用，並不能作為指導作用，一切以讀者所在時間點的情況為準，我介紹這套 API 僅僅是為了這個風氣浮躁的行業帶來點訊息，畢竟 OGC 官網這麼大動作，國內竟然找不到一篇文章，哪怕是簡單介紹的都好啊。

本文僅保留著作權、解釋權，歡迎具名轉載。

2. 什麼是 OGC API

2.1. OGC API 是一個開放、動態的規範族

OGC API 目前有 13 個子類（含一個公共定義），而在去年的時候只有 9 個。只要符合 OGC API 公共定義，就可以為行業中新生的資料需求制定網路請求介面規範。

本文介紹的 API 未來有可能會消失其中某幾個，也有可能會新增，一切以你看到的正式釋出的版本為準。

2.2. OGC API 特點

最顯著的特點可歸納為：

介面風格是 REST
資料傳遞預設為 JSON 格式

2.3. 眾 API 簡述（2022年7月）

首先，給個官網：OGC API

OGC API 是迎著近十年來前端技術飛速發展的趨勢應運而生的，它與上述幾個舊標準最大的區別是：

使用 REST 風格
交換資料預設改用 JSON

這一系列的 API 標準還對原來的幾大服務標準進行了升級改造，以及對其它領域的需求進行了補充。

例如，WFS 3.0 標準被直接改作 OGC Feature API，WMS 則升級為 OGC Map API，見下表：

新版 API	現行 OGC Web 服務標準	狀態
OGC Features API	WFS	已釋出 Part 1/2，一共 4 Part
OGC Maps API	WMS	起草中，可預覽
OGC Tiles API	WMTS	起草中，可預覽
OGC Processes API	WPS	已釋出 1.0，一共 1 Part
OGC Coverages API	WCS	起草中，可預覽

可能有的朋友不太熟悉後面兩個，Processes API 即任務 API，最大的特點就是允許你向介面發起一個資料處理任務，舊標準是 WPS，釋出這個 API 是對介面層面做了統一；Coverages API（也即 WCS）可能面向的是遙感應用，這個 API 更感興趣的是柵格資料的波段資訊、柵格像元等資料。

除了升級改造，還補充、完善了其它的標準：

新增的 API	用途	狀態
OGC Common API	OGC API 的公共定義	Part 1/2 起草中，可預覽
OGC EDR API	環境資料，與 Features API 很相似	已釋出 1.0，一共 1 Part
OGC Records API	查詢資料的資料，即後設資料，一般與 Features API 一起搭配用	Part 1 起草中，可預覽
OGC Styles API	可用於需要渲染的資料的樣式介面	Part 1 起草中，可預覽
OGC DGGS API	存取格網資料的一種介面	起草中，可預覽
OGC Routes API	路由資料介面，最直接的應用即網路分析	Part 1 起草中，可預覽
OGC Joins API	提供為空間資料進行連線操作的介面	起草中，可預覽
OGC MovingFeatures API	時態相關的要素資料介面，Features API 的擴充套件版	起草中，可預覽
OGC 3DGeoVolumes API	三維體塊資料介面，有望統一 3DTiles 和 I3S 等三維資料格式的存取	起草中，可預覽

這幾個 API 比前面 5 個要陌生，所以額外多解釋一番：

OGC EDR API - 環境資料，它查詢的結果似乎並不是「空間要素」，而是各種結合了空間資訊的環境資料，例如風速、空氣溫度、溼度、體感溫度等；允許使用座標、半徑、範圍、定位名稱等引數查詢環境資料，氣象領域、海洋領域的應用可能較廣，應該和 NetCDF 等多維資料格式的關係較為緊密
OGC Records API - 在設計上與 Feature API 略有重合，URL 在使用時會有重合，但在查詢過濾的側重點可能有不同，Feature API 的查詢專注於 空間分析型過濾，而這個 API 更專注於描述性質的屬性過濾，也就是 非空間分析型過濾，例如 title、externalIds 等；由於 Features API 的空間過濾章節規範還未釋出，且 Records API 的規範也未正式釋出、能體驗的例子也較少，所以一切以正式為準
OGC DGGS API - DGGS，即 Discrete Global Grid Systems，它使用比四元樹更一般化的網格劃分地球球面，有一些研究在這種特殊的網格幾何形狀上進行，它一般和 Features API、Processes API 一起使用，畢竟網格也是一種特殊的要素；只不過在 API 的設計上更加傾向於這些「網格」，靜等實現
OGC Routes API - 類似 pgRouting 的一種規範，在資料介面層面實現了統一，你可以拿來查詢路由（理解為有去由、有方向的路徑），返回的是向量要素，也可以呼叫與之配套的 Processes API 進行網路分析（最短路徑等），這個 API 比較硬核，通常是伺服器端的實現比較重
OGC Joins API - 空間連線，使得已有的要素資料與新提供的資料能產生連線關係，熟悉後端資料庫、ArcGIS 屬性表連線等相關操作的應該能大致猜出來這個 API 是幹什麼的，是一種偏行為型的 API，與 Features API 一起使用，不過當前這個 API 的程序比較緩慢，還沒有具體的實現
OGC MovingFeatures API - 是與時間相關向量要素 API，與 Features API 一起使用，目前尚未看到實現，我認為這也是一個非常考驗後端資料庫組織能力的 API
OGC 3DGeoVolumes API - 目的很簡單，將各家的三維資料標準統一到一起，目前還沒什麼內容，但開了個好頭；我認為至少把現有的幾個標準能合併在一起就很難以實現了，如果要在 API 層面使得各大 3D 資料規範統一，那將是一個非常漫長的過程；目前，社群案例中以簡單的 3DTiles 為多，且只能以 REST 介面存取 tileset.json 檔案的 JSON 內容；這個 API 的目標很大，希望把 glTF、3DTiles、I3S、CityGML/CityJSON 等一併具備實體資料內容的格式，通過 3DGeoVolumes 的概念在空間上聚合在一起，在 API 層面做到統一，而不是重新提出一個資料規範
OGC Styles API - 比較容易理解，規範化了各種樣式資訊的增刪改查介面，這些樣式資訊可以用於瓦片、向量要素的渲染；樣式型別包括但不限於 SLD、MapboxStyle 等

3. 能用 OGC API 了嗎

3.1. 各 API 實現情況（官方統計）

各個 API 在 GitHub 上基本上都是有獨立倉庫的，每個倉庫基本上都記錄了當前 API 的軟體實現情況，包括伺服器端軟體、前端庫、開發庫等，我挨個查閱後，將有記錄的 API 實現記錄檔案列舉如下：

OGC Feature API 實現列表
OGC Tiles API 實現列表
OGC Maps API 實現列表暫時未更新，不過 GeoServer 已經實現了部分草案
OGC 3DGeoVolumes API 實現列表本文釋出時只有簡單的 3DTiles 靜態檔案服務，還未看到 I3S
OGC Coverages API 實現列表
OGC Processes API 實現列表
OGC Records API 實現列表
OGC Joins API 實現列表這個 API 在文章釋出時還沒有實現
OGC Routes API 實現列表
OGC Styles API 實現列表

其餘尚未找到（也有可能是 OGC 還未公開其倉庫）。

請注意，這些連結由於 OGC API 仍然在制定過程中，不保證有效性，請自行存取對應的 GitHub 倉庫。

3.2. 前端地相簿的實現

介紹幾個比較有名的 JavaScript 庫實現。

① ArcGIS API for JavaScript

僅在 V4 支援 OGC Feature API，使用 OGCFeatuerLayer 即可。

② OpenLayers6

目前只支援 OGC Tiles API。

對於柵格瓦片，使用 ol/source/OGCMapTile 和 ol/layer/Tile 實現
對於向量瓦片（MVT格式），使用 ol/source/OGCVectorTile 和 ol/layer/VectorTile 實現

但是請注意，目前由於 OGC API 仍然不穩定，所以相關的類仍然沒有檔案，但是在官方的 Examples 中搜尋 OGC 是能看到例子的。

③ LeafletJS

使用擴充套件支援了 OGC Map API：GitLab - Leaflet.ImageOverlay.OGCAPI

3.3. GeoServer 的實現

請參考穩定版檔案 / 最新版檔案，簡單的說，GeoServer 在最新的 2.21 版本已經實現了 Tiles、Coverages、DGGS、Features、Images（這項是請求中的 API，官方網站上還沒有記錄，更能體現 OGC API 是一個開放的規範族）、Styles、Maps 這幾項 API。

3.4. 開發庫的支援

更多資源請到 GitHub 上搜尋。

4. 試用 GeoServer 的 OGC API

目前，僅在 2.18 以上版本看到有 OGC API 的社群擴充套件包。

https://build.geoserver.org/geoserver/

將對應版本的社群擴充套件包解壓到 WEB-INF/libs/ 目錄下後（要選擇替換），重啟 GeoServer 即可在主頁右側看到已經支援的 API

點選你想要進去的 API 的版本號，就可以在介面上看到對應的 API 了。

4.1. 已知 BUG

安裝 OGC API 後，GeoServer 的 WMTS 將會失效，原因未知。請勿在生產環境和有重要資料的個人 GeoServer 上實驗！！！

4.2. 試用 OGC Maps API

安裝好 OGC API 外掛後，在你的瀏覽器直接存取如下類似的 URL（注意你的埠、資料引數等）：

http://localhost:4800/geoserver/ogc/maps
/collections/spatial_base:guangxi_cities
/styles/polygon
/map
?transparent=true
&f=image%2Fpng
&layers=spatial_base%3Aguangxi_cities
&styles=polygon
&crs=EPSG%3A4326
&width=768
&height=553
&bbox=104.04052734375%2C20.6048583984375%2C112.47802734375%2C26.6802978515625

返回的是與 WMS 的 GetMap 幾乎一樣的結果：

除此之外，OGC Map API 也有別的操作，可以到 API 體驗頁面瞭解：

https://developer.ogc.org/api/maps/index.html （在 2.21 版本的 GeoServer 上還未整合本地 Swagger 供本地測試，否則存取 http://localhost:4800/geoserver/ogc/maps/api 即可本地測試，其餘 API 請讀者自行測試）

4.3. 試用 OGC Tiles API

Tiles API 的模板如下：

http://localhost:4800/geoserver/ogc/tiles
/collections/{layerName}
/styles/{style}
/map/tiles
/{tileMatrixSet}/{tileMatrix}/{tileRow}/{tileCol}?f={ImageMIMEType}

所以，發起一張瓦片請求：

http://localhost:4800/geoserver/ogc/tiles
/collections/spatial_base:guangxi_cities
/styles/polygon
/map/tiles
/EPSG:900913/EPSG:900913:7/55/103?f=image/png

得到的瓦片是：

比對 WMTS 的 REST 風格 URL：

http://localhost:4800/geoserver/gwc/service/wmts/rest
/spatial_base:guangxi_cities
/polygon
/EPSG:900913/EPSG:900913:7/55/103?format=image/png

風格相似，升級成本較低。

4.4. 試用 OGC Features API

http://localhost:4800/geoserver/ogc/features
/collections/spatial_base:guangxi_cities
/items
&limit=5

只查單個

http://localhost:4800/geoserver/ogc/features
/collections/spatial_base:guangxi_cities
/items/guangxi_cities.1

或

http://localhost:4800/geoserver/ogc/features
/collections/spatial_base:guangxi_cities
/items/1

查詢單個的返回結果：

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "id": "guangxi_cities.1",
      "geometry": {/* ... */},
      "geometry_name": "geom",
      "properties": {/* ... */}
    }
  ],
  "numberMatched": 1,
  "numberReturned": 1,
  "timeStamp": "2022-07-18T16:48:12.381Z",
  "links": [/* ... */]
}

比對 WFS 的鍵值對形式獲取簡直不要太方便，我認為 Features API 是一個非常不錯的升級。

至於 Features API 的第三部分：空間過濾，以及第四部分增刪改查（對應 WFS 中的 Transaction），還要等草案穩定和各大社群實現。

4.5. 試用 OGC Styles API

你可以直接用 API 請求工具存取你本機上 GeoServer 提供的 Styles API，類似：

http://localhost:4800/geoserver/ogc/styles
/styles

這個雙重 styles 可能會讓人有點迷惑，即 /styles/styles，其實後面那個 styles 是 GeoServer 預設的樣式集，名字就叫「styles」。這條查詢返回的是 GeoServer 上名為「styles」樣式集的所有樣式。

眾所周知，GeoServer 內建的樣式很醜，以內建的 polygon 樣式為例：

它其實是一個很簡單的 SLD 定義：

<?xml version="1.0" encoding="UTF-8"?>
<StyledLayerDescriptor version="1.0.0" 
 xsi:schemaLocation="http://www.opengis.net/sld StyledLayerDescriptor.xsd" 
 xmlns="http://www.opengis.net/sld" 
 xmlns:ogc="http://www.opengis.net/ogc" 
 xmlns:xlink="http://www.w3.org/1999/xlink" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <!-- a Named Layer is the basic building block of an SLD document -->
  <NamedLayer>
    <Name>default_polygon</Name>
    <UserStyle>
    <!-- Styles can have names, titles and abstracts -->
      <Title>Default Polygon</Title>
      <Abstract>A sample style that draws a polygon</Abstract>
      <!-- FeatureTypeStyles describe how to render different features -->
      <!-- A FeatureTypeStyle for rendering polygons -->
      <FeatureTypeStyle>
        <Rule>
          <Name>rule1</Name>
          <Title>Gray Polygon with Black Outline</Title>
          <Abstract>A polygon with a gray fill and a 1 pixel black outline</Abstract>
          <PolygonSymbolizer>
            <Fill>
              <CssParameter name="fill">#AAAAAA</CssParameter>
            </Fill>
            <Stroke>
              <CssParameter name="stroke">#000000</CssParameter>
              <CssParameter name="stroke-width">1</CssParameter>
            </Stroke>
          </PolygonSymbolizer>
        </Rule>
      </FeatureTypeStyle>
    </UserStyle>
  </NamedLayer>
</StyledLayerDescriptor>

SLD 實際上是一種 XML，是有規範的。上述這份 SLD，你可以這樣請求得到：

http://localhost:4800/geoserver/ogc/styles
/styles/polygon

樣式 API 其實算是比較簡單的一個，包括其增刪改查，點到為止。

5. 小結

OGC API 綜合看下來，各行各業，方方面面，基本上都有考慮到，而且十分專注地在討論「地理空間」，即使是來自偏研究領域的 DGGS API 和 EDR API，仍然認認真真地在寫技術規範、參與討論、實現 OpenAPI 的例子，積極與既有技術合併或直接提供實現的簡單案例，而不是國內虛無縹緲的概念。

哀嚎，行業究竟在幹什麼？沙難聚成塔呀...

其實，對於開發者而言，API 的作用就是請求，OGC API 為開發者或呼叫者做了約束，大多數地相簿並不需要完全支援所有的 OGC API，譬如 Feature API 就不需要 —— 正如同 WFS 於 CesiumJS/MapboxGL 一樣，你需要向量要素資料，你也知道有個 Features API 的資料來源，你就照著規範請求向量資料就好了。況且，或受制於技術水平，或受制於業務範圍，有的介面可能在應用過程中是完全不需要或者實現不了的，比如 Joins API、Routes API 等，只能等待社群給出封裝成果。

我認為使用者端可能需要接入的是 Tile API 或者 Map API，畢竟前端原生支援或擴充套件支援服務提供出來的地圖、瓦片才像是一個地相簿。

而像 Routes API、Joins API、MovingFeatures API 這幾個對後端資料庫、演演算法程式要求比較高的，就需要掂量掂量自己的斤兩，看看是等著用別人的成果，還是硬著頭皮自己實現了。

不過話說回來，2020 年到現在也才正式公佈了寥寥幾個 API 的基礎部分，等待這套 API 完全釋出、落實，我認為靠這行吃飯的朋友，如果沒有撬動國內整個行情的力量，還是老老實實用現有成果的好，科研隊伍反而更有空跟進了解。

或許是 WebGIS 下一代的資料規範