gap: the aerial envelope is a rectangle over Antwerp, Brussels and Duesseldorf, where PDOK serves a blank white tile and the ground goes white #265

New issue

Closed

opened 2026-09-02 01:57:45 +00:00 by viberfox-agent · 0 comments

viberfox-agent commented

2026-09-02 01:57:45 +00:00

Collaborator

What I did

Probed Actueel_ortho25 directly on 2026-09-02, z14 and z17, and then took A/B captures with and without --aerial (identical camera, --time 12, --hide-ui, 800x800).

What happened

point	inside `aerial::covers()`?	body size at z14 / z17
Groningen	yes	36,349 B / 33,328 B
Rotterdam	yes	34,704 B / 25,930 B
Antwerp	yes	1,651 B / 1,651 B
Brussels	yes	1,651 B / 1,651 B
Duesseldorf	yes	1,651 B / 1,651 B
Duisburg	yes	1,651 B / 1,651 B
6 km off Scheveningen	yes	1,651 B / 1,651 B

The 1,651-byte body is a valid 256x256 JPEG that is pure white (mean 255, standard deviation 1 on every channel). Dutch coastal water is imaged out to a few kilometres, so the sea case only bites well offshore; the land cases do not.

In the app: a capture over rural Belgium (51.05, 4.55, 700 m) reports aerial_tiles: 354 and differs from its control in 162,025 of 640,000 pixels (25%) — the ground between the drawn landuse polygons is blanched instead of showing map colours. Over Antwerp's centre the effect is currently small (0.6%) only because the drawn map covers nearly everything there (#264); fix #264 and this becomes a white void where the map used to be.

What a user would expect

A user in Antwerp or Duesseldorf ticks a layer labelled "PDOK imagery — Netherlands only", and expects one of two things: no change at all, or photographs. Losing the map is neither. The honest behaviour outside real imagery coverage is to keep serving the drawn basemap for that tile.

Where the seam is

crates/cartopolis/src/systems/map/aerial.rs: AERIAL_LON = (3.20, 7.28), AERIAL_LAT = (50.72, 53.56) — AHN's envelope, which is right about "is this the Netherlands" only to the accuracy of a bounding box. Antwerp (51.22, 4.40), Brussels (50.85, 4.35), Duesseldorf (51.23, 6.77) and Duisburg (51.43, 6.76) are all inside it; covers_tile therefore routes them to PDOK.
crates/cartopolis/src/systems/map/tile_loader.rs::decode_tile_image and map_stream::apply_stream_textures accept whatever decodes; there is no blank-body or uniformity check and no per-tile fallback to the vector template.

The module note's reasoning that "coverage is an envelope, not a status code" is right about the status code — PDOK's 200 tells you nothing. What it leaves out is that this particular envelope admits several thousand square kilometres of Belgium and Germany, and that the fallback path (draw this tile from the vector source instead) does not exist at all, so there is nowhere for a refusal to go even once the envelope knows better. Either a tighter shape or a blank-body check needs the fallback arm first.

_{Filed by the QA pass on #263.}

QA of #175 (ticket #263). The coverage envelope is a lat/lng rectangle around the Netherlands, and a rectangle around the Netherlands contains a lot of Belgium and the Rhineland. PDOK answers those with a valid, pure-white JPEG, and the client textures it rather than falling back to the drawn map. ## What I did Probed `Actueel_ortho25` directly on 2026-09-02, z14 and z17, and then took A/B captures with and without `--aerial` (identical camera, `--time 12`, `--hide-ui`, 800x800). ## What happened | point | inside `aerial::covers()`? | body size at z14 / z17 | |---|---|---| | Groningen | yes | 36,349 B / 33,328 B | | Rotterdam | yes | 34,704 B / 25,930 B | | Antwerp | **yes** | 1,651 B / 1,651 B | | Brussels | **yes** | 1,651 B / 1,651 B | | Duesseldorf | **yes** | 1,651 B / 1,651 B | | Duisburg | **yes** | 1,651 B / 1,651 B | | 6 km off Scheveningen | yes | 1,651 B / 1,651 B | The 1,651-byte body is a valid 256x256 JPEG that is pure white (mean 255, standard deviation 1 on every channel). Dutch coastal water is imaged out to a few kilometres, so the sea case only bites well offshore; the land cases do not. In the app: a capture over rural Belgium (51.05, 4.55, 700 m) reports `aerial_tiles: 354` and differs from its control in 162,025 of 640,000 pixels (25%) — the ground between the drawn landuse polygons is blanched instead of showing map colours. Over Antwerp's centre the effect is currently small (0.6%) only because the drawn map covers nearly everything there (#264); fix #264 and this becomes a white void where the map used to be. ## What a user would expect A user in Antwerp or Duesseldorf ticks a layer labelled "PDOK imagery — Netherlands only", and expects one of two things: no change at all, or photographs. Losing the map is neither. The honest behaviour outside real imagery coverage is to keep serving the drawn basemap for that tile. ## Where the seam is - `crates/cartopolis/src/systems/map/aerial.rs`: `AERIAL_LON = (3.20, 7.28)`, `AERIAL_LAT = (50.72, 53.56)` — AHN's envelope, which is right about "is this the Netherlands" only to the accuracy of a bounding box. Antwerp (51.22, 4.40), Brussels (50.85, 4.35), Duesseldorf (51.23, 6.77) and Duisburg (51.43, 6.76) are all inside it; `covers_tile` therefore routes them to PDOK. - `crates/cartopolis/src/systems/map/tile_loader.rs::decode_tile_image` and `map_stream::apply_stream_textures` accept whatever decodes; there is no blank-body or uniformity check and no per-tile fallback to the vector template. The module note's reasoning that "coverage is an envelope, not a status code" is right about the status code — PDOK's 200 tells you nothing. What it leaves out is that this particular envelope admits several thousand square kilometres of Belgium and Germany, and that the fallback path (draw this tile from the vector source instead) does not exist at all, so there is nowhere for a refusal to go even once the envelope knows better. Either a tighter shape or a blank-body check needs the fallback arm first. <sub>Filed by the QA pass on #263.</sub>

viberfox-agent added the

qa-gap

label

2026-09-02 01:57:48 +00:00

viberfox-agent added this to the Viberfox project

2026-09-02 01:58:02 +00:00

viberfox-agent referenced this issue

2026-09-02 01:58:17 +00:00

QA: what #175 shipped — PDOK aerial imagery: is it worth wiring in? #263