Tableau Quiz: Spatial Joins
10 questions · exam conditions
0:00
Spatial JoinsQuestion 1 of 10

A facilities team has a polygon spatial file containing one row per building and a point spatial file containing one row per environmental sensor. The team must retain every building, including buildings with no sensors, while associating each sensor with every building polygon it intersects.

Which join configuration best meets the requirement?

Use a left join from buildings to sensors with an Intersects join clause on the two Geometry fields.
Use an inner join from buildings to sensors with an equality join clause on the two Geometry fields.
Use a right join from buildings to sensors with an Intersects join clause on the two Geometry fields.
Use a full outer join from buildings to sensors with an equality join clause on building and sensor identifiers.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Spatial Joins

Practice Spatial Joins in Tableau with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Spatial Joins, giving you a quick way to practice the rules, question types, and explanations that matter most for Tableau.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A facilities team has a polygon spatial file containing one row per building and a point spatial file containing one row per environmental sensor. The team must retain every building, including buildings with no sensors, while associating each sensor with every building polygon it intersects.

Which join configuration best meets the requirement?

  1. Use a left join from buildings to sensors with an Intersects join clause on the two Geometry fields. (correct answer)
  2. Use an inner join from buildings to sensors with an equality join clause on the two Geometry fields.
  3. Use a right join from buildings to sensors with an Intersects join clause on the two Geometry fields.
  4. Use a full outer join from buildings to sensors with an equality join clause on building and sensor identifiers.
Explanation: When a question asks you to "retain every row from one side while matching rows from another," you're being tested on two distinct concepts simultaneously: join type (which rows survive) and join clause (what defines a match). Getting one right but not the other will still produce wrong results. Here, the requirement has two parts: keep all buildings even if no sensor falls inside them, and match sensors spatially rather than by a shared ID. Answer A satisfies both. A left join from buildings to sensors preserves every building row — those with no intersecting sensors simply return nulls for the sensor fields. Pairing that with an Intersects spatial join clause correctly defines the match condition: a sensor associates with a building when its point geometry falls within the building's polygon boundary. Answer B fails on both counts. An inner join drops any building that has no matching sensor, which directly violates the "retain every building" requirement. An equality clause on two Geometry fields would also almost never produce matches, since polygon and point geometries are different data types and shapes. Answer C uses the correct Intersects clause, but a right join from buildings to sensors keeps all sensors — not all buildings. This is the mirror-image trap: swapping which side is preserved. Answer D uses a full outer join, which retains all rows from both tables — more than required — and an equality clause on identifiers, which ignores spatial relationships entirely and won't capture the polygon-point intersection logic the scenario demands. A useful rule of thumb: left join = keep the left table whole. Always identify which entity must be fully preserved, make it the left table, and choose your join clause based on how the match is defined — spatially or by key.

Question 2

Two municipal district polygons share a boundary. A service-call point is located exactly on that shared boundary according to the stored coordinates. The point and polygon files are joined using Intersects.

Assuming the geometries are valid and no additional join clauses are used, which result should the analyst expect?

  1. The call can match both districts because the shared polygon boundaries intersect the point. (correct answer)
  2. The call matches neither district because Intersects excludes points located on polygon boundaries.
  3. The call matches only the district with the smaller polygon area after Tableau compares both polygons.
  4. The call matches only the district listed first because spatial joins require a single polygon match.
Explanation: When working with spatial joins in Tableau, the key concept to understand is how the Intersects predicate behaves geometrically. Intersects returns a match whenever two geometries share any portion of space — including edges, vertices, or interiors. This is rooted in standard spatial logic: if geometry A and geometry B share at least one point, they intersect. In this scenario, the service-call point sits exactly on the shared boundary between two polygons. That boundary belongs to both polygons simultaneously — it defines the edge of each district. Because the point touches that shared edge, it intersects both polygons by definition. That makes A the correct answer: the analyst should expect the call to match both districts. B has the logic completely backwards. Intersects does not exclude boundary points — that's the behavior of the stricter Contains or Within predicates, which require the point to fall strictly in the interior of a polygon. A point on an edge absolutely satisfies Intersects. C introduces a comparison that simply doesn't exist in Tableau's spatial join logic. Polygon area plays no role in determining which geometry a point intersects; Tableau does not use area as a tiebreaker. D confuses spatial joins with lookup functions. Spatial joins in Tableau can and do produce multiple matching rows — there is no "first match wins" rule baked into Intersects. A double-match is a valid, expected output. As a study tip, remember the hierarchy: Intersects is the most permissive spatial predicate (edges count), while Contains/Within are stricter (interior only). Questions describing boundary-edge scenarios almost always test this distinction.

Question 3

A point spatial file contains customer locations in a Geometry field. A second spatial file contains service-area polygons in another Geometry field. Customer and service-area names do not follow a common naming convention.

Which join clause should the analyst use to determine spatial membership directly from the files?

  1. Set the two Geometry fields equal so customers match polygons that have identical serialized geometry representations.
  2. Set customer name equal to service-area name after assigning both name fields a geographic role in Tableau.
  3. Use Intersects between the customer Geometry and service-area Geometry fields. (correct answer)
  4. Use equality between the Latitude values that Tableau generates from each spatial file's Geometry field.
Explanation: When working with spatial data in Tableau, the core question is always: what relationship connects the two spatial datasets? Here, you have point locations (customers) and polygon regions (service areas), and you need to determine which customers fall inside which polygons — a classic spatial containment problem. Tableau's spatial join supports an Intersects clause specifically for this purpose. When you join two spatial files using Intersects between their Geometry fields, Tableau evaluates whether each point geometry touches or falls within each polygon geometry. This works directly from the raw spatial data, requires no shared attribute keys, and handles the containment logic natively. C is the correct approach. The distractors each represent a meaningful trap. A misunderstands how spatial geometries work — two records with different shapes will never have identical serialized geometry strings, so equality between Geometry fields would return no matches. B attempts a workaround using geographic roles and name matching, but the passage explicitly states that customer and service-area names share no common naming convention, making a name-equality join impossible. This choice also confuses geographic roles (which help Tableau geocode data for visualization) with join logic. D tries to exploit Tableau's auto-generated Latitude values, but a single latitude doesn't encode polygon membership — two points with the same latitude could belong to completely different service areas, making this geometrically meaningless. A useful rule of thumb: whenever a question involves point-in-polygon or spatial containment across two geometry fields with no shared attribute key, Intersects is your tool. If names or IDs matched, a standard equality join would work — but spatial relationships require a spatial operator.

Question 4

County polygons are placed on the left side of a left spatial join to clinic points. Some counties contain several clinics, while one county contains none. The analyst needs a clinic count that displays zero, rather than one, for the county with no matching clinic.

Which measure is most appropriate after the join?

  1. Count the county identifier because every county row, whether matched or not, carries its own county identifier.
  2. Count the clinic identifier because the unmatched county has a null value on the clinic side, which COUNT ignores. (correct answer)
  3. Count all joined rows because the left join produces no row at all for a county without any matching clinic.
  4. Count the county Geometry field because an unmatched county's polygon is flagged as a special null geometry type.
Explanation: Whenever you see a question about spatial joins and aggregation, focus on two things: what rows the join produces, and how NULL values behave inside aggregate functions. A left spatial join keeps every row from the left side (counties) regardless of whether a match exists on the right side (clinics). For the county with no clinics, the join still produces exactly one row — but every field sourced from the clinic table, including the clinic identifier, comes back as NULL. This is the key mechanic that makes B correct: COUNT(clinic_id) ignores NULLs by design, so it returns 0 for the unmatched county and a real integer for every matched county. That gives you the zero-display behavior the analyst needs. A is wrong because COUNT(county_id) counts the county's own identifier, which is never NULL — even the unmatched county carries its county ID. This would return 1 for every county, including the one with no clinics, which is precisely the misleading result the analyst is trying to avoid. C is wrong because it states the left join produces no row for an unmatched county. That describes an inner join, not a left join. A left join guarantees at least one output row per left-side record. D is wrong because there is no special "null geometry type" flag in standard spatial join behavior. The geometry field for the county itself remains intact; the NULL values appear only on the clinic side of the join. Study tip: Always pair join type knowledge with NULL-handling rules — questions about counts after outer joins almost always hinge on COUNT(column) vs. COUNT(*), since only the latter counts NULLs.

Question 5

A district spatial file contains one polygon row for each district and reporting year, so the same district geometry is repeated for several years. An incident file contains point geometry, an incident date, and a derived reporting year. The analyst wants each incident matched only to the district record for the same year.

Which join design best prevents each incident from matching the repeated district rows for other years?

  1. Use Intersects on the Geometry fields and change the physical join to a full outer join.
  2. Use Intersects on the Geometry fields and sort both tables by reporting year before joining.
  3. Use equality on reporting year only and let Tableau infer the containing district from the map.
  4. Use Intersects on the Geometry fields and add equality between the two reporting-year fields. (correct answer)
Explanation: When working with spatial joins in Tableau, the core challenge is controlling which rows match across tables. A spatial join using Intersects matches a point to every polygon that contains it — so if the same district polygon appears five times (once per year), a single incident point will match all five rows. Your job is to add a constraint that narrows each match to exactly one row. That's precisely what D does. By combining an Intersects condition on the geometry fields and an equality condition on reporting year, you create a compound join clause. An incident matches a district row only when the point falls inside the polygon and the years match. This eliminates the duplicate-year problem entirely and is the cleanest, most direct solution. A is wrong because switching to a full outer join changes which unmatched rows are included in the result — it doesn't prevent the one-to-many spatial match from still firing across all years. You'd still get cross-year duplicates; you'd just also see nulls for unmatched rows. B is a trap: sorting before a join has no effect on join logic in Tableau. Tableau's join engine doesn't use sort order to limit matches — every intersecting polygon row still matches regardless of how the data is ordered. C is wrong because an equality join on year alone has no spatial component, so Tableau cannot infer geographic containment from that — it would either produce incorrect matches or fail to join spatially at all. The key study tip: whenever a spatial table has repeated geometries across a dimension (like time), always pair your Intersects clause with an equality clause on that dimension to prevent fan-out.

Question 6

A transportation agency joins bus-route line geometries to evacuation-zone polygons using Intersects. One route begins outside a zone, crosses through the zone, and ends outside the zone. Neither endpoint lies within the zone.

How should the spatial join treat this route-zone pair?

  1. It should not match because at least one route endpoint must be inside the polygon.
  2. It should match only if the midpoint of the route line is inside the polygon.
  3. It should match because part of the line geometry passes through the polygon. (correct answer)
  4. It should not match because Intersects supports points within polygons but not line crossings.
Explanation: When working with spatial joins in Tableau (and GIS tools generally), the critical question is: what does the chosen spatial relationship actually require? The Intersects predicate is the most permissive common option — it returns a match whenever any part of one geometry shares any space with another geometry, including edges, interiors, or crossings. In this scenario, a bus route enters an evacuation zone, travels through it, and exits — meaning a segment of the line geometry physically overlaps the polygon's interior. That is a textbook intersection, which is why C is correct: the match should occur because part of the line passes through the polygon. Neither endpoint needs to be inside for Intersects to apply. A is wrong because it confuses Intersects with a point-in-polygon test. Intersects never requires an endpoint or any specific vertex to fall inside the polygon — it only requires any geometric overlap. B is wrong for a similar reason: the midpoint has no special significance under Intersects. Checking the midpoint would be an arbitrary, nonstandard rule that Tableau's spatial join does not use. D is flatly incorrect about Tableau's capabilities; Intersects fully supports line-crosses-polygon relationships, not just point containment. This choice describes a limitation that doesn't exist. A useful study tip: whenever you see a spatial join question, mentally map the predicate name to its requirement. Intersects = any overlap whatsoever. Contains/Within = one geometry entirely inside another. If the question involves a line crossing a polygon, Intersects will always match — endpoints are irrelevant.

Question 7

A parcel polygon overlaps a narrow edge of a flood-zone polygon, but the parcel's centroid lies outside the flood zone. The compliance rule states that any parcel with any geometric overlap must be flagged.

Which approach correctly implements the rule?

  1. Join the parcel centroid to the flood polygon because centroid containment is equivalent to polygon overlap.
  2. Join the parcel and flood-zone Geometry fields using Intersects because their polygon areas overlap. (correct answer)
  3. Join parcel and flood-zone identifiers because overlapping polygons normally share a geographic identifier.
  4. Compare polygon areas and flag the parcel only when the parcel has the smaller total area.
Explanation: When questions involve spatial relationships between polygon layers, you need to distinguish between geometric overlap and attribute-based proximity. The key question here is: what does "any geometric overlap" actually require technically? The rule is explicit — even a sliver of shared area triggers the flag. That means you need a spatial join using Intersects as the relationship predicate, which returns a match whenever two geometries share any point, edge, or area. Answer B is correct because joining the parcel and flood-zone Geometry fields using Intersects will catch exactly this scenario: the parcel polygon's edge crosses into the flood zone, so the geometries intersect, and the parcel gets flagged — regardless of where the centroid falls. Answer A fails precisely because of the scenario described in the passage. A centroid join only checks whether the parcel's center point falls inside the flood polygon. Since the centroid lies outside the flood zone here, this join would produce no match and the parcel would be silently missed — a dangerous compliance gap. Answer C is wrong because overlapping polygons do not automatically share a geographic identifier. Spatial overlap is a geometric relationship, not an attribute relationship. Shared IDs would only work if the data were explicitly coded that way, which cannot be assumed. Answer D introduces area comparison, which is irrelevant to the rule. The compliance trigger is any overlap, not relative parcel size. Filtering by area would both miss small encroachments and incorrectly exclude valid violations. When you see "any geometric overlap" in a compliance rule, that phrase is your cue to reach for Intersects — not centroid joins, not attribute matches, not area thresholds.

Question 8

An analyst spatially joins two files that should cover the same city. One file's coordinates are defined in geographic degrees, while the other file was exported in projected meter coordinates with missing or incorrect coordinate reference system metadata. Almost no features match.

What should the analyst investigate first?

  1. Verify that both files have accurate coordinate reference system metadata and are interpreted in compatible locations. (correct answer)
  2. Change the join to a full outer join so Tableau can transform unmatched coordinates automatically.
  3. Convert the polygon identifiers to strings so coordinate values are compared at the same data type.
  4. Sort both spatial files by Geometry so corresponding features occupy the same physical row positions.
Explanation: Whenever you see a spatial join failing to match features, your first instinct should be to think about coordinate reference systems (CRS). Geographic data only makes sense when every layer speaks the same spatial "language" — meaning coordinates must be interpreted in the same reference system before locations can be compared. Here, one file uses geographic degrees (latitude/longitude) and the other uses projected meter coordinates with broken or missing CRS metadata. Tableau and most spatial engines rely on that metadata to reproject or align layers automatically. Without it, a point at coordinates (500000, 4200000) in meters gets compared against points near (500000°, 4200000°) in degrees — positions that don't exist on Earth. The result is almost zero feature matches, exactly what the analyst sees. Answer A is correct because verifying and correcting the CRS metadata on both files is the essential first diagnostic step. Once both layers are interpreted in compatible systems, the join can resolve locations accurately. Answer B is wrong because a full outer join changes which unmatched rows are returned, not why the coordinates don't align. Tableau cannot auto-reproject data simply by changing join type — that's not what outer joins do. Answer C is wrong because the problem is spatial misalignment, not a data-type mismatch between identifier strings. Converting polygon IDs to strings does nothing to reconcile coordinate systems. Answer D is wrong because spatial joins match features by location, not by row order. Sorting geometries physically in a file has no effect on whether their coordinates fall in the same place on Earth. Study tip: On spatial questions, always ask "are both layers in the same coordinate reference system?" before investigating join types, data types, or sort order.

Question 9

A retailer spatially joins store points to sales-territory polygons. Because two territory polygons overlap, one store point intersects both polygons. The retailer then calculates total sales by territory from the joined data.

What is the most accurate interpretation of the joined result?

  1. The store is assigned only to the polygon whose centroid is closest to the store point.
  2. The store matches both territories, so its sales can contribute to both territory-level totals. (correct answer)
  3. The spatial join rejects the store because a point cannot intersect more than one polygon.
  4. The store matches one territory selected according to the physical order of the polygon rows.
Explanation: When working with spatial joins in Tableau, the key concept to understand is that a spatial join matches features based on geometric relationships — and unlike a database primary-key join, nothing prevents a single point from matching multiple polygons if those polygons overlap. In this scenario, two territory polygons share overlapping space, and one store point falls within that overlapping zone. Tableau's spatial join evaluates the intersection condition for every polygon-point pair. Since the store genuinely intersects both polygons, the join produces two rows for that store — one pairing with each territory. When you then aggregate sales by territory, that store's sales appear in both territory totals. This is answer B, and it's the most accurate interpretation of what the data actually contains. A is wrong because spatial joins in Tableau don't use centroid proximity as a tiebreaker — that's a different type of spatial operation (nearest-neighbor analysis). Nothing in a standard spatial join computes or compares centroids. C is incorrect because Tableau does not reject or error on a point intersecting multiple polygons; it simply returns multiple matching rows, which is standard many-to-many join behavior. D is wrong because Tableau's spatial join is not row-order dependent — it doesn't arbitrarily select "the first polygon that appears." Row order in a data source is generally unreliable and never the basis for spatial matching logic. The study tip here: whenever you see overlapping polygons in a spatial join question, immediately think duplicate rows and double-counting risk. The join itself is working correctly — it's your downstream aggregation logic that must account for the fact that one feature can match many polygons.

Question 10

An asset table is on the left side of a left spatial join to maintenance-region polygons. Most assets have valid point geometries, but one asset has a null Geometry value. The join clause uses Intersects.

What is the expected result for the asset with the null Geometry value?

  1. It is removed because Intersects converts every left spatial join into an inner join for null geometries.
  2. It is matched to every region because a null geometry is treated as having an unknown location.
  3. It is assigned to the nearest region centroid because Tableau substitutes a proximity comparison.
  4. It is retained with null region fields because the left join preserves the unmatched asset row. (correct answer)
Explanation: Whenever you see a question about spatial joins in Tableau, anchor your thinking to the join type first, then layer in the geometry behavior. A left join's fundamental promise is that every row from the left table is preserved in the output — spatial joins honor that same contract. When an asset has a null Geometry value, Tableau cannot evaluate the Intersects predicate (there's nothing to intersect against), so the asset simply fails to match any region polygon. Because the join is a left join, that unmatched row isn't discarded — it's retained with null values filled in for all region fields. This is exactly what D describes, making it the correct answer. A is wrong because it conflates a specific edge-case behavior with a rule that doesn't exist. Left spatial joins do not silently convert to inner joins when a geometry is null; the left-join guarantee holds regardless. B is wrong because Tableau does not treat null geometry as "unknown location" and attempt to match it everywhere — null means absent, not ambiguous, and no match is generated. C is wrong because Tableau never substitutes a proximity or centroid-based fallback when a geometry is null; that kind of nearest-neighbor logic would require an explicit distance-based join, not an Intersects clause. A practical tip: on Tableau exam questions involving joins, always identify the join type before reasoning about edge cases. The words "left join" and "preserves" are nearly synonymous — if a row can't match, it survives with nulls. Any answer suggesting automatic exclusion or substitution for unmatched left-side rows should immediately raise a red flag.