或許是 WebGIS 下一代的數據規範 - OGC API 系列

---

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. 開發庫的支持

• TypeScript - haoliangyu/ogcapi-js
• JavaScript - koopjs/provider-ogcapi-features
• Python - geopython/pygeoapi
• C# - sam-is/OgcApi.Net
• Rust - camptocamp/ogcapi
• Golang - WouterVisscher/ogcapi

更多資源請到 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 完全發佈、落實，我認爲靠這行喫飯的朋友，如果沒有撬動國內整個行情的力量，還是老老實實用現有成果的好，科研隊伍反而更有空跟進了解。