Joins & relationships

Spatial joins, attribute joins, nearest neighbour and point-in-polygon.

Three points joined to two overlapping zones, producing four rows rather than three. a spatial join is a relation, so the row count is not the input countzone Azone Bsjoinpoint 1 · zone Apoint 2 · zone Apoint 2 · zone Bpoint 3 · zone Bthree points in, four rows outThe fan-out is not a defect — it is the join reporting every relationship it found

A join answers "which of these goes with which of those", and there are only two ways to answer it: read a key somebody already wrote down, or compute the relationship from the geometry. The first is faster and authoritative. The second works when no key exists, which is most of the time.

The surprise in spatial joins is arithmetic rather than spatial. An attribute join on a unique key is a function — each left row matches at most one right row. A spatial join is a relation, and a relation can be true several times, so a left feature that falls inside two overlapping zones comes back twice. The row count growing is not a fault; it is the join reporting every relationship it found, and the fix is deciding what one output row should mean.

The pages below run from what a join is doing, through the joins themselves — point-in-polygon, polygon overlay, nearest neighbour — to the specific ways one returns nothing, or far too much.

Learning paths run through this topic too — see the end of this page.

🧭 Start with the concepts

The ideas the how-to guides below assume you already have.

Show every concept in this topic

⚙️ Then do the task

Step-by-step walkthroughs with code you can copy and adapt.

Show every how-to guide in this topic

🔧 When it breaks

The errors this topic produces, with the cause explained rather than just the command.

Show every fix in this topic

Related topics

Subjects that keep coming up alongside this one, most overlap first.

Keep browsing

Joins & relationships sits in Geometry & space. Every topic on the site is listed on the topics index.