GIS Case Study
GeoGrid Analytics — Geodata Visualization & Analysis
A high-performance vector-tile platform for exploring and analysing very large geospatial datasets in the browser.
Domain
Utilities & Energy, geodata Analytics
Role
Full-Stack GIS Developer
At A Glance
What Makes It Work
Renders multi-million-feature national datasets on a web map with no loss of interactivity
Vector tiles served straight out of PostGIS through Martin and Tegola
Live symbology control: colour ramps, categories, opacity and per-layer styling
Attribute tables, feature inspection and on-map spatial querying
Why a browser could not open this data
The client held national-scale utility datasets: every power line, substation and service polygon in the country, running to millions of features. Their existing workflow was desktop GIS: an analyst opened the files locally, waited, and exported static images for everyone else. Nobody outside the GIS team could ask a question of the data directly, and the answer to most questions was a two-day turnaround for a screenshot. A conventional web map was tried first and failed on load. Sending GeoJSON of that size to a browser is not slow; it simply does not work. The brief became narrower and harder: let non-specialists explore the full dataset in a browser, at national zoom and at street zoom, with the styling control an analyst would expect, without a desktop licence.
Serving tiles straight out of the database
The core decision was to stop moving data and start moving tiles. Feature data stays in PostGIS. Martin and Tegola sit in front of it and generate Mapbox Vector Tiles on demand, so the browser only ever receives the geometry visible in the current viewport at the current zoom, already simplified for that scale. A national overview is a handful of small tiles; zooming into a substation yard fetches full-detail geometry for that one area. Because tiles are cut from live tables rather than a pre-built cache, an edit in the database is visible on the next pan. That mattered for a utilities team whose asset register changes weekly. The React front end talks to the tile endpoints and a Django API for attribute queries, so spatial questions, everything within this buffer, all assets of this class in this district, run server-side and return only results. Our web application development work on this project was mostly about deciding what should never leave the server.
What analysts can now do without a desktop
The symbology editor is the part users notice first. Colour ramps, categorical styling and opacity are all live controls applied to the tile layer in the browser, so an analyst can restyle a national dataset by voltage class or asset age in seconds and share the URL. The attribute table sorts, filters and zooms to features, and the layer manager handles visibility, ordering and blending across a stack of datasets. The practical outcome was that the GIS team stopped being a bottleneck. Planners and field managers answer their own questions. The desktop tools are still used for editing and heavy analysis, but the two-day screenshot loop is gone, and the same platform pattern, PostGIS, a tile server, a lightweight client, has since been reused on other data engineering engagements where the dataset was too large for anything else.
Capabilities
Core Functionality
Load and render heavy datasets: power lines, substations, wells, pipelines
Symbology editor with categorical and graduated styling
Attribute table with sorting, filtering and zoom-to-feature
Layer manager with visibility, ordering and opacity control
Basemap switching between satellite, streets and terrain
Feature identification with full attribute pop-ups
Default layer styles saved and reloaded as JSON
Technologies
Tools & Stack
Product
From The Working Application
Questions
Frequently Asked Questions
How large a dataset can this approach handle?
The practical limit is the database rather than the browser. Because tiles are generated per viewport and zoom level from PostGIS, the client only ever receives what is visible, so datasets in the tens of millions of features are workable. Performance tuning happens in indexing, geometry simplification thresholds and tile caching rather than in the front end.
Does the map update when the underlying data changes?
Yes. Tiles are cut from live tables rather than a pre-generated cache, so an edit committed to PostGIS appears on the next tile request. Where a dataset is static, a cache layer can be added in front of the tile server to reduce database load, and that is a configuration choice rather than a rebuild.
Why Martin and Tegola rather than a single tile server?
They have different strengths. Martin is extremely fast for straightforward table-to-tile serving. Tegola gives finer control over per-layer SQL and zoom-dependent simplification. Running both let us pick the right tool per layer without compromising on either.
Can this be deployed on our own infrastructure?
Yes. The stack is PostgreSQL with PostGIS, open-source tile servers and a React client, with no proprietary mapping licence required. It runs on a single Linux host for moderate loads and scales horizontally by adding tile server instances behind a load balancer.
Contact Us
Have A Project?
Let’s Build ItHave a project in mind? Tell us what you're building and we'll get back to you within 12–24 hours with a clear plan.
🔒
100% Confidential
⚡
12–24 Hr Response
🛡️
60-Day Bug Fix
✅
Free Consultation
💬
Start Your Project
Fill in the details below or book a call