From 16e62b13c79ec9a0c84579e0dad54db191ca3bc3 Mon Sep 17 00:00:00 2001 From: Alex Mandel Date: Fri, 15 Sep 2023 14:01:12 -0700 Subject: [PATCH 1/8] fix: Markdown link syntax --- cloud-optimized-geotiffs/intro.ipynb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cloud-optimized-geotiffs/intro.ipynb b/cloud-optimized-geotiffs/intro.ipynb index e31774a..c2c99d5 100644 --- a/cloud-optimized-geotiffs/intro.ipynb +++ b/cloud-optimized-geotiffs/intro.ipynb @@ -11,7 +11,7 @@ "\n", "Cloud-Optimized GeoTIFF (the COG) is a variant of the TIFF image format that specifies a particular layout of internal data in the GeoTIFF specification to allow for optimized (subsetted or aggregated) access over a network for display or data reading. The key components are overviews, and internal tiling.\n", "\n", - "For more details see https://www.cogeo.org/\n", + "For more details see [https://www.cogeo.org/](https://www.cogeo.org/)\n", "\n", "\"COG\n", "\n", From 0d9a4a0aa97c706760cc7463318d71a9075e19d5 Mon Sep 17 00:00:00 2001 From: Alex Mandel Date: Fri, 15 Sep 2023 15:13:36 -0700 Subject: [PATCH 2/8] feat: updated to COG pages Some links, added text, minor reorg --- cloud-optimized-geotiffs/cogs-examples.ipynb | 52 +++++++++++++------- cloud-optimized-geotiffs/intro.ipynb | 25 ++++++---- 2 files changed, 49 insertions(+), 28 deletions(-) diff --git a/cloud-optimized-geotiffs/cogs-examples.ipynb b/cloud-optimized-geotiffs/cogs-examples.ipynb index 2ecc6b6..8cd8757 100644 --- a/cloud-optimized-geotiffs/cogs-examples.ipynb +++ b/cloud-optimized-geotiffs/cogs-examples.ipynb @@ -173,6 +173,14 @@ "veg_gtiff_filename = f\"{test_data_dir}/{veg_files[0]}\"" ] }, + { + "cell_type": "markdown", + "id": "13da6953", + "metadata": {}, + "source": [ + "> To learn more about the example data see the [Vegetation Continuous Fields (VCF) information page](https://lpdaac.usgs.gov/products/vcf5kyrv001/)." + ] + }, { "cell_type": "markdown", "id": "451dbe01", @@ -297,17 +305,13 @@ "id": "ff2cc531", "metadata": {}, "source": [ - "## Dimensions\n", - "\n", - "This attribute is also sometimes called **chunks** or **internal tiles**.\n", + "## Data Structure\n", "\n", - "Dimensions are the number of bands, rows and columns stored in a GeoTIFF. There is a tradeoff between storing lots of data in one GeoTIFF and storing less data in many GeoTIFFs. The larger a single file, the larger the GeoTIFF header and the multiple requests may be required just to read the spatial index before data retrieval. The opposite problem occurs if you make too many small files, then it takes many reads to retrieve data, and when rendering a combined visualization can greatly impact load time.\n", + "**Dimensions**\n", + "Dimensions are the number of bands, rows and columns stored in a GeoTIFF. [More Info](intro.ipynb#dimensions)\n", "\n", - "If you plan to pan and zoom a large amount of data through a tiling service in a web browser, there is a tradeoff between 1 large file, or many smaller files. The current recommendation is to meet somewhere in the middle, a moderate amount of medium files.\n", - "\n", - "### Internal Blocks\n", - "\n", - "Internal blocks are required if the dimensions of data are over 512x512. However you can control the size of the internal blocks. 256x256 or 512x512 are recommended. When displaying data at full resolution, or doing partial reading of data this size will impact the number of reads required. A size of 256 will take less time to read, and read less data outside the desired bounding box, however for reading large parts of a file, it may take more total read requests. Some clients will aggregate neighboring block reads to reduce the total number of requests. \n", + "**Internal Blocks** (aka chunks or internal tiles)\n", + "Internal blocks are required if the dimensions of data are over 512x512. [More Info](intro.ipynb#internal-blocks)\n", "\n", "Let's check out the dimensions and blocks of our GeoTIFF and Cloud-Optimized GeoTIFF." ] @@ -423,15 +427,15 @@ "## Overviews\n", "\n", "Overviews are downsampled (aggregated) data intended for visualization.\n", - "The best resampling algorithm depends on the range, type, and distribution of the data.\n", "\n", - "The smallest size overview should match the tiling components’ fetch size, typically 256x256. Due to aspect ratio variation just aim to have at least one dimension at or slightly less than 256. The COG driver in GDAL, or rio cogeo tools should do this.\n", + "The smallest size overview should match the tiling components’ fetch size, typically 256x256. Due to aspect ratio variation just aim to have at least one dimension at or slightly less than 256. \n", + "> The COG driver in GDAL, or rio cogeo tools should do this.\n", "\n", - "There are many resampling algorithms for generating overviews. When creating overviews several options should be compared before deciding which resampling method to apply.\n", + "There are many resampling algorithms for generating overviews. The best resampling algorithm depends on the range, type, and distribution of the data. When creating overviews several options should be compared before deciding which resampling method to apply. \n", "\n", "GDAL >= 3.2 allows for the overview resampling method to be set directly.\n", "\n", - "TODO: need to add hints on how to check which resampling method to use for overviews. Possibly provide code for comparing." + "" ] }, { @@ -736,13 +740,18 @@ "source": [ "# Data Type\n", "\n", - "The smallest possible data type, that still represents the data appropriately, should be used. It is not generally recommended to shift data from float to integer by multiplying, a space saving technique, as end users then need to undo this step to use the data. Data compression is preferred, see also Compression.\n", + "**Recommendation** The smallest possible data type, that still represents the data appropriately, should be used. It is not generally recommended to shift data from float to integer by multiplying, a space saving technique, as end users then need to undo this step to use the data. Data compression is preferred, see also [Compression](#compression).\n", + "\n", + "GeoTIFF format supports many data types. The key is that all bands must be of the same data type. Unlike some other formats you can not mix and match integers (whole numbers) and floats (decimal numbers) in the same file. If you have this use case consider splitting files by data type and using a catalog like STAC to keep track of them, or look at other formats like [Zarr](../zarr/intro.qmd).\n", "\n", "Scenario: If the COG is intended only for visualization, conversion to 3 band byte will improve performance. \n", "\n", + "> GDAL supported Data Types [list](https://gdal.org/drivers/raster/gtiff.html#gtiff-geotiff-file-format)\n", + "\n", + "\n", "# Compression (aka File Size)\n", "\n", - "The biggest benefit to compression is on the storage side. It’s always recommended to use a lossless compression method. Deflate or LZW are the most recommended compression algorithms, there are some choices that depend on the data type and distribution, and if the goal is maximum compression or not. Maximum compression does result in some performance loss." + "The biggest benefit to compression is on the storage side. It’s always recommended to use a lossless compression method. **Deflate** or **LZW** are the most recommended compression algorithms, there are some choices that depend on the data type and distribution, and if the goal is maximum compression or not. Maximum compression does result in some performance loss." ] }, { @@ -755,7 +764,7 @@ "\n", "# Projection\n", "\n", - "Read performance can be greatly impacted by the choice of projection and the particular applications used for dynamic tile serving. Using a known CRS defined in the PROJ database (typically EPSG code) is preferred over custom projections. Load times can be 5-20 times greater when using a custom projection. Whenever applying projections make sure to use WKT2 representation. If using a database of known projections this should be fine, there are known issues around manually setting proj-strings.\n" + "Read performance can be greatly impacted by the choice of projection and the particular applications used for dynamic tile serving. Using a known CRS defined in the PROJ database (typically EPSG code) is preferred over custom projections. Load times can be 5-20 times greater when using a custom projection. Whenever applying projections make sure to use WKT2 representation. If using a database of known projections, i.e. EPSG codes, this should be fine, there are known issues around manually setting proj-strings.\n" ] }, { @@ -768,7 +777,7 @@ "* The optimum size of data at which splitting across files improves performance as a multi-file dataset instead of a single file.\n", "* When to recommend particular internal tile sizes\n", "* Compression impacts on http transfer rates.\n", - "* Support for COG creation in other common scientific platforms (e.g. R)\n" + "* Support for COG creation in all common Geospatial tools varies.\n" ] }, { @@ -785,7 +794,7 @@ ], "metadata": { "kernelspec": { - "display_name": "Python 3 (ipykernel)", + "display_name": "Python 3.10.12 64-bit", "language": "python", "name": "python3" }, @@ -799,7 +808,12 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.11.4" + "version": "3.10.12" + }, + "vscode": { + "interpreter": { + "hash": "31f2aee4e71d21fbe5cf8b01ff0e069b9275f58929596ceb00d14d90e3e16cd6" + } } }, "nbformat": 4, diff --git a/cloud-optimized-geotiffs/intro.ipynb b/cloud-optimized-geotiffs/intro.ipynb index c2c99d5..a35c924 100644 --- a/cloud-optimized-geotiffs/intro.ipynb +++ b/cloud-optimized-geotiffs/intro.ipynb @@ -9,7 +9,7 @@ "\n", "## What is a Cloud-Optimized GeoTIFF?\n", "\n", - "Cloud-Optimized GeoTIFF (the COG) is a variant of the TIFF image format that specifies a particular layout of internal data in the GeoTIFF specification to allow for optimized (subsetted or aggregated) access over a network for display or data reading. The key components are overviews, and internal tiling.\n", + "Cloud-Optimized GeoTIFF (the COG), a raster format, is a variant of the TIFF image format that specifies a particular layout of internal data in the GeoTIFF specification to allow for optimized (subsetted or aggregated) access over a network for display or data reading. The key components are overviews, and internal tiling.\n", "\n", "For more details see [https://www.cogeo.org/](https://www.cogeo.org/)\n", "\n", @@ -17,14 +17,14 @@ "\n", "### Dimensions\n", "\n", - "This attribute is also sometimes called **chunks** or **internal tiles**.\n", - "\n", "Dimensions are the number of bands, rows and columns stored in a GeoTIFF. There is a tradeoff between storing lots of data in one GeoTIFF and storing less data in many GeoTIFFs. The larger a single file, the larger the GeoTIFF header and the multiple requests may be required just to read the spatial index before data retrieval. The opposite problem occurs if you make too many small files, then it takes many reads to retrieve data, and when rendering a combined visualization can greatly impact load time.\n", "\n", "If you plan to pan and zoom a large amount of data through a tiling service in a web browser, there is a tradeoff between 1 large file, or many smaller files. The current recommendation is to meet somewhere in the middle, a moderate amount of medium files.\n", "\n", "### Internal Blocks\n", "\n", + "> This attribute is also sometimes called **chunks** or **internal tiles**.\n", + "\n", "Internal blocks are required if the dimensions of data are over 512x512. However you can control the size of the internal blocks. 256x256 or 512x512 are recommended. When displaying data at full resolution, or doing partial reading of data this size will impact the number of reads required. A size of 256 will take less time to read, and read less data outside the desired bounding box, however for reading large parts of a file, it may take more total read requests. Some clients will aggregate neighboring block reads to reduce the total number of requests.\n", "\n", "### Overviews\n", @@ -34,7 +34,7 @@ "\n", "The smallest size overview should match the tiling components’ fetch size, typically 256x256. Due to aspect ratio variation just aim to have at least one dimension at or slightly less than 256. The COG driver in GDAL, or rio cogeo tools should do this.\n", "\n", - "There are many resampling algorithms for generating overviews. When creating overviews several options should be compared before deciding which resampling method to apply." + "There are many [resampling algorithms](https://gdal.org/programs/gdal_translate.html#cmdoption-gdal_translate-r) for generating overviews. When creating overviews several options should be compared before deciding which resampling method to apply." ] }, { @@ -60,18 +60,20 @@ "* [Development Seed Blog: Do you really want people using your data?](https://medium.com/@_VincentS_/do-you-really-want-people-using-your-data-ec94cd94dc3f)\n", "\n", "## How to visualize COGs\n", + "\n", "\n", - "* GDAL vis* drivers (vsicurl, vsis3, vsiaz,)\n", "* Titiler https://github.com/developmentseed/titiler\n", - "* Rio-viz https://github.com/developmentseed/rio-viz" + "* Rio-viz https://github.com/developmentseed/rio-viz\n", + "* GDAL vis* drivers (vsicurl, vsis3, vsiaz,) \n", + "* Open in your favorite Desktop GIS or Remote Sensing Application" ] } ], "metadata": { "kernelspec": { - "display_name": "Python [conda env:geospatial]", + "display_name": "Python 3.10.12 64-bit", "language": "python", - "name": "conda-env-geospatial-py" + "name": "python3" }, "language_info": { "codemirror_mode": { @@ -83,7 +85,12 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.10.6" + "version": "3.10.12" + }, + "vscode": { + "interpreter": { + "hash": "31f2aee4e71d21fbe5cf8b01ff0e069b9275f58929596ceb00d14d90e3e16cd6" + } } }, "nbformat": 4, From 0be7067f2d5c8673d95a6c24da61516cc8bef976 Mon Sep 17 00:00:00 2001 From: Alex Mandel Date: Fri, 15 Sep 2023 16:57:51 -0700 Subject: [PATCH 3/8] fix: split GeoTiff details to new page --- cloud-optimized-geotiffs/cogs-details.ipynb | 98 ++++++++++++++++++++ cloud-optimized-geotiffs/cogs-examples.ipynb | 58 ------------ 2 files changed, 98 insertions(+), 58 deletions(-) create mode 100644 cloud-optimized-geotiffs/cogs-details.ipynb diff --git a/cloud-optimized-geotiffs/cogs-details.ipynb b/cloud-optimized-geotiffs/cogs-details.ipynb new file mode 100644 index 0000000..b2487ac --- /dev/null +++ b/cloud-optimized-geotiffs/cogs-details.ipynb @@ -0,0 +1,98 @@ +{ + "cells": [ + { + "cell_type": "markdown", + "id": "e84fbc0b", + "metadata": {}, + "source": [ + "# COG Format Details\n", + "\n", + "In the [COG Intro](intro.ipynb) you can see what makes a COG different from non-optimized GeoTIFFs. The rest of this page details additional GeoTIFF information that can be relevant to making your files as useful as possible but not a COG requirement." + ] + }, + { + "cell_type": "markdown", + "id": "0d780549-1ffb-45cd-a7ac-969072d46137", + "metadata": {}, + "source": [ + "# Data Type\n", + "\n", + "**Recommendation** The smallest possible data type, that still represents the data appropriately, should be used. It is not generally recommended to shift data from float to integer by multiplying, a space saving technique, as end users then need to undo this step to use the data. Data compression is preferred, see also [Compression](#compression).\n", + "\n", + "GeoTIFF format supports many data types. The key is that all bands must be of the same data type. Unlike some other formats you can not mix and match integers (whole numbers) and floats (decimal numbers) in the same file. If you have this use case consider splitting files by data type and using a catalog like STAC to keep track of them, or look at other formats like [Zarr](../zarr/intro.qmd).\n", + "\n", + "Scenario: If the COG is intended only for visualization, conversion to 3 band byte will improve performance. \n", + "\n", + "> GDAL supported Data Types [list](https://gdal.org/drivers/raster/gtiff.html#gtiff-geotiff-file-format)\n", + "\n", + "\n", + "# Compression (aka File Size)\n", + "\n", + "The biggest benefit to compression is on the storage side. It’s always recommended to use a lossless compression method. **Deflate** or **LZW** are the most recommended compression algorithms, there are some choices that depend on the data type and distribution, and if the goal is maximum compression or not. Maximum compression does result in some performance loss." + ] + }, + { + "cell_type": "markdown", + "id": "9fbe71f0-20b9-4a1b-8e7f-de52a90cc7c6", + "metadata": {}, + "source": [ + "# No Data\n", + "Setting a no data value makes it clear to users and visualization tools what pixels are not actually data. For visualization this allows these pixels to be easily hidden (transparent). Historically many values have been used, 0, -9999, etc… The key is to make sure the GDAL flag for no data is set. It is also suggested that the smallest negative value be used instead of a random value. For byte and unsigned integers/floats this will be 0, if 0 has meaning in your data use a different value (like the max possible value). Having the right nodata flag set is important for overview generation.\n", + "\n", + "# Projection\n", + "\n", + "Read performance can be greatly impacted by the choice of projection and the particular applications used for dynamic tile serving. Using a known CRS defined in the PROJ database (typically EPSG code) is preferred over custom projections. Load times can be 5-20 times greater when using a custom projection. Whenever applying projections make sure to use WKT2 representation. If using a database of known projections, i.e. EPSG codes, this should be fine, there are known issues around manually setting proj-strings.\n" + ] + }, + { + "cell_type": "markdown", + "id": "1e9d49cc-7e1a-4e7b-94a3-539b8e51f0c7", + "metadata": {}, + "source": [ + "## What we don’t know (areas of research)\n", + "\n", + "* The optimum size of data at which splitting across files improves performance as a multi-file dataset instead of a single file.\n", + "* When to recommend particular internal tile sizes\n", + "* Compression impacts on http transfer rates.\n", + "* Support for COG creation in all common Geospatial tools varies.\n" + ] + }, + { + "cell_type": "markdown", + "id": "d193ab02-bb69-455e-9b72-5b89728f086e", + "metadata": {}, + "source": [ + "## Additional Resources\n", + "\n", + "* [An Introduction to Cloud Optimized GeoTIFFS (COGs) Part 1: Overview](https://developers.planet.com/docs/planetschool/an-introduction-to-cloud-optimized-geotiffs-cogs-part-1-overview/)\n", + "* [Do you really want people using your data?](https://medium.com/@_VincentS_/do-you-really-want-people-using-your-data-ec94cd94dc3f)" + ] + } + ], + "metadata": { + "kernelspec": { + "display_name": "Python 3.10.12 64-bit", + "language": "python", + "name": "python3" + }, + "language_info": { + "codemirror_mode": { + "name": "ipython", + "version": 3 + }, + "file_extension": ".py", + "mimetype": "text/x-python", + "name": "python", + "nbconvert_exporter": "python", + "pygments_lexer": "ipython3", + "version": "3.10.12" + }, + "vscode": { + "interpreter": { + "hash": "31f2aee4e71d21fbe5cf8b01ff0e069b9275f58929596ceb00d14d90e3e16cd6" + } + } + }, + "nbformat": 4, + "nbformat_minor": 5 +} diff --git a/cloud-optimized-geotiffs/cogs-examples.ipynb b/cloud-optimized-geotiffs/cogs-examples.ipynb index 8cd8757..3f71a91 100644 --- a/cloud-optimized-geotiffs/cogs-examples.ipynb +++ b/cloud-optimized-geotiffs/cogs-examples.ipynb @@ -732,64 +732,6 @@ "source": [ "show_overviews(tmp_cog)" ] - }, - { - "cell_type": "markdown", - "id": "0d780549-1ffb-45cd-a7ac-969072d46137", - "metadata": {}, - "source": [ - "# Data Type\n", - "\n", - "**Recommendation** The smallest possible data type, that still represents the data appropriately, should be used. It is not generally recommended to shift data from float to integer by multiplying, a space saving technique, as end users then need to undo this step to use the data. Data compression is preferred, see also [Compression](#compression).\n", - "\n", - "GeoTIFF format supports many data types. The key is that all bands must be of the same data type. Unlike some other formats you can not mix and match integers (whole numbers) and floats (decimal numbers) in the same file. If you have this use case consider splitting files by data type and using a catalog like STAC to keep track of them, or look at other formats like [Zarr](../zarr/intro.qmd).\n", - "\n", - "Scenario: If the COG is intended only for visualization, conversion to 3 band byte will improve performance. \n", - "\n", - "> GDAL supported Data Types [list](https://gdal.org/drivers/raster/gtiff.html#gtiff-geotiff-file-format)\n", - "\n", - "\n", - "# Compression (aka File Size)\n", - "\n", - "The biggest benefit to compression is on the storage side. It’s always recommended to use a lossless compression method. **Deflate** or **LZW** are the most recommended compression algorithms, there are some choices that depend on the data type and distribution, and if the goal is maximum compression or not. Maximum compression does result in some performance loss." - ] - }, - { - "cell_type": "markdown", - "id": "9fbe71f0-20b9-4a1b-8e7f-de52a90cc7c6", - "metadata": {}, - "source": [ - "# No Data\n", - "Setting a no data value makes it clear to users and visualization tools what pixels are not actually data. For visualization this allows these pixels to be easily hidden (transparent). Historically many values have been used, 0, -9999, etc… The key is to make sure the GDAL flag for no data is set. It is also suggested that the smallest negative value be used instead of a random value. For byte and unsigned integers/floats this will be 0, if 0 has meaning in your data use a different value (like the max possible value). Having the right nodata flag set is important for overview generation.\n", - "\n", - "# Projection\n", - "\n", - "Read performance can be greatly impacted by the choice of projection and the particular applications used for dynamic tile serving. Using a known CRS defined in the PROJ database (typically EPSG code) is preferred over custom projections. Load times can be 5-20 times greater when using a custom projection. Whenever applying projections make sure to use WKT2 representation. If using a database of known projections, i.e. EPSG codes, this should be fine, there are known issues around manually setting proj-strings.\n" - ] - }, - { - "cell_type": "markdown", - "id": "1e9d49cc-7e1a-4e7b-94a3-539b8e51f0c7", - "metadata": {}, - "source": [ - "## What we don’t know (areas of research)\n", - "\n", - "* The optimum size of data at which splitting across files improves performance as a multi-file dataset instead of a single file.\n", - "* When to recommend particular internal tile sizes\n", - "* Compression impacts on http transfer rates.\n", - "* Support for COG creation in all common Geospatial tools varies.\n" - ] - }, - { - "cell_type": "markdown", - "id": "d193ab02-bb69-455e-9b72-5b89728f086e", - "metadata": {}, - "source": [ - "## Additional Resources\n", - "\n", - "* [An Introduction to Cloud Optimized GeoTIFFS (COGs) Part 1: Overview](https://developers.planet.com/docs/planetschool/an-introduction-to-cloud-optimized-geotiffs-cogs-part-1-overview/)\n", - "* [Do you really want people using your data?](https://medium.com/@_VincentS_/do-you-really-want-people-using-your-data-ec94cd94dc3f)" - ] } ], "metadata": { From 2925d49e8a1d9cbf044fb3ffff872a2450eab6c8 Mon Sep 17 00:00:00 2001 From: Alex Mandel Date: Mon, 18 Sep 2023 09:17:34 -0700 Subject: [PATCH 4/8] fix: Preview builds on _site #58 --- .github/workflows/preview.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/preview.yml b/.github/workflows/preview.yml index 0181d34..6796c1c 100644 --- a/.github/workflows/preview.yml +++ b/.github/workflows/preview.yml @@ -24,4 +24,4 @@ jobs: - name: Deploy preview uses: rossjrw/pr-preview-action@v1 with: - source-dir: docs + source-dir: _site From c2a6c759bcfcd2fd51585dc3667bcf9bdbcf17db Mon Sep 17 00:00:00 2001 From: Alex Mandel Date: Mon, 18 Sep 2023 09:49:47 -0700 Subject: [PATCH 5/8] fix: reapply edits to new qmd file --- cloud-optimized-geotiffs/intro.qmd | 28 +++++----------------------- 1 file changed, 5 insertions(+), 23 deletions(-) diff --git a/cloud-optimized-geotiffs/intro.qmd b/cloud-optimized-geotiffs/intro.qmd index 4cf9484..82c3f36 100644 --- a/cloud-optimized-geotiffs/intro.qmd +++ b/cloud-optimized-geotiffs/intro.qmd @@ -2,22 +2,22 @@ ## What is a Cloud-Optimized GeoTIFF? -Cloud-Optimized GeoTIFF (the COG) is a variant of the TIFF image format that specifies a particular layout of internal data in the GeoTIFF specification to allow for optimized (subsetted or aggregated) access over a network for display or data reading. The key components are overviews, and internal tiling. +Cloud-Optimized GeoTIFF (the COG), a raster format, is a variant of the TIFF image format that specifies a particular layout of internal data in the GeoTIFF specification to allow for optimized (subsetted or aggregated) access over a network for display or data reading. The key components are overviews, and internal tiling. -For more details see https://www.cogeo.org/ +For more details see [https://www.cogeo.org/](https://www.cogeo.org/) COG Diagram ### Dimensions -This attribute is also sometimes called **chunks** or **internal tiles**. - Dimensions are the number of bands, rows and columns stored in a GeoTIFF. There is a tradeoff between storing lots of data in one GeoTIFF and storing less data in many GeoTIFFs. The larger a single file, the larger the GeoTIFF header and the multiple requests may be required just to read the spatial index before data retrieval. The opposite problem occurs if you make too many small files, then it takes many reads to retrieve data, and when rendering a combined visualization can greatly impact load time. If you plan to pan and zoom a large amount of data through a tiling service in a web browser, there is a tradeoff between 1 large file, or many smaller files. The current recommendation is to meet somewhere in the middle, a moderate amount of medium files. ### Internal Blocks +> This attribute is also sometimes called **chunks** or **internal tiles**. + Internal blocks are required if the dimensions of data are over 512x512. However you can control the size of the internal blocks. 256x256 or 512x512 are recommended. When displaying data at full resolution, or doing partial reading of data this size will impact the number of reads required. A size of 256 will take less time to read, and read less data outside the desired bounding box, however for reading large parts of a file, it may take more total read requests. Some clients will aggregate neighboring block reads to reduce the total number of requests. ### Overviews @@ -27,22 +27,4 @@ The best resampling algorithm depends on the range, type, and distribution of th The smallest size overview should match the tiling components’ fetch size, typically 256x256. Due to aspect ratio variation just aim to have at least one dimension at or slightly less than 256. The COG driver in GDAL, or rio cogeo tools should do this. -There are many resampling algorithms for generating overviews. When creating overviews several options should be compared before deciding which resampling method to apply. - -## How to create and validate COGs - -1. [Rio-cogeo: GitHub - cogeotiff/rio-cogeo: Cloud Optimized GeoTIFF creation and validation plugin for rasterio](https://github.com/cogeotiff/rio-cogeo) -2. [Gdal: COG – Cloud Optimized GeoTIFF generator — GDAL documentation](https://gdal.org/drivers/raster/cog.html) - - -## Additional Resources - -* [Planet Blog: An Introduction to Cloud Optimized GeoTIFFS (COGs) Part 1: Overview](https://developers.planet.com/docs/planetschool/an-introduction-to-cloud-optimized-geotiffs-cogs-part-1-overview/) -* [COG Talk — Part 1: What’s new?](https://medium.com/devseed/cog-talk-part-1-whats-new-941facbcd3d1) -* [Development Seed Blog: Do you really want people using your data?](https://medium.com/@_VincentS_/do-you-really-want-people-using-your-data-ec94cd94dc3f) - -## How to visualize COGs - -* GDAL vis* drivers (vsicurl, vsis3, vsiaz,) -* Titiler https://github.com/developmentseed/titiler -* Rio-viz https://github.com/developmentseed/rio-viz +There are many [resampling algorithms](https://gdal.org/programs/gdal_translate.html#cmdoption-gdal_translate-r) for generating overviews. When creating overviews several options should be compared before deciding which resampling method to apply. \ No newline at end of file From 637ad293232dc1876771d9bc99646e8276ecf9d4 Mon Sep 17 00:00:00 2001 From: Alex Mandel Date: Mon, 18 Sep 2023 10:02:47 -0700 Subject: [PATCH 6/8] fix: move details from ipynb to qmd --- cloud-optimized-geotiffs/cogs-details.ipynb | 98 --------------------- cloud-optimized-geotiffs/cogs-details.qmd | 37 ++++++++ 2 files changed, 37 insertions(+), 98 deletions(-) delete mode 100644 cloud-optimized-geotiffs/cogs-details.ipynb create mode 100644 cloud-optimized-geotiffs/cogs-details.qmd diff --git a/cloud-optimized-geotiffs/cogs-details.ipynb b/cloud-optimized-geotiffs/cogs-details.ipynb deleted file mode 100644 index b2487ac..0000000 --- a/cloud-optimized-geotiffs/cogs-details.ipynb +++ /dev/null @@ -1,98 +0,0 @@ -{ - "cells": [ - { - "cell_type": "markdown", - "id": "e84fbc0b", - "metadata": {}, - "source": [ - "# COG Format Details\n", - "\n", - "In the [COG Intro](intro.ipynb) you can see what makes a COG different from non-optimized GeoTIFFs. The rest of this page details additional GeoTIFF information that can be relevant to making your files as useful as possible but not a COG requirement." - ] - }, - { - "cell_type": "markdown", - "id": "0d780549-1ffb-45cd-a7ac-969072d46137", - "metadata": {}, - "source": [ - "# Data Type\n", - "\n", - "**Recommendation** The smallest possible data type, that still represents the data appropriately, should be used. It is not generally recommended to shift data from float to integer by multiplying, a space saving technique, as end users then need to undo this step to use the data. Data compression is preferred, see also [Compression](#compression).\n", - "\n", - "GeoTIFF format supports many data types. The key is that all bands must be of the same data type. Unlike some other formats you can not mix and match integers (whole numbers) and floats (decimal numbers) in the same file. If you have this use case consider splitting files by data type and using a catalog like STAC to keep track of them, or look at other formats like [Zarr](../zarr/intro.qmd).\n", - "\n", - "Scenario: If the COG is intended only for visualization, conversion to 3 band byte will improve performance. \n", - "\n", - "> GDAL supported Data Types [list](https://gdal.org/drivers/raster/gtiff.html#gtiff-geotiff-file-format)\n", - "\n", - "\n", - "# Compression (aka File Size)\n", - "\n", - "The biggest benefit to compression is on the storage side. It’s always recommended to use a lossless compression method. **Deflate** or **LZW** are the most recommended compression algorithms, there are some choices that depend on the data type and distribution, and if the goal is maximum compression or not. Maximum compression does result in some performance loss." - ] - }, - { - "cell_type": "markdown", - "id": "9fbe71f0-20b9-4a1b-8e7f-de52a90cc7c6", - "metadata": {}, - "source": [ - "# No Data\n", - "Setting a no data value makes it clear to users and visualization tools what pixels are not actually data. For visualization this allows these pixels to be easily hidden (transparent). Historically many values have been used, 0, -9999, etc… The key is to make sure the GDAL flag for no data is set. It is also suggested that the smallest negative value be used instead of a random value. For byte and unsigned integers/floats this will be 0, if 0 has meaning in your data use a different value (like the max possible value). Having the right nodata flag set is important for overview generation.\n", - "\n", - "# Projection\n", - "\n", - "Read performance can be greatly impacted by the choice of projection and the particular applications used for dynamic tile serving. Using a known CRS defined in the PROJ database (typically EPSG code) is preferred over custom projections. Load times can be 5-20 times greater when using a custom projection. Whenever applying projections make sure to use WKT2 representation. If using a database of known projections, i.e. EPSG codes, this should be fine, there are known issues around manually setting proj-strings.\n" - ] - }, - { - "cell_type": "markdown", - "id": "1e9d49cc-7e1a-4e7b-94a3-539b8e51f0c7", - "metadata": {}, - "source": [ - "## What we don’t know (areas of research)\n", - "\n", - "* The optimum size of data at which splitting across files improves performance as a multi-file dataset instead of a single file.\n", - "* When to recommend particular internal tile sizes\n", - "* Compression impacts on http transfer rates.\n", - "* Support for COG creation in all common Geospatial tools varies.\n" - ] - }, - { - "cell_type": "markdown", - "id": "d193ab02-bb69-455e-9b72-5b89728f086e", - "metadata": {}, - "source": [ - "## Additional Resources\n", - "\n", - "* [An Introduction to Cloud Optimized GeoTIFFS (COGs) Part 1: Overview](https://developers.planet.com/docs/planetschool/an-introduction-to-cloud-optimized-geotiffs-cogs-part-1-overview/)\n", - "* [Do you really want people using your data?](https://medium.com/@_VincentS_/do-you-really-want-people-using-your-data-ec94cd94dc3f)" - ] - } - ], - "metadata": { - "kernelspec": { - "display_name": "Python 3.10.12 64-bit", - "language": "python", - "name": "python3" - }, - "language_info": { - "codemirror_mode": { - "name": "ipython", - "version": 3 - }, - "file_extension": ".py", - "mimetype": "text/x-python", - "name": "python", - "nbconvert_exporter": "python", - "pygments_lexer": "ipython3", - "version": "3.10.12" - }, - "vscode": { - "interpreter": { - "hash": "31f2aee4e71d21fbe5cf8b01ff0e069b9275f58929596ceb00d14d90e3e16cd6" - } - } - }, - "nbformat": 4, - "nbformat_minor": 5 -} diff --git a/cloud-optimized-geotiffs/cogs-details.qmd b/cloud-optimized-geotiffs/cogs-details.qmd new file mode 100644 index 0000000..2b73500 --- /dev/null +++ b/cloud-optimized-geotiffs/cogs-details.qmd @@ -0,0 +1,37 @@ +# COG Format Details + +In the [COG Intro](intro.ipynb) you can see what makes a COG different from non-optimized GeoTIFFs. The rest of this page details additional GeoTIFF information that can be relevant to making your files as useful as possible but not a COG requirement. + +## Data Type + +**Recommendation** The smallest possible data type, that still represents the data appropriately, should be used. It is not generally recommended to shift data from float to integer by multiplying, a space saving technique, as end users then need to undo this step to use the data. Data compression is preferred, see also [Compression](#compression). + +GeoTIFF format supports many data types. The key is that all bands must be of the same data type. Unlike some other formats you can not mix and match integers (whole numbers) and floats (decimal numbers) in the same file. If you have this use case consider splitting files by data type and using a catalog like STAC to keep track of them, or look at other formats like [Zarr](../zarr/intro.qmd). + +Scenario: If the COG is intended only for visualization, conversion to 3 band byte will improve performance. + +> GDAL supported Data Types [list](https://gdal.org/drivers/raster/gtiff.html#gtiff-geotiff-file-format) + + +## Compression (aka File Size) + +The biggest benefit to compression is on the storage side. It’s always recommended to use a lossless compression method. **Deflate** or **LZW** are the most recommended compression algorithms, there are some choices that depend on the data type and distribution, and if the goal is maximum compression or not. Maximum compression does result in some performance loss. + +## No Data +Setting a no data value makes it clear to users and visualization tools what pixels are not actually data. For visualization this allows these pixels to be easily hidden (transparent). Historically many values have been used, 0, -9999, etc… The key is to make sure the GDAL flag for no data is set. It is also suggested that the smallest negative value be used instead of a random value. For byte and unsigned integers/floats this will be 0, if 0 has meaning in your data use a different value (like the max possible value). Having the right nodata flag set is important for overview generation. + +## Projection + +Read performance can be greatly impacted by the choice of projection and the particular applications used for dynamic tile serving. Using a known CRS defined in the PROJ database (typically EPSG code) is preferred over custom projections. Load times can be 5-20 times greater when using a custom projection. Whenever applying projections make sure to use WKT2 representation. If using a database of known projections, i.e. EPSG codes, this should be fine, there are known issues around manually setting proj-strings. + +## What we don’t know (areas of research) + +* The optimum size of data at which splitting across files improves performance as a multi-file dataset instead of a single file. +* When to recommend particular internal tile sizes +* Compression impacts on http transfer rates. +* Support for COG creation in all common Geospatial tools varies. + +## Additional Resources + +* [An Introduction to Cloud Optimized GeoTIFFS (COGs) Part 1: Overview](https://developers.planet.com/docs/planetschool/an-introduction-to-cloud-optimized-geotiffs-cogs-part-1-overview/) +* [Do you really want people using your data?](https://medium.com/@_VincentS_/do-you-really-want-people-using-your-data-ec94cd94dc3f) \ No newline at end of file From 79e9df1dec9344a1cc5facfc13803569d4d2246f Mon Sep 17 00:00:00 2001 From: Alex Mandel Date: Mon, 18 Sep 2023 10:22:39 -0700 Subject: [PATCH 7/8] fix: revert erroneous change to index.qmd top level --- _quarto.yml | 1 + cloud-optimized-geotiffs/cogs-examples.ipynb | 4 +- index.qmd | 87 ++++++++++++++++---- 3 files changed, 74 insertions(+), 18 deletions(-) diff --git a/_quarto.yml b/_quarto.yml index fcec87b..b3113a7 100644 --- a/_quarto.yml +++ b/_quarto.yml @@ -35,6 +35,7 @@ website: - section: Cloud Optimized GeoTIFFs contents: - cloud-optimized-geotiffs/intro.qmd + - cloud-optimized-geotiffs/cogs-details.qmd - cloud-optimized-geotiffs/cogs-examples.ipynb - section: Zarr contents: diff --git a/cloud-optimized-geotiffs/cogs-examples.ipynb b/cloud-optimized-geotiffs/cogs-examples.ipynb index 3f71a91..df6a297 100644 --- a/cloud-optimized-geotiffs/cogs-examples.ipynb +++ b/cloud-optimized-geotiffs/cogs-examples.ipynb @@ -308,10 +308,10 @@ "## Data Structure\n", "\n", "**Dimensions**\n", - "Dimensions are the number of bands, rows and columns stored in a GeoTIFF. [More Info](intro.ipynb#dimensions)\n", + "Dimensions are the number of bands, rows and columns stored in a GeoTIFF. [More Info](intro.qmd#dimensions)\n", "\n", "**Internal Blocks** (aka chunks or internal tiles)\n", - "Internal blocks are required if the dimensions of data are over 512x512. [More Info](intro.ipynb#internal-blocks)\n", + "Internal blocks are required if the dimensions of data are over 512x512. [More Info](intro.qmd#internal-blocks)\n", "\n", "Let's check out the dimensions and blocks of our GeoTIFF and Cloud-Optimized GeoTIFF." ] diff --git a/index.qmd b/index.qmd index 82c3f36..6626972 100644 --- a/index.qmd +++ b/index.qmd @@ -1,30 +1,85 @@ -# Cloud-Optimized GeoTIFFs +--- +title: "Cloud-Optimized Geospatial Formats Guide" +subtitle: "Methods for Generating and Testing Cloud-Optimized Geospatial Formats" +--- -## What is a Cloud-Optimized GeoTIFF? +If you wish to provide optimized access to geospatial data, this guide is for you. Given the large and growing size of geospatial data, users can no longer rely solely on file download to achieve their science goals. -Cloud-Optimized GeoTIFF (the COG), a raster format, is a variant of the TIFF image format that specifies a particular layout of internal data in the GeoTIFF specification to allow for optimized (subsetted or aggregated) access over a network for display or data reading. The key components are overviews, and internal tiling. +## Built for the community, by the community. -For more details see [https://www.cogeo.org/](https://www.cogeo.org/) +There is no one-size-fits-all approach to cloud-optimized data, but the community has developed many tools for creating and assessing geospatial formats that should be organized and shared. -COG Diagram +With this guide, we provide the landscape of cloud-optimized geospatial formats and provide the best-known answers to common questions. -### Dimensions +## How to get involved -Dimensions are the number of bands, rows and columns stored in a GeoTIFF. There is a tradeoff between storing lots of data in one GeoTIFF and storing less data in many GeoTIFFs. The larger a single file, the larger the GeoTIFF header and the multiple requests may be required just to read the spatial index before data retrieval. The opposite problem occurs if you make too many small files, then it takes many reads to retrieve data, and when rendering a combined visualization can greatly impact load time. +If you want to contribute or modify content, read the [Get Involved](./contributing.qmd) page. -If you plan to pan and zoom a large amount of data through a tiling service in a web browser, there is a tradeoff between 1 large file, or many smaller files. The current recommendation is to meet somewhere in the middle, a moderate amount of medium files. +If you have a question or idea for this guide, please start a [Github Discussion](https://github.com/cloudnativegeo/cloud-optimized-geospatial-formats-guide/discussions/new/choose). -### Internal Blocks +## The opportunity -> This attribute is also sometimes called **chunks** or **internal tiles**. +Just putting data on the cloud does not solve the big geospatial data problem. Users cannot reasonably wait to download, store and work with large files on their machines. To have access to data in memory, large volumes of data must be available via subsetting methods. -Internal blocks are required if the dimensions of data are over 512x512. However you can control the size of the internal blocks. 256x256 or 512x512 are recommended. When displaying data at full resolution, or doing partial reading of data this size will impact the number of reads required. A size of 256 will take less time to read, and read less data outside the desired bounding box, however for reading large parts of a file, it may take more total read requests. Some clients will aggregate neighboring block reads to reduce the total number of requests. +While it is possible to provide subsetting as a service, this requires maintanence of additional servers and network latency (data has to go to the server where the subsetting service is running and then to the user). With cloud-optimized formats and the appropriate libraries, subsets of data can be accessed remotely without the introduction of an additional server. -### Overviews +Regardless, users will be accessing data over a network, which must be considered when designing the cloud-optimized format. Traditional geospatial formats are optimized for on-disk access via small internal chunks. The introduction of a network introduces latency and the number of requests must considered. -Overviews are downsampled (aggregated) data intended for visualization. -The best resampling algorithm depends on the range, type, and distribution of the data. +As a community, we have arrived at the following **cloud-optimized format pattern:** -The smallest size overview should match the tiling components’ fetch size, typically 256x256. Due to aspect ratio variation just aim to have at least one dimension at or slightly less than 256. The COG driver in GDAL, or rio cogeo tools should do this. +1. Metadata includes addresses for data blocks. +2. Metadata is stored in a consistent format and location. +3. Metadata can be read once. +3. Metadata can be used to read the underlying file format which supports subsetted access via adressable chunks, internal tiling or both. -There are many [resampling algorithms](https://gdal.org/programs/gdal_translate.html#cmdoption-gdal_translate-r) for generating overviews. When creating overviews several options should be compared before deciding which resampling method to apply. \ No newline at end of file +These characteristics allow for parallelized and partial reading. + +## Data Type to Traditional to Cloud-Optimized Geospatial File Format Table + +The diagram below depicts how some of the cloud-optimized formats discussed in this guide are cloud-optimized formats of traditional geospatial file formats. + +![Cloud-Optimized Geospatial Formats](./images/cogeo-formats-table.png) + +Notes: + +* Some data formats cover multiple data types, specifically: + * GeoJSON can be used for both vector and point data. + * HDF5 can be used for point data or data cubes (or both via groups). + * GeoParquet and FlatGeobuf can be used for vector data or point data. +* LAS files are intended for 3D points, not 2D points (since COPC files are compressed LAS files, same goes for COPC files). +* [TopoJSON](https://github.com/topojson/topojson) (an extension of GeoJSON that encodes topology) and [newline-delimited GeoJSON](https://stevage.github.io/ndgeojson/) are types of GeoJSON worth mentioning but not explicitly represented in the diagram. +* GeoTIFF and GeoParquet are geospatial versions of the non-geospatial file formats TIFF and Parquet, respectively. FlatGeobuf builds upon the non-geospatial [flatbuffers](https://github.com/google/flatbuffers) serialization library (though flatbuffers is not a standalone file format) + +## Table of Contents + +1. [Overview of Formats (slideshow)](./overview.qmd) +2. Formats + a. [Cloud-Optimized GeoTIFFs](./cloud-optimized-geotiffs/intro.qmd) + b. [Zarr](./zarr/intro.qmd) + c. [Kerchunk](./kerchunk/intro.qmd) + c. [Cloud-Optimized NetCDF4/HDF5](./cloud-optimized-netcdf4-hdf5/index.qmd) + d. [GeoParquet](./geoparquet/index.qmd) + e. [FlatGeobuf](./flatgeobuf/intro.qmd) +3. [Cookbooks](./cookbooks/index.qmd) + + +## Running examples + +Most of the data formats covered in this guide have a Jupyter Notebook example that covers the basics of how to read and write the given format. At the top of each notebook is a link to an `environment.yml` file that describes what libraries need to be installed for the notebook to run correctly. You can use [Conda](https://www.anaconda.com/download) or [Mamba](https://mamba.readthedocs.io/en/latest/index.html) (a successor to Conda with faster package installs) to install the environment needed to run the notebook. + +## Authors + +* Aimee Barciauskas +* Alex Mandel +* Kyle Barron +* [Overview Slide](./overview.qmd) credits: Vincent Sarago, Chris Holmes, Patrick Quinn, Matt Hanson, Ryan Abernathey + +## Questions to ask when generating cloud-optimized geospatial data in any format + +1. What variable(s) should be included in the new data format? +2. Will you create copies to optimize for different needs? +3. What is the intended use case or usage profile? Will this product be used for visualization, analysis or both? +4. What is the expected access method? +5. How much of your data is typically rendered or selected at once? + +{{< include _thankyous.qmd >}} From a18c208a662f5e0ca514cb13bd233b2cceccaa20 Mon Sep 17 00:00:00 2001 From: Alex Mandel Date: Mon, 18 Sep 2023 10:52:19 -0700 Subject: [PATCH 8/8] fix: config, title, link fixing --- _quarto.yml | 3 ++- _thankyous.qmd | 4 +--- cloud-optimized-geotiffs/cogs-details.qmd | 8 ++++++-- cloud-optimized-geotiffs/intro.qmd | 19 +++++++++++++------ 4 files changed, 22 insertions(+), 12 deletions(-) diff --git a/_quarto.yml b/_quarto.yml index b3113a7..9cf4101 100644 --- a/_quarto.yml +++ b/_quarto.yml @@ -1,5 +1,6 @@ project: type: website + output-dir: _site preview: port: 4200 browser: false @@ -32,7 +33,7 @@ website: text: Overview Slides - section: Formats contents: - - section: Cloud Optimized GeoTIFFs + - section: Cloud Optimized GeoTIFFs (COG) contents: - cloud-optimized-geotiffs/intro.qmd - cloud-optimized-geotiffs/cogs-details.qmd diff --git a/_thankyous.qmd b/_thankyous.qmd index 8ba72d9..2abf6a9 100644 --- a/_thankyous.qmd +++ b/_thankyous.qmd @@ -1,6 +1,4 @@ ---- -title: Our supporters ---- +# Our Supporters ## Thank you to our supporters diff --git a/cloud-optimized-geotiffs/cogs-details.qmd b/cloud-optimized-geotiffs/cogs-details.qmd index 2b73500..c1905ba 100644 --- a/cloud-optimized-geotiffs/cogs-details.qmd +++ b/cloud-optimized-geotiffs/cogs-details.qmd @@ -1,6 +1,10 @@ -# COG Format Details +--- +title: "Make better GeoTIFFs" +--- -In the [COG Intro](intro.ipynb) you can see what makes a COG different from non-optimized GeoTIFFs. The rest of this page details additional GeoTIFF information that can be relevant to making your files as useful as possible but not a COG requirement. +# Make better GeoTIFFs + +In the [COG Intro](intro.qmd) you can see what makes a COG different from non-optimized GeoTIFFs. The rest of this page details additional GeoTIFF information that can be relevant to making your files as useful as possible but not a COG requirement. ## Data Type diff --git a/cloud-optimized-geotiffs/intro.qmd b/cloud-optimized-geotiffs/intro.qmd index 82c3f36..107af12 100644 --- a/cloud-optimized-geotiffs/intro.qmd +++ b/cloud-optimized-geotiffs/intro.qmd @@ -1,6 +1,8 @@ -# Cloud-Optimized GeoTIFFs +--- +title: "Cloud-Optimized GeoTIFFs" +--- -## What is a Cloud-Optimized GeoTIFF? +# What is a Cloud-Optimized GeoTIFF? Cloud-Optimized GeoTIFF (the COG), a raster format, is a variant of the TIFF image format that specifies a particular layout of internal data in the GeoTIFF specification to allow for optimized (subsetted or aggregated) access over a network for display or data reading. The key components are overviews, and internal tiling. @@ -8,23 +10,28 @@ For more details see [https://www.cogeo.org/](https://www.cogeo.org/) COG Diagram -### Dimensions +## Dimensions Dimensions are the number of bands, rows and columns stored in a GeoTIFF. There is a tradeoff between storing lots of data in one GeoTIFF and storing less data in many GeoTIFFs. The larger a single file, the larger the GeoTIFF header and the multiple requests may be required just to read the spatial index before data retrieval. The opposite problem occurs if you make too many small files, then it takes many reads to retrieve data, and when rendering a combined visualization can greatly impact load time. If you plan to pan and zoom a large amount of data through a tiling service in a web browser, there is a tradeoff between 1 large file, or many smaller files. The current recommendation is to meet somewhere in the middle, a moderate amount of medium files. -### Internal Blocks +## Internal Blocks > This attribute is also sometimes called **chunks** or **internal tiles**. Internal blocks are required if the dimensions of data are over 512x512. However you can control the size of the internal blocks. 256x256 or 512x512 are recommended. When displaying data at full resolution, or doing partial reading of data this size will impact the number of reads required. A size of 256 will take less time to read, and read less data outside the desired bounding box, however for reading large parts of a file, it may take more total read requests. Some clients will aggregate neighboring block reads to reduce the total number of requests. -### Overviews +## Overviews Overviews are downsampled (aggregated) data intended for visualization. The best resampling algorithm depends on the range, type, and distribution of the data. The smallest size overview should match the tiling components’ fetch size, typically 256x256. Due to aspect ratio variation just aim to have at least one dimension at or slightly less than 256. The COG driver in GDAL, or rio cogeo tools should do this. -There are many [resampling algorithms](https://gdal.org/programs/gdal_translate.html#cmdoption-gdal_translate-r) for generating overviews. When creating overviews several options should be compared before deciding which resampling method to apply. \ No newline at end of file +There are many [resampling algorithms](https://gdal.org/programs/gdal_translate.html#cmdoption-gdal_translate-r) for generating overviews. When creating overviews several options should be compared before deciding which resampling method to apply. + +## See more + +- Additional [GeoTIFF details](cogs-details.qmd) that can be helpful. +- Making and using [COG examples](cogs-examples.ipynb). \ No newline at end of file