Inspiration

Georgia Power and Dominion Energy South Carolina each publish their own planned transmission projects, but neither utility can easily see the other's plans. Projects that are physically close, or scheduled around the same time, are natural opportunities to share right-of-way, coordinate outages, or split land and construction costs — but without a shared view, those overlaps go unnoticed. The Sperry Tech "Gridlock" challenge asked for exactly that missing view.

What it does

  • Turns both utilities' public planning reports into one clean, unified dataset of projects.
  • Geocodes every project to a real location in Georgia or South Carolina and, where possible, routes it along the actual power line rather than a straight guess.
  • Finds and ranks coordination opportunities by how close two projects actually come to each other, how much their build windows overlap, and whether their voltages match.
  • Shows it all on an interactive map with filters, a ranked opportunity list, and a camera that flies you to each match.
  • For any selected opportunity, estimates the land and cost savings from sharing a right-of-way instead of building separately.
  • Lets a utility submit a new or updated project — by uploading a PDF report or filling a short form — and see it flow straight into the map.

How we built it

  • A Python pipeline parses both utilities' report formats, merges them into one contract-shaped table, and geocodes each project against OpenStreetMap substations and power lines.
  • An overlap engine scores and ranks every cross-utility pair, with a confidence score so shaky location guesses never outrank solid ones.
  • A FastAPI backend serves the ranked data and a cost/impact estimate; SQLite holds the processed results.
  • A Mapbox-powered frontend renders the map, the ranked list, and a submission dialog for adding new projects.
  • We split the work by area at first (parsing, geocoding, app) and converged to work across the whole stack as the project came together.

Challenges we ran into

  • The source reports turned out to be real, messy PDFs — inconsistent formatting, typos, abbreviated substation names — not the clean text we'd been told to expect.
  • OpenStreetMap doesn't name every substation, so matching a project's endpoints to a real location needed several fallback strategies.
  • Getting "how close are these two projects" right meant measuring the closest point between their actual routes, not just comparing project centers, or real overlaps got missed.
  • Merging in a teammate's login page mid-build, after it had restructured which file held the map app, took careful conflict resolution rather than a simple merge.

Accomplishments that we're proud of

  • A fully automated pipeline from raw utility PDFs to a ranked, mapped list of coordination opportunities.
  • Real geocoding and routing along actual power lines instead of straight-line guesses.
  • A working, adjustable cost and land-savings estimate for the bonus round.
  • Utilities can submit or update their own projects and see the effect on the map immediately.

What we learned

  • Real-world utility data is messier than any spec, so defensive parsing and validation pay off immediately.
  • A confidence score matters as much as the match itself — showing uncertainty honestly avoids claiming a coordination opportunity that isn't real.
  • Restructuring shared files mid-project (like splitting one page into a login page and a map page) needs deliberate merge handling, not a blind "keep both."

Built With

Share this project:

Updates

Submission history