Oleksandr Bezdieniezhnykh
b0fffa6d42
Phase A baseline outputs from /autodev (Steps 1-5): - Problem & solution docs (_docs/00_problem, _docs/01_solution) - Codebase documentation (_docs/02_document) incl. architecture, module-layout, glossary, system-flows, baseline compliance scan - Test specs (blackbox, performance, resilience, security, resource, traceability matrix) - Test task decomposition (_docs/02_tasks/todo): AZ-285..AZ-290 - Testability refactor (_docs/04_refactoring/01-testability-refactoring): - TC-01 Move DownloadedTileInfoV2 + new ExistingTileInfo to Common.DTO - TC-02 Replace dead ISatelliteDownloader API with real signatures - TC-03 GoogleMapsDownloaderV2 implements ISatelliteDownloader - TC-04 TileService depends on ISatelliteDownloader (mockable) - TC-05 DI + endpoints use ISatelliteDownloader - Test runner scripts (scripts/run-tests.sh, run-performance-tests.sh) - Autodev state pointer (_docs/_autodev_state.md) Prepares the codebase for AZ-285..AZ-290 unit/integration test work. Co-authored-by: Cursor <cursoragent@cursor.com>
2.5 KiB
Problem Statement
What is the system?
Satellite Provider is a backend service that supplies satellite imagery to a GPS-denied UAV navigation system. It pre-downloads and caches satellite tiles from external imagery providers (Layer 1) and will accept UAV-captured nadir camera imagery (Layer 2) uploaded post-flight. The downloader component is implementation-agnostic — the architecture supports multiple satellite imagery providers (e.g., Google Maps) via the ISatelliteDownloader interface.
What problem does it solve?
UAVs operating without GPS rely on visual navigation by matching real-time camera imagery against pre-existing satellite maps. This requires:
- Pre-mission planning: satellite imagery for the planned route must be downloaded and available before flight, regardless of which imagery provider is used
- Post-mission ingestion: ground truth imagery captured during flight must be stored for future reference and improved accuracy
- Tile management: imagery must be organized by geographic coordinates and zoom level, deduplicated, and served efficiently
- Provider flexibility: the system must not be locked to a single satellite imagery source — providers may change or multiply
Without this service, operators would need to manually download and organize satellite imagery — an error-prone process that doesn't scale to multiple routes or large coverage areas.
Who are the users?
- GPS-Denied Navigation Service — the primary consumer, requesting tiles for route planning and accessing cached imagery for visual positioning
- Mission Planners — define routes and regions to pre-download satellite coverage
- UAV Systems (planned) — upload nadir camera tiles post-flight for Layer 2 enrichment
How does it work at a high level?
- A client defines a geographic area (region) or path (route) via the REST API
- The service calculates which satellite tiles are needed to cover that area
- Tiles are downloaded from the configured satellite imagery provider (abstracted via
ISatelliteDownloaderinterface; e.g., Google Maps) - Tiles are stored on disk and indexed in PostgreSQL
- Optionally, tiles are stitched into composite images and packaged as ZIP archives
- The client polls for completion and retrieves output artifacts
For routes, the service additionally:
- Interpolates intermediate points every ~200m along the path
- Applies geofence filters to limit tile downloads to areas of interest
- Generates consolidated route maps with geofence overlays