• 

  This is the intent , session creation interface

• 

  This is the user interface showing FSU bus stops

Last Mile Connect

Safety-first last-mile walking companion for the Florida State Univeristy area. Get off the bus, set your destination, find someone going the same way, and walk together with turn-by-turn directions from the stop.

---

Inspiration

The last mile—the walk from the bus stop to your dorm, class, or office—is where many people feel least safe or unsure of the route, especially after dark.

We wanted to make that segment safer and clearer:

• Match people heading the same way
  
• Create time-bound walking sessions (not permanent connections)
  
• Show turn-by-turn walking directions from the bus stop
  

So no one has to guess the route or walk alone if they don’t want to.

---

What It Does

Set Origin & Destination

• Use “Use my location” or pick an FSU bus stop
  
• Click the map to set your destination
  
• Reverse-geocodes to a readable address
  
• If origin is a bus stop → shows walking directions (distance, time, step-by-step route)
  

---

Create Intent

• One active intent per user
  
• Origin & destination stored as geographic points
  
• Automatically expires in ~60 minutes
  

---

Find Matches

• Backend finds other intents within ~2 km
  
• Optionally prioritizes same bus stop
  
• Ranked by buddy score:
  • Route overlap
    
  • Past ratings
    
• Vehicle users match only with walkers
  
• Walkers see both
  

---

Create Session

1. Pick a match
   
2. Create a session linking both intents
   

Status visibility:

• You requested → You initiated
  
• Incoming request → Other user initiated
  
• Accept → Either user can Activate
  

---

Walk Together

When the session is ACTIVE:

• Both users’ locations sent via WebSocket
  
• Stored in Redis
  
• Map shows live:
  • You marker
    
  • Peer marker
    
• Optional SOS
  
• Auto-complete when time limit is reached
  

---

How We Built It

Backend

• FastAPI
  
• PostgreSQL + PostGIS
  
  • ST_DWithin for 2 km proximity
    
  • Same-stop detection
    
• Redis (live locations with TTL)
  
• JWT authentication
  
• WebSockets:
  • Session updates channel
    
  • Per-session live location stream
    

---

Frontend

• Leaflet
  
• OpenStreetMap tiles
  
• Stops from GTFS-style data:
  • stops.txt → fsu_stops.json
    
  • GET /api/stops
    
• Nominatim → Reverse geocoding
  
• OSRM → Walking routes from bus stop to destination
  

---

Matching Logic

• Route-overlap score
  
• Optional same-stop merge
  
• Buddy score = weighted combination:
  • Route overlap
    
  • Past ratings
    

Session State Machine:

1. REQUESTED
   
2. ACCEPTED
   
3. ACTIVE
   
4. COMPLETED / ABORTED
   

---

Challenges We Ran Into

Clarity for the Other User

Initially the recipient only saw:

Session #X

We improved clarity by adding:

• You requested
  
• Incoming request
  

So it’s obvious who initiated and who should accept.

---

Single Source of Truth for Stops

Problem:

• Hardcoded demo stops
  
• Backend stops
  

Solution:

• Backend (fsu_stops.json from GTFS) as the primary source
  
• Hardcoded list used only as fallback when the API fails
  

---

Keeping Both Sides in Sync

Accept, Activate, and live markers had to stay consistent across two browsers.

Solution:

• WebSocket pushes for session/intent updates
  
• Dedicated WebSocket + Redis + polling flow for live locations
  

---

What We Learned

• Use PostGIS for proximity and same-stop matching instead of doing distance math in app code
  
• Design a small session state machine for multi-user flows
  
• Use Redis with TTL for ephemeral live location data
  
• Use PostgreSQL for persistent sessions and intents
  
• Integrate OSRM (walking routes) + Nominatim (reverse geocoding) to keep the UI human-readable and actionable
  

Built With

• fastapi
• leaflet.js
• mapquest-nominatim-search
• osm
• osrm
• postgis
• postgresql
• redis
• websockets