gap: the five BGT collections #176 approved have no ticket and nothing to pick them up #261

Closed
opened 2026-09-02 00:46:38 +00:00 by viberfox-agent · 0 comments
Collaborator

Found while QA'ing #176 (issue #258).

What I did

Walked #176 as a player would meet it, then looked for the work it approved.

What happened

#176 answered "is it worth wiring in?" with yes, for five collections —
scheiding_vlak, vegetatieobject_lijn, bord, kast, bak — and shipped the
client half: PROP_KINDS positions 7 Board, 8 Bin, 9 Recycling
(crates/cartopolis/src/systems/map/surveyed.rs:81), plus the note and the
direction.md row. Nothing emits those positions. A player meets nothing at all.

The extractor half is server/pipeline/bgt.ts in jeroen/cartopy, and the
container that filed #176 cannot read that repository (the token answers 404).
#176 raised that as its open question 1 — "the ticket has to be split, or the
implementing agent needs a token; which?" — and closed without an answer.

The result is that the approved work exists only as a table row in
docs/direction.md:104 and a section in
docs/notes/surveyed-street-objects.md. Neither is a queue. Its acceptance
criterion "the extractor reads scheiding_vlak, vegetatieobject_lijn, bord,
kast and bak" is unmet and untracked.

What a user would expect

That an approved source ends up in the world, or that the thing standing in the
way has a ticket with a name on it.

Why this is worth a ticket rather than a shrug

The sibling verdict did it right. #203 (crop parcels) hit exactly the same wall
and filed #204 — cartopy: server/pipeline/brp.ts — the extractor half of the
crop parcels
, which is open. #176 filed a follow-up for the item it rejected
(bridge decks and tunnels) and none for the five it accepted.

This is the concrete instance of the pattern #221 proposes a rule for; it is
filed separately because #221 is a proposal about docs/direction.md and this is
one piece of unowned work.

What the extractor has to do

Measured against the live API over ~10x9 km of Groningen on 2026-09-02, current
versions only, following the cursor to the end rather than reading one page:

collection current emit as
scheiding_vlak muur 3,027 LINE_KINDS 1 Wall
vegetatieobject_lijn haag 32 LINE_KINDS 2 Hedge
bord, minus verkeersbord 374 (of 1,681) PROP_KINDS 7 Board
kast 162 PROP_KINDS 6 Cabinet
bak afvalbak / container+afval apart plaats 15 / 18 PROP_KINDS 8 / 9

kademuur (742) and transitie (1,423) are dropped per the note. type is
niet-bgt on all of bord, kast, bak and vegetatieobject_lijn — the class
is in plus_type, exactly as the note warns.

The per-cell byte cost, which #176 flagged as not measured: over 47 z14 cells
the five collections come to 291 kB, and the heaviest single cell gains 35 kB
on top of the ~60 kB objects file it already has. Walls are almost all of it.
That is not a reason to hold anything up.

Found while QA'ing #176 (issue #258). ## What I did Walked #176 as a player would meet it, then looked for the work it approved. ## What happened #176 answered "is it worth wiring in?" with **yes, for five collections** — `scheiding_vlak`, `vegetatieobject_lijn`, `bord`, `kast`, `bak` — and shipped the client half: `PROP_KINDS` positions 7 `Board`, 8 `Bin`, 9 `Recycling` (`crates/cartopolis/src/systems/map/surveyed.rs:81`), plus the note and the `direction.md` row. Nothing emits those positions. A player meets nothing at all. The extractor half is `server/pipeline/bgt.ts` in `jeroen/cartopy`, and the container that filed #176 cannot read that repository (the token answers 404). #176 raised that as its open question 1 — "the ticket has to be split, or the implementing agent needs a token; **which?**" — and closed without an answer. The result is that the approved work exists only as a table row in `docs/direction.md:104` and a section in `docs/notes/surveyed-street-objects.md`. Neither is a queue. Its acceptance criterion "the extractor reads `scheiding_vlak`, `vegetatieobject_lijn`, `bord`, `kast` and `bak`" is unmet and untracked. ## What a user would expect That an approved source ends up in the world, or that the thing standing in the way has a ticket with a name on it. ## Why this is worth a ticket rather than a shrug The sibling verdict did it right. #203 (crop parcels) hit exactly the same wall and filed **#204 — `cartopy: server/pipeline/brp.ts` — the extractor half of the crop parcels**, which is open. #176 filed a follow-up for the item it *rejected* (bridge decks and tunnels) and none for the five it accepted. This is the concrete instance of the pattern #221 proposes a rule for; it is filed separately because #221 is a proposal about `docs/direction.md` and this is one piece of unowned work. ## What the extractor has to do Measured against the live API over ~10x9 km of Groningen on 2026-09-02, current versions only, following the cursor to the end rather than reading one page: | collection | current | emit as | |---|---|---| | `scheiding_vlak` `muur` | 3,027 | `LINE_KINDS` 1 `Wall` | | `vegetatieobject_lijn` `haag` | 32 | `LINE_KINDS` 2 `Hedge` | | `bord`, minus `verkeersbord` | 374 (of 1,681) | `PROP_KINDS` 7 `Board` | | `kast` | 162 | `PROP_KINDS` 6 `Cabinet` | | `bak` `afvalbak` / `container`+`afval apart plaats` | 15 / 18 | `PROP_KINDS` 8 / 9 | `kademuur` (742) and `transitie` (1,423) are dropped per the note. `type` is `niet-bgt` on all of `bord`, `kast`, `bak` and `vegetatieobject_lijn` — the class is in `plus_type`, exactly as the note warns. **The per-cell byte cost, which #176 flagged as not measured**: over 47 z14 cells the five collections come to 291 kB, and the heaviest single cell gains **35 kB** on top of the ~60 kB objects file it already has. Walls are almost all of it. That is not a reason to hold anything up.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
jeroen/cartopolis#261
No description provided.