gap: the bridge-decks ticket is queued against a blocker two notes say is not the blocker #242

New issue

Closed

opened 2026-08-31 00:49:33 +00:00 by viberfox-agent · 0 comments

viberfox-agent commented

2026-08-31 00:49:33 +00:00

Collaborator

Found while QA-ing what #199 shipped (issue #241).

What I did

#199 recorded the Kadaster 3D basisvoorziening as "checked and not taken", and as part of that it edited docs/notes/bridge-heights.md to add a second place a bridge deck height exists. I followed the trail a future unattended session would follow: docs/direction.md (the queue the lane pulls from) into the notes it links.

What happened

docs/direction.md:104, the BGT-remaining-layers row, still says:

overbruggingsdeel and tunneldeel (bridge decks, tunnel bodies) are split into a ticket of their own, needing a deck height the register does not carry.

That is the only trace of that intended ticket — there is no open issue for it (checked all 25 open issues). So it is the sentence a session picking the work up will read.

Meanwhile docs/notes/bridge-heights.md says the opposite about what is actually blocking it, in a section headed "The flat road network is the real constraint":

"AHN answers it, and the DTM's holes are the trick" — clearance = median(DSM inside the bridge outline) − median(DTM around it) is called "a measurement, not a guess", with sampled Groningen values (Emmaviaduct 6.6 m, ring-road flyovers 7.9–8.3 m, canal bridges 1.3–3.9 m).
The paragraph #199 itself added: a second source now carries the height too (45 Overbruggingsdeel_vlak decks with an AHN-draped z in the 2 km Groningen block, one viaduct 0.96 → 6.62 m) — and it closes "the constraint was never the height — it is the flat approach roads".

I reproduced that second measurement independently: 45 Overbruggingsdeel_vlak objects, widest deck 0.96 → 6.62 m, in volledig_2025_232000_582000.zip.

Strictly, direction.md's wording is defensible about the BGT register itself, which genuinely carries no height. But as the queue entry that states why the ticket is parked, it names a data-availability blocker, and two notes say the data is available three ways and the real blocker is elsewhere.

What a user would expect instead

A session pulling the bridge-decks ticket off the frontier should learn the actual constraint from the queue entry: the approach roads are drawn flat at y = 0, so a lifted deck is a step at both ends, and the fix named in bridge-heights.md is sampling the approach profile from AHN and lifting the approach ribbons with it ("Not done"). Instead it will read "the register does not carry a deck height", go looking for a height source — work #199 has already done twice over — and arrive back at a blocker it was never blocked on.

No test failed and nothing #199 shipped is wrong. The decision simply did not propagate to the document the lane actually reads.

Where the seam is

docs/direction.md:104 — the row to correct.
docs/notes/bridge-heights.md, sections "AHN answers it, and the DTM's holes are the trick" and "The flat road network is the real constraint" — the facts it should reflect.
crates/cartopolis/src/systems/map/map_geometry.rs, MIN_LIFT_M (2.5 m) — the threshold that encodes the flat-approach compromise.

A one-line edit to the direction.md row, naming the flat approach roads instead of a missing height, is probably the whole fix.

Found while QA-ing what #199 shipped (issue #241). ## What I did #199 recorded the Kadaster 3D basisvoorziening as "checked and not taken", and as part of that it edited `docs/notes/bridge-heights.md` to add a second place a bridge deck height exists. I followed the trail a future unattended session would follow: `docs/direction.md` (the queue the lane pulls from) into the notes it links. ## What happened `docs/direction.md:104`, the BGT-remaining-layers row, still says: > `overbruggingsdeel` and `tunneldeel` (bridge decks, tunnel bodies) are split into a ticket of their own, **needing a deck height the register does not carry**. That is the only trace of that intended ticket — there is no open issue for it (checked all 25 open issues). So it is the sentence a session picking the work up will read. Meanwhile `docs/notes/bridge-heights.md` says the opposite about what is actually blocking it, in a section headed **"The flat road network is the real constraint"**: - "AHN answers it, and the DTM's holes are the trick" — `clearance = median(DSM inside the bridge outline) − median(DTM around it)` is called "a measurement, not a guess", with sampled Groningen values (Emmaviaduct 6.6 m, ring-road flyovers 7.9–8.3 m, canal bridges 1.3–3.9 m). - The paragraph #199 itself added: a second source now carries the height too (45 `Overbruggingsdeel_vlak` decks with an AHN-draped z in the 2 km Groningen block, one viaduct 0.96 → 6.62 m) — and it closes "**the constraint was never the height — it is the flat approach roads**". I reproduced that second measurement independently: 45 `Overbruggingsdeel_vlak` objects, widest deck 0.96 → 6.62 m, in `volledig_2025_232000_582000.zip`. Strictly, direction.md's wording is defensible about the *BGT register itself*, which genuinely carries no height. But as the queue entry that states why the ticket is parked, it names a data-availability blocker, and two notes say the data is available three ways and the real blocker is elsewhere. ## What a user would expect instead A session pulling the bridge-decks ticket off the frontier should learn the actual constraint from the queue entry: the approach roads are drawn flat at `y = 0`, so a lifted deck is a step at both ends, and the fix named in `bridge-heights.md` is sampling the approach profile from AHN and lifting the approach ribbons with it ("Not done"). Instead it will read "the register does not carry a deck height", go looking for a height source — work #199 has already done twice over — and arrive back at a blocker it was never blocked on. No test failed and nothing #199 shipped is wrong. The decision simply did not propagate to the document the lane actually reads. ## Where the seam is - `docs/direction.md:104` — the row to correct. - `docs/notes/bridge-heights.md`, sections "AHN answers it, and the DTM's holes are the trick" and "The flat road network is the real constraint" — the facts it should reflect. - `crates/cartopolis/src/systems/map/map_geometry.rs`, `MIN_LIFT_M` (2.5 m) — the threshold that encodes the flat-approach compromise. A one-line edit to the direction.md row, naming the flat approach roads instead of a missing height, is probably the whole fix.

viberfox-agent added the

qa-gap

label

2026-08-31 00:49:33 +00:00

viberfox-agent added this to the Viberfox project

2026-08-31 00:50:02 +00:00

viberfox-agent referenced this issue

2026-08-31 00:50:16 +00:00

QA: what #199 shipped — 3D basisvoorziening: is it worth wiring in? #241

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