How Does a Spatial Join Work?

A spatial join matches features according to where they are in relation to one another, then transfers or summarises information from those matches.

Instead of asking whether two records share the same ID or name, a spatial join can ask questions such as:

Which district contains this school?
Which roads intersect this flood zone?
Which health facilities are within 5 kilometres of this settlement?
What is the nearest weather station to each farm?

The geography becomes the join condition.

A simple example is joining school points to administrative polygons. For each school, the operation identifies the district that contains it and attaches information from that district—perhaps its name or administrative code—to the school record.

That basic idea is straightforward. The details become important when one feature matches several others, lies exactly on a boundary, uses the wrong spatial relationship, or belongs to data whose geometries or coordinate reference systems are problematic.

A normal join matches values; a spatial join matches geometries

Suppose you have two tables.

The first contains schools:

school_id: 101; school_name: School A; district_code: D04
school_id: 102; school_name: School B; district_code: D07

The second contains districts:

district_code: D04; district_name: District North
district_code: D07; district_name: District South

An ordinary attribute join can use:

school.district_code = district.district_code

The records match because their field values correspond.

Now imagine the school dataset has no district code, but it does have a point geometry. The district dataset contains polygons.

A spatial join can instead ask:

Which district polygon contains each school point?

The match comes from the relationship between the geometries.

That is the central difference.

Spatial Join vs Attribute Join will examine when each method is preferable. A spatial join is not automatically better merely because the records contain geographic data: if both datasets already contain reliable common identifiers, an attribute join may be simpler and more deterministic.

A spatial join has several moving parts

A useful way to understand the operation is:

features to keep
      +
features to compare against
      +
spatial relationship
      +
rule for multiple matches
      =
spatially joined result

Different GIS applications use different terminology, but the concepts are broadly the same.

You need to know:

Which features define the output records?
Which other features are being searched for matches?
What geographic relationship counts as a match?
What should happen when there are zero, one, or several matches?
Which attributes should be transferred or summarised?

Most unexpected spatial-join results can be traced back to one of those choices.

The target layer determines what you are asking about

Imagine two layers:

Schools

1,000 points

Districts

50 polygons

If the question is:

Which district is each school in?

then schools are the features you want to preserve as the main output records.

Conceptually:

For every school
    find the district that contains it

The result might look like:

school: School A; district: District 4
school: School B; district: District 4
school: School C; district: District 7

But reverse the question:

Which schools are located in each district?

and the structure of the problem changes.

Conceptually:

For every district
    find the schools inside it

You may now want a count:

district: District 4; school_count: 2
district: District 7; school_count: 1

or perhaps a one-to-many table in which each district-school relationship becomes a record.

The same two geographic layers can therefore produce very different results depending on which layer defines the records being joined.

This is why join direction is not merely a software-interface detail. It expresses the question being asked.

The spatial relationship determines what counts as a match

The next choice is the spatial predicate or relationship.

Common examples include:

intersects
within
contains
touches
overlaps
crosses
nearest
within a specified distance

These relationships describe different geometric conditions.

Suppose a school point lies clearly inside a district polygon.

Then you might reasonably describe:

school WITHIN district

From the opposite perspective:

district CONTAINS school

Those two expressions look at a related relationship from opposite directions.

INTERSECTS is broader. Two geometries intersect when they share any point in space, subject to the precise geometry model used by the software.

For a point well inside a polygon, several predicates may therefore appear to give the same answer.

The difference becomes visible around edges and more complicated geometries.

Boundary points are a classic example

Imagine a point located exactly on the border between two district polygons.

Visually:

District A     |     District B
               |
               ● School
               |

Which district is the school “within”?

That seemingly obvious question exposes an important difference between ordinary language and formal spatial relationships.

Under the usual Simple Features geometry model, the boundary of a polygon is not part of its interior. A point lying exactly on that boundary can therefore intersect the polygon without being strictly within it.

Depending on the geometry and predicate, it may also match both neighbouring polygons under a broader relationship.

That means changing:

WITHIN

to:

INTERSECTS

is not merely changing syntax.

It changes what qualifies as a spatial match.

Within vs Contains vs Intersects will treat these predicate semantics and boundary cases in detail.

One feature can legitimately match several others

Many people first encounter spatial joins through point-in-polygon examples:

one school → one district

That creates the impression that every spatial join should produce one match per feature.

It does not.

Suppose a road crosses three protected areas:

Road 17 → Protected Area A
Road 17 → Protected Area B
Road 17 → Protected Area C

All three relationships can be geographically valid.

Likewise, overlapping polygon datasets can cause a point to intersect more than one polygon.

A spatial join therefore has to decide what to do with multiple matches.

Some workflows preserve them as separate records:

road: Road 17; protected_area: Area A
road: Road 17; protected_area: Area B
road: Road 17; protected_area: Area C

That is a one-to-many result.

Other workflows need one output record per original road and therefore have to aggregate, count, concatenate, select, or otherwise resolve the matches.

One-to-One vs One-to-Many Spatial Joins will explore that distinction separately.

The important lesson here is:

multiple output records are not automatically duplicates or errors.

They may represent multiple real spatial relationships.

What information actually gets joined?

A spatial join does not usually mean combining every field from both datasets indiscriminately.

Suppose schools have:

school_id
school_name
student_count
geometry

and districts have:

district_code
district_name
population
area_km2
geometry

The output might retain the school geometry and add only:

district_code
district_name

Giving:

school_id
school_name
student_count
district_code
district_name
geometry

That is often enough to answer:

Which district is each school in?

There may be little reason to duplicate every district attribute into every school record.

This matters particularly with large datasets. Joining unnecessary attributes increases data volume and can make downstream schemas harder to understand.

The output should preserve the information needed for the next operation, not simply everything the software can copy.

Spatial joins can also aggregate information

Sometimes the goal is not to attach the identity of matching features but to summarise them.

For example:

How many health facilities fall within each district?

The conceptual operation is still spatial matching:

district ← facilities that fall within it

But instead of storing every facility record, the result can calculate:

facility_count

Similarly, you might compute:

total population of matching points or zones;
average value among nearby observations;
minimum or maximum attribute;
count of intersecting features;
sum of a numeric field.

This is one reason a spatial join can be more than “adding columns based on location”.

It can also turn geographic relationships into summary attributes.

A spatial join is not the same as an overlay

This distinction becomes especially useful once you start working with polygon operations.

Suppose a district polygon overlaps a flood-zone polygon.

A spatial join might answer:

Which flood zones intersect this district?

and attach information about the matching zones to the district.

It does not necessarily create a new geometry representing only the overlapping area.

An overlay operation such as intersection can do that:

district geometry
       ∩
flood-zone geometry
       =
new overlap geometry

That is a different output.

The broad distinction is:

Spatial join: establish relationships and transfer or aggregate attributes according to geography.

Overlay: construct new geometries from geometric relationships.

There are tools and workflows where the boundary between those ideas becomes more nuanced, but this distinction is a useful starting point.

A later Spatial Join vs Overlay article can own the detailed comparison rather than turning this pillar into an overlay guide.

Nearest-feature joins use distance rather than topological containment

Not every spatial join asks whether features overlap.

Suppose you have villages and hospitals and want to attach the nearest hospital to each village.

Conceptually:

For every village:
    find the hospital with the smallest distance

The relationship is now based on proximity.

A result might contain:

village: Village A; nearest_hospital: Hospital 3; distance_km: 4.2
village: Village B; nearest_hospital: Hospital 8; distance_km: 11.6

That is still a spatial matching problem, but the matching criterion differs from within, contains, or intersects.

It also introduces new considerations.

What distance model is being used?

Are the coordinates geographic or projected?

Is straight-line proximity an appropriate proxy for accessibility?

A facility that is geographically nearest may not be the easiest one to reach by road.

Those questions belong to the later distance and accessibility cluster, but they demonstrate that “spatial join” describes a family of location-based matching operations rather than one single predicate.

Geometry quality affects the result

A spatial join can only reason about the geometries it receives.

Suppose two district polygons should meet cleanly along a common border, but their source data actually contains:

a small overlap;
a small gap;
an invalid polygon;
duplicated features;
an outdated boundary version.

Then a spatial join reflects those geometries, not the administrative reality you intended them to represent.

A school may unexpectedly match two districts because the polygons overlap.

Another school may match none because it falls into a narrow gap between boundaries.

Those results can look like join failures even though the operation is faithfully evaluating the data supplied to it.

This is one reason topology and geometry validity form their own important GIS topic rather than being merely technical cleanup.

Coordinate reference systems matter too

Spatial relationships depend on coordinates being interpreted correctly.

If a school's coordinates are wrongly labelled with a CRS, the point can be thousands of kilometres away from the district polygons it is supposed to match.

The spatial join may then return no matches—not because the predicate is wrong, but because the geometries really do not overlap in the coordinate space the software is using.

Different layers do not necessarily need to be permanently stored in the same CRS. GIS systems can often transform geometries as part of processing or display.

But the source CRS of each layer must be correctly known.

That is why a result such as:

0 matches

should not immediately lead to:

change WITHIN to INTERSECTS

The predicate is only one possible cause.

If the layers themselves do not appear where expected, CRS problems should be diagnosed before the join logic.

Why did my join create “duplicates”?

This is one of the most common surprises.

Suppose your input contains 1,000 schools.

You perform a spatial join.

The result contains 1,143 rows.

It is tempting to conclude:

The join duplicated 143 records.

Maybe.

But first ask whether some schools matched more than one feature.

Potential reasons include:

overlapping polygons;
a one-to-many output;
one geometry genuinely intersecting several others;
duplicate features in the join layer;
use of intersects when a narrower predicate was intended;
multipart or unusual geometries;
boundary conditions.

Blindly removing duplicate-looking rows can therefore erase valid geographic relationships.

The diagnostic article Why Did My Spatial Join Create Duplicate Records? will examine those cases directly.

Why can a spatial join return no matches?

The opposite problem is also common.

Possible explanations include:

The features genuinely do not satisfy the relationship.

A point outside every polygon should not match a within join.

The wrong predicate was selected.

A boundary point may intersect a polygon without satisfying the intended stricter relationship.

The join direction is wrong.

A within B is not expressed identically to B within A.

A CRS is missing or incorrect.

The layers may not actually occupy the same geographic locations once their coordinates are interpreted.

The geometries contain errors.

Gaps, invalid features, or malformed geometries can affect spatial relationships.

The datasets represent different versions of geography.

Administrative boundaries from different years can disagree even when both files are valid.

A spatial join is deterministic with respect to its inputs and rules. When its result is surprising, the useful question is therefore not merely:

Why did the join fail?

It is:

Which assumption about the inputs, relationship, or expected cardinality was wrong?

A useful pre-join checklist

Before running a spatial join, ask:

What should one output record represent?

A school? A district? A road? A relationship between two features?

Which layer should define those records?

This establishes the direction of the join.

What spatial relationship actually represents the question?

Within, intersects, contains, nearest, within distance, or something else?

Can one feature legitimately match several others?

If yes, decide whether the output should preserve those relationships or aggregate them.

Which attributes do you actually need?

Avoid making the result wider than necessary.

Are the geometries and CRSs trustworthy?

A join cannot compensate for fundamentally mislocated or malformed data.

What should happen when there is no match?

Should the feature remain with null joined attributes, or should unmatched records be excluded?

These decisions make the operation much easier to interpret afterwards.

A spatial join turns location into a relationship

The simplest way to think about a spatial join is:

Use geography as the key.

An attribute join might say:

match because district_code = "D04"

A spatial join can say:

match because this point lies inside that polygon

or:

match because these geometries intersect

or:

match because this is the nearest feature

Once those matches are established, attributes can be transferred, counts or summaries can be calculated, or one-to-many relationships can be preserved.

The operation becomes difficult only when the underlying question is left implicit.

Which features are we asking about?

What geographic relationship should qualify?

Can there be several correct matches?

What information should the result retain?

When those choices are explicit, a spatial join stops being a mysterious GIS command and becomes what it really is: a structured way of relating records through geography.

References

PostGIS Workshop — Spatial Joins. Explains spatial joins as combining information from different tables according to spatial relationships rather than ordinary shared keys.
QGIS Documentation — Join Attributes by Location. Documents spatial attribute joining using geometric predicates such as intersects, contains, within, overlaps, crosses, and touches.
ArcGIS Pro — Spatial Join. Documents target and join features, one-to-one and one-to-many operations, match options, field mapping, and spatially based attribute transfer.
PostGIS — ST_Intersects. Provides the formal geometry relationship used by the ST_Intersects predicate and relates it to the DE-9IM spatial model.