Flight Itinerary Search

This team algorithms project explores flight-itinerary search in Java. It reads a flight dataset, builds connections that respect departure and arrival times, and compares two search approaches over that schedule. My work covered the entry point, search-node representation, debugging, and refactoring.

An airport alone is not a state

A route through a flight schedule depends on when each leg arrives. Reaching the right airport after the next flight has departed does not create a usable connection. The application groups flights by departure airport and uses sorted sets to find departures within the permitted time window.

Search nodes carry a route’s accumulated duration and price along with its current flight. The final node ordering adds elapsed minutes and simulated ticket price into a combined score. The prices themselves are generated from distance, time-of-day terms, and a seeded random component. This is an experimental dataset model, rather than live booking or fare data.

Two ways to explore the schedule

Algorithm A maintains a priority queue of candidate nodes. Algorithm B builds routes recursively, with a depth bound and a set of airports already used in the current path. Both rely on the same flight and connection data, which lets the project examine different exploration strategies without changing the whole input pipeline.

The checked-in application reads a 50,000-flight CSV and prompts for its search input. Development included changes to flight-time representation, connection lookup, and the objective used to order routes. The report discusses cheapest and shortest routes separately; the final implementation uses the combined score described above. Those are different formulations of the search problem.

My part in the team

The project report credits me with Main, Node, debugging, and refactoring. Ryan worked on Flight and debugging, Mike on FlightList and debugging, and Liza on reading the data. That division matters when reading the source: the schedule model, input, and algorithms belong to a team application, while my clearest implementation scope is the application entry point and node representation.

Reading the historical results

The report retains timing results and complexity claims from the course project. They have not been reproduced in the current review. I also no longer remember the original assignment’s route constraints, and the old decision discussions were unavailable.

The ten Java source files compile unchanged. Later checks on six small synthetic cases found that both searches excluded direct routes, and that a one-stop route could depend on the destination having an outgoing flight. These cases limit any claim of general route correctness or optimality. They also make the connection rules and stopping conditions useful parts of the project to examine alongside the historical report.