Optimizing Enterprise Web Maps with Cloud-Optimized GeoTIFF (COG) Architecture

Introduction: Rethinking Raster Delivery for Enterprise Web GIS

Adopting Cloud-Optimized GeoTIFF web map architecture transforms how enterprise mapping systems handle large raster datasets, shifting from traditional server-side tile rendering to direct cloud object storage delivery. Enterprise web mapping systems frequently depend on large raster datasets, including satellite imagery, digital elevation models (DEMs), land-cover classifications, and environmental measurements. Delivering these datasets efficiently becomes difficult as spatial coverage, resolution, concurrent users, and visualization requirements increase.

Traditional raster delivery typically involves pre-rendering imagery into thousands of static XYZ tiles or routing requests through a dynamic tile server. Pre-rendering can consume substantial storage and processing resources, particularly when multiple datasets require separate styles, coordinate systems, and zoom levels. Dynamic tile servers eliminate some preprocessing requirements but introduce additional infrastructure, caching complexity, and computational workloads.

Cloud-Optimized GeoTIFF (COG) architecture offers an alternative: serve appropriately structured raster files directly from HTTP-accessible object storage and let compatible clients retrieve only the data they need. This approach uses internal image tiling, reduced-resolution overviews, and HTTP byte-range requests to avoid downloading entire raster datasets for routine visualization. (OGC COG Standard)

The result is a cloud-native geospatial architecture that can reduce tile-generation overhead and simplify raster distribution without eliminating the need for server-side processing in every use case.

This guide explains how to design, implement, validate, and benchmark an enterprise web mapping system built around COGs.

1. Understanding the Core Anatomy of a COG

A COG remains a GeoTIFF or BigTIFF file. Its defining advantage is the organization of its internal structures for efficient remote access, rather than a completely different raster encoding.

Three components make this possible.

1.1 Internal tiles and image blocks

A conventional raster may store imagery in strips or other arrangements that are inefficient when an application needs only a small geographic region.

A tiled GeoTIFF divides the raster into rectangular blocks. A client viewing a particular area can retrieve the compressed blocks intersecting that area instead of downloading the complete image.

The GDAL COG driver uses a default block size of 512 × 512 pixels, although other supported block sizes can be configured. Larger blocks may reduce request overhead but increase the amount of data fetched when only a small region is required. Smaller blocks can improve spatial selectivity but may increase request counts. (GDAL COG driver documentation)

1.2 Image overviews and pyramids

Overviews are reduced-resolution representations of the original raster. They allow a web map to display a large geographic extent without fetching full-resolution pixels unnecessarily.

For example, a raster measuring 32,768 × 32,768 pixels may contain overview levels at progressively smaller dimensions. At a distant zoom level, the client can use a suitable overview rather than reconstructing the display from the original resolution.

Overview generation must match the data’s meaning:

• Continuous data: Average or bilinear resampling is often appropriate for imagery, temperature, and elevation visualization.
• Categorical data: Nearest-neighbor or mode resampling is generally more appropriate for land-cover classes and classified rasters.
• Analytical products: Select the resampling method based on the intended measurement and acceptable error, rather than visual appearance alone.

Overviews improve visualization performance, but they do not replace the full-resolution measurements needed for accurate analysis.

1.3 TIFF directories and byte offsets

A TIFF file contains Image File Directories (IFDs), metadata, and references to image blocks. A COG organizes its full-resolution image, overviews, tile offset arrays, and pixel data to make remote reading efficient.

The geospatial metadata identifies the raster’s coordinate reference system, transform, and geographic extent. A COG-aware client reads the necessary metadata, selects an appropriate resolution level, identifies relevant blocks, and requests their byte ranges.

The approximate workflow is:

1. Retrieve the initial metadata needed to interpret the file.
2. Identify a suitable overview or full-resolution image.
3. Determine the byte offsets for relevant image blocks.
4. Request the required byte ranges from storage.
5. Decode and render the retrieved pixels in the browser.

The layout matters because a valid GeoTIFF is not automatically a well-optimized COG. File organization and remote access behavior must both be considered.

2. How HTTP Range Requests Eliminate the Full-Download Requirement

HTTP range requests allow a client to request a specific section of a resource using the Range request header. A successful partial response normally returns status 206 Partial Content, along with a Content-Range header describing the returned bytes. These behaviors are specified in RFC 9110, HTTP Semantics.

Consider a 2 GB raster stored in an object-storage bucket. If a browser needs only a handful of blocks to display the current viewport, downloading all 2 GB would be wasteful. With an appropriately structured COG, the browser can request the byte ranges corresponding to the required metadata, overview, and image blocks.

The data flow is:

Browser map client → HTTP range request → object storage or CDN → partial byte response → raster decoder → rendered map

This reduces unnecessary transfer, although the actual number of bytes retrieved depends on the file layout, overview levels, block dimensions, viewport, and client implementation.

[Image 1: Diagram showing HTTP range requests fetching specific internal byte ranges from a COG file on S3]

Alt text: System architecture diagram illustrating an HTTP range request pulling specific byte offsets directly from a Cloud-Optimized GeoTIFF stored in S3.

In production, verify that the storage endpoint and any intervening proxy or CDN preserve correct byte-range behavior. A COG’s internal layout cannot compensate for infrastructure that ignores range requests or serves inconsistent content.

3. Step-by-Step Implementation Guide

Step 1: Convert source GeoTIFFs into COGs with GDAL

GDAL provides a dedicated COG output driver that creates the optimized file layout and handles overview generation when needed.

First, inspect the source raster:

gdalinfo input.tif

Review the dimensions, coordinate reference system, band count, data type, NoData values, and existing overviews before choosing compression and resampling options.

Create the COG:

gdal_translate input.tif output.cog.tif \
  -of COG \
  -co COMPRESS=DEFLATE \
  -co BLOCKSIZE=512 \
  -co PREDICTOR=YES \
  -co OVERVIEW_RESAMPLING=AVERAGE \
  -co NUM_THREADS=ALL_CPUS

This example uses lossless DEFLATE compression, 512-pixel blocks, a predictor selected according to the data type, average overview resampling, and multithreaded processing.

Adapt the settings to the dataset:

• DEFLATE: Appropriate when lossless compression is important.
• LZW or ZSTD: Alternative compression choices whose availability and performance depend on the GDAL build and downstream readers.
• JPEG: Useful for many 8-bit photographic imagery products where lossy compression is acceptable.
• PREDICTOR: Can improve compression for supported integer or floating-point data.
• NUM_THREADS: Uses multiple workers for supported processing stages.

The example’s AVERAGE overview method is not suitable for every raster. Replace it with NEAREST for many categorical datasets, or select another appropriate method.

Important distinction: TILED=YES is a creation option associated with the traditional GeoTIFF driver. A file produced with -of GTiff -co TILED=YES -co COMPRESS=DEFLATE is tiled, but that alone does not guarantee a COG-optimized layout. For the final deliverable, use -of COG. See the official GDAL COG driver reference.

For example, the following creates a conventional tiled intermediate when a legacy processing stage requires one:

gdal_translate input.tif staged.tif \
  -of GTiff \
  -co TILED=YES \
  -co COMPRESS=DEFLATE

You can subsequently convert that intermediate using the COG command above. If no intermediate is required, prefer converting directly to COG to avoid unnecessary processing and temporary storage.

Validate the output

Inspect the generated file:

gdalinfo output.cog.tif

On GDAL versions supporting the COG validation subcommand, run:

gdal driver cog validate output.cog.tif

Use a validator compatible with your installed version and include validation in the publishing pipeline. Check that the file has suitable internal tiling and overviews and that its metadata and pixel values meet application requirements.

Step 2: Publish the COG to cloud object storage

Once validated, upload the raster to object storage such as Amazon S3 or Google Cloud Storage. Object storage separates file hosting from application compute and can serve raster data without maintaining a dedicated raster server.

A typical production layout might be:

geospatial-platform/
├── imagery/
│   ├── orthophoto-2026.cog.tif
│   └── sentinel-composite.cog.tif
├── elevation/
│   └── regional-dem.cog.tif
└── landcover/
    └── classification.cog.tif

Use stable paths or versioned object names so cached content remains consistent after updates.

Configure CORS

When a web map and its raster files are hosted on different origins, the browser’s cross-origin resource sharing (CORS) checks may block access unless the storage endpoint permits the required requests.

For a public, read-only map, configure the bucket to allow GET requests from the actual application origin. Depending on the client and its response-header requirements, expose headers such as Content-Range, Accept-Ranges, and ETag.

For Amazon S3, use the bucket’s CORS configuration. For Google Cloud Storage, configure the appropriate CORS settings for the endpoint being used. See the official Amazon S3 CORS documentation and Google Cloud Storage CORS guide.

CORS is not an access-control mechanism. It does not make private objects public or replace bucket permissions, identity policies, or signed access mechanisms.

For sensitive datasets, use authenticated access through an approved design, such as short-lived signed URLs where appropriate. Ensure that the chosen authentication approach works with the COG client’s metadata and subsequent range requests.

Configure caching and delivery

For immutable, versioned COG objects, configure suitable cache lifetimes and consider a CDN when users are geographically distributed. A CDN can reduce repeated origin requests and improve delivery latency for frequently accessed ranges.

Do not apply long-lived caching to mutable object URLs without a reliable invalidation or versioning strategy. Also verify that CDN configuration preserves range behavior and serves consistent versions of each file.

Step 3: Integrate COGs into a browser map

The browser client is responsible for reading the COG and translating the requested geographic view into raster requests.

Two practical options are OpenLayers and Leaflet with georaster-layer-for-leaflet.

Option A: OpenLayers

OpenLayers includes a GeoTIFF source designed for rendering GeoTIFF and COG data as a map layer. Its documented example uses GeoTIFF with a WebGLTile layer. (OpenLayers COG example)

Install OpenLayers:

npm install ol

Create a minimal application module:

import Map from 'ol/Map.js';
import WebGLTileLayer from 'ol/layer/WebGLTile.js';
import GeoTIFF from 'ol/source/GeoTIFF.js';
import {
  getView,
  withExtentCenter,
  withHigherResolutions,
} from 'ol/View.js';

const source = new GeoTIFF({
  sources: [
    {
      url: 'https://your-domain.example/data/output.cog.tif',
    },
  ],
});

const map = new Map({
  target: 'map',
  layers: [
    new WebGLTileLayer({
      source,
    }),
  ],
  view: getView(
    source,
    withHigherResolutions(1),
    withExtentCenter(),
  ),
});

Create a DOM element with id="map" and give it a defined height in CSS. Replace the example URL with the actual published COG URL.

This approach avoids introducing a dedicated raster tile server merely to display an existing COG. The browser reads the raster source and renders the layer according to the map view.

Option B: Leaflet with georaster-layer-for-leaflet

For applications already built with Leaflet, the georaster and georaster-layer-for-leaflet packages provide another option. The layer supports GeoTIFF and COG data and extends Leaflet’s grid-layer mechanism. See the project documentation.

Install the packages:

npm install georaster georaster-layer-for-leaflet

Then load and display a raster:

import parseGeoraster from 'georaster';
import GeoRasterLayer from 'georaster-layer-for-leaflet';

const url = 'https://your-domain.example/data/output.cog.tif';

const georaster = await parseGeoraster(url);

const layer = new GeoRasterLayer({
  georaster,
  resolution: 256,
});

layer.addTo(map);
map.fitBounds(layer.getBounds());

Here, map is an existing Leaflet map instance. The resolution setting controls sampling for the layer’s rendered tiles and should be tuned for the target dataset and device performance.

For either client, test the complete user experience rather than assuming all processing happens on the storage server. Raster decoding, reprojection, styling, and drawing still consume browser resources.

4. Enterprise Architecture and Performance Optimization

Direct COG delivery works best when the system treats raster storage, raster rendering, and analytical processing as separate concerns.

4.1 Use a hybrid architecture where necessary

A practical enterprise design may contain:

• Object storage: The authoritative repository for immutable or versioned COGs.
• CDN: Caches frequently requested content closer to users.
• Web map client: Retrieves raster byte ranges and renders supported layers.
• Application API: Provides authorization, catalog metadata, and business logic where required.
• Raster processing service: Handles dynamic reprojection, server-side color mapping, derived imagery, or formats not adequately supported by the browser.

Direct access is particularly attractive when many users need to explore existing raster products without generating a separate tile pyramid for every layer.

A server-side tile service may still be preferable when the application requires consistent server-rendered styles, controlled access to private datasets, expensive raster calculations, or compatibility with clients that cannot consume COGs directly. The goal is to avoid unnecessary infrastructure, not to eliminate every server-side component.

4.2 Select block sizes and overviews deliberately

The default 512 × 512 block size is a good starting point, not a universal optimum.

Benchmark realistic workloads: panning across a small area, loading a national overview, zooming into a city, and displaying several overlapping layers. Small viewport requests may benefit from smaller blocks, while larger blocks may reduce network overhead for broad or dense access patterns.

Create enough overview levels to support the application’s useful zoom range. If users primarily inspect regional patterns, a missing or inadequate overview can force unnecessary high-resolution reads.

4.3 Control concurrency and browser work

A COG can reduce data transfer while leaving rendering as the bottleneck. Large multiband rasters, multiple visible layers, complex color functions, and reprojection can all increase client-side processing costs.

For enterprise deployment:

• Limit the number of simultaneously active raster layers where appropriate.
• Choose a rendering resolution aligned with display needs.
• Test memory use and responsiveness on lower-specification devices.
• Monitor network concurrency and ensure rapid panning does not trigger uncontrolled request bursts.
• Use server-side processing for operations that would overwhelm browser memory or compute resources.

4.4 Integrate analytics separately from visualization

A COG is well suited to remote raster access, but it should not become the only data representation in the platform.

For example, vector attributes and analytical tables may belong in a spatial database or analytical lakehouse, while large raster products remain in object storage. This separation avoids forcing visualization-oriented file access patterns onto every analytical workload.

Consider interlinking this guide with the related technical resources:

• GDAL Multi-Threading and VRT Optimization: Explain how to prepare and combine raster sources efficiently before creating final cloud-optimized deliverables. Suggested URL: /guides/optimizing-raster-processing-gdal-multithreading-vrt/
• DuckDB Spatial Lakehouse Storage: Explain how analytical tables, spatial queries, and object-storage-based datasets complement COG delivery. Suggested URL: /guides/duckdb-spatial-lakehouse-storage/

Replace these suggested paths with the final published URLs before deployment.

5. Troubleshooting Common COG Delivery Problems

Symptom	Likely cause	Diagnostic action
The browser downloads the complete raster	Range requests are ignored, a proxy interferes, or the client cannot use the file efficiently	Inspect network requests and confirm that partial responses work
CORS errors appear in the console	Incorrect allowed origin, methods, or response-header configuration	Check the actual storage endpoint and browser error details
The map is slow at small zoom levels	Missing or inadequate overviews	Inspect overview levels with gdalinfo
Raster blocks are requested repeatedly	Poor caching, changing URLs, or uncached range responses	Inspect cache headers, CDN behavior, and object versioning
The map freezes on large datasets	Excessive browser memory or CPU use	Reduce layer concurrency, tune rendering resolution, or move expensive processing server-side
The output is not recognized as a COG	The file may be tiled but not correctly optimized	Run a compatible COG validator and regenerate if necessary

A basic range-request test can help isolate storage problems:

curl -sS \
  -D - \
  -H "Range: bytes=0-16383" \
  -o /dev/null \
  "https://your-domain.example/data/output.cog.tif"

For a server that supports the requested range, inspect the response for 206 Partial Content and a suitable Content-Range. A 200 OK response may indicate that the server ignored the range header, so investigate before deploying the dataset.

This test checks HTTP behavior; it does not prove that the file itself satisfies the COG layout requirements. Validate both the file and the delivery path.

6. SEO Best Practices and Technical Documentation

To strengthen the article’s relevance for engineers searching for Cloud-Optimized GeoTIFF COG web map architecture, use the primary keyword naturally in the introduction and appropriate headings. Integrate secondary terms such as “stream COG HTTP range requests,” “optimize raster tile delivery web GIS,” and “cloud-native geospatial formats GDAL COG” where they accurately describe the implementation.

Add contextual internal links to the GDAL VRT optimization and DuckDB spatial lakehouse guides. These links help readers move from raster preparation to cloud delivery and then to analytical architecture.

For authoritative external documentation, link directly to the OGC Cloud-Optimized GeoTIFF Standard, the GDAL COG driver reference, and the selected mapping library’s documentation.

Optimize the image described earlier with a descriptive filename such as cog-http-range-request-architecture.png and keep its alt text meaningful. Include tested commands, code examples, and troubleshooting guidance rather than repeating keywords unnaturally.

7. Performance Benchmarks: How to Measure the Improvement

COG architecture should be benchmarked against the existing delivery approach using the same datasets, test locations, zoom levels, and user workloads. Performance varies considerably with network conditions, storage region, file compression, raster complexity, and cache hit rates, so universal speedup claims would be misleading.

Measure the following indicators:

Metric	Why it matters
Initial map render time	Measures how quickly users see useful imagery
Bytes transferred per viewport	Reveals whether the client retrieves only necessary data
Number of HTTP requests	Shows request overhead and the effectiveness of block selection
Median and P95 response latency	Captures typical performance and slower user experiences
Origin versus CDN traffic	Helps identify caching effectiveness and storage load
CPU and memory usage	Reveals client-side rendering and decoding bottlenecks
Cost per session or workload	Connects technical performance with actual operating cost

Establish at least three comparable test cases: a regional overview, a local high-resolution inspection, and repeated access to a frequently viewed area.

Compare the existing tile-server or pre-rendered workflow with direct COG access and, where relevant, a hybrid CDN-backed implementation. Record cold-cache and warm-cache results separately. Use browser developer tools to inspect transferred bytes and timing, storage logs for origin requests, and application profiling to identify rendering costs.

The expected architectural benefit is that direct COG access avoids generating and storing every possible visualization tile in advance. It can also reduce transferred data when only a small part of a large raster is needed. However, fewer bytes do not always mean faster rendering: a high-latency connection, missing overviews, poor block selection, or expensive client-side computation can offset the gains.

Conclusion

Cloud-Optimized GeoTIFFs provide a practical foundation for scalable raster delivery in enterprise web GIS. By combining internal tiling, reduced-resolution overviews, byte-range-friendly organization, cloud object storage, and compatible browser clients, organizations can make large raster products accessible without requiring a dedicated tile server for every visualization.

The most reliable implementation starts with deliberate GDAL conversion, validates the output, confirms HTTP range and CORS behavior, and tests the browser workflow under realistic conditions. Storage and CDN caching, overview design, compression choices, and client rendering must then be tuned against measurable workloads.

COGs are not a universal replacement for tile servers or analytical raster pipelines. They are a powerful architectural option when remote access to existing raster data is the primary requirement. With a hybrid design where necessary, enterprises can reduce redundant tile generation while retaining server-side capabilities for advanced processing, access control, and data products that demand them.