3D Flight Tracker: Real-Time Aviation Visualization on Mercator Maps

When Flight Tracking Meets 3D Visualization

Flight tracking projects have always been a popular area for open-source and indie developers. Recently, a project called "3D Airplane Tracker on Mercator Map" gained attention on Hacker News, combining traditional 2D flight maps with 3D visualization to deliver a more intuitive and immersive real-time flight data experience.

The core appeal of these projects lies in transforming abstract aviation data — aircraft latitude, longitude, altitude, heading, and speed — into flowing visual objects on a familiar world map. The upgrade to "3D" means developers must not only handle geographic coordinate projection, but also introduce altitude, model rendering, and camera control, significantly raising the technical bar.

Why Mercator Projection

The Trade-offs of Mercator

The project name specifically highlights "Mercator Map" — and for good reason. Mercator projection is the most widely used projection in navigation and web maps (such as Google Maps and OpenStreetMap). Its key property is angle preservation (conformal projection), which correctly represents headings and bearings on the map — a natural fit for visualizing aircraft tracks.

Invented by Flemish cartographer Gerardus Mercator in 1569 and originally designed for nautical navigation, Mercator projection works by unrolling a sphere onto a cylinder tangent at the equator. The mathematical essence is a transformation of spherical coordinates (φ, λ): x = R·λ, y = R·ln[tan(π/4 + φ/2)]. The logarithmic relationship in the y coordinate produces equal local scale in all directions — the conformal property. Notably, Mercator has a mathematical singularity at the poles: vertical stretching approaches infinity as latitude approaches 90°, which is precisely why Greenland (located between ~60°N and 83°N) appears enormous on Mercator maps despite being only one-fourteenth the area of Africa.

The web mapping world uses "Web Mercator" (EPSG:3857) — a simplified variant that treats Earth as a perfect sphere (radius ~6,378,137 m) rather than an ellipsoid, enabling simpler calculations and more efficient tile loading. Popularized by Google Maps in 2005 and subsequently adopted by Bing Maps, OpenStreetMap, and others, it has become the de facto web mapping standard. Web Mercator crops the world to approximately ±85.05° latitude, making the world map a perfect square — ideal for pyramid-style tile splitting (zoom level z has 2^z × 2^z tiles). For developers, choosing Web Mercator means reusing a mature tile ecosystem, including CDN-distributed pre-rendered raster tiles, vector tile services, and rendering engines.

However, Mercator has a clear limitation: area distortion worsens toward the poles. For flight tracking applications involving polar routes, developers must weigh "user familiarity" against "geographic accuracy." Choosing Mercator is essentially embracing mainstream map interaction conventions.

The Technical Leap from 2D to 3D

Overlaying 3D models onto a 2D projected map is the core technical challenge. Key problems include:

• Coordinate transformation: Mapping aircraft geographic coordinates (WGS84) to Mercator plane coordinates and accurately positioning 3D aircraft models;
• Altitude representation: Real cruising altitude (~10 km) is tiny relative to Earth's scale — visual exaggeration is needed without losing realism;
• Camera control: The 3D scene must support rotation, zoom, and pan while keeping the map and aircraft models precisely aligned.

WGS84 (World Geodetic System 1984) is the global geodetic coordinate system used by GPS and ADS-B data, with Earth's center of mass as origin and a reference ellipsoid with semi-major axis of 6,378,137 m and flattening of ~1/298.257. For flight tracking display, two key transformations are required: first projecting WGS84 geographic coordinates (degrees) to Web Mercator plane coordinates (meters), then mapping to screen pixels based on the current zoom level. Aircraft altitude must be handled separately — typically exaggerated visually by tens of times, since 10 km cruising altitude is only ~0.16% of Earth's 6,371 km radius and would be essentially invisible at true scale.

These problems are typically solved using the WebGL stack. WebGL (Web Graphics Library) is a browser-native 3D graphics API based on OpenGL ES 2.0/3.0, specified by the Khronos Group and natively supported by all modern browsers. It allows JavaScript to call the GPU directly via shader programs for hardware-accelerated rendering. WebGL shaders are written in GLSL and consist of two stages: the Vertex Shader (geometric transformations) and Fragment Shader (pixel coloring). The vertex shader's core job is applying the MVP (Model-View-Projection) matrix chain to map 3D vertex coordinates to 2D clip space.

Since raw WebGL requires manual management of vertex buffers, shader compilation, and render state, several higher-level abstractions have emerged:

• Three.js: The most popular general-purpose WebGL wrapper, providing scene graphs, material systems, and lighting models. The scene graph organizes objects hierarchically so that transforming a parent node automatically propagates to children — updating an aircraft's position and orientation only requires modifying the root node's transform matrix;
• deck.gl: Open-sourced by Uber, optimized for large-scale geospatial data visualization. It uses GPU Instanced Rendering extensively — packing per-aircraft position, rotation, and other parameters into a single GPU attribute buffer and drawing all instances in a single Draw Call. The vertex shader uses the built-in gl_InstanceID variable to read each instance's parameters, enabling thousands of dynamically positioned aircraft to be rendered with near-constant GPU overhead;
• Mapbox GL JS: Built around vector tiles transmitted in Protocol Buffers binary format and rendered client-side by a WebGL engine. The map and data layers share the same WebGL context and depth buffer, enabling correct occlusion — aircraft flying behind mountain ranges — which traditional Canvas 2D overlays cannot achieve.

For flight tracking, deck.gl's ScenegraphLayer combined with a Mapbox GL JS base map is a mature stack. ScenegraphLayer supports loading glTF format 3D aircraft models. glTF (GL Transmission Format), dubbed the "JPEG of 3D," is a Khronos Group standard using JSON for scene structure and binary files for geometry and textures. glTF 2.0 supports PBR (Physically Based Rendering) materials — using metalness and roughness parameters based on Microfacet Theory to physically describe how materials interact with light. This produces realistic aluminum fuselage reflections and cockpit glass Fresnel effects across varying lighting conditions, far beyond the plastic-looking highlights of traditional Phong shading. Combined with instanced rendering, thousands of aircraft with real-time heading-based orientations can be drawn in a single Draw Call.

Where Does Flight Data Come From

The soul of any flight tracker is its data source. Real-time aviation data primarily comes from ADS-B (Automatic Dependent Surveillance–Broadcast) — aircraft actively broadcast their position, altitude, speed, and other information, collected by ground stations or crowdsourced networks.

ADS-B was mandated in the US, EU, and other major aviation jurisdictions around 2020, and most commercial aircraft are now equipped. Aircraft ADS-B transponders (typically Mode S extended squitter format, DF17) broadcast approximately twice per second at 1090 MHz. Each message contains the aircraft's unique 24-bit ICAO address, GPS position, barometric altitude, ground speed, true heading, and vertical rate, receivable up to 200–400 km away in unobstructed conditions.

Position data uses CPR (Compact Position Reporting) encoding, which compresses latitude and longitude into 17-bit integers. Decoding requires combining two consecutive messages (odd and even frames, within 10 seconds) to recover precise coordinates — a single frame can only determine an approximate region (~±5.5° latitude).

This open broadcast characteristic has spawned a massive crowdsourced receiver network: tens of thousands of aviation enthusiasts worldwide use SDR (Software Defined Radio) USB receivers costing as little as $20 to build personal ground stations. The most economical option is the Realtek RTL2832U-based USB dongle ("RTL-SDR") — originally designed for DVB-T digital TV reception, but repurposed as a wideband SDR by directly reading its ADC samples. It downconverts received RF signals to baseband via a tuner chip (such as the R820T2), then digitizes at ~2.4 MSPS, outputting raw I/Q (in-phase/quadrature) complex samples to USB. Paired with open-source software like dump1090 (developed by Redis author Salvatore Sanfilippo) or readsb, a Raspberry Pi plus a simple 1090 MHz antenna can form a stable ADS-B receiving node for under $30.

Common data sources include:

• OpenSky Network: An open ADS-B data network run by Swiss and German academic institutions, offering a free REST API and historical datasets. The API supports bounding-box queries returning state vectors with full position, altitude, speed, and heading fields;
• ADS-B Exchange: Known for "unfiltered, uncensored" data — it doesn't cooperate with governments or corporations to block specific aircraft, making military planes and private jets visible where other platforms hide them;
• Commercial APIs (FlightAware, Flightradar24): More complete data with lower latency, fusing ADS-B with radar and MLAT (Multilateration). MLAT uses Time Difference of Arrival (TDOA) from multiple synchronized ground receivers — each pair defines a hyperbola, and their intersection gives the aircraft's position. At least 4 nanosecond-synchronized receivers are needed for 3D positioning, effectively filling ADS-B coverage gaps at low altitudes and in radar blind spots. These typically require paid subscriptions with strict rate limits on free tiers.

For open-source personal projects, OpenSky Network is often the most practical choice. Its free tier allows full global aircraft state vector snapshots up to once every 10 seconds — sufficient for personal project demos, though higher-frequency per-aircraft trajectory data requires a paid or researcher account.

The Value and Lessons of These Projects

Learning Value Over Practical Value

Given its relatively modest reception on Hacker News, this project looks more like a personal technical exploration than a polished product. But that's precisely its value — it's an excellent comprehensive learning case study.

A complete 3D flight tracker touches nearly every core domain of modern web development: real-time data fetching and processing, GIS, WebGL 3D rendering, performance optimization (potentially thousands of aircraft on screen simultaneously), and interaction design. Any developer looking to systematically advance their frontend and visualization skills will find rich practical value here.

Rethinking When 3D Visualization Makes Sense

You might not have noticed: 3D is not always better than 2D. Mature products like Flightradar24 have long used 2D maps as their primary view — precisely because 2D is often more efficient for quick lookups, information density, and performance. 3D's value lies more in immersion and presentation — large-screen displays, educational demos, or pure visual storytelling.

This is a reminder for developers: technical impressiveness doesn't equal product value. When considering heavy solutions like 3D, clearly defining "who you're solving what problem for" is what matters. For exploratory projects, pursuing visual expressiveness as a goal is entirely legitimate in its own right.

Summary

"3D Airplane Tracker on Mercator Map" is a small but elegant technical project that gracefully integrates geographic projection, real-time data streams, and 3D rendering. The "data visualization + real-time data" project archetype it represents remains an ideal scenario for developers to sharpen comprehensive skills. For developers interested in map visualization or frontend 3D development, building or improving a similar project hands-on often yields more than reading ten tutorials.

Key Takeaways

• Mercator projection's conformal property stems from the logarithmic transformation y = R·ln[tan(π/4 + φ/2)], making it naturally suited for flight heading visualization, though polar area distortion is an inherent limitation. Web Mercator (EPSG:3857) crops the world map into a square to support pyramid-style tile splitting (2^z × 2^z tiles at zoom level z), providing developers a mature tile ecosystem as the web mapping industry standard.
• WGS84 is the foundational reference system for GPS and ADS-B data, with a geocentric ellipsoid and semi-major axis of 6,378,137 m. Getting from geographic coordinates to screen pixels requires two coordinate transformations; aircraft altitude typically needs visual exaggeration to produce meaningful 3D depth.
• WebGL provides browser-side GPU-accelerated rendering; its vertex shader executes the MVP matrix chain to map 3D coordinates to clip space, while the fragment shader handles final pixel coloring. Three.js (with scene graph hierarchy management), deck.gl (with GPU instanced rendering using gl_InstanceID for single Draw Call batch rendering), and Mapbox GL JS (with real-time vector tile rendering) form the mainstream geospatial 3D visualization stack. The glTF format, with its low runtime overhead and PBR material support (metalness/roughness microfacet model), is the preferred 3D asset format for aircraft models in web scenes.
• ADS-B is the foundation of modern flight tracking. Messages use CPR encoding (odd/even frame pairs to decode precise coordinates) in Mode S DF17 long message format. RTL2832U-based low-cost USB receivers capturing I/Q complex sample streams, paired with open-source software like dump1090, bring the cost of building a personal ADS-B receiving node under $30. MLAT multilateration — using TDOA hyperbolic intersection (requiring at least 4 nanosecond-synchronized receivers) — complements ADS-B by filling low-altitude and radar blind-spot coverage gaps.
• The core value of 3D visualization lies in immersion and presentation, not information density. Technology choices should be grounded in clear user scenarios — impressive technical solutions must be justified by real needs.