RoamBuffer

Turn unexpected travel downtime into a weather-aware U.S. mini-adventure—with a protected return-time buffer.

Comment

Inspiration

Travel does not always follow the itinerary. A delayed train, an early hotel arrival, or an unexpected hour between reservations can leave someone with enough time to explore—but not enough time to confidently decide where to go and still return on schedule.

I built RoamBuffer to answer one focused question: “What can I enjoy nearby without losing track of when I need to be back?”

What it does

RoamBuffer creates a realistic, time-boxed mini-itinerary from a traveler’s current starting point.

The traveler selects a U.S. location, available minutes or a required return time, walking pace, interests, indoor or outdoor preference, and a planning style. RoamBuffer combines weather context with nearby OpenStreetMap places and evaluates possible one-to-three-stop loops.

Every accepted plan includes the estimated walk to each stop, planned visit duration, estimated return walk, leave-by schedule, and a protected return buffer. The application explains why each stop was selected and how weather, movement preference, and plan style affected the result.

The three styles are Easygoing, Balanced, and Make the most of it. Easygoing prioritizes shorter estimated walking and additional buffer. Balanced uses the standard scoring model. Make the most of it favors variety and fuller use of the safe exploration window without consuming protected return time.

Users can save a plan locally, print or share it, and copy a URL containing normalized planner settings. No account is required, and the application does not maintain a server-side travel-history database.

This hackathon release limits discovery to U.S. locations. Seattle Pike Place Market and San Francisco Ferry Building include clearly labeled fixture fallbacks so judges can test the primary experience when a public provider is unavailable.

How I built it

The backend uses Python, FastAPI, Pydantic, HTTPX, and Uvicorn. The interface uses Jinja2, semantic HTML, custom CSS, and vanilla JavaScript. Leaflet renders the map with OpenStreetMap attribution.

Open-Meteo supplies U.S.-filtered geocoding and weather context. OpenStreetMap Overpass supplies nearby place data. The planner uses deterministic scoring rather than a runtime language model. It estimates walking time using Haversine distance with a conservative route multiplier, includes the complete return leg, and rejects every route that exceeds the safe exploration budget.

The project includes typed external-service adapters, caching, bounded retries, request pacing, fixture fallbacks, structured error states, a Progressive Web App shell, automated tests, browser tests, GitHub Actions, and Render deployment configuration.

Challenges

The main challenge was making useful recommendations without presenting uncertain public data as fact. Straight-line distance is not a pedestrian route, opening-hours data can be incomplete, and public providers can temporarily fail.

I addressed this by using conservative estimates, labeling unknown availability, displaying explicit disclaimers, including the return leg in every calculation, and identifying whenever fixture data is used.

Another challenge was safely restoring locations and preferences through browser storage and shared links. The application validates allowlisted settings, excludes returned place data from URLs, and rejects unsupported international selections.

Accomplishments

I am proud that the return buffer is a hard planning constraint rather than a suggestion. The planner remains deterministic, explainable, and testable across multiple travel styles.

The application also provides live U.S. location discovery, two resilient demonstrations, return-by planning, browser-local saving, shareable settings links, accessible controls, responsive layouts, and failure states without requiring a paid runtime API.

What I learned

Constraint-based planning was a better fit for this problem than unconstrained text generation. Time, distance, weather, pace, and return requirements need to be validated before an itinerary is shown.

I also learned that resilience and honest uncertainty are product features, especially for a travel application.

What’s next

Future work could add international coverage, localized units and time formats, multilingual interface copy, additional fixture-backed destinations, opt-in pedestrian routing, richer accessibility data, and live transit-disruption context.

Built With

Share this project:

Updates