Param GunturuSenior Full-Stack Engineer

Project 02 / 05 · PG&E · 2020–2021

The wildfire safety map customers open before the winds come up

In California, wildfire risk isn't abstract — for customers living in the wildland-urban interface, it's whether their house has power tomorrow. The Community Wildfire Safety Map is the consumer-facing portal customers open before fire season to look up an address or county and see, in plain language, what the utility has planned for it: where lines are being hardened, where wires are going underground, where animal guards and sectionalizing devices have been installed, and the likelihood of a Public Safety Power Shutoff this season. Built in React with D3 driving the overlays on top of the ESRI Maps SDK base, styled in Tailwind directly against the Figma design system, and translated component-by-component without a CSS-modules intermediate so the design system stays the contract.

View live site
Role
React Engineer
Dates
Dec 2020 – Aug 2021
Location
San Francisco, CA
Domain
Consumer / safety transparency
  • React
  • D3.js
  • ESRI Maps SDK
  • Tailwind CSS
  • Figma
At a glance
Customers reached
5.5M

Public consumer map open to every utility customer in the California service area.

Map stack
React · D3 · ESRI

React for the application shell; D3 driving overlays; ESRI Maps SDK for the basemap, projection and GIS primitives.

Categories
Four

Switchable mitigation overlays: line undergrounding, hazard prevention, outage-size reduction, enhanced detection.

Design handoff
Figma → Tailwind

Design tokens and component variants mapped 1:1 from Figma to code — no intermediate CSS-modules layer.

The interface

Illustrative recreation

View live site ↗

An interactive recreation of the public map — fictional counties, illustrative project data, real UI behavior. Search by address or county, switch the category, open a county to see what's planned. The live production site is linked above.

pge.com/wildfire-safety-map
Open full screen ↗

React + D3 over an ESRI Maps SDK base

County polygons, service-area outlines, high-fire-threat-district overlays and category-switchable project layers all render from a single D3 data layer over the ESRI base.

Address → county → detail

An address resolves to its county and PSPS-likelihood detail; opening a county pulls up completed mitigation work, circuit status and customer impact in plain language.

Figma to Tailwind, end to end

Every panel, popup, legend and modal was styled in Tailwind directly against the Figma handoff — one design system across the whole surface customers see.

Recreation · faithful to the original UI behavior, not the shipped source.

The problem

A safety tool customers can actually open

Public Safety Power Shutoffs only work as a wildfire-prevention tool if the customers on the receiving end know what's happening, where, and why. The utility had committed publicly to that level of transparency — community-by-community mitigation work, undergrounding plans, sectionalization device installations, the likelihood of a shutoff for any given address — but the existing portal was an aging surface customers had a hard time navigating.

The Community Wildfire Safety Map is the consumer portal that fixed that. A homeowner opens the page, types an address (or picks a county directly), and gets a real answer about their own area before fire season: completed and forecast mitigation work by category, a multi-year PSPS history table, a cities-in-this-county listing, and total mileage of upgrades by type. No phone tree, no PDF download, no “contact your utility representative.”

The PSPS playbook only works if the customers on the other end of it know what's happening, where, and why.
— The motivating constraint

Key decisions

Four choices that defined the build

The map is the visible product, but the lookup flows are how customers actually use it, and the design system is what keeps the whole surface coherent across phone, tablet and desktop. Four decisions did the load-bearing work.

01Decision

React for the shell, D3 for overlays, ESRI for the basemap

Each rendering layer does the work it's best at. ESRI Maps SDK owns the basemap — tiles, projection, GIS primitives, the underlying geographic accuracy. D3 owns everything on top — county polygons, project markers, hazard zones, category-switchable mitigation overlays — because the work there is data-driven (hundreds of features by category, restyling on interaction, animating between states). React owns the surrounding application surface: the controls (search, filters, dropdown), the modal, the routing.

The catch· Three rendering technologies to coordinate (DOM, SVG-via-D3, ESRI canvas). In exchange, each is doing what it's optimized for, and adding an interactive overlay doesn't fight the basemap's rendering.

02Decision

A single declarative data layer driving every category

County polygons, service-area outlines, high-fire-threat-district overlays, and every category-switchable project layer all read from one D3 data layer. Switching from undergrounding to hazard prevention to outage-size reduction is a single state change — no re-render of the base, no separate render path per category, no copy-pasted overlay logic that drifts over time.

The catch· More upfront data shaping to fit every category into a unified shape. In exchange, adding a new mitigation category later is one declarative entry, not a new render path.

03Decision

Address and county both converge on the same detail surface

Two lookup paths — type an address, or click a county directly — converge on one detail modal. PSPS likelihood, cities in the county, completed mitigation work, planned upgrades by category and mileage, all sourced from the same data payload regardless of entry point. Customers don't relearn navigation when they switch from address-based to area-based lookup.

The catch· The modal carries more data and has to load gracefully across both entry points. In exchange, the cognitive load on the customer is roughly one menu, not two.

04Decision

Figma → Tailwind, no intermediate design layer

Every panel, popup, legend, dropdown and the county modal are styled in Tailwind directly against the Figma handoff. Design tokens (colors, spacing, type) translate 1:1; component variants live in code mapped 1:1 to design system entries. No CSS-modules layer in between, no generic component library to bend toward the design — direct translation, design system as the API.

The catch· Tighter coupling between code and the design source. In exchange, design system changes can't silently drift away from what ships — a Figma update is a code update.

What I built

The map, the lookups, and the county detail

The map layer is React for the application shell with D3 driving every overlay on top of the ESRI Maps SDK basemap. D3 handles county polygons, service-area outlines, high-fire-threat-district overlays, and the category-switchable mitigation markers (undergrounding, hazard prevention, outage-size reduction, enhanced detection) — all rendering off a single declarative data layer so adding a new category later is a data entry, not a new render path.

The two lookup flows — typing an address, or clicking a county directly — are what turn the visualization into a tool. Both converge on the same detail modal: PSPS likelihood, a multi-year shutoff history table, cities in the county, completed and forecast mitigation work by category, total upgrade mileage by type. Customers don't relearn navigation when they switch from address-based to area-based lookup.

The map controls, the category dropdown with its swatch legend, the popup cards on individual project markers, and the full county detail modal all live in the same Figma design system. I held that line in Tailwind so the surface reads consistently end to end, with WCAG 2.1 keyboard and screen-reader support for the broad public audience the map serves.

Project 03 / 05 · Next

Spirit Airlines — booking funnel rebuild

→