Oldcircle/geo-sleuth

🧭 geo-sleuth

An agent skill that finds where a photo was taken — and shows its work.

Works with

_{…and any other agent that reads SKILL.md and runs shell commands.}

No text. No plates. No landmarks. One bridge, one mountain. Located to within 2 m.

---

Quick start

npx skills add Oldcircle/geo-sleuth

Pick your agents when prompted. Then hand your agent a photo and say:

find where this photo was taken

On first use, ask the agent to run doctor.py from the installed skill’s scripts/ folder and address any failed checks (see Requirements and setup). That is the whole interface. The agent reads SKILL.md, runs the scripts, and comes back with the camera position, the direction it was facing and a satellite evidence image. Prefer to copy the folder yourself? See Installation.

Why geo-sleuth

• One photo, one sentence. Give your agent a photo and say find where this photo was taken. You get back the camera position, the direction it was facing, and a satellite evidence image.
• It works when there is nothing to read. No sign, no plate, no landmark: OpenStreetMap geometry, elevation data, satellite tiles and street view carry the search on their own.
• Geometry instead of guesswork. Pier spacing becomes a distance ruler, shadows become a bearing, a ridge line becomes a fingerprint that elevation data can be matched against.
• Every claim points at a file. A conclusion has to name the command that ran in the session and the file it produced. Population and fame are not evidence.
• Scripts rank, the model judges. Twenty single-purpose scripts search, score and sort; the model only picks among the top few.
• One skill, every agent. A standard Agent Skill — SKILL.md plus plain Python scripts — so the same folder runs in Claude Code, Codex, Cursor, Gemini CLI, OpenCode and GitHub Copilot.
• Answers carry an error radius. Coordinates ± radius, the camera heading, an evidence image and a graded confidence.

Cases

None of these photos had GPS data. Each case lists what the skill read from the photo, how it narrowed the search, and how far the result landed from the confirmed camera position.

Each case is a record of one run by one model. The skill tells the agent how to work; what to query, how to filter and how many top results to check are the model's own decisions, so a different model or different decisions may not reach the same result. Under each case, Reproduction conditions and checkpoints lists the input, the hint, the key parameters and what each stage should still cover, so you can find the step where your own run diverged.

1 · Rice paddy and viaduct Railway bridges × skyline × pier count.	2 · Desert skyline Power lines × skyline × a phone tilted by 1°.	3 · Cherry street Street-tree open data × shadows × street view.
±2 m Qingyuan, Guangdong	within 100 m Da Qaidam, Qinghai	3 m Vancouver, Canada

1. A rice paddy and a viaduct

A phone photo with the EXIF stripped: a white oven at the edge of a harvested rice paddy, a long viaduct in the distance, a steep mountain on the right. Not a single character in the frame. One message to an agent with this skill installed, and it came back with the camera position and the direction the camera was facing.

photo → 27,335 → 171 → 14,372 → 22 → 3 → 1 → ±2 m

| Step | What it did | Candidates left | |---|---|---| | Read the photo | Poles on the viaduct are catenary masts, so it is an electrified railway. Pier spacing used as a ruler (32 m span assumed): the left segment is about 0.5 km away, the right one over 1 km. A steep mountain about 3 km away. Rice harvested but grass still green, so no frost yet. | South China, as a bet, not a proof | | Region scan | Pulled every railway bridge in the region from OpenStreetMap: 27,335 segments. Sampled a point every 400 m and computed the 360° horizon from elevation data at each one. Kept points with flat ground nearby, a clear mountain within a few km, and a flat horizon next to it. | 171 sites | | Skyline fit | Placed candidate camera positions around each site and rendered the ridge line seen from each one: 14,372 positions. The top 20 were within 0.1° of each other, so it added a constraint: the bridge must be near on the left and far on the right. | 22 | | Overlay check | Drew the top three ridge lines back onto the photo. Score #1 (Fuzhou) had a bump hidden behind the oven, which is why it scored well. #3 (Huizhou) sloped where the photo is flat. #2 (Qingyuan) fit from the foot of the mountain to the edge of the frame. | 1 | | Pier count | 17 piers in the photo become 17 bearings from the camera. Where they hit the railway line, the intersections must be evenly spaced. Combined with the skyline: first a band about 300 m long, then a single spot. | ±2 m |

<sub>Piers as a ruler: wide spacing on the left means near, tight spacing on the right means far.


Left: the top three ridge lines drawn onto the photo. Right: the evidence image the skill produced.</sub>

More figures from this run

<sub>Region scan: every railway bridge in the region (grey), sites that pass the horizon test (orange).


Pier count: bearings to the 17 piers intersect the line; only one camera position makes the spacing even.

The run took about 72 minutes end to end, roughly half of it waiting on computation.</sub>

2. A desert skyline, one degree off

A sand dune in the foreground, a range of bare dark mountains behind it, and a few pylons at the foot of the range. There is no text, road or building in the frame, and reverse image search returned only generic desert photos from northwest China.

photo → 1,537 sites → stuck around 10 px → solve a 1° tilt → 1 site → one dune

| Step | What it did | Left | |---|---|---| | Read the photo | The pylons are the only man-made objects, so the camera is within a few kilometres of a power line. Sand, gravel and bare rock point to northwest China. | 4 provinces | | Power lines × terrain | osm.py geom pulled every power line in Xinjiang, Gansu, Ningxia and Qinghai. terrain.py scan worked along them with elevation data and kept the places where mountains fill the view. | 1,537 sites | | Skyline fit | terrain.py ridge traced the ridge in the photo, and terrain.py fit compared it with the ridge seen from each site. In Qinghai the top 25 sites all scored between 9.6 and 11.7 px; the true site was 9th. | stuck | | The tilt | A phone held 1° off level moves the ridge at the edge of a 2048 px frame by 1024 × tan 1° ≈ 18 px, about 10 px on average, which is the size of the gap between the sites. At the true site the error across the frame lies on a line whose slope is tan θ, with θ ≈ 1°. fit was changed to solve the roll together with the horizon offset. | | | Fit again | With the roll solved, the true site went from 11.1 to 6.2 px. The next best site was at 9.4 px. | 1 site | | Satellite | Within 1 km along the line of sight there are three crescent dunes and a tent camp. A 750/330/110 kV bundle runs 1–2 km to the east, which is why the pylons appear only on the left of the photo. The camera stood on the crest of the dune west of the camp, facing 205°. | one dune |

<sub>Power lines from OSM (gold), sites where mountains fill the view (orange), and the camera (red star). Xinjiang's sites are not drawn.


The true site, before and after solving the roll. Top: the error grows from one side of the frame to the other, and its slope gives the angle. Bottom: with the roll solved, the trend is gone.


Skyline error per site. Assuming a level camera, the true site sits inside the pack; with the roll solved, it is the only one below 9 px.


Evidence image. The OSM power lines (gold) run over the pylons visible in the satellite image.</sub>

Blind re-run. Later we gave the photo to a new agent running the current skill, with one hint: it is in China. It scanned the 5,334 power lines in Qinghai, fit 792 sites, and picked one at 0.224° against 0.357° for the next. It ended on the same dune crest, 87 m from the confirmed camera position, after 32 minutes. The roll fit added for this photo is now part of terrain.py fit; Contributing explains why this case is the reference for changes to the core scripts.

3. A cherry tree on a Vancouver street

A flowering cherry over a sidewalk. The plates and street furniture place it in Vancouver. Finding the street is the hard part, because the city has close to ten thousand blocks.

photo → Vancouver → 1,095 big cherries → 97 blocks → 72 slope checks → W 60th Ave → 3 m

| Step | What it did | Left | |---|---|---| | Read the photo | White-and-blue BC plates, a dark-green streetlight in a grass boulevard, Vancouver Special houses. | Vancouver | | Street-tree data | Vancouver publishes every street tree with species, trunk diameter and address. The candidates came from this data rather than from well-known cherry streets: flowering cherries with a trunk of at least 40 cm, then blocks with at least three of them. | 1,095 trees, 97 blocks | | Shadows and slope | The cars' shadows fall to the left and toward the camera, so the sun is ahead and to the right. The yards on the camera side sit above the sidewalk behind rock walls, so that side of the street is uphill. The agent measured the cross-slope of 72 blocks from elevation data and checked which side the big trees stand on. | a few blocks | | Tree by tree | On the 100 block of W 60th Ave, the north side is lined with large cherries. On the south side, the trees 30–60 m ahead are 7.6 cm saplings, and the next large one is about 75 m away. The photo shows the same thing: nothing tall on the near right and pink canopy in the distance. | 1 block | | Street view | The 2009 and 2024 captures show the rock retaining wall with stone steps, the green streetlight and the white house. The house with a rooftop deck is in the 2024 capture and in the photo. The camera was on the north sidewalk, facing east. | 3 m |

<sub>Left: all 184,517 street trees with coordinates in the city's data, the 1,095 large flowering cherries and the 97 candidate blocks. Right: what the photo gives away.


The photo was taken from the sidewalk and the street view car drove down the middle of the road, so the angles differ.


Evidence image. Pink rings are large cherries from the city's data, green rings are saplings.</sub>

Blind re-run. The table above comes from a blind run: a new agent running the current skill, given the photo and no hint. It finished in 53 minutes, 3 m from the confirmed camera position.

Installation

geo-sleuth is a standard Agent Skill: one folder holding SKILL.md, scripts/, references/ and data/. Install it with the skills CLI, or copy the folder yourself.

All six agents, user-wide, one command:

npx skills add Oldcircle/geo-sleuth -g -a claude-code -a codex -a cursor -a gemini-cli -a opencode -a github-copilot -y

By hand:

git clone https://github.com/Oldcircle/geo-sleuth
mkdir -p ~/.agents/skills ~/.claude/skills
cp -r geo-sleuth/skills/geo-sleuth ~/.agents/skills/              # Codex, Cursor, Gemini CLI, OpenCode, GitHub Copilot
ln -s ~/.agents/skills/geo-sleuth ~/.claude/skills/geo-sleuth     # Claude Code

~/.agents/skills/ is read by Codex, Cursor, Gemini CLI, OpenCode and GitHub Copilot, so one copy there covers all five. Each agent's own folders, from its docs:

| Agent | User-wide | Per project | |---|---|---| | Claude Code | ~/.claude/skills/ | .claude/skills/ | | Codex | ~/.agents/skills/ | .agents/skills/ | | Cursor | ~/.cursor/skills/ or ~/.agents/skills/ | .cursor/skills/ or .agents/skills/ | | Gemini CLI | ~/.gemini/skills/ or ~/.agents/skills/ | .gemini/skills/ or .agents/skills/ | | OpenCode | ~/.config/opencode/skills/ or ~/.agents/skills/ | .opencode/skills/ or .agents/skills/ | | GitHub Copilot | ~/.copilot/skills/ or ~/.agents/skills/ | .github/skills/ or .agents/skills/ |

Any other agent that reads SKILL.md and runs shell commands works the same way: put the folder where it looks for skills.

How it works

The work is split into three layers. Scripts decide, scripts perceive and rank, the model only judges among the top few.

flowchart LR
  A["photo"] --> B["intake.py
EXIF · OCR · reverse image search"]
  B --> C["board.py
candidate board: clues, likelihood ratios, ranking, next step"]
  C --> D{"which branch?"}
  D --> E["sun.py · terrain.py · osm.py · pose.py
shadows, skylines, OSM corridors, camera pose"]
  D --> F["sat_scan.py · match.py · gsv.py · baidu_pano.py
CLIP-ranked satellite tiles, DINOv2+SIFT street view"]
  E --> G["board.py check · report"]
  F --> G
  G --> H["evidence.py
coordinates ± radius · evidence image · graded confidence"]

| Layer | Who | Tools | |---|---|---| | Decide: which candidates, how evidence scores, what can be excluded, where to scan next | scripts (the candidate board) | board.py | | Perceive: read text, look up tables, find targets in satellite tiles, compare street view | scripts rank first, a person looks at the top few | intake.py ocr.py clues.py sat_scan.py match.py geo.py | | Judge: pull clues from the frame, propose hypotheses, pick among the ranked few | the model | SKILL.md + references/ |

Every conclusion has to point at a command that actually ran in the session and the file it produced. Exclusions need read or computed evidence; observations and guesses can only lower a candidate's weight.

Toolbox

Twenty-odd scripts, one job each. The full table with data sources is in skills/geo-sleuth/references/data-sources.md.

| What it does | Script | |---|---| | Environment checks, browser launch and optional network probes | doctor.py | | EXIF: GPS, capture time, equivalent focal length