Modern WebGIS Architecture: How Browser-Based Mapping Platforms Work

Ten years ago, serving geospatial data to a web browser required a stack of specialized software: GeoServer or MapServer for WMS/WFS, PostGIS for spatial queries, a tile cache for performance, and a desktop GIS for data preparation. The infrastructure was complex, expensive to maintain, and brittle.

Today's WebGIS architecture looks fundamentally different. Cloud-native formats eliminate much of the server-side complexity. Serverless functions handle on-demand processing. Client-side rendering engines leverage GPU acceleration for smooth interactivity. The result: more capable applications with simpler infrastructure.

The Data Layer

Cloud Optimized GeoTIFF (COG)

The format that changed geospatial data serving. A COG is a regular GeoTIFF with two key structural additions:

• Internal tiling: Data organized in fixed-size tiles (typically 256×256 or 512×512 pixels) rather than scanlines
• Overview pyramids: Pre-computed reduced-resolution versions embedded in the file

These structural features enable HTTP range requests — a client can request just the tiles it needs for the current view extent and zoom level, without downloading the entire file. A 10 GB satellite scene stored as a COG on any HTTP server (S3, Azure Blob, GCS) can be accessed tile-by-tile with no specialized server software.

Vector Tiles (MVT/PMTiles)

Vector data (points, lines, polygons) served as pre-rendered tiles in Mapbox Vector Tile (MVT) format:

• Data is clipped, simplified, and encoded per tile
• Client renders the vectors using style rules (colors, widths, labels)
• Enables smooth zoom transitions and client-side styling

PMTiles: A single-file archive format for vector (or raster) tiles. One file on cloud storage replaces an entire tile server — the client fetches individual tiles via HTTP range requests, similar to COG.

STAC (SpatioTemporal Asset Catalog)

A standardized API and metadata format for discovering and accessing geospatial data:

• Searchable catalogs of satellite imagery, DEMs, and other datasets
• Consistent metadata schema across providers
• Links to actual data files (COGs, etc.)
• Enables building data discovery interfaces without proprietary backends

The Tile Serving Layer

Static Tile Serving

Pre-generated tile pyramids stored as files:

• XYZ convention: /{z}/{x}/{y}.png or .pbf for vector tiles
• Served from any web server, CDN, or cloud storage
• No computation at request time — just file retrieval
• Best for: basemaps, reference layers, datasets that don't change frequently

Dynamic Tile Serving

Tiles generated on-the-fly from source data:

• TiTiler: Python-based dynamic tiler for COGs — reads a COG from cloud storage, extracts the requested tile, applies color mapping, and returns a PNG/WebP
• Martin: Rust-based vector tile server for PostGIS
• pg_tileserv: Lightweight PostGIS vector tile server

Dynamic serving eliminates pre-generation but requires computation per request. Caching (CDN, Redis) mitigates the performance cost for frequently accessed tiles.

Serverless Tile Generation

The newest approach: tile generation functions deployed as serverless (Lambda, Cloud Functions):

• Scale to zero when idle (no infrastructure cost)
• Scale automatically under load
• No server management
• Pay per request

This architecture is particularly attractive for satellite imagery platforms where usage is bursty and datasets are large.

The Client Layer

Mapping Libraries

OpenLayers: Full-featured, supports raster tiles, vector tiles, WMS, WFS, GeoJSON, COG direct reading, and extensive interaction capabilities. Large but comprehensive.

MapLibre GL JS: WebGL-based vector tile renderer forked from Mapbox GL JS. Excellent performance for vector tile rendering and 3D terrain visualization.

Leaflet: Lightweight and simple. Good for basic mapping needs but less capable for advanced rendering or large datasets.

Deck.gl: Specialized in large-scale data visualization (millions of points, complex overlays) using WebGL.

Client-Side Processing

Modern browsers are surprisingly capable for geospatial processing:

• GeoTIFF.js: Read COG tiles directly in the browser
• Turf.js: Spatial analysis (buffer, intersect, area calculation) in JavaScript
• Web Workers: Background processing without blocking the UI
• WebGL/GPU: Hardware-accelerated rendering for smooth map interaction

The trend is toward moving more processing to the client, reducing server load and latency.

The Analysis Layer

Server-Side Analysis

Heavy computation remains on the server:

• Time series analysis across hundreds of satellite scenes
• Machine learning classification
• Large-area statistics (zonal statistics over millions of pixels)
• Data format conversion and reprojection

Typically implemented as API endpoints that accept spatial/temporal parameters and return results (statistics, derived products, classification maps).

Client-Server Hybrid

Many modern WebGIS applications split analysis:

• Server: Generate band math products, compute statistics, run ML models
• Client: Apply color maps, adjust visualization parameters, perform simple measurements

This hybrid approach provides interactive responsiveness (client-side) while leveraging server computational power for heavy processing.

Authentication and Access Control

Multi-user WebGIS platforms need:

• User authentication: OAuth, JWT tokens, session management
• Data authorization: Which users can access which datasets?
• Usage metering: Track tile requests, API calls, storage consumption
• Rate limiting: Prevent abuse and manage costs

These concerns add architectural complexity but are essential for production platforms.

Performance Optimization

Tile Caching

CDN-cached tiles reduce latency and server load:

• Popular basemap tiles cached globally for <50ms delivery
• Dynamic tiles cached with appropriate TTL
• Cache invalidation when source data updates

Progressive Loading

Good WebGIS UX requires:

• Show low-resolution overview immediately
• Load higher-resolution tiles as user zooms
• Prioritize tiles in the current viewport
• Cancel requests for tiles that scroll out of view

Data Compression

• WebP/AVIF: Smaller raster tiles than PNG (30-50% size reduction)
• Brotli/gzip: Compressed vector tiles (60-80% reduction)
• Quantization: Reduce vector tile coordinate precision where full precision isn't needed

The Evolution

The trajectory is clear: from complex server stacks toward simpler, cloud-native architectures where data formats do the work that servers used to do. A COG on S3 replaces a tile server. PMTiles on a CDN replaces a vector tile server. STAC replaces a custom metadata database.

This simplification doesn't reduce capability — it increases it, because the eliminated server infrastructure was overhead that added complexity without adding analytical value. The compute that matters (analysis, visualization, interaction) is preserved; the compute that was just data plumbing (tile generation, format conversion, cache management) is increasingly handled by intelligent data formats and cloud infrastructure.

For anyone building a WebGIS platform today, the architectural choice is straightforward: cloud-native formats, serverless processing where possible, and capable client-side rendering. The traditional GIS server stack still exists and still works, but the modern alternative is simpler to deploy, cheaper to operate, and more scalable.