或许是 WebGIS 下一代的数据规范 - OGC API 系列

目录

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

新版 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 完全发布、落实，我认为靠这行吃饭的朋友，如果没有撬动国内整个行情的力量，还是老老实实用现有成果的好，科研队伍反而更有空跟进了解。