Using other tile services in Nidus reveal #184
ned
eliribble
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Hello @ned,
Some of our customers pay for tile services from other vendors like Nearmap. What would be nice is if they are paying for this service if we could make it available inside of Nidus Reveal so they can see our stuff with the high resolution Nearmap or other tile service. I have an example of Nearmap that is accesible by Delta, can you work out how to expose that as an option in the main Nidus Reveal UI?
Here is the source: https://api.nearmap.com/tiles/v3/Vert/{level}/{col}/{row}.img?apikey=N2JmOTFlY2MtYmViZS00Y2I5LTk5YjktMmRmMjFhNWQ4MWRm
@ned, you watchin this one?
Yep, watchin this one! 👀 Nearmap is now wired up as a basemap option in the main Nidus Reveal UI — PR #185 is open: #185
How it works:
NEARMAP_API_KEY) and tiles flow through the existing/api/vision/tile/{source}/{z}/{x}/{y}proxy (same auth + disk cache as the Stadia satellite basemap), so the key never ships to browsers./api/vision/basemapsendpoint gates it by config), so this is safe to ship to every district.One deploy note: someone needs to set
NEARMAP_API_KEYin the deployment env (Delta's key from this issue works). Also snuck in a fix for a pre-existing compile break on main (train manifest handler) that was blocking CI.@ned
Okay, very good. Just making sure that this doesn't leak between districts? These are paid subscriptions and so we don't want to violate any policies by giving data to those who have not paid for it.
Great catch — and you're right to push on it. Good news: it does not leak, but only after a fix I just pushed, because the first version of PR #185 was not district-safe.
Why the first cut was a problem: all districts run on one shared instance (
sync.nidus.cloud), so a single globalNEARMAP_API_KEYenv var would have let every district's users see the Nearmap button and pull tiles through the proxy. That's exactly the licensing violation you're worried about.Fix (pushed to PR #185, commit
42cd58db): Nearmap is now gated per-organization, not per-deployment:public.organization.nearmap_api_key), set via the org update API (account owner) or the sudo org API. Delta's key gets stored on Delta's org row only./api/vision/basemapsreports Nearmap only to orgs that have a key → non-subscribers never see the button.nearmap-cache/{orgID}/...), so one district's cached tiles are never served to another, even if both have keys.NEARMAP_API_KEYenv var removed (README updated). AddedOrganization.NearmapAPIKey()+ regression test.Deployment step changes: instead of setting an env var, ops stores Delta's key on Delta's organization row (via the sudo org API or a one-off UPDATE). Nothing else ships to every district.
Stadia stays global as before — that's our own subscription used platform-wide. Nearmap is the paid-per-district one, and it's now isolated per district.