Nearmap basemap option for Nidus Reveal (issue #184) #185
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "issue-184-nearmap-tiles"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #184 — exposes Nearmap (and future external tile vendors) as a basemap option in the main Nidus Reveal UI.
What
nearmap/package: minimal resty client forhttps://api.nearmap.com/tiles/v3/Vert/{z}/{x}/{y}.img(256×256 JPEG, CORS-enabled — verified against the live API with the Delta key). Rejects non-JPEG responses; parses{"error": ...}bodies like "No tile found for this request" (out-of-coverage areas).public.organization.nearmap_api_key(nullable), NOT an env var. Districts share one production instance, so a globalNEARMAP_API_KEYwould have exposed Delta's paid Nearmap subscription to every district — the licensing violation Benjamin flagged on #184. The key is set via org update or sudo org update; the sudo org summary exposes anearmapEnabledflag without leaking the key value.GET /api/vision/tile/nearmap/{z}/{x}/{y}: reuses the existing Stadia tile-proxy path (serveVisionTile) — worker/session auth, disk cache under{FilesDirectory}/nearmap-cache/{orgID}/(namespaced per org). The key is resolved from the authenticated user's org and the gate is checked BEFORE the cache read, so a district without a key can neither fetch nor read cached Nearmap imagery. Worker-token requests pass no user and never see Nearmap.GET /api/vision/basemaps: reportsnearmaponly for orgs with a key, so the UI button is hidden for non-subscribers.MapStyleSwitchergeneralized from a 2-state toggle to an option list (default unchanged: Map/Satellite); the Reveal map gains a Nearmap option rendering/api/vision/tile/nearmap/{z}/{x}/{y}as a 256 raster overlay, same as satellite. Options are filtered on mount by/api/vision/basemaps.Also fixes (pre-existing, blocks CI on main)
Commit
f98b9485declaredmaskSource/confirmedOnlyinside theforloop inpostTrainManifestbut the manifest INSERT references them after the loop —go build ./api/failed on main. Hoisted the computation above the loop (no behavior change).Verification
go build ./...,go vet ./api ./nearmap ./configclean;go test ./nearmap3/3 pass, plus a regression test forOrganization.NearmapAPIKey().pnpm typecheckclean;pnpm build-syncclean.access-control-allow-origin: *with Origin header.Deploy note
Apply migration 00239 (
goose up), then set Delta's key per org viaorg update/sudo org update(nearmap_api_key). No env var needed.CI is green on the PR head (commit 86a20c7f) — run 1295 success.
go build/vet, tests, and pnpm typecheck/build all pass, so the branch is mergeable as-is. Note for reviewers: the postTrainManifest compile fix included here is the only thing un-breakinggo build ./api/on main (f98b9485broke it), so main stays red until this merges. Ready for review/merge — shout if you want anything changed.Follow-up push (42cd58db) with the per-organization gating refactor, now folded into this PR — CI run 1020 is green on the branch head.
Why: districts share one production instance, so the original global
NEARMAP_API_KEYenv var would have exposed Delta's paid Nearmap subscription to every district on the deployment (the licensing concern from #184). The key now lives in the DB instead:public.organization.nearmap_api_key(nullable) — migration 00239; set via org update / sudo org update; sudo summary exposes anearmapEnabledflag without leaking the key/api/vision/basemapsreports nearmap only for orgs with a key (UI button hidden otherwise)nearmap-cache/{orgID}/...) so tiles cached for one district are never served to anotherThe env var and its README entry are removed. PR description updated with the new deploy steps (goose up 00239 + per-org key, no env var).
42cd58db0123cbba601bNearmap has since been added in later commits.
Pull request closed