jeroen/cartopolis

Watch

Fork 0

gap: the navigation-marks water gate stops nothing inside the Netherlands #212

New issue

Closed

opened 2026-08-30 07:56:17 +00:00 by viberfox-agent · 1 comment

viberfox-agent commented

2026-08-30 07:56:17 +00:00

Collaborator

Found by the QA pass on #210, walking what #206/#207 shipped.

What I did

Two measurements against the live tile source and the live register.

Sampled ten z14 cells spread across the country — Groningen Grote Markt, Utrecht centre, Veluwe heath, Brabant farmland, Drenthe farmland, Amsterdam centre, Vaals, a Flevoland polder, the Achterhoek, Walcheren — fetched each tile from tiles.cartopolis.org/tiles/osm/14/{x}/{y} and applied vector_tiles::body_mentions_water to the raw body.
Cold-started the client with an empty cache at its default location (Groningen), then listed cache/features/marks/.

What happened

10 of 10 sampled Dutch cells pass the water gate. Every one carries water_polygons; eight also carry water_lines. The Veluwe heath and the Achterhoek — about as dry as inland Netherlands gets — carry water_polygons on their own. The country is drained by ditches and dotted with ponds, so at z14 there is no dry cell in it.

The cold start bore that out: nine Groningen cells were each asked of PDOK and each answered empty, and all nine were written to the cache as {"marks":[]} (12 bytes each):

cache/features/marks/v1/14/{8489,8490,8491}/{5320,5321,5322}.json   12 bytes each

That is 18 requests to api.pdok.nl (two collections × nine cells) on a first run at the app's own start location, for nothing.

What the design says instead

docs/notes/navigation-marks.md and the commit body both rest the "fetch from the client rather than through a cartopy extractor" argument on this gate:

The envelope stops the world outside the Netherlands; the cell's water stops the dry two thirds inside it.

The Groningen row is the one the design turns on: an empty cell is not free, and most of a streamed ring is empty. Hence the two gates below.

There is no dry two thirds. Inside the envelope the second gate is very close to a constant true, so the request count is the same as if it were not there.

Why no test caught it

The two tests disagree about Groningen and neither joins the halves:

crates/geo/src/vector_tiles.rs — the_water_probe_reads_an_undecoded_body asserts body_mentions_water(GRONINGEN_Z14) is true. That is the correct answer and it is the one that breaks the gate.
crates/cartopolis/src/systems/map/nav_marks.rs — a_foreign_or_dry_cell_asks_for_nothing asserts !should_fetch(GRONINGEN, false), passing the wet/dry answer in by hand. It can only ever prove the boolean is honoured, never that any real cell produces it.

Where the seam is

crates/cartopolis/src/systems/map/nav_marks.rs — should_fetch, and the module note's "Two gates before a request is made"
crates/geo/src/vector_tiles.rs — WATER_HINT_LAYERS
docs/notes/navigation-marks.md — "Two gates, and why they are the whole cost argument"

What a person might decide

Narrowing the hint set does not rescue it: water_polygons alone is still 10/10. Three directions, for whoever picks this up:

Accept the cost and correct the note. 18 requests per fresh 3×3 ring, cached afterwards, against a service with an hour of Cache-Control and CORS *. That may simply be fine — but the note should say so rather than claim a saving it does not make.
Gate on the fairway rather than on water. A mark stands in a navigable channel, not in a ditch; the register's own extent is the country, but a coarse per-cell presence bitmap of the 18,474 points would be exact and tiny.
Fetch the register once instead of per cell. In the client's own compacted WireMark form the Waal's 43 marks are 4,802 bytes — about 112 bytes each — so the whole national register is roughly 2.1 MB, less than the 3.8 MB the BGT paving costs for one dense cell. A single national fetch would delete both gates and every empty answer with them.

Nothing here is user-visible: the marks draw correctly (nav_marks=115 over the Waal, settled). This is the cost argument not holding, not a broken layer.

_{Filed by the QA pass on #210. Not autonomous — a person decides whether this becomes work.}

Found by the QA pass on #210, walking what #206/#207 shipped. ## What I did Two measurements against the live tile source and the live register. 1. Sampled ten z14 cells spread across the country — Groningen Grote Markt, Utrecht centre, Veluwe heath, Brabant farmland, Drenthe farmland, Amsterdam centre, Vaals, a Flevoland polder, the Achterhoek, Walcheren — fetched each tile from `tiles.cartopolis.org/tiles/osm/14/{x}/{y}` and applied `vector_tiles::body_mentions_water` to the raw body. 2. Cold-started the client with an empty cache at its **default** location (Groningen), then listed `cache/features/marks/`. ## What happened **10 of 10 sampled Dutch cells pass the water gate.** Every one carries `water_polygons`; eight also carry `water_lines`. The Veluwe heath and the Achterhoek — about as dry as inland Netherlands gets — carry `water_polygons` on their own. The country is drained by ditches and dotted with ponds, so at z14 there is no dry cell in it. The cold start bore that out: nine Groningen cells were each asked of PDOK and each answered empty, and all nine were written to the cache as `{"marks":[]}` (12 bytes each): ``` cache/features/marks/v1/14/{8489,8490,8491}/{5320,5321,5322}.json 12 bytes each ``` That is **18 requests to api.pdok.nl** (two collections × nine cells) on a first run at the app's own start location, for nothing. ## What the design says instead `docs/notes/navigation-marks.md` and the commit body both rest the "fetch from the client rather than through a cartopy extractor" argument on this gate: > The envelope stops the world outside the Netherlands; the cell's water stops the dry two thirds inside it. > The Groningen row is the one the design turns on: an empty cell is not free, and most of a streamed ring is empty. Hence the two gates below. There is no dry two thirds. Inside the envelope the second gate is very close to a constant `true`, so the request count is the same as if it were not there. ## Why no test caught it The two tests disagree about Groningen and neither joins the halves: - `crates/geo/src/vector_tiles.rs` — `the_water_probe_reads_an_undecoded_body` asserts `body_mentions_water(GRONINGEN_Z14)` is **true**. That is the correct answer and it is the one that breaks the gate. - `crates/cartopolis/src/systems/map/nav_marks.rs` — `a_foreign_or_dry_cell_asks_for_nothing` asserts `!should_fetch(GRONINGEN, false)`, passing the wet/dry answer in **by hand**. It can only ever prove the boolean is honoured, never that any real cell produces it. ## Where the seam is - `crates/cartopolis/src/systems/map/nav_marks.rs` — `should_fetch`, and the module note's "Two gates before a request is made" - `crates/geo/src/vector_tiles.rs` — `WATER_HINT_LAYERS` - `docs/notes/navigation-marks.md` — "Two gates, and why they are the whole cost argument" ## What a person might decide Narrowing the hint set does not rescue it: `water_polygons` alone is still 10/10. Three directions, for whoever picks this up: - **Accept the cost and correct the note.** 18 requests per fresh 3×3 ring, cached afterwards, against a service with an hour of `Cache-Control` and CORS `*`. That may simply be fine — but the note should say so rather than claim a saving it does not make. - **Gate on the fairway rather than on water.** A mark stands in a navigable channel, not in a ditch; the register's own extent is the country, but a coarse per-cell presence bitmap of the 18,474 points would be exact and tiny. - **Fetch the register once instead of per cell.** In the client's own compacted `WireMark` form the Waal's 43 marks are 4,802 bytes — about 112 bytes each — so the whole national register is roughly **2.1 MB**, less than the 3.8 MB the BGT paving costs for one dense cell. A single national fetch would delete both gates and every empty answer with them. Nothing here is user-visible: the marks draw correctly (`nav_marks=115` over the Waal, settled). This is the cost argument not holding, not a broken layer. <sub>Filed by the QA pass on #210. Not `autonomous` — a person decides whether this becomes work.</sub>

viberfox-agent added the

qa-gap

label

2026-08-30 07:56:17 +00:00

viberfox-agent added this to the Viberfox project

2026-08-30 07:56:31 +00:00

viberfox-agent referenced this issue

2026-08-30 08:06:12 +00:00

QA: what #206 shipped — Rijkswaterstaat vaarwegmarkeringen, PDOK OGC API: is it worth wiring in? #210

viberfox-agent referenced this issue

2026-08-30 08:22:26 +00:00

gap: the vaarwegmarkeringen vocabularies are wider than the census the parser was built on #213

viberfox-agent referenced this issue

2026-08-30 08:22:39 +00:00

gap: you cannot find out what a navigation mark is #214

viberfox-agent commented

2026-08-30 08:24:26 +00:00

Author

Collaborator

🤖 Considered by the 3-day retrospective (#218) and deliberately left unpromoted. Not because it is wrong — the measurement is solid, and 10 of 10 sampled Dutch cells passing the gate is the kind of finding this lane exists to produce.

It is left because the ticket's own "What a person might decide" section is a genuine three-way choice, and the three answers are not variations on one fix:

accept the cost and correct the note changes prose only,
gate on the fairway adds a national presence bitmap and a new artefact to serve,
fetch the register once, nationally (~2.1 MB) deletes both gates and the per-cell cache with them.

A machine can judge the outcome of any of the three — the request count on a cold start is a number. It cannot pick between them, and picking is most of the work. That is the line the retrospective drew: a gap where the fix is determined gets promoted (#213, #214), a gap where the decision is the deliverable stays here.

Worth saying plainly: nothing is broken. The marks draw correctly. What is false is the cost argument in docs/notes/navigation-marks.md, and the cheapest honest answer may simply be to correct the note.

_{Left for the maintainer by the retrospective on #218.}

🤖 **Considered by the 3-day retrospective (#218) and deliberately left unpromoted.** Not because it is wrong — the measurement is solid, and 10 of 10 sampled Dutch cells passing the gate is the kind of finding this lane exists to produce. It is left because the ticket's own "What a person might decide" section is a genuine three-way choice, and the three answers are not variations on one fix: - *accept the cost and correct the note* changes prose only, - *gate on the fairway* adds a national presence bitmap and a new artefact to serve, - *fetch the register once, nationally* (~2.1 MB) deletes both gates and the per-cell cache with them. A machine can judge the outcome of any of the three — the request count on a cold start is a number. It cannot pick between them, and picking is most of the work. That is the line the retrospective drew: a gap where the fix is determined gets promoted (#213, #214), a gap where the *decision* is the deliverable stays here. Worth saying plainly: nothing is broken. The marks draw correctly. What is false is the cost argument in `docs/notes/navigation-marks.md`, and the cheapest honest answer may simply be to correct the note. <sub>Left for the maintainer by the retrospective on #218.</sub>

viberfox-agent referenced this issue

2026-08-30 08:24:58 +00:00

Retrospective: the last 3 day(s), and what to do differently #218

viberfox-agent referenced this issue

2026-08-30 10:28:59 +00:00

gap: the level-crossing rail gate passes every tile, because rail is a Shortbread attribute key #236

viberfox-agent referenced this issue

2026-09-02 02:33:37 +00:00

gap: a cell's ground waits on api.pdok.nl before it is tessellated #267

viberfox-agent referenced this issue

2026-09-02 02:43:03 +00:00

QA: what #206 shipped — Rijkswaterstaat vaarwegmarkeringen, PDOK OGC API: is it worth wiring in? #266