Wire the OSM SoA bake into the /osm cockpit (endpoint + overlay), and scope the V1→V3 key migration - #108
Merged
Conversation
Adds osm-soa-bake as a sibling path dependency and a new handler that queries the Morton-sorted RowSlab directly (raw OSM-XYZ z/x/y, never through osm_tiles::tile_to_hhtl — that's a different, display-only 3-tier key). Reads the baked slab via mmap from OSM_SLAB_PATH, decodes position + identity per row, caps the response and reports total vs returned for dense tiles. TDD: cross-checks tile_range against two independently-implemented forward-geometry functions (osm-soa-bake's point_to_tms_morton and q2's own osm_tiles::lonlat_to_tile) so the anti-vacuity test can't pass by accident. Phase 1 of claude-notes/plans/2026-08-08-osm-soa-cockpit-wiring.md. Build/test verification still in progress; Phase 2 (GUI overlay) not started. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NMeiLmtDKhomJNSo2ecbJw
Wires the /osm slippy map's client JS to the /api/osm/features/:z/:x/:y endpoint added in Phase 1: fetches real OSM rows for tiles in view from the baked RowSlab and renders them as points layered on the raster basemap, using the same tile-pixel coordinate space (and world-wrap offset correction) as the existing raster tile images so they inherit pan/zoom for free. Opt-in via a new toggle button (mirrors the Garmin drape's posture) with a status readout for loading / no-slab-baked / truncated-tile states. Verification: cargo check -p cockpit-server --tests passed clean (full compile-time check of the whole crate, zero errors); the embedded JS was independently syntax-checked with `node --check`. A live browser run against a real baked slab was not completed this session — see the Phase-2 verification note in the plan for why (disk exhaustion in this environment prevented linking cockpit-server's binary/test artifacts across five separate attempts, including one that crashed LLVM on an unrelated dependency). That end-to-end check is the first thing a follow-up session should do.
…g leg Phase 3 records the measured V1/V2 vs V3 delta for the /osm endpoint. The bake side is already fully V3 (osm-soa-bake::identity consumes lance_graph_contract::identity_quad at classid(4)+payload(12); the row's four cascade tiers occupy GEO_V3_FACET rails 0-3). The only V1 surface left is cockpit-server's osm_tiles.rs: 3 tiers at z=24, XYZ (no TMS flip), 48-bit morton -- and it is a parallel implementation of math osm-soa-bake::tms already owns, so the migration is mostly deletion. Phase 4 records the operator-directed slab-hosting story: S3 as scratch plus RAILWAY_VOL, following the existing lance-graph hydration-lifecycle and MedCare-rs bake_s3 precedent rather than inventing one. Credentials stay in the environment; /volume01 is Railway-side and absent locally, so that leg is noted as deploy-only-verifiable. No code changes -- scoping only, with two-sided falsifiers specified.
Two concrete results, both measured rather than inferred. 1. The V1/V3 divergence is now a number, not a reading of constants. cockpit-server is binary-only and its test binary cannot be linked in this environment, so the falsification ran where it can build: a throwaway probe that copies q2's tile_to_hhtl / morton_interleave / lonlat_to_tile verbatim and compares them against the real tms::point_to_tiers. Every tier differs at Berlin, Reykjavik and Sydney. The V3 column is recorded as the expected-value fixture the migration must reproduce. The falsifier test itself is written out in the plan but deliberately NOT committed: it fails against current V1 code (that is its job), and landing it together with an unverifiable implementation would ship a coordinate-key migration whose correctness was never observed. A wrong key silently mis-addresses every row. 2. The Berlin slab is baked and uploaded. 2,525,052 rows / 1.20 GiB, classid 0x0F011000 (GEO_DOMAIN | CLASSVIEW_V3_SUBSTRATE) -- the artifact asserting its own V3-ness, which means the slab was never V1; only q2's display key is. Stored under the same <repo>/bakes/<version>/ + SHA256SUMS convention the existing bakes use, with checksums recorded so the hydrate path can verify rather than trust.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThe change adds an OSM feature API backed by a memory-mapped slab and connects it to an optional cockpit map overlay. It adds query tests and documents completed integration work plus planned V3 key migration and production slab hosting. ChangesOSM SoA cockpit overlay
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant OSMMap
participant osm_features_handler
participant RowSlab
OSMMap->>osm_features_handler: Request visible tile features
osm_features_handler->>RowSlab: Query raw OSM XYZ tile range
RowSlab-->>osm_features_handler: Return matching slab rows
osm_features_handler-->>OSMMap: Return capped features and counts
OSMMap->>OSMMap: Render cached point markers
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_71d71d89-e06c-4543-95e6-dce8c146a4bb) |
AdaWorldAPI
marked this pull request as ready for review
August 10, 2026 22:11
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This was referenced Aug 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Connects two halves that were built to meet and never wired:
openstreetmap-website-rsproduces a Morton-sorted V3 slab of real OSM rows, and q2's/osmcockpit renders a slippy map — but only ever fetched raster tiles. The bake had no consumer; the cockpit had no real feature data.What lands
GET /api/osm/features/:z/:x/:y(osm_features.rs) — mmaps the bakedRowSlabatOSM_SLAB_PATH, callstile_range(z,x,y)with raw OSM-XYZ, decodesmorton_at→ lon/lat andread_identity→(entity_type, ordinal). Caps rows per tile but reportstotalalongsidereturned, so a dense tile is honest about truncation rather than looking complete. Unset/unopenable slab ⇒ 503, never a panic.Feature overlay in
/osm(osm.rs) — fetches visible tiles and draws points over the basemap, positioned in the same tile-pixel space as the raster<img>s (including thetx - wxworld-wrap correction, so markers stay under the right world copy at low zoom / across ±180°). Opt-in toggle mirroring the Garmin drape's posture, with a status line for loading / no-slab / truncated.The key-space finding, measured
The plan documents a real V1/V2 → V3 gap, and the measurement is the point:
osm_tiles.rsThe bake side was never V1 —
osm-soa-bake::identityconsumeslance_graph_contract::identity_quadatclassid(4)+payload(12), the four cascade tiers occupyGEO_V3_FACETrails 0–3, and the baked artifact self-reportsclassid 0x0F011000(GEO_DOMAIN | CLASSVIEW_V3_SUBSTRATE). Only q2's displayed address is V1, and it is additionally a parallel implementation of mathosm_soa_bake::tmsalready owns.Because
cockpit-serveris binary-only and its test binary would not link here, the divergence was falsified where it could build — a probe copying q2'stile_to_hhtl/morton_interleave/lonlat_to_tileverbatim against the realtms::point_to_tiers. Every tier differs at every point (Berlinheel=0x624bvs0xc8e1). Those V3 values are recorded as the expected-value fixture the migration must reproduce.The falsifier test is written out in the plan but deliberately not committed. It fails against current V1 code — that is its job — and landing it beside an implementation I could not execute would ship a coordinate-key migration whose correctness was never observed. A wrong key silently mis-addresses every row. It should land with the migration, on a machine that can link, and be seen to go red-then-green.
Importantly: the overlay renders correctly without that migration, since the query path already goes through
tile_range. Phase 3 makes the displayed address agree with the slab's key.Slab provenance
Berlin baked and published this session: 2,525,052 rows / 1,292,826,624 bytes / 37.3s, under the same
<repo>/bakes/<version>/+SHA256SUMSconvention as the existing bakes, with sizes read back after upload.Verification status — honest
cargo check -p cockpit-server --tests— clean, zero errors (full compile-time check incl. tests).node --check'd — clean (a Rust compiler can't see inside that string literal)./osmagainst a real slab. Linkingcockpit-serverrepeatedly exhausted this environment's disk (one attempt crashed LLVM on an untouched dependency). That end-to-end check remains the gating item and should be the first thing done where the binary can link.Draft until that runs.
Generated by Claude Code
Summary by CodeRabbit
New Features
/osmcockpit.Bug Fixes