Relay

Inspiration

Utilities publish future transmission projects years in advance, but neighboring utilities often plan independently.

That creates a simple problem: two utilities can have major projects happening only a few miles apart at nearly the same time without an easy way to spot opportunities to coordinate.

Relay was built around one question:

What if utilities could see where their future construction plans overlap before the digging starts?

What it does

Relay compares public transmission construction plans from multiple utilities and flags projects that are geographically close, scheduled around the same time, or both.

We started with Dominion Energy South Carolina and Georgia Power.

Relay shows:

Project locations on a map
Distance between nearby projects
Construction timelines
Utility and project details
Potential coordination opportunities

How we built it

1. PDF parsing

We used Python and pdfplumber to extract structured project data from DESC's 44 project sheets and Georgia Power planning documents.

2. OSM substation matching

We used OpenStreetMap and the Overpass API to match project endpoints and substations to real geographic coordinates.

3. Full located dataset

We combined the cleaned project data with latitude, longitude, dates, utility information, and source data into one normalized dataset.

4. Database + PostGIS

We loaded the project data into PostgreSQL with PostGIS, giving Relay the ability to run geographic queries and distance calculations.

5. Overlap engine

Relay compares projects from different utilities using geographic distance and schedule overlap.

We use a 25-mile project-center gate to identify potential cross-utility matches.

6. Snowflake Cortex

We use Snowflake Cortex to generate a short explanation of why a project pair may represent a coordination or resource-sharing opportunity.

Challenges we ran into

PDFs, not tables. Utility PDFs look structured to humans but are messy to parse. Names can wrap, break across lines, or appear differently between summary tables and project sheets.

Names are not locations. A name like "Goshen" can match multiple substations, so we use nearby project endpoints and geography to choose the most reasonable location.

Incomplete OSM data. Some substations have missing names or operator tags, so a few edge cases required additional validation or manually verified locations.

Centers vs. lines. Transmission projects can span miles. We kept the 25-mile project-center gate because it reproduces the challenge reference data, while using geographic calculations for deeper comparisons.

Accomplishments that we're proud of

We're proud that Relay is more than a dashboard built on a manually prepared spreadsheet.

We built the full pipeline:

PDFs → structured data → geographic matching → PostGIS → overlap detection → map visualization → AI-assisted insights

We also successfully processed DESC's 44 project sheets and reproduced the challenge's reference overlap behavior.

What we learned

The biggest lesson was that the hardest part is not calculating distance — it's getting trustworthy data.

We learned a lot about:

PDF parsing
Data normalization
OpenStreetMap and Overpass
Geographic matching
PostgreSQL and PostGIS
Spatial queries
Snowflake Cortex
Handling ambiguous real-world infrastructure data

We also learned that good automation still needs validation. Sometimes rejecting a bad match is more valuable than forcing an answer.

What's next for Relay

Next, we want to expand Relay beyond two utilities and make the ingestion pipeline more automated.

Future improvements include:

More utility datasets
Better line geometry
Match confidence scores
Timeline visualization
Filtering by distance, year, and utility
Alerts when new overlaps appear
More detailed resource-sharing and savings analysis

Long-term, Relay could become a shared planning layer that helps utilities coordinate future infrastructure work before crews and equipment are already in the field.