HillPark

Project summary and skills

Built with Damir Ashinov and Sam Brown. Their names link to their own ePortfolios.

Parking is the most common complaint on the University of Arkansas campus. The university sold 21,124 annual car permits in fiscal 2025 for 14,632 spaces, about 1.44 permits for every space. A permit tells you where you're allowed to park, not where you should. HillPark answers the second question for one person's week.

You enter your permit and your classes. For each class day, HillPark ranks the lots and garages your permit allows by walking time, driving time and traffic, estimates how full each lot will be when you arrive, and checks whether parking at the Economy lot and taking the bus would be faster. The Your week tab then picks the best one to three lots for the whole week.

The data

• 110 parking lots and garages with their outlines and permit rules, and 217 campus buildings, from the university's interactive campus map
• Streets and footpaths from OpenStreetMap, for walking and driving routes
• TomTom road speeds at 12 points around campus, logged every 30 minutes since September 28 for our operations research project
• Razorback Transit's published bus schedule (GTFS)

The industrial engineering concept

Choosing lots for a week is a facility location problem: the class days are the customers, the lots are the facilities, and the question is which few facilities to open so that serving every customer costs as little as possible. That's the p-median model, and HillPark solves it as an integer program (see Key features). The app as a whole is a decision-support tool: it turns lot outlines, permit rules, street networks, a traffic log and a bus timetable into one recommendation, and shows the reasons behind it.

Skills I practiced

• Custom Java classes and inheritance. The interface pieces extend Vaadin's Div and Dialog, and one TrafficForecast interface has three implementations, so the scoring code doesn't care which forecast is chosen.
• Collections and file input. Lots, buildings, traffic readings and bus trips are read from CSV, JSON and GTFS files into lists and lookup tables at startup.
• External libraries. Tablesaw to clean and summarize the traffic log, Smile for the forecast, Google OR-Tools for the week plan, and Vaadin for the interface.
• GitHub workflow. A shared repository, 35 JUnit tests, and one-click start scripts so every teammate can run it.

Development process

The original idea

HillPark grew out of our operations research project on campus parking. Damir and I had already mapped every lot and started logging traffic for that model, and we realized the same data could help one student decide where to park, not just help the university decide which permits each lot should take.

How the scope changed

The first version ranked lots for a single day. It grew into a plan for each class day, then added where you drive in from, an estimate of how full each lot is, park and ride from Lot 500, and a saved schedule. The last additions use the course's toolkit most directly: the Smile traffic forecast and the OR-Tools week plan.

Roadblocks and how we got past them

• No occupancy data. We've asked Transit & Parking how full each lot gets, but that data hasn't arrived. Until it does, the app labels its fullness figures as estimates instead of presenting them as facts.
• Blank bus times. About 80% of the stop times in the transit feed are empty, so HillPark fills them in by distance along each route.
• Library limits. Vaadin versions after 24.10.7 need a paid license key, so the project stays on that version. Smile's linear models need native math libraries for every operating system, so the app leaves them out.
• Build problems. IntelliJ picked a newer JDK on my laptop and the build failed with a confusing “JVM target 5” error. The start script now looks for Java 21 first, and the README explains the fix.

Key features

A week plan from an integer program

What it does: you choose how many different lots you're willing to use, from one to three, and OR-Tools picks the lots and which days go to each so the week's total score is as low as possible.

The core of the model in Java, from LotCountOptimizer (comments added for this page):

MPVariable[] y = new MPVariable[lots];
// y[l] = 1 if lot l is one of your lots
for (int l = 0; l < lots; l++) y[l] = solver.makeBoolVar("use_lot_" + l);
for (int d = 0; d < days; d++) {
    // park in exactly one lot on each class day
    MPConstraint parkOnce = solver.makeConstraint(1, 1, "park_once_day_" + d);
    for (int l = 0; l < lots; l++) {
        // skip lots your permit can't use that day
        if (!Double.isFinite(cost[d][l])) continue;
        x[d][l] = solver.makeBoolVar("park_d" + d + "_l" + l);
        parkOnce.setCoefficient(x[d][l], 1);
        // x[d][l] - y[l] <= 0: park only in lots you picked
        MPConstraint onlyPicked = solver.makeConstraint(-inf, 0, "picked_d" + d + "_l" + l);
        onlyPicked.setCoefficient(x[d][l], 1);
        onlyPicked.setCoefficient(y[l], -1);
        objective.setCoefficient(x[d][l], cost[d][l]);
    }
}
// use at most K lots in the week
MPConstraint atMostK = solver.makeConstraint(0, maxLots, "at_most_k_lots");
for (int l = 0; l < lots; l++) atMostK.setCoefficient(y[l], 1);
objective.setMinimization();

Why it matters: a person can easily find the best lot for one day, but not the best split across a week. In the example week, one lot all week (Lot 209) scores 178 minutes. Two lots (Lot 446 on Monday, Wednesday and Friday, Lot 204 on Tuesday and Thursday) score 149 minutes, 16% less. The example uses the default settings, so its score is walking time plus traffic delay, with a few penalty minutes for lots likely to be full. With at most 7 × 110 binary variables, SCIP solves it in milliseconds, and the tests check its answer against brute force on 25 random weeks.

A traffic forecast trained with Smile

What it does: predicts how slow each road into campus will be on a given day and half hour, from the road's location, type and normal speed. It trains a random forest and a gradient-boosting model on our TomTom log and tests them against plain half-hour averages on the newest 20% of the readings, days the models never saw.

Why it matters: driving time depends on when you arrive, and a two-week log is too thin to average every road and half hour on its own. The models share what they learn across roads and times. The app uses whichever tests best and retrains each time it starts, so it improves as the log grows.

Park and ride from real bus times

What it does: finds the latest bus from Lot 500 that still gets you to your first class on time, the first one back after your last class, and compares the trip with driving to your best lot. Walking routes come from Dijkstra's algorithm on about 13,800 street and footpath nodes.

Why it matters: every permit can park at Lot 500, so for many students the bus is the real alternative to circling a full lot. For a 9:40 am class at the J.B. Hunt building, HillPark says to be parked by 9:09 and take the 9:12 Route 500 Express.

My part

I set up our shared repository and built the first working version on October 12 and 13, working with Claude, an AI assistant. I decided what the app should do, asked for each feature, tested it in the browser and pushed the changes. Building the traffic forecast in Smile and the week plan in OR-Tools was my call, so the app would use the tools from our course. The lot and traffic data comes from the parking project Damir and I built together.

HillPark is a student project, not an official University of Arkansas tool.