随着遥感对地观测技术的发展, 遥感数据在国土资源、海洋环境、气象等各行业中被广泛应用, 成为时空分析的重要数据来源。为更好地管理、共享这些遥感数据, 国内研究者基于分布式技术做了大量的基础研究^[1-4], 同时, 如何能够在数据持续更新情况下, 为不同领域的用户提供及时的、便捷的遥感数据共享服务, 成为遥感应用领域的研究热点。

遥感数据共享包括数据共享和数据预览。Web端的数据在线预览依赖于地图瓦片服务^[5], 分为预先渲染和动态创建两种方式: 预先渲染需要在瓦片生成完毕后才能提供服务, 具有更快的响应速度, 是构建地图瓦片服务的主要方式^[6-8]; 动态创建方式在节约计算资源方面更有优势^[9], 适合在数据持续更新情况下使用。目前, 国际上知名的地图服务商业化软件ArcGIS Server支持使用镶嵌数据集(mosaic dataset)插件实现影像瓦片的动态创建^[9]; 主流的开源地图服务软件GeoServer支持在不使用GWC(geowebcache)的情况下对遥感影像直接提供网络地图服务(web map service, WMS)服务。对于瓦片动态创建速度优化, 可以在原始数据内部增加Tiling和Overview^[10], 也可使用近年提出的云优化GeoTIFF格式(cloud optimized GeoTIFF, COG), 它具有高效地提取GeoTIFF文件中的子区域的特性^[11]。

主流地图服务软件支持瓦片的动态创建, 也有多种瓦片动态创建优化方法, 如今主流的地图服务软件中影像图层的发布需要手动指定参数, 不利于影像图层自动化发布; 遥感影像数据具有多源性, 无法采用统一方法优化瓦片动态创建速度^[12]。针对上述问题, 本文使用对象存储的WebHooks服务实现遥感影像数据向COG格式的自动转化, 利用COG格式的特性优化遥感影像瓦片动态创建的性能, 设计实现遥感影像自动发布的地图瓦片服务。

1 遥感影像瓦片快速动态创建基础 1.1 COG内部结构

COG是标准GeoTIFF格式, 其对内部结构的改动都服从于GeoTIFF标准中允许但非强制要求的部分, 具体结构^[13-14]如图 1所示。

头文件区中, 标准TIFF签名后有一个隐藏区(header ghost area), 包含自身的大小、图像文件目录(image file directory, IFD)的布局等描述信息^[13]。头文件区后面依次是全分辨率影像的IFD、略缩图的IFD和影像数据存储区域。

IFD是TIFF文件标准中一种文件头的定义框架, 实质上是一组灵活的标签, 包含影像数据在文件中的位置信息, 为文件读取提供捷径。COG中, 前16 kb的数据中包含了所有IFD^[14], 读取这部分数据就可以利用IFD访问数据局部, 提取目标信息。

1.2 COG特性

使用HTTP协议请求影像数据时, 可以在请求头中使用accept-ranges字段指定所需数据的范围, 这种方式称为范围请求(range requests)。利用范围请求, 只需访问COG部分数据, 就能从中提取头文件、空间子集等数据, COG中还为略缩图瓦片金字塔设计了专门结构, 可以在不读取完整数据的情况下预览影像。

为了分析COG部分读取与标准GeoTIFF总体读取的效率差异, 相关人员选用以下指标: (1) 单点的读取: 选取稍微偏离中心点的点, 读取该点的值。(2) 区域平均: 取一个不规则的范围做空间子集的模拟, 获取该子集的平均值。(3) 多波段影像读取: 取一个点, 输出该点在所有波段的值^[12]。通过对COG格式影像执行以上3种操作得到对比结果(如图 2), 在区域平均和单点读取中, 读取的字节数比率在5%~15%左右; 多波段影像访问时的读取比率较高, 但也只有25%左右, 相比总体访问模式效率提升明显。

地理空间数据抽象库(geospatial data abstraction library, GDAL)的虚拟文件系统(virtual file systems)支持使用/vsicurl前缀指向在线数据, 这种访问同样支持范围请求, 在此基础上, 地图瓦片服务的数据源将不再局限于自身文件系统中的数据, 还可以是局域网或互联网中的任意支持HTTP协议访问的数据。

2 遥感影像地图服务快速构建方法 2.1 影像数据存储

目前, 遥感影像存储方式大致分为三种: 关系数据库(空间数据中间件)、网络存储和分布式存储^[3]。其中对象存储是网络存储的一种, 使用REST和SOAP协议访问对象^[15], 架构简单、部署容易, 可以更好地发挥COG的特性, 本文设计的遥感影像地图服务中使用对象存储服务管理遥感影像数据。

对象存储中, 数据存储在桶(bucket)中, 桶中对象状态的变化可以通过事件广播监听, 利用事件广播的WebHooks接口, 设计遥感影像上传、更新时的触发器, 构建WebHooks监听服务, 流程如图 3所示。

WebHooks监听的触发事件采用S3中事件定义, S3是AWS(亚马逊云服务)的对象存储服务^[15], 其接口设计是目前行业事实标准^[16-17], 监听事件与触发事件的对应关系如表 1所示。

通过监听表 1中的事件, 完成遥感影像数据的格式转化和管理, 数据存储服务提供传统地图服务中图层管理的功能, 依据当前数据存储情况给客户端提供当前可用的图层信息。

2.2 影像地图发布

依据OGC的WMTS服务标准, 一次瓦片请求必须出现的参数如表 2所示。

在传统地图服务中, Layer参数指向的是一组配置, 这组配置包括原始数据地址、合成波段、空间范围等信息。除原始数据地址、合成波段外, 其余信息都可从原始数据头文件获取。本文利用Layer参数指定原始数据地址, 添加参数Indexes指定合成波段, 替代之前Layer参数的功能。

生成相同数据的不同瓦片时, 一些信息被重复计算, 如数据的值域范围等, 本文设计影像数据统计信息服务, 通过数据地址返回一个包含统计信息的JSON文本, 在正式请求瓦片之前, 先通过该服务获取影像数据的统计信息, 流程如图 4所示。

由图 4, 客户端从数据存储服务中获取可用的影像数据(图层)列表, 通过数据地址从统计信息服务中获取该数据统计信息, 之后将这些信息整合进请求参数中完成瓦片请求。

2.3 影像瓦片动态创建

在接到瓦片的动态创建指令后, 进入影像瓦片动态创建流程, 整个流程如图 5所示。

由图 5, 流程依次执行: 1) 解析参数, 计算虚拟变换参数与空间子集: 解析波段索引(Indexes), 获取合成波段; 解析瓦片矩阵(TileMatrix), 行号(TileRow)和列号(TileCol), 得出投影坐标系下的瓦片的空间范围, 最终计算出虚拟变换参数、瓦片空间子集。2) 读取瓦片数据: 依据虚拟变换参数, 从源数据创建虚拟变形数据集(warped virtual dataset), 根据波段顺序和空间子集读取瓦片数据。3) 线性拉伸: 依据该波段数据的值域范围对瓦片数据做线性拉伸, 提升显示效果。4) 无值区掩膜(mask)提取: 若存在alpha波段, 则将该波段作为无值区掩膜, 否则计算得到无值区掩膜。5) 图片渲染: 将处理后的瓦片数据与掩膜数据叠加, 渲染为图片。

2.4 影像瓦片缓存处理

为避免瓦片缓存对地图服务主进程的影响, 使用外置NoSQL数据库实现瓦片缓存, 设计瓦片缓存机制如图 6所示。

本文中瓦片唯一标识码的生成方法与GeoServer类似, 不同的是, 在GeoServer中, 为了兼顾WMS协议, 生成标识瓦片的唯一标识码时使用瓦片的外包矩形作为参数, 计算Hash值时为了保证外包矩形各坐标中浮点型精度, 增加计算量。本文生成方法使用原始数据地址、瓦片所在缩放等级和行列号以及其他参数计算出唯一标识, 其中缩放等级和行列号均为整数, 减少计算量, 过程如下: 1) 将请求参数按照特定方法排序, 并将请求参数统一转换为大写字符。2) 遍历排序后的请求参数序列, 将其拼接成以 & 字符连接的字符串。3) 计算字符串Hash值得到瓦片的唯一标识码。

对于每一次瓦片请求, 首先通过中间件根据计算出的唯一标识码确认是否有对应的缓存, 若已有缓存, 则直接返回缓存数据, 否则进入下个流程: 将该标识码与处理池已有的标识码比对, 若未找到相同的标识码, 进入生产流程; 若有相同值, 则线程进入等待状态, 直到该瓦片生产流程结束, 在一张瓦片生产流程结束后, 持有相同标识码的等待线程同步做出响应, 删除处理池中的该标识码, 通过异步的方式将瓦片缓存至瓦片缓存数据库。

3 应用实例与分析 3.1 应用环境与服务构建

实验选取主流开源地图服务器软件GeoServer作为对照, 应用环境配置如表 3所示。

GeoServer使用跨平台二进制2.16版本, 使用startup启动脚本运行。影像发布步骤为: 1) 手动执行格式转化命令, 将GeoTIFF影像转化为COG格式。2) 建立GeoTIFF格式的数据存储(datastore): 为数据存储命名, 指定源数据地址。3) 通过数据存储发布图层: 为图层命名, 选择坐标参考系统(CRS), 指定空间范围和合成波段顺序。

本文设计的遥感影像地图服务实现过程如下: 数据存储端, 考虑到易部署性和易拓展性, 选用MinIO(一款基于云原生技术的对象存储服务软件)构建服务, 编写Python脚本结合MinIO的WebHooks接口实现监听服务, 包括文件格式转化和缓存清理功能; 地图瓦片服务端, 使用rasterio(GDAL的Python绑定库)读取COG数据, 完成瓦片的提取, 使用aiohttp和asynio优化并发访问性能。瓦片缓存端, 选用高性能、支持数据持久化的Redis数据库配合本文设计的瓦片唯一标识码生成方法缓存瓦片数据。影像发布流程为使用MinIO管理工具将数据上传至对象存储服务。

3.2 数据与实验设计

数据使用无人机多波段DOM影像, 图 7为影像局部, 影像详细信息如表 4所示。

实验分两组对照, 一组使用GeoServer对同个数据两种格式(GeoTIFF和COG)分别提供地图瓦片服务, 通过响应速度验证COG在瓦片动态创建中的速度优势。另一组使用相同的COG数据, 使用GeoServer和本文设计实现的遥感影像地图服务分别提供地图瓦片服务, 通过响应时间测试两者在瓦片动态创建和处理缓存瓦片两个方面的性能差异。

实验过程中, 向地图服务发送若干并发请求, 记录各请求的响应时间, 为避免各瓦片包含的数据量不同影响结果, 测试用的瓦片(由缩放等级和行列号描述)集, 通过如下流程生成: 1) 读取影像的空间范围、有效缩放等级范围, 转换到投影坐标系。2) 对每个缩放等级, 计算空间范围左上和右下两个坐标所在的瓦片的行列号, 得到该缩放等级下所有瓦片, 形成瓦片集。3) 将瓦片集中的各瓦片的范围与空间范围做叠加分析, 移除未完全包含于空间范围的瓦片。4) 将瓦片集打乱顺序, 按照10、50和100的长度切片, 得到瓦片测试集。

为了避免客户端与服务端之间网络波动对结果的影响, 执行并发请求和结果统计的Python脚本在服务端运行, 结果中的响应时间不包含网络延迟。

3.3 结果分析

本文设计的遥感影像地图服务称为简化地图服务, 标准GeoTIFF格式称为非COG。

瓦片动态创建时, COG与非COG之间、两种服务之间性能对比如图 8所示。

由图 8可知, 使用非COG数据动态创建瓦片时, 响应时间显著增长, 由图 8c, 在处理100次并发请求中最后一个响应时, 使用COG与非COG之间响应时间相差超过2 min, COG有明显优势。

在同样使用COG格式时, 简化地图服务与GeoServer对比, 由图 8a, 在处理10次并发请求时, 平均响应速度更快; 由图 8b和图 8c, 在处理50次和100次并发请求时, 简化地图服务在处理前部少量请求时有速度优势, GeoServer总体响应时间更优。

处理已缓存瓦片时, 两种服务对比情况如图 9所示。

图 9结果表明, 简化地图服务在上述3组测试中, 响应速度保持在0.15 s之内, 而GeoServer的响应速度随着并发请求个数的增加显著增长, 依据图 9c, 在100次并发请求的测试中, 完成最后请求所用的时间超过0.4 s。

综上得出, 简化地图服务在动态创建瓦片的场景下, 性能与GeoServer各有优劣; 在瓦片已缓存的场景下比GeoServer表现更好。

4 结语

本文设计实现一种自动发布的地图影像瓦片服务, 相比传统方法构建的地图服务, 有以下优点:

1) 构建了自动处理工作流, 将源数据转化为COG格式, 加速瓦片动态创建。

2) 源数据在地图服务外部管理, 影像数据上传、更新时自动发布地图服务。

该方法构建的遥感影像地图服务依然存在不足, 源数据压缩后会影响瓦片动态创建的速度, 而存储未压缩的数据占用更多存储空间, 如何寻找两者间的平衡点还需进一步研究。