Geospatial / GIS & Built Environment

Advanced · Methods & Study Design track · ~35 min hands-on + readings and quiz

← Back to the Methods & Study Design track

AI support for the spatial methods behind built-environment and environmental-health research.

What you’ll be able to do

  • Use AI to scaffold mapping and spatial-join code
  • Work with street-level and satellite imagery responsibly
  • Validate spatial results and watch for ecological fallacy

Overview

AI can scaffold geospatial code (mapping, buffers, spatial joins) and help interpret street-level or satellite imagery — directly useful for built-environment and environmental-health work. As with all coding, you read and validate what it produces.

Spatial work has its own traps: projection errors, edge effects, and the ecological fallacy. AI won’t catch these for you; methodological judgment does.

Practice activities

Activity 1 · Advanced — Scaffold and validate a spatial join

Time ~22 min · Tools ChatGPT Edu/Claude + R (sf) or Python (geopandas)

Goal. Build and validate a spatial analysis with AI help.

Setup. Two public spatial layers — e.g., Philadelphia crash points (the Philadelphia Crashes data GeoJSON) and a neighborhood or Census-tract boundary file.

Steps.

  1. Scaffold the code:

    Write R (sf) or Python (geopandas) code to load these two layers, ensure a matching CRS, and count pedestrian crashes per neighborhood. Explain each step and the CRS handling. [datasets]

  2. Run it and validate against a known case — does a high-crash corridor show up where you’d expect?

  3. Check spatial traps:

    What projection or edge-effect issues should I check here?

Expected result. A crashes-per-area count and a validation against a known pattern.

Check your work. CRS mismatches silently produce wrong joins — confirm both layers share a projection.

Common pitfalls. Don’t infer individual risk from area rates (the ecological fallacy). AI won’t catch spatial traps for you.

Stretch (optional). Map the result and sanity-check a few points against the source.

Activity 2 · Advanced — Interpret street imagery carefully

Time ~15 min · Tools a multimodal AI + public Street View

Goal. Use AI on street imagery while respecting its limits.

Setup. A few public Google Street View images of Philadelphia intersections (faces and plates are already blurred).

Steps.

  1. Ask for a description:

    Describe the pedestrian-safety features visible in this street image: crosswalks, signals, curb ramps, obstructions.

  2. Note where it guessed or hedged.

  3. Mark what a human rater must confirm before the labels are usable.

Expected result. AI-described features and a list needing human confirmation.

Check your work. Vision models guess confidently — verify each safety-relevant call.

Common pitfalls. Don’t treat AI image descriptions as measurements. Avoid images with identifiable people in unapproved tools.

Stretch (optional). Compare the AI’s description to a quick manual audit of the same image.

Activity 3 · Advanced — Run and self-validate the spatial join with Claude Code

Time ~25 min · Tools Claude Code (terminal) + Python (geopandas) or R (sf) installed locally

Goal. Watch an AI agent write, run, and validate the spatial join itself — including catching the CRS mismatch that Activity 1 could only warn you about.

Setup. The same two public layers as Activity 1 — Philadelphia crash points (the Philadelphia Crashes data GeoJSON) and a neighborhood or Census-tract boundary file — downloaded to a working folder. Claude Code is a consumer/PI-purchased tool, not Drexel-supported: Low Risk (public) Data only, which these layers are.

Steps.

  1. Start Claude Code in the folder containing both files and give it the full task:

    Write and run Python (geopandas) or R (sf) code to count pedestrian crashes per neighborhood from these two files. Before joining, print each layer’s CRS. If they don’t match, reproject one to match the other and tell me exactly what you changed and why. Do not join until they match.

  2. Ask for the diagnostics a naive script would skip:

    Print the crash row count before the join, the count after, and how many crash points fell outside every neighborhood boundary. What might explain points that fall outside?

  3. Have the agent validate against a known pattern, the same test you ran by hand in Activity 1:

    Show the top 10 neighborhoods by pedestrian crash count. Does a known high-crash corridor (e.g., Roosevelt Boulevard through the Northeast) appear where expected? If not, investigate before concluding.

  4. Read the transcript, not just the answer — confirm the agent actually printed both CRSs and reprojected before joining, rather than asserting it did.

Expected result. A crashes-per-neighborhood table plus a visible audit trail: both layers’ CRS printed, any reprojection explained, before/after row counts, and a count of unmatched points.

Check your work. The unmatched-point count is your edge-effect signal — points on boundary lines or outside city limits should be small in number and explainable. If the agent never printed a CRS, it may have joined blind exactly the way a copy-pasted script would.

Common pitfalls. An agent that runs code can still validate against the wrong expectation — you supply the known pattern, it only checks it. Agreeable confirmation (“yes, that corridor shows up”) isn’t validation; make it show the numbers. The ecological fallacy still applies to area rates, agent or no agent.

Stretch (optional). Ask Claude Code to deliberately re-run the join with the reprojection step removed and compare the two result tables — seeing how a CRS mismatch silently fails (zero or garbage matches, no error) is the whole lesson.

Check your readiness

Answer these, then check — your score suggests whether to dive in or skim the readings first.

Useful resources