Our goal was to build a Java-based system that calculates driving distances between national parks for use in route planning and optimization.
Team Members:
Project Summary
For this project, we developed a Java-based system to generate a distance matrix between U.S. national parks using real-world geographic data. The system reads park information (name, code, latitude, longitude, and type) from a CSV file and uses the Google Routes API to calculate driving distances between each pair of parks. The resulting distances are stored in a 2D array and exported as a CSV file for further analysis.
The intended purpose of this project is to support route optimization and decision-making problems, such as determining efficient travel paths between multiple locations. This type of system can be applied to logistics, transportation planning, and operations research problems like the Traveling Salesman Problem (TSP).
From an Industrial Engineering perspective, this project relates to optimization and network modeling. The distance matrix serves as the input for solving routing problems, which are commonly used in transportation systems to minimize cost, distance, or travel time.
Throughout the project, we practiced several important technical skills. We created custom Java classes to organize and separate functionality. We worked with ArrayList data structures to store and manipulate park data, and used file input/output to read from and write to CSV files. We also integrated an external library (OpenCSV) to efficiently parse structured data. Additionally, we gained experience working with external APIs.
Project Development Process
Our original goal was to create a road trip planner that could generate optimal routes between national parks while accounting for a user’s vehicle. Initially, we planned to include a feature where users could select their car make and model to automatically determine fuel efficiency and driving range. However, we were unable to find a reliable dataset with MPG values for a wide range of vehicles, so we pivoted to allowing users to manually input their MPG and gas tank size to estimate range and required gas stops. We also reduced the size of our destinations dataset from the 433 units in the National Park System down to only the National Parks in order to reduce runtime and API calls.
As the project progressed, our biggest shift was in the optimization model. We originally attempted to use a Google OR-Tools mixed integer programming model to solve a modified orienteering problem, but we ran into challenges with subtour elimination and the lack of a fixed set of parks, making it incompatible with standard formulations. We then explored several alternatives, including generating permutations, backtracking, and depth-first search, and ant colony optimization, but we ultimately settled on an iterative local search (ILS) heuristic.
Our final model starts with a greedy initial solution, then applies perturbations to escape local optima and iteratively searches for improved routes. The best solution is selected based on maximizing the number of parks visited while minimizing total distance. Overall, our final project evolved significantly from our initial plan, but it closely matched our original design vision and resulted in a functional and realistic road trip planning tool.
Key Features
The biggest component for our website is the integration of the Google Routes API to generate a real distance matrix between national parks. Instead of using straight-line distances, our system calculates actual driving distances based on real roads, so the results are accurate and applicable.
The autocomplete feature on the Starting and Ending Point fields is something that elevates the user experience and makes it feel like a fully developed website. Without this feature, it would be difficult to ensure the user enters in a correctly formatted input to be read by our API. This would make the system less reliable and harder to use.
The overall visual appeal of our website is something we spent a lot of time on. We first chose a color scheme that reminded us of road trips and nature. This attention to design makes the application feel like a complete product rather than just a technical prototype.
Finally, the Preferred Parks input feature adds realism and flexibility to the model. Users often have specific destinations in mind, and this feature allows them to prioritize certain parks while still finding a feasible route. Instead of forcing a route that may not make sense, the system incorporates user preferences in a balanced way, which increases its practicality.
Reflection
Working on this project taught me a lot about teamwork, communication, and problem solving. One thing I learned was that debugging is much harder when you are not the person who originally wrote the code. Because of that, it was really important for our team to communicate clearly and explain our logic to each other either in person or leave comments in the code. We also had to be careful when pushing changes from different computers so we did not accidentally overwrite each other’s work.
Throughout the project, I helped brainstorm ideas and troubleshoot. I worked on the Vaadin layout and click listeners, and for the visual design I found the color scheme and helped get the coding of the styling started based on experience from a previous assignment. I also got the Google API key working at the beginning since it was difficult to find clear resources online initially. I created the distance matrix method, which allowed us to make sure the API key actually worked and laid a foundation for the rest of the project. In addition to the coding side, I handled much of the writing work for the project, including the user guide and mid-progress report. Addison and Emerson quickly became much more oriented with the other aspects of the API, so I tried my best to pick up the slack and make sure they did not have to do as much writing and documenting.
Throughout the process, I grew more confident working on a long-term coding project and pivoting when our original ideas did not work out. It was very intimidating to face a big task that would take so many weeks so I had to get used to setting our own deadlines and pacing. In the end, our pace was good and we did not end up cramming or panicking on the due date. Our successful project taught me a lot about working with a team, dividing duties, and self-pacing.