Hands-on exercise sets for all eight Compendium volumes, using free resources wherever possible, plus two capstone project specs with self-assessment rubrics.
These five exercises put the ideas from Volume A into your hands. Everything here runs on a free ArcGIS public account and data from the Living Atlas or data you create yourself in Map Viewer. No organizational account, no ArcGIS Pro, no credits. Where a concept is taught in depth in the Compendium, this workbook cross-references the chapter rather than re-teaching it; do the reading first if a step feels unfamiliar.
Work the exercises in order. Each one builds an instinct the next one leans on: how the world becomes data, how the flat map lies about the round earth, how styling choices manufacture stories, how to interrogate a stranger's data, and how to spot and repair a bad map.
Objective: Decide, and then verify against real layers, whether five real-world phenomena are best represented as vector points, lines, polygons, or as rasters.
What you need: A free ArcGIS public account, Map Viewer, and Living Atlas search. Background: Compendium Chapter 1 (How GIS Thinks) and Compendium Chapter 5 (Finding Data).
Steps:
Add > Browse layers and switch the source to Living
Atlas.Success criteria: You can state, for each of the five phenomena, which model the real published layers use, and you can explain the two cases where scale changed the answer (rivers and cities). If your explanation includes the words "discrete" and "continuous" used correctly, you have the core of Chapter 1 internalized.
Stretch goal: Find one phenomenon that genuinely resists both models cleanly, such as a wetland boundary or a wildfire perimeter, and write three sentences on what is lost by forcing it into a polygon.
Objective: Demonstrate projection distortion yourself by proving that two regions that look wildly different in size on the default basemap are actually comparable on the ground.
What you need: A free ArcGIS public account and Map Viewer's measurement tools. Background: Compendium Chapter 3 (Coordinate Systems and Projections).
Steps:
Success criteria: Your measured Africa-to-Greenland ratio should be dramatically larger than your on-screen visual estimate — by an order of magnitude in the difference of impressions. If your measured ratio came out close to your visual guess, your traces were too rough or you measured planar rather than geodesic values; retrace more carefully.
Stretch goal: Search Living Atlas or ArcGIS Online for a basemap or web map built on an equal-area or polar projection (they exist, though the default catalog leans Mercator), open it, and describe how the same two landmasses compare there.
Objective: Restyle one choropleth layer four ways and observe how classification method, class count, and color choices change the apparent story without changing a single data value.
What you need: A free ArcGIS public account, Map Viewer, and one Living Atlas demographic layer with a numeric attribute, such as a census or American Community Survey layer of income or population by county. Background: Compendium Chapter 7 (Styling and Smart Mapping) for the mechanics and Compendium Chapter 4 (Cartographic Design) for the judgment.
Steps:
Success criteria: You produce four visibly different maps from one unchanged attribute, and your four headlines genuinely differ in what they claim about the region. If two of your maps look the same, your data may be too uniform; switch to a more skewed attribute and rerun.
Stretch goal: Add a fifth version using an unclassed (continuous) color ramp and explain in three sentences why unclassed styling is more honest for some audiences and less readable for others.
Objective: Evaluate the fitness of a layer you did not make, using only its item page and its behavior in the map, and issue a written verdict on whether you would trust it for real work.
What you need: A free ArcGIS public account and the ArcGIS Online search. Background: Compendium Chapter 5 (Finding Data).
Steps:
Success criteria: Your scorecard has an explicit pass/fail/unknown for every question in step 2, and your verdict names at least one concrete defect or gap you found in step 4 or 5. Finding zero issues usually means the spot check was too gentle, not that the layer is perfect; check three more places.
Stretch goal: Repeat the same scorecard against the authoritative or Living Atlas equivalent and note which questions even well-curated layers leave unanswered.
Objective: Deliberately commit five classic cartographic sins in one map, then fix them one at a time so you can articulate exactly what each sin does to the reader.
What you need: A free ArcGIS public account, Map Viewer, and a county- or tract-level demographic layer from Living Atlas with both a raw count field (total population) and something to normalize by (area or households). Background: Compendium Chapter 4 (Cartographic Design), with styling mechanics from Compendium Chapter 7 (Styling and Smart Mapping).
Steps:
Success criteria: A stranger shown only the After map can state its main pattern in one sentence without prompting, and your sin-by-sin notes identify raw-counts-in-choropleth as the most serious of the five, since it misleads even careful readers rather than merely slowing them down.
Stretch goal: Make a third version tuned for a different audience, such as a colorblind-safe version with a ramp chosen for deuteranopia, and note which of your fixes survived unchanged.
If these exercises felt comfortable, you are ready for Volume B: Exercise 3 and 5 lead directly into Compendium Chapter 7 (Styling and Smart Mapping) and Compendium Chapter 9 (Pop-ups, Fields, and Labels), and the skeptical habits from Exercise 4 are the working posture for Compendium Chapter 10 (Hosted Feature Layers) when you start publishing layers of your own that strangers will interrogate right back.
These five exercises drill the skills taught in Compendium Chapters 6 through 10: the Map Viewer, smart mapping, Arcade, pop-ups, and hosted feature layers. Work them in order — each one builds on the map you made in the last. Exercises 1 through 4 need nothing more than a free ArcGIS public account and the Living Atlas. Exercise 5 requires publishing privileges; if you don't have them, a read-along alternative is included so you still get the mental model. If you're unsure which kind of account you have, Compendium Chapter 2 (The ArcGIS Ecosystem) explains the account types.
One rule for the whole workbook: when a step doesn't work the way you expect, don't click randomly. Stop, name what you expected, and find the panel that owns that behavior — knowing which panel owns what is most of Map Viewer fluency.
Objective: Build and save a web map that deliberately touches every major Map Viewer panel, so you know where everything lives without hunting.
What you need: A free ArcGIS public account, signed in at arcgis.com. Living Atlas access is built in.
Steps:
Add > Browse layers, switch the source to
Living Atlas, and search for a county-level demographic boundary layer —
one of Esri's American Community Survey (ACS) boundary layers works well
because it's polygon data with lots of numeric fields. Add it.
(Compendium Chapter 5 covers judging what you find; here, an
Esri-published ACS layer is a safe pick.)Save > Save as with a real title, at least
three tags, and a one-sentence summary. Then find the map's item page
from your Content list and skim what got recorded there.Success criteria: Sign out, sign back in, and reopen
the map from Content. The filter, labels, transparency,
bookmarks, and renamed layer all persisted. Without opening the app, you
can say from memory which panel owns filtering, which owns labels, and
which owns effects.
Stretch goal: Add a second Living Atlas layer, group the two layers, and set staggered visible ranges so one hands off to the other as you zoom — a generalized layer far out, a detailed one close in.
Objective: Style the same numeric field five different ways and judge, for each, what it shows honestly and what it hides.
What you need: The map from Exercise 1 (or a fresh map with the same kind of county-level ACS polygon layer). You need one raw count field (total population works) and either an area field or a second count to normalize by.
Steps:
Success criteria: You can state, for each of the five styles, one thing it communicates well and one thing it distorts or hides. Your saved map keeps the style you judged best — and if that's a color style, it's the normalized one.
Stretch goal: Try the Relationship (bivariate) style with two related fields, and the combined Color and Size style. Decide whether either earns its added reading difficulty for your question. Chapter 7 (Styling and Smart Mapping) explains when multivariate styles pay off.
Objective: Write three attribute expressions — a formatter, a classifier, and a guarded calculation — and wire each into the layer's pop-up.
What you need: The same map and layer, with at least two numeric fields you understand (a total and a subgroup count is ideal). Compendium Chapter 8 (Arcade from Zero to Fluent) is the companion text; this exercise is its gym.
Steps:
Open the pop-ups panel for the layer and find where attribute
expressions are managed. Create a new expression and take stock of the
editor: the $feature profile variable, the function
reference, the field list, and a way to test the expression against a
real feature. Testing after every change is the habit to build.
Expression 1 — the formatter. Raw counts display
like 1083459. Return a readable string instead:
Text(Round($feature.YOUR_COUNT_FIELD), '#,###')Replace the field name using the editor's field list rather than typing it — field names in ACS layers are not guessable. Test it, name the expression "Population (formatted)", and save.
Expression 2 — the classifier. Bucket a numeric
value into named tiers using When:
var v = $feature.YOUR_COUNT_FIELD;
When(
v >= 500000, "Large",
v >= 100000, "Mid-size",
v > 0, "Small",
"No data"
)Adjust the thresholds to fit your field's actual range (check the styles pane histogram for sensible breaks). Test it against a big county, a small one, and — important — one where the field might be empty.
Expression 3 — the guarded calculation. Compute a subgroup's share of the total, and refuse to divide by zero or null:
var part = $feature.SUBGROUP_FIELD;
var total = $feature.TOTAL_FIELD;
IIf(total > 0, Round(part / total * 100, 1), null)Returning null on bad input is deliberate: the pop-up
shows nothing instead of Infinity or an error. Test on
several features.
Add all three expressions to the pop-up's content and click around the map to see them in real use.
Success criteria: Clicking any feature shows a
thousands-separated population, a tier name that matches the county's
obvious size, and a percentage between 0 and 100 — with no error text,
Infinity, or NaN on any feature you can find,
including sparse ones.
Stretch goal: Rewrite the classifier using
Decode and decide which reads better. Then move a copy of
the classifier out of the pop-up entirely: use it as an expression-based
style in the styles pane, so the map itself colors by your tiers.
Objective: Replace the default wall-of-fields pop-up with a designed one: a title that reads like a sentence, a text block that speaks plainly, and a chart that compares related fields.
What you need: The same map. Pick a set of related numeric fields that make a fair comparison — age brackets, income brackets, or similar breakdown fields in an ACS layer. Compendium Chapter 9 (Pop-ups, Fields, and Labels) is the reference; this is the practice.
Steps:
{NAME} County — {expression/...} pulling in
your formatted population from Exercise 3. The title should deliver the
single most important fact by itself.{field} placeholders and your Exercise 3 expressions inline
— for example: "About X% of residents here fall in the selected group,
making this a Tier county." Prose with live values beats twenty
labeled rows.Success criteria: A stranger clicking any county learns the headline fact within a few seconds without decoding a field name. The chart renders sensibly on every feature you test, and nothing in the pop-up shows a raw machine-readable field name.
Stretch goal: Configure number formatting (separators, rounded digits) on any remaining listed fields, and add an image or an Arcade element block to see what richer pop-up content looks like. Then compare your pop-up to the same layer's default in a fresh map — keep the before/after as your own proof of skill.
Objective: Publish a small hosted feature layer of your own, create a view layer from it, watch an edit flow from source to view, and use the view to hide fields and share safely.
What you need — read this first: This exercise requires an account that can publish hosted feature layers: an organizational account with a publishing role, or a free developer-tier account if one is available to you. A free public account cannot publish hosted layers. If that's you, skip to the read-along alternative at the end of this exercise — the mental model matters more than the clicks.
Steps:
name, category (two distinct values, e.g.
"cafe" and "park"), rating (a number),
latitude, longitude. Real-world familiarity
makes verification instant. (Compendium Chapter 11 covers data-creation
paths; Chapter 12 covers doing schema properly.)Content > New item, add the CSV from your
computer and choose to publish it as a hosted feature layer. At the
field-configuration step, confirm rating is numeric and
location is taken from your latitude/longitude columns.rating field and
add a definition filter so the view shows only one
category. You now have a third item.Success criteria: Three items exist (file, layer, view); the view shows fewer fields and fewer rows than the source; an edit made through the source appears through the view without republishing; and the view is public while the source stays private.
Stretch goal: Create a second view with the opposite category filter — one source, two audiences. Then open the REST endpoint URLs of the source layer and the view from their item pages and compare them (Compendium Chapter 32 explains what you're looking at).
Read-along alternative (public accounts): Open any Esri-published hosted feature layer item from Living Atlas and walk its item page — overview, data tab, and whatever settings a viewer can see. As you read the steps above, map each onto what you're looking at: publishing creates an item plus a live service; a view is a second service over the same stored data with its own field visibility, filters, and sharing; edits happen in the shared data, so every view sees them. When you later get publishing privileges, the drill will take minutes because the model is already in place.
You've now run the whole Volume B loop: find data, style it defensibly, compute what the data doesn't store, present it clearly, and control who sees what. Volume F (Chapters 26 through 30) is where these maps become apps; the map you built here is a ready input to that work.
These five exercises walk the full life of a dataset: create data from nothing, give it structure, draw it by hand, deliberately damage it, then run the review loop that catches the damage. They exercise Compendium Chapter 11 (Creating Data), Chapter 12 (Schema Design), Chapter 13 (Editing Workflows), and Chapter 14 (Data Quality); when you get stuck on a concept, go back to the chapter and return here.
All five exercises share one scenario: a street-tree inventory for a park or a few blocks near where you live. Real trees you can see on the basemap make every step concrete, and each exercise feeds the next, so do them in order.
You need a free ArcGIS public account (sign up at arcgis.com), a spreadsheet program or text editor, and a folder for the files you will make. Two steps require an organizational account and are flagged where they occur, each with a read-along alternative. Nothing requires ArcGIS Pro except stretch goals, which say so.
ArcGIS Online's interface shifts between releases, so steps are written at the level of intent. If a named button has moved, look for the same goal in the same area, or check Compendium Chapter 6 (Map Viewer Complete Reference) for the current layout.
Objective: Create a location table by hand and bring it into a map by the coordinate path and the address path, so you understand what each path needs and where each one fails.
What you need: A free public account, a spreadsheet or text editor, and Map Viewer. The address path's batch geocoder is a chargeable organizational service; if you only have a public account, read that branch and do the manual workaround in step 6 instead.
Steps:
trees_coords.csv in your editor with columns
tree_id, latitude, longitude,
species_guess, notes, and one row per tree.
Keep latitude and longitude as plain decimal numbers, negative for the
southern and western hemispheres. This is the coordinate path from
Compendium Chapter 11: the table already knows where everything is.trees_addresses.csv, delete the coordinate columns, and add
an address column with the nearest street address for each
tree, plus city and postal code columns. If you have an organizational
account, add this file the same way and let the geocoder locate the
rows; watch how it reports match quality, and inspect any row it placed
with low confidence.Success criteria: Both layers display; the coordinate-path points sit on the actual tree canopies in the imagery; you can state, in one sentence each, what the coordinate path requires that the address path does not, and vice versa.
Stretch goal: Add a sixth row with a deliberately malformed address (misspelled street, wrong postal code) and observe what the geocoder or the search box does with it. Bad-match behavior is the thing that bites real projects.
Objective: Turn the ad-hoc CSV from Exercise 1 into a designed schema with field types, coded value domains, and a data dictionary you could hand to another person.
What you need: A spreadsheet or text editor. This exercise is design work first; applying the schema to a live hosted layer needs an organizational account, and that branch is flagged in step 5.
Steps:
condition domain (for example Good, Fair, Poor, Dead), a
species domain from the species actually present in your
area, maybe an inspection_status domain. For each domain,
write both the stored code and the human-readable label. Ask of every
text field: would free typing here create garbage? If yes, it wants a
domain.Success criteria: A written data dictionary of eight to twelve fields, at least two coded value domains with codes and labels, one range constraint with reasoning, and three complete records entered without a single judgment call the dictionary could not answer.
Stretch goal: Add a second table for inspections,
one row per visit, related to trees by tree_id, and write
down why repeated inspections belong in a related table instead of extra
columns. Compendium Chapter 12 treats relationships in depth.
Objective: Draw ten connected features by hand with snapping turned on, so shared edges and endpoints actually coincide instead of merely looking close.
What you need: A free public account and Map Viewer. Use a sketch layer, which you can create without any org privileges; if sketch layers are unavailable in your setup, an editable hosted layer (org account) works identically, and Compendium Chapter 13 (Editing Workflows) covers both.
Steps:
Success criteria: Ten features exist; at maximum zoom, every intended junction shows coincident geometry with no visible gap or crossing; you can point at one junction where you saw the snap cue engage and can say what it snapped to.
Stretch goal: Turn snapping off and draw one extra line connecting two features, as carefully as you can. Zoom in on its endpoints and compare with your snapped work. Keep the bad line; Exercise 4 wants it.
Objective: Deliberately introduce duplicate features and sliver gaps, then detect all of them using inspection techniques rather than memory.
What you need: The map from Exercise 3 and the CSV from Exercise 1. All free. Rule-based topology validation is ArcGIS Pro territory (Compendium Chapter 14, Data Quality, covers it); here you do the manual version, which is also the version you can do anywhere.
Steps:
tree_id: a duplicate record at
identical coordinates. Then add another row whose coordinates differ
from an existing tree's by a tiny amount in the last decimal place: a
near-duplicate, the kind field crews create by collecting the same tree
twice.Success criteria: Your hunt list matches your answer key exactly, every planted defect is repaired, and re-running the transparency pass and table sort turns up nothing new.
Stretch goal: If you have ArcGIS Pro, load the same features into a file geodatabase, build a topology with a no-gaps and a no-overlaps rule, and validate. Compare what the rules caught against what your eyes caught.
Objective: Put everything from Exercises 1 through 4 through one formal review cycle: checklist, findings log, fixes, and a verification pass by a second set of eyes.
What you need: Everything you have built so far, a spreadsheet for the QA log, and ideally one other person with a free account; a solo alternative is built into the steps.
Steps:
tree_id values; every domain-constrained value is from the
domain list; every junction is snapped at close zoom; no slivers under
transparency; no empty required fields; notes are intelligible to a
stranger. Binary means each check is pass or fail, never "mostly."Success criteria: A completed QA log where every finding reached verified status, and a three-sentence retrospective that names at least one upstream change rather than blaming individual mistakes.
Stretch goal: Run the loop a second time a week later after adding five new trees without looking at your checklist while collecting. Count findings per feature for the new batch versus the old. If the number dropped, the process improved you; that is the metric that matters.
You have now touched every stage Volume C describes: creation paths, structure and constraints, editing mechanics, and quality practice. The natural continuation is publishing this inventory as an editable hosted feature layer for a field device: Compendium Chapter 10 (Hosted Feature Layers) plus Chapter 30 (Field Maps, Survey123, QuickCapture), with the full worked pipeline in Compendium Chapter 37 (Worked Project - Field Collection).
These five exercises put the tools from Volume D (Compendium Chapters 16 through 20) into your hands. One honest note before you start: most spatial analysis tools in ArcGIS Online sit behind an organizational account with analysis privileges, and several of them consume credits (Compendium Chapter 2, The ArcGIS Ecosystem). Every exercise below tells you up front which parts need those privileges and gives you a free path: either a manual version built on the Map Viewer measurement and sketch tools, or a paper version where you reason through the same logic. The manual versions are not consolation prizes. Working a buffer question by hand teaches you what the tool actually computes better than clicking Run ever will.
For all five exercises, a free ArcGIS public account is enough to open Map Viewer, add Living Atlas layers, style them, measure, sketch, and save a map. Finding good layers is covered in Compendium Chapter 5 (Finding Data); Map Viewer mechanics are Chapter 6.
Objective: Answer a concrete proximity question, "How many schools in my county are within one mile of a major highway?", using Buffer and Summarize Within, and report the answer in a sentence a non-GIS person can trust.
What you need: Map Viewer and two Living Atlas layers: a point layer of schools and a line layer of major roads or freeways covering your area (search the Living Atlas for both; national coverage exists for the United States, and most countries have equivalents). The tool path needs an org account with spatial analysis privileges and a small credit cost. The free path needs only the measurement tool.
Steps:
Analysis > Tools and run the buffer
tool (Create Buffers) on the filtered roads layer at one mile, with the
dissolve option on. Dissolving matters: without it, overlapping buffers
around adjacent road segments would let one school be counted several
times.Free path: shrink the question to one town. Add the same two layers, open the measurement tool from the map tools, and check each school in town against the nearest highway by measuring. Tally by hand. Same logic, smaller extent, zero credits.
Success criteria: The buffer draws as a continuous ribbon along the roads, not a pile of stacked shapes. The count survives a spot check: pick three schools sitting near the buffer edge, measure each one's distance to the road, and confirm the tool classified them the way your measurements say it should. Your written answer names the dataset and the distance.
Stretch goal: Rerun at half a mile and at two miles. The count will not scale linearly with distance. Explain why in two sentences, using what Chapter 16 says about how buffered area grows and how features cluster along corridors.
Objective: Run the same join with different match options and explain, for one specific county, why the resulting counts differ.
What you need: A county boundaries polygon layer and a rivers or streams line layer from the Living Atlas, filtered to your state. The tool path uses Join Features, which needs analysis privileges. The paper alternative needs a pencil.
Steps:
Paper alternative (no privileges needed): Draw three adjacent counties and two rivers, one contained entirely in a county and one crossing all three. Build the count table for intersects and for completely within by hand. The whole lesson fits on an index card.
Success criteria: Intersects counts are never smaller than completely-within counts, and you can name one specific river responsible for the difference in one specific county.
Stretch goal: Rerun the intersects version as a one-to-many join and look at the result's table. Explain what happened to the number of rows and why one-to-many output is the wrong input for a choropleth map but the right input for a table of county-river pairs.
Objective: Produce a hot-spot analysis and write an interpretation paragraph that claims only what the statistics actually support.
What you need: A polygon layer carrying both a count-style field and a population field; the American Community Survey layers in the Living Atlas work well (tract or county level). The tool path uses Find Hot Spots, which needs analysis privileges and credits. The free path uses only smart mapping.
Steps:
Free path (no privileges): You cannot compute the statistic, but the core lesson survives. Style the count field and the rate field with smart mapping (Chapter 7) in two copies of the map and compare where each draws the eye. Then write the same four-part paragraph about the visual pattern, replacing the significance language with an honest statement that no significance test was run.
Success criteria: The count map and the rate map disagree somewhere, and you can say why. Your paragraph contains zero causal language, states the aggregation unit, and includes at least one alternative explanation.
Stretch goal: Rerun (or re-style) at a different aggregation level, counties instead of tracts, and note where conclusions change. You have just demonstrated the modifiable areal unit problem; name it, and check its entry in Compendium Chapter 40 (Mega-Glossary).
Objective: Show, for a real location, where a straight-line buffer overstates access, and quantify the gap.
What you need: A point of interest near a barrier: a fire station, library, or grocery store close to a river, rail corridor, or limited-access highway. The tool path needs an org account with network analysis privileges, because travel areas call a network service and consume credits (Chapter 2). The free manual path needs only the measurement tool and is genuinely the more instructive version.
Steps (tool path):
Steps (free manual path):
Success criteria: You found at least two locations where road distance is more than double the straight-line distance, and you can name the barrier for each. Your write-up states which question each shape answers: the circle answers "as the crow flies," the travel area answers "as the car drives."
Stretch goal: Reason about time instead of distance. A location across a freeway interchange can be close by road distance yet slow at rush hour. Write two sentences on when you would insist on a time-based travel area with traffic, using Chapter 18's treatment of travel modes.
Objective: Design and execute a small weighted suitability model by hand, so you understand exactly what the raster overlay tools in Compendium Chapter 19 automate.
What you need: Paper or a spreadsheet, plus Map Viewer with the imagery basemap and the measurement tool. No analysis privileges, no Pro, no credits. If licensing has blocked you out of every tool so far, this exercise is your equalizer: it is the full suitability workflow with your brain as the geoprocessor.
Steps:
Success criteria: A complete table of sites by criteria with scores, weights, and totals; a declared winner; and one sentence stating whether the ranking survived the sensitivity test. If the winner flips on a modest weight change, your honest conclusion is "it depends on priorities," which is a real and useful finding.
Stretch goal: Identify the criterion that was hardest to score consistently and rewrite its scale so two different people would assign the same score. If you have access to ArcGIS Pro, rebuild the model with distance rasters, reclassification, and weighted overlay following Chapter 19, and compare the software's answer to your paper one.
You have now run, or hand-simulated, the four workhorse patterns of Volume D: buffer-and-summarize, spatial join, statistical pattern detection, and multi-criteria overlay, plus the network-versus-Euclidean distinction that separates careful proximity work from lazy circles. The worked projects in Compendium Chapters 36 and 37 chain these same moves into complete deliverables; the recipes in Chapter 38 give you compressed versions to adapt. When a result looks wrong, start with Chapter 39 (Troubleshooting Encyclopedia) before assuming the tool lied. It almost never did; the inputs usually did.
This workbook turns Volume E into hands-on practice. Every exercise here requires ArcGIS Pro on a Windows machine — there is no browser workaround for the desktop application itself. If you do not have Pro, you have two honest options: get a time-limited free trial or a low-cost personal-use license (Compendium Chapter 2, The ArcGIS Ecosystem, explains the licensing paths), or read along. Each exercise includes a read-along alternative that tells you what to watch for so the material still sticks.
No paid data is used anywhere. Everything comes from the Living Atlas (Compendium Chapter 5, Finding Data) or from data you create during the exercise. Work through the exercises in order — Exercise 2 reuses the project from Exercise 1, and Exercises 4 and 5 reuse the map from Exercise 3.
Objective: Build a Pro project whose structure you could hand to a stranger — or to yourself in six months — without an apology email.
What you need: ArcGIS Pro with any license level. No org account needed; you can sign in with a Pro license and still complete this exercise entirely locally. Read-along alternative: study the project anatomy section of Compendium Chapter 21 (Pro Interface and Projects) and sketch on paper what folders and files a new project creates.
Steps:
GIS-Practice folder with a
subfolder for this workbook. The discipline starts outside the software:
projects that get dumped into default locations are projects that get
lost.MyProject1, and leave "create a folder for this project"
checked so everything nests cleanly.View > Catalog Pane) and
inspect what Pro made for you: a project file, a default file
geodatabase, and a default toolbox. Right-click each and read its
properties. Understand that the geodatabase is where your outputs will
land unless you say otherwise — this default matters constantly in
Exercise 2.Insert > Connections > Folder > Add Folder Connection)
to one other location you actually use, and deliberately do not add
connections to your entire drive. A project with three meaningful
connections is navigable; one with fifteen is noise.Map > Add Data, then browse the Living Atlas section)
so the map is not empty.Success criteria: The reopened project loads with no broken data sources (red exclamation marks) for anything stored inside the project folder. You can explain, without looking, where a new geoprocessing output would land by default and why.
Stretch goal: Create a second project from the
Catalog template instead of the Map template, compare what each template
gives you, and decide which you would make your personal default. Then
explore Project > Options and set your default project
location so future projects start disciplined automatically.
Objective: Run a four-tool geoprocessing chain manually, then rebuild it as a reusable model and prove both produce identical results.
What you need: The project from Exercise 1, plus two Living Atlas layers that overlap: one polygon layer (a counties or administrative-boundaries layer works well) and one line layer (rivers, railroads, or major roads). Any overlapping polygon-and-line pair works — the chain is the point, not the data. Read-along alternative: Compendium Chapter 22 (Geoprocessing in Depth) walks the same tools conceptually, and Chapter 25 (ModelBuilder) shows a finished model; trace the data flow with a pencil.
Steps:
Map > Selection > Select By Attributes, then export
the selection to your project geodatabase (right-click the layer, then
look for the export or copy-features option). Working from a local copy
keeps the rest of the chain fast and keeps you from hammering a shared
service — Compendium Chapter 10 (Hosted Feature Layers) explains why
that courtesy matters.Analysis > Tools), letting each output land in the
project geodatabase: first Dissolve your exported polygons into a single
study-area boundary; second, Clip the line layer to that boundary;
third, Buffer the clipped lines at a distance that makes sense for your
data; fourth, use a select-by-location or an overlay tool to find which
of your original polygons intersect the buffer. Compendium Chapter 16
(Proximity and Overlay) covers what these tools actually compute — do
not re-derive that here, just run them deliberately.Analysis > History) and read the parameters it
recorded. This history is your lab notebook; the whole exercise fails
silently if you skip it.Steps continued — the comparison: Open the attribute tables of the manual final output and the model final output side by side.
Success criteria: Feature counts match exactly between the manual run and the model run, and rerunning the model with a different region parameter completes without edits to the model itself. If counts differ, the history pane will show you which parameter diverged — that diagnosis is the real lesson.
Stretch goal: Expose the buffer distance as a second model parameter, then run the model as a geoprocessing tool from the pane rather than from the model canvas. If you want to go further, Compendium Chapter 31 (Python for ArcGIS) shows how to export the same chain to a Python snippet from the history pane.
Objective: Reproduce another cartographer's map styling closely enough that a side-by-side comparison takes effort to tell apart.
What you need: Pro, plus a reference map: browse the Living Atlas in a web browser and pick a published web map with a graduated-color (choropleth) polygon style you like — demographic maps are plentiful and free. Keep it open in the browser as your answer key. Add the same or a similar polygon layer to a new map in your Pro project. Read-along alternative: Compendium Chapter 23 (Symbology and Labeling) with the reference web map open beside it; for each styling choice in the web map, find the Pro control that would produce it.
Steps:
Success criteria: At matching extents, a person glancing at both maps for five seconds cannot immediately say which is which. Class breaks land on the same values or defensibly close ones, and you can articulate every deliberate deviation you kept.
Stretch goal: Save your recreated symbology as a style or layer file so it is reusable, then restyle the same layer with an unclassed color scheme and write two sentences on which communicates the data more honestly — Compendium Chapter 4 (Cartographic Design) gives you the evaluation vocabulary.
Objective: Build a print-quality layout with a main map and an overview locator, then convert it into a map series that generates a page per feature automatically.
What you need: Pro and the styled map from Exercise 3, whose polygon layer will double as the map series index. Read-along alternative: Compendium Chapter 24 (Layouts and Map Series) covers every element used here; sketch the two-frame layout on paper and annotate which properties each element needs.
Steps:
Insert > New Layout) at a
standard page size in landscape. Add a map frame covering roughly the
right two-thirds of the page, pointed at your Exercise 3 map.Success criteria: Paging through the series changes the main frame's extent and the title with zero manual edits, the locator's extent indicator tracks correctly on every page, and no element overlaps or clips on the two pages you chose.
Stretch goal: Add dynamic text that reports an attribute value from the current index feature (a population figure, an area), so each page carries its own statistic. Then adjust the series' extent behavior — the margin or scale rounding around each feature — and compare fixed-scale pages against best-fit pages.
Objective: Export the same layout under several settings profiles and learn, from evidence, which settings matter for size, quality, and downstream use.
What you need: Pro and the finished layout from Exercise 4. A PDF reader and any image viewer for inspection. Read-along alternative: the export section of Compendium Chapter 24, plus this exercise's comparison table drawn from its description — predict the winners before reading on.
Steps:
Share > Export Layout, export the current page
as a PDF at a deliberately low resolution setting, then again at a high
one. Keep every other setting identical.Success criteria: You can point at the largest and smallest files and explain why each landed there, and you can demonstrate one export where text stays selectable and one where it does not.
Stretch goal: Use the map series export options to export both of your Exercise 4 pages into a single multi-page PDF, then compare its size against the sum of two single-page exports. Then export one page at a physically larger page size versus a higher resolution and decide which lever actually bought you more usable detail.
If these five exercises felt comfortable, the two worked projects in Compendium Chapters 36 and 37 chain these same skills into end-to-end builds, and Chapter 38 (Cookbook) gives you forty more reps in smaller bites. If ModelBuilder was the exercise that clicked, Chapter 31 (Python for ArcGIS) is the natural escalation.
These five exercises put the Volume F chapters to work: Instant Apps (Compendium Chapter 26), StoryMaps (Chapter 27), Dashboards (Chapter 28), and the field apps (Chapter 30). Exercises 1 and 2 are fully doable with a free public ArcGIS account. Exercises 3 and 4 need an organizational account — each includes a read-along alternative so you still get the reasoning practice without one. Exercise 5 needs nothing but this page. Before you start, build one reusable asset: a web map you will carry through the first three exercises. If you have not made a web map before, work through Compendium Chapter 6 (Map Viewer Complete Reference) first.
Objective: Publish the same web map through three different Instant Apps templates and articulate, in writing, which template fits which audience and why.
What you need: A free public ArcGIS account. A web map you build in this exercise from a Living Atlas layer — no uploads, no publishing privileges. If a particular template is not offered to your account type, read along for that one and configure the other two.
Steps:
Create app > Instant Apps. Browse the template gallery
and read the stated purpose of each template before touching anything.
Note how the gallery describes each one in terms of audience task, not
features.Success criteria: You have three working app URLs driven by one web map. Your notes name a distinct primary audience for each template, and you can state one task where each template beats the other two. If your three write-ups sound interchangeable, you configured too much and homogenized them — reset one to defaults and look again.
Stretch goal: Pick the template you judged the worst fit for your map and try to redeem it: change the map (not just app settings) until that template works. Notice how much of "app fit" is really "map design fit" — a lesson Chapter 26 states and this exercise proves.
Objective: Build a short, complete story that uses exactly five block types, including one sidecar with working map actions.
What you need: A free public ArcGIS account (sign in at the ArcGIS StoryMaps site). The web map from Exercise 1. One or two images you own or that are openly licensed.
Steps:
Success criteria: The published story reads top to bottom in a few minutes with no dead blocks. Every map action, when clicked, visibly changes the map. A friend who knows nothing about GIS can tell you what the story's point was — if they describe the map instead of the point, your text blocks are captions, not narrative.
Stretch goal: Duplicate the story and rebuild the sidecar in the floating layout instead of docked. Compare scroll feel on a phone. Write one sentence on when you would choose each layout.
Objective: Build a dashboard where two selectors filter the map and at least one data element, so a viewer can slice the data without touching the map.
What you need: An organizational account with app creation privileges — public accounts cannot author dashboards. A layer with at least one categorical field and one numeric or date field; a Living Atlas feature layer works, or reuse your Exercise 1 map. No org account? Read the steps anyway, then open any public dashboard you can find (search ArcGIS Online for dashboards shared publicly), interact with its selectors, and reverse-engineer which element is wired to which — write down the action mapping you infer. That analysis is most of the learning.
Steps:
Create app > Dashboards from your web map's item page.
Add the map as the first element.Success criteria: Changing either selector visibly updates the map, the indicator, and the chart; using both together narrows results further; clearing them restores the full view. If an element ignores a selector, the wiring gap is in that selector's action targets — not in the element.
Stretch goal: Add a list element wired so that selecting a row in the list flashes and pans to that feature on the map. You have now wired element-to-element actions in both directions: control-to-data and data-to-map.
Objective: Build an editable layer with a smart form where one question appears only when a previous answer requires it, and prove it works in the Field Maps mobile app.
What you need: An organizational account that can publish hosted feature layers and use Field Maps Designer, plus a phone with the ArcGIS Field Maps app installed and signed in to the same account. No org account? Read the steps, then on paper design the schema and visibility rule for this scenario: a tree-inspection form where "Pest observed?" (yes/no) controls whether "Pest type" and "Photo of damage" appear. Write the fields, domains, and the condition in plain English — that design is the transferable skill.
Steps:
Success criteria: The conditional field appears and disappears on the phone exactly per your rule, and a submitted record shows correct attributes on the desktop. If the form on the phone looks stale after edits, pull down to refresh the map in Field Maps — designers commonly forget the mobile app caches the form.
Stretch goal: Add a second condition: make severity required only when issue type is "Pothole". Then test the failure path — try to submit a pothole with no severity and confirm the form blocks you with a comprehensible message.
Objective: For five realistic field-data scenarios, choose Field Maps, Survey123, or QuickCapture, and defend each choice in two or three sentences.
What you need: Nothing but Compendium Chapter 30 fresh in your mind. No account required.
Steps:
Success criteria: Check yourself: A — Field Maps (asset-centric, revisit-and-update, navigation to existing features is the core motion). B — Survey123 (form-first with branching logic; the survey is the product, the point is metadata). C — QuickCapture (single-tap capture at speed; any form would be a safety hazard). D — Survey123 via a public link (no sign-in, no app training, works in a browser — the sharing model decides it, not the form). E — Field Maps (map-centric navigation to stations plus structured editing; a strong second answer is Field Maps launching a linked Survey123 form for the readings — if you said that, you have understood the chapter better than the exercise). You pass if at least four picks match and every justification names a deciding factor rather than a feature list.
Stretch goal: Write a sixth scenario of your own where the honest answer is "two apps working together," and specify which app hands off to which, and what data travels across the handoff.
Volume G is where ArcGIS stops being an application and starts being a system: REST services you can read like documents, Python commands you can capture and replay, and administrative decisions about who gets what. This workbook gives you five exercises to practice all three. Two run entirely in a web browser with no account at all. One needs ArcGIS Pro, with a full read-along alternative if you do not have it. Two are paper exercises, because administration is mostly thinking, and thinking is free.
Work them in order. Exercises 1 and 2 build on each other directly.
Objective: Open a live feature service's REST endpoint in a plain browser tab and extract the facts an administrator or developer would need before trusting the service.
What you need: Any web browser and the Living Atlas website (browsing requires no sign-in — see Compendium Chapter 5, Finding Data). No account, no software.
Steps:
FeatureServer — the layers hang off it as
/0, /1, and so on./0 to the URL). Now
answer, from the page alone: What is the geometry type? What is the
spatial reference WKID (Compendium Chapter 3 explains what that number
means)? What is the maximum record count the server will return per
request? Which capabilities are listed — Query only, or editing
operations too??f=pjson to the end of the layer URL and reload.
Same information, now as formatted JSON — the shape a script or app
would consume.Success criteria: Without opening any map, you can
state the layer's geometry type, its WKID, its per-request record limit,
whether it can be edited, and the names of one text and one numeric
field. You can also explain what each segment of the URL means, from the
server address down to /0.
Stretch goal: Find a second public layer from a different publisher that does allow editing. Confirm it from the Services Directory alone: the capabilities line will include editing operations, not just Query. Note anything else that differs — record limits, field counts, whether attachments are enabled.
Objective: Query a feature layer using nothing but the browser address bar, controlling the filter, the returned fields, and the output format.
What you need: The layer URL from Exercise 1, or any
public feature layer URL ending in /FeatureServer/0.
Steps:
/query to the layer URL and load it. You get an
HTML form — the server's built-in test harness for the query
operation.1=1 (which matches
everything), set the option that returns only a count, and submit. Read
the number. Then look at your address bar: every form field you touched
became a URL parameter. That URL is the API call; the form just built it
for you.where=1=1, returnCountOnly=true, and
f=json. Reload. Same count, machine-readable format.where=STATE_NAME='Texas', using your layer's
actual field name and a value you know exists. The browser will encode
spaces and quotes for you.outFields to just two field
names, add returnGeometry=false, keep f=json.
Confirm the response contains only the attributes you asked for and no
geometry.f=json for f=pjson (pretty-printed)
and then f=html, and note how the same request renders
three ways.Success criteria: You can hand-build one URL that
returns only your chosen attributes, with no geometry, for only the
features matching your filter — and you can say what every parameter in
it does. Sanity check: your filtered count should be smaller than your
1=1 count.
Stretch goal: Ask the server for a statistic instead of features. Use the query form's output-statistics input to request a count or sum grouped by a field, submit, and study the URL it builds. Check first that the layer page lists statistics support among its advanced query capabilities — not every layer has it. Compendium Chapter 32 covers statistics queries in depth.
Objective: Convert a tool you ran with mouse clicks into a line of Python you can edit and rerun — the shortest reliable path from GIS user to GIS automator.
What you need: ArcGIS Pro (any license level) with a project containing at least one feature layer; if you have none, digitize a few points first (Compendium Chapter 11 covers every path). This exercise requires Pro. If you do not have it, use the read-along alternative below — do not skip the exercise.
Steps:
Analysis > Tools, with a distance such as 500 meters.
Let it finish.Analysis ribbon
(the History button). Every tool run in this project is logged here —
this is the memory that makes capture possible (Compendium Chapter 22,
Geoprocessing in Depth).Copy Python Command.Analysis ribbon's
Python dropdown, paste, but read before you run: the tool is now a
function call in the shape arcpy.analysis.Buffer(...), and
every choice you made in the tool dialog is an argument."1 Kilometers". Notice the unit lives inside the distance
string — that is how geoprocessing passes linear units.Read-along alternative (no Pro): Study this representative captured command and answer the questions below.
arcpy.analysis.Buffer(
in_features="Schools",
out_feature_class=r"C:\Projects\Demo\Demo.gdb\Schools_Buffer",
buffer_distance_or_field="500 Meters",
dissolve_option="ALL"
)Which argument would you change to buffer a different layer? Which to write the result somewhere else? Why is the unit inside the distance string rather than a separate argument? What do you predict happens if you rerun this unchanged — and what setting governs whether the existing output is overwritten? Compendium Chapter 31 (Python for ArcGIS) answers all four; try before you look.
Success criteria: Your modified command runs without errors and produces a second, distinct output — and you can point to the argument that controls distance without opening the help.
Stretch goal: Run a second tool (for example Clip) against your buffer output, copy its Python command too, and paste both lines into the Python window in sequence so the first tool's output feeds the second tool's input. That is a two-line script — you are halfway to Compendium Chapter 31's standalone scripts and Chapter 25's models.
Objective: Produce a one-page licensing and sharing plan that gives twelve fictional staff exactly the access their work requires and nothing more.
What you need: Pen and paper or a blank document, and Compendium Chapter 34 (Administration) for the current user type and role definitions. No software, no account. This is deliberately a paper exercise: administrators commit real money and real risk with these decisions, so the design habit matters more than the clicks.
The organization — Ridgeline Water District, 12 people:
Steps:
Success criteria: Every person has exactly one user type and one compatible role; nobody holds publishing rights who never publishes; both traced flows work end to end through your groups; and you can defend every above-viewer assignment in a single sentence.
Stretch goal: A summer intern joins to help with field collection: write down what you grant and what you deliberately withhold. Then Ridgeline merges with a neighboring district's 8-person team: identify which parts of your plan scale unchanged and which need redesign.
Objective: Write a short decision memo recommending ArcGIS Online, ArcGIS Enterprise, or a hybrid for each of three scenarios, naming the deciding factor explicitly.
What you need: Compendium Chapter 35 (ArcGIS Enterprise) and Chapter 2 (The ArcGIS Ecosystem) as references; a blank document. Paper exercise — no software.
The scenarios:
Steps:
Success criteria: Each memo leads with its recommendation, and each deciding factor is a real constraint quoted from the scenario, not a preference. The hard test: someone reading only your three deciding-factor sentences could reconstruct all three recommendations.
Stretch goal: Take your most confident recommendation and write the counter-memo arguing the opposite choice as honestly as you can. If the counter-memo turns out persuasive, your deciding factor was not actually decisive — find the one that is.
Exercises 1 through 3 are the raw ingredients of Compendium Chapter 31's scripting workflows and Chapter 32's service integrations; exercises 4 and 5 are the daily reality of Chapter 34. To see these skills combined under project pressure, work Compendium Chapters 36 and 37 (the worked projects), and keep Chapter 38 (Cookbook) nearby for the recipes you will now recognize on sight.
Everything before this point handed you a recipe. These two capstones hand you a spec. That difference matters: a portfolio reviewer or hiring manager does not care whether you can follow numbered steps — they care whether you can take a loosely defined problem, make defensible decisions, and ship something that works. The two worked projects in Compendium Chapter 36 (Worked Project - Dashboard) and Compendium Chapter 37 (Worked Project - Field Collection) are the guided versions of what you are about to do. The rule for this workbook: do not open those chapters until your self-assessment is done. Work from the spec, and when you get stuck, go to the reference chapters cited in each rubric — not to the worked answer.
Both capstones need app-authoring privileges that a free public account does not include: creating dashboards, publishing editable hosted feature layers, and signing in to field apps are organizational-account capabilities. The practical free path is the ArcGIS Online free trial, which is time-limited but costs nothing and covers everything both capstones require. Sign up for it only when you can run both capstones back to back within the trial window. If a trial is not an option, each capstone below includes a read-along alternative that preserves most of the learning with a public account.
Three rules:
Objective. Design and build a live, interactive dashboard on a topic from your own life or neighborhood, end to end, from data sourcing through published app.
What you need. An ArcGIS Online trial account (or organizational account); the Living Atlas; optionally an open data portal for your city or region. Read-along alternative: with a free public account you can complete steps 1 through 4 as a styled web map with configured pop-ups, then read Compendium Chapter 28 (Dashboards) against your map and sketch the dashboard layout on paper — you lose the app assembly but keep the data and map work, which is most of the grade.
The spec. Pick a personal domain: somewhere you have real knowledge and can judge whether the output looks right. Good candidates: restaurants or coffee shops you have actually visited, your running or cycling routes, street trees on your block, farmers markets in your county, playgrounds you have taken kids to, houses sold in your neighborhood this year. Your dashboard must:
Steps.
Milestone checklist.
Common failures.
Self-assessment rubric. Score yourself honestly on each row; anything below "competent" tells you exactly which chapter to reread before revising.
| Dimension | Chapters | Competent looks like |
|---|---|---|
| Data sourcing | Ch 5, Ch 10 | Reference layer's provenance stated; your layer performs without warnings |
| Schema design | Ch 12 | Correct field types; category fields use domains; no fields named
field_1 |
| Map craft | Ch 4, Ch 7 | Symbology encodes the data's actual structure; legible at the default extent |
| Pop-up quality | Ch 9 | Only relevant fields, formatted, in a deliberate order |
| Dashboard composition | Ch 28 | Layout matches the brief's ten-second test; no orphan elements |
| Interactivity | Ch 28, Ch 8 | Selections cascade correctly; empty-selection state is sensible |
Success criteria. Someone who knows your neighborhood but not GIS can open the link cold, understand the question within ten seconds, and answer it correctly by interacting with the dashboard — and nothing they click produces a blank or broken element.
Stretch goal. Add one Arcade expression that computes a value not stored in any field — a per-area rate, a days-since-visit count, a category derived from two other fields — and drive an indicator or pop-up with it (Compendium Chapter 8, Arcade from Zero to Fluent).
Objective. Run a complete field data collection operation in which you play both roles — the GIS lead who designs and manages the job, and the field worker who executes it — and let each role's friction teach you what the other did wrong.
What you need. An ArcGIS Online trial account; a smartphone with the ArcGIS Field Maps app installed; something inspectable within walking distance — street trees, sidewalk defects, fire hydrants, park benches, storefronts, litter hotspots. Read-along alternative: without a trial or a phone, run the same two-role structure using browser-based editing in Map Viewer (Compendium Chapter 13, Editing Workflows) — you lose GPS and the mobile form, but the schema-design, role-separation, and QA lessons survive intact.
The spec. The lead designs a collection schema, publishes an editable layer, and configures the field app. The field worker collects at least twenty real features over two separate outings, following the form exactly as configured — no mental workarounds. Between outings, the lead reviews the incoming data, documents every defect, fixes the schema and form, and sends the worker back out. The final deliverables are a QA'd dataset, a defect log, and a simple results map.
Steps.
Milestone checklist.
Common failures.
Self-assessment rubric.
| Dimension | Chapters | Competent looks like |
|---|---|---|
| Schema and domains | Ch 12 | Every category field domained; required fields defensible |
| Layer configuration | Ch 10 | Editing settings intentional; attachments working |
| Form design | Ch 30 | Field order matches inspection order; sub-thirty-second capture |
| Field execution | Ch 13, Ch 30 | Twenty-plus real features; friction log kept honestly |
| QA discipline | Ch 14 | Defects logged with root causes, not just fixed silently |
| Iteration | Ch 14, Ch 12 | Outing two measurably smoother, and you can prove it from the logs |
Success criteria. A stranger reading your defect log and decision log can reconstruct what went wrong in outing one, what you changed, and why outing two went better — and the final dataset passes your own documented QA checks.
Stretch goal. Feed the collected layer into a live dashboard of collection progress (features per day, counts by category, latest photo), so the lead role could have monitored the field role in real time — then note in your log what you would add to the schema to make that dashboard better, which is how real field operations evolve.
A capstone becomes a portfolio piece when someone else can evaluate it without you in the room. For each finished project, assemble:
If both capstones clear their rubrics and this checklist, you have working evidence of the full stack this compendium teaches: sourcing, schema, creation, cartography, apps, field operations, and quality control. From here, Compendium Chapter 38 (Cookbook) is your recipe box for the next projects, and Compendium Chapter 39 (Troubleshooting Encyclopedia) is where you go when the next spec — the one a client hands you — breaks in ways this workbook never mentioned.