Wrap | Devpost

Inspiration

NYC publishes street closures for parades, fairs, block parties, and construction, often well before they happen. But a permit is hard to use when its location is a sentence buried in a city feed. The cost becomes clear when a closure pushes everyone toward the same few detours.

We built Wrap to turn those schedules into a map people can use before they leave and a route they can adjust when plans change.

What it does

Search an address or place, see mapped disruptions, and compare routes around them. An hourly timeline shows scheduled closures over the next seven days. A separate forecast uses recurring events to show possible closures farther ahead, clearly marked as predictions.

Wrap also supports a trip check-in: if a bus has not arrived, it compares the available options and recommends switching or continuing to wait. Scheduled closures are never presented as confirmation that a sidewalk is blocked.

How we built it

Wrap is a mobile-first PWA built with Next.js, TypeScript, Tailwind CSS, and MapLibre. Server-side handlers combine NYC’s mapped event and construction layers with permitted-event records. A street-centerline index turns text such as “5 AVENUE between EAST 42 STREET and EAST 59 STREET” into map geometry.

OpenRouteService handles destination search and walking and driving routes. Transit planning uses OpenTripPlanner, with MTA data available when configured. Route checks and stay-versus-switch decisions are deterministic. An optional model summarizes event details; it does not decide where a closure is or whether a route is clear.

For the forecast, we analyze permitted-event history from 2013 onward, group recurring events, and extract calendar rules. No model training is involved.

Challenges we ran into

Permits describe locations in text. Street names vary across datasets, and matching the right street is only the first step. We also have to identify the exact blocks between the named intersections.

Wrong geometry can look convincing. Checking only street vertices missed mid-block crossings, including diagonal streets. Using a segment’s middle array element as its midpoint could extend a closure into the next block. Both bugs produced believable maps, which made them harder to catch.

Accomplishments that we’re proud of

Wrap resolves closures at the block level, including diagonal intersections and similarly named streets in different neighborhoods. Records we cannot place confidently are counted as unmapped and kept out of route avoidance.

The forecast can recognize patterns such as “fourth Thursday in November” and decline to predict events whose dates are inconsistent. The demo also runs reliably without pretending its scripted event, bus delay, or route switch is live data.

What we learned

The most valuable work was making public data dependable. A plausible but misplaced closure can be worse than a missing one.

Calendar rules beat a generative model for forecasting recurring events: they are faster to check, easier to explain, and cannot invent a parade. We use AI only where an explanation helps, while keeping the underlying facts and route decisions grounded in data.

What’s next for Wrap

We want to strengthen coverage and verification across all five boroughs, notify people before a saved address is affected, and show how closures change bus service and nearby traffic. We also want clearer answers to “which nearby street should I use?”

Another next step is deployment. While we would've loved to deploy Wrap right now, we still need to find a VPS service to deploy our router on.

Wrap’s current closure data is scheduled, not a complete picture of conditions on the ground. An emergency closure or a bus delay that has not reached its data source may still be missing.