← Back to projectsW·O–H / SUMMER 2026All editions ↗

PROJECT 03 / C++ / ALGORITHMS & DATA

Flight Tracker & Finder

Many connections.
One better route.

A flight-search engine that answers real travel questions about price, distance, connections, and time.

Explore the project ↓

Advanced Data Structures · course project

One network. More ways to find a route.

I built a C++ command-line engine that turns airport and flight files into a searchable graph. It finds routes by fare, distance, connections, time, and required stops.

View source on GitHub ↗
Built
16 search operations in approximately one month
Stack
C++ · BFS · Dijkstra · time-aware search
Scale
100+ airports; 100,000+ original course flight records
TRY A ROUTE EXAMPLELOWEST TOTAL FARE
BISBismarck
DENDenver
MSPMinneapolis
ORDChicago
ATLAtlanta
DFWDallas
JFKNew York
Conceptual example — not captured program output
REQUESTMinimum total cost
EXAMPLE ROUTEBIS → DEN → ORD → JFK
EDGE WEIGHTFare in dollars
ENGINEDijkstra with fare weights
SEARCH OPTIONS

What would you like to find?

Explore the original 16-operation menu. Each request shows its inputs, output, and underlying search strategy.

Airport and direct-flight lookup
Path and optimization
Reachability limits
Required stop and time

All 16 operations from the original command-line menu are represented here.

ALGORITHMS

One graph, multiple definitions of “best.”

Every flight is directional. A route from airport A to airport B does not automatically create a route back from B to A. The request determines how the graph is traversed and what each connection means.

BFS
Queue-based traversal

Used to discover a valid multi-stop path and to explore which destinations remain reachable under flight-count or fare limits.

PATHS / REACHABILITY
DIJKSTRA
Variable edge weights

The same shortest-path routine can treat each connection as fare, miles, or a unit weight of one flight, depending on the selected menu operation.

FARE / MILES / CONNECTIONS
TIME-AWARE
Constrained route search

Separate routines account for departure times, arrival times, elapsed hours, and a required middle airport. Required-stop requests run in two stages: source to M, then M to destination.

TIME / REQUIRED STOP
USER CHOICEMenu operation→SEARCH PRIORITYPath · hops · fare · miles · time→RETURNMatching flights or best route

The algorithms operated behind the interface; users selected the travel question they wanted answered rather than selecting an algorithm by name.

DATA MODEL

The data structure made every route addressable.

Airport codes were mapped to indexes for fast lookup. The route matrix then used an origin index, destination index, and flight-option index to preserve every available directed flight between two airports.

FAST LOOKUPairportIndex["BIS"] → 12airportIndex["DEN"] → 46

An unordered map converts a human-readable airport code into the index used by the graph.

→
3D FLIGHT STORAGEflights[origin][destination][option]
12460...n

The first two dimensions identify the route. The third stores each separate flight option available on that route.

→
FLIGHT RECORD
  • Origin and destination
  • Departure, arrival, and duration
  • Fare and miles
  • Flight ID and airline
Classes and structs

Grouped related airport and flight fields into records the algorithms could pass through consistently.

Directed connections

Each stored flight represented movement from one specific origin to one specific destination.

Multiple flight options

The third dimension retained more than one possible flight between the same pair of airports.

Indexed access

The unordered map avoided repeatedly scanning the airport dataset to locate a code.

CHALLENGES

The difficult part was making the entire system agree.

This was my first time working with a dataset this large and my first time combining graph traversal, weighted optimization, schedule constraints, and 16 different requests in one application. The challenge was not limited to one isolated bug.

01Parse

Read two large datasets while keeping airport and flight records consistent.

→
02Index

Resolve airport codes quickly enough to support repeated interactive requests.

→
03Model

Represent directed routes and multiple flight options without losing their details.

→
04Search

Choose the correct traversal or weighted strategy for each user request.

→
05Constrain

Combine stops, times, fares, hours, distances, and destination requirements.

“The whole thing was hard to do.” That difficulty is what made it the first project that showed me I could work through real data complexity rather than only small classroom examples.
SOURCE CODE

The complete project is now available on GitHub.

The public repository contains the original C++ implementation, supporting data files, and instructions for compiling and running the 16-operation command-line application locally.

PUBLIC REPOSITORY github.com/FwDubbb/flighttracker

Review the graph structure, route-search algorithms, airport lookup system, and constrained flight operations used throughout the project.

g++ -std=c++11 11weird.cpp -o flighttracker ./flighttracker place.a1 quizn.air2
View source and run locally ↗
PROJECT CONTENTS
  • Complete C++ source code
  • Airport and flight data files
  • Sixteen command-line operations
  • BFS, Dijkstra, and constrained graph searches
  • Local compilation and usage instructions

The route map above is an interactive explanation, not a claim that the original program used a graphical interface. The 100,000+ scale refers to the original course dataset; smaller public sample files can be included for reproducible demonstrations.

100+ airports 100,000+ original course records 16 menu operations 2 core graph algorithms 1 directed network