Handling Multi-Jurisdiction Zoning Overlays in PostGIS

12 min read

This guide sits under Mapping Municipal Zoning Overlays to GIS Data, part of the Core Architecture & Code Taxonomy for Municipal Permits reference, and focuses on one hard case: storing and querying zoning overlays in PostGIS when a single parcel falls under several overlapping jurisdictions whose rules disagree.

Real parcels are rarely governed by one authority. A lot near a city edge can sit inside city zoning, an unincorporated-county overlay, a special flood-control district, and a state coastal boundary at once — each a separate polygon layer, each maintained by a different agency on a different schedule, and each potentially in a different spatial reference system. The task here is to model those overlapping regulatory geometries in PostGIS so that a spatial query returns every applicable overlay for a parcel, resolves the ones that conflict by a defensible priority order, and does so fast enough to run per-application at intake on a modest municipal database server. Get the SRID handling wrong and ST_Intersects silently returns nothing; get the priority logic wrong and two agencies claim jurisdiction over the same decision. The input is a parcel geometry plus a stack of jurisdiction overlay layers; the output is a deterministic, ranked list of overlays that the permit router and the multi-jurisdiction permit record can consume without ambiguity.

Multi-jurisdiction overlay resolution: common SRID → GiST-indexed ST_Intersects → priority rank Two PostGIS tables — parcels and jurisdiction_overlays — both store geometry in a single common SRID and each carry a GiST spatial index on the geometry column. A spatial query joins them with ST_Intersects; the query planner uses the GiST index to perform a fast bounding-box pre-filter before running the exact geometry predicate, which is what keeps the join tractable on a constrained server. The set of overlays matched to a parcel enters priority resolution, which orders them by a jurisdiction hierarchy of federal over state over county over city and uses ST_Overlaps to distinguish overlays that merely share a boundary from those that truly overlap. The output is a deterministic ranked overlay set handed to the permit router. GiST bbox scan matched set parcels geom (SRID 2229) GiST index jurisdiction_overlays geom (SRID 2229) jurisdiction_level GiST index ST_Intersects join GiST bbox pre-filter then exact predicate 1 Priority resolution federal > state > county > city ST_Overlaps vs shared edge 2 Ranked overlay set deterministic · per parcel Permit router multi-jurisdiction record

Precise Problem Framing

The defining characteristic of multi-jurisdiction overlay data is that it is genuinely many-to-many: one parcel touches many overlays, and one overlay covers many parcels, so the relationship must live in a spatial join rather than a foreign key. The compliance stake is that the set of overlays returned for a parcel must be complete and stable — a missing overlay means a mandated review is skipped, and a non-deterministic ordering means two clerks defend two different lead agencies for the same lot.

Two failure modes dominate. The first is silent SRID mismatch: PostGIS refuses to compare geometries in different spatial reference systems, and a query that joins a parcel stored in one SRID against overlays stored in another either errors or, worse, returns an empty set that looks like “no overlays apply.” The second is conflict without a rule: when a city historic overlay and a county flood overlay both bind a parcel, the schema must encode which agency’s decision leads, or the routing becomes a coin flip. This guide addresses both — first by making SRID an enforced invariant, then by encoding jurisdiction priority as data the query resolves deterministically.

Step 1 — Model Overlays with an Explicit, Enforced SRID

Store every geometry column in one common SRID chosen for the jurisdiction — typically the relevant State Plane zone so distance and area predicates are meaningful — and declare it in the column type so PostGIS rejects any insert in the wrong reference system at write time rather than failing mysteriously at query time. Carry the jurisdiction level and a numeric priority on the overlay table itself, so conflict resolution is a column lookup, not application code.

-- One common SRID (State Plane, EPSG:2229 here) enforced at the column level.
-- A geometry in any other SRID is rejected on INSERT, not silently mismatched.
CREATE TABLE jurisdiction_overlays (
    overlay_id      text PRIMARY KEY,
    jurisdiction    text        NOT NULL,   -- e.g. 'city_of_x', 'county_y'
    jurisdiction_level text     NOT NULL,   -- 'federal' | 'state' | 'county' | 'city'
    priority        smallint    NOT NULL,   -- lower = higher precedence
    severity        text        NOT NULL,   -- 'advisory' | 'standard' | 'blocking'
    effective_date  date        NOT NULL,
    geom            geometry(MultiPolygon, 2229) NOT NULL
);

CREATE TABLE parcels (
    parcel_id text PRIMARY KEY,
    geom      geometry(MultiPolygon, 2229) NOT NULL
);

Pinning the SRID in the column type (geometry(MultiPolygon, 2229)) turns a whole class of “why did my join return nothing” bugs into an immediate constraint violation at load time, which is exactly where a municipal data engineer wants to catch a mis-projected agency export.

Step 2 — Index with GiST and Query with ST_Intersects

Spatial joins are only tractable with a GiST index on each geometry column: the index lets the planner run a bounding-box pre-filter, so ST_Intersects evaluates the expensive exact-geometry predicate on a handful of candidates instead of the whole table. On a constrained municipal server this is the difference between a sub-second intake lookup and a query that scans the entire county fabric.

-- GiST is required for the planner to use ST_Intersects as an index condition.
CREATE INDEX parcels_geom_gix   ON parcels           USING GIST (geom);
CREATE INDEX overlays_geom_gix  ON jurisdiction_overlays USING GIST (geom);

-- Keep planner statistics current after bulk overlay loads.
ANALYZE jurisdiction_overlays;

-- Every overlay a parcel touches, already ordered by jurisdiction priority.
SELECT o.overlay_id, o.jurisdiction_level, o.priority, o.severity
FROM   parcels p
JOIN   jurisdiction_overlays o
       ON ST_Intersects(p.geom, o.geom)   -- GiST bbox pre-filter, then exact test
WHERE  p.parcel_id = %(parcel_id)s
ORDER  BY o.priority, o.overlay_id;        -- deterministic tie-break on overlay_id

Use ST_Intersects (not ST_Contains) for review-triggering overlays so a parcel that only clips an overlay boundary is still caught. When you must distinguish a real areal overlap from two polygons that merely share an edge — common where a city and county boundary run along the same street centerline — reach for ST_Overlaps, which is false for a shared boundary with no interior intersection, and reserve it for the priority step below.

Step 3 — Resolve Conflicts by Jurisdiction Priority

When several overlays bind one parcel, collapse them to a lead constraint using the priority column, while retaining the full set for parallel reviews. Because priority lives in the data, resolution is a stable sort, and the same inputs always yield the same lead agency — the determinism a compliance officer needs to defend the routing decision.

-- Lead overlay per parcel plus the retained full set for dual-agency routing.
WITH matched AS (
    SELECT o.overlay_id, o.jurisdiction_level, o.priority, o.severity,
           ST_Overlaps(p.geom, o.geom) AS true_overlap
    FROM   parcels p
    JOIN   jurisdiction_overlays o ON ST_Intersects(p.geom, o.geom)
    WHERE  p.parcel_id = %(parcel_id)s
)
SELECT
    (ARRAY_AGG(overlay_id ORDER BY priority, overlay_id))[1] AS lead_overlay,
    COUNT(*) FILTER (WHERE severity = 'blocking') > 1        AS requires_dual_review,
    ARRAY_AGG(overlay_id ORDER BY priority, overlay_id)      AS all_overlays
FROM matched;

The ORDER BY priority, overlay_id inside the aggregate is what makes the lead selection reproducible: priority decides precedence, and the overlay_id tie-break keeps two same-priority overlays from swapping lead position between runs. Retaining all_overlays means a parcel bound by both a state coastal overlay and a county flood overlay is flagged for dual-agency review rather than having one silently dropped.

Step 4 — Query from Python with psycopg and GeoAlchemy

Application code should treat the resolved overlay set as a typed result, not raw tuples. Use psycopg 3 with a row factory for direct queries, and reserve GeoAlchemy 2 for when overlays are part of a larger ORM model. Always pass the parcel ID as a bound parameter — never string-format it into SQL — and keep the connection pooled so per-application intake lookups do not pay connection setup on a busy server.

from __future__ import annotations

import psycopg
from psycopg.rows import dict_row

RESOLVE_SQL = """
    WITH matched AS (
        SELECT o.overlay_id, o.priority, o.severity
        FROM   parcels p
        JOIN   jurisdiction_overlays o ON ST_Intersects(p.geom, o.geom)
        WHERE  p.parcel_id = %(parcel_id)s
    )
    SELECT (ARRAY_AGG(overlay_id ORDER BY priority, overlay_id))[1] AS lead_overlay,
           ARRAY_AGG(overlay_id ORDER BY priority, overlay_id)      AS all_overlays,
           COUNT(*) FILTER (WHERE severity = 'blocking') > 1        AS dual_review
    FROM matched;
"""


def resolve_overlays(conn: psycopg.Connection, parcel_id: str) -> dict:
    """Return the lead overlay and full ordered set for one parcel.

    Uses a bound parameter (never string interpolation) and a dict row factory
    so the caller gets named fields ready for the compliance payload.
    """
    with conn.cursor(row_factory=dict_row) as cur:
        cur.execute(RESOLVE_SQL, {"parcel_id": parcel_id})
        row = cur.fetchone()
    # A parcel touching no overlay yields NULLs — normalize to an explicit empty.
    if row is None or row["lead_overlay"] is None:
        return {"parcel_id": parcel_id, "lead_overlay": None,
                "all_overlays": [], "dual_review": False}
    return {"parcel_id": parcel_id, **row}

For GeoAlchemy 2 users, declare the geometry column with Geometry("MULTIPOLYGON", srid=2229) so the ORM emits the same SRID-typed column, and wrap the intersects predicate with func.ST_Intersects(...) — the underlying GiST index still applies, so the ORM path is no slower than raw SQL. The resulting overlay set maps cleanly onto the structure described in how to structure permit application JSON for multi-jurisdiction use, which defines how the per-jurisdiction sections of a permit record are keyed.

Parameter and Configuration Reference

Parameter Type Default Municipal-context notes
geometry column SRID int 2229 Pin to the jurisdiction’s State Plane zone; enforced in the column type so wrong-SRID inserts fail immediately.
index type — GIST Required for ST_Intersects to use an index; a B-tree does nothing for geometry.
jurisdiction_level text — Drives the priority hierarchy; constrain to the known enum to prevent typos ranking as unknown.
priority smallint — Lower wins; keep federal/state/county/city gaps wide (10/20/30/40) for future insertions.
join predicate — ST_Intersects Review-triggering overlays; use ST_Contains only for whole-parcel constraints.
ST_Overlaps use — conflict step Distinguishes true areal overlap from a shared boundary edge.
work_mem size 64MB Raise per-session for large multi-overlay joins on constrained servers; avoid a global bump.
pool size int 4–8 Small pool; intake lookups are short, and a municipal DB host has limited connections.

Common Failure Patterns and Fixes

ST_Intersects returns nothing because of an SRID mismatch

If overlays were loaded in EPSG:4326 while parcels are in 2229, the join returns empty or raises. Enforce the SRID in the column type as in Step 1, and when ingesting an agency export in another CRS, ST_Transform it to the common SRID on load — never at query time, which defeats the index.

Sequential scan instead of the GiST index

A join that ignores the index usually means stale statistics or a wrapped geometry column. Run ANALYZE after bulk loads, keep the predicate as ST_Intersects(p.geom, o.geom) with no function wrapping o.geom, and confirm with EXPLAIN that the index condition appears.

Non-deterministic lead agency between runs

Aggregating overlays without a total ordering lets two same-priority overlays swap lead position. Always sort by priority and a stable tie-break like overlay_id, so the lead constraint is reproducible for audit.

Shared boundaries counted as overlaps

Two jurisdictions whose borders run along the same street centerline ST_Intersects on that shared edge, inflating the overlay set. Use ST_Overlaps (false for a boundary-only touch) when the compliance question is whether the parcel truly falls inside both areas.

Slivers from imprecise agency geometries

Millimetre-scale gaps and overlaps from different survey vintages create spurious matches or misses near boundaries. Snap agency layers to a shared grid with ST_SnapToGrid on load and repair invalid rings before indexing, mirroring the normalization the parent overlay-mapping component applies upstream.

Audit and Logging Guidance

Because the overlay set drives which agencies review a permit, log the resolved result as a compliance artifact: the parcel ID, the lead overlay, the full ordered overlay list, the dual_review flag, and the effective_date of each overlay version that participated. Capture the query’s execution against a specific overlay-layer version so an auditor can reconstruct which boundaries were authoritative on the filing date — overlay geometries change through council action, and a resolution must be reproducible against the fabric that existed when it ran. Log SRID-mismatch rejections and any parcel that resolves to dual_review at a level your GIS and compliance teams monitor, since a rising dual-review rate can signal an agency republishing boundaries that now overlap where they previously abutted. Retain these records for the state-mandated period, and periodically re-run resolution for in-flight permits so a mid-review boundary change surfaces as an alert rather than a surprise at inspection.

Frequently Asked Questions

Why store all overlays in one SRID instead of transforming at query time?

Transforming geometry inside the join (ST_Transform(o.geom, 2229)) wraps the indexed column in a function, so the planner can no longer use the GiST index and falls back to a full scan. Storing everything in one enforced SRID keeps every predicate index-eligible and eliminates the mismatch failure mode entirely — transform once on ingest, never per query.

How do I choose between ST_Intersects, ST_Overlaps, and ST_Contains?

Use ST_Intersects for any overlay meant to trigger a review, because partial overlap still pulls the parcel into scope. Use ST_Contains only when the constraint must apply to the whole parcel, such as a buffer that must fully enclose it. Reserve ST_Overlaps for the conflict step, where you need to tell a genuine areal overlap from two areas that merely share a boundary line.

Will this perform on a small municipal database server?

Yes, if the GiST indexes exist and statistics are current: the bounding-box pre-filter reduces exact-geometry tests to a handful per parcel, so per-application intake stays sub-second even county-wide. Keep a small connection pool, raise work_mem per session only for large batch resolutions, and run bulk county-wide re-resolution as an overnight job rather than blocking intake.

Related in this area

Related Best Practices for Linking Zoning Codes to Parcel IDs Related Validating Parcel IDs Against County GIS APIs