jeroen/cartopolis

Watch

Fork 0

NWB road network: is it worth wiring in? #180

New issue

Closed

opened 2026-08-29 17:54:26 +00:00 by viberfox-agent · 6 comments

viberfox-agent commented

2026-08-29 17:54:26 +00:00

Collaborator

Problem

docs/direction.md:55 lists NWB road network as an unverified frontier candidate offering "measured carriageways, and bridge and tunnel geometry". The first half of this ticket is checking whether that is true and whether it is worth wiring in. It was checked, on 2026-08-29, against the live service. Both halves of the row's description are wrong, and the dataset is not worth wiring in.

What NWB actually is

The service is https://api.pdok.nl/rws/nationaal-wegenbestand-wegen/ogc/v1 (OGC API Features). It has exactly two collections: wegvakken (road sections) and hectopunten (hectometre posts). Its landing page declares rel="license" → CC0 1.0, so the licence question is settled and is not a blocker.

wegvakken geometry is multilinestring — the schema endpoint gives {"x-ogc-role": "primary-geometry", "format": "geometry-multilinestring"}. There is no polygon anywhere in the service. Its 60-odd properties are administrative: street name, road number, route number, road authority, house-number ranges, municipality, openlr, wvk_id / jte_id_beg / jte_id_end, bst_code, fow, frc, rel_hoogte.

So:

No measured carriageways. No width, no lane count, no carriageway polygon — a centreline and an authority code. The client's drawn ribbon takes its width from a per-class constant table, crates/geo/src/road_texture.rs:164-201 (motorway 22 m, residential 7 m, …), and NWB carries nothing that would replace it.
No bridge or tunnel geometry. Not a polygon, not an outline, not a clearance. The only structure-adjacent field is rel_hoogte, an integer grade level.

Why the gaps it could fill are already closed

Bridge geometry and height already work, from elsewhere. docs/notes/bridge-heights.md — Shortbread's bridges polygon layer supplies the outline, AHN's DSM-minus-DTM supplies a measured clearance, and resolve_bridge_decks lifts the deck and the road span onto it. NWB has nothing to add to that path.
Surveyed carriageway polygons were already considered and rejected, on a better source. crates/geo/src/paving.rs:7-35 argues it at length for the BGT: replacing the OSM ribbons loses the road texture, the kerb casing and the depth ladder, and "the BGT cannot supply any of that". NWB's centrelines are strictly weaker than the BGT polygons that lost that argument.
The grade separation rel_hoogte would supply is already recovered without it. docs/notes/grade-separation.md:99-114 records that Shortbread ships no layer, that this was expected to need an external source, and that the expectation was wrong: the dangle rule carries the fix (59 refusals to the grade rule's 4 on the Groningen fixture) and two_viaducts_crossing_are_not_a_junction covers the interchange case. The note says so explicitly: "This note previously said the interchange case needed a source carrying layer and that nothing here could recover it. That was wrong."

And rel_hoogte is mostly absent anyway — measured over an unpaged sample, 37 of 400 features non-null at Knooppunt Oudenrijn (bbox=5.045,52.060,5.085,52.085), 31 of 1000 over Groningen centre.

What it would cost, and what it would change

Paged with the rel="next" link over bbox=6.555,53.207,6.580,53.222 (~1.7 × 1.7 km of Groningen centre, comparable to the z14 cell the additive trees bin at — crates/cartopolis/src/systems/map/surveyed.rs:36): 1,392 features, 2.03 MB of raw GeoJSON, in two requests. The service caps a page at 1000 features whatever limit asks for and returns no numberMatched — the same truncation trap CLAUDE.md already records for the BAG WFS. That is the same order as the heaviest thing the client streams today (paving, 3.8 MB for the densest cell), spent on a second copy of centrelines the MVT already delivers for free.

It changes only the data behind the picture, not the picture. geobron_nm shows the geometry is largely BGT-derived and so more accurate than OSM's, but the client draws a constant-width ribbon around whatever centreline it is given; a decimetre-accurate centreline under an invented width is invisible.

Two pointers worth recording while they are in hand

Neither is scope here, but both are the thing somebody will reach for NWB expecting:

Lane counts exist, in a different service. WEGGEG, https://api.pdok.nl/rws/weggegevens/ogc/v1, collections wegvak_max_snelheden and wegvak_rijstroken, also CC0, joined to NWB on wvk_id (omschr: "2 -> 2"). It covers Rijkswaterstaat roads only — the same Groningen city-centre box returns 2 lane features against NWB's 1,392. It is a motorway dataset, not a city one.
Surveyed bridge polygons are in the BGT, which the project already extracts: the BGT OGC API exposes overbruggingsdeel and kunstwerkdeel_vlak / _lijn / _punt. If surveyed bridge geometry is ever wanted, it belongs to the "BGT, the remaining layers" row at docs/direction.md:54, not to this one. Interface confirmed; volume and usefulness are not checked.

Approach

Documentation only. No crate is touched, no Rust changes, no build.

1. docs/notes/nwb-road-network.md — a new note. This is the "directions abandoned without a diff" case docs/notes/README.md names, which has no commit to attach to. Front-matter per that file:

---
topic: nwb-road-network
triggers: [NWB, wegvakken, hectopunten, rel_hoogte, WEGGEG, rijstroken, wvk_id, road_width_m, "measured carriageway", "bridge geometry", PDOK, Rijkswaterstaat]
updated: 2026-08-29
---

Carry the findings above as prose, with the date and the method on every measurement. Link [[bridge-heights]]-style to bridge-heights.md, grade-separation.md and paving.rs's module doc, since each is where the corresponding gap was already closed.

2. docs/direction.md — record the result against the row. Remove | NWB road network | … | from the Candidates table (line 55) and add a new subsection under The frontier, after the candidates table:

**Checked and not taken.** The interface, licence and volume were confirmed and
the answer was no. Kept here so the check is not repeated:

| Source | Checked | Why not |
|---|---|---|
| NWB road network | 2026-08-29 | Centrelines with administrative attributes. No width, no carriageway polygons, no bridge or tunnel geometry — the row's description was wrong. Its one unique field, `rel_hoogte`, answers a question `grade-separation.md` already closed without it. CC0, so the licence was never the obstacle. [notes/nwb-road-network.md](notes/nwb-road-network.md) |

That table will be reused by the other seven rows, which is why it is a section rather than an annotation on one line.

docs/direction.md:4-5 says a session "may not rewrite it". This edit is authorised by the frontier paragraph itself, docs/direction.md:47-49 — "'this one is not worth it' is a valid result to record here" — and is confined to the frontier section. Do not touch the goal, the values, or the may/may-not sections.

3. The commit body must name which reading of docs/direction.md was applied. The ticket boilerplate refers to "the seven values at the top"; there is no numbered list of seven under that heading, so cite the sentences instead. The load-bearing one is the goal at docs/direction.md:10-16 — content comes from registries, and the world degrades to OSM where none covers it. NWB is a registry, and the check is whether it says anything OSM does not; on width, structures and grade it does not, and where it does the answer was already recovered. paving.rs:7-35 is the precedent that a more accurate outline is not on its own an upgrade.

Then close this ticket.

Acceptance criteria

docs/notes/nwb-road-network.md exists, with topic: / triggers: / updated: front-matter in the shape docs/notes/README.md specifies.
The note states the service base URL https://api.pdok.nl/rws/nationaal-wegenbestand-wegen/ogc/v1 and its two collections, wegvakken and hectopunten.
The note records the licence as CC0 1.0, and says it was read from the landing page's rel="license" link rather than from a wiki.
The note states that wegvakken geometry is multilinestring and that the service exposes no polygon, citing the /collections/wegvakken/schema endpoint.
The note records both measurements with their date (2026-08-29), their bbox and the command that produced them: 1,392 features / 2.03 MB raw GeoJSON over bbox=6.555,53.207,6.580,53.222, and the rel_hoogte null counts (969/1000 Groningen centre, 363/400 Oudenrijn).
The note records the 1000-feature page cap and the absent numberMatched, and points at the matching BAG WFS trap already in CLAUDE.md.
The note says why each of the three gaps NWB might have filled is already closed, linking bridge-heights.md, grade-separation.md and crates/geo/src/paving.rs, and names crates/geo/src/road_texture.rs:164 as where the ribbon width actually comes from.
The note carries the two pointers — WEGGEG (wegvak_rijstroken, CC0, joined on wvk_id, RWS roads only, 2 features over the Groningen box) and the BGT's overbruggingsdeel / kunstwerkdeel_* — each marked with exactly what was and was not verified.
The NWB road network row no longer appears in the Candidates table in docs/direction.md.
docs/direction.md has a "Checked and not taken" table under The frontier containing the NWB row, its check date and a reason, linking to the new note.
Nothing outside the frontier section of docs/direction.md is modified.
No file under crates/ is modified.
The commit body names the sentence of docs/direction.md the decision was taken under and why, per the repo's rule that a docs commit explaining a direction carries its reasoning.

Verification

No build. This branch changes no Rust, so the workspace gates (cargo fmt --check, the crate checks, scene-smoke) are untouched and nothing needs --shot or cargo shots.

Reproduce the numbers in the note (each is a read-only HTTP request; all were run from this container on 2026-08-29):

B=https://api.pdok.nl/rws/nationaal-wegenbestand-wegen/ogc/v1

# Collections, licence, and the geometry type.
curl -sL "$B?f=json" | jq '.links[] | select(.rel=="license")'
curl -sL "$B/collections?f=json" | jq -r '.collections[].id'
curl -sL "$B/collections/wegvakken/schema?f=json" | jq '.properties.geometry'

# Per-cell volume: page on the rel="next" link, NOT on offset (unsupported).
curl -sL "$B/collections/wegvakken/items?bbox=6.555,53.207,6.580,53.222&limit=1000&f=json"

# rel_hoogte at an interchange.
curl -sL "$B/collections/wegvakken/items?bbox=5.045,52.060,5.085,52.085&limit=400&f=json" \
  | jq '[.features[].properties.rel_hoogte] | group_by(.) | map({v:.[0],n:length})'

# WEGGEG lane coverage over the same city box (expect 2).
curl -sL "https://api.pdok.nl/rws/weggegevens/ogc/v1/collections/wegvak_rijstroken/items?bbox=6.555,53.207,6.580,53.222&limit=500&f=json" \
  | jq '.features | length'

Check the edits:

grep -n "NWB" docs/direction.md          # only under "Checked and not taken"
git diff --stat -- crates/               # must be empty
head -6 docs/notes/nwb-road-network.md   # front-matter present

Nothing here needs a workstation.

Out of scope

Any client, extractor or streamer code. There is no NWB streamer, no coverage manifest and no cartopy pipeline stage in this ticket. The conclusion is that none should be built.
Wiring WEGGEG lane counts into road_width_m. It is a real dataset with a real join key, it is CC0, and it would change the picture on motorways. It is also a different source, national-roads-only, and belongs to its own frontier row and its own ticket. Record the pointer; do not build it.
Reading the BGT's overbruggingsdeel / kunstwerkdeel_*. That is docs/direction.md:54, "BGT, the remaining layers". Its volume and usefulness are unmeasured.
Any change to the routing graph, level_of, the noding pass, or the bridge deck path. All three already work, and this ticket found no reason to touch them.
The other seven candidate rows. The "Checked and not taken" table is created here with one row in it; filling the rest is each row's own ticket.
Editing the goal, the values, or the may/may-not sections of docs/direction.md.

Open questions

None. The three questions the ticket poses were answered against the live service: the interface exists and is documented above, the licence is CC0 and permits caching and redistribution, and the dataset changes neither the picture nor any data the client is missing.

Sources: NWB Wegen (PDOK OGC API), Nationaal Wegen Bestand (NWB) — PDOK, Weggegevens (WEGGEG) OGC API, Wegkenmerk kunstwerken over de weg (RWS dataregister)

Branch: docs/180-nwb-not-worth-wiring

Original request

From the frontier in docs/direction.md: NWB road network — measured carriageways, and bridge and tunnel geometry.

The first half of this ticket is deciding whether it is worth doing at all:

Is there an interface a client or an extractor can use, and what does it cost per cell?
Does the licence allow redistributing what we would cache?
Does it change the picture, or only the data behind it?

Not worth it is a valid answer. Record it in docs/direction.md against this row
with the reason, and close this ticket — that is the result, not a failure.

Decide it yourself. This ticket is not being watched, so a question asked
here is a ticket that stops. The seven values at the top of docs/direction.md
exist to settle exactly this kind of ambiguity — pick the reading they support,
say in the commit body which one you applied and why, and build. Only a decision
that would need something nobody can derive from the repository — a credential, a
licence somebody must agree to, a choice about what the project is for — is a
reason to stop.

If it is worth doing, follow the shape the surveyed layers already use:
an extractor under tools/, a coverage manifest, a streamer that adds to what
is drawn rather than replacing it, and no unbounded per-frame upload.

_{Filed by the autopilot.}

_{🤖 Refined by the viberfox issue agent. Reply with @agent refine and what is wrong to have this rewritten.}

## Problem `docs/direction.md:55` lists **NWB road network** as an unverified frontier candidate offering "measured carriageways, and bridge and tunnel geometry". The first half of this ticket is checking whether that is true and whether it is worth wiring in. It was checked, on 2026-08-29, against the live service. **Both halves of the row's description are wrong, and the dataset is not worth wiring in.** ### What NWB actually is The service is `https://api.pdok.nl/rws/nationaal-wegenbestand-wegen/ogc/v1` (OGC API Features). It has exactly two collections: `wegvakken` (road sections) and `hectopunten` (hectometre posts). Its landing page declares `rel="license"` → **CC0 1.0**, so the licence question is settled and is not a blocker. `wegvakken` geometry is `multilinestring` — the schema endpoint gives `{"x-ogc-role": "primary-geometry", "format": "geometry-multilinestring"}`. There is no polygon anywhere in the service. Its 60-odd properties are administrative: street name, road number, route number, road authority, house-number ranges, municipality, `openlr`, `wvk_id` / `jte_id_beg` / `jte_id_end`, `bst_code`, `fow`, `frc`, `rel_hoogte`. So: - **No measured carriageways.** No width, no lane count, no carriageway polygon — a centreline and an authority code. The client's drawn ribbon takes its width from a per-class constant table, `crates/geo/src/road_texture.rs:164-201` (motorway 22 m, residential 7 m, …), and NWB carries nothing that would replace it. - **No bridge or tunnel geometry.** Not a polygon, not an outline, not a clearance. The only structure-adjacent field is `rel_hoogte`, an integer grade level. ### Why the gaps it *could* fill are already closed - **Bridge geometry and height already work, from elsewhere.** `docs/notes/bridge-heights.md` — Shortbread's `bridges` polygon layer supplies the outline, AHN's DSM-minus-DTM supplies a measured clearance, and `resolve_bridge_decks` lifts the deck and the road span onto it. NWB has nothing to add to that path. - **Surveyed carriageway polygons were already considered and rejected**, on a better source. `crates/geo/src/paving.rs:7-35` argues it at length for the BGT: replacing the OSM ribbons loses the road texture, the kerb casing and the depth ladder, and "the BGT cannot supply any of that". NWB's centrelines are strictly weaker than the BGT polygons that lost that argument. - **The grade separation `rel_hoogte` would supply is already recovered without it.** `docs/notes/grade-separation.md:99-114` records that Shortbread ships no `layer`, that this was expected to need an external source, and that **the expectation was wrong**: the *dangle* rule carries the fix (59 refusals to the grade rule's 4 on the Groningen fixture) and `two_viaducts_crossing_are_not_a_junction` covers the interchange case. The note says so explicitly: "This note previously said the interchange case needed a source carrying `layer` and that nothing here could recover it. That was wrong." And `rel_hoogte` is mostly absent anyway — measured over an unpaged sample, 37 of 400 features non-null at Knooppunt Oudenrijn (`bbox=5.045,52.060,5.085,52.085`), 31 of 1000 over Groningen centre. ### What it would cost, and what it would change Paged with the `rel="next"` link over `bbox=6.555,53.207,6.580,53.222` (~1.7 × 1.7 km of Groningen centre, comparable to the z14 cell the additive trees bin at — `crates/cartopolis/src/systems/map/surveyed.rs:36`): **1,392 features, 2.03 MB of raw GeoJSON, in two requests.** The service caps a page at 1000 features whatever `limit` asks for and returns no `numberMatched` — the same truncation trap CLAUDE.md already records for the BAG WFS. That is the same order as the heaviest thing the client streams today (paving, 3.8 MB for the densest cell), spent on a second copy of centrelines the MVT already delivers for free. It changes only the data behind the picture, not the picture. `geobron_nm` shows the geometry is largely BGT-derived and so more accurate than OSM's, but the client draws a constant-width ribbon around whatever centreline it is given; a decimetre-accurate centreline under an invented width is invisible. ### Two pointers worth recording while they are in hand Neither is scope here, but both are the thing somebody will reach for NWB expecting: - **Lane counts exist, in a different service.** WEGGEG, `https://api.pdok.nl/rws/weggegevens/ogc/v1`, collections `wegvak_max_snelheden` and `wegvak_rijstroken`, also CC0, joined to NWB on `wvk_id` (`omschr: "2 -> 2"`). It covers **Rijkswaterstaat roads only** — the same Groningen city-centre box returns **2** lane features against NWB's 1,392. It is a motorway dataset, not a city one. - **Surveyed bridge polygons are in the BGT**, which the project already extracts: the BGT OGC API exposes `overbruggingsdeel` and `kunstwerkdeel_vlak` / `_lijn` / `_punt`. If surveyed bridge geometry is ever wanted, it belongs to the "BGT, the remaining layers" row at `docs/direction.md:54`, not to this one. Interface confirmed; volume and usefulness are **not** checked. ## Approach Documentation only. No crate is touched, no Rust changes, no build. **1. `docs/notes/nwb-road-network.md`** — a new note. This is the "directions abandoned without a diff" case `docs/notes/README.md` names, which has no commit to attach to. Front-matter per that file: ```yaml --- topic: nwb-road-network triggers: [NWB, wegvakken, hectopunten, rel_hoogte, WEGGEG, rijstroken, wvk_id, road_width_m, "measured carriageway", "bridge geometry", PDOK, Rijkswaterstaat] updated: 2026-08-29 --- ``` Carry the findings above as prose, with the date and the method on every measurement. Link `[[bridge-heights]]`-style to `bridge-heights.md`, `grade-separation.md` and `paving.rs`'s module doc, since each is where the corresponding gap was already closed. **2. `docs/direction.md`** — record the result against the row. Remove `| NWB road network | … |` from the Candidates table (line 55) and add a new subsection under **The frontier**, after the candidates table: ```markdown **Checked and not taken.** The interface, licence and volume were confirmed and the answer was no. Kept here so the check is not repeated: | Source | Checked | Why not | |---|---|---| | NWB road network | 2026-08-29 | Centrelines with administrative attributes. No width, no carriageway polygons, no bridge or tunnel geometry — the row's description was wrong. Its one unique field, `rel_hoogte`, answers a question `grade-separation.md` already closed without it. CC0, so the licence was never the obstacle. [notes/nwb-road-network.md](notes/nwb-road-network.md) | ``` That table will be reused by the other seven rows, which is why it is a section rather than an annotation on one line. `docs/direction.md:4-5` says a session "may not rewrite it". This edit is authorised by the frontier paragraph itself, `docs/direction.md:47-49` — "'this one is not worth it' is a valid result to record here" — and is confined to the frontier section. Do not touch the goal, the values, or the may/may-not sections. **3. The commit body** must name which reading of `docs/direction.md` was applied. The ticket boilerplate refers to "the seven values at the top"; there is no numbered list of seven under that heading, so cite the sentences instead. The load-bearing one is the goal at `docs/direction.md:10-16` — content comes from registries, and the world degrades to OSM where none covers it. NWB is a registry, and the check is whether it says anything OSM does not; on width, structures and grade it does not, and where it does the answer was already recovered. `paving.rs:7-35` is the precedent that a more accurate outline is not on its own an upgrade. Then close this ticket. ## Acceptance criteria - [ ] `docs/notes/nwb-road-network.md` exists, with `topic:` / `triggers:` / `updated:` front-matter in the shape `docs/notes/README.md` specifies. - [ ] The note states the service base URL `https://api.pdok.nl/rws/nationaal-wegenbestand-wegen/ogc/v1` and its two collections, `wegvakken` and `hectopunten`. - [ ] The note records the licence as **CC0 1.0**, and says it was read from the landing page's `rel="license"` link rather than from a wiki. - [ ] The note states that `wegvakken` geometry is `multilinestring` and that the service exposes no polygon, citing the `/collections/wegvakken/schema` endpoint. - [ ] The note records both measurements with their date (2026-08-29), their bbox and the command that produced them: 1,392 features / 2.03 MB raw GeoJSON over `bbox=6.555,53.207,6.580,53.222`, and the `rel_hoogte` null counts (969/1000 Groningen centre, 363/400 Oudenrijn). - [ ] The note records the 1000-feature page cap and the absent `numberMatched`, and points at the matching BAG WFS trap already in `CLAUDE.md`. - [ ] The note says why each of the three gaps NWB might have filled is already closed, linking `bridge-heights.md`, `grade-separation.md` and `crates/geo/src/paving.rs`, and names `crates/geo/src/road_texture.rs:164` as where the ribbon width actually comes from. - [ ] The note carries the two pointers — WEGGEG (`wegvak_rijstroken`, CC0, joined on `wvk_id`, RWS roads only, 2 features over the Groningen box) and the BGT's `overbruggingsdeel` / `kunstwerkdeel_*` — each marked with exactly what was and was not verified. - [ ] The `NWB road network` row no longer appears in the Candidates table in `docs/direction.md`. - [ ] `docs/direction.md` has a "Checked and not taken" table under **The frontier** containing the NWB row, its check date and a reason, linking to the new note. - [ ] Nothing outside the frontier section of `docs/direction.md` is modified. - [ ] No file under `crates/` is modified. - [ ] The commit body names the sentence of `docs/direction.md` the decision was taken under and why, per the repo's rule that a `docs` commit explaining a direction carries its reasoning. ## Verification No build. This branch changes no Rust, so the workspace gates (`cargo fmt --check`, the crate checks, `scene-smoke`) are untouched and nothing needs `--shot` or `cargo shots`. Reproduce the numbers in the note (each is a read-only HTTP request; all were run from this container on 2026-08-29): ```bash B=https://api.pdok.nl/rws/nationaal-wegenbestand-wegen/ogc/v1 # Collections, licence, and the geometry type. curl -sL "$B?f=json" | jq '.links[] | select(.rel=="license")' curl -sL "$B/collections?f=json" | jq -r '.collections[].id' curl -sL "$B/collections/wegvakken/schema?f=json" | jq '.properties.geometry' # Per-cell volume: page on the rel="next" link, NOT on offset (unsupported). curl -sL "$B/collections/wegvakken/items?bbox=6.555,53.207,6.580,53.222&limit=1000&f=json" # rel_hoogte at an interchange. curl -sL "$B/collections/wegvakken/items?bbox=5.045,52.060,5.085,52.085&limit=400&f=json" \ | jq '[.features[].properties.rel_hoogte] | group_by(.) | map({v:.[0],n:length})' # WEGGEG lane coverage over the same city box (expect 2). curl -sL "https://api.pdok.nl/rws/weggegevens/ogc/v1/collections/wegvak_rijstroken/items?bbox=6.555,53.207,6.580,53.222&limit=500&f=json" \ | jq '.features | length' ``` Check the edits: ```bash grep -n "NWB" docs/direction.md # only under "Checked and not taken" git diff --stat -- crates/ # must be empty head -6 docs/notes/nwb-road-network.md # front-matter present ``` Nothing here needs a workstation. ## Out of scope - **Any client, extractor or streamer code.** There is no NWB streamer, no coverage manifest and no cartopy pipeline stage in this ticket. The conclusion is that none should be built. - **Wiring WEGGEG lane counts into `road_width_m`.** It is a real dataset with a real join key, it is CC0, and it would change the picture on motorways. It is also a different source, national-roads-only, and belongs to its own frontier row and its own ticket. Record the pointer; do not build it. - **Reading the BGT's `overbruggingsdeel` / `kunstwerkdeel_*`.** That is `docs/direction.md:54`, "BGT, the remaining layers". Its volume and usefulness are unmeasured. - **Any change to the routing graph, `level_of`, the noding pass, or the bridge deck path.** All three already work, and this ticket found no reason to touch them. - **The other seven candidate rows.** The "Checked and not taken" table is created here with one row in it; filling the rest is each row's own ticket. - **Editing the goal, the values, or the may/may-not sections of `docs/direction.md`.** ## Open questions None. The three questions the ticket poses were answered against the live service: the interface exists and is documented above, the licence is CC0 and permits caching and redistribution, and the dataset changes neither the picture nor any data the client is missing. Sources: [NWB Wegen (PDOK OGC API)](https://api.pdok.nl/rws/nationaal-wegenbestand-wegen/ogc/v1?f=html), [Nationaal Wegen Bestand (NWB) — PDOK](https://www.pdok.nl/ogc-apis/-/article/nationaal-wegen-bestand-nwb-wegen), [Weggegevens (WEGGEG) OGC API](https://api.pdok.nl/rws/weggegevens/ogc/v1?f=html), [Wegkenmerk kunstwerken over de weg (RWS dataregister)](https://maps.rijkswaterstaat.nl/dataregister-publicatie/srv/api/records/9664c8f7-2640-4e26-99b2-1b9e7313d7e8) --- Branch: `docs/180-nwb-not-worth-wiring` <details><summary>Original request</summary> From the frontier in [`docs/direction.md`](../src/branch/main/docs/direction.md): **NWB road network** — measured carriageways, and bridge and tunnel geometry. The first half of this ticket is deciding whether it is worth doing at all: - Is there an interface a client or an extractor can use, and what does it cost per cell? - Does the licence allow redistributing what we would cache? - Does it change the picture, or only the data behind it? **Not worth it is a valid answer.** Record it in `docs/direction.md` against this row with the reason, and close this ticket — that is the result, not a failure. **Decide it yourself.** This ticket is not being watched, so a question asked here is a ticket that stops. The seven values at the top of `docs/direction.md` exist to settle exactly this kind of ambiguity — pick the reading they support, say in the commit body which one you applied and why, and build. Only a decision that would need something nobody can derive from the repository — a credential, a licence somebody must agree to, a choice about what the project is *for* — is a reason to stop. If it is worth doing, follow the shape the surveyed layers already use: an extractor under `tools/`, a coverage manifest, a streamer that adds to what is drawn rather than replacing it, and no unbounded per-frame upload. Filed by the autopilot.  </details> 🤖 Refined by the viberfox issue agent. Reply with **@agent refine** and what is wrong to have this rewritten.

viberfox-agent added the

labels

2026-08-29 17:54:26 +00:00

viberfox-agent added this to the Viberfox project

2026-08-29 17:54:37 +00:00

viberfox-agent commented

2026-08-29 17:54:39 +00:00

Author

Collaborator

🤖 Refining this before anything gets built — reading the code, no branch, no commits. If it turns out I'd have to guess at the requirements I'll stop and ask instead.

viberfox-agent referenced this issue

2026-08-29 18:00:11 +00:00

Autopilot log #181

viberfox-agent added

agent:refined

and removed

agent:refining

labels

2026-08-29 18:02:34 +00:00

viberfox-agent commented

2026-08-29 18:02:35 +00:00

Author

Collaborator

🤖 Refined. The description above is now the spec; I'll pick it up for implementation on the next poll.

If the direction is wrong, say so now — @agent refine with a correction rewrites it, and agent:skip stops me.

_{🤖 viberfox issue agent on the VPS — 39 turns · $3.16 · session 0a2ff303-5d3e-459b-b1b7-5906771b60f3. Reply with @agent to continue this session.}

🤖 **Refined.** The description above is now the spec; I'll pick it up for implementation on the next poll. If the direction is wrong, say so now — **@agent refine** with a correction rewrites it, and `agent:skip` stops me. --- 🤖 viberfox issue agent on the VPS — 39 turns · $3.16 · session `0a2ff303-5d3e-459b-b1b7-5906771b60f3`. Reply with **@agent** to continue this session.

viberfox-agent added

agent:running

and removed

agent:refined

labels

2026-08-29 18:02:48 +00:00

viberfox-agent commented

2026-08-29 18:03:11 +00:00

Author

Collaborator

🤖 Picked this up — working on branch docs/180-nwb-not-worth-wiring in a fresh worktree on the VPS. I'll report back here when I'm done.

_{Label an issue agent:skip to keep me off it, or driven to keep it in a session you are driving.}

🤖 Picked this up — working on branch `docs/180-nwb-not-worth-wiring` in a fresh worktree on the VPS. I'll report back here when I'm done. Label an issue `agent:skip` to keep me off it, or `driven` to keep it in a session you are driving.

viberfox-agent referenced this issue from a commit

2026-08-29 18:08:21 +00:00

docs(direction): NWB is centrelines, and is not worth wiring in

viberfox-agent referenced this issue from a commit

2026-08-29 18:10:16 +00:00

docs(direction): NWB is centrelines, and is not worth wiring in

viberfox-agent commented

2026-08-29 18:11:00 +00:00

Author

Collaborator

I checked NWB against the live service and it is not worth wiring in. The change is documentation only.

What I changed

Two files, no code:

Added docs/notes/nwb-road-network.md — the check, with every measurement dated and its command written down so nobody repeats it.
Changed docs/direction.md — removed the NWB road network row from the Candidates table and added a new "Checked and not taken" table under The frontier holding it. The goal, the values and the may/may-not sections are untouched.

Why not

The frontier row promised "measured carriageways, and bridge and tunnel geometry". Both halves are wrong:

No carriageways. wegvakken is multilinestring, hectopunten is multipoint, and there is no polygon anywhere in the service. The 60-odd properties are administrative — no width, no lane count. The road ribbon's width comes from a constant table in crates/geo/src/road_texture.rs:164, and NWB carries nothing to replace it.
No bridge or tunnel geometry. No outline, no clearance. The only structure-adjacent field is rel_hoogte, an integer grade level — and it is null in 969 of 1000 features over Groningen centre, 363 of 400 at Knooppunt Oudenrijn.
Grade separation is already recovered without it. grade-separation.md records that the dangle rule handles the interchange case and that the earlier expectation of needing an external source was wrong.

Cost, if it were wired: 1,392 features and 2.03 MB of raw GeoJSON over 1.7 × 1.7 km of Groningen centre — the order of the heaviest thing the client streams today, for a second copy of centrelines the map tiles already deliver. The licence is CC0 1.0, so terms were never the obstacle.

How I verified it

I re-ran every measurement in the ticket against the live service myself rather than transcribing them. All reproduced exactly. I also confirmed two things the ticket did not: offset is rejected with a 400, so paging must follow the rel="next" link; and bst_code is a carriageway subtype naming no structure, which is what makes "no bridge geometry" a statement about the whole schema rather than about one field.

cargo fmt --check passes across the workspace. No crate is touched, so the crate checks and scene-smoke are unaffected — git diff origin/main -- crates/ is empty. Nothing here needs a visual check.

Two things for you

Pointers I recorded but did not build. Lane counts do exist, in WEGGEG (wegvak_rijstroken, CC0, joins to NWB on wvk_id) — but it covers Rijkswaterstaat roads only: 2 lane features over the same Groningen box against NWB's 1,392. It is a motorway dataset and belongs to its own frontier row. Surveyed bridge polygons are in the BGT (overbruggingsdeel, kunstwerkdeel_*); I confirmed the collections exist and nothing else. Both are marked in the note with exactly what was and was not checked.

The worktree I was handed was broken. Its .git file pointed at an admin directory under /home/agent/viberfox/.git/worktrees/ that does not exist, so every git command answered fatal: not a git repository: (null). git worktree repair cannot fix that. I made a second worktree on the same branch at .claude/worktrees/docs-180-nwb-repair, copied the edits across and committed there. The branch is pushed and correct; the two leftover directories are worth a sweep when convenient.

Branch docs/180-nwb-not-worth-wiring is pushed at 4fd5cb2. The commit body names the goal at docs/direction.md:10-16 as the reading applied — content comes from registries, so the test for a registry is whether it says anything OpenStreetMap does not, and on width, structures and grade it does not.

No commits were made.

_{🤖 viberfox issue agent on the VPS — 55 turns · $4.27 · session c4a0440c-220f-4a49-b101-d34632b51d2c. Reply with @agent to continue this session.}

I checked NWB against the live service and it is not worth wiring in. The change is documentation only. ## What I changed Two files, no code: - **Added `docs/notes/nwb-road-network.md`** — the check, with every measurement dated and its command written down so nobody repeats it. - **Changed `docs/direction.md`** — removed the `NWB road network` row from the Candidates table and added a new "Checked and not taken" table under **The frontier** holding it. The goal, the values and the may/may-not sections are untouched. ## Why not The frontier row promised "measured carriageways, and bridge and tunnel geometry". Both halves are wrong: - **No carriageways.** `wegvakken` is multilinestring, `hectopunten` is multipoint, and there is no polygon anywhere in the service. The 60-odd properties are administrative — no width, no lane count. The road ribbon's width comes from a constant table in `crates/geo/src/road_texture.rs:164`, and NWB carries nothing to replace it. - **No bridge or tunnel geometry.** No outline, no clearance. The only structure-adjacent field is `rel_hoogte`, an integer grade level — and it is null in 969 of 1000 features over Groningen centre, 363 of 400 at Knooppunt Oudenrijn. - **Grade separation is already recovered without it.** `grade-separation.md` records that the dangle rule handles the interchange case and that the earlier expectation of needing an external source was wrong. Cost, if it were wired: 1,392 features and 2.03 MB of raw GeoJSON over 1.7 × 1.7 km of Groningen centre — the order of the heaviest thing the client streams today, for a second copy of centrelines the map tiles already deliver. The licence is CC0 1.0, so terms were never the obstacle. ## How I verified it I re-ran every measurement in the ticket against the live service myself rather than transcribing them. All reproduced exactly. I also confirmed two things the ticket did not: `offset` is rejected with a 400, so paging must follow the `rel="next"` link; and `bst_code` is a carriageway subtype naming no structure, which is what makes "no bridge geometry" a statement about the whole schema rather than about one field. `cargo fmt --check` passes across the workspace. No crate is touched, so the crate checks and `scene-smoke` are unaffected — `git diff origin/main -- crates/` is empty. Nothing here needs a visual check. ## Two things for you **Pointers I recorded but did not build.** Lane counts do exist, in WEGGEG (`wegvak_rijstroken`, CC0, joins to NWB on `wvk_id`) — but it covers Rijkswaterstaat roads only: 2 lane features over the same Groningen box against NWB's 1,392. It is a motorway dataset and belongs to its own frontier row. Surveyed bridge polygons are in the BGT (`overbruggingsdeel`, `kunstwerkdeel_*`); I confirmed the collections exist and nothing else. Both are marked in the note with exactly what was and was not checked. **The worktree I was handed was broken.** Its `.git` file pointed at an admin directory under `/home/agent/viberfox/.git/worktrees/` that does not exist, so every git command answered `fatal: not a git repository: (null)`. `git worktree repair` cannot fix that. I made a second worktree on the same branch at `.claude/worktrees/docs-180-nwb-repair`, copied the edits across and committed there. The branch is pushed and correct; the two leftover directories are worth a sweep when convenient. Branch `docs/180-nwb-not-worth-wiring` is pushed at `4fd5cb2`. The commit body names the goal at `docs/direction.md:10-16` as the reading applied — content comes from registries, so the test for a registry is whether it says anything OpenStreetMap does not, and on width, structures and grade it does not. _No commits were made._ --- 🤖 viberfox issue agent on the VPS — 55 turns · $4.27 · session `c4a0440c-220f-4a49-b101-d34632b51d2c`. Reply with **@agent** to continue this session.

viberfox-agent added

agent:done

and removed

agent:running

labels

2026-08-29 18:11:00 +00:00

viberfox-agent referenced this issue from a pull request that will close it,

2026-08-29 18:54:27 +00:00

NWB road network: is it worth wiring in? #184

viberfox-agent

2026-08-29 18:54:31 +00:00