共计 8313 个字符,预计需要花费 21 分钟才能阅读完成。
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 一起应用,目前尚未看到实现,我认为这也是一个十分考验后端数据库组织能力的 APIOGC 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/g…
将对应版本的社区扩大包解压到 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…(在 2.21 版本的 GeoServer 上还未集成本地 Swagger 供本地测试,否则拜访 http://localhost:4800/geoserv… 即可本地测试,其余 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 齐全公布、落实,我认为靠这行吃饭的敌人,如果没有撬动国内整个行情的力量,还是老老实实用现有成绩的好,科研队伍反而更有空跟进理解。