gap: with Aerial photography on, the drawn map is painted over the photograph — 99% of a city frame is unchanged #264

New issue

Closed

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

viberfox-agent commented

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

Collaborator

What I did

Built the client and took five A/B capture pairs headlessly (lavapipe), each pair identical apart from the --aerial flag: same camera, --time 12, --hide-ui, --size 800x800, CARTO_TILE_URL pinned to the vector basemap. Metrics from --dump-state, pixel differences with ImageMagick compare -metric AE -fuzz 2% over 640,000 pixels.

What happened

The fetch half works — aerial_tiles is non-zero in every aerial run and 0 in every control, and no tile fetch failed:

view	altitude	`aerial_tiles`	pixels changed vs control
Groningen centre	700 m	405 of 424	4,534 (0.7%)
Farmland N of Groningen	700 m	378	25,407 (4.0%)
Groningen centre	5,000 m	258	80,023 (12.5%)
Antwerp centre	700 m	368	3,944 (0.6%)
Rural Belgium	700 m	354	162,025 (25.3%)

Over the city at 700 m — the z15–z17 band the layer was built for, where the drawn map is a magnified z14 render — the photograph reaches 0.7% of the frame. The pixels that do change are thin slivers: a farmyard, a road verge, the gaps between landuse polygons. Everything else is the drawn map sitting on top.

The photograph is genuinely there underneath: cropping one farmyard shows real grass and tree texture in the aerial run where the control shows a flat grey fill. It is just that in a city there is almost nowhere the vector map leaves uncovered.

What a user would expect

Ticking Map ▸ Aerial photography makes the ground a photograph — buildings, roads, labels and trees still drawn over it, but the landuse painting stops. docs/manual.md promises exactly that ("swaps the drawn ground for real photographs … worth switching on close to the ground"), and today, close to the ground, it is the one place you cannot see it.

There is also no workaround from the UI. Map hides the ground tiles themselves (StreamTile visibility), so switching it off takes the photograph away too, not the fills over it. No other toggle reaches them.

Where the seam is

crates/cartopolis/src/systems/map/map_stream.rs textures the clipmap quads from PDOK, and is deliberately the only consumer that changes source.
crates/geo/src/vector_tiles.rs::tessellate_surfaces / land_group emits opaque fills for farmland/grass/park/meadow/forest (Grass, Forest), residential/industrial/commercial/retail (Built), sand/beach, plus the ocean, water_polygons and sites layers. Those, the paving band and the road ribbons all sit above the tile quads on the depth ladder.
Nothing outside map_stream reads DataLayers::aerial_enabled, so no surface builder knows the ground became a photograph.

The plausible fix is for the surface groups to be suppressed where aerial imagery covers the cell — the landuse fills at minimum; water is arguable, since the water shader is what makes a canal read as water.

docs/notes/aerial-imagery.md records this under "What is still unjudged" as a look pass ("whether a photographic backdrop reads well under the drawn land / water / sites polygons"). The measurement above says it is not a look question: at street level there is no backdrop to judge.

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

QA of #175 (ticket #263). The imagery arrives and is textured onto the clipmap; it is then almost entirely covered by the vector map drawn on top of it, so ticking the checkbox looks like it did nothing. ## What I did Built the client and took five A/B capture pairs headlessly (lavapipe), each pair identical apart from the `--aerial` flag: same camera, `--time 12`, `--hide-ui`, `--size 800x800`, `CARTO_TILE_URL` pinned to the vector basemap. Metrics from `--dump-state`, pixel differences with ImageMagick `compare -metric AE -fuzz 2%` over 640,000 pixels. ## What happened The fetch half works — `aerial_tiles` is non-zero in every aerial run and 0 in every control, and no tile fetch failed: | view | altitude | `aerial_tiles` | pixels changed vs control | |---|---|---|---| | Groningen centre | 700 m | 405 of 424 | 4,534 (**0.7%**) | | Farmland N of Groningen | 700 m | 378 | 25,407 (4.0%) | | Groningen centre | 5,000 m | 258 | 80,023 (12.5%) | | Antwerp centre | 700 m | 368 | 3,944 (0.6%) | | Rural Belgium | 700 m | 354 | 162,025 (25.3%) | Over the city at 700 m — the z15–z17 band the layer was built for, where the drawn map is a magnified z14 render — the photograph reaches 0.7% of the frame. The pixels that do change are thin slivers: a farmyard, a road verge, the gaps between landuse polygons. Everything else is the drawn map sitting on top. The photograph is genuinely there underneath: cropping one farmyard shows real grass and tree texture in the aerial run where the control shows a flat grey fill. It is just that in a city there is almost nowhere the vector map leaves uncovered. ## What a user would expect Ticking **Map ▸ Aerial photography** makes the ground a photograph — buildings, roads, labels and trees still drawn over it, but the landuse painting stops. `docs/manual.md` promises exactly that ("swaps the drawn ground for real photographs … worth switching on close to the ground"), and today, close to the ground, it is the one place you cannot see it. There is also no workaround from the UI. **Map** hides the ground tiles themselves (`StreamTile` visibility), so switching it off takes the photograph away too, not the fills over it. No other toggle reaches them. ## Where the seam is - `crates/cartopolis/src/systems/map/map_stream.rs` textures the clipmap quads from PDOK, and is deliberately the only consumer that changes source. - `crates/geo/src/vector_tiles.rs::tessellate_surfaces` / `land_group` emits opaque fills for `farmland`/`grass`/`park`/`meadow`/`forest` (Grass, Forest), `residential`/`industrial`/`commercial`/`retail` (Built), `sand`/`beach`, plus the `ocean`, `water_polygons` and `sites` layers. Those, the paving band and the road ribbons all sit above the tile quads on the depth ladder. - Nothing outside `map_stream` reads `DataLayers::aerial_enabled`, so no surface builder knows the ground became a photograph. The plausible fix is for the surface groups to be suppressed where aerial imagery covers the cell — the landuse fills at minimum; water is arguable, since the water shader is what makes a canal read as water. `docs/notes/aerial-imagery.md` records this under "What is still unjudged" as a look pass ("whether a photographic backdrop reads well under the drawn land / water / sites polygons"). The measurement above says it is not a look question: at street level there is no backdrop to judge. <sub>Filed by the QA pass on #263.</sub>

viberfox-agent added the

qa-gap

label

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

viberfox-agent added this to the Viberfox project

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

viberfox-agent referenced this issue

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

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

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