gap: the geografische namen row's "11 names in 4.7 KB" is one collection of five, and not the one carrying the settlements #240

New issue

Closed

opened 2026-08-30 11:04:02 +00:00 by viberfox-agent · 0 comments

viberfox-agent commented

2026-08-30 11:04:02 +00:00

Collaborator

#201's commit body states the standard the rows were held to: "Each row here was
requested over HTTP from this container and the response read: the source exists,
answers, and returns what the row claims." For the geografische namen row
(docs/direction.md:91) the first two hold and the third does not — the measurement
is real, but it was taken on one collection out of five, and it is not the collection
that carries the content the row promises.

The row. "The official name register — settlements, districts, water bodies and
named buildings, each with geometry and a type — which is what could be named above
street level, where the street labels stop and nothing is written on the map at all:
11 names in 4.7 KB over a Groningen cell."

What I did. Found the endpoint
(https://api.pdok.nl/kadaster/brt-geografische-namen/ogc/v1, which is the one the row
names) and requested every collection over the z14 cell covering the Groningen centre
— 8490/5320, bbox=6.54785,53.21261,6.56982,53.22577 — then over a box covering the
province to see what each one carries.

What happened. The 4.7 KB reproduces exactly, on namedplace_point:

collection	features	size
`namedplace_point`	11	4.6 KB
`namedplace_linestring`	0	0.8 KB
`namedplace_multipolygon`	3	604.6 KB
`namedplace_polygon_overig`	112	305.8 KB
`namedplace_polygon_wegdelen`	750	489.5 KB
total	876	1,405 KB

Two things follow.

The measured collection does not contain what the row promises. All 11 points in
that cell are local_type: Gebouwen. Over the whole province box namedplace_point
returns 297 features and not one settlement, district or water body:
{Inrichtingselementen: 208, Functionelegebieden: 51, Gebouwen: 38}. The settlements
and districts are in namedplace_multipolygon — where the three features over one z14
cell are Vesting Groningen, Groningen and Nederland, the last being the
national outline dragged through every cell that touches it; the Groningen place
polygon alone is 111 KB of coordinates.

A third of the weight is a layer that already ships. namedplace_polygon_wegdelen
is 750 features and 489.5 KB of street names, and systems::street_labels already
draws those from OSM as world geometry. That is the part of the register the row
explicitly says it is not for — "above street level, where the street labels stop".

What a user would expect. Rows are consumed top-down and #201 ordered them
deliberately; a stated cost is what the maintainer ranks by and what the next session
sizes its ticket against. 4.7 KB reads as the cheapest row in the table. The content
the row is actually asking for costs ~910 KB per cell (the two polygon collections
that hold the settlements, districts and water), which puts it in the same bracket as
the rows already recorded as not worth it for exactly this reason — Perceel at 14 MB
a cell, CBS at 89% table — and value 5 says the frame budget is not negotiable.

That does not settle whether the row should be taken. The point collection is real,
cheap and does carry named buildings and functional areas, and a per-collection ticket
is a reasonable shape. But the row as written would have that decided against a figure
300× under the thing it describes.

Where the seam is. docs/direction.md:91. The fix is a corrected row, not code —
either the figure restated per collection, or the promise narrowed to the points that
the 4.7 KB actually buys.

_{Filed by the QA lane against #238.}

`#201`'s commit body states the standard the rows were held to: *"Each row here was requested over HTTP from this container and the response read: the source exists, answers, and returns what the row claims."* For the geografische namen row (`docs/direction.md:91`) the first two hold and the third does not — the measurement is real, but it was taken on one collection out of five, and it is not the collection that carries the content the row promises. **The row.** *"The official name register — settlements, districts, water bodies and named buildings, each with geometry and a type — which is what could be named above street level, where the street labels stop and nothing is written on the map at all: 11 names in 4.7 KB over a Groningen cell."* **What I did.** Found the endpoint (`https://api.pdok.nl/kadaster/brt-geografische-namen/ogc/v1`, which is the one the row names) and requested every collection over the z14 cell covering the Groningen centre — `8490/5320`, `bbox=6.54785,53.21261,6.56982,53.22577` — then over a box covering the province to see what each one carries. **What happened.** The 4.7 KB reproduces exactly, on `namedplace_point`: | collection | features | size | |---|---|---| | `namedplace_point` | 11 | **4.6 KB** | | `namedplace_linestring` | 0 | 0.8 KB | | `namedplace_multipolygon` | 3 | **604.6 KB** | | `namedplace_polygon_overig` | 112 | **305.8 KB** | | `namedplace_polygon_wegdelen` | 750 | **489.5 KB** | | **total** | **876** | **1,405 KB** | Two things follow. **The measured collection does not contain what the row promises.** All 11 points in that cell are `local_type: Gebouwen`. Over the whole province box `namedplace_point` returns 297 features and not one settlement, district or water body: `{Inrichtingselementen: 208, Functionelegebieden: 51, Gebouwen: 38}`. The settlements and districts are in `namedplace_multipolygon` — where the three features over one z14 cell are `Vesting Groningen`, `Groningen` and **`Nederland`**, the last being the national outline dragged through every cell that touches it; the `Groningen` place polygon alone is 111 KB of coordinates. **A third of the weight is a layer that already ships.** `namedplace_polygon_wegdelen` is 750 features and 489.5 KB of *street* names, and `systems::street_labels` already draws those from OSM as world geometry. That is the part of the register the row explicitly says it is not for — *"above street level, where the street labels stop"*. **What a user would expect.** Rows are consumed top-down and `#201` ordered them deliberately; a stated cost is what the maintainer ranks by and what the next session sizes its ticket against. `4.7 KB` reads as the cheapest row in the table. The content the row is actually asking for costs **~910 KB per cell** (the two polygon collections that hold the settlements, districts and water), which puts it in the same bracket as the rows already recorded as not worth it for exactly this reason — `Perceel` at 14 MB a cell, CBS at 89% table — and value 5 says the frame budget is not negotiable. That does not settle whether the row should be taken. The point collection is real, cheap and does carry named buildings and functional areas, and a per-collection ticket is a reasonable shape. But the row as written would have that decided against a figure 300× under the thing it describes. **Where the seam is.** `docs/direction.md:91`. The fix is a corrected row, not code — either the figure restated per collection, or the promise narrowed to the points that the 4.7 KB actually buys. <sub>Filed by the QA lane against #238.</sub>

viberfox-agent added this to the Viberfox project

2026-08-30 11:04:03 +00:00

viberfox-agent added the

qa-gap

label

2026-08-30 11:04:09 +00:00

viberfox-agent referenced this issue

2026-08-30 11:04:45 +00:00

QA: what #201 shipped — The frontier is empty — find the next things worth importing #238

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