概述#
Cloud Optimized GeoTIFF (COG) 依賴兩種輔助技術。
-
第一種是 GeoTiff 的儲存能力：用特殊方式儲存像素，而不僅僅是將未處理的像素直接儲存起來。
-
第二種是 HTTP Get 支援的範圍請求，這種能力可以讓 client 只請求檔案中需要的那部分。
前者的 GeoTIFF 儲存方式，使後者的請求能方便地獲取檔案中需要被處理的那部分資料。
GeoTIFF 的組織方式#
COG 使用的兩種主要的資料組織技術是瓦片和概觀圖，資料的壓縮也使得資料在線傳輸變得更高效。
瓦片切片在影像中創建了內置了切片，而不是簡單地應用資料的條紋，使用資料的條紋的話，想要獲取指定的資料需要讀取整個資料，當切片可以在指定區域快速被獲取到成為可能之後，同樣的需求只需要訪問資料的特定部分就可以了。
概觀圖創建了同個影像的向下取樣的多個版本。向下取樣的意思是當從一個原始影像 ' 縮小 ' 時，有很多細節消失掉了（當前的 1 個像素在原始影像中可能存在 100 個甚至 1000 個像素），同時它的資料量也更小。通常一個 GeoTIFF 會有多個概觀圖來匹配不同縮放等級。這使得服務端的響應變得更快，因為渲染時只需要返回這個特定的像素值即可，無需再來找出用哪個像素值來表示這 1000 個像素，但是這也會使得整個檔案的體積變大。
通過資料的壓縮，會使軟體能夠快速獲取影像，通常會有更好的用戶體驗，但是使 HTTP GET 的範圍請求的工作更有效率依然是非常重要的。
HTTP Get 範圍請求#
HTTP 的 1.1 版本引入了一個非常牛的功能：範圍請求，在 client 請求服務端資料的 GET 請求時使用。如果服務端在 response 的 header 中有Accept-Ranges: bytes，這就說明資料中的 bytes 可以被客戶端用任何想用的方式分塊的請求。這通常也被稱為 "Byte Serving", 維基百科中有文章詳細解釋了其工作原理。client 可以從服務端請求需要的 bytes，在 Web 領域，這被廣泛地應用，例如視頻服務，這樣，client 就不需要下載下整個檔案就可以來操作它了。
範圍請求是一個可選的字段，所以服務端並非必須要實現它。但是大多數的雲服務提供商（Amazon, Google, Microsoft, OpenStack 等）的對象儲存工具提供了這個選項。所以大多數的儲存在雲上的資料已經能夠提供範圍請求的服務。
整合#
介紹過這兩個技術之後，兩個部分之間如何一起工作就變得很明顯了。GeoTIFF 中的瓦片和概觀圖以確定的結構儲存在雲端的檔案中，這樣，範圍請求就能請求到檔案中相關的部分了。
概觀圖在 client 想要渲染一個整幅影像的快視圖時起作用，整個過程不需要下載每一個像素，這樣一來，請求變成請求體積更小、預先創建的概觀圖。GeoTIFF 檔案特定的結構在支援 HTTP 範圍請求的服務端就能使 client 輕鬆地獲取整個檔案中需要的那部分。
切片在一些整幅影像的局部需要被處理或者可視化的時候發揮作用。這可以是概觀圖的一部分，也可以是全分辨率的。需要注意的是，瓦片組織所有的相關資料的區域在檔案中的相同位置，所以範圍請求可以在需要的時候獲取它。
如果 GeoTIFF 沒有被用概觀圖和切片 ‘cloud optimized’ 過，同樣也能進行一些遠程操作，但是它們需要下載整個資料或者需要下載的資料量超過實際需求的的資料。
優勢#
越來越多的地理資訊資料被遷移到了雲端☁️，而且其中大多數被儲存在基於雲服務的對象儲存中，比如 S3 or Google Cloud Storage，傳統的 GIS 檔案格式能夠方便的儲存在雲端，但是對於提供 Web 地圖瓦片服務或者執行快速的資料處理時，這些格式就不再保持高效了，通常需要將資料全部下載到另一個地方，之後再轉換為更優化的格式或者讀入內存中。
Cloud Optimized GeoTIFF 通過一些 小技術使得使得資料流更高效，使得基於雲服務的地理資料工作流成為可能。在線影像平台比如 Planet Platform 和 GBDX 使用這種方式提供影像服務從而使影像處理非常快速。使用 COG 技術的軟體能通過獲取需要的資料的那部分來優化執行時間。
許多新的地理資訊軟體比如GeoTrellis, Google Earth Engine 和 IDAHO 同樣在他們的軟體架構中使用了 COG 的理念。每一個處理節點高速執行影像處理通過獲取 COG 的部分的檔案流。
對於現有的 GeoTIFF 標準的影響，不像引入一個新的檔案格式。因為當前的軟體不需要任何的修改也能夠讀取 COG。它們不需要具備處理流檔案的能力，只需要簡單地將整個檔案下載下來並且讀取即可。
在雲端提供 Cloud Optimized GeoTIFF 格式的檔案能夠幫助減少大量的檔案拷貝。因為在線的軟體能使用流檔案而不需要保留其自己的副本，這就變得更加高效，也是當今一種通用的模式。此外，資料提供商無需提供多種格式的資料，因為老式軟體和新式軟體同樣能讀取這些資料。資料提供商只需要更新一個版本的資料，與此同時，無需多餘的拷貝和下載，多種在線軟體都能夠同時使用它。
快速入門#
前言#
這個教程說明開發者如何使用和生產 Cloud Optimized GeoTIFF。
讀取#
最簡單的使用方式是使用 GDAL 的VSI Curl 功能。可以閱讀 GDAL Wiki 在How to read it with GDAL小節。當今大多數的地理資訊軟體都在使用 GDAL 作為依賴庫，所以引入 GDAL 是讀取 COG 功能的最快方式。
Planet 上，所有的資料都已經是 COG 格式，關於下載有一個小教程： download part of an image 。 大多數教程只講了關於 Planet API 的使用方法，但也說明了 GDAL Warp 怎樣從大的 COG 檔案中提取單個工作區域。
創建#
同樣在 GDAL wiki 關於 COG 的頁面，How to generate it with GDAL。
$ gdal_translate in.tif out.tif -co TILED=YES -co COPY_SRC_OVERVIEWS=YES -co COMPRESS=DEFLATE
或者使用rio-cogeo plugin:
$ rio cogeo create in.tif out.tif --cog-profile deflate
與多其他的地理資訊軟體應該也能夠添加合適的縮圖和切片。
驗證#
使用 rio-cogeo plugin:
$ rio cogeo validate test.tif