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.
Demo Scripts
This folder contains runnable demos for the internal remote-sensing result service.
Prerequisites
- PostgreSQL and PostGIS are available to the API through
config/service.env. - The Python environment is available at
PYTHON_EXE. - Go is installed and can run
go run.
Service Startup
You can start the stack manually from the repository root:
.\start-all.bat
Or use the self-contained full-flow demo to start a temporary stack on demo ports:
.\demo\demo_full_flow.ps1 -StartStack -StartCallbackReceiver
Demo List
demo_import_and_slice.ps1Imports a raster result, binds a style, and triggers COG, preview, legend, and tile generation.demo_register_target_system.ps1Creates or updates a callback-based target system.demo_push_result.ps1Pushes an existing managed result to a target system or callback URL.demo_geojson_flow.ps1Registers a GeoJSON resource and optionally pushes it through the same delivery interface.demo_full_flow.ps1Runs the main end-to-end flow: sample raster, import, slice, target registration, and callback push.demo_callback_receiver.pySmall local receiver for inspecting push payloads.
Suggested Order
- Start the services manually, or run
demo_full_flow.ps1 -StartStack -StartCallbackReceiver. - Run
demo_import_and_slice.ps1to create a managed result. - Run
demo_register_target_system.ps1to register a callback receiver. - Run
demo_push_result.ps1to publish the managed result. - Run
demo_geojson_flow.ps1 -Pushif you want to verify the retained GeoJSON delivery path.
Example Commands
.\demo\demo_import_and_slice.ps1
.\demo\demo_register_target_system.ps1 -CallbackUrl http://127.0.0.1:8920/callback
.\demo\demo_push_result.ps1 -ResultCode demo_result_20260406_120000 -TargetSystemCode demo_callback
.\demo\demo_geojson_flow.ps1 -Push -CallbackUrl http://127.0.0.1:8920/callback
.\demo\demo_full_flow.ps1 -StartStack -StartCallbackReceiver
Output
Each demo prints a JSON summary that includes the main identifiers and URLs. Temporary run data is written under temp/demo-runs/.
source_system_code is intentionally left empty in the demos. If you want to populate it, seed the source_systems table first.