其他分享
首页 > 其他分享> > 或许是 WebGIS 下一代的数据规范 - OGC API 系列

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

作者：互联网

目录

1. 前言

1.1. 经典的 OGC 标准回顾

直至今日，GeoServer 仍在发挥作用，WebGIS 的几大服务标准仍在应用：

这三个应该是耳熟能详的了，还有其它的就不列举了，本篇的重点并不是介绍这些现行标准，上面三个标准的速查可参考我往期的文章。

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 特点

最显著的特点可归纳为：

2.3. 众 API 简述（2022年7月）

首先，给个官网：OGC API

OGC API 是迎着近十年来前端技术飞速发展的趋势应运而生的，它与上述几个旧标准最大的区别是：

这一系列的 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 个要陌生，所以额外多解释一番：

3. 能用 OGC API 了吗

3.1. 各 API 实现情况（官方统计）

各个 API 在 GitHub 上基本上都是有独立仓库的，每个仓库基本上都记录了当前 API 的软件实现情况，包括服务端软件、前端库、开发库等，我挨个查阅后，将有记录的 API 实现记录文档列举如下：

其余尚未找到（也有可能是 OGC 还未公开其仓库）。

请注意，这些链接由于 OGC API 仍然在制定过程中，不保证有效性，请自行访问对应的 GitHub 仓库。

3.2. 前端地图库的实现

介绍几个比较有名的 JavaScript 库实现。

① ArcGIS API for JavaScript

仅在 V4 支持 OGC Feature API，使用 OGCFeatuerLayer 即可。

② OpenLayers6

目前只支持 OGC Tiles API。

但是请注意，目前由于 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

image

点击你想要进去的 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 几乎一样的结果：

image

除此之外，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

得到的瓦片是：

image

比对 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 样式为例：

image

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

标签：styles,Features,实现,WebGIS,API,GeoServer,OGC
来源： https://www.cnblogs.com/onsummer/p/what-is-ogc-api.html