Building Real-Time Spatial Dashboards in QGIS with GeoNode and PostGIS

Introduction: Why Static Maps Fall Short for Time-Sensitive Decisions

A static map captures the state of a geographic area at a particular moment. That works well for printed reports, planning documents, and historical analysis, but it becomes less useful when the underlying situation changes every few seconds or minutes.

Consider a flood-monitoring team tracking river gauges, a transport department monitoring vehicle locations, or an emergency dispatch center following active incidents. A map exported in the morning may be outdated by the time someone uses it to make a decision.

A real-time spatial dashboard connects incoming geographic data to a database, publishes it through mapping services, and presents updated locations, indicators, and filters to users. The goal is not simply to display moving points. It is to reduce the delay between a real-world event and the information available to the people responding to it.

An open-source stack built around PostgreSQL, PostGIS, GeoNode, GeoServer, and QGIS provides a practical foundation for this workflow. Each component performs a distinct role: data storage, spatial querying, data cataloging and sharing, map service delivery, and desktop analysis.

One important distinction: refreshing a map is not the same as ingesting live data. A dashboard is only as current as its data feed, database updates, service cache, and client refresh behavior. These components must be designed together.

What can you build?

The same pattern can support logistics, utility maintenance, public transport, wildfire monitoring, and many other applications where location and time jointly determine the value of the information.

Building Real-Time Spatial Dashboards in QGIS with GeoNode and PostGIS: A Practical Approach

The core design is a pipeline: incoming observations are written to PostGIS, GeoServer publishes selected data through interoperable services, GeoNode organizes and shares the geospatial resources, and QGIS or a web dashboard displays the information.

1.1 Component responsibilities

GeoNode’s dashboard and map functionality is important here: its MapStore-based tools support charts, tables, counters, and other widgets connected to geographic datasets. These are not the same as a database ingestion engine, so the live feed still needs to be implemented separately.

1.2 Architecture diagram

The main data path is:

1. A device or API produces a new observation.

2. An ingestion service validates and writes it to PostGIS.

3. GeoServer reads the database and exposes the published layer.

4. GeoNode makes the layer discoverable and presents it in maps or dashboards.

5. QGIS and the web client refresh their displayed data according to their configured update behavior.

Important design decision: QGIS Desktop and a browser dashboard are separate clients. Configuring automatic refresh in QGIS does not automatically make the GeoNode web map refresh, and a web map refresh does not control how frequently the database receives updates.

1.3 Polling, event-driven updates, and true streaming

Three approaches are common:

• Polling: The client or service requests updated data at a regular interval. This is simple and often sufficient for dashboards that update every 10–60 seconds.

• Database notifications: PostgreSQL can notify a listening application when changes occur. This can reduce unnecessary polling, but the receiving application must listen for notifications and then refresh the relevant data.

• Streaming or push delivery: A service sends events to connected clients using technologies such as WebSockets or server-sent events. This is more suitable when near-instantaneous browser updates are important.

A live database alone does not guarantee live browser updates. Standard WMS map requests, WFS feature requests, QGIS refresh intervals, and custom push channels each have their own behavior and latency.

For most first implementations, begin with scheduled ingestion and controlled polling. Add event-driven delivery only when the operational requirement justifies the additional complexity.

2. Step-by-Step Implementation Workflow

The following implementation uses a current-position table for moving objects and a separate observation table for historical records. It assumes PostgreSQL and PostGIS are installed, and that GeoServer and GeoNode are already running or will be deployed by an administrator.

The examples use vehicle tracking, but the same design can be adapted to flood gauges, environmental sensors, or incident reports.

Step 1: Create a PostGIS database and live spatial tables

1.1 Enable PostGIS

Connect to PostgreSQL using psql or a database client such as pgAdmin, then create a database:

CREATE DATABASE spatial_live;

Connect to that database and enable PostGIS:

CREATE EXTENSION IF NOT EXISTS postgis;

For an existing managed database, confirm that PostGIS is installed and that your database role has permission to use the extension.

1.2 Create a current-state table

A current-state table stores the most recent known position for each vehicle. The table can be updated repeatedly without creating a new feature for every GPS message.

CREATE SCHEMA IF NOT EXISTS live;

CREATE TABLE live.vehicle_positions (
    vehicle_id       text PRIMARY KEY,
    observed_at      timestamptz NOT NULL,
    received_at      timestamptz NOT NULL DEFAULT now(),
    status           text NOT NULL DEFAULT 'unknown',
    speed_kph        double precision,
    geom             geometry(Point, 4326) NOT NULL
);

The example uses EPSG:4326 for longitude and latitude. This is convenient for storing GPS positions, but it is not suitable for every distance calculation. Use an appropriate projected CRS or a suitable geography calculation when measuring metric distances.

Add indexes:

CREATE INDEX vehicle_positions_geom_gix
    ON live.vehicle_positions
    USING GIST (geom);

CREATE INDEX vehicle_positions_observed_at_idx
    ON live.vehicle_positions (observed_at DESC);

CREATE INDEX vehicle_positions_status_idx
    ON live.vehicle_positions (status);

ANALYZE live.vehicle_positions;

The GiST index accelerates supported spatial queries by using bounding-box filtering before more exact spatial checks. Attribute indexes can also help with common filters, although each additional index adds maintenance overhead during updates.

1.3 Create a historical observations table

A current-state table is efficient for rendering the latest vehicle locations, but it loses previous positions when records are overwritten. Preserve history separately if you need movement trails, historical replay, or performance analysis.

CREATE TABLE live.vehicle_observations (
    observation_id   bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    vehicle_id       text NOT NULL,
    observed_at      timestamptz NOT NULL,
    received_at      timestamptz NOT NULL DEFAULT now(),
    speed_kph        double precision,
    status           text NOT NULL,
    geom             geometry(Point, 4326) NOT NULL
);

CREATE INDEX vehicle_observations_geom_gix
    ON live.vehicle_observations
    USING GIST (geom);

CREATE INDEX vehicle_observations_vehicle_time_idx
    ON live.vehicle_observations (vehicle_id, observed_at DESC);

For a high-volume system, consider partitioning the history table by time, setting a retention policy, and moving older observations to archival storage. Do not partition solely because a dataset is growing; first measure insert rates, query patterns, and retention requirements.

1.4 Update the current position safely

A GPS ingestion service can insert a new vehicle position or update the existing row for that vehicle.

INSERT INTO live.vehicle_positions (
    vehicle_id,
    observed_at,
    status,
    speed_kph,
    geom
)
VALUES (
    'V001',
    '2026-10-20T08:30:00Z',
    'active',
    32.5,
    ST_SetSRID(ST_MakePoint(36.8219, -1.2921), 4326)
)
ON CONFLICT (vehicle_id)
DO UPDATE SET
    observed_at = EXCLUDED.observed_at,
    received_at = now(),
    status = EXCLUDED.status,
    speed_kph = EXCLUDED.speed_kph,
    geom = EXCLUDED.geom
WHERE EXCLUDED.observed_at >
      live.vehicle_positions.observed_at;

This example uses a sample position near Nairobi. Replace it with real coordinates and a timestamp from your data source.

The conflict rule prevents an older GPS observation from overwriting a newer one. For systems that can receive out-of-order messages, this is a valuable safeguard.

Ingestion design checklist:

• Validate the vehicle ID and coordinates.

• Parse timestamps consistently, preferably as timezone-aware values.

• Reject or quarantine invalid observations.

• Decide how to handle late-arriving data.

• Use parameterized SQL or a database driver rather than building SQL strings from untrusted payloads.

• Commit data in sensible batches if the feed is high volume.

• Record rejected messages and ingestion failures.

• Define how to mark a vehicle as stale when it stops sending updates.

For sensors that report measurements rather than locations, store the measurement value, measurement timestamp, quality flag, and associated geometry. Keep the latest value separate from the historical series if dashboard queries frequently need both.

Step 2: Connect QGIS directly to PostGIS

A direct PostGIS connection is useful for inspecting live data, validating the ingestion workflow, and building analytical layers before publishing them to the web.

1. Open QGIS Desktop.

2. In the Browser panel, locate PostgreSQL.

3. Create a new connection.

4. Enter the database host, port (commonly 5432), database name (spatial_live), and an appropriate database role.

5. Test the connection.

6. Expand the database and locate live.vehicle_positions.

7. Add the table to the map canvas.

Use a read-only role for visualization wherever possible. The ingestion service should have the write privileges it needs, while ordinary dashboard viewers should not receive database write access simply because they can see a layer.

If the table does not appear, check the schema, geometry metadata, role permissions, network access, and whether the geometry column and primary key are correctly defined.

Step 3: Configure automatic layer refresh in QGIS

QGIS supports automatic layer refresh at a configured interval. The exact wording and available options can vary slightly by version and layer provider. The important setting is to refresh the data, not just redraw the existing cached features.

3.1 Configure the refresh interval in the interface

1. Right-click the PostGIS layer in the Layers panel.

2. Select Properties.

3. Open the Rendering section.

4. Locate Refresh layer at interval.

5. Enable the setting and specify an interval in seconds.

6. Choose the data-reload behavior if the interface offers a choice between reloading data and redrawing the layer.

7. Apply the change and test it by updating a record in PostGIS.

For an initial test, try an interval of 10 seconds. This is a starting point, not a universal recommendation. A layer containing thousands of complex geometries may need a longer interval, while a small operational layer might support a shorter one.

QGIS terminology and controls can vary across releases. If you cannot find the option, check the documentation for your installed version and the capabilities of the layer’s data provider.

3.2 Configure refresh with PyQGIS

You can also configure a layer’s refresh behavior through the QGIS Python console.

from qgis.core import QgsProject, Qgismatches = QgsProject.instance().mapLayersByName(    "vehicle_positions")if not matches:    raise RuntimeError("vehicle_positions layer not found")layer = matches[0]# Refresh every 10 seconds.layer.setAutoRefreshInterval(10_000)layer.setAutoRefreshMode(    Qgis.AutoRefreshMode.ReloadData)

The interval is specified in milliseconds. This example reloads the data every 10,000 milliseconds, or 10 seconds.

For very large tables, do not assume that a shorter interval is always better. Each reload may trigger new database queries, network transfers, and rendering operations.

3.3 Understand PostgreSQL notifications

Some QGIS data-provider workflows also support refreshing a layer in response to database notifications. This can be more efficient than repeated polling when changes are irregular. However, PostgreSQL NOTIFY does not directly redraw a QGIS canvas by magic: the relevant provider or listening component must support the notification workflow, and the layer must be configured appropriately.

For a simple deployment, interval-based refresh is easier to set up and troubleshoot. For an event-driven design, test the complete notification-to-client-refresh path before relying on it operationally.

Step 4: Publish the PostGIS layer through GeoServer

GeoServer is the mapping service between the database and the web client. It can publish PostGIS tables through services such as Web Map Service (WMS) and Web Feature Service (WFS). GeoServer’s official documentation describes configuring a PostGIS store through its administration interface.

4.1 Create a PostGIS store

1. Open the GeoServer administration interface.

2. Navigate to Data → Stores → Add a new Store.

3. Select PostGIS.

4. Enter the workspace, store name, database host, port, database, schema, username, and password.

5. Set suitable connection-pool options.

6. Save the store and test the connection.

Use a database role with read-only access to the tables GeoServer publishes, unless editing through a deliberately authorized service is part of the design. Avoid using the PostgreSQL superuser for normal application connections.

4.2 Publish the layer

1. Open the new store.

2. Find vehicle_positions.

3. Select Publish.

4. Confirm the native CRS and declared SRS.

5. Calculate or verify the layer bounds.

6. Save the layer configuration.

7. Preview the layer in GeoServer.

The published layer should read from the same PostGIS table that the ingestion process updates. If a separate export or static copy is published instead, changes to the live table will not automatically appear in that copy.

4.3 Choose the correct service

For a dashboard with many moving points, consider rendering the broader context as WMS or cached tiles while retrieving a smaller, filtered set of current features for interaction. Frequently changing layers should not be treated like static basemaps.

Step 5: Register and publish the dataset in GeoNode

GeoNode provides the catalog, metadata, sharing, permissions, maps, and dashboard experience. The exact synchronization steps depend on the GeoNode version and deployment configuration, so treat GeoServer as the service layer and GeoNode as the portal and collaboration layer rather than assuming they are interchangeable.

A typical workflow is:

1. Sign in to GeoNode with an account authorized to manage or publish datasets.

2. Confirm that GeoNode is correctly connected to its GeoServer instance.

3. Register or publish the PostGIS-backed layer through the supported GeoNode/GeoServer workflow for your deployment.

4. Add the layer’s title, abstract, keywords, owner, license, and update-frequency metadata.

5. Verify that its service endpoint works and that the intended audience can access it.

6. Add the layer to a map in GeoNode’s MapStore-based viewer.

7. Save and share the map with the relevant users or groups.

GeoNode documentation describes connecting an existing PostGIS database through

Do not assume that every manually created GeoServer layer is automatically registered and managed as a GeoNode dataset. Follow the supported publication or synchronization workflow for the specific version you deploy.

Permissions and security

Before exposing live data, decide:

• Which users can view the layer.

• Which users can download the underlying features.

• Whether exact vehicle or incident locations are sensitive.

• Whether the dataset should be public, organization-only, or restricted to named groups.

• Whether historical records require different permissions from current positions.

A layer that is appropriate for an internal dispatch team may not be appropriate for public publication. Publish only the fields and geographic precision needed by each audience.

Step 6: Build the web dashboard and its indicators

GeoNode’s MapStore-based viewer includes dashboard tools for creating widgets such as charts, tables, text elements, and counters. Widgets can be connected to datasets and coordinated with map interactions.

GeoNode master documentation

+1

For a vehicle-monitoring dashboard, a useful layout might contain:

6.1 Create a counter widget

A counter can display the number of records matching a filter, such as the number of active vehicles.

1. Open the map in the GeoNode map viewer.

2. Open the layer’s widget panel.

3. Create a counter widget.

4. Select the appropriate dataset and configure the counter’s aggregation or filter options available in your deployment.

5. Give the widget a meaningful title, such as Active vehicles.

6. Save the map and test whether the widget responds correctly to map or dataset filters.

For an incident dashboard, use separate counts for open, assigned, and resolved incidents. Ensure that the status categories are mutually exclusive if the counts are intended to add up to a total.

6.2 Create charts and tables

A status chart can group records by a categorical field such as status. A table can show the most relevant operational fields, while a map provides geographic context.

Useful widgets include:

• A bar chart of incidents by severity.

• A table of unresolved incidents with timestamps.

• A counter showing active incidents.

• A line chart showing sensor readings over time.

• A map highlighting features within a selected area.

Check whether the widget supports the intended aggregation and filtering behavior. For a large history table, querying and grouping every historical observation each time a dashboard loads can be expensive. Use a current-state table or a database view for current indicators, and query the historical table only when needed.

Step 7: Add dynamic filters and status indicators

A dashboard becomes more useful when users can answer specific questions without manually inspecting every feature.

For example, operators might want to display only:

• Vehicles whose status is active.

• Incidents with severity high.

• Sensor readings from the past 15 minutes.

• Records within the current map extent.

• Facilities or incidents assigned to a particular district.

7.1 Filter the layer at the database level

A filtered SQL query can reduce the amount of data returned to the client. For example:

SELECT
    vehicle_id,
    observed_at,
    status,
    speed_kph,
    geom
FROM live.vehicle_positions
WHERE status = 'active'
  AND observed_at >= now() - interval '15 minutes';

This query returns recently observed active vehicles. It does not, by itself, prove that the vehicle is currently operational: a GPS device may have stopped reporting, or the status field may be stale. A robust system should distinguish the reported operational status from the freshness of the latest observation.

7.2 Derive a stale-position indicator

A practical approach is to calculate freshness from the timestamp rather than relying only on the stored status.

SELECT
    vehicle_id,
    status,
    observed_at,
    CASE
        WHEN observed_at < now() - interval '5 minutes'
            THEN 'stale'
        ELSE 'recent'
    END AS freshness,
    geom
FROM live.vehicle_positions;

This is a display rule, not a universal definition of stale data. Choose the threshold according to the device’s expected reporting interval and operational risk.

If a sensor reports every 60 seconds, a five-minute threshold may be reasonable. If a tracking device reports every two seconds, five minutes may be far too long.

7.3 Create a database view for dashboard summaries

For dashboards that display active incident counts, a view can simplify the query logic:

CREATE OR REPLACE VIEW live.incident_summary AS
SELECT
    status,
    severity,
    COUNT(*) AS incident_count
FROM live.incidents
GROUP BY status, severity;

This assumes that live.incidents exists and has the stated fields. The view is evaluated when queried; it does not store a precomputed snapshot. If the dashboard needs to serve large numbers of users or expensive aggregations, consider a materialized view or a separate summary table with a controlled refresh strategy.

7.4 Make filters useful and safe

In GeoNode, configure available widget filters and layer filters using the supported map viewer functionality. For a more customized dashboard, a web application can expose filter controls and request filtered features through a WFS endpoint or a purpose-built API.

For any custom implementation:

• Use parameterized queries on the server.

• Whitelist supported filter fields and operators.

• Limit returned records.

• Use pagination or bounding-box filtering for large datasets.

• Keep database credentials on the server rather than in browser code.

• Apply the same authorization rules to filtered queries as to ordinary layer requests.

Do not let a browser submit arbitrary SQL to PostGIS.

Step 8: Verify that updates reach every client

Once the data pipeline and dashboard are connected, test the entire update path instead of assuming the configuration is correct.

1. Insert or update a test record in PostGIS.

2. Confirm that the updated record appears in a direct database query.

3. Check the QGIS layer after its configured refresh interval.

4. Request the published GeoServer layer again.

5. Check the GeoNode map and widgets.

6. Measure the delay from ingestion to display.

7. Repeat the test with a stale timestamp, a changed status, and an invalid input.

If QGIS shows the update but GeoNode does not, investigate the web service, map cache, client refresh behavior, or publication workflow. If neither client shows it, begin with ingestion, database transactions, permissions, and the layer’s connection details.

A basic latency metric is:

For meaningful monitoring, distinguish the time an event occurred from the time it was received and the time it was displayed. This helps separate delayed devices from delayed ingestion, database, service, or client updates.

3. Performance and Optimization

A dashboard that works with 100 vehicle points may become slow when it must display 100,000 moving features and serve dozens of users. Performance depends on the entire pipeline: message ingestion, database writes, spatial queries, map rendering, network transfer, and client refresh frequency.

3.1 Use an appropriate indexing strategy

Create a GiST spatial index on frequently queried geometry columns. Add ordinary B-tree indexes on attributes used in filtering and sorting, such as status and observation time.

For example:

CREATE INDEX IF NOT EXISTS vehicle_geom_gix
    ON live.vehicle_positions
    USING GIST (geom);

CREATE INDEX IF NOT EXISTS vehicle_status_time_idx
    ON live.vehicle_positions (status, observed_at DESC);

ANALYZE live.vehicle_positions;

PostGIS can use spatial indexes for supported predicates such as ST_Intersects, ST_Within, and ST_DWithin. The index helps narrow the candidate features before the database performs more precise geometric checks.

Avoid assuming every spatial function automatically benefits from an index. For example, a query that calculates ST_Distance against every record and then filters by the result can be slower than a suitable ST_DWithin query. Verify the actual query plan with EXPLAIN ANALYZE on a representative dataset.

3.2 Reduce the number of features sent to the client

Do not send the entire historical tracking table to a browser when the dashboard only needs the latest position of each vehicle.

Useful strategies include:

• Publish the current-state table separately from historical observations.

• Filter by time, status, and map extent.

• Return only the fields needed for the display.

• Simplify complex geometries where appropriate.

• Use clustering or aggregation when displaying dense point distributions.

• Paginate large feature tables.

• Apply zoom-dependent rendering so detailed features are not unnecessarily drawn at small scales.

A dashboard should have an explicit policy for maximum feature counts and query timeouts. When the user zooms out, displaying a density surface or cluster summary may be more useful than rendering thousands of overlapping symbols.

3.3 Configure connection pooling

Each database connection has a cost. GeoServer maintains a connection pool for database-backed stores, allowing it to reuse connections rather than creating a new database connection for every request. Pool settings include minimum and maximum connections, timeouts, connection validation, and fetch size.

Tune the pool based on measured concurrency and database capacity.

• Avoid setting the maximum pool size arbitrarily high.

• Account for connections used by ingestion, QGIS users, administration, and other services.

• Monitor connection wait times and database resource usage.

• Set sensible timeouts and verify idle connections when network interruptions are possible.

• Ensure that the combined connection limits of all application instances remain within the database’s capacity.

If GeoServer runs several instances, calculate the potential total connections across all of them rather than configuring each pool independently.

3.4 Treat caching carefully

GeoWebCache and other caching layers can improve map responsiveness, particularly for static basemaps and slowly changing reference layers. However, cached tiles can become stale after a live layer changes. GeoServer documents tile seeding and cache management as part of its GeoWebCache functionality.

A useful design is to separate layers by update frequency:

If the live layer is included in cached tiles, establish an explicit invalidation or expiration policy. Otherwise, the database can contain new positions while the browser continues displaying an old map image.

3.5 Tune refresh intervals and ingestion batches

Refreshing every second is not automatically better than refreshing every 10 seconds. If a dashboard has 50 users, each refreshing several layers every second, the resulting request load can become significant.

Estimate the approximate request rate:

Where:

• \(R\) is the approximate number of layer requests per second.

• \(U\) is the number of active users.

• \(L\) is the average number of independently refreshed layers per user.

• \(T\) is the refresh interval in seconds.

For example, 30 users refreshing four layers every 10 seconds generate approximately 12 layer requests per second, before accounting for retries, charts, map tiles, and other application traffic.

This estimate is only a starting point. Actual load depends on whether the client reuses requests, how expensive the queries are, and how much data each request returns.

For the ingestion side, batch inserts when it is safe to do so. Use upserts for current-state records, but preserve individual observations separately if you need history. Monitor write latency, table growth, index maintenance, and autovacuum behavior.

3.6 Monitor the system, not just the map

A production deployment should track:

• Ingestion success and failure rates.

• Age of the latest observation.

• Database query latency.

• GeoServer response time and error rates.

• Number of active and waiting database connections.

• Client refresh failures.

• End-to-end display latency.

• Disk usage and historical-data growth.

For emergency or safety-critical applications, add explicit stale-data warnings and define what operators should do when updates stop. A map that quietly freezes can be more dangerous than a map that clearly reports a connection failure.

4. Security and Operational Reliability

Real-time location data can be sensitive. Vehicle locations, emergency incidents, and infrastructure sensor readings may expose operational patterns or personal information.

Before deployment:

• Use encrypted connections where data travels across untrusted networks.

• Store credentials in protected configuration or secret-management systems.

• Give each service only the database privileges it needs.

• Restrict access to internal databases and administrative interfaces.

• Enforce GeoNode permissions and verify access at the underlying service endpoints.

• Log administrative changes and ingestion failures.

• Establish data retention and backup policies.

• Test recovery from database outages, lost sensor connections, and invalid messages.

For a production deployment, test the system under realistic load and simulate feed interruptions. Make it clear in the user interface when the latest data is stale, incomplete, or unavailable.

5. Summary and Use Case Scenario

Worked example: A live flood-monitoring dashboard

Suppose a county emergency management team needs to monitor river-level sensors during heavy rainfall. Each sensor reports its location, observation time, water level, and operational status.

The important distinction is between displaying a threshold breach and establishing a confirmed flood emergency. Sensor errors, missing observations, local conditions, and the limits of the underlying flood model all matter. A dashboard should support decision-making, not imply certainty that the data cannot justify.

Final implementation checklist

• PostgreSQL and PostGIS are configured and accessible to authorized services.
• Current-state and historical tables are designed for their separate purposes.
• Ingestion validates coordinates, timestamps, and incoming values.
• Spatial and attribute indexes support the common queries.
• QGIS can connect to the live PostGIS layer.
• QGIS reloads data at an appropriate interval.
• GeoServer publishes the correct database-backed layer.
• GeoNode recognizes the dataset and applies the intended permissions.
• Map, chart, table, and counter widgets show meaningful values.
• Cache behavior is understood for every frequently changing layer.
• End-to-end update latency and stale-data conditions are tested.
• Monitoring, security, retention, and recovery procedures are documented.

The core lesson is that a real-time spatial dashboard is a coordinated data pipeline, not simply a map with automatic refresh enabled. PostGIS provides the live spatial store, GeoServer delivers geographic services, GeoNode organizes and shares the resources, and QGIS supports desktop analysis and refreshed visualization. When ingestion, queries, refresh behavior, security, and validation are designed together, this open-source stack can provide a practical foundation for operational geospatial monitoring.