1. 概述

越来越多的地理空间数据正在迁移到云，并且通常是存储在基于云的对象存储中。传统的 GIS 文件可以很容易的存储在云端，但是很难以在线的方式展示或者处理这些数据。如果想在线查看影像数据，通常需要提前做好切片、发布成服务，然后提供给客户端使用，这对于不经常变化的影像数据比较合适，但是对于需要及时在线查看的影像数据就会有很大难度，毕竟对影像数据切片需要考虑服务器的性能、文件大小以及切片的等级；在比如如果需要对影像数据进行处理，通常需要将它们完全下载到另一个位置，然后转换为某种格式或者存储在内存中。
Cloud Optimized GeoTIFF（简称 COG）通过一些技术实现了高效的数据流，从而实现了完全基于云的地理空间工作流程。越来越多的在线影像平台通过使用该技术对云上的影像提供在线浏览以及提供实时处理功能。
COG 文件本质上就是 GeoTIFF 文件。利用 GeoTIFF 标准的好处在于，所有的传统软件都可以在不需要额外修改的情况下读取 COG 文件，它们不会使用流媒体的功能，但是可以轻松地下载整个数据集并进行读取。
以 COG 格式提供数据有助于减少数据冗余。由于在线软件系统可以以流失传输数据，因此不需要保留自己的数据副本已进行高效的访问。数据提供只需要发布一个版本的数据，多个在线软件就可以同时访问数据，无需额外的下载。数据提供商也不需要提供多种文件格式，因为传统的系统可以读取与在线流媒体软件相同的 GeoTIFF。
COG 文件格式可提供的能力总结如下：

1. 有效地图像数据访问：可以感知 COG 的软件可以仅以数据流的方式获取所需的部分数据，从而缩短处理时间并创建以前不可能的实时工作流。
2. 减少数据的重复存储：使用云工作流的方式访问 COG 文件，使得各种软件能够在线访问单个文件，而不需要复制和缓存数据。
3. 旧版兼容性：传统的 GIS 软件能够像使用普通的 GeoTIFF 文件一样使用 COG 文件。

2. COG 工作原理

COG 依赖于两项互补的技术。第一个是 GeoTIFF 不仅能够存储图像的原始像素数据，而且还能够以特定的方式来组织这些像素。第二个是 HTTP Get Range 请求，它可以允许客户端请求他们仅需要的部门。COG 文件就是使用第一个技术组织 GeoTIFF，以便用户可以使用 Rang 请求轻松地选择文件中对处理有用的部分。

2.1 GeoTIFF：Tiling 和 Overviews

COG 中使用的2种用来组织 GeoTIFF 的技术：Tiling 和 Overviews，并且为了能够有效地在线传输，也对原始数据进行了压缩。
Tiling 组织的图像以瓦片的方式而不是以条带的方式来组织数据。假设一个场景，用户需要访问某个区域的数据，如果使用条带的方式来组织数据，则需要访问整个文件才能获取到关键数据；但如果使用瓦片的方式组织数据，只需要访问文件中需要读取的部分，可以更快地访问某个区域的数据。
Overviews 创建同一个图像的低采样版本，也就是说，它的表达效果是原始影像缩小的效果，能展示的细节要少得多，同时文件体积也要小得多。通常一个 GeoTIFF 会有许多 Overviews，用来匹配不同的缩放级别。这会增加文件的体积，但是能够更快地提供服务，因为图像渲染器只需要返回 Overviews 中的值，而不需要弄清楚如何将1000个像素表示为一个。
Tiling、Overviews 以及数据压缩的组合方式是使得软件能够快速访问图像的通用最佳实践，对于使用 Range 请求能够高效获取数据也更为重要。

2.2 HTTP Get Range 请求

HTTP 1.1 版本引入了一个非常酷的功能：Range 请求。当客户端向服务器端请求数据时，它在 GET 请求中发挥作用。如果服务器在其响应的 Header 中返回了Accept-Ranges：bytes，它会告诉客户端，可以从服务器端请求所需要的字节数据。这通常称为字节服务（Byte Service），它在互联网视频播放等场景下有成熟的应用，客户端不必下载整个文件就可以开始播放。
Range 请求是一个可选字段，因此不需要 Web 服务器强制实现，但是，大多数云厂商提供的对象存储服务都具备该功能。只要客户知道想要请求什么，存储在云上的大多数数据能够自动提供对应的数据。

2.3 技术原理

将使用 Tiling、Overviews 方式组织的 GeoTIFF 文件存放在支持 Range 请求的云存储上，客户端以 Range 的方式请求文件中的相关部分。当客户端想要快速渲染整个文件的图像时，Overviews 就会发挥作用，它不必下载每个像素数据，只需要请求更小、已经创建的 Overview 就可以。当整个文件的一小部分需要处理或者可视化时，Tiling 就会开始发挥作用。这可以是 Overview 的一部分，也可以是全分辨率的图像。但是 Tiling 将一个区域的所有相关字节组织在文件的同一部分，因此 Range 请求可以获取它所需要的内容。
虽然即使 GeoTIFF 没有通过 Tiling 或者 Overview 进行“云优化”处理，客户端也可以通过网络获取数据，但是如果实际上只需要很小的一部分数据时，它不得不下载整个文件或者其中的大部分数据。

3. 文件结构

COG 文件本质上是 GeoTIFF 文件，所以它的文件结构与 GeoTIFF 文件结构是一致的，只是为了能好地在线传输，COG 文件对于图像元数据以及像素数据的位置做了特殊规定。
在文件开头，COG 包含了全分辨率图像的元数据，然后是 Overview 元数据（这一部分是可选的），最后是图像本身。为了使其对流媒体或渐进式渲染更加友好，COG 标准建议以最小的 Overview 开始，然后以全分辨率图像结束。
具体来讲，COG 文件结构如下：

• IFH（包括字节序、TIFF/BigTIFF 文件标识、第一个 IFD 的偏移量）
• 全分辨率对应的 IFD
• IFD 目录中不适合内联的 TIFF TAG 的值，例如：TileOffsets、TileByteCounts 和 GeoTIFF 键
• （可选）第1个 Overview 的 IFD（通常以因子2进行采样），然后是不适合内联的 TAG 的值
• （可选）第2个 Overview 的 IFD（通常以因子4进行采样），然后是不适合内联的 TAG 的值
• ...
• （可选）最后一个 Overview 的 IFD（通常以因子2N进行采样），然后是不适合内联的 TAG 的值
• （可选）上一个 Overview 级别的瓦片内容
• ...
• （可选）第一个 Overview 级别的瓦片内容
• 全分辨率的瓦片内容

在生成 COG 文件时，需要注意以下2点内容：

• 瓦片的大小通常是256 或者512像素
• 需要使用压缩算法对数据进行压缩，其中，LZW 和 DEFLATE 是无损的，JPEG 是有损的。虽然 DEFLATE 比 LZW 压缩算法更快，但是可能会引起某些软件包的兼容性问题。