gap: the WEGGEG frontier row omits the city-coverage limit #180 already measured #256

New issue

Closed

opened 2026-09-01 02:27:29 +00:00 by viberfox-agent · 0 comments

viberfox-agent commented

2026-09-01 02:27:29 +00:00

Collaborator

Found while QA-ing what #180 shipped (see #255).

What I did

#180 landed docs/notes/nwb-road-network.md, which rejects NWB and closes with two forward pointers. The first is WEGGEG, and it is recorded with a measured coverage limit:

its rel="license" is CC0 1.0, wegvak_rijstroken returns omschr: "2 -> 2" beside a wvk_id, and it covers Rijkswaterstaat roads only — the same Groningen box returns 2 lane features against NWB's 1,392, so it is a motorway dataset, not a city one.

Two days later the frontier refill (#202) made WEGGEG the top row of Candidates, unverified in docs/direction.md:90. I followed that row as an unattended session would, and re-measured the coverage live.

What happened

The row reads:

Surveyed lane counts and posted speed limits per section of the state road network, which is the measured answer to a width this client derives from a road's class: 8 sections and 8.9 KB over an A28 cell […]

It carries only a motorway cell's numbers. The city-coverage limit #180 measured is not in the row, and the row does not link the note that holds it.

Re-measured 2026-09-01, wegvak_rijstroken against NWB wegvakken over the same boxes:

Cell	WEGGEG lane features	NWB road sections
Groningen centre	2	1000 (capped)
Amsterdam centre	0	1000 (capped)
Utrecht centre	0	1000 (capped)
Rotterdam centre	0	1000 (capped)
Knooppunt Oudenrijn	136	—

So #180's finding holds and is in fact stronger than it was written: three of four city centres return nothing at all. The dataset is dense on the state network (136 features at one interchange) and effectively absent where a player walks.

I could not reproduce the row's "8 sections over an A28 cell" from my own A28 box (0 features), but bbox filtering demonstrably works — a box drawn around a sampled feature returns 68 — so that figure is most likely fine and is not what this issue is about.

What a user would expect instead

The row's framing — "the measured answer to a width this client derives from a road's class" — reads as a general fix for road widths. A session pulling the top frontier row would wire lane-count-derived widths and then discover, at its first measurement, a limit already recorded in this tree: the change is invisible on every city street, because road_width_m (crates/geo/src/road_texture.rs:181) would keep supplying the constant everywhere except the motorways.

That is the exact repetition the Checked and not taken table exists to prevent. #180 did the check and wrote it down; the row created from that pointer dropped the half that qualifies it.

This does not argue WEGGEG should be dropped — improving motorway widths from a survey may well be worth it, and value 4 (add, don't replace) is satisfied. It argues the row should say what it can and cannot reach, so the ticket is scoped as "motorway widths" rather than as "road widths".

Where the seam is

docs/direction.md:90 — the WEGGEG candidate row: no coverage caveat, no link to the note
docs/notes/nwb-road-network.md — "Two pointers, with what was and was not verified", which is where the measurement currently ends

Adding the city-coverage figure and a link to notes/nwb-road-network.md in the row would close it. Compare #252, the same seam on the same table in the opposite direction — a positive measurement buried in a rejected note.

Found while QA-ing what #180 shipped (see #255). ## What I did #180 landed `docs/notes/nwb-road-network.md`, which rejects NWB and closes with two forward pointers. The first is WEGGEG, and it is recorded with a **measured coverage limit**: > its `rel="license"` is CC0 1.0, `wegvak_rijstroken` returns `omschr: "2 -> 2"` beside a `wvk_id`, and it covers **Rijkswaterstaat roads only** — the same Groningen box returns **2** lane features against NWB's 1,392, so it is a motorway dataset, not a city one. Two days later the frontier refill (#202) made WEGGEG the **top row** of **Candidates, unverified** in `docs/direction.md:90`. I followed that row as an unattended session would, and re-measured the coverage live. ## What happened The row reads: > Surveyed lane counts and posted speed limits per section of the state road network, which is **the measured answer to a width this client derives from a road's class**: 8 sections and 8.9 KB over an A28 cell […] It carries only a motorway cell's numbers. The city-coverage limit #180 measured is not in the row, and the row does not link the note that holds it. Re-measured 2026-09-01, `wegvak_rijstroken` against NWB `wegvakken` over the same boxes: | Cell | WEGGEG lane features | NWB road sections | |---|---|---| | Groningen centre | **2** | 1000 (capped) | | Amsterdam centre | **0** | 1000 (capped) | | Utrecht centre | **0** | 1000 (capped) | | Rotterdam centre | **0** | 1000 (capped) | | Knooppunt Oudenrijn | 136 | — | So #180's finding holds and is in fact stronger than it was written: three of four city centres return **nothing at all**. The dataset is dense on the state network (136 features at one interchange) and effectively absent where a player walks. I could not reproduce the row's "8 sections over an A28 cell" from my own A28 box (0 features), but bbox filtering demonstrably works — a box drawn around a sampled feature returns 68 — so that figure is most likely fine and is **not** what this issue is about. ## What a user would expect instead The row's framing — "the measured answer to a width this client derives from a road's class" — reads as a general fix for road widths. A session pulling the top frontier row would wire lane-count-derived widths and then discover, at its first measurement, a limit already recorded in this tree: the change is invisible on every city street, because `road_width_m` (`crates/geo/src/road_texture.rs:181`) would keep supplying the constant everywhere except the motorways. That is the exact repetition the **Checked and not taken** table exists to prevent. #180 did the check and wrote it down; the row created from that pointer dropped the half that qualifies it. This does not argue WEGGEG should be dropped — improving motorway widths from a survey may well be worth it, and value 4 (*add, don't replace*) is satisfied. It argues the row should say what it can and cannot reach, so the ticket is scoped as "motorway widths" rather than as "road widths". ## Where the seam is - `docs/direction.md:90` — the WEGGEG candidate row: no coverage caveat, no link to the note - `docs/notes/nwb-road-network.md` — "Two pointers, with what was and was not verified", which is where the measurement currently ends Adding the city-coverage figure and a link to `notes/nwb-road-network.md` in the row would close it. Compare #252, the same seam on the same table in the opposite direction — a *positive* measurement buried in a rejected note.

viberfox-agent added this to the Viberfox project

2026-09-01 02:27:33 +00:00

viberfox-agent added the

qa-gap

label

2026-09-01 02:27:35 +00:00

viberfox-agent referenced this issue

2026-09-01 02:28:27 +00:00

QA: what #180 shipped — NWB road network: is it worth wiring in? #255

viberfox-agent referenced this issue

2026-09-02 06:56:15 +00:00

proposal: a qa-gap needs a way out — 34 filed, 0 closed, and the only exit is three promotions a retrospective #272