A spatial join is an operation in a geographic information system (GIS) or spatial database that combines the attribute tables of two spatial layers based on a desired spatial relation between their geometries.[1] It is similar to the table join operation in relational databases in merging two tables, but each pair of rows is correlated based on some form of matching location rather than a common key value.[2] It is also similar to vector overlay operations common in GIS software such as Intersect and Union in merging two spatial datasets, but the output does not contain a composite geometry, only merged attributes.
Spatial joins are used in a variety of spatial analysis and management applications, including allocating individuals to districts and statistical aggregation. Spatial join is found in most, if not all, GIS and spatial database software, although this term is not always used, and sometimes it must be derived indirectly by the combination of several tools.
See main article: Spatial relation and Geospatial topology. Fundamental to the spatial join operation is the formulation of a spatial relationship between two geometric primitives as a logical predicate; that is, a criterion that can be evaluated as true or false.[3] For example, "A is less than 5km from B" would be true if the distance between points A and B is 3km, and false if the distance is 10km. These relation predicates can be of two types:
Note that some relations are commutative (e.g., A overlaps B if and only if B overlaps A) while others are not (e.g., A is within B does not mean B is within A).
The geometric primitives involved in these relations may be of any dimension (points, lines, or regions), but some relations may only have meaning with certain dimensions. For example, "A is within B" has a clear meaning if A is a point and B is a region, but is meaningless if both A and B are points. Other relations may be vague; for example, the distance between two regions or two lines may be interpreted as the minimal distance between their closest boundaries, or a mean distance between their centroids.[6]
As in a relational table join as defined in the relational algebra, two input layers or tables are provided (hereafter X and Y), and the output is a table containing all of the columns of each of the inputs (or some subset thereof if selected by the user). The rows of the new table are a subset of Cross join or Cartesian product of the two tables, all possible pairs of rows . Rather than include all possible combinations, each pair is evaluated according to the given spatial predicate; those for which the predicate is true are considered "matching" and are retained, while those for which the predicate is false are discarded.
For example, consider the following two tables:
| StudentID | LastName | GPA | Residence: point | |
|---|---|---|---|---|
| 1 | Rafferty | 3.56 | • | |
| 2 | Jones | 2.75 | • | |
| 3 | Heisenberg | 3.98 | • | |
| 4 | Robinson | 1.56 | • | |
| 5 | Smith | 2.67 | • | |
| 6 | Williams | 3.46 | • |
| SchoolID | SchoolName | District: polygon | Building: point | |
|---|---|---|---|---|
| 31 | Belknap Elementary | □ | • | |
| 33 | Parkview Elementary | □ | • | |
| 34 | Smith Elementary | □ | • | |
| 35 | Central Elementary | □ | • |
When the spatial join is executed, the direction of attachment must be specified, for two reasons: 1) the given spatial predicate may not be commutative, and 2) there is often a many-to-one relationship between the rows (e.g., many students are inside each school district). In the example above, a common goal would be to join the schools table to the students table (the target table), with the relation predicate being "student.residence within school.district." Assuming that the districts do not overlap, each student point will be in no more than one school district, so the output would have the same rows as the students table, with the corresponding school attributes attached, as:
| StudentID | LastName | GPA | Residence: point | SchoolID | SchoolName | |
|---|---|---|---|---|---|---|
| 1 | Rafferty | 3.56 | • | 33 | Parkview Elementary | |
| 2 | Jones | 2.75 | • | 34 | Smith Elementary | |
| 3 | Heisenberg | 3.98 | • | 35 | Central Elementary | |
| 4 | Robinson | 1.56 | • | 33 | Parkview Elementary | |
| 5 | Smith | 2.67 | • | 34 | Smith Elementary | |
| 6 | Williams | 3.46 | • | 33 | Parkview Elementary |
The reverse operation, in this case attaching the student information to the schools table, is not as simple because many rows must be joined to one row. Some GIS software does not allow this operation, but most implementations allow for an aggregate join, in which aggregate summaries of the matching rows can be included, such as arrays, counts, sums, or means.[7] For example, the result table might look like:
| SchoolID | SchoolName | District: polygon | Building: point | Students_COUNT | GPA_MEAN | |
|---|---|---|---|---|---|---|
| 31 | Belknap Elementary | □ | • | 0 | ||
| 33 | Parkview Elementary | □ | • | 3 | 2.86 | |
| 34 | Smith Elementary | □ | • | 2 | 2.71 | |
| 35 | Central Elementary | □ | • | 1 | 3.98 |
Another option when there are multiple matches is to use some criterion to select one of the rows from the matching set, usually a spatial optimization criterion.[8] For example, one could join the school building points (not the districts) to the student residents points by selecting the school that is nearest to each student. Not all software implements this option directly, although in some cases it can be derived through a combination of tools.