A Bounding Box Is Not California

The geographic promise

Earthquake Watch covers notable earthquakes in California. That sentence creates a data requirement: an event outside California must never become an editorial candidate.

The source is the United States Geological Survey FDSN Event Web Service. It is authoritative, documented, and available without a private API key. Its geographic query accepts minimum and maximum latitude and longitude values. Those values define a rectangle.

California is not a rectangle. Any practical rectangle around the state also covers parts of Nevada, Oregon, Arizona, and Baja California. A source query can therefore be valid while the publication result is wrong.

Collection and geographic validation

The source adapter queries a rectangle large enough to cover California. Every returned event then passes through a second geographic test against a California polygon stored with the project.

The sequence matters:

1. Query the official event service for the required time range and broad geographic bounds.
2. Parse each source event and preserve its United States Geological Survey identifier and source URL.
3. Test the event coordinates against the California polygon.
4. Drop events outside the polygon before scoring or drafting.
5. Score only the records that satisfy the publication’s actual geographic promise.

The polygon test turns “California-only” from editorial guidance into executable behavior. A Nevada earthquake cannot accidentally become a California story because it never enters the candidate set.

Scoring after scope

Geographic acceptance and editorial significance are different decisions. Earthquake Watch handles them in that order.

An accepted California event enters scoring at magnitude 3.0 or above. Shallow events under ten kilometers receive additional weight because they can be felt more strongly near the surface. Events at magnitude 5.0 or above receive a further increase. Retracted source events are spiked instead of being left in the publication as stale reports.

These thresholds identify candidates. They do not manufacture significance. Each published report still attaches the source event, magnitude, depth, nearby population context, and relevant geographic explanation.

Why this pattern matters

Bounding boxes are common because source systems can evaluate them quickly. Product scope usually follows political boundaries, service areas, watersheds, parcels, districts, coastlines, or other shapes that a rectangle approximates poorly.

The reusable pattern is straightforward:

• Use a broad source query to collect a complete candidate set.
• Apply the real boundary inside the application.
• Reject out-of-scope records before ranking, summarization, or publication.
• Preserve the source coordinates and the boundary version so the decision can be reproduced.

This is a small architecture decision with a large trust effect. The publication can state its scope plainly because the pipeline has a mechanism that enforces it.

The system around the filter

The geographic filter sits inside a Python 3.12 pipeline managed with uv. SQLite stores source and publication records. Jinja2 renders a static site, and a Cloudflare Worker serves the output.

The static public site does not need to know how to run a polygon test. The build pipeline owns collection, geographic validation, scoring, records, and rendering. That separation keeps the deployed surface simple while preserving a repeatable path from official event to published report.

Explore the Earthquake Watch case study or open the live publication.