logo
Home
Select your permit type
Fitler applied
List Tab
Search
Where should I park?
AI feature

Inspiration

Parking at Virginia Tech can be frustrating, especially when you’re already running late. You can drive all the way to a garage or lot, only to find out it’s basically full, or realize once you get there that your permit doesn’t even work.

That’s where the idea for HokiePark came from. We wanted to make something simple: before you drive across campus, you should be able to see where you can actually park and whether there’s likely to be space when you arrive.

What it does

HokiePark is a mobile-first parking map for Virginia Tech’s Blacksburg campus.

The map uses real building, parking lot, and garage data from Virginia Tech’s GIS system. Users can tap on a parking area to see information about it, including estimated availability, permit access, and ADA parking.

You can also choose your permit type, and the map will fade out lots you aren’t allowed to use. That was important to us because finding an open lot doesn’t help if parking there gets you a ticket.

We also added a Plan Ahead feature. Instead of only asking what parking looks like right now, you can ask something like, “Where should I park for a 2 PM class in Hancock Hall?” The app looks at the destination, permit type, and predicted parking demand around that time.

There’s also a simple text assistant for asking parking questions without having to search through the map manually.

The app runs with sample parking counts by default, but it can also connect to Supabase for live parking data if real sensor or garage count data becomes available.

How we built it

We built HokiePark in TypeScript and used MapLibre GL for the map, with OpenFreeMap providing the basemap.

Virginia Tech’s public GIS data gave us the actual shapes and locations of buildings, parking lots, and garages, so we didn’t have to manually recreate the campus.

The app is bundled with esbuild and compiles into a single dist/index.html file. It’s also a PWA, which means it can be installed on a phone and still load core parts of the app offline.

For parking predictions, we built a small pipeline in Databricks. We used Virginia Tech class schedule data to estimate how parking demand changes throughout the day. The data moves through bronze, silver, and gold stages, and an MLflow-tracked model predicts occupancy for each parking area by weekday and 15-minute time window.

For real-time data, we added optional Supabase support. The browser only has read access through row-level security, so users can’t modify parking counts from the client.

Challenges we ran into

One of our biggest problems was actually working on the same thing at the same time. Two of us ended up building separate versions of the permit eligibility system. Once we compared them, we kept the version that was based directly on Virginia Tech Parking Services information and rewrote our tests around that.

We also had problems with our parking demand model. At first, the predictions jumped up and down around class-change times. We eventually realized we were double-counting people leaving one class while other students were arriving for the next one.

Another issue was our test setup. Our browser tests were accidentally leaving full Chrome profiles behind after every run. Eventually they filled up the disk on the development machine, which was not how we expected to spend part of the hackathon.

Accomplishments that we're proud of

One thing we cared about was being clear about what data was real and what wasn’t.

The campus map and parking geometry come from Virginia Tech data. Our prediction pipeline actually ran in Databricks and was tracked with MLflow. At the same time, the current garage availability numbers in the demo are simulated unless a live Supabase feed is connected.

We’re also proud that the app isn’t usable only through the map. Buildings and parking lots can be reached with a keyboard and screen reader, so someone doesn’t have to rely on clicking small areas on a map.

We also tried not to guess when the data wasn’t clear. If we couldn’t verify the parking rules for a specific area, the app tells the user to check the posted sign instead of pretending we know the answer. Parking regulations can change, and giving someone bad information could mean a real ticket.

What we learned

The biggest lesson was probably to communicate before starting overlapping features. We lost time because multiple people were solving the same problem separately.

We also learned that parking data has several different sources of truth. A database might say one thing, a prediction model might say another, but the posted sign at the parking lot still wins. We ended up treating signage, live occupancy, and predicted occupancy as separate types of information instead of mixing them together.

We also learned that using simulated data isn’t necessarily a problem for a prototype. The important part is being upfront about it. We tried to clearly separate real VT GIS data, modeled predictions, and demo-only parking counts.

What's next for HokiePark

The next step would be getting HokiePark onto real HTTPS hosting so people can install and use it easily on their phones.

After that, the biggest improvement would be replacing simulated parking availability with real garage gate counts or sensor data. We’d also like to work with Virginia Tech to confirm permit rules for the few areas where the public information isn’t completely clear.

Longer term, we’d like to improve the assistant so it can handle more natural parking questions, and potentially turn HokiePark into a native mobile app.