Tableau Quiz: Custom Geocoding
10 questions · exam conditions
0:00
Custom GeocodingQuestion 1 of 10

An organization identifies distribution sites with internal codes such as DC-NE-04 and DC-SW-11. Each code has a verified latitude and longitude, but the codes have no meaningful street, city, or postal-code components. The organization wants analysts to map these codes by assigning a reusable geographic role.

Which approach best meets the requirement?

Assign the Postal Code role to the site-code field, and specify the country in Edit Locations.
Import a custom geocoding CSV that maps each site code to its latitude and longitude.
Create a custom territory from the site codes, and let Tableau calculate each territory centroid.
Create aliases that replace each site code with the name of its nearest recognized city.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Custom Geocoding

Practice Custom Geocoding 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 Custom Geocoding, 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

An organization identifies distribution sites with internal codes such as DC-NE-04 and DC-SW-11. Each code has a verified latitude and longitude, but the codes have no meaningful street, city, or postal-code components. The organization wants analysts to map these codes by assigning a reusable geographic role.

Which approach best meets the requirement?

  1. Assign the Postal Code role to the site-code field, and specify the country in Edit Locations.
  2. Import a custom geocoding CSV that maps each site code to its latitude and longitude. (correct answer)
  3. Create a custom territory from the site codes, and let Tableau calculate each territory centroid.
  4. Create aliases that replace each site code with the name of its nearest recognized city.
Explanation: When Tableau can't recognize a field through its built-in geocoding engine — because the values aren't real place names, postal codes, or administrative regions — the right tool is custom geocoding. Whenever you see location identifiers that are purely internal codes tied to known coordinates, ask yourself: "Does Tableau's geocoder have any hope of resolving these?" If the answer is no, you need to supply the coordinates yourself. That's exactly why B is correct. Importing a custom geocoding CSV lets you define a new geographic role by mapping each site code (like DC-NE-04) directly to its verified latitude and longitude. Tableau registers this as a reusable role, so analysts can assign it to the field across any workbook — no manual coordinate entry required each time. A fails because the Postal Code role expects values that conform to real postal-code formats. Internal distribution codes share no structural or geographic relationship with postal codes, so Tableau simply cannot match them, even with a country specified in Edit Locations. C is a misapplication of custom territories. Territories are used to group existing geographic regions (like states or counties) into larger units — they don't create new mappable locations from scratch, and they can't resolve unrecognized codes. D creates an aliasing workaround that actually destroys the requirement. Replacing site codes with nearest-city names loses the precise coordinates, forces Tableau to snap points to city centroids it already knows, and introduces locational error. The study tip here: when a question describes internal codes with known coordinates, custom geocoding via CSV is almost always the answer. It's the only method that creates a genuinely reusable geographic role from scratch.

Question 2

An analyst prepares custom geocoding for research stations. The CSV contains station identifiers and two coordinate columns. After import, stations expected in northern Canada appear in the Indian Ocean. Inspection shows that a sample row contains latitude 68.4 and longitude −105.7, but those values were placed in the opposite coordinate columns.

Which correction most directly resolves the problem?

  1. Reverse the map's latitude and longitude shelves after every custom-geocoded field is added.
  2. Change both coordinate values to positive numbers before importing the custom geocoding again.
  3. Correct the CSV column assignments so latitude is 68.4 and longitude is −105.7, then reimport. (correct answer)
  4. Assign the station identifier the Country/Region role and specify Canada in Edit Locations.
Explanation: When working with custom geocoding in Tableau, the most important thing to understand is that coordinate columns must be explicitly mapped to the correct geographic roles — latitude and longitude are not interchangeable. If your CSV assigns the wrong values to the wrong columns, Tableau will faithfully plot points using those swapped values, placing locations in entirely wrong parts of the world. Here, the station sits at latitude 68.4°N and longitude −105.7° (western Canada) — but the CSV has those values in the opposite columns. Tableau reads what it's given: it treats −105.7 as a latitude and 68.4 as a longitude, plotting the point near the Indian Ocean. The fix is straightforward — correct the column assignments in the CSV so that 68.4 sits under the latitude column and −105.7 sits under the longitude column, then reimport. That's exactly what C does, and it targets the actual root cause. A is wrong because swapping the shelves in Tableau's view doesn't fix the underlying data — you'd be applying a visual workaround that could break other calculations and won't persist reliably across workbooks. B is a trap: making both values positive would strip the directional meaning (west and north are encoded via sign), moving your station to a completely different location rather than fixing it. D is wrong because assigning a Country/Region role to a station identifier and using Edit Locations is designed for ambiguous place names, not for correcting raw coordinate values that are simply swapped. The study tip here: whenever custom geocoding produces wildly misplaced points, check the CSV column headers first — a swapped latitude/longitude column is the most common culprit, and the fix always lives in the source data, not in Tableau's interface.

Question 3

An analyst imported custom geocoding for campus buildings. The facilities team later corrected the coordinates of three buildings in the original CSV. The existing workbook still plots the buildings at their old positions after the data source is refreshed.

Which action should the analyst take?

  1. Refresh the extract again because custom-geocoding coordinates are part of the data-source refresh.
  2. Reimport the corrected custom geocoding so Tableau updates the stored location mappings. (correct answer)
  3. Clear the worksheet cache because Tableau reads the custom-geocoding CSV whenever a map renders.
  4. Reassign the building field to the same geographic role so Tableau recalculates the source coordinates.
Explanation: When working with custom geocoding in Tableau, it's important to understand where that geocoding data lives and how Tableau accesses it. Custom geocoding isn't embedded in your workbook or refreshed as part of a normal data-source refresh — it's stored as a separate imported mapping that Tableau maintains independently. This distinction is exactly what this question tests. Because Tableau stores custom geocoding in its own internal location database (separate from your data source), updating the original CSV file does nothing on its own. Tableau has no automatic connection back to that file after the initial import. To apply the corrected coordinates, you must explicitly reimport the geocoding through Tableau > Map > Geocoding > Import Custom Geocoding, which overwrites the stored mappings with the updated values. That's why B is correct — it's the only action that actually updates the location mappings Tableau uses when rendering the map. A is wrong because refreshing the extract updates the attribute data in your data source, not the coordinate mappings stored in Tableau's geocoding database. These are two completely separate systems. C is wrong because Tableau does not re-read the CSV file on each render — the file was only relevant at import time, so clearing a cache won't help. D is wrong because reassigning a geographic role only tells Tableau how to classify a field; it doesn't trigger a re-read of any coordinate source and won't change where the buildings are plotted. A reliable rule of thumb: any time coordinates from custom geocoding appear stale, your first instinct should be to reimport, not refresh.

Question 4

A map contains 2,000 customer records. Tableau reports 18 unknown postal codes. Twelve are obsolete codes that have known replacements, four are typographical errors, and two contain null values. The analyst selects Show Data at Default Position from the special-values indicator.

What is the most important consequence of this choice?

  1. Tableau resolves the obsolete and mistyped codes by assigning each one its nearest valid postal area.
  2. Tableau displays unresolved records at a fallback position, but their actual locations remain uncorrected. (correct answer)
  3. Tableau excludes only the null records while matching the remaining codes through custom geocoding.
  4. Tableau permanently adds the replacement postal codes to the workbook's geographic database.
Explanation: When Tableau encounters records it cannot geocode, it gives you a special-values indicator at the bottom of the map view. The key concept being tested here is what Show Data at Default Position actually does — and critically, what it doesn't do. Choosing this option tells Tableau to plot unresolvable records at a generic fallback coordinate (typically a central point for the country or region) so they appear on the map rather than being hidden. This is purely a display accommodation, not a data-correction mechanism. The underlying postal code values in your data source remain exactly as they were — obsolete, mistyped, or null. That's why B is correct: the records show up visually, but their actual locations are never fixed. A is wrong because Tableau does not perform any proximity matching or automatic code substitution when you choose this option. Assigning a "nearest valid postal area" describes behavior that doesn't exist in this workflow — that kind of geocoding repair requires manual intervention or a custom geocoding import. C is wrong on two counts: null values are not treated separately from other unresolved records under this option, and there is no custom geocoding matching triggered automatically. D is wrong because Show Data at Default Position makes no permanent changes to Tableau's geographic database whatsoever — it's a transient display setting, not a data-editing function. A useful study rule: whenever a Tableau question mentions a display option for special values, ask yourself whether the underlying data is being changed or just being rendered differently. On this exam, display settings and data corrections are almost always designed as distractors for each other.

Question 5

A utility company has two mapping requirements. It must plot individual substations identified by internal codes and verified coordinates, and it must display irregular maintenance-area boundaries supplied as polygon geometry.

How should the analyst use custom geocoding in this solution?

  1. Use custom geocoding for both the substation points and the polygon maintenance boundaries.
  2. Create custom territories for substations, and geocode each polygon from its maintenance-area name.
  3. Use spatial data for substations, and create aliases to generate the polygon maintenance boundaries.
  4. Use custom geocoding for substations, and connect to spatial data for the polygon boundaries. (correct answer)
Explanation: When Tableau questions describe two different data scenarios, your job is to match each scenario to the right tool — not force one tool to do everything. Here, the analyst faces two distinct challenges: point locations identified by internal codes with verified coordinates, and polygon geometries representing irregular boundaries. These require different approaches because the data types and sources are fundamentally different. Custom geocoding in Tableau lets you define your own point locations by uploading a file that maps custom names or codes to latitude/longitude coordinates. This is perfect for substations identified by internal codes that Tableau wouldn't recognize natively. Spatial data (shapefiles, GeoJSON, etc.), on the other hand, is the correct vehicle for polygon geometry — it carries the actual boundary coordinates that define irregular shapes. D is correct because it applies each tool to the scenario it was built for: custom geocoding handles the substations, and a spatial file connection handles the polygon boundaries. A is wrong because custom geocoding only produces point locations — you simply cannot define polygon boundaries through it. Trying to use it for both would fail at the polygon stage entirely. B confuses two separate features. Custom territories group existing Tableau-recognized locations into regions; they don't place substations identified by internal codes. And geocoding from a "maintenance-area name" doesn't generate polygon geometry — it would only produce a centroid point at best. C is the subtlest trap. Aliases rename dimension values for display purposes — they have no geocoding or geometry-generating capability whatsoever. Study tip: On Tableau exam questions, watch for scenarios mixing point data with polygon data. Points → custom geocoding or lat/long fields; polygons → spatial file connections. These are never interchangeable.

Question 6

A workbook contains a field named Municipality with values such as "Richmond," "Kingston," and "Cambridge." The field has the City geographic role. Tableau recognizes some values but marks others as ambiguous because these city names occur in several countries. A separate Nation field contains the correct country for every row.

Which action should the analyst take to resolve the ambiguous locations while preserving city-level geocoding?

  1. In Edit Locations, set Country/Region to From Field and select the Nation field. (correct answer)
  2. Change Municipality from the City geographic role to the Country/Region geographic role.
  3. Filter the ambiguous municipalities from the view and retain only automatically recognized cities.
  4. Create aliases that append the Nation value to each displayed municipality name.
Explanation: Whenever you see a question about ambiguous geocoding in Tableau, think about why ambiguity occurs: city names like "Richmond" or "Cambridge" exist in multiple countries, so Tableau doesn't know which geographic coordinates to use. The solution is to give Tableau additional context — a reference field that anchors each city to its correct country — without abandoning the city-level role entirely. That's exactly what option A accomplishes. In the Edit Locations dialog, setting Country/Region to "From Field" and selecting the Nation field tells Tableau to use that column as a hierarchical constraint. Now when Tableau looks up "Richmond," it knows to find the Richmond in the country specified by Nation, resolving the ambiguity while keeping Municipality geocoded at the city level. Option B is a fundamental misunderstanding of geographic roles. Changing Municipality to Country/Region doesn't resolve the ambiguity — it destroys the city-level detail entirely and would try to geocode city names as countries, which makes no sense. Option C simply hides the problem: filtering out ambiguous cities means you lose data, which is never an acceptable resolution strategy when the data is valid and needed. Option D creates display aliases for labels but does nothing to the underlying geographic coordinates Tableau uses for mapping — the ambiguity in the spatial lookup remains unresolved regardless of how the names appear on screen. A useful rule of thumb: when a geographic field has ambiguity due to duplicate names across countries, always look for a way to add context through a related field rather than changing the role or removing data. The "From Field" option in Edit Locations is Tableau's built-in tool for exactly this scenario.

Question 7

A consulting team imports custom geocoding for proprietary sales zones and verifies the results in Tableau Desktop. A client who receives only the workbook definition file must be able to open the workbook without separately reproducing the consultant's local geocoding setup.

Which delivery approach best preserves the workbook's custom-geocoding dependencies?

  1. Send the plain workbook definition file and ask the client to refresh the generated latitude field so the geocoding mappings are reconstructed from the data source.
  2. Export the finished map as a static worksheet image, since custom-geocoded locations are stored locally and are typically unavailable outside the author's environment.
  3. Deliver a packaged workbook or publish the workbook with the required supporting resources included. (correct answer)
  4. Send only the original geocoding CSV and instruct the client to import it locally, since Tableau rebuilds the workbook's geocoding definitions from that file on first open.
Explanation: When a question asks about sharing a workbook that depends on custom resources — geocoding, data sources, images, or local files — your central question should be: what packaging mechanism does Tableau provide to bundle those dependencies together? Custom geocoding lives in the author's local Tableau Repository and is not embedded in a plain .twb file. If you hand someone only that file, Tableau on their machine searches its own local geocoding definitions and finds nothing, breaking the map entirely. The solution Tableau provides is the packaged workbook (.twbx), which bundles the workbook definition alongside supporting resources — including custom geocoding — into a single portable container. Publishing to Tableau Server or Cloud achieves the same effect by uploading those resources to the server environment. Either way, the client opens the workbook and everything works without any local setup. That makes C the correct approach. A is wrong because refreshing the generated latitude field doesn't reconstruct custom geocoding — it simply recalculates against whatever geocoding definitions exist on the client's machine, which won't include the proprietary zones. B avoids the problem entirely by abandoning the interactive map, but exporting a static image is a lossy workaround, not a solution. The client loses all map interactivity and filtering. D is tempting but incorrect. Importing a geocoding CSV creates a local definition on that machine — it doesn't automatically link to or repair the workbook. The client would have to manually re-import and potentially remap fields. As a study tip: whenever you see "custom resources" or "local dependencies" in a Tableau question, think .twbx — packaging is almost always the right answer.

Question 8

A company extends Tableau's city geocoding with several newly incorporated cities. Two of the new cities share the same name but are in different states. The first import includes only City, Latitude, and Longitude. Results vary depending on which state is displayed in the workbook.

How should the custom geocoding data be redesigned to support reliable disambiguation?

  1. Include State and Country context with each city, along with the corresponding coordinates. (correct answer)
  2. Keep only City and replace the two duplicate names with a single averaged coordinate.
  3. Remove the coordinate columns and allow Tableau to infer each city from its state abbreviation.
  4. Convert the city names to aliases that contain state names while retaining one coordinate per alias.
Explanation: When working with custom geocoding in Tableau, the core challenge is disambiguation — giving Tableau enough context to uniquely identify each location. Tableau's geocoding hierarchy works from broader to narrower: Country → State/Province → City. When you import custom geocodes, you need to mirror that hierarchy so Tableau can match records unambiguously. Answer A is correct because including State and Country alongside each city gives Tableau the full geographic context needed to distinguish two cities that share the same name. When your data contains both the city name and its state, Tableau can correctly resolve "Springfield, IL" versus "Springfield, MO" without guessing — which eliminates the inconsistent results described in the scenario. Answer B fails because averaging the coordinates of two geographically distinct cities produces a fabricated location that represents neither city accurately. You'd be destroying real geographic data rather than solving the disambiguation problem. Answer C is flawed on two levels: it removes the coordinates entirely (defeating the purpose of custom geocoding, which exists precisely because Tableau can't infer these new cities on its own) and assumes Tableau will correctly deduce a city from a state abbreviation alone — which it won't for cities not already in its internal database. Answer D introduces aliases that embed state names into city labels, which is a workaround rather than a proper geocoding structure. Aliases also don't provide coordinates in a way Tableau's custom geocoding import process recognizes as hierarchical, making this approach unreliable and non-standard. The key study tip: whenever a geocoding question involves duplicate place names, your instinct should be to add geographic hierarchy, not manipulate the names or coordinates themselves.

Question 9

A text field named Office Location contains valid city names, but it displays the Abc icon in the Data pane. After the field is added to a worksheet, Tableau creates a text view rather than a map. The data source also contains a Country field.

What should the analyst do first, and what might be required next?

  1. Assign Office Location the City role, then use Country as context if city names remain ambiguous. (correct answer)
  2. Import Office Location as custom geocoding, then convert Country to a continuous measure.
  3. Assign Office Location the State/Province role, then hide any values reported as unknown.
  4. Convert Office Location to a measure, then place Country on the map's Detail property.
Explanation: When Tableau displays the Abc icon next to a field, it means the field is treated as a string dimension with no geographic role assigned — which is exactly why dropping it on a view produces text instead of a map. Your first instinct should be: does this field need a geographic role? For city-level data, the fix is to right-click the field, select Geographic Role → City. This tells Tableau's geocoding engine how to interpret the values. However, city names are notoriously ambiguous — "Springfield" exists in dozens of countries and states — so Tableau may fail to resolve some locations correctly. That's where the Country field becomes valuable: assigning it as a contextual filter or placing it in the view helps Tableau disambiguate which city belongs to which country. Answer A correctly captures this two-step reality: assign the role first, then use Country to resolve ambiguity. Answer B is wrong because custom geocoding is only necessary when your locations aren't in Tableau's built-in geocoding database (e.g., fictional regions or proprietary territories). Valid city names don't require it, and converting Country to a continuous measure makes no geographic sense. Answer C is wrong because assigning the State/Province role to city data would cause widespread mismatches — cities and states are distinct geographic levels. Hiding unknown values doesn't fix a misclassified role; it just conceals the error. Answer D is wrong because geographic fields should remain dimensions, not measures. Converting a city field to a measure strips it of its geographic meaning entirely. Study tip: On Tableau exam questions, the Abc icon is a signal that a geographic field is unrecognized — always look for geographic role assignment as your first corrective step.

Question 10

A map reports St. Louis Cty as an unknown location. In the source system, this label must remain unchanged because it is used by other applications. Tableau's Edit Locations dialog offers St. Louis County as a valid matching location.

What is the most appropriate workbook-level resolution?

  1. Import a new custom geographic role containing every county in the source data.
  2. Exclude St. Louis Cty from the view and enable the option to show data at default position.
  3. Assign the City geographic role because Tableau does not recognize abbreviated county names.
  4. Match St. Louis Cty to St. Louis County in Edit Locations without altering the source value. (correct answer)
Explanation: When Tableau encounters a location name it can't geocode — like an abbreviation or typo — it flags it as "unknown" on the map. The key concept here is that Tableau provides a workbook-level fix called Edit Locations, which lets you manually map an unrecognized label to a known geographic entity without touching the source data. That's exactly the constraint this question is testing: the source value must stay intact because other applications depend on it. Option D is correct because Edit Locations creates an internal alias within the workbook, telling Tableau "when you see St. Louis Cty, treat it as St. Louis County." The map renders correctly, the source data remains "St. Louis Cty," and no other systems are affected. It's precise, non-destructive, and scoped to the workbook. Option A is a significant overreach — importing a custom geographic role for every county is a heavyweight solution designed for entirely new geographic hierarchies that Tableau doesn't recognize at all, not for a simple name mismatch when a valid match already exists in Edit Locations. Option B is counterproductive. Excluding the location from the view means you're hiding data rather than resolving the problem. "Show data at default position" places unmatched points at a generic coordinate, which is inaccurate and misleading — not a real fix. Option C reflects a misunderstanding of geographic roles. The issue isn't the role type (it's already a county); it's the label mismatch. Switching to City would assign the wrong geographic level entirely. Study tip: When a question mentions that source data cannot be changed, immediately think Edit Locations — it's Tableau's purpose-built, workbook-only geocoding override.