· 7 min read
Building LK Bus Radar
From data collection to real-time tracking — lessons learned along the way.
I've always been interested in projects that solve a problem I actually experience.
LK Bus Radar started with a fairly simple idea:
What if you could see where a bus actually is instead of just waiting and wondering when it will arrive?
Public transportation is something many people in Sri Lanka depend on every day. But when it comes to buses, there isn't always an easy way to know where a particular bus is, what route it's following, or how long it might take to reach you.
That made me curious.
Could I build something myself?
That's how LK Bus Radar started.
It Started With Data
The first challenge wasn't building the map.
It wasn't the mobile app.
It wasn't even real-time tracking.
It was the data.
A tracking system is only as useful as the information behind it.
I needed things like:
- Bus routes
- Route numbers
- Bus stops
- Timetables
- Route coordinates
- Vehicle information
- GPS locations
- Device information
Some of this information is relatively easy to find.
Some of it isn't.
And that quickly became one of the biggest lessons from the project:
Real-world data is messy.
Building the Data Layer
I started thinking about the project as several separate pieces rather than one big application.
Something like:
LK Bus Radar
│
┌──────────┴──────────┐
│ │
Static Data Live Data
│ │
Routes / Stops GPS Locations
Timetables Vehicles
│ │
└──────────┬──────────┘
│
▼
API
│
▼
Web / Mobile App
Static information doesn't change very often.
A bus's location is completely different.
That distinction became important when designing the system.
There was no reason to constantly request information that hadn't changed.
MongoDB for the Tracking Data
For the tracking side of the project, I worked with MongoDB.
It made sense for the type of information I was dealing with because vehicle data can change frequently and doesn't always fit neatly into a rigid structure.
A simplified representation could look something like:
Vehicle
├── Device ID
├── Bus Number
├── Route
├── Latitude
├── Longitude
├── Speed
└── Timestamp
Every location update gives the system another piece of information about where that vehicle is.
The timestamp is particularly important.
A location without a timestamp doesn't tell you much.
If a bus was reported at a location ten minutes ago, showing that point on a map as though it were current could be misleading.
Static Transport Data
I also worked with static transport information separately.
Things such as:
- Routes
- Route metadata
- Timetables
- Stops
- Transport information
could be stored and updated independently from live GPS information.
This helped keep the system more organized.
I also explored using Firebase Cloud Functions to periodically synchronize static transport data.
The idea was simple:
External Data
│
▼
Cloud Function
│
▼
Validate / Process
│
▼
Database
│
▼
LK Bus Radar
Instead of manually updating the data every time something changed, the system could handle the synchronization automatically.
The Real-Time Part
This was where things became much more interesting.
Getting a GPS coordinate isn't particularly difficult.
Turning a stream of GPS coordinates into something useful is another story.
Imagine receiving:
06:20:01 → 6.9271, 79.8612
06:20:05 → 6.9273, 79.8616
06:20:09 → 6.9277, 79.8620
06:20:14 → 6.9281, 79.8625
Those points aren't just numbers.
Together, they describe movement.
The application can use them to determine where the vehicle is and display that movement on a map.
Making the Map Useful
One of the most visible parts of LK Bus Radar is obviously the map.
But putting a marker on a map is the easy part.
The harder questions are:
Which bus is this?
Which route does it belong to?
Is its location current?
Where is it going?
What happens when the GPS signal disappears?
Those questions forced me to think beyond the UI.
The map is really just the final layer of a much bigger system.
GPS Isn't Perfect
Real-world GPS data isn't as clean as data generated in a controlled environment.
There can be:
- GPS drift
- Missing updates
- Delayed updates
- Incorrect coordinates
- Sudden jumps
- Poor signal
- Devices going offline
For example, a vehicle might suddenly appear several hundred meters away from its previous position.
That doesn't necessarily mean the bus actually teleported.
It might simply be a bad GPS reading.
This introduced another important part of the project:
Data validation.
Before displaying information to users, the system needs to have some understanding of whether the data makes sense.
Designing the API
Once the database and tracking logic started taking shape, I needed a way for applications to access the data.
That's where the API came in.
Instead of allowing the web or mobile application to communicate directly with the database, the API becomes the middle layer.
Mobile App
│
▼
API
│
▼
Database
│
├── Routes
├── Vehicles
├── Stops
└── Locations
This gives the application a controlled way to request exactly what it needs.
For example:
GET /vehicles
GET /vehicles/{id}
GET /routes
GET /routes/{id}
GET /routes/{id}/vehicles
The exact implementation evolved as the project developed, but the principle stayed the same.
Keeping the System Efficient
One thing I learned quickly is that real-time applications can become expensive and inefficient if you're not careful.
Imagine having hundreds of vehicles sending updates every few seconds.
That's a lot of data.
Then imagine hundreds or thousands of users requesting those locations at the same time.
The numbers grow very quickly.
So I had to start thinking about:
- How frequently GPS data should be stored
- How frequently clients should refresh
- Which data should be cached
- Which information should be static
- How much historical data is actually necessary
- How to reduce unnecessary database requests
A real-time system isn't simply about making everything update as quickly as possible.
It's about finding a sensible balance.
The Mobile and Web Experience
Once the backend started coming together, the next challenge was turning all that data into something people could actually use.
A user shouldn't have to understand databases, APIs, GPS coordinates, or transport metadata.
They should simply be able to open the application and see something useful.
Ideally:
Open App
↓
Select Route
↓
See Available Buses
↓
Select Bus
↓
See Current Location
↓
Follow Movement
That's the experience I wanted LK Bus Radar to provide.
What I Learned From the Project
LK Bus Radar taught me a lot more than I expected.
1. Data Is Harder Than Code
Writing code is often the easy part.
Finding reliable, consistent, usable data can be much harder.
A beautiful application built on bad data is still a bad application.
2. Real-Time Systems Are Different
When an application depends on constantly changing information, you have to think about time.
Is the information current?
How old is it?
What happens when updates stop?
What should the user see?
These are questions that don't exist in the same way in a normal CRUD application.
3. Backend Design Matters
It's easy to focus on the map because that's what users see.
But the real work happens behind it.
The database, API, data processing, synchronization, validation, and tracking logic are what make the map useful.
4. Start Small
One of the biggest lessons was not trying to build everything at once.
It's tempting to think:
"I'll build the entire transport system."
But that's a huge problem.
It's much easier to start with:
One route
↓
One bus
↓
One GPS device
↓
One API
↓
One map
Then expand.
The Bigger Idea
LK Bus Radar isn't just about tracking buses.
It represents something I enjoy about software development.
You start with a real-world problem.
Then you try to understand it.
Then you collect the data.
Then you build something around that data.
Then you discover that the real world doesn't behave as neatly as your code does.
So you adapt.
That's where the interesting part begins.
What's Next?
There are still plenty of things I'd like to improve.
Things like:
- Better route matching
- More accurate ETA calculations
- Improved GPS filtering
- Historical trip data
- Better route visualization
- Notifications
- Improved mobile experience
- More reliable real-time updates
- Better data synchronization
- Analytics around routes and vehicles
There is also a lot of potential in using the collected data to understand transportation patterns rather than simply displaying vehicle locations.
Final Thoughts
LK Bus Radar started as an idea around a very simple question:
"Where is the bus?"
But building it taught me that answering that question isn't simple at all.
You need data.
You need reliable GPS information.
You need a database.
You need APIs.
You need synchronization.
You need to deal with bad data.
And eventually, you need to turn all of that into something a person can understand in a few seconds.
That's what made the project so interesting for me.
It wasn't just about building another application.
It was about taking something from the real world, collecting information about it, and trying to turn that information into something genuinely useful.