DJI Terra already emits standard XYZ z/x/y trees, so a good capture does not
need slicing again. scripts/import-tiles.ps1 validates the source, refuses a
tile-extension mismatch, copies it into the scan root, writes the manifest and
triggers a scan.
The extension check is the point: detectTileFormat picks whichever tile it
happens to see first and the published URL template uses that single extension,
so a layer mixing .png and .webp silently 404s half its tiles.
GUIDE.md gains the mixed workflow: import for the captures that are good as-is,
slice the GeoTIFF when the layer needs to be rebuildable as a mosaic.
docs/GUIDE.md walks through the jobs people actually do, rather than listing
routes: minting a token and fetching a first tile, wiring the tile template into
Leaflet and OpenLayers, accumulating drone imagery across several flights and
deciding when a mosaic rebuild is worth it, integrating a downstream system, a
symptom-to-cause troubleshooting table, and the day-to-day console actions.
API.md stays the reference; the README points at both.
Binding to 0.0.0.0 used to demand credentials because the admin console and
the tile routes shared one listener. That forced a choice between keeping the
console off the network and letting other machines fetch tiles.
Admin routes are now loopback-only by default: the service can bind 0.0.0.0 so
/tiles, /vectors, the catalog and the probes reach the LAN, while /admin and
/api/v1/admin answer 403 to anything arriving from another host. Credentials
are only required when ADMIN_ALLOW_REMOTE=true actually opens the console up,
which is the case worth guarding.
Tests cover both sides: a remote admin request is refused, a remote tile
request still reaches the token check.
docs/API.md covers authentication (admin credentials vs service tokens and
their scopes), every public endpoint grouped by purpose, the slicing request
and job shape, the completion callback, error codes, and the checklist for
exposing the console to the LAN.
A Go service that scans existing basemap tile directories and vector files,
catalogues them in SQLite, issues scoped access tokens, and serves tiles and
downloads to downstream systems. It deliberately does not generate or process
raster data: GIS software produces the tiles, this service catalogues,
authorises and distributes them.
Capabilities
- scans basemap tile directories (manifest-based or raw z/x/y) and vector
assets (.geojson, .json, .zip, shapefiles with sidecars)
- token auth with per-resource grants, expiry and coarse scopes (read, slice)
- resource health inspection flags a moved or deleted tile root before a client
hits a 404
- downstream push with exponential-backoff retries and manual re-queue
- image slicing jobs driven by the GDAL bundled with QGIS, including VRT
mosaicking so successive drone flights accumulate into one seamless layer
- a narrow, non-admin slicing API for external callers: submit, poll,
idempotent by job code, completion callback
- ops console covering health, ledger, tokens, pushes, scans, slicing and
service info
- native Windows service install/start/stop with crash recovery, auto-start and
a rotating log file, so no NSSM or WinSW wrapper is needed
Verified with 49 tests plus live runs against real tile data and real GDAL.