Designing intelligent geospatial systems is about turning data and analysis into a service that end users can rely on every day. Work in this service line starts with requirements analysis and continues through architecture definition, the spatial database, the processing engine, the service layer and the user interface. The aim is a system that accepts the client’s data in one consistent spatial framework, runs heavy processing in a controlled way and exposes its output through standard services. This page explains the main architecture components, common technical decisions, authentication and roles, offline field work, and the place of machine-learning models and their evaluation. The dependence of model quality on labelled data is stated plainly.
Requirements Analysis and Scope Definition
The first step converts a broad client request into a list of operational questions. To do this, the current workflow, the roles and responsibilities, the existing data, the organisational constraints and the shape of the decision to be supported are examined. The outcome is a document that fixes the scope, the system users, and the expected inputs and outputs.
Acceptance criteria are also defined during requirements analysis so that fulfilment can be judged at the end of the project. These criteria may be the response time of a spatial query, the number of concurrent users, the display accuracy of layers, or the access level attached to each role. Defining them clearly before implementation prevents repeated scope changes.
Part of the analysis concerns data quality: which coordinate reference system the client’s existing data uses, what level of accuracy and completeness it has, and how much preparation it needs before loading. Many project delays originate here rather than in the software itself.
- A list of users, roles and the functions each group must perform in the system.
- A list of input datasets with source, format and the party responsible for each.
- Measurable acceptance criteria for the key system functions.
- An explicit boundary between what this phase covers and what lies outside it.
System Architecture and Component Selection
The usual architecture is layered, with four main parts: the spatial database, the processing engine, the service layer and the user interface. Keeping these layers separate means that changing the interface or adding a new processing engine does not require rewriting the whole system. Layers communicate through defined interfaces so that each part can be tested and replaced independently.
Technology is chosen from the real needs of the system rather than from the novelty of the tooling. For systems handling large volumes of spatial data with concurrent reads and writes, a relational database with a spatial extension such as PostgreSQL with PostGIS is a conventional choice. Component modularity, event logging and status monitoring are designed in from the start.
Design must also account for growth: isolating heavy processing from the request path, allowing additional processing nodes to be added, and defining a job queue for long-running work. It is also decided which data is processed server-side and which part moves to the browser or the mobile app.
Spatial Database and Processing Engines
The spatial database is the heart of the system. Its design begins with data modelling: deciding the table that stores each feature, its attributes, the relationships between tables and the integrity rules that must hold. Topology rules and geometry validation are defined at this stage so that inconsistent data does not enter the system.
Spatial indexing is decisive for query speed; without it, spatial searches over large tables become slow. For very large datasets, strategies such as table partitioning, generating tiled versions and caching frequent results are applied.
The processing engine is the layer that turns raw and existing data into information layers. It may contain a chain of filters, spectral index computation, spatial analysis, classification or execution of machine-learning models. Long-running jobs are executed in a queue and their progress can be followed by the user.
- Data modelling with topology and integrity rules.
- Spatial indexing and strategies for managing data volume.
- Design of the processing chain and a job queue for heavy work.
- Execution logging and the ability to reproduce a run with the same parameters.
Service Layer: OGC Standards and APIs
The service layer is the mechanism that publishes the system’s data and functions. Spatial layers are published through OGC standards: WMS for a rendered map image, WMTS for pre-rendered tiles, WFS for vector features and WCS for raster data. The choice among these services follows from the way the data is consumed; tiles for fast display, vector features for analytical and editing access.
Alongside standard services, application programming interfaces are designed for the system’s specific functions so that mobile apps, dashboards and other organisational systems can work with it. These interfaces are designed on clear principles: resource separation, structured responses such as GeoJSON, standard status codes and versioning to avoid breaking integration later.
Map servers such as GeoServer or MapServer can act as the layer between the database and the standard services. The choice between them and a direct service implementation depends on request volume, caching needs and the required level of access control.
Web Front End, 3D and Tiles
The user interface determines how far the system is adopted in daily work. For two-dimensional systems, libraries such as Leaflet and OpenLayers are used, and CesiumJS is a conventional choice for 3D display and urban modelling. The library is selected against the size of the data, the type of analysis and the complexity of display.
For smooth display, data is converted into vector tiles and 3D tiles so that the browser loads only the area in view. In 3D use cases, formats such as 3D Tiles and data modelling based on CityGML are used for display and analysis of urban volumes.
The display surface is role-oriented: some users only need to view and search, others must edit, and another group wants reports and statistics. The interface is designed separately for each group so that unnecessary complexity is not imposed on everyone.
- 2D display with Leaflet and OpenLayers, 3D display with CesiumJS.
- Conversion to vector and 3D tiles for tile-wise loading.
- Role-oriented interface design matching each group’s task.
- Measurement and spatial query tools within the same display environment.
Authentication, Roles and Offline Field Work
Access control is designed into organisational systems from the start. Authentication may use username and password, signed tokens or connection to the organisation’s identity services. In a token-based architecture, each API request carries a valid token and authorisation is checked on the server.
Roles define who may do what: view, edit, approve, issue reports or manage users. Access can also be restricted by geographic layer so that each user sees only the data relevant to their area of responsibility. Logging user actions is necessary for tracking changes.
In field work, reliable network access is not always available, so the field app is designed offline-first. The required base data is stored locally, field records with photographs and positions remain on the device when there is no network, and once a connection is restored the records are synchronised and conflicts resolved. Defining how the system behaves when local and server data conflict is part of the design.
GeoAI, Labelled Data and Model Evaluation
In the intelligent functions, tasks such as semantic segmentation, object detection and image classification are used. Semantic segmentation assigns a class to every pixel, object detection returns a bounding box and class for each feature, and classification assigns a whole image or patch to one category. The choice among them depends on the shape of the client’s question.
The quality of these models depends first on the labelled data, not on the network architecture alone. Deciding the volume and variety of training data, keeping labelling consistent, and covering the classes that occur in practice are the core of the work. This must be clear with the client from the beginning so that expectations of model accuracy are set realistically.
Models are evaluated with quantitative metrics: precision and recall, the F1 score, and for segmentation the intersection over union. The test set must be separate from the training data and, where possible, drawn from a different area so that the evaluation result is not optimistic. The training method report, the model version and the limits of its use are part of the delivery.
- Define the intelligent function from the operational question, not from the model type.
- Establish labelled-data requirements and the labelling method before training.
- Evaluate with precision, recall, F1 and IoU on an independent test set.
- State plainly that model quality depends on the labelled data.
Summary
Designing intelligent geospatial systems is, before it is programming, an architecture decision: defining the requirement precisely, separating the layers, designing the spatial database correctly and making the service path clear. A system built on this basis can accept new data and gain functions without being rewritten.
The output of this service line may be a Web GIS system, a remote-sensing system, an intelligent processing engine, or a web or mobile interface, depending on the client’s need. In every case the architecture document, the data model, the service documentation and the evaluation report form part of the delivery.
To begin, it is enough to establish the current workflow, the user roles, the existing data and the acceptance criteria; from these the architecture, the component list and the execution plan can be prepared.