osm features: a city tile is served COMPLETE, and probe M4 says why the overland rule is still a placeholder - #110
Conversation
…rland rule is still a placeholder
The previous pass diagnosed the row cap as "spatially biased" and fixed HOW
rows were dropped without asking WHETHER they should be. They should not be.
MAX_FEATURES_PER_TILE was a flat 5,000 applied at every zoom. Against a real
bake that is not a coarse-zoom backstop, it is the normal case: from the one
measured tile (14/8802/5373, total 15,016) and a tile quartering per zoom
step, Berlin is decimated at z14 (67% dropped), z13 (92%) and z12 (98%). One
mid-sized city, served two-thirds absent at the zoom where a person reads a
city. Stride sampling only changes that from "wrong in one corner" to "wrong
everywhere, evenly" — uniform loss looks better, which is worse.
The falsifier written for the first fix certified the defect. It asserted the
returned points cover >=95% of the tile's EXTENT, and a uniform stride covers
~100% of a bounding box at ANY stride: measured on that exact fixture, the
assertion passes while keeping 25% of rows, and still passes at 5.9%. A test
that passes at 94% data loss has no power over data loss. Counting rows
discriminates; measuring their bounding box does not.
row_budget(z) — the budget is zoom-conditioned, because "how many features
may I drop" is an LOD question and LOD is a function of what the tile is.
CITY_ZOOM_FLOOR = 13 at or above, served complete
OVERVIEW_ROW_BUDGET = 100k decimation target below it
CITY_ROW_CEILING = 400k transport backstop only
Then ran probe M4, which has been queued NOT RUN and whose process rule says
a bucketing-strategy change runs the probe first or is labelled CONJECTURE.
osm-soa-bake's tier_probe, on Berlin (city, 2.52M features) and Iceland
(overland, 0.65M) — features per tile by cascade tier:
tier Berlin med/p95/max Iceland med/p95/max
heel z8 1,564,647 (2 tiles) 3,838 / 34,985 / 202,296
hip z16 206 / 996 / 3,844 1 / 8 / 1,067
twig z24 1 / 1 / 20 (99.7% fit) 1 / 1 / 7 (99.9% fit)
leaf z32 1 / 1 / 11 1 / 1 / 7
It terminates at TWIG, not HEEL — M4's own FAIL direction. Two consequences:
there is exactly ONE useful bucketing level (the hip cell; occupancy goes
1 -> 206 -> 1.56M), so the principled overland rule is one representative per
occupied hip cell (312:1 on Berlin), not a row stride — OVERVIEW_ROW_BUDGET
is labelled CONJECTURE accordingly. And density is a property of the extract,
not the zoom (Berlin and Iceland differ ~200x at hip, converge by twig), so a
zoom-keyed floor is a policy, not a measurement.
What the probe does let me state as measured: CITY_ROW_CEILING is bounded,
not chosen. A z13 tile is 8x8 hip tiles and Berlin's densest hip tile holds
3,844, so a z13 tile is bounded above by 246,016 — 400,000 provably cannot
fire for a Berlin-class bake.
Falsifiers, each verified red against the restored flat-5k defect
("5000 of 10000 rows"):
a_city_zoom_tile_is_served_complete counts rows, not extent
row_budget_is_zoom_conditioned_at_the_city_floor
a_decimated_overview_tile_samples_..._prefix re-scoped to the selection
rule at an injected budget, documented as NO evidence of completeness —
it stayed green through the disable-the-fix run, which is exactly why it
must not be the gate.
Also in this commit, from the same pass:
osint_gotham: three assertions still bounded the V3 tenant at
FACET_CAPACITY + 1 after the 6x(8:8) completion widened it to
FACET_STAKEHOLDER, failing on a byte production already writes. Widened, plus
a positive assert_eq!(bv[FACET_TYPE], 10) — a widened zero-check alone would
make the test pass by inspecting less.
83 passed, 0 failed (was 79 passing with 1 pre-existing failure).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NMeiLmtDKhomJNSo2ecbJw
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe OSM tile endpoint now applies zoom-dependent row budgets and stride sampling. The plan records probe results and removes proposed projection authorization. Facet-tenant tests now cover the expanded V3 tenant layout and stakeholder type facet. ChangesOSM tile serving
Facet-tenant test coverage
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
Suggested reviewers: Poem
✨ Finishing Touches📝 Generate docstrings
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_6f82ba6e-da4f-4bf0-9c73-58083b633c53) |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_ed39a2a8-60bb-4d68-91ae-12428343a9fe) |
What was wrong
The previous pass diagnosed the row cap as "spatially biased" and fixed how rows were dropped without asking whether they should be. They should not be.
MAX_FEATURES_PER_TILEwas a flat5_000applied at every zoom. Against a real bake that is not a coarse-zoom backstop — it is the normal case. From the one measured tile (14/8802/5373,total = 15_016) and a slippy tile quartering in area per zoom step:One mid-sized city, served two-thirds absent at the zoom where a person actually reads a city. Stride sampling only changes that from "wrong in one corner" to "wrong everywhere, evenly" — uniform loss looks better, which is worse.
The falsifier certified the defect
The test written for the first fix asserted the returned points cover ≥95% of the tile's extent. A uniform stride covers ~100% of a bounding box at any stride — measured on that exact fixture shape:
A test that passes at 94% data loss has no power over data loss. Counting rows discriminates; measuring their bounding box does not.
The fix
row_budget(z)— the budget is zoom-conditioned, because "how many features may I drop" is an LOD question and LOD is a function of what the tile is, not a constant.CITY_ZOOM_FLOOR = 13— at or above, a tile is a place you are looking at, served completeOVERVIEW_ROW_BUDGET = 100_000— decimation target below the floorCITY_ROW_CEILING = 400_000— transport backstop onlyProbe M4, run — and it refutes part of the above
bf16-hhtl-terrain.md's process rule: an agent changing bucketing strategy runs the probe first, or labels the proposal CONJECTURE and defers commitment.row_budgetis a bucketing-strategy change and it was written as settled fact. M4 has sat NOT RUN, and its harness (osm-soa-bake'stier_probe) was already written for it.Ran on Berlin (city, 2.52M features) and Iceland (overland, 0.65M) — features per tile by cascade tier:
Terminates at TWIG, not HEEL — M4's own FAIL direction. Three things follow, two of which cut against what I had just written:
OVERVIEW_ROW_BUDGETis now labelled CONJECTURE in its own doc comment.CITY_ROW_CEILINGis bounded, not chosen. A z13 tile is 8×8 = 64 hip tiles, and Berlin's densest hip tile holds 3,844, so a z13 tile is bounded above by 246,016 — 400,000 provably cannot fire for a Berlin-class bake.M4's result is recorded upstream in
lance-graph/.claude/knowledge/bf16-hhtl-terrain.mdper that file's update protocol, scoped explicitly to the OSM point-feature form.Falsifiers
Each verified red against the restored flat-5k defect (
5000 of 10000 rows):a_city_zoom_tile_is_served_complete— counts rows; fixture asserted > the old 5k cap so it cannot go vacuousrow_budget_is_zoom_conditioned_at_the_city_floor— can-fire and can-stay-silent on the same knoba_decimated_overview_tile_samples_the_whole_curve_not_a_morton_prefix— the old coverage test, re-scoped to the selection rule at an injected budget and documented as no evidence of completeness. It stayed green through the disable-the-fix run, which is exactly why it must not be the gate.Also in this PR
osint_gotham: three assertions still bounded the V3 tenant atFACET_CAPACITY + 1after the 6×(8:8) completion widened it toFACET_STAKEHOLDER, failing on a byte production already writes. Widened, plus a positiveassert_eq!(bv[FACET_TYPE], 10)— a widened zero-check alone would make the test pass by inspecting less.Verification
What was actually run, locally:
cargo test --bin q2-cockpit— 83 passed, 0 failed (was 79 passing with 1 pre-existing failure)rustfmt --checkclean across every hunk in this diff; the file's remaining drift is pre-existing and deliberately not churnedNot run:
cargo build --workspace/cargo nextest run --workspace/cargo xtask verify. The workspace's full dependency closure exceeds this environment's disk ceiling (recorded in the plan's Disk note). The change is confined tocockpit-server, a leaf binary crate; no shared crate is modified.Not verified:
CITY_ZOOM_FLOORis set from Berlin-class density; a denser extract (Jakarta, Tokyo) has not been measured. If it is wrong it is wrong in the safe direction (more completeness, larger responses), and the completeness test fails loudly rather than silently thinning.🤖 Generated with Claude Code
https://claude.ai/code/session_01NMeiLmtDKhomJNSo2ecbJw
Summary by CodeRabbit
New Features
Bug Fixes