特色栏目： python 批处理 net编程 Javascript Php Asp Css Html5 Android seo centos

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

来源：互联网收集：自由互联发布时间：2022-07-20

目录 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. 能用 OG

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

上一篇：十年架构五年生活-03作为技术组长的困扰
下一篇：没有了

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

相关文章