Open Geospatial Consortium

Submission Date: 2022-06-29

Approval Date:   <yyyy-mm-dd>

Publication Date:   <yyyy-mm-dd>

External identifier of this OGC® document: http://www.opengis.net/doc/{doc-type}/{standard}/{m.n}

Internal reference number of this OGC® document:    21-026

Version: n.n

Category: OGC® Implementation Standard

Editor:   Joan Maso

OGC Cloud Optimized GeoTIFF standard candidate

Copyright notice

Copyright © 2022 Open Geospatial Consortium

To obtain additional rights of use, visit http://www.opengeospatial.org/legal/

Warning

This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Document type:    OGC® Standard

Document subtype:   

Document stage:    Draft

Document language:  English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.

THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

i. Abstract

The Cloud Optimized GeoTIFF (COG) relies on two characteristics of the TIFF v6 format (tiles and reduced resolution subfiles), GeoTIFF keys for georeference, and the HTTP range, which allows for efficient downloading of parts of imagery and grid coverage data on the web and to make fast data visualization of TIFF of BigTIFF files and fast geospatial processing workflows possible. COG aware applications can download only the information they need to visualize or process the data on the web. Numerous remote sensing datasets are available in cloud storage facilities that can benefit from optimized visualization and processing. This standard formalizes the requirements for a TIFF file to become a COG file and for the HTTP server to make COG files available fast on the web.

ii. Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, Cloud, GeoTIFF, Imagery, Web

iii. Preface

COG was previously defined by a community of users with the intention of improving the distribution of remote sensing images on the cloud. This document respects the decisions taken and conventions adopted by the community and formalizes them in standard requirements and recommendations. The standard name still reflects this original purpose: a format optimized for the cloud. Similar principles are applied to other emerging formats such as Zarr (https://zarr.readthedocs.io/en/stable/) and Cloud Optimized Point Cloud (https://copc.io/).

This document depends on the TIFF specification and the GeoTIFF standard. For big files, it may depend on the BigTIFF community standard. The standard takes advantage of some existing characteristics of the TIFF specification and the existing HTTP range specification and does not modify them in anyway.

iv. Security Considerations

Cloud Optimized GeoTIFF mainly describes a data format. Security considerations for implementations utilizing Cloud Optimized GeoTIFF are in the domain of the implementing application, deployment platform, operating system, networking environment and web browsers.

In general, this standard does not place constraints on application, platform, operating system level, network or web browser security. However, this standard has a requirements class that requires "HTTP range". Attention has been made to also allow secure variants of HTTP such as HTTPS and still be able to mix data from different origins in web browsers using HTTP range. In that respect, considerations to support Cross Origin Resource Sharing (CORS) are done in the document. In particular, servers are encouraged to advertise the support for HTTP ranges in the Control-Allow-Headers header to allow for HTTPS CORS.

Note
 The security measures discussed in the following sections only allow various kinds of authentication under HTTPS. HTTPS only provides confidentiality or encryption at the protocol level. Confidentiality or encryption at the data level is not discussed by this standard.

v. Submitting organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

  • UAB-CREAF

  • Planet Labs PBC

  • Spatialys

  • Development Seed

vi. Submitters

All questions regarding this submission should be directed to the editor or the submitters:

Name

Affiliation

Joan Maso

UAB-CREAF

Quinn Scripter

Planet Labs PBC

Even Rouault

Spatialys

Vincent Sarago

Development Seed

1. Scope

This document is an OGC standard that specifies how TIFF files can be organized in a way that favors the extraction of convenient parts of the data at the needed resolution for visualization or analysis purposes. It also specifies how to use HTTP (or HTTPS) to communicate only the part of information needed without downloading the complete file.

This document depends on the TIFF specification and the GeoTIFF standard. For big files, it depends on the BigTIFF community standard. The standard takes advantage of some existing characteristics of the TIFF specification and the existing HTTP range RFC and does not modify them in anyway.

2. Conformance

This Standard defines 4 conformance classes.

Requirement Class GeoTIFF Tiles (http://www.opengis.net/spec/COG/1.0/req/req-class-geotiff-format)

Defines what characteristics of the TIFF (or BigTIFF) format should be used. Target: TIFF Encoders (and COG clients)

Requirement Class GeoTIFF Overviews (http://www.opengis.net/spec/COG/1.0/req/req-class-geotiff-overviews)

Defines the overview characteristics of the TIFF (or BigTIFF) format that should be used. Target: TIFF Encoders (and COG clients)

Requirement Class GeoTIFF Keys (http://www.opengis.net/spec/COG/1.0/req/req-class-http-range)

Defines how to use COG in the web to download only a fragment of the data. Target: A web Server (and COG web clients)

Requirement Class HTTP range http://www.opengis.net/spec/COG/1.0/req/req-class-geotiff-keys

Defines how to use GeoKeys to georeference the data. Target: GeoTIFF encoders

Conformance with this Standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.

In order to conform to this OGC Standard, a software implementation shall choose to implement: * Any one or more of the conformance levels specified in Annex A (normative).

All requirements-classes and conformance-classes described in this document are owned by the Standard(s) identified.

Note
 Currently there is no way to list the conformance classes that a GeoTIFF file conforms to, so the COG is not specifying how to do so.

3. References

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

Adobe development association. TIFF Revision 6.0 Final — June 3, (1992) https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf

Fielding R., Lafonand Y., Reschke J.: Hypertext Transfer Protocol (HTTP/1.1): Range Requests. RFC 7233. Internet Engineering Task Force (IETF). ISSN: 2070-1721 (2014) https://datatracker.ietf.org/doc/html/rfc7233

Devys E., Habermann T., Heazel C., Lott R., Rouault E.: OGC GeoTIFF Standard. OGC 19-008r4. (2019) http://docs.opengeospatial.org/is/19-008r4/19-008r4.html

van Damme J.: The BigTIFF File Format. https://www.awaresystems.be/imaging/tiff/bigtiff.html (No normative reference)

4. Terms and Definitions

This document used the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the 'ModSpec'. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

4.1. cloud computing

on-demand availability of computer system resources, especially data storage (cloud storage) and computing power, without direct active management by the user [Wikipedia]

4.2. geokey

key in a GeoTIFF equivalent in function to a TIFF tag, but using a different offset mechanism

4.2. GeoTIFF

standard for storing georeference and geocoding information in a TIFF 6.0 compliant raster file or in a BigTIFF [GeoTIFF Format Specification 1.0, modified]

4.3. overview

downsampled versions of the same image.

Note
 There is no mention of the term overview in the TIFF v6 specification. This standard favors the use of the expression Reduced-Resolution Subfile to talk about an overview
4.3. tag

packet of numerical or ASCII values, which have a numerical TIFF "Tag" identifier indicating their information content

4.4. tile

geometric shape with known properties that may or may not be the result of a tiling (tessellation) process. A tile consists of a single connected "piece" (topological disc) without "holes" or "lines" [OGC 19-014r3]+

In the context of a 2D tile matrix, a tile is one of the rectangular regions of space, which can be uniquely identified by an integer row and column, making up the tile matrix.

In the context of a geospatial data tile set, a tile contains data for such a partition of space as part of an overall set of tiles for that tiled geospatial data. [OGC 2DTMS]

4.5. subfile

mechanism for including multiple images in a single TIFF file based on the use of IFDs

5. Conventions

This section provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.

5.1. Abbreviations

BigTIFF

Big Tagged Image File Format
COG

Cloud Optimized GeoTIFF
CORS

Cross-Origin Resource Sharing
EPSG

Registry of CRS descriptions maintained by the International Association of Oil and Gas Producers (IOGP) formerly known as the "European Petroleum Survey Group (EPSG)" and currently used only as an acronym
HTTP

Hypertext Transfer Protocol
HTTPS

Hypertext Transfer Protocol Secure
IFD

Image File Directory
TIFF

Tagged Image File Format

5.2. Identifiers

The normative provisions in this Standard are denoted by the URI

http://www.opengis.net/spec/cog/{m.n}

All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.

6. Overview

Traditionally, high resolution imagery over the web requires that big files have to be entirely downloaded to the client before they can be analyzed or visualized. In the past these files were provided by servers in the provider premises. Depending on the circumstances, this process can require considerable download time thus preventing the creation of responsive real time applications. Nowadays, cloud services offer almost unlimited storage but the cost of the service depends on the intensity of use. The solution to the problems specified here is called Cloud Optimized GeoTIFF (COG) that is based on a particular usage of one of the most popular formats in the world: the TIFF format.

The TIFF format was created by the Aldus Corporation for use in desktop publishing. Aldus released the last version of the TIFF specification in 1992 (v. 6.0), subsequently only updated with an Adobe Systems copyright after the Adobe acquired Aldus in 1994. Several Aldus or Adobe technical notes have been published with minor extensions to the format, and several specifications have been based on TIFF 6.0, including TIFF/EP (ISO 12234-2), TIFF/IT (ISO 12639), TIFF-F (RFC 2306) and TIFF-FX (RFC 3949), GeoTIFF (OGC 19-008r4, v1.1) and BigTIFF.

TIFF is a flexible, adaptable file format for handling images and data within a single file, by including the header tags (size, definition, image-data arrangement, applied image compression) that provide metadata about the images. The ability to store image data in a lossless format makes a TIFF file a useful image archive. TIFF can be used to store grey scale, color or RGB images as well as integer of floating point data, making it ideal as a support for storing the rangeset of a 2D grid coverage data.

To improve TIFF performance over the web, COG relies on two characteristics of the TIFF v6 format, the georeference GeoTIFF keys and a relatively unused HTTP property. This way, COG allows for efficient downloading of parts of imagery and grid coverage data on the web, enables fast data visualization and facilitates faster geospatial processing workflows. This particular type of TIFF has been recently used to set up a large series of remote sensing images on cloud providers repositories (e.g. Amazon Web Services), enabling cloud processing at lower traffic. In fact, COG-aware software can request just the portions of data that it needs, improving access time and bandwidth.

COG is based on the GeoTIFF standard and does not introduce additional capabilities to the TIFF v6. As such, legacy software should be able to read COG files with no additional modifications. However, legacy software will not be able to take advantage of the streaming (understood here as partial download) capabilities, but still can easily download the whole file and read it.

The amount of data available for geospatial analytics has increased considerably in recent years. Therefore, downloading the data into a single computer is often not feasible. Data producers that provide data in the COG format can help decrease how much data is downloaded and copied. This is because online software systems do not need to keep their own copy of the data for efficient access. New online software can access the content efficiently, while old versions can still download the data completely. This avoids the need to have two copies of the file: one for fast access and another for download purposes.

COG relies on two complementary approaches already available in the existing standards to achieve its goal:

  • The first is the ability of GeoTIFF to store the raw pixels of the image organized in an efficient way using tiles and overviews

  • The second is HTTP GET Range request, that let web clients request just the portions of a file that they need.

Using the first approach, COG organizes the GeoTIFF so the latter requests can easily select and get the parts of the file that are useful for processing.

6.1. Efficient organization of data in a TIFF file

The Tiling and Reduced-Resolution Subfiles (sometimes called overviews) in the GeoTIFF format supports the necessary structure for COG files so that the HTTP GET Range queries can request just the part of the file that is relevant.

Reduced-Resolution Subfiles come into play when the client wants to render a quick image of the whole or a big part of the area represented in the file. Instead of downloading every pixel, the software can just request a smaller, already created, lower resolution version. The structure of the COG file on an HTTP Range supporting web server enables client software to easily find and download just the part of the whole file that is needed.

Tiles come into play when some small area of the overall extent of the COG file needs to be processed or visualized. This could be part of a reduced-resolution subfile, or it could be at full resolution. Tile organization makes all the relevant bytes of an area (a tile) to be in the same part of the file, so the software can use HTTP GET Range request to get only the tiles it needs.

6.2. Relation to OGC Tile Set Standards

The combined use of tiles and resolution levels is not new in OGC standards. In fact the OGC Two-dimensional Tile Matrix Set standard (and the older OGC WMTS 1.0) use exactly the same approach. However, the OGC API - Tiles standard and the older WMTS 1.0 standard require either a service to be installed in the web server provider or thousands of pre-generated independent files (one for each tile) to be created. None of this is necessary in the COG approach as most of the modern web services natively support HTTP range.

7. GeoTIFF format requirements

A COG file is a file that conforms to a subset of the TIFF specification (or the BigTIFF specification) and adheres to the GeoTIFF tag requirements. A COG uses two main organization techniques available in the TIFF version 6.0 specification: Tiling and Reduced-Resolution Subfiles (sometimes called Overviews). The tiled data can also be compressed for more efficient passage online. In addition, a COG file uses the GeoTIFF conventions for storing the relevant geospatial metadata. For convenience, Tiling and Reduced-Resolution Subfiles are presented in two independent conformance classes.

7.1. Requirement Class GeoTIFF Tiles

Requirements Class

http://www.opengis.net/spec/COG/1.0/req/req-class-geotiff-format

Target type

TIFF Encoder

Dependency

http://www.opengis.net/spec/GeoTIFF/1.1/req/Core

Dependency

https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf

Dependency

bigtiff.org

7.1.1. Basic format

A COG file is a TIFF or a BigTiFF file.

Requirement 1

/req/req-class-geotiff-format/use-geotiff

A

If the resulting COG file is bigger than 4 GByte, the COG file SHALL follow the BigTIFF standard that modifies the TIFF version 6.0 standard

Recommendation 1

/rec/rec-class-geotiff-format/use-geotiff

A

If the resulting COG file is smaller than 4 GByte a COG file SHOULD follow the TIFF version 6.0 standard

7.1.2. Tiles

In the context for a TIFF file, Tiling is a strategy for dividing the content in the TIFF file differently than using the classical Strips. In the Strips approach the data are organized into sequences of lines (rows) while tiling creates a number of internal rectangular tiles stored in the actual image. In Tiling the information related to a particular bounding box is easier to extract as it is closer in the file than in the strips approach. Actually, with strips all data from the previous rows needs to be read to get to the following rows. With tiling, a much quicker access to a certain area is possible so that the portion of the file that needs to be read can be adjusted to better match the application needs.

Requirement 2

/req/req-class-geotiff-format/tiling

A

All Image File Directories (IFD) in a COG file SHALL be organized into tiles (instead of strips) as described in section 15 of the TIFF version 6.0 specification

Note
 The ability to have multiple Image File Directories (IFD) becomes important when the COG has also overviews. See the next requirements class for more details.

Tiles, as defined in the TIFF version 6.0 specification, can be mapped to the ones defined in the OGC Two Dimensional Tile Matrix Set Standard (2D-TMS). For example in 2D-TMS, the TIFF 6.0 forces all tiles to be of the same size. This is possible with the introduction of the concept of padding: If necessary extra blank rows or columns are added to the right-most and bottom-most tile to make them the same shape as other tiles. However, the naming of the TIFF tags used version 6.0 and the property names used in the 2D-TMS differ. The following table provides a mapping between the two standards.

Table 1. Mapping between the OGC the 2D-TMS standard and the TIFF version 6.0, section 15
OGC 2D-TMS TIFF v. 6.0 Definition

TileWidth

TileWidth

The tile width in pixels. The number of columns in each tile

TileHeight

TileLength

The tile height in pixels. The number of rows in each tile

MatrixWidth

TilesAcross

Number of tiles in the width direction

MatrixHeight

TilesDown

Number of tiles in the height direction

Please note that the TIFF 6.0 specification imposes the requirement that TileWidth and TileLength must be a multiple of 16. The specification argues that this restriction improves performance in some graphics environments and enhances compatibility with compression schemes such as JPEG. There is no such restriction in the OGC 2D-TMS.

7.1.3. Compression

Compression of the bytes is a general best practice for enabling software to quickly access data, in particular over the network. The combination of compression with the HTTP GET Range requests maximizes efficiency. HTTP GET Range will be standardized in another requirements class.

Recommendation 2

/rec/rec-class-geotiff/rec-compression

A

In a COG file, tiled data should be compressed efficiently

7.1.4. Planar Configuration considerations

When more than component is encoded in a TIFF file, the TIFF provides two possibilities:

  • The component values for each pixel are stored contiguously. This is marked in the file as PlanarConfiguration=Contig (a.k.a. Chunky format, value 1). This is a common arrangement for RGB combinations of bands. The data is stored as RGBRGBRGB… (this arrangement is also known as Band Interleaved by Pixel, BIP)

  • The components are stored in separate component planes. This is marked in the file as PlanarConfiguration=Separate (a.k.a. Planar format, value 2). This is the common arrangement for the bands of a multispectral image (this arrangement is also known as Band Sequential, BSQ).

Note
 (extracted from the TIFF 6.0 specification) PlanarConfiguration=2 is not currently [written in 1992] in widespread use and it is not recommended for general interchange.

Following this note, most common implementations of the COG encoders (e.g. GDAL) use PlanarConfiguration=1 (see https://gdal.org/drivers/raster/cog.html#high-level).

7.2. Requirement Class GeoTIFF Overviews

Requirements Class

http://www.opengis.net/spec/COG/1.0/req/req-class-geotiff-overviews

Target type

TIFF encoder

Dependency

http://www.opengis.net/spec/COG/1.0/req/req-class-geotiff-format

7.2.1. Requirement Reduced-Resolution Subfiles

Reduced-Resolution Subfiles (a.k.a Overviews) are down sampled versions of the same image included in the same TIFF file. This means that an overview is a zoomed out version from the original image. It has less detail but is also smaller. For visualization purposes or for analytical processes that do not require full resolution, a COG can provide Reduced-Resolution Subfiles that match different scale denominators or cell sizes required by clients. Reduced-Resolution Subfiles increase the size of the file but also increase performance.

Note
 The general description of the COG use the concept of overviews. Actually, there is nothing called overviews in the TIFF version 6.0 specification. Instead, the TIFF version 6.0 describes how a TIFF file can be composed of one or more images, each one stored in an Image File Directories (IFD). Some IFDs may contain reduced-resolution subfiles. This is the reason why this standard favors the use of the expression Reduced-Resolution Subfiles to talk about overviews.

There may be more than one IFD in a TIFF file and each IFD indicates the offset of the next IFD sits in the file (or 0 if no other IFD is available). Each IFD defines a subfile. Having images as subfiles has several applications. The NewSubfileType entry specifies several types of subfiles, among which we distinguish: - IFD with a NewSubfileType tag whose bit 0 is not set, or without a NewSubfileType tag, to mean a full-resolution image data - IFD with a NewSubfileType tag whose bit 0 is set, to mean a reduced-resolution image data of the full resolution one.

Requirement 3

/req/req-class-geotiff-overviews/overviews

A

A COG file SHALL have at least one IFD with a NewSubfileType tag whose bit 0 is not set, or without a NewSubfileType tag (full-resolution image data).

B

An IFD with a NewSubfileType tag whose bit 0 is not set, or without a NewSubfileType tag SHALL have an offset to the next IFD that will point to an IFD with a NewSubfileType tag whose bit 0 is set (reduced-resolution image data), or 0 if there is no reduced-resolution image.

C

This IFD with a NewSubfileType tag whose bit 0 is set SHALL have an Image Width an Image Height inferior than the previous IFD.

D

If other reduced resolution images are needed, a IFD with a NewSubfileType tag whose bit 0 is set SHALL have an offset to the next IFD that will point to an IFD with a NewSubfileType tag whose bit 0 is set (reduced-resolution image data).

E

This additional IFD with a NewSubfileType tag whose bit 0 is set SHALL have an Image Width an Image Height inferior than the previous IFD.

Note
 The presence of reduced-resolution subfiles in a COG file is optional. Only the COG files that conform to this conformance class are forced to have reduced-resolution subfiles.

Recommendation 3

/rec/rec-class-geotiff/ifd-order

A

In a COG file, and after the TIFF/BigTIFF header/signature and pointer to first IFD (and an eventual ghost area) sections SHOULD follow the following order:

1. IFD of the full resolution image, followed by TIFF tags values, excluding the TileOffsets and TileByteCounts arrays.

2. IFD of the mask of the full resolution image, if present, followed by TIFF tags values, excluding the TileOffsets and TileByteCounts arrays.

3. IFD of the first (largest in dimensions) Reduced-Resolution Subfile, if present

4. …​

5. IFD of the last (smallest) Reduced-Resolution Subfile, if present

6. IFD of the first (largest in dimensions) Reduced-Resolution Subfile of the mask, if present

7. …​

8. IFD of the last (smallest) Reduced-Resolution Subfile of the mask, if present TileOffsets and TileByteCounts arrays of the above IFDs

9. tile data of the smallest Reduced-Resolution Subfile, if present (with each tile followed by the corresponding tile of mask data, if present), with leader and trailer bytes

10. …​

11. tile data of the largest Reduced-Resolution Subfile, if present (interleaved with mask data if present)

12. tile data of the full resolution image, if present (interleaved with corresponding mask data if present)
Note
 There can be more than one full-resolution image data in the file. In this case, each full-resolution image data will be contiguous to its reduced-resolution subfiles and their IFDs.

7.3. Requirement Class GeoTIFF Keys

The GeoTIFF standard defines a mechanism to add GeoTIFF keys to a TIFF file. The main purpose of these keys is to add a geospatial reference to the data stored in the TIFF file. In a COG, GeoTIFF keys are a fundamental part of the standard as most of the COG files are geospatially referenced TIFFs.

Requirements Class

http://www.opengis.net/spec/COG/1.0/req/req-class-geotiff-keys

Target type

GeoTIFF Encoder

Dependency

http://www.opengis.net/spec/COG/1.0/req/req-class-geotiff-format

7.3.1. Requirement GeoTIFF

A COG uses GeoTIFF to document the metadata about the TIFF file.

Requirement 4

/req/req-class-geotiff-format/basic-metadata-format

A

A COG file SHALL include and encode geospatial metadata in the GeoTIFF format following the GeoTIFF standard

7.3.2. Requirement Georeference Keys

There is a geometrical relation between the reduced-resolution subfiles and the corresponding full-resolution subfile. Only full-resolution subfiles are required to have GeoTIFF keys.

Requirement 5

/req/req-class-geotiff-keys/georeference

A

In a COG file, the IFD Subfiles of full resolution (a.k.a IFDs whose bit 0 of the value of the NewSubfileType tag is not set, or NewSubfileType absent) SHALL contain georeference data using ModelTiepointTag, ModelPixelScaleTag and GeoKeyDirectoryTag tags.

All linked reduced-resolution subfiles (a.k.a IFDs whose bit 0 of the value of the NewSubfileType tag is set) that are linked to a full resolution IFD (i.e. an IFD whose bit 0 of the value of the NewSubfileType tag is not set, or NewSubfileType absent) share the set of georeference keys from the full resolution IFD. In practice this means that they have a common CRS and extent information, and differ only by their resolution. This means that there is the assumption that all related subfiles share the same point of origin for the top left corner or the image.

Requirement 6

/req/req-class-geotiff-keys/point-of-origin

A

In a COG file all reduced-resolution subfiles SHALL not contain georeference data and use the one in the corresponding full resolution subfile. As a consequence, COG readers SHALL consider that all reduced-resolution subfiles share the same point of origin for the top left corner of the image as the full resolution subfile

The pixel size in the first dimension of a reduced-resolution subfile can be calculated by multiplying the full-resolution subfile pixel size by the ImageWidth ratio between the full-resolution and the reduced-resolution. The pixel size in the second dimension of a reduced-resolution subfile can be calculated by multiplying the full-resolution subfile pixel size by the ImageHeight ratio between the full-resolution and the reduced-resolution.

For the IFD reduced-resolution subfiles linked to IFD0, IFDn_PixelScaleX and IFDn_PixelScaleY can be calculated like this:

IFDn_PixelScaleX=IFD0_PixelScaleX*IFD0_ImageWidth/IFDn_ImageWidth
IFDn_PixelScaleY=IFD0_PixelScaleY*IFD0_ImageHeight/IFDn_ImageHeight

For a georeferenced file with a projected CRS that is fully defined in the EPSG database there is no need to define the base Geographic CRS, geodetic datum, etc. in the TIFF file. In these cases, the following keys in the IFD0 are sufficient;

ImageWidth = 15829
ImageHeight = 6520
ModelTiepointTag = (0 0 0 187334 3255440 0)
ModelPixelScaleTag = (30 30 0)
GeoKeyDirectoryTag:
-    GTModelTypeGeoKey = 1 (ModelTypeProjected 2D)
-    GTRasterTypeGeoKey = 1 (RasterPixelIsArea)
-    ProjectedCRSGeoKey = 32628 (Projected 2D CRS WGS 84 / UTM zone 28N)

This example corresponds to imagery over the Canary Islands with a resolution of 30 meters per pixel. There is a grid intersection line in the image at pixel location (0, 0)

The 2 first numbers in ModelTiepointTag correspond to the projected coordinate reference system easting/northing of (X:187334, Y:3255440) (the numbers 4th and 5th in ModelTiepointTag) in the EPSG:32628 (WGS 84 / UTM zone 28N)

The georeference of the reduced-resolution subfiles (a.k.a IFDs whose bit 0 of the value of the NewSubfileType tag is set) that are linked to this IFD0 are supposed to be the same except ModelPixelScaleTag represents meters per pixel (pixel size). In this example, IFD0 has ImageWidth=20111 and ImageHeigth=16882 while IFD1 has ImageWidth=10056 and ImageHeigth=8441, so IFD1_PixelScaleX and IFD1_PixelScaleY can be calculated as: 30*20111/10056=59.997 and 30*16882/8441=60.

As we can see in the example, tiles can easily result in non-square-pixels; a situation that should be handled by clients combining the data with other imagery that have square pixels.

8. HTTP range support requirements

HTTP Version 1.1 introduced a range header in the GET requests that supports requesting only a fragment of a resource. If the server advertises "Accept-Ranges: bytes" in its response headers of a GET request, the server is telling the client that bytes of data can be requested in parts, in separated requests. The client can request just the bytes that it needs from the server at any time. In a web environment, this is very useful for serving files such as video. By using range requests, clients do not need to download the entire file to begin playing it. Herein this use case, this is useful to get only the tiles needed at a particular time. This is done by getting the headers and IFDs of this TIFF file first and using this information to determine the conversion between tile indices to byte ranges. A client trying to show a COG file on the screen can request the resolutions needed and only the tiles needed to cover the screen. Once the user moves or pans, other GET range requests will get the new needed resolutions and tiles.

8.1. Requirement Class HTTP range

Requirements Class

http://www.opengis.net/spec/COG/1.0/req/req-class-http-range

Target type

Web server

Dependency

https://datatracker.ietf.org/doc/html/rfc7233

Dependency

http://www.opengis.net/spec/GeoTIFF/1.1/req/Core

Dependency

https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf

Dependency

bigtiff.org

8.1.1. Requirement range

Requirement 7

/req/req-class-http-range/range

A

A HTTP or HTTPS server serving COG files SHALL support HTTP range

B

A HTTP or HTTPS server serving COG files shall use byte ranges.

The use of range in web browsers using HTTPS is restricted by the Cross-Origin Resource Sharing (CORS) rules (read ore about this here: https://support.streamroot.io/hc/en-us/articles/115003168773-Range-request-basics). If the client and the server are in different domains (e.g. by using a generic COG enabled web map client requesting external COG files) servers have to explicitly declare that they allow the "range" header from a client that is not in the same domain. Since this is a very common use case in geospatial data sharing the decision was to make this a requirement.

Requirement 8

/req/req-class-http-range/https-headers

A

A HTTPS server serving COG files shall advertise that it allows access control for ranges by adding this line in the headers Access-Control-Allow-Headers: range

Note
 Support for range in HTTPS is necessary but not sufficient. A server that wants to authorize a client application from another domain (under the CORS rules) should also use the Access-Control-Allow-Origin: header to indicate what domains are authorized to read the COG file (or use * to indicate that all domains are authorized). Services that wants to comply about the geospatial data sharing principles should be willing to allow other clients reading the data even if they are in other domains. However, this is a voluntary decision of the server implementers.

9. Media Types for any data encoding(s)

A GeoTIFF file is a TIFF file. It is common to use the tiff MIME type, image/tiff according to [RFC3302] (see https://www.iana.org/assignments/media-types/image/tiff). The registration of the MIME type also allows for a application with no format restriction for default value.

Recommendation 4

/rec/rec-media-type/media-type

A

When required, a COG file should use the MIME type image/tiff with the application parameter value cloud-optimized-geotiff, therefore as follows:

image/tiff; application=cloud-optimized-geotiff

Annex A: Conformance Class Abstract Test Suite (Normative)

A implementation of this standard must satisfy the following system characteristics to be conformant with this specification.

A.1. Conformance Class GeoTIFF Tiles

Conformance Class

http://www.opengis.net/spec/COG/1.0/conf/geotiff-format

Target type

TIFF Encoder

Requirements class

GeoTIFF Tiles

A.1.1. Basic format

Abstract Test 1

/conf/geotiff-format/use-geotiff

Test Purpose

Validate that a COG file bigger than 4 GByte follows the BigTIFF standard

Requirement

[req_geotiff-format-use-geotiff]

Test method

Validate the requirements of the BiGTIFF

Test passes if a COG file bigger than 4 GByte follows the BigTIFF standard

A.1.2. Tiles

Abstract Test 2

/conf/geotiff-format/tiling

Test Purpose

Validate that all Image File Directories (IFD) in a COG file are organized into tiles

Requirement

[req_geotiff-format-tiling]

Test method

Validate the requirements of tiled IFDs

Test passes if all Image File Directories (IFD) in a COG file are organized into tiles

A.2. Conformance Class GeoTIFF Overviews

Conformance Class

http://www.opengis.net/spec/COG/1.0/conf/geotiff-overviews

Target type

TIFF Encoder

Requirements class

GeoTIFF Overviews

A.2.1. Overviews

Abstract Test 3

/conf/geotiff-overviews/overviews

Test Purpose

Validate that a COG file contains the full resolution image as well as the reduced resolution images

Requirement

[req_geotiff-overviews-overviews]

Test method

Validate the requirements of overviews

Test passes if at least one IFD whose bit 0 of the value of the NewSubfileType tag is not set, or NewSubfileType absent (full-resolution image data) is present in the COG file and an the IFD with SubfileType 1 has an offset to an IFD with a NewSubfileType tag whose bit 0 is set (reduced-resolution image data), or 0 if there is no reduced-resolution image and all the IFD with a NewSubfileType tag whose bit 0 is set have an Image Width an Image Height inferior than the previous IFD.

A.3. Conformance Class GeoTIFF Keys

Conformance Class

http://www.opengis.net/spec/COG/1.0/conf/geotiff-keys

Target type

GeoTIFF Encoder

Requirements class

GeoTIFF Keys

A.3.1. GeoTIFF

Abstract Test 4

/conf/geotiff-format/basic-metadata-format

Test Purpose

Validate that a COG file includes and encodes geospatial metadata following the GeoTIFF standard

Requirement

[req_geotiff-format-basic-metadata-format]

Test method

Validate the requirements of GeoTIFF metadata

Test passes if geospatial metadata following the GeoTIFF standard is found on the COG file

A.3.2. Georeference Keys

Abstract Test 5

/conf/geotiff-keys/georeference

Test Purpose

Validate that a COG file contains georeference data using ModelTiepointTag, ModelPixelScaleTag and GeoKeyDirectoryTag tags in the IFD Subfiles of full resolution

Requirement

[req_geotiff-keys-georeference]

Test method

Validate the requirements of georeference

Test passes if georeference data using ModelTiepointTag, ModelPixelScaleTag and GeoKeyDirectoryTag tags is found in the IFD Subfiles of full resolution of the COG file (a.k.a IFDs whose bit 0 of the value of the NewSubfileType tag is not set, or NewSubfileType absent)

Abstract Test 6

/conf/geotiff-keys/point-of-origin

Test Purpose

Validate that all reduced-resolution subfiles do not contain georeference data.

Requirement

[req_geotiff-keys-point-of-origin]

Test method

Validate the requirements of no metadata in subfiles

Test passes if all reduced-resolution subfiles do not contain georeference data in the COG file

A.4. Conformance Class HTTP range

Conformance Class

http://www.opengis.net/spec/COG/1.0/conf/http-range

Target type

Web server

Requirements class

HTTP range

A.4.1. Range

Abstract Test 7

/conf/http-range/use-range

Test Purpose

Validate that a server supports HTTP range

Requirement

[req_http-range-use-range]

Test method

Validate the requirements of the HTTP range

Test passes if an HTTP or HTTPS server supports HTTP range and uses byte ranges.

Abstract Test 8

/conf/http-range/https-headers

Test Purpose

Validate that the header Access-Control-Allow-Headers: range is provided

Requirement

[req_http-range-https-headers]

Test method

Validate the requirements of HTTPS allow headers

Test passes if an HTTPS server advertises that allows access control for ranges by adding this line in the headers Access-Control-Allow-Headers: range

Annex B: Revision History

Date Release Editor Primary clauses modified Description

2021-10-26

0.1

Joan Masó

all

initial version from parts of OGC 21-025

2022-06-01

0.2

Joan Masó

all

First complete version including ATS

Annex C: Bibliography

[1] Cloud Optimized GeoTIFF. An imagery format for cloud-native geospatial processing. In Internet: https://www.cogeo.org/

[2] GDAL COG - Cloud Optimized GeoTIFF generator. In Internet: https://gdal.org/drivers/raster/cog.html

[3] Maso J. OGC Testbed-17: Cloud Optimized GeoTIFF specification Engineering Report. OGC 21-025 (2022)