GIS Case Study
Vantage Map Studio — Custom Geo-Visualization Framework
A customised, embeddable geo-visualization framework extended with new layer types and integrated into existing web applications.
Domain
Geospatial Data Visualization
Role
Frontend / Geospatial Engineer
At A Glance
What Makes It Work
Forked and extended an open-source visualization framework with client-specific features and branding
deck.gl-powered rendering of large point, line and polygon datasets
Packaged as a reusable NPM module and dropped into host applications
Custom data loaders and schema managers for vector-tile and GeoJSON sources
Extending a framework instead of replacing it
The client already had web applications their users knew, and wanted serious geospatial visualisation inside them, not a separate map portal people would have to open in another tab. Kepler.gl was the right rendering engine for the volume of point, line and polygon data involved, but out of the box it is a standalone application with its own opinions about layout, panels and data loading. Rather than build a visualisation layer from scratch on deck.gl, we forked Kepler.gl and extended it. The goal was to keep the mature rendering pipeline and interaction model, strip the parts that did not belong inside a host application, and add the layer types and loaders the client's data required. That is a narrower engineering problem than it sounds, because the framework's internals were not designed to be embedded.
Making it embeddable
The extended framework is packaged as an NPM module and dropped into host applications as a component. Map state is driven programmatically, addDataToMap and the related actions, so the host application controls what is loaded, when, and how it is styled, without the user touching a file dialog. A schema manager saves and restores full map configuration, which means a host can persist a user's view and rebuild it exactly on return. We registered a custom vector-tile layer into the framework's layer registry so tile-served datasets sit alongside the standard GeoJSON and CSV loaders, and built loaders for the client's own data schemas. The UI was rethemed to the host brand with a trimmed, task-focused panel set: the controls a user of this particular application needs, and none of the ones that would confuse them.
What it delivers in the host applications
End users get high-performance geospatial visualisation without leaving the application they were already in. Dataset and layer blending controls are exposed where they add value and hidden where they do not, and the same module powers several host applications with different data and different branding. The engineering lesson from this project was about restraint. It would have been faster to ship Kepler.gl as-is in an iframe, and it would have been a worse product. Extending the framework properly cost more upfront and produced something the client's own team can maintain: the module is versioned, the extensions are documented, and upstream improvements can be merged. This is the pattern we now recommend on custom software development work where a strong open-source core exists but does not quite fit.
Capabilities
Core Functionality
Custom vector-tile layer registered into the framework's layer registry
Map state driven programmatically via addDataToMap and the processor API
Schema manager used to save and restore full map configuration
Branded UI theme with a trimmed, task-focused panel set
Dataset and layer blending controls exposed to end users
Embedded into host applications as a versioned package
Technologies
Tools & Stack
Product
From The Working Application
Questions
Frequently Asked Questions
Why fork Kepler.gl rather than build on deck.gl directly?
Kepler.gl already solves layer management, styling UI, filtering and interaction on top of deck.gl, and those took years to mature. Forking let us keep all of that and change only what the embedded context required. Building from deck.gl alone would have meant reimplementing most of that UI.
Can the module be used in a non-React application?
The module itself is React-based. For non-React hosts it can be mounted into a container element as a self-contained widget, with map state driven through the exposed API rather than React props. We have done both.
How are upstream Kepler.gl updates handled?
The fork tracks upstream, and our extensions are kept as isolated additions rather than scattered modifications, so merging upstream releases is a routine task rather than a rewrite. The custom layer and loaders register through the framework's own extension points.
Does it support vector tiles as well as loaded files?
Yes. A custom vector-tile layer was registered into the framework, so tile-served datasets from a server such as Martin or Mapbox Tiling Service appear alongside GeoJSON and CSV sources and can be styled and filtered the same way.
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