• 1. 前言
  • 1.1. 經典的 OGC 標準回顧
  • 1.2. 共同特點與時代變化
  • 1.3. 免責宣告
• 2. 什么是 OGC API
  • 2.1. OGC API 是一個開放、動態的規范族
  • 2.2. OGC API 特點
  • 2.3. 眾 API 簡述（2022年7月）
• 3. 能用 OGC API 了嗎
  • 3.1. 各 API 實作情況（官方統計）
  • 3.2. 前端地圖庫的實作
    • ① ArcGIS API for JavaScript
    • ② OpenLayers6
    • ③ LeafletJS
  • 3.3. GeoServer 的實作
  • 3.4. 開發庫的支持
• 4. 試用 GeoServer 的 OGC API
  • 4.1. 已知 BUG
  • 4.2. 試用 OGC Maps API
  • 4.3. 試用 OGC Tiles API
  • 4.4. 試用 OGC Features API
  • 4.5. 試用 OGC Styles API
• 5. 小結

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，見下表：

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

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

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

標籤：GIS

上一篇：Vue中關于this指向的問題

下一篇：京準電鐘北斗時鐘服務器,GPS網路時間服務器,NTP衛星授時系統