One Map, Multiple Analytical Layers: Next-Generation Geospatial Analysis with deck.gl in Vispeahen

One map. Multiple analytical layers. No code required.

In the world of Business Intelligence, maps have long served a simple purpose: showing a location, marking points, and coloring values.

Real-world analytical needs, however, are often far more complex.

You may want to see regional boundaries, customer locations, density, movement, and various data relationships all at once. And this visualization needs to be more than a static map: it should be an active analytical surface that interacts with the rest of the dashboard.

In Vispeahen, we have extended our mapping infrastructure with deck.gl to meet exactly this need.

For us, the goal is not simply to use deck.gl.

The real objective is to turn deck.gl’s powerful, layered visualization architecture into an analytical experience that BI users can work with, without writing any code.

One Map, Multiple Analytical Layers

In Vispeahen, a map is no longer a visual that displays a single data type.

Multiple analytical layers can be combined on the same map, and each layer can be configured independently.

In a single logistics analysis, for example, the following can be displayed simultaneously:

• Polygon Layer for distribution zones

• Scatterplot Layer for warehouses and delivery points

• Heatmap Layer for order density

• Arc Layer for flows between warehouses and delivery points

This approach takes the classic “map chart” concept a step further.

The map is no longer just a location indicator; it becomes a surface where different data layers are analyzed together over the same geography.

Vispeahen currently supports the following layers:

• Scatterplot

• Arc

• Line

• Polygon

• GeoJSON

• Hexagon

• Heatmap

• Tile

• Vector Tile

The Power of deck.gl, Without Code

deck.gl is a powerful geospatial visualization framework.

Used directly, however, it requires a developer-oriented approach.

In Vispeahen, users do not need to:

• write SQL,

• develop in JavaScript,

• learn the deck.gl API, or

• know the Layer classes.

• 
  

  

Users simply select the relevant geometry and metric columns, then configure the structure they want to see through the interface.

The required query is generated automatically by the Vispeahen Query Engine.

From the user’s perspective, the process is straightforward:

Select the data → Select the geometry → Select the metric → Define the layer → Build the analysis

The technical details are handled by the platform.

Maps Don’t Just Display Data, They Talk to the Dashboard

Maps in Vispeahen are not static visuals that merely present results.

They interact bidirectionally with the other components on the dashboard.

For example, when you select Ankara on the map:

• sales charts can be filtered for Ankara,

• KPI values can be recalculated,

• customer distribution can change, and

• other visuals can update according to the selected region.

The reverse also works.

A selection on another chart can filter the map or affect the layers within it.

More importantly, on maps with multiple layers, different interactions can be defined for each layer.

For example:

• Selecting a polygon can update regional KPIs.

• Selecting a customer on the Scatterplot layer can open the customer’s details.

• Selecting a connection on the Arc layer can trigger a movement analysis.

As a result, the map stops being a passive component of the dashboard and becomes an active part of the analysis.

Powerful Maps Are Not Just a Frontend Concern

In geospatial visualization, performance is not only about how fast the browser can render.

The following are also key parts of the overall experience:

• reading the data from the source,

• querying it,

• filtering it,

• aggregating it,

• transporting it, and

• processing it in the browser.

Vispeahen does not leave this process to frontend deck.gl performance alone.

In the background, the Vispeahen Query Engine prepares the data according to the visualization’s requirements and manages the necessary processing steps.

The architecture can be summarized as follows:

Data Source → Vispeahen Query Engine → Processing / Aggregation → deck.gl → Browser

This way, instead of always transferring the full raw dataset to the browser, only the data needed for visualization is prepared and delivered.

Not Tied to a Single Data Source

The Vispeahen Query Engine works with a variety of enterprise data sources.

Supported sources include:

• PostgreSQL

• Oracle

• SQL Server

• MySQL

• MariaDB

• BigQuery

• ClickHouse

• Elasticsearch

• OpenSearch

As a result, geospatial analysis is not tied to a specific database or data architecture.

Your data might live in PostgreSQL.

It might be stored in Oracle.

Your high-volume event data might be in ClickHouse.

Your location-based records might reside in Elasticsearch or OpenSearch.

The analytical experience remains the same for the user.

The user selects the geometry and metric they want to see; Vispeahen handles query generation and data preparation.

Working Directly with Geospatial Data Formats

Vispeahen can read a variety of geospatial data formats natively.

These include:

• Latitude / Longitude

• WKT

• WKB

• GeoJSON

This means the way spatial data is stored across different systems does not turn into additional development work for the user.

The data can be brought directly into an analytical layer.

Where Does DuckDB Come In?

DuckDB is one of the powerful analytical engines used in Vispeahen’s data processing architecture.

However, the Vispeahen Query Engine does not consist of DuckDB alone.

The Query Engine works with a range of data sources, while DuckDB can come into play as part of a high-performance analytical processing layer in scenarios that call for processing and aggregation.

The goal here is to shield users from the technical details of the underlying infrastructure.

Users don’t need to think about which engine is running; they focus on which analytical question they want answered.

The Map Is No Longer Just the Dashboard’s Backdrop

In domains such as IoT, telecommunications, logistics, energy, municipal services, retail, field operations, and mobility, the geographic dimension is central to the data.

For this reason, a map is no longer just the answer to the question:

“Where is this value?”

It is also an analytical tool for answering questions such as:

“Where is it concentrated?”

“Which regions are related to each other?”

“Where is movement originating and where is it heading?”

“How does a change in one region affect other metrics?”

“What do different data layers tell us together over the same geography?”

This is precisely what we aim to achieve with the deck.gl integration in Vispeahen:

To turn geospatial data from multiple sources into a layered, interactive analytical experience, without writing code.

One Map. Multiple Analytical Layers. No Code.

deck.gl offers a powerful visualization foundation.

Vispeahen combines that power with data sources, a query engine, aggregation, dashboard interactivity, and a no-code user experience.

In short:

One map. Multiple analytical layers. No code.