jeroen/cartopolis

Watch

Fork 0

QA: what #175 shipped — PDOK aerial imagery: is it worth wiring in? #263

New issue

Closed

opened 2026-09-02 01:19:39 +00:00 by viberfox-agent · 2 comments

viberfox-agent commented

2026-09-02 01:19:39 +00:00

Collaborator

Issue #175 (“PDOK aerial imagery: is it worth wiring in?”) was built and merged by the unattended lane, and nobody has used it. Walk what it delivered as a player would meet it.

This is a QA pass, not a build. Change no code and open no pull request on this
ticket — the deliverables are findings.

Exercise it for real. Run what a player would touch, headlessly: cargo run -p cartopolis_simulator with a client or a wire/HTTP probe for anything online, the
loopback tests, cargo run -p cartopolis -- --shot … --dump-state for anything with
geometry. CLAUDE.md lists every harness. If part of this genuinely needs a screen, a
phone or a microphone, verify the half a machine can reach and name the half it cannot.
Walk the user's journey, not the happy path. At each step ask what a real user
would obviously expect to be able to do next — then try exactly that. A refusal or an
absence that would surprise a user is a finding even when every implemented piece
works: registration worked, claiming a house worked, and a registered account still
could not claim a house. No test failed; a user hit a wall.
File each real gap as its own issue: title starting gap:, label qa-gap, with
what you did, what happened, what a user would expect instead, and where in the code
the seam is. Use the Forgejo API with the FORGEJO_TOKEN in your environment. Do not
label them autonomous — a person decides which gaps become work.
Report and close. Your final message: what you exercised, what held, what you
filed. Nothing found after a genuine pass is a good outcome — say what you checked.
Then close this ticket through the API; a QA pass has no branch to merge.

Decide it yourself. Nobody is watching this ticket; a question asked here is a
ticket that stops. Judge by what a reasonable player would expect, verify before
claiming, and never post credentials or file contents from outside the repository.

_{Filed by the autopilot.}

Issue #175 (“PDOK aerial imagery: is it worth wiring in?”) was built and merged by the unattended lane, and nobody has used it. Walk what it delivered as a player would meet it. **This is a QA pass, not a build.** Change no code and open no pull request on this ticket — the deliverables are findings. 1. **Exercise it for real.** Run what a player would touch, headlessly: `cargo run -p cartopolis_simulator` with a client or a wire/HTTP probe for anything online, the loopback tests, `cargo run -p cartopolis -- --shot … --dump-state` for anything with geometry. CLAUDE.md lists every harness. If part of this genuinely needs a screen, a phone or a microphone, verify the half a machine can reach and name the half it cannot. 2. **Walk the user's journey, not the happy path.** At each step ask what a real user would obviously expect to be able to do next — then try exactly that. A refusal or an absence that would surprise a user is a finding even when every implemented piece works: registration worked, claiming a house worked, and a registered account still could not claim a house. No test failed; a user hit a wall. 3. **File each real gap as its own issue**: title starting `gap:`, label `qa-gap`, with what you did, what happened, what a user would expect instead, and where in the code the seam is. Use the Forgejo API with the `FORGEJO_TOKEN` in your environment. Do not label them `autonomous` — a person decides which gaps become work. 4. **Report and close.** Your final message: what you exercised, what held, what you filed. Nothing found after a genuine pass is a good outcome — say what you checked. Then close this ticket through the API; a QA pass has no branch to merge. **Decide it yourself.** Nobody is watching this ticket; a question asked here is a ticket that stops. Judge by what a reasonable player would expect, verify before claiming, and never post credentials or file contents from outside the repository. Filed by the autopilot.

viberfox-agent added the

agent

autopilot

labels

2026-09-02 01:19:39 +00:00

viberfox-agent added this to the Viberfox project

2026-09-02 01:19:44 +00:00

viberfox-agent added the

agent:running

label

2026-09-02 01:19:45 +00:00

viberfox-agent commented

2026-09-02 01:19:48 +00:00

Author

Collaborator

🤖 Picked this up — working on branch feat/263-qa-what-175-shipped in a fresh worktree on the VPS. I'll report back here when I'm done.

_{Label an issue agent:skip to keep me off it, or driven to keep it in a session you are driving.}

🤖 Picked this up — working on branch `feat/263-qa-what-175-shipped` in a fresh worktree on the VPS. I'll report back here when I'm done. Label an issue `agent:skip` to keep me off it, or `driven` to keep it in a session you are driving.

viberfox-agent referenced this issue

2026-09-02 01:57:20 +00:00

gap: with Aerial photography on, the drawn map is painted over the photograph — 99% of a city frame is unchanged #264

viberfox-agent referenced this issue

2026-09-02 01:57:45 +00:00

gap: the aerial envelope is a rectangle over Antwerp, Brussels and Duesseldorf, where PDOK serves a blank white tile and the ground goes white #265

viberfox-agent closed this issue

2026-09-02 01:57:56 +00:00

viberfox-agent commented

2026-09-02 01:58:17 +00:00

Author

Collaborator

The aerial photography layer from #175 works as plumbing but not as a feature: it fetches PDOK's photographs and puts them under a drawn map that covers them. I filed two gaps and changed no code.

What I exercised

Built the client and took five before/after capture pairs, identical apart from the --aerial flag (same camera, noon, no chrome, 800×800, vector tile source pinned). Also probed the PDOK service directly, and ran both test suites.

What held. Every tile arrived: aerial_tiles was 258–405 standing tiles per run and zero in every control, with no fetch failure in any log. The photographs really are on the ground — a farmyard crop shows grass and tree texture where the control shows a flat grey fill. The cache separation added by #175 works, the service is up and CORS-open, and both suites pass: 236 tests in cartopolis_geo, 820 in cartopolis.

What I filed

#264 — the drawn map is painted over the photograph. Over Groningen's centre at 700 m, turning the layer on changes 4,534 of 640,000 pixels — 0.7% of the frame. Farmland: 4%. From 5 km: 12.5%. The opaque landuse fills (farmland, park, forest, residential, commercial), the paving and the road ribbons all sit above the ground tiles, and nothing outside map_stream knows the ground became a photograph. Switching off Map hides the photograph, not the fills, so there is no way round it from the panel. The note calls this an unjudged look question; at street level there is nothing left to look at.

#265 — the coverage rectangle covers Antwerp, Brussels, Düsseldorf and Duisburg. PDOK answers those with a valid 1,651-byte pure-white tile, and the client textures it with no fallback to the drawn map. Rural Belgium at 700 m: 25% of the frame goes blanched. It is mostly masked today by #264 — fix that and it becomes a white void.

What I did not verify

Ticking the checkbox at runtime. --aerial only exercises the startup path; the retear that happens when you flip the box mid-session has no test and no headless route. I read it and it looks right, but nobody has run it.
Colour and lighting — this container renders in software.
One measured trade I did not file, because the note already records it as open: PDOK serves 256-pixel tiles while the drawn map renders at 512, so the photograph arrives at half the texel density of the map it replaces, and the clipmap never asks past zoom 17 although the service goes to 21.

Ticket #263 is closed. The branch has no commits.

No commits were made.

_{🤖 viberfox issue agent on the VPS — 97 turns · $9.58 · session 0f2132f1-5811-4aa7-a79a-aa5bc5efa55a. Reply with @agent to continue this session.}

The aerial photography layer from #175 works as plumbing but not as a feature: it fetches PDOK's photographs and puts them under a drawn map that covers them. I filed two gaps and changed no code. ## What I exercised Built the client and took five before/after capture pairs, identical apart from the `--aerial` flag (same camera, noon, no chrome, 800×800, vector tile source pinned). Also probed the PDOK service directly, and ran both test suites. **What held.** Every tile arrived: `aerial_tiles` was 258–405 standing tiles per run and zero in every control, with no fetch failure in any log. The photographs really are on the ground — a farmyard crop shows grass and tree texture where the control shows a flat grey fill. The cache separation added by #175 works, the service is up and CORS-open, and both suites pass: 236 tests in `cartopolis_geo`, 820 in `cartopolis`. ## What I filed **[#264](https://code.garage44.eu/jeroen/cartopolis/issues/264) — the drawn map is painted over the photograph.** Over Groningen's centre at 700 m, turning the layer on changes **4,534 of 640,000 pixels — 0.7% of the frame**. Farmland: 4%. From 5 km: 12.5%. The opaque landuse fills (farmland, park, forest, residential, commercial), the paving and the road ribbons all sit above the ground tiles, and nothing outside `map_stream` knows the ground became a photograph. Switching off **Map** hides the photograph, not the fills, so there is no way round it from the panel. The note calls this an unjudged look question; at street level there is nothing left to look at. **[#265](https://code.garage44.eu/jeroen/cartopolis/issues/265) — the coverage rectangle covers Antwerp, Brussels, Düsseldorf and Duisburg.** PDOK answers those with a valid 1,651-byte pure-white tile, and the client textures it with no fallback to the drawn map. Rural Belgium at 700 m: 25% of the frame goes blanched. It is mostly masked today by #264 — fix that and it becomes a white void. ## What I did not verify - **Ticking the checkbox at runtime.** `--aerial` only exercises the startup path; the retear that happens when you flip the box mid-session has no test and no headless route. I read it and it looks right, but nobody has run it. - **Colour and lighting** — this container renders in software. - One measured trade I did not file, because the note already records it as open: PDOK serves 256-pixel tiles while the drawn map renders at 512, so the photograph arrives at half the texel density of the map it replaces, and the clipmap never asks past zoom 17 although the service goes to 21. Ticket #263 is closed. The branch has no commits. _No commits were made._ --- 🤖 viberfox issue agent on the VPS — 97 turns · $9.58 · session `0f2132f1-5811-4aa7-a79a-aa5bc5efa55a`. Reply with **@agent** to continue this session.

viberfox-agent added

agent:done

and removed

agent:running

labels

2026-09-02 01:58:17 +00:00

viberfox-agent referenced this issue

2026-09-03 00:47:47 +00:00

Autopilot log #257

viberfox-agent referenced this issue

2026-09-04 00:30:53 +00:00

alreadyFiled only ever sees 50 issues, so every autopilot dedupe key silently expires — #206 was QA'd twice #281