← projects

GOKTENGRI

A production-minded geospatial monitoring platform with a Cesium globe and MapLibre operational map

Source code is not publicly available at the moment. This page outlines the system design, data layers, technical architecture, and analytical direction behind GOKTENGRI.

Overview

GOKTENGRI is an operational geospatial analysis platform that brings together global-scale event streams and dynamic data layers on top of a 3D world interface.

The platform is designed to combine satellite tracking, earthquake activity, flight movement, regional risk indicators, and future spatial datasets within a single map-based system. The goal is not merely to display data, but to turn multiple layers of real-world signals into something readable, filterable, and analytically useful.

Rather than treating the project as a simple map visualization, GOKTENGRI is structured as a platform that collects, normalizes, evaluates, and contextualizes spatial data for different analytical scenarios.

System Direction

Many real-world developments are spatial by nature.

An earthquake is not only a seismic event; it can also affect ports, production zones, tourism regions, logistics corridors, insurance exposure, and market sentiment.

Air traffic is not only about aircraft positions; it can also reflect tourism pressure, trade movement, geopolitical shifts, or regional security patterns.

Satellite movement is not only orbital data; it can also be relevant in terms of observation capability, communication infrastructure, strategic visibility, and defense-oriented awareness.

GOKTENGRI is built around this layered perspective. Instead of presenting isolated datasets, it is designed to place multiple data streams in the same geographic context so they can be read together.

This makes the platform suitable for scenarios where geopolitical, financial, touristic, logistical, and operational factors need to be evaluated on the same spatial surface.

Core Data Layers

The platform is structured around independent but combinable data layers.

Current and planned layers include:

Each layer has its own structure, refresh logic, trust profile, and operational value. Because of that, the system does not process all providers in the same way. Satellite data, seismic feeds, and flight tracking sources behave differently at both the technical and analytical level, so each one requires its own ingestion and interpretation model.

Analytical Use Cases

One of the main strengths of GOKTENGRI is that it is not limited to showing one category of data. It is built to support cross-layer interpretation.

Geopolitical Context Analysis

Regional events rarely stay local in their effects. A natural disaster, airspace irregularity, military movement, or infrastructure disruption can influence neighboring countries, trade routes, diplomatic conditions, and security perception.

GOKTENGRI can be used to examine such developments in geographic context.

Examples include:

This shifts the reading of events away from a simple “where did it happen?” view toward a more useful “what could this affect?” model.

Financial Impact Context

Many geographically localized events have broader financial consequences. Natural disasters, airspace restrictions, port interruptions, regional instability, or infrastructure exposure can affect logistics costs, insurance risk, supply chains, and market expectations.

GOKTENGRI provides a spatial base for connecting geographic events with financial impact zones.

Potential analytical directions include:

The platform is not positioned as a direct forecasting engine. Instead, it acts as a decision-support surface where geographically relevant events can be monitored in relation to financial consequences.

Tourism and Travel Context

Tourism is one of the sectors most immediately affected by spatial risk. Earthquakes, flight disruption, regional tension, natural events, or transport pressure can directly influence travel decisions and destination attractiveness.

GOKTENGRI can evaluate tourism regions together with live or near-live event layers, making it possible to assess current spatial context around specific destinations.

Examples include:

This makes the platform relevant not only as a map interface, but as an analytical view for travel platforms, tourism operators, or region-based monitoring workflows.

Logistics and Operational Awareness

Global logistics depends on airports, ports, industrial corridors, transport nodes, and energy-linked infrastructure. Spatial disruptions near those points can create indirect but meaningful operational consequences.

GOKTENGRI can function as a monitoring layer for that type of environment.

Possible use cases include:

In this context, the map is not a visual accessory. It becomes an operational surface for reading change, pressure, and proximity.

Technical Architecture

GOKTENGRI is being developed as a full-stack web application.

Core technologies include:

The frontend handles the 3D map interface and user interaction, while the backend is responsible for ingesting raw provider data, normalizing it, and exposing clean structures for the map layer.

At a high level, the architecture consists of:

This separation keeps the frontend independent from the raw and inconsistent structure of external providers. Changes in upstream formats, delays, or provider limitations can be managed on the backend without turning the client layer into a fragile integration surface.

Provider-Aware Processing

GOKTENGRI does not assume that all providers are equally trustworthy or equally complete.

Each source is evaluated against criteria such as:

This becomes critical once multiple data categories are placed in the same system. A seismic feed, a flight-tracking API, and a TLE source cannot be judged using the same technical expectations.

For example, the absence of a recent earthquake event does not imply provider degradation. Missing aircraft data may reflect receiver density or access limits rather than empty airspace. TLE data may still be operationally useful even when it is not minute-level fresh.

Because of that, provider health and data freshness are evaluated per layer rather than globally.

Satellite Layer

The satellite layer is one of the more technical components of the system.

Satellite positions are not treated as static markers, but as dynamic entities derived from orbital data.

The general processing flow includes:

The main design requirement here is to avoid treating orbital data like a second-by-second live tracking stream. That would create unnecessary cost and an inaccurate freshness model. The layer is instead managed according to the actual behavior of the data source and the meaning of orbital updates.

Earthquake Layer

The earthquake layer is designed to expose recent seismic activity as a map-readable event stream.

Each event can be interpreted through attributes such as:

The layer is not limited to showing where an event occurred. It can also be extended to evaluate what surrounds that event spatially: cities, ports, industrial zones, tourism areas, and transport corridors.

That makes the earthquake layer useful not only as a monitoring feed, but also as an input for broader regional and economic interpretation.

Flight Data Layer

The flight layer is used to observe air movement and traffic density patterns.

Its main limitation is that public flight data is rarely globally complete. Coverage can be affected by receiver density, oceanic blind spots, authentication limits, and rate restrictions.

For that reason, flight data is treated as an observation layer with known coverage constraints rather than as a universally complete truth surface.

It can still be meaningful for scenarios such as:

The distinction between “no data” and “no movement” remains important throughout the interface.

Spatial Data Handling

Since location is central to the platform, PostGIS is part of the database layer.

This makes it possible to move beyond plain latitude-longitude storage and prepare the system for more advanced spatial operations such as:

As a result, the platform is not limited to displaying points on a globe. It can evolve toward real spatial analysis workflows.

Map Experience

In GOKTENGRI, the map is the primary interface.

Because of that, the interaction model is built around information hierarchy rather than visual spectacle alone.

The interface needs to answer questions such as:

The aim is not to overwhelm the user with raw density, but to expose meaningful structure through filters, layer controls, zoom-aware detail, and provider-aware context.

Performance Model

Rendering large and dynamic spatial datasets on top of a 3D globe requires careful performance decisions.

The system is built with attention to:

In map systems, impressive visuals are relatively easy to achieve early. The real challenge is preserving clarity and responsiveness as the number of layers, entities, and scenarios increases.

Development Direction

The long-term direction of GOKTENGRI is not limited to aggregating multiple feeds on one globe. The broader aim is to evolve toward a layered analysis system where geographically linked events can be interpreted together.

Planned directions include:

This positions GOKTENGRI as a platform that can support multiple sectors without being locked into a single narrow use case.

Conclusion

GOKTENGRI is a layered geospatial analysis platform built around the idea that real-world signals become more meaningful when they are read together in spatial context.

Its value does not come from displaying satellite, earthquake, or flight data individually, but from making those layers interpretable on the same operational surface.

Geopolitical developments and their financial implications, natural disasters and their effect on tourism or logistics, shifts in air movement, and geographically concentrated infrastructure risks can all be examined within the same system.

For that reason, GOKTENGRI is positioned not simply as a full-stack map application, but as an extensible operational data platform built on top of a 3D world interface.