GovFleet Navigator

GovFleet Navigator is a real-time IoT tracking platform that ingests live GPS streams from thousands of government buses, providing seamless fleet oversight and instant commuter updates without lag.

Comment

GovFleet Navigator: High-Throughput IoT Public Transit Tracking

Inspiration

Public transit commuters often suffer from unpredictable wait times, while civic authorities lack the real-time visibility needed to optimize fleet distribution. We realized that tracking a handful of vehicles is a simple API task, but tracking thousands of government buses concurrently is a hardcore data engineering challenge. We were inspired to build GovFleet to bridge the gap between heavy IoT data streams and seamless, real-time civic utility, ensuring that citizens always know exactly where their bus is.

How We Built It

GovFleet is architected to handle massive, continuous data streams without lagging the backend or the user's browser. We divided the system into three distinct layers:

  1. Data Ingestion Pipeline: We built a Python-based IoT simulator representing thousands of buses moving across Tamil Nadu highways. These mock devices publish their GPS coordinates every few seconds to an Eclipse Mosquitto (MQTT) broker, which is a protocol heavily optimized for patchy, low-bandwidth mobile networks.
  2. Streaming and Caching: To prevent our Node.js backend from being overwhelmed, we implemented Apache Kafka as a shock absorber. A consumer service reads from the Kafka topic and immediately updates the active coordinates in a Redis in-memory cache for sub-millisecond retrieval. Simultaneously, historical trip logs and route data are persisted to MongoDB.
  3. Real-Time UI: The frontend is built with React and Tailwind CSS. We established a WebSocket connection to the Node.js Express server to stream the Redis data directly to the client. For the map interface, we utilized Mapbox GL JS, leveraging WebGL and GeoJSON data sources to render thousands of moving markers natively on the GPU.

Mathematical Formulation of Geospatial Tracking

To calculate accurate real-time distances between moving buses and waiting commuters without overwhelming the server, the backend processes spherical telemetry data using the Haversine formula. Given the latitude and longitude of a bus in radians $(\varphi_1, \lambda_1)$ and a bus stop $(\varphi_2, \lambda_2)$, the great-circle distance $d$ is computed as:

$$a = \sin^2\left(\frac{\varphi_2 - \varphi_1}{2}\right) + \cos(\varphi_1) \cdot \cos(\varphi_2) \cdot \sin^2\left(\frac{\lambda_2 - \lambda_1}{2}\right)$$

$$c = 2 \cdot \text{atan2}\left(\sqrt{a}, \sqrt{1-a}\right)$$

$$d = R \cdot c$$

Where $R$ is the Earth's radius (approximately 6,371 km). By delegating the heavy lifting of these spatial computations to MongoDB's native geospatial indexing ($near, $geoWithin), we maintained high API throughput across the entire fleet.

Challenges We Faced

Handling the sheer volume of MQTT pings was our most significant hurdle. Initially, we tried writing every coordinate ping directly to a standard database, which immediately exhausted connection pools and crashed the server. Introducing Kafka and Redis solved the backend bottleneck, but then the browser froze when rendering thousands of individual HTML map markers. We solved this frontend challenge by transitioning to Mapbox's GeoJSON layers, which bypass the browser's DOM entirely and render the points using hardware acceleration.

What We Learned

We learned that standard HTTP REST APIs are completely inadequate for live, high-frequency IoT tracking. Implementing a message broker like Kafka is absolutely essential to act as a buffer that protects the application layer from traffic spikes. Furthermore, we discovered that frontend rendering limits are just as critical to address as backend bottlenecks; moving data visualization out of the DOM and into WebGL completely transformed the performance and fluidity of the civic dashboard.

Built With

Share this project:

Updates

Submission history