A Web GIS system is the platform that makes an organisation’s spatial data available in one continuous chain from the database to the user’s browser. Designing it does not begin with a mapping library; it starts with the data architecture and the service layer, and ends with user experience and a publishing strategy. A capable Web GIS must provide fast search, smooth rendering of heavy layers and role-based access control at the same time. In many projects the system has to stay responsive on limited infrastructure, sometimes a single server. This page reviews the architectural components and key decisions behind such a system.
Overall architecture and technology choices
These systems typically use a four-layer architecture: a spatial database, a service layer, a tile layer and a user interface. Keeping these layers separate means changing the client-side mapping tool does not require rewriting the data logic.
Technology choice should follow data volume, concurrent user count and the need for server-side analysis, not the popularity of a tool. For small and mid-sized projects, a light combination of one spatial database and one map server is sufficient.
Design should be growth-ready from the outset: adding a new layer, user role or service should not force a redesign.
- A spatial database for storing geometry, attributes and metadata.
- A map server publishing layers on OGC standards.
- A tile layer for fast, scalable display of high-volume data.
- A web interface for display, search and editing.
Spatial database and indexing
The backbone of the system is the spatial database. Storing geometry and attributes in a relational database with a spatial extension enables combined queries and topology rules, and prevents data from scattering across loose files.
A spatial index is essential for fast responses; without it, bounding-box queries on heavy data run slowly. Normalising tables and defining join keys prevents data duplication and inconsistency.
Topology rules and geometry validation should be applied at the database level, so invalid incoming data is filtered before it reaches the display layer.
Service layer and APIs
The service layer is the interface between data and consumers. Publishing vector data with WFS, map imagery with WMS and WMTS, and raw raster data with WCS follows the standard pattern for accessing spatial data.
Alongside standard services, a dedicated API is needed for application logic. A light data format such as GeoJSON suits small interactions and API responses, while heavy data should use tiles or tiled vector files.
The API contract should be stable and documented so mobile apps or side systems can be built on the same logic, and data logic is not duplicated in several places.
Vector tiles and caching strategy
Vector tiles deliver data at several zoom levels in a display-ready form, reducing transfer volume and client-side processing. For dense urban layers this behaves far more smoothly than sending GeoJSON directly.
Caching stores service responses and reduces database load on repeated requests. Setting the allowed tile zoom levels and cache lifetime balances data freshness against speed.
For data that changes frequently, the cache is better refreshed on a time or event basis so users do not see stale data.
Client-side mapping and interaction
The client-side mapping library is chosen from the interaction requirements. Light libraries suit two-dimensional maps with fast interaction, while three-dimensional libraries serve volumetric model display and spatial analysis.
User experience design should start from the real question: find a feature, pan to an extent, measure, and act on a record. Base layers and overlays should be shown with clear control and naming.
Responsiveness and accessibility are part of the design too, particularly where users rely on tablets for field operations.
- A distance, area and where needed volume and profile measurement tool.
- Selection, identification and inspection of feature attributes.
- Layer visibility control and saving of the user’s preferred view.
Search, filtering and dashboards
Search in spatial systems takes two forms: spatial search by point, extent or adjacency, and attribute search by descriptive fields. Combining them enables questions such as finding all records of a class within a defined extent.
Dashboards turn spatial data into readable indicators, and reporting is the system’s formal output. Producing results in common formats such as PDF, spreadsheet and spatial file meets the needs of administrative users.
Dashboard design should avoid busy, message-free visuals; every chart should answer a specific decision or question.
Authentication, roles and performance under load
Role-based access control determines which data each user sees and which actions they may take. Token-based authentication is a simple and effective pattern for systems serving both a mobile app and a web dashboard.
Performance depends on three factors: the spatial index, response size and the caching strategy. Limiting the number of returned features and using tiles instead of one-off responses has the most durable effect.
For users on low bandwidth or unstable connections, reducing base imagery volume, allowing browser-side caching and sending light payloads matters. The system should also respond to the normal load on a single server when resources are configured correctly.
Summary
Designing a Web GIS system is a question of architecture: an orderly database, a clear service layer, an efficient tile and cache strategy, and a user interface that matches the real question. Each of these layers affects the performance of the others.
We recommend taking the spatial index and topology rules seriously, offering a stable and documented API, and building access control in from the outset. Following these principles turns the system from a map viewer into an operational platform for the organisation.
In the end, a system that stays responsive on limited infrastructure provides more practical value than a feature-rich but fragile one.