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

直至今日，GeoServer 仍在发挥作用，WebGIS 的几大服务规范仍在利用：

WMS，网络地图服务
WMTS，网络瓦片地图服务
WFS，网络因素服务

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

现有规范，有一些独特的特点。比方，申请行为较为依赖 XML —— 起因之于“大前端”还未流行的年代，后端罕用 XML，前端就只能用浏览器 API 解析返还的 XML。譬如，WFS 的批改因素的事务操作（Transaction，个别称之为 WFS-T），那写在申请体中的 XML 应用 JavaScript 来编写，就显得比拟干燥简短。

而当初，前后端职能拆散，前端倒退也引人注目，地图开发中，前端大多数时候更心愿发送、失去的是 JS 引擎更容易解析的 JSON，而不是 XML。

明天要介绍的这一套 OGC API，是 OGC 组织在 2 年前就始终在致力、下功夫的，他们把原来的 OGC 官网域名改了，LOGO 换了，甚至为这套 API 开拓了一个新的网站。

本文书写于 2022 年 7 月，这套 API 仍未齐全落地，本文仅作为疏导作用，并不能作为指导作用，所有以读者所在工夫点的状况为准，我介绍这套 API 仅仅是为了这个风尚塌实的行业带来点音讯，毕竟 OGC 官网这么大动作，国内居然找不到一篇文章，哪怕是简略介绍的都好啊。

本文仅保留著作权、解释权，欢送具名转载。

OGC API 目前有 13 个子类（含一个公共定义），而在去年的时候只有 9 个。只有合乎 OGC API 公共定义，就能够为行业中新生的数据需要制订网络申请接口标准。

本文介绍的 API 将来有可能会隐没其中某几个，也有可能会新增，所有以你看到的正式公布的版本为准。

最显著的特点可演绎为：

接口格调是 REST
数据传递默认为 JSON 格局

首先，给个官网：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 等

各个 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 仓库。

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

仅在 V4 反对 OGC Feature API，应用 OGCFeatuerLayer 即可。

目前只反对 OGC Tiles API。

对于栅格瓦片，应用 ol/source/OGCMapTile 和 ol/layer/Tile 实现
对于矢量瓦片（MVT 格局），应用 ol/source/OGCVectorTile 和 ol/layer/VectorTile 实现

然而请留神，目前因为 OGC API 依然不稳固，所以相干的类依然没有文档，然而在官网的 Examples 中搜寻 OGC 是能看到例子的。

应用扩大反对了 OGC Map API：GitLab – Leaflet.ImageOverlay.OGCAPI

请参考稳定版文档 / 最新版文档，简略的说，GeoServer 在最新的 2.21 版本曾经实现了 Tiles、Coverages、DGGS、Features、Images（这项是申请中的 API，官方网站上还没有记录，更能体现 OGC API 是一个凋谢的标准族）、Styles、Maps 这几项 API。

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

更多资源请到 GitHub 上搜寻。

目前，仅在 2.18 以上版本看到有 OGC API 的社区扩大包。

https://build.geoserver.org/g…

将对应版本的社区扩大包解压到 WEB-INF/libs/ 目录下后（要抉择替换），重启 GeoServer 即可在主页右侧看到曾经反对的 API

点击你想要进去的 API 的版本号，就能够在界面上看到对应的 API 了。

装置 OGC API 后，GeoServer 的 WMTS 将会生效，起因未知。请勿在生产环境和有重要数据的集体 GeoServer 上试验！！！

装置好 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…（在 2.21 版本的 GeoServer 上还未集成本地 Swagger 供本地测试，否则拜访 http://localhost:4800/geoserv… 即可本地测试，其余 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

格调类似，降级老本较低。

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），还要等草案稳固和各大社区实现。

你能够间接用 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 其实算是比较简单的一个，包含其增删改查，点到为止。

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

关于webgis:或许是-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. 小结