OrionEye

• 

  Layer

💡 What Inspired Me

In today’s interconnected world, critical global data—ranging from satellite trajectories and live air traffic to network routing, natural disasters, and geopolitical conflicts—is vast, but deeply fragmented. Analysts, developers, and researchers often find themselves juggling dozens of disconnected dashboards, command line tools, and API feeds just to gain a clear picture of an ongoing event. I set out to build OrionEye to solve this operational friction. Inspired by military command terminals and modern OSINT (Open Source Intelligence) workflows, my goal was to build a unified, high-performance visual dashboard that fuses digital infrastructure, spatial analytics, and live orbital dynamics into a single, intuitive interface.

🛠️ How I Built It

OrionEye is built as a web-based real-time geospatial terminal and intelligence hub. The architecture is split into two core layers: a fast, dynamic UI/FX engine and a multi-source data ingestion pipeline.

• Geospatial & Orbital Engine: I integrated CelesTrak data to calculate and project satellite orbits in real time using simplified general perturbations models (SGP4). Orbital state vectors are updated dynamically using position vector equations:
• Live Infrastructure & Telemetry: I integrated the OpenSky Network API for aircraft position tracking, alongside RIPE Atlas probes to trace network latency (\Delta \tau) and hop routing across global ASNs.
• OSINT & Environmental Feeds: The platform streams real-time data from GDELT (Global Data on Events, Location, and Tone) for conflict tracking, alongside live NASA Earth Observatory feeds and ESA launch event streams.
• Tactical Terminal UI: Designed with a modular Command-Line Interface (CLI) system supporting custom visual pipeline shaders (Night Vision/NVG, Thermal/FLIR, and Cyber HUD) using Canvas/WebGL filters. ##🚧 Challenges I Faced
• High-Frequency Data Fusion: Combining high-throughput REST APIs, WebSocket feeds, and client-side orbital calculations without causing frame drops or browser freezing was a major hurdle. I optimized spatial rendering and implemented temporal batching to handle thousands of simultaneous map markers smoothly.
• Coordinate & Projection Alignment: Harmonizing vastly different spatial standards—from standard GPS coordinates (WGS84) and satellite Two-Line Element (TLE) sets to network routing graphs—into a cohesive map required precise geospatial transformations.
• API Rate Limiting & Fallbacks: Managing public API rate limits (such as OpenSky and GDELT) across users required building efficient client-side caching mechanisms and graceful fallback states. ##🎓 What I Learned Building OrionEye taught me key lessons in geospatial data engineering, high-performance web rendering, and OSINT aggregation:
• Mathematical Precision in Web Rendering: Processing orbital mechanics and coordinate transformations directly on the client side reinforced the importance of math optimization in frontend performance.
• The Power of Unified UX: Aggregating diverse datasets into one cohesive terminal drastically reduces cognitive load—proving that how data is presented is just as crucial as the data itself.
• Resilient Architecture: Dealing with disparate external APIs highlighted the necessity of non-blocking asynchronous data pipelines in real-time dashboards.

Built With

• canvas-api
• celestrak-api
• css-shaders
• css3
• data-visualization
• esa-data-api
• gdelt-api
• geojson
• geospatial-data
• gis
• html5
• javascript
• json
• leaflet.js
• mapbox
• nasa-earth-api
• node.js
• opensky-network-api
• osint
• rest-api
• ripe-atlas-api
• sgp4
• webgl
• websockets