前言
Geotrellis 已经迭代到了 2.0 版本（截止写作此文时为 2.0.0-SNAPSHOT 版），2.0 版多了很多新的特性，其中最重要的应该就是 COG，COG 是什么鬼？刚看到时我也是一脸懵，认认真真的学习了一天，稍有体会，本文对此进行简单介绍。
一、COG 简介
1.1 什么是 COG
COG 是 Cloud Optimized GeoTIFF's 的简称，从这个名字就能大概猜出他的意义——云端优化的 GeoTIFF。GDAL 官方 WIKI 定义如下：
简单来说 COG 是规则的 GeoTIFF 文件，只是对普通 GeoTIFF 文件加了些概览等元数据信息，使得可以通过 HTTP 进行局部数据的读取，即需要哪部分的数据就下载哪部分数据。
那么这有什么好处呢？
1.2 COG 的好处
COG 的产生是针对云端文件的（cloud），现在有很多云存储供应商，如 S3、Google Cloud Storage、Azure 等等，GeoTIFF 文件存在云端最大的问题是每次对文件进行处理都需要将其全部取回到本地，处理完成后再上传到云端，这会耗费大量下载和上传的时间、占用存储空间，并且云存储多是根据流量收费，多次下载、上传又会增加网络费用支出。
于是 COG 便应运而生，他以云端为工作流的中心而非本地，不需每次处理 GeoTIFF 文件时将整个文件下载下来，只需要下载需要处理的部分，并且尽量实现数据的云端处理。
1.3 创建 COG
最简单的方式是通过 GDAL 创建 COG，GDAL 无需多言，凡是接触过地理信息的应该都知道此框架，执行如下命令：
gdal_translate in.tif out.tif -co TILED=YES -co COPY_SRC_OVERVIEWS=YES -co COMPRESS=DEFLATE
这样就可以将普通 GeoTIFF 文件转为 COG 文件，而后只需要将其发布为 HTTP 服务即可（文件下载服务），但是此 HTTP 服务必须支持 HTTP range queries，当前 Nginx、Apache 等都是支持此特性的，这也是断点续传的实现方式。当然你也可以直接将其上传到 S3 等云存储，会达到相同的效果。
二、COG 在 Geotrellis 中的应用
2.1 Geotrellis 当前工作流的弊端
在 Geotrellis 中要对一个数据进行处理，首先进行 ETL 操作，将数据 ingest 到其支持的后端中（S3、Hadoop、Accumulo、HBASE 等）形成 Layer 的概念，这样其实在后端中存储的是切割好的不同层级的大量小瓦片；然后再根据需求读出相应的瓦片进行处理或者发送到前端。
到了 2.0 版开发人员意识到一个问题，或者说是早就意识到了这个问题，那就是与 COG 建立的初衷相似，无论是 S3 还是 HDFS 其实都对大量小文件的支持不好、性能不高且占用大量的存储空间，严重影响服务性能。
2.2 COG 支持
于是 Geotrellis 开发人员想到将 COG 运用到此框架中。简单来说不再需要 ETL 操作，或者说是另外一种的 ETL 操作——将普通的 GeoTIFF 文件转换为 COG 文件。在转换的过程中也同样生成对应的元数据，这个元数据里描述的是如何找到x、y、z（SpatialKey 等）请求对应的数据，包括文件名称、存储位置、数据范围（HTTP Range）等，这样就可以通过此范围请求到此数据，并可以对此数据进行其他处理。
有了 COG 的支持，对 Geotrellis 来说无疑是如虎添翼，不仅解决了瓦片数据性能及占用大量存储空间的问题，也解决了瓦片切割耗时长的问题，数据处理不再耗用大量时间，当然任何事情都是辩证的，我猜测在数据读取的时候会比原有方式稍慢（未经过实际测试），这个还是要看系统的需求，平衡各方利弊之后设计满足自身需要的合理解决方案，这也正是一个“资深”程序员应当考虑的事情。
三、总结
本文简单介绍了 COG 以及其在 Geotrellis 中的使用，此处仅是理论和概念探讨，会在后续文章中详细介绍如何在 Geotrellis 中使用 COG。