jeroen/cartopolis
Watch
1
0
Fork
You've already forked cartopolis
 0
Code Issues Pull requests 4 Projects 1 Releases 1 Packages Activity Actions

Rijkswaterstaat water levels: is it worth wiring in? #197

New issue
Closed
opened 2026-08-30 00:01:12 +00:00 by viberfox-agent · 7 comments
viberfox-agent commented 2026-08-30 00:01:12 +00:00
Collaborator
Copy link

Problem

docs/direction.md carries Rijkswaterstaat water levels — "canal and river surfaces at their real height" as an unverified candidate. The ticket's first half is the worth-check: interface, licence, per-cell cost, and whether it changes the picture.

Three of those four are already answered, from read-only HTTP probes run during this refinement on 2026-08-30 (no build, no repo change). They are recorded here so nobody repeats them:

Interface — exists, keyless, and the old one is being retired. https://waterwebservices.rijkswaterstaat.nl/… now 301s to a migration notice. The live service is https://ddapi20-waterwebservices.rijkswaterstaat.nl/:

  • POST /METADATASERVICES/OphalenCatalogus with {"CatalogusFilter":{"Compartimenten":true,"Grootheden":true}} → 200, 1,573,954 bytes. LocatieLijst holds 2,498 locations, each with Lat/Lon in ETRS89 (≈WGS84). Of those, 705 are joined to the WATHTE (Waterhoogte) quantity through AquoMetadataLocatieLijst.
  • POST /ONLINEWAARNEMINGENSERVICES/OphalenWaarnemingen for {"Locatie":{"Code":"groningen"}}, Grootheid: WATHTE, ProcesType: meting, one hour → 200, 3,374 bytes, 7 measurements (10-minute cadence). Eenheid: cm, Hoedanigheid: NAP, value −91 cm NAP. An X-API-KEY header is requested but not enforced.

Licence — CC0. https://rijkswaterstaatdata.nl/waterdata/ states "Op de inhoud van de WaterWebservices is de Creative Commons zero verklaring (CC0) van toepassing." Redistribution of a cached extract is allowed. The licence was never the obstacle.

Coverage — stations, not a field. Nearest WATHTE station to each centre, haversine over the 705 coordinates:

centre nearest ≤1 km ≤3.2 km ≤10 km
Groningen Grote Markt 1.95 km (groningen) 0 1 3
Amsterdam Dam 1.53 km (buiksloot) 0 1 7
Utrecht Domplein 6.84 km (nieuwegein.doorslag) 0 0 4
Rotterdam Blaak 1.19 km (rotterdam.nieuwemaas.boompjes) 0 3 11
Leiden centre 8.74 km (katwijk) 0 0 2
Nijmegen Waal 0.45 km (nijmegen) 2 4 10

Unlike the NDW check, the stations are not absent from cities. But a station is a point with a code and a name; nothing in the response says which water body its level applies to. Attaching groningen's −0.91 m to a Diepenring polygon is a nearest-point guess against value 1, and the register is Rijkswaterstaat's main-water network while a city canal is usually a water board's boezem.

The fourth question is the one the code answers, and it answers "no". The client cannot draw water below the ground it sits in:

  • A water surface takes one level for the whole polygon — terrain.level_over(…) at crates/cartopolis/src/systems/map/map_geometry.rs:1786, the median of the terrain field's samples under it (crates/cartopolis/src/systems/map/terrain.rs:218).
  • Over a canal, AHN's DTM is no-data (crates/cartopolis/src/systems/map/height.rs:583), and FILL_PASSES dilates the banks inward over ~150 m (crates/cartopolis/src/systems/map/terrain.rs:47, :84). So today's water level is the quay level, filled in from the sides.
  • Water is one rung of a millimetre-thick coplanar stack: y_offset −0.0035 m (crates/geo/src/vector_tiles.rs:1283), depth_rung 4.0 (crates/geo/src/vector_tiles.rs:1350). The whole ladder spans 8 mm.
  • Underneath it, the basemap clipmap is eight opaque layers deep and nothing cuts holes in it (crates/cartopolis/src/systems/map/map_stream.rs:884). Its finest level rests at y = −0.03 m (crates/cartopolis/src/systems/map/map_stream.rs:627), 2.65 cm below the water sheet.
  • The depth bias cannot rescue it: water's 256 units read as "~15 cm at 5 km and ~150 µm at 10 m" and "cannot punch through a building, which is separated by metres of honest depth" (crates/geo/src/vector_tiles.rs:1329).

Drop a canal to its register level — order of a metre below the quay — and it goes under an opaque, continuous basemap plane with no bank geometry anywhere to close the gap. There is no canal wall in this tree; the surface stack is a sheet, not a solid.

Approach

Documentation only. No crate is touched, so nothing here compiles.

  1. Write docs/notes/rijkswaterstaat-water-levels.md, in the shape of docs/notes/ndw-traffic.md — topic: / triggers: / updated: front matter per docs/notes/README.md, title of the form "…: checked and not taken". It records: the endpoint move off waterwebservices.rijkswaterstaat.nl, the two request bodies and their measured sizes, the CC0 statement and where it is published, the 705-station coverage table above, the absence of any water-body identifier on a station, and the geometry finding with its citations. It also states plainly what would have to exist before the row could be revisited: a hole punched in the clipmap under water polygons, and bank/quay geometry to close the vertical gap. Filing that as a follow-up ticket is optional and not required by this ticket.
  2. Move the Rijkswaterstaat water levels row in docs/direction.md from Candidates, unverified to Checked and not taken, with a Checked date of the day the branch is written, a one-paragraph reason in the table's existing style, and a link to the new note.
  3. Add a cross-reference to the note from docs/notes/terrain-relief.md, beside its existing statement that water takes one level for the whole body — that is where the next person asking this question will land.
  4. Commit body names the values applied (see below) and Refs #197. Conventional Commits, docs(direction): scope, matching 24f2169.

The values that settle it, to be stated in the commit body as docs/direction.md requires:

  • Value 5, the frame budget and value 3, degrade never break are the decisive pair: the change the row asks for is not a data wire-in but a rewrite of the ground sheet into a solid, and the intermediate state — water a metre under an opaque basemap — is a broken picture, not a degraded one.
  • Value 1, measured beats plausible, is the case for the row and loses on the join: the register measures 705 points and says nothing about which polygon each one governs, so every canal's level would be a nearest-station guess.
  • Value 6, ship the smallest thing a machine can judge: with no visible change available, there is no --dump-state field an --expect could hold.

Acceptance criteria

  • docs/notes/rijkswaterstaat-water-levels.md exists, with topic:/triggers:/updated: front matter matching docs/notes/README.md.
  • The note names both live endpoints (METADATASERVICES/OphalenCatalogus, ONLINEWAARNEMINGENSERVICES/OphalenWaarnemingen), states that the pre-migration host is being retired, and records the request bodies that were used.
  • The note records the licence as CC0 and cites https://rijkswaterstaatdata.nl/waterdata/ as where that is stated.
  • The note records the volume: catalogue bytes, total locations, WATHTE locations, and the bytes/measurement count for one station-hour.
  • The note carries the six-city nearest-station table, with the date the distances were computed.
  • The note states that a station carries no water-body identifier, and that a polygon-to-station join would therefore be by proximity.
  • The note states the geometry finding and cites at least map_geometry.rs:1786, terrain.rs:218, vector_tiles.rs:1283, map_stream.rs:627 and map_stream.rs:884.
  • The note names what would have to exist first (clipmap hole under water polygons + bank geometry) so the row can be revisited rather than re-checked.
  • docs/direction.md's Candidates, unverified table no longer contains the Rijkswaterstaat row; the Checked and not taken table does, with a date, a reason and a link to the note.
  • docs/notes/terrain-relief.md links to the new note where it discusses water taking one level.
  • The commit body names the values applied and their reasoning, and carries Refs #197. No Co-Authored-By trailer.
  • No file outside docs/ is modified.

Verification

The numbers above were measured; re-running is optional confirmation, not a gate. Each is one read-only request:

# catalogue: status, bytes
curl -s -o /tmp/cat.json -w '%{http_code} %{size_download}\n' \
  -X POST https://ddapi20-waterwebservices.rijkswaterstaat.nl/METADATASERVICES/OphalenCatalogus \
  -H 'Content-Type: application/json' \
  -d '{"CatalogusFilter":{"Compartimenten":true,"Grootheden":true}}'

# one station-hour of measured water height
curl -s -o /tmp/obs.json -w '%{http_code} %{size_download}\n' \
  -X POST https://ddapi20-waterwebservices.rijkswaterstaat.nl/ONLINEWAARNEMINGENSERVICES/OphalenWaarnemingen \
  -H 'Content-Type: application/json' \
  -d '{"Locatie":{"Code":"groningen"},
       "AquoPlusWaarnemingMetadata":{"AquoMetadata":{"Compartiment":{"Code":"OW"},
         "Grootheid":{"Code":"WATHTE"},"ProcesType":"meting"}},
       "Periode":{"Begindatumtijd":"2026-08-29T20:00:00.000+02:00",
                  "Einddatumtijd":"2026-08-29T21:00:00.000+02:00"}}'

Station counts and distances come from /tmp/cat.json alone: join AquoMetadataLijst (Grootheid.Code == "WATHTE") to LocatieLijst through AquoMetadataLocatieLijst, then haversine against the six centres.

One number was deliberately not taken here, because getting it is work and this pass decides whether to build. The gap between today's AHN-derived canal level and the register's NAP level is measurable without the client, via one AHN DTM box over a Groningen canal:

https://service.pdok.nl/rws/ahn/wcs/v1_0?service=WCS&version=1.0.0&request=GetCoverage&coverage=dtm_05m&...

(the request shape is HeightRequest in crates/cartopolis/src/systems/map/height.rs; the anchor's absolute NAP datum is HeightLayer::ground_m, height.rs:295, which docs/notes/flood-defences.md already uses to convert a NAP crest into anchor-relative metres). Include it in the note if taken. It does not change the conclusion either way: above ~8 mm the coplanar stack cannot hold the drop and the basemap covers the water; below it there is nothing to show. Say which of the two the measurement lands on, or say it was not measured.

Nothing to build and nothing to render. No cargo command applies — no crate is touched. No --shot or cargo shots is needed, which is as well, since this container cannot render.

Nothing needs a workstation. If the branch grows any non-docs change, that is out of scope and the ticket has changed shape.

Out of scope

  • Any client or extractor code. No tools/ extractor, no coverage manifest, no streamer, no cartopy pipeline. The "if it is worth doing" half of the ticket does not fire.
  • The clipmap hole and bank/quay geometry. They are what a future revisit would need; building them is not this ticket, and the note only names them.
  • A water-level readout in the UI. The row promises surfaces at their real height, not a number in a panel; adding one would be inventing scope.
  • The water boards' peilgebied / peilbesluit polygons (target levels as areas, published alongside the waterkering lines systems::dikes already streams). They are a different source with a different provider and would be a different frontier row, not this one. Mention as a pointer if useful; do not check or spec it here.
  • Tidal animation on the big rivers. Same geometry obstacle, and the row does not ask for it.
  • The 3D basisvoorziening row in the same candidates table. Untouched.
  • PROTOCOL_HISTORY, any migration, CHANGELOG.md. Docs-only; 24f2169 did not touch the changelog either.

Open questions

None.

Branch: docs/197-rijkswaterstaat-water-levels

Original request

From the frontier in docs/direction.md: Rijkswaterstaat water levels — canal and river surfaces at their real height.

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` carries **Rijkswaterstaat water levels — "canal and river surfaces at their real height"** as an unverified candidate. The ticket's first half is the worth-check: interface, licence, per-cell cost, and whether it changes the picture. Three of those four are already answered, from read-only HTTP probes run during this refinement on 2026-08-30 (no build, no repo change). They are recorded here so nobody repeats them: **Interface — exists, keyless, and the old one is being retired.** `https://waterwebservices.rijkswaterstaat.nl/…` now 301s to a migration notice. The live service is `https://ddapi20-waterwebservices.rijkswaterstaat.nl/`: - `POST /METADATASERVICES/OphalenCatalogus` with `{"CatalogusFilter":{"Compartimenten":true,"Grootheden":true}}` → **200, 1,573,954 bytes**. `LocatieLijst` holds **2,498** locations, each with `Lat`/`Lon` in ETRS89 (≈WGS84). Of those, **705** are joined to the `WATHTE` (Waterhoogte) quantity through `AquoMetadataLocatieLijst`. - `POST /ONLINEWAARNEMINGENSERVICES/OphalenWaarnemingen` for `{"Locatie":{"Code":"groningen"}}`, `Grootheid: WATHTE`, `ProcesType: meting`, one hour → **200, 3,374 bytes, 7 measurements** (10-minute cadence). `Eenheid: cm`, `Hoedanigheid: NAP`, value **−91 cm NAP**. An `X-API-KEY` header is requested but not enforced. **Licence — CC0.** `https://rijkswaterstaatdata.nl/waterdata/` states "Op de inhoud van de WaterWebservices is de Creative Commons zero verklaring (CC0) van toepassing." Redistribution of a cached extract is allowed. The licence was never the obstacle. **Coverage — stations, not a field.** Nearest `WATHTE` station to each centre, haversine over the 705 coordinates: | centre | nearest | ≤1 km | ≤3.2 km | ≤10 km | |---|---|---|---|---| | Groningen Grote Markt | 1.95 km (`groningen`) | 0 | 1 | 3 | | Amsterdam Dam | 1.53 km (`buiksloot`) | 0 | 1 | 7 | | Utrecht Domplein | 6.84 km (`nieuwegein.doorslag`) | 0 | 0 | 4 | | Rotterdam Blaak | 1.19 km (`rotterdam.nieuwemaas.boompjes`) | 0 | 3 | 11 | | Leiden centre | 8.74 km (`katwijk`) | 0 | 0 | 2 | | Nijmegen Waal | 0.45 km (`nijmegen`) | 2 | 4 | 10 | Unlike the NDW check, the stations are not absent from cities. But a station is a point with a code and a name; **nothing in the response says which water body its level applies to.** Attaching `groningen`'s −0.91 m to a Diepenring polygon is a nearest-point guess against value 1, and the register is Rijkswaterstaat's main-water network while a city canal is usually a water board's boezem. **The fourth question is the one the code answers, and it answers "no".** The client cannot draw water below the ground it sits in: - A water surface takes **one level for the whole polygon** — `terrain.level_over(…)` at `crates/cartopolis/src/systems/map/map_geometry.rs:1786`, the median of the terrain field's samples under it (`crates/cartopolis/src/systems/map/terrain.rs:218`). - Over a canal, AHN's DTM is no-data (`crates/cartopolis/src/systems/map/height.rs:583`), and `FILL_PASSES` dilates the banks inward over ~150 m (`crates/cartopolis/src/systems/map/terrain.rs:47`, `:84`). So today's water level *is* the quay level, filled in from the sides. - Water is one rung of a millimetre-thick coplanar stack: `y_offset` **−0.0035 m** (`crates/geo/src/vector_tiles.rs:1283`), `depth_rung` 4.0 (`crates/geo/src/vector_tiles.rs:1350`). The whole ladder spans 8 mm. - Underneath it, **the basemap clipmap is eight opaque layers deep and nothing cuts holes in it** (`crates/cartopolis/src/systems/map/map_stream.rs:884`). Its finest level rests at **y = −0.03 m** (`crates/cartopolis/src/systems/map/map_stream.rs:627`), 2.65 cm below the water sheet. - The depth bias cannot rescue it: water's 256 units read as "~15 cm at 5 km and ~150 µm at 10 m" and "cannot punch through a building, which is separated by metres of honest depth" (`crates/geo/src/vector_tiles.rs:1329`). Drop a canal to its register level — order of a metre below the quay — and it goes **under an opaque, continuous basemap plane** with no bank geometry anywhere to close the gap. There is no canal wall in this tree; the surface stack is a sheet, not a solid. ## Approach Documentation only. No crate is touched, so nothing here compiles. 1. **Write `docs/notes/rijkswaterstaat-water-levels.md`**, in the shape of `docs/notes/ndw-traffic.md` — `topic:` / `triggers:` / `updated:` front matter per `docs/notes/README.md`, title of the form "…: checked and not taken". It records: the endpoint move off `waterwebservices.rijkswaterstaat.nl`, the two request bodies and their measured sizes, the CC0 statement and where it is published, the 705-station coverage table above, the absence of any water-body identifier on a station, and the geometry finding with its citations. It also states plainly **what would have to exist before the row could be revisited**: a hole punched in the clipmap under water polygons, and bank/quay geometry to close the vertical gap. Filing that as a follow-up ticket is optional and not required by this ticket. 2. **Move the `Rijkswaterstaat water levels` row** in `docs/direction.md` from *Candidates, unverified* to *Checked and not taken*, with a `Checked` date of the day the branch is written, a one-paragraph reason in the table's existing style, and a link to the new note. 3. **Add a cross-reference** to the note from `docs/notes/terrain-relief.md`, beside its existing statement that water takes one level for the whole body — that is where the next person asking this question will land. 4. **Commit body** names the values applied (see below) and `Refs #197`. Conventional Commits, `docs(direction):` scope, matching `24f2169`. **The values that settle it,** to be stated in the commit body as `docs/direction.md` requires: - **Value 5, the frame budget** and **value 3, degrade never break** are the decisive pair: the change the row asks for is not a data wire-in but a rewrite of the ground sheet into a solid, and the intermediate state — water a metre under an opaque basemap — is a broken picture, not a degraded one. - **Value 1, measured beats plausible**, is the case *for* the row and loses on the join: the register measures 705 points and says nothing about which polygon each one governs, so every canal's level would be a nearest-station guess. - **Value 6, ship the smallest thing a machine can judge**: with no visible change available, there is no `--dump-state` field an `--expect` could hold. ## Acceptance criteria - [ ] `docs/notes/rijkswaterstaat-water-levels.md` exists, with `topic:`/`triggers:`/`updated:` front matter matching `docs/notes/README.md`. - [ ] The note names both live endpoints (`METADATASERVICES/OphalenCatalogus`, `ONLINEWAARNEMINGENSERVICES/OphalenWaarnemingen`), states that the pre-migration host is being retired, and records the request bodies that were used. - [ ] The note records the licence as CC0 and cites `https://rijkswaterstaatdata.nl/waterdata/` as where that is stated. - [ ] The note records the volume: catalogue bytes, total locations, `WATHTE` locations, and the bytes/measurement count for one station-hour. - [ ] The note carries the six-city nearest-station table, with the date the distances were computed. - [ ] The note states that a station carries no water-body identifier, and that a polygon-to-station join would therefore be by proximity. - [ ] The note states the geometry finding and cites at least `map_geometry.rs:1786`, `terrain.rs:218`, `vector_tiles.rs:1283`, `map_stream.rs:627` and `map_stream.rs:884`. - [ ] The note names what would have to exist first (clipmap hole under water polygons + bank geometry) so the row can be revisited rather than re-checked. - [ ] `docs/direction.md`'s *Candidates, unverified* table no longer contains the Rijkswaterstaat row; the *Checked and not taken* table does, with a date, a reason and a link to the note. - [ ] `docs/notes/terrain-relief.md` links to the new note where it discusses water taking one level. - [ ] The commit body names the values applied and their reasoning, and carries `Refs #197`. No `Co-Authored-By` trailer. - [ ] No file outside `docs/` is modified. ## Verification The numbers above were measured; re-running is optional confirmation, not a gate. Each is one read-only request: ```bash # catalogue: status, bytes curl -s -o /tmp/cat.json -w '%{http_code} %{size_download}\n' \ -X POST https://ddapi20-waterwebservices.rijkswaterstaat.nl/METADATASERVICES/OphalenCatalogus \ -H 'Content-Type: application/json' \ -d '{"CatalogusFilter":{"Compartimenten":true,"Grootheden":true}}' # one station-hour of measured water height curl -s -o /tmp/obs.json -w '%{http_code} %{size_download}\n' \ -X POST https://ddapi20-waterwebservices.rijkswaterstaat.nl/ONLINEWAARNEMINGENSERVICES/OphalenWaarnemingen \ -H 'Content-Type: application/json' \ -d '{"Locatie":{"Code":"groningen"}, "AquoPlusWaarnemingMetadata":{"AquoMetadata":{"Compartiment":{"Code":"OW"}, "Grootheid":{"Code":"WATHTE"},"ProcesType":"meting"}}, "Periode":{"Begindatumtijd":"2026-08-29T20:00:00.000+02:00", "Einddatumtijd":"2026-08-29T21:00:00.000+02:00"}}' ``` Station counts and distances come from `/tmp/cat.json` alone: join `AquoMetadataLijst` (`Grootheid.Code == "WATHTE"`) to `LocatieLijst` through `AquoMetadataLocatieLijst`, then haversine against the six centres. **One number was deliberately not taken here, because getting it is work and this pass decides whether to build.** The gap between today's AHN-derived canal level and the register's NAP level is measurable without the client, via one AHN DTM box over a Groningen canal: ``` https://service.pdok.nl/rws/ahn/wcs/v1_0?service=WCS&version=1.0.0&request=GetCoverage&coverage=dtm_05m&... ``` (the request shape is `HeightRequest` in `crates/cartopolis/src/systems/map/height.rs`; the anchor's absolute NAP datum is `HeightLayer::ground_m`, `height.rs:295`, which `docs/notes/flood-defences.md` already uses to convert a NAP crest into anchor-relative metres). Include it in the note if taken. **It does not change the conclusion either way**: above ~8 mm the coplanar stack cannot hold the drop and the basemap covers the water; below it there is nothing to show. Say which of the two the measurement lands on, or say it was not measured. **Nothing to build and nothing to render.** No `cargo` command applies — no crate is touched. No `--shot` or `cargo shots` is needed, which is as well, since this container cannot render. **Nothing needs a workstation.** If the branch grows any non-docs change, that is out of scope and the ticket has changed shape. ## Out of scope - **Any client or extractor code.** No `tools/` extractor, no coverage manifest, no streamer, no `cartopy` pipeline. The "if it is worth doing" half of the ticket does not fire. - **The clipmap hole and bank/quay geometry.** They are what a future revisit would need; building them is not this ticket, and the note only names them. - **A water-level readout in the UI.** The row promises surfaces at their real height, not a number in a panel; adding one would be inventing scope. - **The water boards' `peilgebied` / `peilbesluit` polygons** (target levels as areas, published alongside the `waterkering` lines `systems::dikes` already streams). They are a different source with a different provider and would be a different frontier row, not this one. Mention as a pointer if useful; do not check or spec it here. - **Tidal animation on the big rivers.** Same geometry obstacle, and the row does not ask for it. - **The `3D basisvoorziening` row** in the same candidates table. Untouched. - **`PROTOCOL_HISTORY`, any migration, `CHANGELOG.md`.** Docs-only; `24f2169` did not touch the changelog either. ## Open questions None. --- Branch: `docs/197-rijkswaterstaat-water-levels` <details><summary>Original request</summary> From the frontier in [`docs/direction.md`](../src/branch/main/docs/direction.md): **Rijkswaterstaat water levels** — canal and river surfaces at their real height. 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. <sub>Filed by the autopilot. <!-- autopilot:rijkswaterstaat-water-levels --></sub> </details> <sub>🤖 Refined by the viberfox issue agent. Reply with **@agent refine** and what is wrong to have this rewritten.</sub>
viberfox-agent commented 2026-08-30 00:01:24 +00:00
Author
Collaborator
Copy link

🤖 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.

🤖 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 commented 2026-08-30 00:07:39 +00:00
Author
Collaborator
Copy link

🤖 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 — 40 turns · $3.40 · session 8c2429cf-3350-407a-84d7-c2e44780c2d4. 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. --- <sub>🤖 viberfox issue agent on the VPS — 40 turns · $3.40 · session `8c2429cf-3350-407a-84d7-c2e44780c2d4`. Reply with **@agent** to continue this session.</sub>
viberfox-agent commented 2026-08-30 00:07:56 +00:00
Author
Collaborator
Copy link

🤖 Picked this up — working on branch docs/197-rijkswaterstaat-water-levels 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/197-rijkswaterstaat-water-levels` in a fresh worktree on the VPS. I'll report back here when I'm done. <sub>Label an issue `agent:skip` to keep me off it, or `driven` to keep it in a session you are driving.</sub>
viberfox-agent commented 2026-08-30 00:14:24 +00:00
Author
Collaborator
Copy link

Pushed. One commit, docs only.

The answer is no, and it is this codebase that says so — not Rijkswaterstaat

I re-ran every probe in the ticket rather than trusting it, and took the one measurement it left open.

What holds up. The old host waterwebservices.rijkswaterstaat.nl now 301s to a migration notice; the live one is ddapi20-…. The catalogue is 1,573,954 bytes with 2,498 locations, 705 of them water-height stations. A station-hour is 3,374 bytes, 7 measurements, cm NAP. No API key is enforced. CC0, stated on rijkswaterstaatdata.nl/waterdata/. Four of six city centres have no station within a kilometre; Rotterdam and Nijmegen came out slightly closer than the ticket's table because I used my own centre coordinates, which the note now states.

One finding sharpened. A station record has exactly seven fields and none of them names a water body. groningen — whose −0.91 m would be attached to the Diepenring — sits 2 km out on the Van Starkenborghkanaal and carries no water name at all. So every polygon's level would be a nearest-point guess.

The number the ticket deliberately left open, now taken. AHN's DTM over the Groningen canals is no-data on the water and +1.1 to +4.6 m NAP on the banks, against an anchor datum of +7.57 m at the Grote Markt and a register level of −0.91 m. The drop is two to five metres. The coplanar stack spans 8 mm and the clipmap's finest level is 2.65 cm below the water sheet, so the canal would go under an opaque basemap with no bank geometry to close the gap. That lands the measurement firmly on the "cannot hold it" side.

Files

  • docs/notes/rijkswaterstaat-water-levels.md — new, in the shape of ndw-traffic.md.
  • docs/direction.md — row moved from Candidates, unverified to Checked and not taken, dated 2026-08-30.
  • docs/notes/terrain-relief.md — cross-reference where it says water takes one level.

Values applied, in the commit body: 5 and 3 as the pair that settles it, 1 as the case for the row that loses on the join, 6 because there is no --dump-state field an --expect could hold.

Verification

cargo fmt --check is clean. No crate is touched, so cargo check and the test suites have nothing to say about this diff and I did not run them — CI's own path filter skips the build jobs for a docs/**-only change. Nothing needs a visual check; there is no rendering change here.

For you to decide

Two pointers I recorded but did not check, because they are separate frontier rows rather than this one:

  • The water boards' peilgebied / peilbesluit — target levels as areas, published alongside the waterkering lines systems::dikes already streams. An area answers the join question a station cannot. The geometry obstacle applies to it identically, so it is only worth a row once the ground stack changes.
  • A hole in the clipmap under water polygons, plus bank and quay geometry. That is the actual prerequisite. I did not file it as a ticket — the ticket said filing it was optional, and it is a rendering change that wants someone who can look at a screen. Say the word and I will write it up.

Branch docs/197-rijkswaterstaat-water-levels (pushed)

004d9b0 docs(direction): Rijkswaterstaat water levels checked and not taken

🤖 viberfox issue agent on the VPS — 38 turns · $3.59 · session ad9d639a-647e-43ac-8a96-0121efb720d9. Reply with @agent to continue this session.

Pushed. One commit, docs only. ## The answer is no, and it is this codebase that says so — not Rijkswaterstaat I re-ran every probe in the ticket rather than trusting it, and took the one measurement it left open. **What holds up.** The old host `waterwebservices.rijkswaterstaat.nl` now 301s to a migration notice; the live one is `ddapi20-…`. The catalogue is 1,573,954 bytes with 2,498 locations, 705 of them water-height stations. A station-hour is 3,374 bytes, 7 measurements, cm NAP. No API key is enforced. CC0, stated on `rijkswaterstaatdata.nl/waterdata/`. Four of six city centres have no station within a kilometre; Rotterdam and Nijmegen came out slightly closer than the ticket's table because I used my own centre coordinates, which the note now states. **One finding sharpened.** A station record has exactly seven fields and none of them names a water body. `groningen` — whose −0.91 m would be attached to the Diepenring — sits 2 km out on the Van Starkenborghkanaal and carries no water name at all. So every polygon's level would be a nearest-point guess. **The number the ticket deliberately left open, now taken.** AHN's DTM over the Groningen canals is no-data on the water and +1.1 to +4.6 m NAP on the banks, against an anchor datum of +7.57 m at the Grote Markt and a register level of −0.91 m. The drop is **two to five metres**. The coplanar stack spans 8 mm and the clipmap's finest level is 2.65 cm below the water sheet, so the canal would go under an opaque basemap with no bank geometry to close the gap. That lands the measurement firmly on the "cannot hold it" side. ## Files - `docs/notes/rijkswaterstaat-water-levels.md` — new, in the shape of `ndw-traffic.md`. - `docs/direction.md` — row moved from *Candidates, unverified* to *Checked and not taken*, dated 2026-08-30. - `docs/notes/terrain-relief.md` — cross-reference where it says water takes one level. Values applied, in the commit body: **5** and **3** as the pair that settles it, **1** as the case for the row that loses on the join, **6** because there is no `--dump-state` field an `--expect` could hold. ## Verification `cargo fmt --check` is clean. No crate is touched, so `cargo check` and the test suites have nothing to say about this diff and I did not run them — CI's own path filter skips the build jobs for a `docs/**`-only change. Nothing needs a visual check; there is no rendering change here. ## For you to decide Two pointers I recorded but did not check, because they are separate frontier rows rather than this one: - **The water boards' `peilgebied` / `peilbesluit`** — target levels as *areas*, published alongside the `waterkering` lines `systems::dikes` already streams. An area answers the join question a station cannot. The geometry obstacle applies to it identically, so it is only worth a row once the ground stack changes. - **A hole in the clipmap under water polygons, plus bank and quay geometry.** That is the actual prerequisite. I did not file it as a ticket — the ticket said filing it was optional, and it is a rendering change that wants someone who can look at a screen. Say the word and I will write it up. **Branch** `docs/197-rijkswaterstaat-water-levels` (pushed) ``` 004d9b0 docs(direction): Rijkswaterstaat water levels checked and not taken ``` --- <sub>🤖 viberfox issue agent on the VPS — 38 turns · $3.59 · session `ad9d639a-647e-43ac-8a96-0121efb720d9`. Reply with **@agent** to continue this session.</sub>
viberfox-agent commented 2026-08-30 00:15:26 +00:00
Author
Collaborator
Copy link

🤖 Marked agent:done without a CI verdict on 004d9b0b — no workflow reported on this commit. The branch is waiting for review; check the run yourself before landing it.

🤖 Marked `agent:done` **without a CI verdict** on `004d9b0b` — no workflow reported on this commit. The branch is waiting for review; check the run yourself before landing it.
viberfox-agent 2026-08-30 00:16:15 +00:00
viberfox-agent commented 2026-08-30 00:16:16 +00:00
Author
Collaborator
Copy link

🤖 Merged into main as pull request #198 (004d9b0b).

🤖 **Merged into `main`** as pull request #198 (`004d9b0b`).
viberfox-agent commented 2026-08-30 00:59:47 +00:00
Author
Collaborator
Copy link

🤖 Merged, but not deployed. The deploy step exited 1:

main is at d83a3bd5
  waiting for CI on d83a3bd5
refusing: no Actions job ran for d83a3bd5 — nothing has verified this commit

main has the change; the public services are still on the previous build.

🤖 **Merged, but not deployed.** The deploy step exited 1: ``` main is at d83a3bd5 waiting for CI on d83a3bd5 refusing: no Actions job ran for d83a3bd5 — nothing has verified this commit ``` `main` has the change; the public services are still on the previous build.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
fix/high-precision-recovery
worktree-bridge-cse_01Rn3MUPhnvEduZyuBpEzSjz
refactor/materials-crate
worktree-bridge-cse_01R8NtJemVDbj5vQwnhPkGaF
worktree-bridge-cse_01XyroV5kuy4KMgJXXqSvR3a
feat/prim-hands-and-tones
refactor/long-functions
fix/atlas-unused-json
refactor/anchored-camera
refactor/mcp-server-crate
docs/client-codegen-breakdown
chore/landing-number-check
refactor/client-lib-split
refactor/shared-formats
refactor/vector-tiles-modules
worktree-bridge-cse_01DZ5F5a3z4HHcfcAKcjPufE
worktree-bridge-cse_01GMoBMn3Rd8TR6vDfvMJrVS
worktree-bridge-cse_018NvTh1tirLk6N91S2Aqzov
calls-vp9-perf-ux
feat/calls-video
feat/295-perf-repeat
feat/calls
design/contacts-mockup
perf/lod22-binary-cells
perf/load-critical-path
perf/tall-structures-from-atlas
feat/activitypub-places
design/chat-world-mockup
deploy/viewer-path
perf/snappier-loading
HEAD
worktree-bridge-cse_017PchWTRS4tDvYWsCfiitBq
bridge-cse-lods
worktree-bridge-cse_01VzLU1RqyvjU8kykUzErat8
feat/301-perf-baseline-diff
fix/297-street-smoke-timeout
ci/290-flicker-smoke-headroom
fix/268-floating-marks-water-level
fix/281-autopilot-page-issue-lists
fix/232-crossing-clearance-from-rails
perf/237-reanchor-skips-an-unmoved-anchor
feat/214-nav-marks-readout
fix/219-autopilot-docs-only-deploy
worktree-bridge-cse_01J8JH1ZQTxFXDzY8Ui7fxsU
diag/adreno-sky-probe
fix/adreno-medium-texel-scale
worktree-bridge-cse_01THBbRn4fWL7NdvJo6HJRUq
perf/render-budget
fix/road-joins-and-tile-decode
continuous
Labels
Clear labels   
agent
Hand this issue to the Claude agent on the VPS

  
agent:ci
Branch pushed; waiting for CI. It becomes agent:done only if CI passes.

  
agent:done
The agent finished and pushed a branch

  
agent:failed
The agent errored out; see its comment

  
agent:needs-input
Refined, but there are blocking questions. Nothing is built until they are answered.

  
agent:refined
Spec written and agreed; queued for implementation.

  
agent:refining
The issue agent is reading the code and writing a spec.

  
agent:running
The agent has claimed this issue and is working

  
agent:shipped
autopilot

  
agent:skip
Keep the issue agent off this one

  
autonomous
Hand this to the issue agent: refine it, then implement it unattended.

  
autopilot
autopilot

  
driven
A person is steering this one (Zed or claude.ai/code). The issue agent leaves it alone; remove to hand over.

  
local
Worked on locally in Zed — the remote issue agent leaves it alone. Remove to hand over.

  
plan
autopilot

  
proposal
Filed unattended by the steward from docs/direction.md. Close with a comment to reject; the next run reads it.

  
qa
autopilot

  
qa-gap
A gap found by a QA pass: implemented pieces work, a user still hits a wall

  
research
Research from an unattended night: areas the project could grow into. Not buildable as-is.

  
retro
autopilot

  
ship
autopilot

No labels
agent
agent:ci
agent:done
agent:failed
agent:needs-input
agent:refined
agent:refining
agent:running
agent:shipped
agent:skip
autonomous
autopilot
driven
local
plan
proposal
qa
qa-gap
research
retro
ship
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Viberfox
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
jeroen/cartopolis#197
No description provided.