add solution drafts 3 times, used research skill, expand acceptance criteria

2026-04-23 02:06:36 +00:00 · 2026-03-14 20:38:00 +02:00
parent 767874cb90
commit d764250f9a
23 changed files with 3385 additions and 1 deletions
@@ -19,3 +19,15 @@
 - Mean Reprojection Error (MRE) < 1.0 pixels. The distance, in pixels, between the original pixel location of the object and the re-projected pixel location.

 - The whole system should work as a background service exposed via REST API with Server-Sent Events (SSE) for real-time streaming. Service should be up and running and awaiting for the initial request. On the request processing should start, and immediately after the first results system should provide them to the client via SSE stream
+
+- Satellite reference imagery resolution must be at least 0.5 m/pixel, ideally 0.3 m/pixel
+
+- System should report a confidence score per position estimate (high = satellite-anchored, low = VO-extrapolated with drift)
+
+- Output coordinates in WGS84 format (GeoJSON or CSV)
+
+- Satellite imagery for the operational area should be less than 2 years old where possible
+
+- Maximum cumulative VO drift between satellite correction anchors should be less than 100 meters
+
+- Memory usage should stay below 16GB RAM and 6GB VRAM to ensure RTX 2060 compatibility
@@ -0,0 +1,91 @@
+# Question Decomposition — Solution Assessment (Mode B, Draft02)
+
+## Original Question
+Assess solution_draft02.md for weak points, security vulnerabilities, and performance bottlenecks, then produce a revised solution draft03.
+
+## Active Mode
+Mode B: Solution Assessment — `solution_draft02.md` is the highest-numbered draft.
+
+## Question Type Classification
+- **Primary**: Problem Diagnosis — identify weak points, vulnerabilities, bottlenecks in draft02
+- **Secondary**: Decision Support — evaluate alternatives for identified issues
+
+## Research Subject Boundary Definition
+
+| Dimension | Boundary |
+|-----------|----------|
+| **Domain** | GPS-denied UAV visual navigation, aerial geo-referencing |
+| **Geography** | Eastern/southern Ukraine (left of Dnipro River) — steppe terrain |
+| **Hardware** | Desktop/laptop with NVIDIA RTX 2060+, 16GB RAM, 6GB VRAM |
+| **Software** | Python ecosystem, GPU-accelerated CV/ML |
+| **Timeframe** | Current state-of-the-art (2024-2026), production-ready tools |
+| **Scale** | 500-3000 images per flight, up to 6252×4168 resolution |
+
+## Problem Context Summary
+- UAV aerial photos taken consecutively ~100m apart, downward non-stabilized camera
+- Only starting GPS known — must determine GPS for all subsequent images
+- Must handle: sharp turns, outlier photos (up to 350m gap), disconnected route segments
+- Processing <5s/image, real-time SSE streaming, REST API service
+- No IMU data available
+- Camera: 26MP (6252×4168), 25mm focal length, 23.5mm sensor width, 400m altitude
+
+## Decomposed Sub-Questions
+
+### A: DINOv2 Cross-View Retrieval Viability
+"Is DINOv2 proven for UAV-to-satellite coarse retrieval? What are real-world performance numbers? What search radius is realistic?"
+
+### B: XFeat Reliability for Aerial VO
+"Is XFeat proven for aerial visual odometry? How does it compare to SuperPoint in aerial scenes specifically? What are known failure modes?"
+
+### C: LightGlue ONNX on RTX 2060 (Turing)
+"Does LightGlue-ONNX work reliably on Turing architecture? What precision (FP16/FP32)? What are actual benchmarks?"
+
+### D: GTSAM iSAM2 Factor Graph Design
+"Is the proposed factor graph structure sound? Are the noise models appropriate? Are custom factors (DEM, drift limit) well-specified?"
+
+### E: Copernicus DEM Integration
+"How is Copernicus DEM accessed programmatically? Is it truly free? What are the actual API requirements?"
+
+### F: Homography Decomposition Robustness
+"How reliable is cv2.decomposeHomographyMat selection heuristic when UAV changes direction? What are failure modes?"
+
+### G: Image Rotation Handling Completeness
+"Is heading-based rotation normalization sufficient? What if heading estimate is wrong early in a segment?"
+
+### H: Memory Model Under Load
+"Can DINOv2 embeddings + SuperPoint features + GTSAM factor graph + satellite cache fit within 16GB RAM and 6GB VRAM during a 3000-image flight?"
+
+### I: Satellite Match Failure Cascading
+"What happens when satellite matching fails for 50+ consecutive frames? How does the 100m drift limit interact with extended VO-only sections?"
+
+### J: Multi-Provider Tile Schema Compatibility
+"Do Google Maps and Mapbox use the same tile coordinate system? What are the practical differences in switching providers?"
+
+### K: Security Attack Surface
+"What are the remaining security vulnerabilities beyond JWT auth? SSE connection abuse? Image processing exploits?"
+
+### L: Recent Advances (2025-2026)
+"Are there newer models or approaches published since draft02 that could improve accuracy or performance?"
+
+### M: End-to-End Processing Time Budget
+"Is the total per-frame time budget realistic when all components run together? What is the critical path?"
+
+---
+
+## Timeliness Sensitivity Assessment
+
+- **Research Topic**: GPS-denied UAV visual navigation — assessment of solution_draft02 architecture and component choices
+- **Sensitivity Level**: 🟠 High
+- **Rationale**: CV feature matching models (SuperPoint, LightGlue, XFeat, DINOv2) evolve rapidly with new versions and competitors. GTSAM is stable. Satellite tile API pricing/limits change. Core algorithms (homography, VO) are stable.
+- **Source Time Window**: 12 months (2025-2026)
+- **Priority official sources to consult**:
+  1. GTSAM official documentation and PyPI (factor type compatibility)
+  2. LightGlue-ONNX GitHub (Turing GPU compatibility)
+  3. Google Maps Tiles API documentation (pricing, session tokens)
+  4. DINOv2 official repo (model variants, VRAM)
+  5. faiss wiki (GPU memory allocation)
+- **Key version information to verify**:
+  - GTSAM: 4.2 stable, 4.3 alpha (breaking changes)
+  - LightGlue-ONNX: FP16 on Turing, FP8 requires Ada Lovelace
+  - Pillow: ≥11.3.0 required (CVE-2025-48379)
+  - FastAPI: ≥0.135.0 (SSE support)
@@ -0,0 +1,212 @@
+# Source Registry — Draft02 Assessment
+
+## Source #1
+- **Title**: GTSAM GPSFactor Class Reference
+- **Link**: https://gtsam.org/doxygen/a04084.html
+- **Tier**: L1
+- **Publication Date**: 2025 (latest docs)
+- **Timeliness Status**: ✅ Currently valid
+- **Version Info**: GTSAM 4.2
+- **Target Audience**: GTSAM users building factor graphs with GPS constraints
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: GPSFactor and GPSFactor2 work with Pose3/NavState, NOT Pose2. For 2D position constraints, PriorFactorPoint2 or custom factors are needed.
+- **Related Sub-question**: D (GTSAM iSAM2 Factor Graph Design)
+
+## Source #2
+- **Title**: GTSAM Pose2 SLAM Example
+- **Link**: https://gtbook.github.io/gtsam-examples/Pose2SLAMExample.html
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Version Info**: GTSAM 4.2
+- **Target Audience**: GTSAM users
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: BetweenFactorPose2 provides odometry constraints with noise model Diagonal.Sigmas(Point3(sigma_x, sigma_y, sigma_theta)). PriorFactorPose2 anchors poses.
+- **Related Sub-question**: D
+
+## Source #3
+- **Title**: GTSAM Python pip install version compatibility (PyPI)
+- **Link**: https://pypi.org/project/gtsam/
+- **Tier**: L1
+- **Publication Date**: 2026-01
+- **Timeliness Status**: ✅ Currently valid
+- **Version Info**: gtsam 4.2 (stable), gtsam-develop 4.3a1 (alpha)
+- **Target Audience**: Python developers
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: GTSAM 4.2 stable on pip. 4.3 alpha has breaking changes (C++17, Boost removal). Known issues with Eigen 5.0.0, ARM64 builds. Stick with 4.2 for production.
+- **Related Sub-question**: D
+
+## Source #4
+- **Title**: LightGlue-ONNX repository
+- **Link**: https://github.com/fabio-sim/LightGlue-ONNX
+- **Tier**: L1
+- **Publication Date**: 2026-01 (last updated)
+- **Timeliness Status**: ✅ Currently valid
+- **Version Info**: LightGlue-ONNX (supports ONNX Runtime + TensorRT)
+- **Target Audience**: Computer vision developers
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: ONNX export with 2-4x speedup over PyTorch. FP16 works on Turing (RTX 2060). FP8 requires Ada Lovelace/Hopper. Mixed precision supported since July 2023.
+- **Related Sub-question**: C (LightGlue ONNX on RTX 2060)
+
+## Source #5
+- **Title**: LightGlue rotation issue #64
+- **Link**: https://github.com/cvg/LightGlue/issues/64
+- **Tier**: L4
+- **Publication Date**: 2023
+- **Timeliness Status**: ✅ Currently valid (issue still open)
+- **Target Audience**: LightGlue users
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: SuperPoint+LightGlue not rotation-invariant. Fails at 90°/180°. Workaround: try rotating images by {0°, 90°, 180°, 270°}. Steerable CNNs proposed but not available.
+- **Related Sub-question**: G (Image Rotation Handling)
+
+## Source #6
+- **Title**: SIFT+LightGlue for UAV Image Mosaicking (ISPRS 2025)
+- **Link**: https://isprs-archives.copernicus.org/articles/XLVIII-2-W11-2025/169/2025/
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Summary**: SIFT+LightGlue hybrid achieves robust matching in low-texture and high-rotation UAV scenarios. Outperforms both pure SIFT and SuperPoint+LightGlue.
+- **Related Sub-question**: G
+
+## Source #7
+- **Title**: DINOv2-Based UAV Visual Self-Localization
+- **Link**: https://ui.adsabs.harvard.edu/abs/2025IRAL...10.2080Y/abstract
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: UAV localization researchers
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: DINOv2 with adaptive enhancement achieves 86.27 R@1 on DenseUAV benchmark for UAV-to-satellite matching. Proves DINOv2 viable for coarse retrieval.
+- **Related Sub-question**: A (DINOv2 Cross-View Retrieval)
+
+## Source #8
+- **Title**: SatLoc-Fusion (Remote Sensing 2025)
+- **Link**: https://www.mdpi.com/2072-4292/17/17/3048
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: UAV navigation researchers
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: Hierarchical: DINOv2 absolute + XFeat VO + optical flow. <15m error, >2Hz on 6 TFLOPS edge. Adaptive confidence-based fusion. Validates our approach architecture.
+- **Related Sub-question**: A, B
+
+## Source #9
+- **Title**: XFeat: Accelerated Features (CVPR 2024)
+- **Link**: https://arxiv.org/abs/2404.19174
+- **Tier**: L1
+- **Publication Date**: 2024
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: CV researchers
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: 5x faster than SuperPoint. Real-time on CPU. Semi-dense matching. XFeat has built-in matcher for fast VO; also compatible with LightGlue via xfeat-lightglue models.
+- **Related Sub-question**: B (XFeat Reliability)
+
+## Source #10
+- **Title**: XFeat + LightGlue compatibility (GitHub issue #128)
+- **Link**: https://github.com/cvg/LightGlue/issues/128
+- **Tier**: L4
+- **Publication Date**: 2024
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: LightGlue/XFeat users
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: XFeat-LightGlue trained models available on HuggingFace (vismatch/xfeat-lightglue). Also ONNX export available. XFeat's built-in matcher is separate.
+- **Related Sub-question**: B
+
+## Source #11
+- **Title**: DINOv2 VRAM usage by model variant
+- **Link**: https://blog.iamfax.com/tech/image-processing/dinov2/
+- **Tier**: L3
+- **Publication Date**: 2024
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: Developers deploying DINOv2
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: ViT-S/14: ~300MB VRAM, 0.05s/img. ViT-B/14: ~600MB, 0.1s/img. ViT-L/14: ~1.5GB, 0.35s/img. ViT-G/14: ~5GB, 2s/img.
+- **Related Sub-question**: H (Memory Model)
+
+## Source #12
+- **Title**: Copernicus DEM on AWS Open Data
+- **Link**: https://registry.opendata.aws/copernicus-dem/
+- **Tier**: L1
+- **Publication Date**: Ongoing
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: Developers needing DEM data
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: Free access via S3 without authentication. Cloud Optimized GeoTIFFs, 1x1 degree tiles, 30m resolution. `aws s3 ls --no-sign-required s3://copernicus-dem-30m/`
+- **Related Sub-question**: E (Copernicus DEM)
+
+## Source #13
+- **Title**: Google Maps Tiles API Usage and Billing
+- **Link**: https://developers.google.com/maps/documentation/tile/usage-and-billing
+- **Tier**: L1
+- **Publication Date**: 2026-02 (updated)
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: Google Maps API consumers
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: 100K free requests/month. 6,000/min, 15,000/day rate limits. $200 monthly credit expired Feb 2025. Requires session tokens.
+- **Related Sub-question**: J
+
+## Source #14
+- **Title**: Google Maps vs Mapbox tile schema
+- **Link**: https://developers.google.com/maps/documentation/tile/2d-tiles-overview
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Summary**: Both use z/x/y Web Mercator tiles (256px). Compatible coordinate systems. Google requires session tokens; Mapbox requires API tokens. Mapbox global to zoom 16, regional to 21+.
+- **Related Sub-question**: J
+
+## Source #15
+- **Title**: FastAPI SSE connection cleanup issues (sse-starlette #99)
+- **Link**: https://github.com/sysid/sse-starlette/issues/99
+- **Tier**: L4
+- **Publication Date**: 2024
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: FastAPI SSE developers
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: Async generators cannot be easily cancelled once awaited. Use EventPublisher pattern with asyncio.Queue for proper cleanup. Prevents shutdown hangs and connection lingering.
+- **Related Sub-question**: K (Security/Stability)
+
+## Source #16
+- **Title**: OpenCV decomposeHomographyMat issues (#23282)
+- **Link**: https://github.com/opencv/opencv/issues/23282
+- **Tier**: L4
+- **Publication Date**: 2023
+- **Timeliness Status**: ✅ Currently valid
+- **Summary**: decomposeHomographyMat can return non-orthogonal rotation matrices. Returns 4 solutions. Positive depth constraint needed for disambiguation. Calibration matrix K precision critical.
+- **Related Sub-question**: F (Homography Decomposition)
+
+## Source #17
+- **Title**: CVE-2025-48379: Pillow Heap Buffer Overflow
+- **Link**: https://nvd.nist.gov/vuln/detail/CVE-2025-48379
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Version Info**: Pillow 11.2.0-11.2.1 affected, fixed in 11.3.0
+- **Summary**: Heap buffer overflow in Pillow's image encoding. Requires pinning Pillow ≥11.3.0 and validating image formats.
+- **Related Sub-question**: K (Security)
+
+## Source #18
+- **Title**: SALAD: Optimal Transport Aggregation for Visual Place Recognition
+- **Link**: https://arxiv.org/abs/2311.15937
+- **Tier**: L1
+- **Publication Date**: 2024
+- **Timeliness Status**: ✅ Currently valid
+- **Summary**: DINOv2+SALAD outperforms NetVLAD. Single-stage retrieval, no re-ranking. 30min training. Optimal transport aggregation better than raw DINOv2 CLS token for retrieval.
+- **Related Sub-question**: A
+
+## Source #19
+- **Title**: NaviLoc: Trajectory-Level Visual Localization
+- **Link**: https://www.mdpi.com/2504-446X/10/2/97
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Summary**: Treats VPR as noisy measurement, uses trajectory-level optimization. 19.5m MLE, 16x improvement over per-frame VPR. Validates trajectory optimization approach.
+- **Related Sub-question**: L (Recent Advances)
+
+## Source #20
+- **Title**: FAISS GPU memory management
+- **Link**: https://github.com/facebookresearch/faiss/wiki/Faiss-on-the-GPU
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Summary**: GPU faiss allocates ~2GB scratch space by default. On 6GB VRAM RTX 2060, CPU-based faiss recommended. Supports CPU-GPU interop.
+- **Related Sub-question**: H (Memory)
@@ -0,0 +1,142 @@
+# Fact Cards — Draft02 Assessment
+
+## Fact #1
+- **Statement**: GTSAM `GPSFactor` works with `Pose3` variables, NOT `Pose2`. `GPSFactor2` works with `NavState`. Neither accepts `Pose2`. For 2D position constraints, use `PriorFactorPoint2` or a custom factor.
+- **Source**: [Source #1] https://gtsam.org/doxygen/a04084.html, [Source #2]
+- **Phase**: Assessment
+- **Target Audience**: GPS-denied UAV navigation developers
+- **Confidence**: ✅ High (official GTSAM documentation)
+- **Related Dimension**: Factor Graph Design
+
+## Fact #2
+- **Statement**: GTSAM 4.2 is stable on pip. GTSAM 4.3 alpha has breaking changes (C++17 migration, Boost removal). Known pip dependency resolution issues for Python bindings (Sept 2025). Production should use 4.2.
+- **Source**: [Source #3] https://pypi.org/project/gtsam/
+- **Phase**: Assessment
+- **Confidence**: ✅ High (PyPI official)
+- **Related Dimension**: Factor Graph Design
+
+## Fact #3
+- **Statement**: LightGlue-ONNX achieves 2-4x speedup over compiled PyTorch. FP16 works on Turing (RTX 2060). FP8 requires Ada Lovelace/Hopper — falls back to higher precision on Turing. Mixed precision supported since July 2023.
+- **Source**: [Source #4] https://github.com/fabio-sim/LightGlue-ONNX
+- **Phase**: Assessment
+- **Confidence**: ✅ High (official repo, benchmarks)
+- **Related Dimension**: Processing Performance
+
+## Fact #4
+- **Statement**: SuperPoint and LightGlue are NOT rotation-invariant. Performance degrades significantly at 90°/180° rotations. Practical workaround: try matching at {0°, 90°, 180°, 270°} rotations. SIFT+LightGlue hybrid is proven better for high-rotation UAV scenarios (ISPRS 2025).
+- **Source**: [Source #5] issue #64, [Source #6] ISPRS 2025
+- **Phase**: Assessment
+- **Confidence**: ✅ High (confirmed in official issue + peer-reviewed paper)
+- **Related Dimension**: Rotation Handling
+
+## Fact #5
+- **Statement**: DINOv2 achieves 86.27 R@1 on DenseUAV benchmark for UAV-to-satellite matching (with adaptive enhancement). Raw DINOv2 performance is lower but still viable for coarse retrieval.
+- **Source**: [Source #7] https://ui.adsabs.harvard.edu/abs/2025IRAL...10.2080Y/
+- **Phase**: Assessment
+- **Confidence**: ✅ High (peer-reviewed)
+- **Related Dimension**: Satellite Matching
+
+## Fact #6
+- **Statement**: SatLoc-Fusion validates the exact architecture pattern: DINOv2 for absolute geo-localization + XFeat for VO + optical flow for velocity. Achieves <15m error at >2Hz on 6 TFLOPS edge hardware. Uses adaptive confidence-based fusion.
+- **Source**: [Source #8] https://www.mdpi.com/2072-4292/17/17/3048
+- **Phase**: Assessment
+- **Confidence**: ✅ High (peer-reviewed, dataset provided)
+- **Related Dimension**: Overall Architecture
+
+## Fact #7
+- **Statement**: XFeat is 5x faster than SuperPoint. Runs real-time on CPU. Has built-in matcher for fast matching. Also compatible with LightGlue via xfeat-lightglue trained models (HuggingFace vismatch/xfeat-lightglue). ONNX export available.
+- **Source**: [Source #9] CVPR 2024, [Source #10] GitHub
+- **Phase**: Assessment
+- **Confidence**: ✅ High (CVPR paper + working implementations)
+- **Related Dimension**: Feature Extraction
+
+## Fact #8
+- **Statement**: DINOv2 VRAM: ViT-S/14 ~300MB (0.05s/img), ViT-B/14 ~600MB (0.1s/img), ViT-L/14 ~1.5GB (0.35s/img). On GTX 1080.
+- **Source**: [Source #11] blog benchmark
+- **Phase**: Assessment
+- **Confidence**: ⚠️ Medium (third-party benchmark, not official)
+- **Related Dimension**: Memory Model
+
+## Fact #9
+- **Statement**: Copernicus DEM GLO-30 is freely available on AWS S3 without authentication: `s3://copernicus-dem-30m/`. Cloud Optimized GeoTIFFs, 30m resolution, global coverage. Alternative: Sentinel Hub API (requires free registration).
+- **Source**: [Source #12] AWS Registry
+- **Phase**: Assessment
+- **Confidence**: ✅ High (AWS official registry)
+- **Related Dimension**: DEM Integration
+
+## Fact #10
+- **Statement**: Google Maps Tiles API: 100K free requests/month, 15,000/day, 6,000/min. Requires session tokens (not just API key). $200 monthly credit expired Feb 2025. February 2026: split quota buckets for 2D and Street View tiles.
+- **Source**: [Source #13] Google official docs
+- **Phase**: Assessment
+- **Confidence**: ✅ High (official documentation)
+- **Related Dimension**: Satellite Provider
+
+## Fact #11
+- **Statement**: Google Maps and Mapbox both use z/x/y Web Mercator tiles (256px). Compatible coordinate systems. Main differences: authentication method (session tokens vs API tokens), max zoom levels (Google: 22, Mapbox: global 16, regional 21+).
+- **Source**: [Source #14] Google + Mapbox docs
+- **Phase**: Assessment
+- **Confidence**: ✅ High (official docs)
+- **Related Dimension**: Multi-Provider Cache
+
+## Fact #12
+- **Statement**: FastAPI SSE async generators cannot be easily cancelled once awaited. Causes shutdown hangs, connection lingering. Solution: EventPublisher pattern with asyncio.Queue for proper lifecycle management.
+- **Source**: [Source #15] sse-starlette issue #99
+- **Phase**: Assessment
+- **Confidence**: ⚠️ Medium (community report, confirmed by library maintainer)
+- **Related Dimension**: API Stability
+
+## Fact #13
+- **Statement**: cv2.decomposeHomographyMat returns up to 4 solutions. Can return non-orthogonal rotation matrices. Disambiguation requires: positive depth constraint + calibration matrix K precision. Not just "motion consistent with previous direction."
+- **Source**: [Source #16] OpenCV issue #23282
+- **Phase**: Assessment
+- **Confidence**: ✅ High (confirmed OpenCV issue)
+- **Related Dimension**: VO Robustness
+
+## Fact #14
+- **Statement**: Pillow CVE-2025-48379: heap buffer overflow in 11.2.0-11.2.1. Fixed in 11.3.0. Image processing pipeline must pin Pillow ≥11.3.0.
+- **Source**: [Source #17] NVD
+- **Phase**: Assessment
+- **Confidence**: ✅ High (CVE database)
+- **Related Dimension**: Security
+
+## Fact #15
+- **Statement**: DINOv2+SALAD (optimal transport aggregation) outperforms raw DINOv2 CLS token for visual place recognition. Single-stage, no re-ranking needed. 30-minute training. Better suited for coarse retrieval than raw cosine similarity on CLS tokens.
+- **Source**: [Source #18] arXiv
+- **Phase**: Assessment
+- **Confidence**: ✅ High (peer-reviewed)
+- **Related Dimension**: Satellite Matching
+
+## Fact #16
+- **Statement**: FAISS GPU allocates ~2GB scratch space by default. On 6GB VRAM RTX 2060, GPU faiss would consume 33% of VRAM just for indexing. CPU-based faiss recommended for this hardware profile.
+- **Source**: [Source #20] FAISS wiki
+- **Phase**: Assessment
+- **Confidence**: ✅ High (official wiki)
+- **Related Dimension**: Memory Model
+
+## Fact #17
+- **Statement**: NaviLoc achieves 19.5m MLE by treating VPR as noisy measurement and optimizing at trajectory level (not per-frame). 16x improvement over per-frame approaches. Validates trajectory-level optimization concept.
+- **Source**: [Source #19]
+- **Phase**: Assessment
+- **Confidence**: ✅ High (peer-reviewed)
+- **Related Dimension**: Optimization Strategy
+
+## Fact #18
+- **Statement**: Mapbox satellite imagery for Ukraine: no specific update schedule. Uses Maxar Vivid product. Coverage to zoom 16 globally (~2.5m/px), regional zoom 18+ (~0.6m/px). No guarantee of Ukraine freshness — likely 2+ years old in conflict areas.
+- **Source**: [Source #14] Mapbox docs
+- **Phase**: Assessment
+- **Confidence**: ⚠️ Medium (general Mapbox info, no Ukraine-specific data)
+- **Related Dimension**: Satellite Provider
+
+## Fact #19
+- **Statement**: For 2D factor graphs, GTSAM uses Pose2 (x, y, theta) with BetweenFactorPose2 for odometry and PriorFactorPose2 for anchoring. Position-only constraints use PriorFactorPoint2. Custom factors via Python callbacks are supported but slower than C++ factors.
+- **Source**: [Source #2] GTSAM by Example
+- **Phase**: Assessment
+- **Confidence**: ✅ High (official GTSAM examples)
+- **Related Dimension**: Factor Graph Design
+
+## Fact #20
+- **Statement**: XFeat's built-in matcher (match_xfeat) is fastest for VO (~15ms total extraction+matching). xfeat-lightglue is higher quality but slower. For satellite matching where accuracy matters more, SuperPoint+LightGlue remains the better choice.
+- **Source**: [Source #9] CVPR 2024, [Source #10]
+- **Phase**: Assessment
+- **Confidence**: ⚠️ Medium (inference from multiple sources)
+- **Related Dimension**: Feature Extraction Strategy
@@ -0,0 +1,31 @@
+# Comparison Framework — Draft02 Assessment
+
+## Selected Framework Type
+Problem Diagnosis + Decision Support
+
+## Selected Dimensions
+1. Factor Graph Design Correctness
+2. VRAM/Memory Budget Feasibility
+3. Rotation Handling Completeness
+4. VO Robustness (Homography Decomposition)
+5. Satellite Matching Reliability
+6. Concurrency & Pipeline Architecture
+7. Security Attack Surface
+8. API/SSE Stability
+9. Provider Integration Completeness
+10. Drift Management Strategy
+
+## Findings Matrix
+
+| Dimension | Draft02 Approach | Weak Point | Severity | Proposed Fix | Factual Basis |
+|-----------|------------------|------------|----------|--------------|---------------|
+| Factor Graph | Pose2 + GPSFactor + custom DEM/drift factors | GPSFactor requires Pose3, not Pose2. Custom Python factors are slow. | **Critical** | Use Pose2 + BetweenFactorPose2 + PriorFactorPoint2 for satellite anchors. Convert lat/lon to local ENU. Avoid Python custom factors. | Fact #1, #2, #19 |
+| VRAM Budget | DINOv2 + SuperPoint + LightGlue ONNX + faiss GPU | No model specified for DINOv2. faiss GPU uses 2GB scratch. Combined VRAM could exceed 6GB. | **High** | Use DINOv2 ViT-S/14 (300MB). faiss on CPU only. Sequence model loading (not concurrent). Explicit budget: XFeat 200MB + DINOv2-S 300MB + SuperPoint 400MB + LightGlue 500MB. | Fact #8, #16 |
+| Rotation Handling | Heading-based rectification + SIFT fallback | No heading at segment start. No trigger criteria for SIFT vs rotation retry. Multi-rotation matching not mentioned. | **High** | At segment start: try 4 rotations {0°, 90°, 180°, 270°}. After heading established: rectify. SIFT fallback when SuperPoint inlier ratio < 0.2. | Fact #4 |
+| Homography Decomposition | Motion consistency selection | Only "motion consistent with previous direction" — underspecified. 4 solutions possible. Non-orthogonal matrices can occur. | **Medium** | Positive depth constraint first. Then normal direction check (plane normal should point up). Then motion consistency. Orthogonality check on R. | Fact #13 |
+| Satellite Coarse Retrieval | DINOv2 + faiss cosine similarity | Raw DINOv2 CLS token suboptimal for retrieval. SALAD aggregation proven better. | **Medium** | Use DINOv2+SALAD or at minimum use patch-level features, not just CLS token. Alternatively, fine-tune DINOv2 on remote sensing. | Fact #5, #15 |
+| Concurrency Model | "Async — don't block VO pipeline" | No concrete concurrency design. GPU can't run two models simultaneously. | **High** | Sequential GPU: XFeat VO first (15ms), then async satellite matching on same GPU. Use asyncio for I/O (tile download, DEM fetch). CPU faiss for retrieval. | Fact #8, #16 |
+| Security | JWT + rate limiting + CORS | No image format validation. No Pillow version pinning. No SSE abuse protection beyond connection limits. No sandbox for image processing. | **Medium** | Pin Pillow ≥11.3.0. Validate image magic bytes. Limit image dimensions before loading. Memory-map large images. CSP headers. | Fact #14 |
+| SSE Stability | FastAPI EventSourceResponse | Async generator cleanup issues on shutdown. No heartbeat. No reconnection strategy. | **Medium** | Use asyncio.Queue-based EventPublisher. Add SSE heartbeat every 15s. Include Last-Event-ID for reconnection. | Fact #12 |
+| Provider Integration | Google Maps + Mapbox + user tiles | Google requires session tokens (not just API key). 15K/day limit = ~7 flights from cache misses. Mapbox Ukraine coverage uncertain. | **Medium** | Implement session token management for Google. Add Bing Maps as third provider. Document DEM+tile download budget per flight. | Fact #10, #11, #18 |
+| Drift Management | 100m cumulative drift limit factor | Custom factor. If satellite fails for 50+ frames, no anchors → drift factor has nothing to constrain against. | **High** | Add dead-reckoning confidence decay: after N frames without anchor, emit warning + request user input. Track estimated drift explicitly. Set hard limit for user input request. | Fact #17 |
@@ -0,0 +1,192 @@
+# Reasoning Chain — Draft02 Assessment
+
+## Dimension 1: Factor Graph Design Correctness
+
+### Fact Confirmation
+According to Fact #1, GTSAM's `GPSFactor` class works exclusively with `Pose3` variables. `GPSFactor2` works with `NavState`. Neither accepts `Pose2`. According to Fact #19, `PriorFactorPoint2` provides 2D position constraints, and `BetweenFactorPose2` provides 2D odometry constraints.
+
+### Problem
+Draft02 specifies `Pose2 (x, y, heading)` variables but lists `GPSFactor` for satellite anchors. This is an API mismatch — the code would fail at runtime.
+
+### Solution
+Two valid approaches:
+1. **Pose2 graph (recommended)**: Use `Pose2` variables + `BetweenFactorPose2` for VO + `PriorFactorPose2` for satellite anchors (constraining full pose when heading is available) or use a custom partial factor that constrains only the position part of Pose2. Convert WGS84 to local ENU coordinates centered on starting GPS.
+2. **Pose3 graph**: Use `Pose3` with fixed altitude. More accurate but adds unnecessary complexity for 2D problem.
+
+The custom DEM terrain factor and drift limit factor also need reconsideration: Python custom factors invoke a Python callback per optimization step, which is slow. DEM terrain is irrelevant for 2D Pose2 (altitude is not a variable). Drift should be managed by the Segment Manager logic, not as a factor.
+
+### Conclusion
+Switch to Pose2 + BetweenFactorPose2 + PriorFactorPose2 (or partial position prior). Remove DEM terrain factor (handle elevation in GSD calculation outside the graph). Remove drift limit factor (handle in Segment Manager). This simplifies the factor graph and avoids Python callback overhead.
+
+### Confidence
+✅ High — based on official GTSAM documentation
+
+---
+
+## Dimension 2: VRAM/Memory Budget Feasibility
+
+### Fact Confirmation
+According to Fact #8: DINOv2 ViT-S/14 ~300MB, ViT-B/14 ~600MB. Fact #16: faiss GPU uses ~2GB scratch. Fact #3: LightGlue ONNX FP16 works on RTX 2060.
+
+### Problem
+Draft02 doesn't specify DINOv2 model size. Proposing faiss GPU would consume 2GB of 6GB VRAM. Combined with other models, total could exceed 6GB. Draft02 estimates ~1.5GB per frame for XFeat/SuperPoint + LightGlue, but doesn't account for DINOv2 or faiss.
+
+### Budget Analysis
+Concurrent peak VRAM (worst case):
+- XFeat inference: ~200MB
+- LightGlue ONNX (FP16): ~500MB
+- DINOv2 ViT-B/14: ~600MB
+- SuperPoint: ~400MB
+- faiss GPU: ~2GB
+- ONNX Runtime overhead: ~300MB
+- **Total: ~4.0GB** (without faiss GPU: ~2.0GB)
+
+Sequential loading (recommended):
+- Step 1: XFeat + XFeat matcher (VO): ~400MB
+- Step 2: DINOv2-S (coarse retrieval): ~300MB → unload
+- Step 3: SuperPoint + LightGlue ONNX (fine matching): ~900MB
+- Peak: ~1.3GB (with model switching)
+
+### Conclusion
+Use DINOv2 ViT-S/14 (300MB, 0.05s/img — fast enough for coarse retrieval). Run faiss on CPU (the embedding vectors are small, CPU search is <1ms for ~2000 vectors). Sequential model loading for GPU: VO models first, then satellite matching models. Keep models loaded but process sequentially (no concurrent GPU inference).
+
+### Confidence
+✅ High — based on documented VRAM numbers
+
+---
+
+## Dimension 3: Rotation Handling Completeness
+
+### Fact Confirmation
+According to Fact #4, SuperPoint+LightGlue fail at 90°/180° rotations. According to Fact #6 (ISPRS 2025), SIFT+LightGlue outperforms SuperPoint+LightGlue in high-rotation UAV scenarios.
+
+### Problem
+Draft02 says "estimate heading from VO chain, rectify images before satellite matching, SIFT fallback for rotation-heavy cases." But:
+1. At segment start, there's no heading from VO chain — no rectification possible.
+2. No criteria for when to trigger SIFT fallback.
+3. Multi-rotation matching strategy ({0°, 90°, 180°, 270°}) not mentioned.
+
+### Conclusion
+Three-tier rotation handling:
+1. **Segment start (no heading)**: Try DINOv2 coarse retrieval (more rotation-robust than local features) → if match found, estimate heading from satellite alignment → proceed normally.
+2. **Normal operation (heading available)**: Rectify to approximate north-up using accumulated heading → SuperPoint+LightGlue.
+3. **Match failure fallback**: Try 4 rotations {0°, 90°, 180°, 270°} with SuperPoint. If still fails → SIFT+LightGlue (rotation-invariant).
+
+Trigger for SIFT: SuperPoint inlier ratio < 0.15 after rotation retry.
+
+### Confidence
+✅ High — based on confirmed LightGlue limitation + proven SIFT+LightGlue alternative
+
+---
+
+## Dimension 4: VO Robustness (Homography Decomposition)
+
+### Fact Confirmation
+According to Fact #13, cv2.decomposeHomographyMat returns 4 solutions. Can return non-orthogonal matrices. Calibration matrix K precision is critical.
+
+### Problem
+Draft02 specifies selection by "motion consistent with previous direction + positive depth." This is underspecified for the first frame pair in a segment (no previous direction). Non-orthogonal R detection is missing.
+
+### Conclusion
+Disambiguation procedure:
+1. Compute all 4 decompositions.
+2. **Filter by positive depth**: triangulate a few matched points, reject solutions where points are behind camera.
+3. **Filter by plane normal**: for downward-looking camera, the normal should approximately point up (positive z component in camera frame).
+4. **Motion consistency**: if previous direction available, prefer solution consistent with expected motion direction.
+5. **Orthogonality check**: verify R'R ≈ I, det(R) ≈ 1. If not, re-orthogonalize via SVD.
+6. For first frame pair: rely on filters 2+3 only.
+
+### Confidence
+✅ High — based on well-documented decomposition ambiguity
+
+---
+
+## Dimension 5: Satellite Coarse Retrieval
+
+### Fact Confirmation
+According to Fact #15, DINOv2+SALAD outperforms raw DINOv2 CLS token for retrieval. According to Fact #5, DINOv2 achieves 86.27 R@1 with adaptive enhancement.
+
+### Problem
+Draft02 proposes "DINOv2 global retrieval + faiss cosine similarity." Using raw CLS token is suboptimal. SALAD or patch-level feature aggregation would improve retrieval accuracy.
+
+### Conclusion
+DINOv2+SALAD is the better approach but adds a training/fine-tuning dependency. For a production system without the ability to fine-tune: use DINOv2 patch tokens (not just CLS) with spatial pooling, then cosine similarity via faiss. This captures more spatial information than CLS alone. If time permits, train SALAD head (30 minutes on appropriate dataset).
+
+Alternatively, consider SatDINO (DINOv2 pre-trained on satellite imagery) if available as a checkpoint.
+
+### Confidence
+⚠️ Medium — SALAD is proven but adding training dependency may not be worth the complexity for this use case
+
+---
+
+## Dimension 6: Concurrency & Pipeline Architecture
+
+### Fact Confirmation
+Single GPU (RTX 2060) cannot run two models concurrently. Fact #8 shows sequential model inference times. Fact #3 shows LightGlue ONNX at ~50-100ms.
+
+### Problem
+Draft02 says satellite matching is "async — don't block VO pipeline" but on a single GPU, you can't parallelize GPU inference.
+
+### Conclusion
+Pipeline design:
+1. **VO (synchronous, per-frame)**: XFeat extract + match (~30ms total) → homography estimation (~5ms) → GTSAM update (~5ms) → emit position via SSE. **Total: ~40ms per frame.**
+2. **Satellite matching (asynchronous, overlapped with next frame's VO)**: DINOv2 coarse (~50ms) → SuperPoint+LightGlue fine (~150ms) → GTSAM update (~5ms) → emit refined position. **Total: ~205ms but overlapped.**
+3. **I/O (fully async)**: Tile download, DEM fetch, cache management — all via asyncio.
+4. **CPU tasks (parallel)**: faiss search (CPU), homography RANSAC (CPU-bound but fast).
+
+The GPU processes frames sequentially. The "async" part is that satellite matching for frame N happens while VO for frame N+1 proceeds. Since satellite matching (~205ms) is longer than VO (~40ms), the pipeline is satellite-matching-bound but VO results stream immediately.
+
+### Confidence
+✅ High — based on documented inference times
+
+---
+
+## Dimension 7: Security Attack Surface
+
+### Fact Confirmation
+According to Fact #14, Pillow CVE-2025-48379 affects image loading. Fact #12 confirms SSE cleanup issues.
+
+### Problem
+Draft02 has JWT + rate limiting + CORS but misses:
+- Image format/magic byte validation before loading
+- Pillow version pinning
+- Memory-limited image loading (a 100,000 × 100,000 pixel image could OOM)
+- SSE heartbeat for connection health
+- No mention of directory traversal prevention depth
+
+### Conclusion
+Additional security measures:
+1. Pin Pillow ≥11.3.0 in requirements.
+2. Validate image magic bytes (JPEG/PNG/TIFF) before loading with PIL.
+3. Check image dimensions before loading: reject if either dimension > 10,000px.
+4. Use OpenCV for loading (separate from PIL) — validate separately.
+5. Resolve image_folder path to canonical form (os.path.realpath) and verify it's under allowed base directories.
+6. Add Content-Security-Policy headers.
+7. SSE heartbeat every 15s to detect stale connections.
+8. Implement asyncio.Queue-based event publisher for SSE.
+
+### Confidence
+✅ High — based on documented CVE + known SSE issues
+
+---
+
+## Dimension 8: Drift Management Strategy
+
+### Fact Confirmation
+According to Fact #17, NaviLoc demonstrates that trajectory-level optimization with noisy VPR measurements achieves 16x better accuracy than per-frame approaches. SatLoc-Fusion uses adaptive confidence metrics.
+
+### Problem
+Draft02's "drift limit factor" as a GTSAM custom factor is problematic: (1) custom Python factors are slow, (2) if no satellite anchors arrive for extended period, the drift factor has nothing to constrain against.
+
+### Conclusion
+Replace GTSAM drift factor with Segment Manager logic:
+1. Track cumulative VO displacement since last satellite anchor.
+2. If cumulative displacement > 100m without anchor: emit warning SSE event, increase satellite matching frequency/radius.
+3. If cumulative displacement > 200m: request user input with timeout.
+4. If cumulative displacement > 500m: mark segment as LOW confidence, continue but warn.
+5. Confidence score per position: decays exponentially with distance from nearest anchor.
+
+This is simpler, faster, and more controllable than a GTSAM custom factor.
+
+### Confidence
+✅ High — engineering judgment supported by SatLoc-Fusion's confidence-based approach
@@ -0,0 +1,100 @@
+# Validation Log — Draft02 Assessment (Draft03)
+
+## Validation Scenario 1: Factor graph initialization with first satellite match
+
+**Scenario**: Flight starts, VO processes 10 frames, satellite match arrives for frame 5.
+
+**Expected with Draft03 fixes**:
+1. GTSAM graph starts with PriorFactorPose2 at starting GPS (frame 0).
+2. BetweenFactorPose2 added for frames 0→1, 1→2, ..., 9→10.
+3. Satellite match for frame 5: add PriorFactorPose2 with position from satellite match and noise proportional to reprojection error × GSD.
+4. iSAM2.update() triggers backward correction — frames 0-4 and 5-10 both adjust.
+5. All positions in local ENU coordinates, converted to WGS84 for output.
+
+**Validation result**: Consistent. PriorFactorPose2 correctly constrains Pose2 variables. No GPSFactor API mismatch.
+
+## Validation Scenario 2: Segment start with unknown heading (rotation handling)
+
+**Scenario**: After a sharp turn, new segment starts. First image has unknown heading.
+
+**Expected with Draft03 fixes**:
+1. VO triple check fails → segment break.
+2. New segment starts. No heading available.
+3. For satellite coarse retrieval: DINOv2-S processes unrotated image → top-5 tiles.
+4. For fine matching: try SuperPoint+LightGlue at 4 rotations {0°, 90°, 180°, 270°}.
+5. If match found: heading estimated from satellite alignment. Subsequent images rectified.
+6. If no match: try SIFT+LightGlue (rotation-invariant).
+7. If still no match: request user input.
+
+**Validation result**: Consistent. Three-tier fallback addresses the heading bootstrap problem.
+
+## Validation Scenario 3: VRAM budget during satellite matching
+
+**Scenario**: Processing frame with concurrent VO + satellite matching on RTX 2060 (6GB).
+
+**Expected with Draft03 fixes**:
+1. XFeat features already extracted for VO: ~200MB VRAM.
+2. DINOv2 ViT-S/14 loaded for coarse retrieval: ~300MB.
+3. After coarse retrieval, DINOv2 can be unloaded or kept resident.
+4. SuperPoint loaded for fine matching: ~400MB.
+5. LightGlue ONNX loaded: ~500MB.
+6. Peak if all loaded: ~1.4GB.
+7. ONNX Runtime workspace: ~300MB.
+8. Total peak: ~1.7GB — well within 6GB.
+9. faiss runs on CPU — no VRAM impact.
+
+**Validation result**: Consistent. VRAM budget is comfortable even without model unloading.
+
+## Validation Scenario 4: Extended satellite failure (50+ frames)
+
+**Scenario**: Flying over area with outdated/changed satellite imagery. Satellite matching fails for 80 consecutive frames (~8km).
+
+**Expected with Draft03 fixes**:
+1. Frames 1-10: normal VO, satellite matching fails. Cumulative drift increases.
+2. Frame ~10 (1km drift): warning SSE event emitted. Satellite search radius expanded.
+3. Frame ~20 (2km drift): user_input_needed SSE event. If user provides GPS → anchor + backward correction.
+4. If user doesn't respond within timeout: continue with LOW confidence.
+5. Frame ~50 (5km drift): positions marked as very low confidence.
+6. Confidence score per position decays exponentially from last anchor.
+7. If satellite finally matches at frame 80: massive backward correction. Refined events emitted.
+
+**Validation result**: Consistent. Explicit drift thresholds are more predictable than the custom GTSAM factor approach.
+
+## Validation Scenario 5: Google Maps session token management
+
+**Scenario**: Processing a 3000-image flight. Need ~2000 satellite tiles.
+
+**Expected with Draft03 fixes**:
+1. On job start: create Google Maps session with POST /v1/createSession (returns session token).
+2. Use session token in all tile requests for this session.
+3. Daily limit: 15,000 tiles → sufficient for single flight.
+4. Monthly limit: 100,000 → ~50 flights.
+5. At 80% daily limit (12,000): switch to Mapbox.
+6. Mapbox: 200,000/month → additional ~100 flights capacity.
+
+**Validation result**: Consistent. Session management addressed correctly.
+
+## Review Checklist
+- [x] Draft conclusions consistent with fact cards
+- [x] No important dimensions missed
+- [x] No over-extrapolation
+- [x] Conclusions actionable/verifiable
+- [x] GPSFactor API mismatch verified against GTSAM docs
+- [x] VRAM budget calculated with specific model variants
+- [x] Rotation handling addresses segment start edge case
+- [x] Drift management has concrete thresholds
+
+## Counterexamples
+- **Very low-texture terrain** (uniform sand/snow): XFeat VO might fail even on consecutive frames. Mitigation: track texture score per image, warn when low.
+- **Satellite imagery completely missing for region**: Both Google and Mapbox might have no data. Mitigation: user-provided tiles are highest priority.
+- **Multiple concurrent GPU processes**: Another process using the GPU could reduce available VRAM. Mitigation: document exclusive GPU access requirement.
+
+## Conclusions Requiring No Revision
+All conclusions validated. Key improvements are well-supported:
+1. Correct GTSAM factor types (PriorFactorPose2 instead of GPSFactor)
+2. DINOv2 ViT-S/14 for VRAM efficiency
+3. Three-tier rotation handling
+4. Explicit drift thresholds in Segment Manager
+5. asyncio.Queue-based SSE publisher
+6. CPU-based faiss
+7. Session token management for Google Maps
@@ -0,0 +1,80 @@
+# Question Decomposition — Solution Assessment (Mode B)
+
+## Original Question
+Assess the existing solution draft (solution_draft01.md) for weak points, security vulnerabilities, and performance bottlenecks, then produce a revised solution draft.
+
+## Active Mode
+Mode B: Solution Assessment — `solution_draft01.md` exists and is the highest-numbered draft.
+
+## Question Type Classification
+- **Primary**: Problem Diagnosis — identify weak points, vulnerabilities, bottlenecks in existing solution
+- **Secondary**: Decision Support — evaluate alternatives for identified issues
+
+## Research Subject Boundary Definition
+
+| Dimension | Boundary |
+|-----------|----------|
+| **Domain** | GPS-denied UAV visual navigation, aerial geo-referencing |
+| **Geography** | Eastern/southern Ukraine (left of Dnipro River) — steppe terrain, potential conflict-related satellite imagery degradation |
+| **Hardware** | Desktop/laptop with NVIDIA RTX 2060+, 16GB RAM, 6GB VRAM |
+| **Software** | Python ecosystem, GPU-accelerated CV/ML |
+| **Timeframe** | Current state-of-the-art (2024-2026), production-ready tools |
+| **Scale** | 500-3000 images per flight, up to 6252×4168 resolution |
+
+## Problem Context Summary
+- UAV aerial photos taken consecutively ~100m apart, camera pointing down (not autostabilized)
+- Only starting GPS known — must determine GPS for all subsequent images
+- Must handle: sharp turns, outlier photos (up to 350m gap), disconnected route segments
+- Processing <5s/image, real-time SSE streaming, REST API service
+- No IMU data available
+
+## Decomposed Sub-Questions
+
+### A: Cross-View Matching Viability
+"Is SuperPoint+LightGlue with perspective warping reliable for UAV-to-satellite cross-view matching, or are there specialized cross-view methods that would perform better?"
+
+### B: Homography-Based VO Robustness
+"Is homography-based VO (flat terrain assumption) robust enough for non-stabilized camera with potential roll/pitch variations and non-flat objects?"
+
+### C: Satellite Imagery Reliability
+"What are the risks of relying solely on Google Maps satellite imagery for eastern Ukraine, and what fallback strategies exist?"
+
+### D: Processing Time Feasibility
+"Are the processing time estimates (<5s per image) realistic on RTX 2060 with SuperPoint+LightGlue+satellite matching pipeline?"
+
+### E: Optimizer Specification
+"Is the sliding window optimizer well-specified, and are there more proven alternatives like factor graph optimization?"
+
+### F: Camera Rotation Handling
+"How should the system handle arbitrary image rotation from non-stabilized camera mount?"
+
+### G: Security Assessment
+"What are the security vulnerabilities in the REST API + SSE architecture with image processing pipeline?"
+
+### H: Newer Tools & Libraries
+"Are there newer (2025-2026) tools, models, or approaches that outperform the current selections (SuperPoint, LightGlue, etc.)?"
+
+### I: Segment Management Robustness
+"Is the segment management strategy robust enough for multiple disconnected segments, especially when satellite anchoring fails for a segment?"
+
+### J: Memory & Resource Management
+"Can the pipeline stay within 16GB RAM / 6GB VRAM while processing 3000 images at 6252×4168 resolution?"
+
+---
+
+## Timeliness Sensitivity Assessment
+
+- **Research Topic**: GPS-denied UAV visual navigation using learned feature matching and satellite geo-referencing
+- **Sensitivity Level**: 🟠 High
+- **Rationale**: Computer vision feature matching models (SuperPoint, LightGlue, etc.) are actively evolving with new versions and competitors. However, the core algorithms (homography, VO, optimization) are stable. The tool ecosystem changes frequently.
+- **Source Time Window**: 12 months (2025-2026)
+- **Priority official sources to consult**:
+  1. LightGlue / SuperPoint GitHub repos (releases, issues)
+  2. OpenCV documentation (current version)
+  3. Google Maps Tiles API documentation
+  4. Recent aerial geo-referencing papers (2024-2026)
+- **Key version information to verify**:
+  - LightGlue: current version and ONNX/TensorRT support status
+  - SuperPoint: current version and alternatives
+  - FastAPI: SSE support status
+  - Google Maps Tiles API: pricing, coverage, rate limits
@@ -0,0 +1,201 @@
+# Source Registry — Solution Assessment (Mode B)
+
+## Source #1
+- **Title**: GLEAM: Learning to Match and Explain in Cross-View Geo-Localization
+- **Link**: https://arxiv.org/abs/2509.07450
+- **Tier**: L1
+- **Publication Date**: 2025-09
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: Cross-view geo-localization researchers
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: Framework for cross-view geo-localization with explainable matching across modalities. Demonstrates that specialized cross-view methods outperform generic feature matchers.
+
+## Source #2
+- **Title**: Robust UAV Image Mosaicking Using SIFT and LightGlue (ISPRS 2025)
+- **Link**: https://isprs-archives.copernicus.org/articles/XLVIII-2-W11-2025/169/2025/
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: UAV photogrammetry and aerial image processing
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: SIFT+LightGlue achieves superior spatial consistency and reliability for UAV image mosaicking, including low-texture and high-rotation conditions. SIFT outperforms SuperPoint for rotation-heavy scenarios.
+
+## Source #3
+- **Title**: Precise GPS-Denied UAV Self-Positioning via Context-Enhanced Cross-View Geo-Localization (CEUSP)
+- **Link**: https://arxiv.org/abs/2502.11408 / https://github.com/eksnew/ceusp
+- **Tier**: L1
+- **Publication Date**: 2025-02
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: GPS-denied UAV navigation
+- **Research Boundary Match**: ⚠️ Partial overlap (urban, not steppe)
+- **Summary**: DINOv2-based cross-view matching for UAV self-positioning. State-of-the-art on DenseUAV benchmark. Uses retrieval-based (not feature-matching) approach.
+
+## Source #4
+- **Title**: SatLoc Dataset and Hierarchical Adaptive Fusion Framework
+- **Link**: https://www.mdpi.com/2072-4292/17/17/3048
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: GNSS-denied UAV navigation
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: Three-layer architecture: DINOv2 for absolute geo-localization, XFeat for VO, optical flow for velocity. Adaptive fusion with confidence weighting. <15m absolute error on edge hardware.
+
+## Source #5
+- **Title**: LightGlue ONNX/TensorRT acceleration blog
+- **Link**: https://fabio-sim.github.io/blog/accelerating-lightglue-inference-onnx-runtime-tensorrt/
+- **Tier**: L2
+- **Publication Date**: 2024
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: LightGlue users optimizing inference
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: LightGlue ONNX achieves 2-4x speedup over PyTorch. FP8 quantization (Ada/Hopper GPUs only) adds 6x more. RTX 2060 does NOT support FP8.
+
+## Source #6
+- **Title**: LightGlue-ONNX GitHub repository
+- **Link**: https://github.com/fabio-sim/LightGlue-ONNX
+- **Tier**: L2
+- **Publication Date**: 2024-2025
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: LightGlue deployment engineers
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: ONNX export for LightGlue with FlashAttention-2 support. TopK-trick for ~30% speedup. Pre-exported models available.
+
+## Source #7
+- **Title**: LightGlue GitHub Issue #64 — Rotation sensitivity
+- **Link**: https://github.com/cvg/LightGlue/issues/64
+- **Tier**: L4
+- **Publication Date**: 2023-2024
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: LightGlue users
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: LightGlue (with SuperPoint/DISK) is NOT rotation-invariant. 90° or 180° rotation causes matching failure. Manual rectification needed.
+
+## Source #8
+- **Title**: LightGlue GitHub Issue #13 — No-match handling
+- **Link**: https://github.com/cvg/LightGlue/issues/13
+- **Tier**: L4
+- **Publication Date**: 2023
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: LightGlue users
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: LightGlue lacks explicit training on unmatchable pairs. May produce geometrically meaningless matches instead of rejecting non-overlapping views.
+
+## Source #9
+- **Title**: YFS90/GNSS-Denied-UAV-Geolocalization GitHub
+- **Link**: https://github.com/yfs90/gnss-denied-uav-geolocalization
+- **Tier**: L1
+- **Publication Date**: 2024-2025
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: GPS-denied UAV navigation
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: <7m MAE using terrain-weighted constraint optimization + 2D-3D geo-registration. Uses DEM data. Validated across 20 complex scenarios. Works with publicly available satellite maps.
+
+## Source #10
+- **Title**: Efficient image matching for UAV visual navigation via DALGlue (Scientific Reports 2025)
+- **Link**: https://www.nature.com/articles/s41598-025-21602-5
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: UAV visual navigation
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: 11.8% MMA improvement over LightGlue. Uses dual-tree complex wavelet transform + adaptive spatial feature fusion + linear attention. Designed for UAV dynamic flight.
+
+## Source #11
+- **Title**: XFeat: Accelerated Features for Lightweight Image Matching (CVPR 2024)
+- **Link**: https://arxiv.org/html/2404.19174v1 / https://github.com/verlab/accelerated_features
+- **Tier**: L1
+- **Publication Date**: 2024
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: Real-time feature matching applications
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: 5x faster than SuperPoint. Runs real-time on CPU. Sparse + semi-dense matching. Used by SatLoc-Fusion for VO. 1500+ GitHub stars.
+
+## Source #12
+- **Title**: An Oblique-Robust Absolute Visual Localization Method (IEEE TGRS 2024)
+- **Link**: https://ieeexplore.ieee.org/iel7/36/10354519/10356107.pdf
+- **Tier**: L1
+- **Publication Date**: 2024
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: GPS-denied UAV localization
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: SE(2)-steerable network for rotation-equivariant features. Handles drastic perspective changes, non-perpendicular camera angles. No additional training for new scenes.
+
+## Source #13
+- **Title**: Google Maps Tiles API Usage and Billing
+- **Link**: https://developers.google.com/maps/documentation/tile/usage-and-billing
+- **Tier**: L1
+- **Publication Date**: 2025-2026 (continuously updated)
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: Google Maps API users
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: 100,000 free tile requests/month. Rate limit: 6,000/min, 15,000/day for 2D tiles. $200/month free credit expired Feb 2025. Now pay-as-you-go only.
+
+## Source #14
+- **Title**: GTSAM Python API and Factor Graph examples
+- **Link**: https://github.com/borglab/gtsam / https://pypi.org/project/gtsam-develop/
+- **Tier**: L1
+- **Publication Date**: 2025-2026 (v4.2 stable, v4.3a1 dev)
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: Robot navigation, SLAM
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: Python bindings for factor graph optimization. GPSFactor for absolute position constraints. iSAM2 for incremental optimization. Stable v4.2 for production use.
+
+## Source #15
+- **Title**: Copernicus DEM documentation
+- **Link**: https://documentation.dataspace.copernicus.eu/APIs/SentinelHub/Data/DEM.html
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: DEM data users
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: Free 30m DEM (GLO-30) covering Ukraine. API access via Sentinel Hub Process API. Registration required.
+
+## Source #16
+- **Title**: Homography Decomposition Revisited (IJCV 2025)
+- **Link**: https://link.springer.com/article/10.1007/s11263-025-02680-4
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: Computer vision researchers
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: Existing homography decomposition methods can be unstable in certain configurations. Proposes hybrid framework for improved stability.
+
+## Source #17
+- **Title**: Sliding window factor graph optimization for visual/inertial navigation (Cambridge 2020)
+- **Link**: https://www.cambridge.org/core/services/aop-cambridge-core/content/view/523C7C41D18A8D7C159C59235DF502D0/
+- **Tier**: L1
+- **Publication Date**: 2020
+- **Timeliness Status**: ✅ Currently valid (foundational method)
+- **Target Audience**: Navigation system designers
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: Sliding-window factor graph optimization combines accuracy of graph optimization with efficiency of windowed approach. Superior to separate filtering or full batch optimization.
+
+## Source #18
+- **Title**: SuperPoint feature extraction and matching benchmarks
+- **Link**: https://preview-www.nature.com/articles/s41598-024-59626-y/tables/3
+- **Tier**: L1
+- **Publication Date**: 2024
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: Feature matching benchmarking
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: SuperPoint+LightGlue: ~0.36±0.06s per image pair for extraction+matching on GPU. Competitive accuracy for satellite stereo scenarios.
+
+## Source #19
+- **Title**: DINOv2-Based UAV Visual Self-Localization in Low-Altitude Urban Environments
+- **Link**: https://ui.adsabs.harvard.edu/abs/2025IRAL...10.2080Y/
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: UAV visual localization researchers
+- **Research Boundary Match**: ⚠️ Partial overlap (urban, not steppe)
+- **Summary**: DINOv2-based method achieves 86.27 R@1 on DenseUAV benchmark for cross-view matching. Integrates global-local feature enhancement.
+
+## Source #20
+- **Title**: Mapbox Satellite Tiles and Pricing
+- **Link**: https://docs.mapbox.com/data/tilesets/reference/mapbox-satellite/ / https://mapbox.com/pricing
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: Map tile consumers
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: Mapbox offers satellite tiles up to 0.3m resolution (zoom 16+). 200,000 free vector tile requests/month. Unlimited offline downloads on pay-as-you-go. Multi-provider imagery (Maxar, Landsat, Sentinel).
@@ -0,0 +1,161 @@
+# Fact Cards — Solution Assessment (Mode B)
+
+## Fact #1
+- **Statement**: LightGlue (with SuperPoint/DISK descriptors) is NOT rotation-invariant. Image pairs with 90° or 180° rotation produce very few or zero matches. Manual image rectification is required before matching.
+- **Source**: Source #7 (LightGlue GitHub Issue #64)
+- **Phase**: Assessment
+- **Target Audience**: UAV systems with non-stabilized cameras
+- **Confidence**: ✅ High (confirmed by LightGlue maintainers)
+- **Related Dimension**: Cross-view matching robustness, camera rotation handling
+
+## Fact #2
+- **Statement**: LightGlue lacks explicit training on unmatchable image pairs. When given non-overlapping views (e.g., after sharp turn), it may return semantically correct but geometrically meaningless matches instead of correctly rejecting the pair.
+- **Source**: Source #8 (LightGlue GitHub Issue #13)
+- **Phase**: Assessment
+- **Target Audience**: Systems requiring segment detection (VO failure detection)
+- **Confidence**: ✅ High (confirmed by LightGlue maintainers)
+- **Related Dimension**: Segment management, VO failure detection
+
+## Fact #3
+- **Statement**: SatLoc-Fusion achieves <15m absolute localization error using a three-layer hierarchical approach: DINOv2 for coarse absolute geo-localization, XFeat for high-frequency VO, optical flow for velocity estimation. Runs real-time on 6 TFLOPS edge hardware.
+- **Source**: Source #4 (SatLoc-Fusion, Remote Sensing 2025)
+- **Phase**: Assessment
+- **Target Audience**: GPS-denied UAV systems
+- **Confidence**: ✅ High (peer-reviewed, with dataset)
+- **Related Dimension**: Architecture, localization accuracy, hierarchical matching
+
+## Fact #4
+- **Statement**: XFeat is 5x faster than SuperPoint with comparable accuracy. Runs real-time on CPU. Supports both sparse and semi-dense matching. 1500+ GitHub stars, actively maintained.
+- **Source**: Source #11 (CVPR 2024)
+- **Phase**: Assessment
+- **Target Audience**: Real-time feature extraction
+- **Confidence**: ✅ High (peer-reviewed, CVPR 2024)
+- **Related Dimension**: Processing speed, feature extraction
+
+## Fact #5
+- **Statement**: SIFT+LightGlue achieves superior spatial consistency and reliability for UAV image mosaicking, including in low-texture and high-rotation conditions. SIFT is rotation-invariant unlike SuperPoint.
+- **Source**: Source #2 (ISPRS 2025)
+- **Phase**: Assessment
+- **Target Audience**: UAV image matching
+- **Confidence**: ✅ High (peer-reviewed)
+- **Related Dimension**: Feature extraction, rotation handling
+
+## Fact #6
+- **Statement**: SuperPoint+LightGlue extraction+matching takes ~0.36±0.06s per image pair on GPU (unspecified GPU model). This is for standard resolution images, not 6000+ pixel width.
+- **Source**: Source #18
+- **Phase**: Assessment
+- **Target Audience**: Performance planning
+- **Confidence**: ⚠️ Medium (GPU model not specified, may not be RTX 2060)
+- **Related Dimension**: Processing time
+
+## Fact #7
+- **Statement**: LightGlue ONNX/TensorRT achieves 2-4x speedup over compiled PyTorch. FP8 quantization adds 6x more but requires Ada Lovelace or newer GPUs. RTX 2060 (Turing) does NOT support FP8 — limited to FP16/INT8 acceleration.
+- **Source**: Source #5, #6 (LightGlue-ONNX blog and repo)
+- **Phase**: Assessment
+- **Target Audience**: RTX 2060 deployment
+- **Confidence**: ✅ High (benchmarked by repo maintainer)
+- **Related Dimension**: Processing time, hardware constraints
+
+## Fact #8
+- **Statement**: YFS90 achieves <7m MAE using terrain-weighted constraint optimization + 2D-3D geo-registration with DEM data. Validated across 20 complex scenarios including plains, hilly terrain, urban/rural. Works with publicly available satellite maps and DEM data. Re-localization capability after failures.
+- **Source**: Source #9 (YFS90 GitHub)
+- **Phase**: Assessment
+- **Target Audience**: GPS-denied UAV navigation
+- **Confidence**: ✅ High (peer-reviewed, open source, 69★)
+- **Related Dimension**: Optimization approach, DEM integration, accuracy
+
+## Fact #9
+- **Statement**: Google Maps $200/month free credit expired February 28, 2025. Current free tier is 100,000 tile requests/month. Rate limits: 6,000 requests/min, 15,000 requests/day for 2D tiles.
+- **Source**: Source #13 (Google Maps official docs)
+- **Phase**: Assessment
+- **Target Audience**: Cost planning
+- **Confidence**: ✅ High (official documentation)
+- **Related Dimension**: Cost, satellite imagery access
+
+## Fact #10
+- **Statement**: Google Maps satellite imagery for eastern Ukraine is likely updated only every 3-5+ years due to: conflict zone (lower priority), geopolitical challenges, limited user demand. This may not meet the AC requirement of "less than 2 years old."
+- **Source**: Multiple web sources on Google Maps update frequency
+- **Phase**: Assessment
+- **Target Audience**: Satellite imagery reliability
+- **Confidence**: ⚠️ Medium (general guidelines, not Ukraine-specific confirmation)
+- **Related Dimension**: Satellite imagery reliability
+
+## Fact #11
+- **Statement**: Mapbox Satellite offers imagery up to 0.3m resolution at zoom 16+, sourced from Maxar, Landsat, Sentinel. 200,000 free vector tile requests/month. Unlimited offline downloads on pay-as-you-go. Potentially more diverse and recent imagery for Ukraine than Google Maps alone.
+- **Source**: Source #20 (Mapbox docs)
+- **Phase**: Assessment
+- **Target Audience**: Alternative satellite providers
+- **Confidence**: ✅ High (official documentation)
+- **Related Dimension**: Satellite imagery reliability, cost
+
+## Fact #12
+- **Statement**: Copernicus DEM GLO-30 provides free 30m resolution global elevation data including Ukraine. Accessible via Sentinel Hub API. Can be used for terrain-weighted optimization like YFS90.
+- **Source**: Source #15 (Copernicus docs)
+- **Phase**: Assessment
+- **Target Audience**: DEM integration
+- **Confidence**: ✅ High (official documentation)
+- **Related Dimension**: Position optimizer, terrain constraints
+
+## Fact #13
+- **Statement**: GTSAM v4.2 (stable) provides Python bindings with GPSFactor for absolute position constraints and iSAM2 for incremental optimization. Can model VO constraints, satellite anchor constraints, and drift limits in a unified factor graph.
+- **Source**: Source #14 (GTSAM docs)
+- **Phase**: Assessment
+- **Target Audience**: Optimizer design
+- **Confidence**: ✅ High (widely used in robotics)
+- **Related Dimension**: Position optimizer
+
+## Fact #14
+- **Statement**: DALGlue achieves 11.8% MMA improvement over LightGlue on MegaDepth benchmark. Specifically designed for UAV visual navigation with wavelet transform preprocessing for handling dynamic flight blur.
+- **Source**: Source #10 (Scientific Reports 2025)
+- **Phase**: Assessment
+- **Target Audience**: Feature matching selection
+- **Confidence**: ✅ High (peer-reviewed)
+- **Related Dimension**: Feature matching
+
+## Fact #15
+- **Statement**: The oblique-robust AVL method (IEEE TGRS 2024) uses SE(2)-steerable networks for rotation-equivariant features. Handles drastic perspective changes and non-perpendicular camera angles for UAV-to-satellite matching. No retraining needed for new scenes.
+- **Source**: Source #12 (IEEE TGRS 2024)
+- **Phase**: Assessment
+- **Target Audience**: Cross-view matching
+- **Confidence**: ✅ High (peer-reviewed, IEEE)
+- **Related Dimension**: Cross-view matching, rotation handling
+
+## Fact #16
+- **Statement**: Homography decomposition can be unstable in certain configurations (2025 IJCV study). Non-planar objects (buildings, trees) violate planar assumption. For aerial images, dominant ground plane exists but RANSAC inlier ratio drops with non-planar content.
+- **Source**: Source #16 (IJCV 2025)
+- **Phase**: Assessment
+- **Target Audience**: VO design
+- **Confidence**: ✅ High (peer-reviewed)
+- **Related Dimension**: VO robustness
+
+## Fact #17
+- **Statement**: Sliding-window factor graph optimization combines the accuracy of full graph optimization with the efficiency of windowed processing. Superior to either pure filtering or full batch optimization for real-time navigation.
+- **Source**: Source #17 (Cambridge 2020)
+- **Phase**: Assessment
+- **Target Audience**: Optimizer design
+- **Confidence**: ✅ High (peer-reviewed)
+- **Related Dimension**: Position optimizer
+
+## Fact #18
+- **Statement**: SuperPoint is a fully-convolutional model — GPU memory scales linearly with image resolution. 6252×4168 input would require significant VRAM. Standard practice is to downscale to 1024-2048 long edge for feature extraction.
+- **Source**: Source #18, SuperPoint docs
+- **Phase**: Assessment
+- **Target Audience**: Memory management
+- **Confidence**: ✅ High (architectural fact)
+- **Related Dimension**: Memory management, processing pipeline
+
+## Fact #19
+- **Statement**: For GPS-denied UAV localization, hierarchical coarse-to-fine approaches (image retrieval → local feature matching) are state-of-the-art. Direct local feature matching alone fails when the search area is too large or viewpoint difference is too high.
+- **Source**: Source #3, #4, #12 (CEUSP, SatLoc, Oblique-robust AVL)
+- **Phase**: Assessment
+- **Target Audience**: Architecture design
+- **Confidence**: ✅ High (consensus across multiple papers)
+- **Related Dimension**: Architecture, satellite matching
+
+## Fact #20
+- **Statement**: Google Maps Tiles API daily rate limit of 15,000 requests would be hit when processing a 3000-image flight requiring ~2000 satellite tiles plus expansion tiles. Need to either pre-cache or use the per-minute limit (6,000/min) strategically across multiple days.
+- **Source**: Source #13 (Google Maps docs)
+- **Phase**: Assessment
+- **Target Audience**: System design
+- **Confidence**: ✅ High (official rate limits)
+- **Related Dimension**: Satellite tile management, rate limiting
@@ -0,0 +1,79 @@
+# Comparison Framework — Solution Assessment (Mode B)
+
+## Selected Framework Type
+Problem Diagnosis + Decision Support
+
+## Identified Weak Points and Assessment Dimensions
+
+### Dimension 1: Cross-View Matching Strategy (UAV→Satellite)
+
+| Aspect | Draft01 Approach | Identified Problem | Alternative | Factual Basis |
+|--------|-----------------|-------------------|------------|---------------|
+| Strategy | Direct SuperPoint+LightGlue matching with perspective warping | No coarse localization stage. Fails when VO drift is large. LightGlue not rotation-invariant. | Hierarchical: DINOv2/global retrieval → SuperPoint+LightGlue refinement | Fact #1, #2, #15, #19 |
+| Rotation handling | Not addressed | Non-stabilized camera = rotated images. SuperPoint/LightGlue fail at 90°/180° | Image rectification via VO-estimated heading, or rotation-invariant features (SIFT for fallback) | Fact #1, #5 |
+| Domain gap | Perspective warping only | Insufficient for seasonal/illumination/resolution differences | Multi-scale matching, DINOv2 for semantic retrieval, warping + matched features | Fact #3, #15 |
+
+### Dimension 2: Feature Extraction & Matching
+
+| Aspect | Draft01 Approach | Identified Problem | Alternative | Factual Basis |
+|--------|-----------------|-------------------|------------|---------------|
+| VO features | SuperPoint (~80ms) | Adequate but not optimized for speed | XFeat (5x faster, CPU-capable) for VO; keep SuperPoint for satellite matching | Fact #4 |
+| Matching | LightGlue | Good baseline. DALGlue 11.8% better MMA. | LightGlue with ONNX optimization as primary. DALGlue for evaluation. | Fact #7, #14 |
+| Non-match detection | Not addressed | LightGlue returns false matches on non-overlapping pairs | Inlier ratio + match count threshold + geometric consistency check | Fact #2 |
+
+### Dimension 3: Visual Odometry Robustness
+
+| Aspect | Draft01 Approach | Identified Problem | Alternative | Factual Basis |
+|--------|-----------------|-------------------|------------|---------------|
+| Geometric model | Homography (planar assumption) | Unstable for non-planar objects. Decomposition instability in certain configs. | Homography with RANSAC + high inlier ratio requirement. Essential matrix as fallback. | Fact #16 |
+| Scale estimation | GSD from altitude | Valid if altitude is constant. Terrain elevation changes not accounted for. | Integrate Copernicus DEM for terrain-corrected GSD | Fact #12 |
+| Camera rotation | Not addressed | Non-stabilized camera introduces roll/pitch | Estimate rotation from VO, apply rectification before satellite matching | Fact #1, #5 |
+
+### Dimension 4: Position Optimizer
+
+| Aspect | Draft01 Approach | Identified Problem | Alternative | Factual Basis |
+|--------|-----------------|-------------------|------------|---------------|
+| Algorithm | scipy.optimize sliding window | Generic optimizer, no proper uncertainty modeling, no factor types | GTSAM factor graph with iSAM2 incremental optimization | Fact #13, #17 |
+| Terrain constraints | Not used | YFS90 achieves <7m with terrain weighting | Integrate DEM-based terrain constraints via Copernicus DEM | Fact #8, #12 |
+| Drift modeling | Max 100m between anchors | Single hard constraint, no probabilistic modeling | Per-VO-step uncertainty based on inlier ratio, propagated through factor graph | Fact #17 |
+
+### Dimension 5: Satellite Imagery Reliability
+
+| Aspect | Draft01 Approach | Identified Problem | Alternative | Factual Basis |
+|--------|-----------------|-------------------|------------|---------------|
+| Provider | Google Maps only | Eastern Ukraine: 3-5 year update cycle. $200 credit expired. 15K/day rate limit. | Multi-provider: Google Maps primary + Mapbox fallback + pre-cached tiles | Fact #9, #10, #11, #20 |
+| Freshness | Assumed adequate | May not meet AC "< 2 years old" for conflict zone | Provider selection per-area. User can provide custom imagery. | Fact #10 |
+| Rate limiting | Not addressed | 15,000/day cap could block large flights | Progressive download with request budgeting. Pre-cache for known areas. | Fact #20 |
+
+### Dimension 6: Processing Time Budget
+
+| Aspect | Draft01 Approach | Identified Problem | Alternative | Factual Basis |
+|--------|-----------------|-------------------|------------|---------------|
+| Target | <5s (claim <2s) | Per-frame pipeline: VO match + satellite match + optimization. Total could exceed budget. | XFeat for VO (~20ms). LightGlue ONNX for satellite (~100ms). Async satellite matching. | Fact #4, #6, #7 |
+| Image downscaling | Not specified | 6252×4168 cannot be processed at full resolution | Downscale to 1600 long edge for features. Keep full resolution for GSD calculation. | Fact #18 |
+| Parallelism | Not specified | Sequential pipeline wastes GPU idle time | Async: extract features while satellite tile downloads. Pipeline overlap. | — |
+
+### Dimension 7: Memory Management
+
+| Aspect | Draft01 Approach | Identified Problem | Alternative | Factual Basis |
+|--------|-----------------|-------------------|------------|---------------|
+| Image loading | Not specified | 6252×4168 × 3ch = 78MB per raw image. 3000 images = 234GB. | Stream images one at a time. Keep only current + previous features in memory. | Fact #18 |
+| VRAM budget | Not specified | SuperPoint on full resolution could exceed 6GB VRAM | Downscale images. Batch size 1. Clear GPU cache between frames. | Fact #18 |
+| Feature storage | Not specified | 3000 images × features = significant RAM | Store only features needed for sliding window. Disk-backed for older frames. | — |
+
+### Dimension 8: Security
+
+| Aspect | Draft01 Approach | Identified Problem | Alternative | Factual Basis |
+|--------|-----------------|-------------------|------------|---------------|
+| Authentication | API key mentioned | No implementation details. API key in query params = insecure. | JWT tokens for session auth. Short-lived tokens for SSE connections. | SSE security research |
+| Path traversal | Mentioned in testing | image_folder parameter could be exploited | Whitelist base directories. Validate path doesn't escape allowed root. | — |
+| DoS protection | Not addressed | Large image uploads, SSE connection exhaustion | Max file size limits. Connection pool limits. Request rate limiting. | — |
+| API key storage | env var mentioned | Adequate baseline | .env file + secrets manager in production. Never log API keys. | — |
+
+### Dimension 9: Segment Management
+
+| Aspect | Draft01 Approach | Identified Problem | Alternative | Factual Basis |
+|--------|-----------------|-------------------|------------|---------------|
+| Re-connection | Via satellite anchoring only | If satellite matching fails, segment stays floating | Attempt cross-segment matching when new anchors arrive. DEM-based constraint stitching. | Fact #8 |
+| Multi-segment handling | Described conceptually | No detail on how >2 segments are managed | Explicit segment graph with pending connections. Priority queue for unresolved segments. | — |
+| User input fallback | POST /jobs/{id}/anchor | Good design. Needs timeout/escalation for when user doesn't respond. | Add configurable timeout before continuing with VO-only estimate. | — |
@@ -0,0 +1,145 @@
+# Reasoning Chain — Solution Assessment (Mode B)
+
+## Dimension 1: Cross-View Matching Strategy
+
+### Fact Confirmation
+According to Fact #1, LightGlue is not rotation-invariant and fails on rotated images. According to Fact #2, it returns false matches on non-overlapping pairs. According to Fact #19, state-of-the-art GPS-denied localization uses hierarchical coarse-to-fine approaches. SatLoc-Fusion (Fact #3) achieves <15m with DINOv2 + XFeat + optical flow.
+
+### Reference Comparison
+Draft01 uses direct SuperPoint+LightGlue matching with perspective warping. This is a single-stage approach — it assumes the VO-estimated position is close enough to fetch the right satellite tile, then matches directly. But: (a) when VO drift accumulates between satellite anchors, the estimated position may be wrong enough to fetch the wrong tile; (b) the domain gap between UAV oblique images and satellite nadir is significant; (c) rotation from non-stabilized camera is not handled.
+
+State-of-the-art approaches add a coarse localization stage (DINOv2 image retrieval over a wider area) before fine matching. This makes satellite matching robust to larger VO drift.
+
+### Conclusion
+**Replace single-stage with two-stage satellite matching**: (1) DINOv2-based coarse retrieval over a search area (e.g., 500m radius around VO estimate) to find the best-matching satellite tile, (2) SuperPoint+LightGlue for precise alignment on the selected tile. Add image rotation normalization before matching. This is the most critical improvement.
+
+### Confidence
+✅ High — multiple independent sources confirm hierarchical approach superiority.
+
+---
+
+## Dimension 2: Feature Extraction & Matching
+
+### Fact Confirmation
+According to Fact #4, XFeat is 5x faster than SuperPoint with comparable accuracy and is used in SatLoc-Fusion for real-time VO. According to Fact #5, SIFT+LightGlue is more robust for high-rotation conditions. According to Fact #14, DALGlue improves LightGlue MMA by 11.8% for UAV scenarios.
+
+### Reference Comparison
+Draft01 uses SuperPoint for all feature extraction (both VO and satellite matching). This is simpler (unified pipeline) but suboptimal: VO needs speed (processed every frame), while satellite matching needs accuracy (processed periodically).
+
+### Conclusion
+**Dual-extractor strategy**: XFeat for VO (fast, adequate accuracy for frame-to-frame), SuperPoint for satellite matching (higher accuracy needed for cross-view). LightGlue with ONNX/TensorRT optimization as matcher. SIFT as fallback for rotation-heavy scenarios. DALGlue is promising but too new for production — monitor.
+
+### Confidence
+✅ High — XFeat benchmarks are from CVPR 2024, well-established.
+
+---
+
+## Dimension 3: Visual Odometry Robustness
+
+### Fact Confirmation
+According to Fact #16, homography decomposition can be unstable and non-planar objects degrade results. According to Fact #12, Copernicus DEM provides free 30m elevation data for terrain-corrected GSD.
+
+### Reference Comparison
+Draft01's homography-based VO is valid for flat terrain but doesn't account for: (a) terrain elevation changes affecting GSD calculation, (b) non-planar objects in the scene, (c) camera roll/pitch from non-stabilized mount. The terrain in eastern Ukraine is mostly steppe but has settlements, forests, and infrastructure.
+
+### Conclusion
+**Keep homography VO as primary** (valid for dominant ground plane), but: (1) add RANSAC inlier ratio check — if below threshold, fall back to essential matrix estimation; (2) integrate Copernicus DEM for terrain-corrected altitude in GSD calculation; (3) estimate and track camera rotation (roll/pitch/yaw) from consecutive VO estimates and use it for image rectification before satellite matching.
+
+### Confidence
+✅ High — homography with RANSAC and fallback is well-established.
+
+---
+
+## Dimension 4: Position Optimizer
+
+### Fact Confirmation
+According to Fact #13, GTSAM provides Python bindings with GPSFactor and iSAM2 incremental optimization. According to Fact #17, sliding-window factor graph optimization is superior to either pure filtering or full batch optimization. According to Fact #8, YFS90 achieves <7m MAE with terrain-weighted constraints + DEM.
+
+### Reference Comparison
+Draft01 proposes scipy.optimize with a custom sliding window. While functional, this is reinventing the wheel — GTSAM's iSAM2 already implements incremental smoothing with proper uncertainty propagation. GTSAM's factor graph naturally supports: BetweenFactor for VO constraints (with uncertainty), GPSFactor for satellite anchors, custom factors for terrain constraints, drift limit constraints.
+
+### Conclusion
+**Replace scipy.optimize with GTSAM iSAM2 factor graph**. Use BetweenFactor for VO relative motion, GPSFactor for satellite anchors (with uncertainty based on match quality), and a custom terrain factor using Copernicus DEM. This provides: proper uncertainty propagation, incremental updates (fits SSE streaming), backwards smoothing when new anchors arrive.
+
+### Confidence
+✅ High — GTSAM is production-proven, stable v4.2 available via pip.
+
+---
+
+## Dimension 5: Satellite Imagery Reliability
+
+### Fact Confirmation
+According to Fact #9, Google Maps $200/month free credit expired Feb 2025. Current free tier is 100K tiles/month. According to Fact #10, eastern Ukraine imagery may be 3-5+ years old. According to Fact #20, 15,000/day rate limit could be hit on large flights. According to Fact #11, Mapbox offers alternative satellite tiles at comparable resolution.
+
+### Reference Comparison
+Draft01 relies solely on Google Maps. Single-provider dependency creates multiple risk points: outdated imagery, rate limits, cost, API changes.
+
+### Conclusion
+**Multi-provider satellite tile manager**: Google Maps as primary, Mapbox as secondary, user-provided tiles as override. Implement: provider fallback when matching confidence is low, request budgeting to stay within rate limits, tile freshness metadata logging, pre-caching mode for known operational areas.
+
+### Confidence
+✅ High — multi-provider is standard practice for production systems.
+
+---
+
+## Dimension 6: Processing Time Budget
+
+### Fact Confirmation
+According to Fact #6, SuperPoint+LightGlue takes ~0.36s per pair on GPU. According to Fact #7, ONNX optimization adds 2-4x speedup (on RTX 2060, limited to FP16). According to Fact #4, XFeat is 5x faster than SuperPoint for VO.
+
+### Reference Comparison
+Draft01's per-frame pipeline: (1) feature extraction, (2) VO matching, (3) satellite tile fetch, (4) satellite matching, (5) optimization, (6) SSE emit. Total estimated without optimization: ~1-2s for VO + ~0.5-1s for satellite + overhead = 2-4s. With ONNX optimization for matching and XFeat for VO, this drops to ~0.5-1.5s.
+
+### Conclusion
+**Budget is achievable with optimizations**: XFeat for VO (~20ms extraction + ~50ms matching), LightGlue ONNX for satellite (~100ms extraction + ~100ms matching), async satellite tile download (overlapped with VO), GTSAM incremental update (~10ms). Total: ~0.5-1s per frame. Satellite matching can be async — not every frame needs satellite match. Image downscaling to 1600 long edge is essential.
+
+### Confidence
+⚠️ Medium — depends on actual RTX 2060 benchmarks, which are extrapolated from general numbers.
+
+---
+
+## Dimension 7: Memory Management
+
+### Fact Confirmation
+According to Fact #18, SuperPoint is fully-convolutional and VRAM scales with resolution. 6252×4168 images would require significant VRAM and RAM.
+
+### Reference Comparison
+Draft01 doesn't specify memory management. With 3000 images at max resolution, naive processing would exceed 16GB RAM.
+
+### Conclusion
+**Strict memory management**: (1) Downscale all images to max 1600 long edge before feature extraction; (2) stream images one at a time — only keep current + previous frame features in GPU memory; (3) store features for sliding window in CPU RAM, older features to disk; (4) limit satellite tile cache to 500MB in RAM, overflow to disk; (5) batch size 1 for all GPU operations; (6) explicit torch.cuda.empty_cache() between frames if VRAM pressure detected.
+
+### Confidence
+✅ High — standard memory management patterns.
+
+---
+
+## Dimension 8: Security
+
+### Fact Confirmation
+JWT tokens are recommended for SSE endpoint security. API keys in query parameters are insecure (persist in logs, browser history).
+
+### Reference Comparison
+Draft01 mentions API key auth but no implementation details. SSE connections need proper authentication and resource limits.
+
+### Conclusion
+**Security improvements**: (1) JWT-based authentication for all endpoints; (2) short-lived tokens for SSE connections; (3) image folder whitelist (not just path traversal prevention — explicit whitelist of allowed base directories); (4) max concurrent SSE connections per client; (5) request rate limiting; (6) max image size validation; (7) all API keys in environment variables, never logged.
+
+### Confidence
+✅ High — standard security practices.
+
+---
+
+## Dimension 9: Segment Management
+
+### Fact Confirmation
+According to Fact #8, YFS90 has re-localization capability after positioning failures. According to Fact #2, LightGlue may return false matches on non-overlapping pairs.
+
+### Reference Comparison
+Draft01's segment management relies on satellite matching to anchor each segment independently. If satellite matching fails, the segment stays "floating." No mechanism for cross-segment matching or delayed resolution.
+
+### Conclusion
+**Enhanced segment management**: (1) Explicit VO failure detection using match count + inlier ratio + geometric consistency (not just match count); (2) when a new segment gets satellite-anchored, attempt to connect to nearby floating segments using satellite-based position proximity; (3) DEM-based constraint: position must be consistent with terrain elevation; (4) configurable timeout for user input request — if no response within N frames, continue with best estimate and flag.
+
+### Confidence
+⚠️ Medium — cross-segment connection is logical but needs careful implementation to avoid false connections.
@@ -0,0 +1,93 @@
+# Validation Log — Solution Assessment (Mode B)
+
+## Validation Scenario 1: Normal flight over steppe with gradual turns
+
+**Scenario**: 1000-image flight over flat agricultural steppe. FullHD resolution. Starting GPS known. Gradual turns every 200 frames. Satellite imagery 2 years old.
+
+**Expected with Draft02 improvements**:
+1. XFeat VO processes frames at ~70ms each → well under 5s budget
+2. DINOv2 coarse retrieval finds correct satellite area despite 50-100m VO drift
+3. SuperPoint+LightGlue ONNX refines position to ~10-20m accuracy
+4. GTSAM iSAM2 smooths trajectory, reduces drift between anchors
+5. At gradual turns, VO continues working (overlap >30%)
+6. Processing stays under 1GB VRAM with 1600px downscale
+
+**Actual validation result**: Consistent with expectations. This is the "happy path" — both draft01 and draft02 would work. Draft02 advantage: faster processing, better optimizer.
+
+## Validation Scenario 2: Sharp turn with no overlap
+
+**Scenario**: After 500 normal frames, UAV makes a 90° sharp turn. Next 3 images have zero overlap with previous route. Then normal flight continues.
+
+**Expected with Draft02 improvements**:
+1. VO detects failure: match count drops below threshold → segment break
+2. LightGlue false-match protection: geometric consistency check rejects bad matches
+3. New segment starts. DINOv2 coarse retrieval searches wider area for satellite match
+4. If satellite match succeeds: new segment anchored, connected to previous via shared coordinate frame
+5. If satellite match fails: segment marked floating, user input requested (with timeout)
+6. After turn, if UAV returns near previous route, cross-segment connection attempted
+
+**Draft01 comparison**: Draft01 would also detect VO failure and create new segment, but lacks coarse retrieval → satellite matching depends entirely on VO estimate which may be wrong after turn. Higher risk of satellite match failure.
+
+## Validation Scenario 3: High-resolution images (6252×4168)
+
+**Scenario**: 500 images at full 6252×4168 resolution. RTX 2060 (6GB VRAM).
+
+**Expected with Draft02 improvements**:
+1. Images downscaled to 1600×1066 for feature extraction
+2. Full resolution preserved for GSD calculation only
+3. Per-frame VRAM: ~1.5GB for XFeat/SuperPoint + LightGlue
+4. RAM per frame: ~78MB raw + ~5MB features → manageable with streaming
+5. Total peak RAM: sliding window (50 frames × 5MB features) + satellite cache (500MB) + overhead ≈ 1.5GB pipeline
+6. Well within 16GB RAM budget
+
+**Actual validation result**: Consistent. Downscaling strategy is essential and was missing from draft01.
+
+## Validation Scenario 4: Outdated satellite imagery
+
+**Scenario**: Flight over area where Google Maps imagery is 4 years old. Significant changes: new buildings, removed forests, changed roads.
+
+**Expected with Draft02 improvements**:
+1. DINOv2 coarse retrieval: partial success (terrain structure still recognizable)
+2. SuperPoint+LightGlue fine matching: lower match count on changed areas
+3. Confidence score drops for affected frames → flagged in output
+4. Multi-provider fallback: try Mapbox tiles if Google matches are poor
+5. System falls back to VO-only for sections with no good satellite match
+6. User can provide custom satellite imagery for specific areas
+
+**Draft01 comparison**: Draft01 would also fail on changed areas but has no alternative provider and no coarse retrieval to help.
+
+## Validation Scenario 5: 3000-image flight hitting API rate limits
+
+**Scenario**: First flight in a new area. No cached tiles. 3000 images need ~2000 satellite tiles.
+
+**Expected with Draft02 improvements**:
+1. Initial download: 300 tiles around starting GPS (within rate limits)
+2. Progressive download as route extends: 5-20 tiles per frame
+3. Daily limit (15,000): sufficient for tiles but tight if multiple flights
+4. Request budgeting: prioritize tiles around current position, defer expansion
+5. Per-minute limit (6,000): no issue
+6. Monthly limit (100,000): covers ~50 flights at 2000 tiles each
+7. Mapbox fallback if Google budget exhausted
+
+**Draft01 comparison**: Draft01 assumed $200 free credit (expired). Rate limit analysis was incorrect.
+
+## Review Checklist
+- [x] Draft conclusions consistent with fact cards
+- [x] No important dimensions missed
+- [x] No over-extrapolation
+- [x] Conclusions actionable/verifiable
+- [x] All scenarios plausible for the operational context
+
+## Counterexamples
+- **Night flight**: Not addressed (out of scope — restriction says "mostly sunny weather")
+- **Very low altitude (<100m)**: Satellite matching would have poor GSD match — not addressed but within restrictions (altitude ≤1km)
+- **Urban area with tall buildings**: Homography VO degradation — mitigated by essential matrix fallback but not fully addressed
+
+## Conclusions Requiring No Revision
+All conclusions validated against scenarios. Key improvements are well-supported:
+1. Hierarchical satellite matching (coarse + fine)
+2. GTSAM factor graph optimization
+3. Multi-provider satellite tiles
+4. XFeat for VO speed
+5. Image downscaling for memory
+6. Proper security (JWT, rate limiting)
@@ -0,0 +1,76 @@
+# Acceptance Criteria Assessment
+
+## System Parameters (Calculated)
+
+| Parameter | Value |
+|-----------|-------|
+| GSD (at 400m) | 6.01 cm/pixel |
+| Ground footprint | 376m × 250m |
+| Consecutive overlap | 60-73% (at 100m intervals) |
+| Pixels per 50m | ~832 pixels |
+| Pixels per 20m | ~333 pixels |
+
+## Acceptance Criteria
+
+| Criterion | Our Values | Researched Values | Cost/Timeline Impact | Status |
+|-----------|-----------|-------------------|---------------------|--------|
+| GPS accuracy: 80% within 50m | 50m error for 80% of photos | NaviLoc: 19.5m MLE at 50-150m alt. Mateos-Ramirez: 143m mean at >1000m alt (with IMU). At 400m with 26MP + satellite correction, 50m for 80% is achievable with VO+SIM. No IMU adds ~30-50% error overhead. | Medium cost — needs robust satellite matching pipeline. ~3-4 weeks for core pipeline. | **Achievable** — keep as-is |
+| GPS accuracy: 60% within 20m | 20m error for 60% of photos | NaviLoc: 19.5m MLE at lower altitude (50-150m). At 400m, larger viewpoint gap increases error. Cross-view matching MA@20m improving +10% yearly. Needs high-quality satellite imagery and robust matching. | Higher cost — requires higher-quality satellite imagery (0.3-0.5m resolution). Additional 1-2 weeks for refinement. | **Challenging but achievable** — consider relaxing to 30m initially, tighten with iteration |
+| Handle 350m outlier photos | Tolerate up to 350m jump between consecutive photos | Standard VO systems detect outliers via feature matching failure. 350m at GSD 6cm = ~5833 pixels. Satellite re-localization can handle this if area is textured. | Low additional cost — outlier detection is standard in VO pipelines. | **Achievable** — keep as-is |
+| Sharp turns: <5% overlap, <200m drift, <70° angle | System continues working during sharp turns | <5% overlap means consecutive feature matching will fail. Must fall back to satellite matching for absolute position. At 400m altitude with 376m footprint, 200m drift means partial overlap with satellite. 70° rotation is large but manageable with rotation-invariant matchers (AKAZE, SuperPoint). | High complexity — requires multi-strategy architecture (VO primary, satellite fallback). +2-3 weeks. | **Achievable with architectural investment** — keep as-is |
+| Route disconnection & reconnection | Handle multiple disconnected route segments | Each segment needs independent satellite geo-referencing. Segments are stitched via common satellite reference frame. Similar to loop closure in SLAM but via external reference. | High complexity — core architectural challenge. +2-3 weeks for segment management. | **Achievable** — this should be a core design principle, not an edge case |
+| User input fallback (20% of route) | User provides GPS when system cannot determine | Simple UI interaction — user clicks approximate position on map. Becomes new anchor point. | Low cost — straightforward feature. | **Achievable** — keep as-is |
+| Processing speed: <5s per image | 5 seconds maximum per image | SuperPoint: ~50-100ms. LightGlue: ~20-50ms. Satellite crop+match: ~200-500ms. Full pipeline: ~500ms-2s on RTX 2060. NaviLoc runs 9 FPS on Raspberry Pi 5. ORB-SLAM3 with GPU: 30 FPS on Jetson TX2. | Low risk — well within budget on RTX 2060+. | **Easily achievable** — could target <2s. Keep 5s as safety margin |
+| Real-time streaming via SSE | Results appear immediately, refinement sent later | Standard architecture pattern. Process-and-stream is well-supported. | Low cost — standard web engineering. | **Achievable** — keep as-is |
+| Image Registration Rate > 95% | >95% of images successfully registered | ITU thesis: 93% SIM matching. With 60-73% consecutive overlap and deep learning features, >95% for VO between consecutive frames is achievable. The 5% tolerance covers sharp turns. | Medium cost — depends on feature matcher quality and satellite image quality. | **Achievable** — but interpret as "95% for normal consecutive frames". Sharp turn frames counted separately. |
+| MRE < 1.0 pixels | Mean Reprojection Error below 1 pixel | Sub-pixel accuracy is standard for SuperPoint/LightGlue. SVO achieves sub-pixel via direct methods. Typical range: 0.3-0.8 pixels. | No additional cost — inherent to modern matchers. | **Easily achievable** — keep as-is |
+| REST API + SSE background service | Always-running service, start on request, stream results | Standard Python (FastAPI) or .NET architecture. | Low cost — standard engineering. ~1 week for API layer. | **Achievable** — keep as-is |
+
+## Restrictions Assessment
+
+| Restriction | Our Values | Researched Values | Cost/Timeline Impact | Status |
+|-------------|-----------|-------------------|---------------------|--------|
+| No IMU data | No heading, no pitch/roll correction | **CRITICAL restriction.** Most published systems use IMU for heading and as fallback. Without IMU: (1) heading must be derived from consecutive frame matching or satellite matching, (2) no pitch/roll correction — rely on robust feature matchers, (3) scale from known altitude only. Adds ~30-50% error vs IMU-equipped systems. | High impact — requires visual heading estimation. All VO literature assumes at least heading from IMU. +2-3 weeks R&D for pure visual heading. | **Realistic but significantly harder.** Consider: can barometer data be available? |
+| Camera not auto-stabilized | Images have varying pitch/roll | At 400m with fixed-wing, typical roll ±15°, pitch ±10°. Causes trapezoidal distortion in images. Robust matchers (SuperPoint, LightGlue) handle moderate viewpoint changes. Homography estimation between frames compensates. | Medium impact — modern matchers handle this. Pre-rectification using estimated attitude could help. | **Realistic** — keep as-is. Mitigated by robust matchers. |
+| Google Maps only (cost-dependent) | Currently limited to Google Maps | Google Maps in eastern Ukraine may have 2-5 year old imagery. Conflict damage makes old imagery unreliable. **Risk: satellite-UAV matching may fail in areas with significant ground changes.** Alternatives: Mapbox (Maxar Vivid, sub-meter), Bing Maps (0.3-1m), Maxar SecureWatch (30cm, enterprise pricing). | High risk — may need multiple providers. Google: $200/month free credit. Mapbox: free tier for 100K requests. Maxar: enterprise pricing. | **Tighten** — add fallback provider. Pre-download tile cache for operational area. |
+| Image resolution FullHD to 6252×4168 | Variable resolution across flights | Lower resolution (FullHD=1920×1080) at 400m: GSD ≈ 0.20m/pixel, footprint ~384m × 216m. Significantly worse matching but still functional. Need to handle both extremes. | Medium impact — pipeline must be resolution-adaptive. | **Realistic** — keep. But note: FullHD accuracy will be ~3x worse than 26MP. |
+| Altitude ≤ 1km, terrain height negligible | Flat terrain assumption at known altitude | Simplifies scale estimation. At 400m, terrain variations of ±50m cause ±12.5% scale error. Eastern Ukraine is relatively flat (steppe), so this is reasonable. | Low impact for the operational area. | **Realistic** — keep as-is |
+| Mostly sunny weather | Good lighting conditions assumed | Sunny weather = good texture, consistent illumination. Shadows may cause matching issues but are manageable. | Low impact — favorable condition. | **Realistic** — keep. Add: "system performance degrades in overcast/low-light" |
+| Up to 3000 photos per flight | 500-1500 typical, 3000 maximum | At <5s per image: 3000 photos = ~4 hours max. Memory: 3000 × 26MP ≈ 78GB raw. Need efficient memory management and incremental processing. | Medium impact — requires streaming architecture and careful memory management. | **Realistic** — keep. Memory management is engineering, not research. |
+| Sharp turns with completely different next photo | Route discontinuity is possible | Most VO systems fail at 0% overlap. This is effectively a new "start point" problem. Satellite matching is the only recovery path. | High impact — already addressed in AC. | **Realistic** — this is the defining challenge |
+| Desktop/laptop with RTX 2060+ | Minimum GPU requirement | RTX 2060: 6GB VRAM, 1920 CUDA cores. Sufficient for SuperPoint, LightGlue, satellite matching. RTX 3070: 8GB VRAM, 5888 CUDA cores — significantly faster. | Low risk — hardware is adequate. | **Realistic** — keep as-is |
+
+## Missing Acceptance Criteria (Suggested Additions)
+
+| Criterion | Suggested Value | Rationale |
+|-----------|----------------|-----------|
+| Satellite imagery resolution requirement | ≥ 0.5 m/pixel, ideally 0.3 m/pixel | Matching quality depends heavily on reference imagery resolution. At GSD 6cm, satellite must be at least 0.5m for reliable cross-view matching. |
+| Confidence/uncertainty reporting | Report confidence score per position estimate | User needs to know which positions are reliable (satellite-anchored) vs uncertain (VO-only, accumulating drift). |
+| Output format | WGS84 coordinates in GeoJSON or CSV | Standardize output for downstream integration. |
+| Satellite image freshness requirement | < 2 years old for operational area | Older imagery may not match current ground truth due to conflict damage. |
+| Maximum drift between satellite corrections | < 100m cumulative VO drift before satellite re-anchor | Prevents long uncorrected VO segments from exceeding 50m target. |
+| Memory usage limit | < 16GB RAM, < 6GB VRAM | Ensures compatibility with RTX 2060 systems. |
+
+## Key Findings
+
+1. **The 50m/80% accuracy target is achievable** with a well-designed VO + satellite matching pipeline, even without IMU, given the high camera resolution (6cm GSD) and known altitude. NaviLoc achieves 19.5m at lower altitudes; our 400m altitude adds difficulty but 26MP resolution compensates.
+
+2. **The 20m/60% target is aggressive but possible** with high-quality satellite imagery (≤0.5m resolution). Consider starting with a 30m target and tightening through iteration. Performance heavily depends on satellite image quality and freshness for the operational area.
+
+3. **No IMU is the single biggest technical risk.** All published comparable systems use at least heading from IMU/magnetometer. Visual heading estimation from consecutive frames is feasible but adds noise. This restriction alone could require 2-3 extra weeks of R&D.
+
+4. **Google Maps satellite imagery for eastern Ukraine is a significant risk.** Imagery may be outdated (2-5 years) and may not reflect current ground conditions. A fallback satellite provider is strongly recommended.
+
+5. **Processing speed (<5s) is easily achievable** on RTX 2060+. Modern feature matching pipelines process in <500ms per pair. The pipeline could realistically achieve <2s per image.
+
+6. **Route disconnection handling should be the core architectural principle**, not an edge case. The system should be designed "segments-first" — each segment independently geo-referenced, then stitched.
+
+7. **Missing criterion: confidence reporting.** The user should see which positions are high-confidence (satellite-anchored) vs low-confidence (VO-extrapolated). This is critical for operational use.
+
+## Sources
+- [Source #1] Mateos-Ramirez et al. (2024) — VO + satellite correction for fixed-wing UAV
+- [Source #2] Öztürk (2025) — ORB-SLAM3 + SIM integration thesis
+- [Source #3] NaviLoc (2025) — Trajectory-level visual localization
+- [Source #4] LightGlue GitHub — Feature matching benchmarks
+- [Source #5] DALGlue (2025) — Enhanced feature matching
+- [Source #8-9] Satellite imagery coverage and pricing reports
@@ -0,0 +1,63 @@
+# Question Decomposition — AC & Restrictions Assessment
+
+## Original Question
+How realistic are the acceptance criteria and restrictions for a GPS-denied visual navigation system for fixed-wing UAV imagery?
+
+## Active Mode
+Mode A, Phase 1: AC & Restrictions Assessment
+
+## Question Type
+Knowledge Organization + Decision Support
+
+## Research Subject Boundary Definition
+
+| Dimension | Boundary |
+|-----------|----------|
+| **Platform** | Fixed-wing UAV, airplane type, not multirotor |
+| **Geography** | Eastern/southern Ukraine, left of Dnipro River (conflict zone, ~48.27°N, 37.38°E based on sample data) |
+| **Altitude** | ≤ 1km, sample data at 400m |
+| **Sensor** | Monocular RGB camera, 26MP, no IMU, no LiDAR |
+| **Processing** | Ground-based desktop/laptop with NVIDIA RTX 2060+ GPU |
+| **Time Window** | Current state-of-the-art (2024-2026) |
+
+## Problem Context Summary
+
+The system must determine GPS coordinates of consecutive aerial photo centers using only:
+- Known starting GPS coordinates
+- Known camera parameters (25mm focal, 23.5mm sensor, 6252×4168 resolution)
+- Known flight altitude (≤1km, sample: 400m)
+- Consecutive photos taken within ~100m of each other
+- Satellite imagery (Google Maps) for ground reference
+
+Key constraints: NO IMU data, camera not auto-stabilized, potentially outdated satellite imagery for conflict zone.
+
+**Ground Sample Distance (GSD) at 400m altitude**:
+- GSD = (400 × 23.5) / (25 × 6252) ≈ 0.060 m/pixel (6 cm/pixel)
+- Ground footprint: ~376m × 250m per image
+- Estimated consecutive overlap: 60-73% (depending on camera orientation relative to flight direction)
+
+## Sub-Questions for AC Assessment
+
+1. What GPS accuracy is achievable with VO + satellite matching at 400m altitude with 26MP camera?
+2. How does the absence of IMU affect accuracy and what compensations exist?
+3. What processing speed is achievable per image on RTX 2060+ for the required pipeline?
+4. What image registration rates are achievable with deep learning matchers?
+5. What reprojection errors are typical for modern feature matching?
+6. How do sharp turns and route disconnections affect VO systems?
+7. What satellite imagery quality is available for the operational area?
+8. What domain-specific acceptance criteria might be missing?
+
+## Timeliness Sensitivity Assessment
+
+- **Research Topic**: GPS-denied visual navigation using deep learning feature matching
+- **Sensitivity Level**: 🟠 High
+- **Rationale**: Deep learning feature matchers (SuperPoint, LightGlue, GIM) are evolving rapidly; new methods appear quarterly. Satellite imagery providers update pricing and coverage frequently.
+- **Source Time Window**: 12 months (2024-2026)
+- **Priority official sources to consult**:
+  1. LightGlue GitHub repository (cvg/LightGlue)
+  2. ORB-SLAM3 documentation
+  3. Recent MDPI/IEEE papers on GPS-denied UAV navigation
+- **Key version information to verify**:
+  - LightGlue: Current release and performance benchmarks
+  - SuperPoint: Compatibility and inference speed
+  - ORB-SLAM3: Monocular mode capabilities
@@ -0,0 +1,133 @@
+# Source Registry
+
+## Source #1
+- **Title**: Visual Odometry in GPS-Denied Zones for Fixed-Wing UAV with Reduced Accumulative Error Based on Satellite Imagery
+- **Link**: https://www.mdpi.com/2076-3417/14/16/7420
+- **Tier**: L1
+- **Publication Date**: 2024-08-22
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: Fixed-wing UAV navigation researchers
+- **Research Boundary Match**: ✅ Full match (fixed-wing, high altitude, satellite matching)
+- **Summary**: VO + satellite image correction achieves 142.88m mean error over 17km at >1000m altitude using ORB + AKAZE. Uses IMU for heading and barometer for altitude. Error rate 0.83% of total distance.
+- **Related Sub-question**: 1, 2
+
+## Source #2
+- **Title**: Optimized visual odometry and satellite image matching-based localization for UAVs in GPS-denied environments (ITU Thesis)
+- **Link**: https://polen.itu.edu.tr/items/1fe1e872-7cea-44d8-a8de-339e4587bee6
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: UAV navigation researchers
+- **Research Boundary Match**: ⚠️ Partial overlap (multirotor at 30-100m, but same VO+SIM methodology)
+- **Summary**: ORB-SLAM3 + SuperPoint/SuperGlue/GIM achieves GPS-level accuracy. VO module: ±2m local accuracy. SIM module: 93% matching success rate. Demonstrated on DJI Mavic Air 2 at 30-100m.
+- **Related Sub-question**: 1, 2, 4
+
+## Source #3
+- **Title**: NaviLoc: Trajectory-Level Visual Localization for GNSS-Denied UAV Navigation
+- **Link**: https://www.mdpi.com/2504-446X/10/2/97
+- **Tier**: L1
+- **Publication Date**: 2025-12
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: UAV navigation / VPR researchers
+- **Research Boundary Match**: ⚠️ Partial overlap (50-150m altitude, uses VIO not pure VO)
+- **Summary**: Achieves 19.5m Mean Localization Error at 50-150m altitude. Runs at 9 FPS on Raspberry Pi 5. 16x improvement over AnyLoc-VLAD, 32x over raw VIO drift. Training-free system.
+- **Related Sub-question**: 1, 7
+
+## Source #4
+- **Title**: LightGlue: Local Feature Matching at Light Speed (GitHub + ICCV 2023)
+- **Link**: https://github.com/cvg/LightGlue
+- **Tier**: L1
+- **Publication Date**: 2023 (actively maintained through 2025)
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: Computer vision practitioners
+- **Research Boundary Match**: ✅ Full match (core component)
+- **Summary**: ~20-34ms per image pair on RTX 2080Ti. Adaptive pruning for fast inference. 2-4x speedup with PyTorch compilation.
+- **Related Sub-question**: 3, 4
+
+## Source #5
+- **Title**: Efficient image matching for UAV visual navigation via DALGlue
+- **Link**: https://www.nature.com/articles/s41598-025-21602-5
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: UAV navigation researchers
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: DALGlue achieves 11.8% improvement over LightGlue on matching accuracy. Uses dual-tree complex wavelet preprocessing + linear attention for real-time performance.
+- **Related Sub-question**: 3, 4
+
+## Source #6
+- **Title**: Deep-UAV SLAM: SuperPoint and SuperGlue enhanced SLAM
+- **Link**: https://isprs-archives.copernicus.org/articles/XLVIII-1-W5-2025/177/2025/
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: UAV SLAM researchers
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: Replacing ORB-SLAM3's ORB features with SuperPoint+SuperGlue improved robustness and accuracy in aerial RGB scenarios.
+- **Related Sub-question**: 4, 5
+
+## Source #7
+- **Title**: SCAR: Satellite Imagery-Based Calibration for Aerial Recordings
+- **Link**: https://arxiv.org/html/2602.16349v1
+- **Tier**: L1
+- **Publication Date**: 2026-02
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: Aerial/satellite vision researchers
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: Long-term auto-calibration refinement by aligning aerial images with 2D-3D correspondences from orthophotos and elevation models.
+- **Related Sub-question**: 1, 5
+
+## Source #8
+- **Title**: Google Maps satellite imagery coverage and update frequency
+- **Link**: https://ongeo-intelligence.com/blog/how-often-does-google-maps-update-satellite-images
+- **Tier**: L3
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: GIS practitioners
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: Conflict zones like eastern Ukraine face 2-5+ year update cycles. Imagery may be intentionally limited or blurred.
+- **Related Sub-question**: 7
+
+## Source #9
+- **Title**: Satellite Mapping Services comparison 2025
+- **Link**: https://ts2.tech/en/exploring-the-world-from-above-top-satellite-mapping-services-for-web-mobile-in-2025/
+- **Tier**: L3
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: Developers, GIS practitioners
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: Google: $200/month free credit, sub-meter resolution. Mapbox: Maxar imagery, generous free tier. Maxar SecureWatch: 30cm resolution, enterprise pricing. Planet: daily 3-4m imagery.
+- **Related Sub-question**: 7
+
+## Source #10
+- **Title**: Scale Estimation for Monocular Visual Odometry Using Reliable Camera Height
+- **Link**: https://ieeexplore.ieee.org/document/9945178/
+- **Tier**: L1
+- **Publication Date**: 2022
+- **Timeliness Status**: ✅ Currently valid (fundamental method)
+- **Target Audience**: VO researchers
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: Known camera height/altitude resolves scale ambiguity in monocular VO. Essential for systems without IMU.
+- **Related Sub-question**: 2
+
+## Source #11
+- **Title**: Cross-View Geo-Localization benchmarks (SSPT, MA metrics)
+- **Link**: https://www.mdpi.com/1424-8220/24/12/3719
+- **Tier**: L1
+- **Publication Date**: 2024
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: VPR/geo-localization researchers
+- **Research Boundary Match**: ⚠️ Partial overlap (general cross-view, not UAV-specific)
+- **Summary**: SSPT achieved 84.40% RDS on UL14 dataset. MA improvements: +12% at 3m, +12% at 5m, +10% at 20m thresholds.
+- **Related Sub-question**: 1
+
+## Source #12
+- **Title**: ORB-SLAM3 GPU Acceleration Performance
+- **Link**: https://arxiv.org/html/2509.10757v1
+- **Tier**: L1
+- **Publication Date**: 2025
+- **Timeliness Status**: ✅ Currently valid
+- **Target Audience**: SLAM/VO engineers
+- **Research Boundary Match**: ✅ Full match
+- **Summary**: GPU acceleration achieves 2.8x speedup on desktop systems. 30 FPS achievable on Jetson TX2. Feature extraction up to 3x speedup with CUDA.
+- **Related Sub-question**: 3
@@ -0,0 +1,121 @@
+# Fact Cards
+
+## Fact #1
+- **Statement**: VO + satellite image correction achieves ~142.88m mean error over 17km flight at >1000m altitude using ORB features and AKAZE satellite matching. Error rate: 0.83% of total distance. This system uses IMU for heading and barometer for altitude.
+- **Source**: Source #1 — https://www.mdpi.com/2076-3417/14/16/7420
+- **Phase**: Phase 1
+- **Target Audience**: Fixed-wing UAV at high altitude (>1000m)
+- **Confidence**: ✅ High (peer-reviewed, real-world flight data)
+- **Related Dimension**: GPS accuracy, drift correction
+
+## Fact #2
+- **Statement**: ORB-SLAM3 monocular mode with optimized parameters achieves ±2m local accuracy for visual odometry. Scale ambiguity and drift remain for long flights.
+- **Source**: Source #2 — ITU Thesis
+- **Phase**: Phase 1
+- **Target Audience**: UAV navigation (30-100m altitude, multirotor)
+- **Confidence**: ✅ High (thesis with experimental validation)
+- **Related Dimension**: VO accuracy, scale ambiguity
+
+## Fact #3
+- **Statement**: Combined VO + Satellite Image Matching (SIM) with SuperPoint/SuperGlue/GIM achieves 93% matching success rate and "GPS-level accuracy" at 30-100m altitude.
+- **Source**: Source #2 — ITU Thesis
+- **Phase**: Phase 1
+- **Target Audience**: Low-altitude UAV (30-100m)
+- **Confidence**: ✅ High
+- **Related Dimension**: Registration rate, satellite matching
+
+## Fact #4
+- **Statement**: NaviLoc achieves 19.5m Mean Localization Error at 50-150m altitude, runs at 9 FPS on Raspberry Pi 5. 16x improvement over AnyLoc-VLAD. Training-free system.
+- **Source**: Source #3 — NaviLoc paper
+- **Phase**: Phase 1
+- **Target Audience**: Low-altitude UAV (50-150m) in rural areas
+- **Confidence**: ✅ High (peer-reviewed)
+- **Related Dimension**: GPS accuracy, processing speed
+
+## Fact #5
+- **Statement**: LightGlue inference: ~20-34ms per image pair on RTX 2080Ti for 1024 keypoints. 2-4x speedup possible with PyTorch compilation and TensorRT.
+- **Source**: Source #4 — LightGlue GitHub Issues
+- **Phase**: Phase 1
+- **Target Audience**: All GPU-accelerated vision systems
+- **Confidence**: ✅ High (official repository benchmarks)
+- **Related Dimension**: Processing speed
+
+## Fact #6
+- **Statement**: SuperPoint+SuperGlue replacing ORB features in SLAM improves robustness and accuracy for aerial RGB imagery over classical handcrafted features.
+- **Source**: Source #6 — ISPRS 2025
+- **Phase**: Phase 1
+- **Target Audience**: UAV SLAM researchers
+- **Confidence**: ✅ High (peer-reviewed)
+- **Related Dimension**: Feature matching quality
+
+## Fact #7
+- **Statement**: Eastern Ukraine / conflict zones may have 2-5+ year old satellite imagery on Google Maps. Imagery may be intentionally limited, blurred, or restricted for security reasons.
+- **Source**: Source #8
+- **Phase**: Phase 1
+- **Target Audience**: Ukraine conflict zone operations
+- **Confidence**: ⚠️ Medium (general reporting, not Ukraine-specific verification)
+- **Related Dimension**: Satellite imagery quality
+
+## Fact #8
+- **Statement**: Maxar SecureWatch offers 30cm resolution with ~3M km² new imagery daily. Mapbox uses Maxar's Vivid imagery with sub-meter resolution. Google Maps offers sub-meter detail in urban areas but 1-3m in rural areas.
+- **Source**: Source #9
+- **Phase**: Phase 1
+- **Target Audience**: All satellite imagery users
+- **Confidence**: ✅ High
+- **Related Dimension**: Satellite providers, cost
+
+## Fact #9
+- **Statement**: Known camera height/altitude resolves scale ambiguity in monocular VO. The pixel-to-meter conversion is s = H / f × sensor_pixel_size, enabling metric reconstruction without IMU.
+- **Source**: Source #10
+- **Phase**: Phase 1
+- **Target Audience**: Monocular VO systems
+- **Confidence**: ✅ High (fundamental geometric relationship)
+- **Related Dimension**: No-IMU compensation
+
+## Fact #10
+- **Statement**: Camera heading (yaw) can be estimated from consecutive frame feature matching by decomposing the homography or essential matrix. Pitch/roll can be estimated from horizon detection or vanishing points. Without IMU, these estimates are noisier but functional.
+- **Source**: Multiple vision-based heading estimation papers
+- **Phase**: Phase 1
+- **Target Audience**: Vision-only navigation systems
+- **Confidence**: ⚠️ Medium (well-established but accuracy varies)
+- **Related Dimension**: No-IMU compensation
+
+## Fact #11
+- **Statement**: GSD at 400m with 25mm/23.5mm sensor/6252px = 6.01 cm/pixel. Ground footprint: 376m × 250m. At 100m photo interval, consecutive overlap is 60-73%.
+- **Source**: Calculated from problem data using standard GSD formula
+- **Phase**: Phase 1
+- **Target Audience**: This specific system
+- **Confidence**: ✅ High (deterministic calculation)
+- **Related Dimension**: Image coverage, overlap
+
+## Fact #12
+- **Statement**: GPU-accelerated ORB-SLAM3 achieves 2.8x speedup on desktop systems. 30 FPS possible on Jetson TX2. Feature extraction speedup up to 3x with CUDA-optimized pipelines.
+- **Source**: Source #12
+- **Phase**: Phase 1
+- **Target Audience**: GPU-equipped systems
+- **Confidence**: ✅ High
+- **Related Dimension**: Processing speed
+
+## Fact #13
+- **Statement**: Without IMU, the Mateos-Ramirez paper (Source #1) would lose: (a) yaw angle for rotation compensation, (b) fallback when feature matching fails. Their 142.88m error would likely be significantly higher without IMU heading data.
+- **Source**: Inference from Source #1 methodology
+- **Phase**: Phase 1
+- **Target Audience**: This specific system
+- **Confidence**: ⚠️ Medium (reasoned inference)
+- **Related Dimension**: No-IMU impact
+
+## Fact #14
+- **Statement**: DALGlue achieves 11.8% improvement over LightGlue on matching accuracy while maintaining real-time performance through dual-tree complex wavelet preprocessing and linear attention.
+- **Source**: Source #5
+- **Phase**: Phase 1
+- **Target Audience**: Feature matching systems
+- **Confidence**: ✅ High (peer-reviewed, 2025)
+- **Related Dimension**: Feature matching quality
+
+## Fact #15
+- **Statement**: Cross-view geo-localization benchmarks show MA@20m improving by +10% with latest methods (SSPT). RDS metric at 84.40% indicates reliable spatial positioning.
+- **Source**: Source #11
+- **Phase**: Phase 1
+- **Target Audience**: Cross-view matching researchers
+- **Confidence**: ✅ High
+- **Related Dimension**: Cross-view matching accuracy
@@ -0,0 +1,115 @@
+# Comparison Framework
+
+## Selected Framework Type
+Decision Support (component-by-component solution comparison)
+
+## System Components
+1. Visual Odometry (consecutive frame matching)
+2. Satellite Image Geo-Referencing (cross-view matching)
+3. Heading & Orientation Estimation (without IMU)
+4. Drift Correction & Position Fusion
+5. Segment Management & Route Reconnection
+6. Interactive Point-to-GPS Lookup
+7. Pipeline Orchestration & API
+
+---
+
+## Component 1: Visual Odometry
+
+| Solution | Tools | Advantages | Limitations | Fit |
+|----------|-------|-----------|-------------|-----|
+| ORB-SLAM3 monocular | ORB features, BA, map management | Mature, well-tested, handles loop closure. GPU-accelerated. 30FPS on Jetson TX2. | Scale ambiguity without IMU. Over-engineered for sequential aerial — map building not needed. Heavy dependency. | Medium — too complex for the use case |
+| Homography-based VO with SuperPoint+LightGlue | SuperPoint, LightGlue, OpenCV homography | Ground plane assumption perfect for flat terrain at 400m. Cleanly separates rotation/translation. Known altitude resolves scale directly. Fast. | Assumes planar scene (valid for our case). Fails at sharp turns (but that's expected). | **Best fit** — matches constraints exactly |
+| Optical flow VO | cv2.calcOpticalFlowPyrLK or RAFT | Dense motion field, no feature extraction needed. | Less accurate for large motions. Struggles with texture-sparse areas. No inherent rotation estimation. | Low — not suitable for 100m baselines |
+| Direct method (SVO) | SVO Pro | Sub-pixel precision, fast. | Designed for small baselines and forward cameras. Poor for downward aerial at large baselines. | Low |
+
+**Selected**: Homography-based VO with SuperPoint + LightGlue features
+
+---
+
+## Component 2: Satellite Image Geo-Referencing
+
+| Solution | Tools | Advantages | Limitations | Fit |
+|----------|-------|-----------|-------------|-----|
+| SuperPoint + LightGlue cross-view matching | SuperPoint, LightGlue, perspective warp | Best overall performance on satellite stereo benchmarks. Fast (~50ms matching). Rotation-invariant. Handles viewpoint/scale changes. | Requires perspective warping to reduce viewpoint gap. Needs good satellite image quality. | **Best fit** — proven on satellite imagery |
+| SuperPoint + SuperGlue + GIM | SuperPoint, SuperGlue, GIM | GIM adds generalization for challenging scenes. 93% match rate (ITU thesis). | SuperGlue slower than LightGlue. GIM adds complexity. | Good — slightly better robustness, slower |
+| LoFTR (detector-free) | LoFTR | No keypoint detection step. Works on low-texture. | Slower than detector-based methods. Fixed resolution (coarse). Less accurate than SuperPoint+LightGlue on satellite benchmarks. | Medium — fallback option |
+| DUSt3R/MASt3R | DUSt3R/MASt3R | Handles extreme viewpoints and low overlap. +50% completeness over COLMAP in sparse scenarios. | Very slow. Designed for 3D reconstruction not 2D matching. Unreliable with many images. | Low — only for extreme fallback |
+| Terrain-weighted optimization (YFS90) | Custom pipeline + DEM | <7m MAE without IMU! Drift-free. Handles thermal IR. 20 scenarios validated. | Requires DEM data. More complex implementation. Not open-source matching details. | High — architecture inspiration |
+
+**Selected**: SuperPoint + LightGlue (primary) with perspective warping. GIM as supplementary for difficult matches. YFS90-style terrain-weighted sliding window for position optimization.
+
+---
+
+## Component 3: Heading & Orientation Estimation
+
+| Solution | Tools | Advantages | Limitations | Fit |
+|----------|-------|-----------|-------------|-----|
+| Homography decomposition (consecutive frames) | OpenCV decomposeHomographyMat | Directly gives rotation between frames. Works with ground plane assumption. No extra sensors needed. | Accumulates heading drift over time. Noisy for small motions. Ambiguous decomposition (need to select correct solution). | **Best fit** — primary heading source |
+| Satellite matching absolute orientation | From satellite match homography | Provides absolute heading correction. Eliminates accumulated heading drift. | Only available when satellite match succeeds. Intermittent. | **Best fit** — drift correction for heading |
+| Optical flow direction | Dense flow vectors | Simple to compute. | Very noisy at high altitude. Unreliable for heading. | Low |
+
+**Selected**: Homography decomposition for frame-to-frame heading + satellite matching for periodic absolute heading correction.
+
+---
+
+## Component 4: Drift Correction & Position Fusion
+
+| Solution | Tools | Advantages | Limitations | Fit |
+|----------|-------|-----------|-------------|-----|
+| Kalman filter (EKF/UKF) | filterpy or custom | Well-understood. Handles noisy measurements. Good for fusing VO + satellite. | Assumes Gaussian noise. Linearization issues with EKF. | Good — simple and effective |
+| Sliding window optimization with terrain constraints | Custom optimization, scipy.optimize | YFS90 achieves <7m with this. Directly constrains drift. No loop closure needed. | More complex to implement. Needs tuning. | **Best fit** — proven for this exact problem |
+| Pose graph optimization | g2o, GTSAM | Standard in SLAM. Handles satellite anchors as prior factors. Globally optimal. | Heavy dependency. Over-engineered if segments are short. | Medium — overkill unless routes are very long |
+| Simple anchor reset | Direct correction at satellite match | Simplest. Just replace VO position with satellite position. | Discontinuous trajectory. No smoothing. | Low — too crude |
+
+**Selected**: Sliding window optimization with terrain constraints (inspired by YFS90), with Kalman filter as simpler fallback. Satellite matches as absolute anchor constraints.
+
+---
+
+## Component 5: Segment Management & Route Reconnection
+
+| Solution | Tools | Advantages | Limitations | Fit |
+|----------|-------|-----------|-------------|-----|
+| Segments-first architecture with satellite anchoring | Custom segment manager | Each segment independently geo-referenced. No dependency between disconnected segments. Natural handling of sharp turns. | Needs robust satellite matching per segment. Segments without any satellite match are "floating". | **Best fit** — matches AC requirement for core strategy |
+| Global pose graph with loop closure | g2o/GTSAM | Can connect segments when they revisit same area. | Heavy. Doesn't help if segments don't overlap with each other. | Low — segments may not revisit same areas |
+| Trajectory-level VPR (NaviLoc-style) | VPR + trajectory optimization | Global optimization across trajectory. | Requires pre-computed VPR database. Complex. Designed for continuous trajectory, not disconnected segments. | Low |
+
+**Selected**: Segments-first architecture. Each segment starts from a satellite anchor or user input. Segments connected through shared satellite coordinate frame.
+
+---
+
+## Component 6: Interactive Point-to-GPS Lookup
+
+| Solution | Tools | Advantages | Limitations | Fit |
+|----------|-------|-----------|-------------|-----|
+| Homography projection (image → ground) | Computed homography from satellite match | Already computed during geo-referencing. Accurate for flat terrain. | Only works for images with successful satellite match. | **Best fit** |
+| Camera ray-casting with known altitude | Camera intrinsics + pose estimate | Works for any image with pose estimate. Simpler math. | Accuracy depends on pose estimate quality. | Good — fallback for non-satellite-matched images |
+
+**Selected**: Homography projection (primary) + ray-casting (fallback).
+
+---
+
+## Component 7: Pipeline & API
+
+| Solution | Tools | Advantages | Limitations | Fit |
+|----------|-------|-----------|-------------|-----|
+| Python FastAPI + SSE | FastAPI, EventSourceResponse, asyncio | Native SSE support (since 0.135.0). Async GPU pipeline. Excellent for ML/CV workloads. Rich ecosystem. | Python GIL (mitigated with async/multiprocessing). | **Best fit** — natural for CV/ML pipeline |
+| .NET ASP.NET Core + SSE | ASP.NET Core, SignalR | High performance. Good for enterprise. | Less natural for CV/ML. Python interop needed for PyTorch models. Adds complexity. | Low — unnecessary indirection |
+| Python + gRPC streaming | gRPC | Efficient binary protocol. Bidirectional streaming. | More complex client integration. No browser-native support. | Medium — overkill for this use case |
+
+**Selected**: Python FastAPI with SSE.
+
+---
+
+## Google Maps Tile Resolution at Latitude 48° (Operational Area)
+
+| Zoom Level | Meters/pixel | Tile coverage (256px) | Tiles for 20km² | Download size est. |
+|-----------|-------------|----------------------|-----------------|-------------------|
+| 17 | 0.80 m/px | ~205m × 205m | ~500 tiles | ~20MB |
+| 18 | 0.40 m/px | ~102m × 102m | ~2,000 tiles | ~80MB |
+| 19 | 0.20 m/px | ~51m × 51m | ~8,000 tiles | ~320MB |
+| 20 | 0.10 m/px | ~26m × 26m | ~30,000 tiles | ~1.2GB |
+
+Formula: metersPerPx = 156543.03 × cos(48° × π/180) / 2^zoom ≈ 104,771 / 2^zoom
+
+**Selected**: Zoom 18 (0.40 m/px) as primary matching resolution. Zoom 19 (0.20 m/px) for refinement if available. Meets the ≥0.5 m/pixel AC requirement.
@@ -0,0 +1,146 @@
+# Reasoning Chain
+
+## Dimension 1: GPS Accuracy (50m/80%, 20m/60%)
+
+### Fact Confirmation
+- YFS90 system achieves <7m MAE without IMU (Fact from Source DOAJ/GitHub)
+- NaviLoc achieves 19.5m MLE at 50-150m altitude (Fact #4)
+- Mateos-Ramirez achieves 143m mean error at >1000m altitude with IMU (Fact #1)
+- Our GSD is 6cm/pixel at 400m altitude (Fact #11)
+- ITU thesis achieves GPS-level accuracy with VO+SIM at 30-100m (Fact #3)
+
+### Reference Comparison
+- At 400m altitude, our camera produces much higher resolution imagery than typical systems
+- YFS90 at <7m without IMU is the strongest reference — uses terrain-weighted constraint optimization
+- NaviLoc at 19.5m uses trajectory-level optimization but at lower altitude
+- The combination of VO + satellite matching with sliding window optimization should achieve 10-30m depending on satellite image quality
+
+### Conclusion
+- **50m / 80%**: High confidence achievable. Multiple systems achieve better than this.
+- **20m / 60%**: Achievable with good satellite imagery. YFS90 achieves <7m. Our higher altitude makes cross-view matching harder, but 26MP camera compensates.
+- **10m stretch**: Possible with zoom 19 satellite tiles (0.2m/px) and terrain-weighted optimization.
+
+### Confidence: ✅ High for 50m, ⚠️ Medium for 20m, ❓ Low for 10m
+
+---
+
+## Dimension 2: No-IMU Heading Estimation
+
+### Fact Confirmation
+- Homography decomposition gives rotation between frames for planar scenes (multiple sources)
+- Ground plane assumption is valid for flat terrain (eastern Ukraine steppe)
+- Satellite matching provides absolute orientation correction (Sources #1, #2)
+- YFS90 achieves <7m without requiring IMU (Source #3 DOAJ)
+
+### Reference Comparison
+- Most published systems use IMU for heading — our approach is less common
+- YFS90 proves it's possible without IMU, but uses DEM data for terrain weighting
+- The key insight: satellite matching provides both position AND heading correction, making intermittent heading drift from VO acceptable
+
+### Conclusion
+Heading estimation from homography decomposition between consecutive frames + periodic satellite matching correction is viable. The frame-to-frame heading drift accumulates, but satellite corrections at regular intervals (every 5-20 frames) reset it. The flat terrain of the operational area makes the ground plane assumption reliable.
+
+### Confidence: ⚠️ Medium — novel approach but supported by YFS90 results
+
+---
+
+## Dimension 3: Processing Speed (<5s per image)
+
+### Fact Confirmation
+- LightGlue: ~20-50ms per pair (Fact #5)
+- SuperPoint extraction: ~50-100ms per image
+- GPU-accelerated ORB-SLAM3: 30 FPS (Fact #12)
+- NaviLoc: 9 FPS on Raspberry Pi 5 (Fact #4)
+
+### Pipeline Time Budget Estimate (per image on RTX 2060)
+1. SuperPoint feature extraction: ~80ms
+2. LightGlue VO matching (vs previous frame): ~40ms
+3. Homography estimation + position update: ~5ms
+4. Satellite tile crop (from cache): ~10ms
+5. SuperPoint extraction on satellite crop: ~80ms
+6. LightGlue satellite matching: ~60ms
+7. Position correction + sliding window optimization: ~20ms
+8. Total: ~295ms ≈ 0.3s
+
+### Conclusion
+Processing comfortably fits within 5s budget. Even with additional overhead (satellite tile download, perspective warping, GIM fallback), the pipeline stays under 2s. The 5s budget provides ample margin.
+
+### Confidence: ✅ High
+
+---
+
+## Dimension 4: Sharp Turns & Route Disconnection
+
+### Fact Confirmation
+- At <5% overlap, consecutive feature matching will fail
+- Satellite matching can provide absolute position independently of VO
+- DUSt3R/MASt3R handle extreme low overlap (+50% completeness vs COLMAP)
+- YFS90 handles positioning failures with re-localization
+
+### Reference Comparison
+- Traditional VO systems fail at sharp turns — this is expected and acceptable
+- The segments-first architecture treats each continuous VO chain as a segment
+- Satellite matching re-localizes at the start of each new segment
+- If satellite matching fails too → wider search area → user input
+
+### Conclusion
+The system should not try to match across sharp turns. Instead:
+1. Detect VO failure (low match count / high reprojection error)
+2. Start new segment
+3. Attempt satellite geo-referencing for new segment start
+4. Each segment is independently positioned in the global satellite coordinate frame
+
+This is architecturally simpler and more robust than trying to bridge disconnections.
+
+### Confidence: ✅ High
+
+---
+
+## Dimension 5: Satellite Image Matching Reliability
+
+### Fact Confirmation
+- Google Maps at zoom 18: 0.40 m/px at lat 48° — meets AC requirement
+- Eastern Ukraine imagery may be 2-5 years old (Fact #7)
+- SuperPoint+LightGlue is best performer for satellite matching (Source comparison study)
+- Perspective warping improves cross-view matching significantly
+- 93% match rate achieved in ITU thesis (Fact #3)
+
+### Reference Comparison
+- The main risk is satellite image freshness in conflict zone
+- Natural terrain features (rivers, forests, field boundaries) are relatively stable over years
+- Man-made features (buildings, roads) may change due to conflict
+- Agricultural field patterns change seasonally
+
+### Conclusion
+Satellite matching will work reliably in areas with stable natural features. Performance degrades in:
+1. Areas with significant conflict damage (buildings destroyed)
+2. Areas with seasonal agricultural changes
+3. Areas with very homogeneous texture (large uniform fields)
+
+Mitigation: use multiple scale levels, widen search area, accept lower confidence.
+
+### Confidence: ⚠️ Medium — depends heavily on operational area characteristics
+
+---
+
+## Dimension 6: Architecture Selection
+
+### Fact Confirmation
+- YFS90 architecture (VO + satellite matching + terrain-weighted optimization) achieves <7m
+- ITU thesis architecture (ORB-SLAM3 + SIM) achieves GPS-level accuracy
+- NaviLoc architecture (VPR + trajectory optimization) achieves 19.5m
+
+### Reference Comparison
+- YFS90 is closest to our requirements: no IMU, satellite matching, drift correction
+- Our system adds: segment management, real-time streaming, user fallback
+- We need simpler VO than ORB-SLAM3 (no map building needed)
+- We need faster matching than SuperGlue (LightGlue preferred)
+
+### Conclusion
+Hybrid architecture combining:
+- YFS90-style sliding window optimization for drift correction
+- SuperPoint + LightGlue for both VO and satellite matching (unified feature pipeline)
+- Segments-first architecture for disconnection handling
+- FastAPI + SSE for real-time streaming
+
+### Confidence: ✅ High
@@ -0,0 +1,57 @@
+# Validation Log
+
+## Validation Scenario
+Using the provided sample data: 60 consecutive images from a flight starting at (48.275292, 37.385220) heading generally south-southwest. Camera: 26MP at 400m altitude.
+
+## Expected Behavior Based on Conclusions
+
+### Normal consecutive frames (AD000001-AD000032)
+- VO successfully matches consecutive frames (60-73% overlap)
+- Satellite matching every 5-10 frames provides absolute correction
+- Position error stays within 20-50m corridor around ground truth
+- Heading estimated from homography, corrected by satellite matching
+
+### Apparent maneuver zone (AD000033-AD000048)
+- The coordinates show the UAV making a complex turn around images 33-48
+- Some consecutive pairs may have low overlap → VO quality drops
+- Satellite matching becomes the primary position source
+- New segments may be created if VO fails completely
+- Position confidence drops in this zone
+
+### Return to straight flight (AD000049-AD000060)
+- VO re-establishes strong consecutive matching
+- Satellite matching re-anchors position
+- Accuracy returns to normal levels
+
+## Actual Validation (Calculated)
+
+Distances between consecutive samples in the data:
+- AD000001→002: ~180m (larger than stated 100m — likely exaggeration in problem description)
+- AD000002→003: ~115m
+- Typical gap: 80-180m
+- At 376m footprint width and 250m height, even 180m gap gives 52-73% overlap → sufficient for VO
+
+At the turn zone (images 33-48):
+- AD000041→042: ~230m with direction change → overlap may drop to 30-40%
+- AD000042→043: ~230m with direction change → overlap may drop significantly
+- AD000045→046: ~160m with direction change → may be <20% overlap
+- These transitions are where VO may fail → satellite matching needed
+
+## Counterexamples
+
+1. **Homogeneous terrain**: If a section of the flight is over large uniform agricultural fields with no distinguishing features, both VO and satellite matching may fail. Mitigation: use higher zoom satellite tiles, rely on VO with lower confidence.
+
+2. **Conflict-damaged area**: If satellite imagery shows pre-war structures that no longer exist, satellite matching will produce incorrect position estimates. Mitigation: confidence scoring will flag inconsistent matches.
+
+3. **FullHD resolution flight**: At GSD 20cm/pixel instead of 6cm, matching quality degrades ~3x. The 50m target may still be achievable but 20m will be very difficult.
+
+## Review Checklist
+- [x] Draft conclusions consistent with fact cards
+- [x] No important dimensions missed
+- [x] No over-extrapolation
+- [x] Issue found: The problem states "within 100 meters of each other" but actual data shows 80-230m. Pipeline must handle larger baselines.
+- [x] Issue found: Tile download strategy needs to handle unknown route direction — progressive expansion needed.
+
+## Conclusions Requiring Revision
+- Photo spacing is 80-230m not strictly 100m — increases the range of overlap variations. Still functional but wider variance than assumed.
+- Route direction is unknown at start — satellite tile pre-loading must use expanding radius strategy, not directional pre-loading.
@@ -0,0 +1,283 @@
+# Solution Draft
+
+## Product Solution Description
+
+A Python-based GPS-denied visual navigation service that determines GPS coordinates of consecutive UAV aerial photo centers using visual odometry, satellite image geo-referencing, and sliding window position optimization. The system operates as a background REST API service with real-time SSE streaming.
+
+**Core approach**: Consecutive images are matched using learned features (SuperPoint + LightGlue) to estimate relative motion (visual odometry). Periodically, each image is matched against pre-cached Google Maps satellite tiles to obtain absolute position anchors. A sliding window optimizer fuses VO estimates with satellite anchors, constraining drift. The system handles route disconnections by treating each continuous VO chain as an independent segment, geo-referenced through satellite matching.
+
+```
+┌─────────────────────────────────────────────────────────────────────┐
+│                        Client (Desktop App)                         │
+│   POST /jobs (start GPS, camera params, image folder)               │
+│   GET  /jobs/{id}/stream (SSE)                                      │
+│   POST /jobs/{id}/anchor (user manual GPS input)                    │
+│   GET  /jobs/{id}/point-to-gps (image_id, pixel_x, pixel_y)        │
+└──────────────────────┬──────────────────────────────────────────────┘
+                       │ HTTP/SSE
+┌──────────────────────▼──────────────────────────────────────────────┐
+│                     FastAPI Service Layer                            │
+│   Job Manager → Pipeline Orchestrator → SSE Event Emitter           │
+└──────────────────────┬──────────────────────────────────────────────┘
+                       │
+┌──────────────────────▼──────────────────────────────────────────────┐
+│                     Processing Pipeline                              │
+│                                                                      │
+│  ┌─────────────┐  ┌──────────────┐  ┌────────────────────────────┐  │
+│  │  Feature     │  │  Visual      │  │  Satellite Geo-Referencing │  │
+│  │  Extractor   │→│  Odometry    │→│  (cross-view matching)     │  │
+│  │ (SuperPoint) │  │ (homography) │  │  (SuperPoint+LightGlue)   │  │
+│  └─────────────┘  └──────────────┘  └────────────────────────────┘  │
+│         │                │                       │                    │
+│         ▼                ▼                       ▼                    │
+│  ┌──────────────────────────────────────────────────────────────┐    │
+│  │            Sliding Window Position Optimizer                  │    │
+│  │    (VO estimates + satellite anchors + drift constraints)     │    │
+│  └──────────────────────────────────────────────────────────────┘    │
+│                              │                                       │
+│  ┌───────────────────────────▼──────────────────────────────────┐    │
+│  │                  Segment Manager                              │    │
+│  │   (independent segments, satellite-anchored stitching)        │    │
+│  └──────────────────────────────────────────────────────────────┘    │
+│                                                                      │
+│  ┌──────────────────────────────────────────────────────────────┐    │
+│  │               Satellite Tile Cache Manager                    │    │
+│  │   (progressive download, Google Maps Tiles API, disk cache)   │    │
+│  └──────────────────────────────────────────────────────────────┘    │
+└──────────────────────────────────────────────────────────────────────┘
+```
+
+## Existing/Competitor Solutions Analysis
+
+| Solution | Approach | Accuracy | IMU Required | Open Source | Relevance |
+|----------|----------|----------|-------------|-------------|-----------|
+| YFS90/GNSS-Denied-UAV-Geolocalization | VO + satellite matching + terrain-weighted constraint optimization | <7m MAE | No | Yes (GitHub, 69★) | **Highest** — same constraints, best results |
+| AerialPositioning (hamitbugrabayram) | Multi-provider tile engine + deep matchers + perspective warping | Not reported | Simulated INS | Yes (GitHub, 52★) | High — tile engine and perspective warping reference |
+| NaviLoc | Trajectory-level VPR + VIO fusion | 19.5m MLE | Yes (VIO) | Partial | Medium — uses IMU, different altitude range |
+| ITU Thesis (Öztürk 2025) | ORB-SLAM3 + SuperPoint/SuperGlue/GIM SIM | GPS-level | No | No | High — architecture reference |
+| Mateos-Ramirez et al. (2024) | ORB VO + AKAZE satellite + Kalman filter | 143m mean (17km) | Yes | No | Medium — higher altitude, uses IMU |
+| VisionUAV-Navigation | Multi-algorithm feature detection + satellite matching | Not reported | Not stated | Yes (GitHub) | Low — early stage |
+
+**Key insight from competitor analysis**: YFS90 achieves <7m without IMU using terrain-weighted constraint optimization. This validates that our target accuracy (20-50m) is realistic and possibly conservative. The sliding window optimization approach is the critical differentiator from simpler VO+satellite systems.
+
+## Architecture
+
+### Component: Feature Extraction
+
+| Solution | Tools | Advantages | Limitations | Requirements | Security | Cost | Fit |
+|----------|-------|-----------|-------------|-------------|----------|------|-----|
+| SuperPoint | superpoint (PyTorch) | Learned features, robust to viewpoint/illumination changes. Repeatability in aerial scenes. GPU-accelerated. ~80ms per image. | Requires GPU. Fixed descriptor dimension (256). | NVIDIA GPU, PyTorch, CUDA | Model weights from official source only | Free (MIT license) | **Best** |
+| SIFT | OpenCV cv2.SIFT | Classical, well-understood. Scale/rotation invariant. Good satellite matching (SIFT+LightGlue top on ISPRS 2025). | Slower than SuperPoint. Less robust to extreme viewpoint changes. | OpenCV | N/A | Free | Good fallback |
+| ORB | OpenCV cv2.ORB | Very fast. Many keypoints. | Not scale-invariant. Poor for cross-view matching. | OpenCV | N/A | Free | Only for fast VO |
+
+**Selected**: SuperPoint as primary (both VO and satellite matching — unified pipeline). SIFT as fallback for satellite matching where SuperPoint struggles.
+
+### Component: Feature Matching
+
+| Solution | Tools | Advantages | Limitations | Requirements | Security | Cost | Fit |
+|----------|-------|-----------|-------------|-------------|----------|------|-----|
+| LightGlue | lightglue (PyTorch) | Fastest learned matcher (~20-50ms). Adaptive pruning. Best on satellite benchmarks. ONNX/TensorRT support for 2-4x speedup. | Requires GPU for best performance. | NVIDIA GPU, PyTorch | Model weights from official source only | Free (Apache 2.0) | **Best** |
+| SuperGlue | superglue (PyTorch) | Graph neural network, strong spatial context. 93% match rate (ITU thesis). | Slower than LightGlue (~2x). Non-commercial license. | NVIDIA GPU, PyTorch | Model weights from official source only | Non-commercial license | Backup |
+| GIM | gim (PyTorch) | Best generalization for challenging cross-domain scenes. | Additional model complexity. | NVIDIA GPU, PyTorch | Model weights from official source only | Free | Supplementary for difficult matches |
+
+**Selected**: LightGlue as primary. GIM as supplementary for difficult satellite matches.
+
+### Component: Visual Odometry (Consecutive Frame Matching)
+
+| Solution | Tools | Advantages | Limitations | Requirements | Security | Cost | Fit |
+|----------|-------|-----------|-------------|-------------|----------|------|-----|
+| Homography-based VO | OpenCV findHomography, decomposeHomographyMat | Perfect for downward camera + flat terrain. Cleanly gives rotation + translation. Known altitude resolves scale. Simple, fast. | Assumes planar ground (valid for steppe at 400m). Fails at sharp turns (by design). | OpenCV, NumPy | N/A | Free | **Best** |
+| Essential matrix VO | OpenCV findEssentialMat, recoverPose | More general than homography. Works for non-planar scenes. | Scale ambiguity harder to resolve. More complex. Unnecessary for our flat terrain case. | OpenCV | N/A | Free | Overengineered |
+| ORB-SLAM3 monocular | ORB-SLAM3 | Full SLAM with map management, loop closure. | Heavy dependency. Map building unnecessary. Scale ambiguity. | ROS (optional), C++ | N/A | Free (GPL) | Too complex |
+
+**Selected**: Homography-based VO with SuperPoint+LightGlue features.
+
+**VO Pipeline per frame**:
+1. Extract SuperPoint features from current image
+2. Match with previous image using LightGlue
+3. Estimate homography (cv2.findHomography with RANSAC)
+4. Decompose homography → rotation + translation (cv2.decomposeHomographyMat)
+5. Select correct decomposition (motion must be consistent with previous direction)
+6. Convert pixel displacement to meters: `displacement_m = displacement_px × GSD`
+7. GSD = (altitude × sensor_width) / (focal_length × image_width)
+8. Update position: new_pos = prev_pos + rotation × displacement_m
+9. Report inlier ratio as match quality metric
+
+### Component: Satellite Image Geo-Referencing
+
+| Solution | Tools | Advantages | Limitations | Requirements | Security | Cost | Fit |
+|----------|-------|-----------|-------------|-------------|----------|------|-----|
+| Direct cross-view matching with perspective warping | SuperPoint+LightGlue, OpenCV warpPerspective | Pre-warp UAV image to approximate nadir view. Reduces viewpoint gap. Proven approach. | Needs rough camera pose estimate (from VO) for warping. | PyTorch, OpenCV | API key secured | Google Maps API cost | **Best** |
+| Template matching (normalized cross-correlation) | OpenCV matchTemplate | Simple, no learning required. | Very sensitive to scale/rotation/illumination differences. Poor for cross-view. | OpenCV | N/A | Free | Poor for cross-view |
+| VPR retrieval + refinement (NetVLAD/CosPlace) | torchvision, faiss | Handles large search areas. | Coarse localization only (tile-level). Needs fine-grained refinement step. | PyTorch, faiss | N/A | Free | Supplementary — coarse search |
+
+**Selected**: Direct cross-view matching with perspective warping using SuperPoint + LightGlue.
+
+**Satellite Matching Pipeline per frame**:
+1. Estimate approximate position from VO
+2. Fetch satellite tile(s) from cache at estimated position (zoom 18, ~0.4m/px)
+3. Crop satellite region matching UAV image footprint (with margin)
+4. Warp UAV image to approximate nadir view using estimated camera pose
+5. Extract SuperPoint features from warped UAV image
+6. Extract SuperPoint features from satellite crop (can be pre-computed and cached)
+7. Match with LightGlue
+8. If insufficient matches: try GIM, try wider search area, try zoom 17
+9. If sufficient matches (≥15 inliers):
+   a. Estimate homography from matches
+   b. Transform image center through homography → satellite pixel coordinates
+   c. Convert satellite pixel coordinates to WGS84 using tile geo-referencing
+   d. This is the absolute position anchor
+10. Report match count and inlier ratio as confidence metrics
+
+### Component: Sliding Window Position Optimizer
+
+| Solution | Tools | Advantages | Limitations | Requirements | Security | Cost | Fit |
+|----------|-------|-----------|-------------|-------------|----------|------|-----|
+| Constrained sliding window optimization | scipy.optimize, NumPy | Fuses VO + satellite anchors. Constrains maximum drift. Smooths trajectory. Inspired by YFS90 (<7m). | Window size tuning needed. | SciPy, NumPy | N/A | Free | **Best** |
+| Extended Kalman Filter | filterpy | Standard, well-understood. Online fusion. | Linearization approximation. Single-pass, no backward smoothing. | filterpy | N/A | Free | Good simpler alternative |
+| Pose Graph Optimization | g2o or GTSAM (Python bindings) | Globally optimal. Handles complex factor graphs. | Heavy C++ dependency. Overkill for sequential processing. | g2o/GTSAM, C++ | N/A | Free | Over-engineered |
+
+**Selected**: Constrained sliding window optimization (primary), with EKF as simpler initial implementation.
+
+**Optimizer behavior**:
+- Maintains a sliding window of last N positions (N=20-50)
+- VO estimates provide relative motion constraints between consecutive positions
+- Satellite matches provide absolute position anchors (hard/soft constraints)
+- Maximum drift constraint: cumulative VO displacement between anchors < 100m
+- Optimization minimizes: sum of VO residuals + anchor residuals + smoothness penalty
+- On each new frame: add to window, re-optimize, emit updated positions
+- Enables refinement: earlier positions improve as new anchors arrive
+
+### Component: Segment Manager
+
+The segment manager is the core architectural pattern, not an edge case handler.
+
+**Segment lifecycle**:
+1. **Start condition**: First image of flight, or VO failure (feature match count < threshold)
+2. **Active tracking**: VO provides frame-to-frame motion within segment
+3. **Anchoring**: Satellite matching provides absolute position for segment's images
+4. **End condition**: VO failure (sharp turn, outlier, occlusion)
+5. **New segment**: Starts from satellite anchor or user-provided GPS
+
+**Segment states**:
+- `ANCHORED`: At least one satellite match provides absolute position → HIGH confidence
+- `FLOATING`: No satellite match yet → positioned relative to start point only → LOW confidence
+- `USER_ANCHORED`: User provided manual GPS → MEDIUM confidence (human error possible)
+
+**Segment stitching**:
+- All segments share the WGS84 coordinate frame via satellite matching
+- No direct inter-segment matching needed
+- A segment without any satellite anchor remains "floating" and is flagged for user input
+
+### Component: Satellite Tile Cache Manager
+
+| Solution | Tools | Advantages | Limitations | Requirements | Security | Cost | Fit |
+|----------|-------|-----------|-------------|-------------|----------|------|-----|
+| Progressive download with disk cache | aiohttp, aiofiles, sqlite3 | Async download doesn't block pipeline. Tiles cached to disk. Progressive expansion follows route. | Needs internet during processing. First few images may wait for tiles. | Google Maps Tiles API key | API key in env var, not in code | Google Maps API: $200/month free credit covers ~40K tiles | **Best** |
+| Pre-download entire area | requests, sqlite3 | All tiles available at start. No download latency during processing. | Requires known bounding box. Large download for unknown routes. Wasteful. | Same | Same | Higher cost if area is large | For known routes |
+
+**Selected**: Progressive download with disk cache.
+
+**Strategy**:
+1. On job start: download tiles in radius R=1km around starting GPS at zoom 18
+2. As route extends: download tiles ahead of estimated position (radius 500m)
+3. Cache tiles on disk in `{zoom}/{x}/{y}.jpg` directory structure
+4. Cache is persistent across jobs — tiles are reused for overlapping areas
+5. Pre-compute SuperPoint features for cached tiles (saved alongside tile images)
+6. If tile download fails or is unavailable: log warning, mark position as VO-only
+
+**Tile download budget**:
+- Initial 1km radius at zoom 18: ~300 tiles (~12MB)
+- Per-frame expansion: 5-20 new tiles (~0.2-0.8MB)
+- Full 20km flight: ~2000 tiles (~80MB) over the course of processing
+- Well within $200/month Google Maps free credit
+
+### Component: API & Real-Time Streaming
+
+| Solution | Tools | Advantages | Limitations | Requirements | Security | Cost | Fit |
+|----------|-------|-----------|-------------|-------------|----------|------|-----|
+| FastAPI + SSE | FastAPI ≥0.135.0, EventSourceResponse, uvicorn | Native SSE support. Async pipeline. Excellent for ML workloads. OpenAPI docs auto-generated. | Python GIL (mitigated with asyncio + GPU-bound ops). | Python 3.11+, uvicorn | CORS configuration, API key auth | Free | **Best** |
+
+**Selected**: FastAPI + SSE.
+
+**API Endpoints**:
+```
+POST /jobs
+  Body: { start_lat, start_lon, altitude, camera_params, image_folder }
+  Returns: { job_id }
+
+GET /jobs/{job_id}/stream
+  SSE stream of:
+    - { event: "position", data: { image_id, lat, lon, confidence, segment_id } }
+    - { event: "refined", data: { image_id, lat, lon, confidence } }
+    - { event: "segment_start", data: { segment_id, reason } }
+    - { event: "user_input_needed", data: { image_id, reason } }
+    - { event: "complete", data: { summary } }
+
+POST /jobs/{job_id}/anchor
+  Body: { image_id, lat, lon }
+  Manual user GPS input for an image
+
+GET /jobs/{job_id}/point-to-gps?image_id=X&px=100&py=200
+  Returns: { lat, lon, confidence }
+  Interactive point-to-GPS lookup
+
+GET /jobs/{job_id}/results
+  Returns: full results as GeoJSON or CSV
+```
+
+### Component: Interactive Point-to-GPS Lookup
+
+For each processed image, the system stores the estimated camera-to-ground homography (from either satellite matching or VO+estimated pose). Given a pixel coordinate (px, py) in an image:
+
+1. If image has satellite match: use the computed homography to project (px, py) → satellite tile coordinates → WGS84. High confidence.
+2. If image has only VO pose: use camera intrinsics + estimated altitude + estimated heading to ray-cast (px, py) to the ground plane → WGS84. Medium confidence.
+3. Both methods return confidence score based on the underlying position estimate quality.
+
+## Testing Strategy
+
+### Integration / Functional Tests
+- End-to-end pipeline test using provided 60-image sample dataset with ground truth GPS
+- Verify 80% of positions within 50m of ground truth
+- Verify 60% of positions within 20m of ground truth
+- Test sharp turn handling: simulate turn by reordering/skipping images
+- Test segment creation and reconnection
+- Test user manual anchor injection
+- Test point-to-GPS lookup accuracy against known coordinates
+- Test SSE streaming delivers results within 1s of processing completion
+- Test with FullHD resolution images (degraded accuracy expected, but pipeline must not fail)
+
+### Non-Functional Tests
+- Processing speed: <5s per image on RTX 2060 (target <2s)
+- Memory: peak RAM <16GB, VRAM <6GB during 3000-image flight
+- Memory leak test: process 3000 images, verify stable memory
+- Concurrent jobs: 2 simultaneous flights, verify isolation
+- Tile cache: verify tiles are cached and reused across jobs
+- API: load test SSE connections (10 simultaneous clients)
+- Recovery: kill and restart service mid-job, verify job can resume
+
+### Security Tests
+- API key authentication enforcement
+- Google Maps API key not exposed in responses or logs
+- Image folder path traversal prevention
+- Input validation (GPS coordinates, camera parameters)
+- Rate limiting on API endpoints
+
+## References
+- [YFS90/GNSS-Denied-UAV-Geolocalization](https://github.com/YFS90/GNSS-Denied-UAV-Geolocalization) — <7m MAE without IMU
+- [AerialPositioning](https://github.com/hamitbugrabayram/AerialPositioning) — tile engine and deep matcher integration reference
+- [NaviLoc (2025)](https://www.mdpi.com/2504-446X/10/2/97) — trajectory-level visual localization, 19.5m MLE
+- [ITU Thesis (2025)](https://polen.itu.edu.tr/items/1fe1e872-7cea-44d8-a8de-339e4587bee6) — ORB-SLAM3 + SIM integration
+- [Mateos-Ramirez et al. (2024)](https://www.mdpi.com/2076-3417/14/16/7420) — VO + satellite correction for fixed-wing UAV
+- [LightGlue (ICCV 2023)](https://github.com/cvg/LightGlue) — feature matching
+- [SuperPoint](https://github.com/magicleap/SuperPointPretrainedNetwork) — feature extraction
+- [DALGlue (2025)](https://www.nature.com/articles/s41598-025-21602-5) — 11.8% improvement over LightGlue
+- [SCAR (2026)](https://arxiv.org/html/2602.16349v1) — satellite-based aerial calibration
+- [DUSt3R/MASt3R evaluation (2025)](https://arxiv.org/abs/2507.14798) — extreme low-overlap matching
+- [FastAPI SSE docs](https://fastapi.tiangolo.com/tutorial/server-sent-events/)
+- [Google Maps Tiles API](https://developers.google.com/maps/documentation/tile/satellite)
+
+## Related Artifacts
+- AC assessment: `_docs/00_research/gps_denied_visual_nav/00_ac_assessment.md`
+- Comparison framework: `_docs/00_research/gps_denied_visual_nav/03_comparison_framework.md`
+- Reasoning chain: `_docs/00_research/gps_denied_visual_nav/04_reasoning_chain.md`
@@ -0,0 +1,360 @@
+# Solution Draft
+
+## Assessment Findings
+
+| Old Component Solution | Weak Point | New Solution |
+|------------------------|------------|-------------|
+| Direct SuperPoint+LightGlue satellite matching | **Functional**: No coarse localization stage. Fails when VO drift is large or satellite tile is wrong. Not rotation-invariant (GitHub issue #64). Returns false matches on non-overlapping pairs (issue #13). | Two-stage: DINOv2 coarse retrieval → SuperPoint+LightGlue fine alignment. Image rotation normalization. Geometric consistency check for match validation. |
+| SuperPoint for all feature extraction | **Performance**: Unified pipeline is simpler but suboptimal. SuperPoint ~80ms per image is slower than needed for every-frame VO. | Dual-extractor: XFeat for VO (5x faster, ~15ms), SuperPoint for satellite matching (higher accuracy). |
+| scipy.optimize sliding window | **Functional**: Generic optimizer. No proper uncertainty modeling per measurement. No terrain constraints. Reinvents what GTSAM already provides. | GTSAM iSAM2 factor graph: BetweenFactor (VO), GPSFactor (satellite anchors), terrain constraints from Copernicus DEM. |
+| Google Maps as sole satellite provider | **Functional**: Eastern Ukraine imagery 3-5+ years old. $200/month free credit expired Feb 2025. 15K/day rate limit tight for large flights. | Multi-provider: Google Maps primary + Mapbox fallback + user-provided tiles. Request budgeting. |
+| No image downscaling strategy | **Performance/Memory**: 6252×4168 images cannot fit in 6GB VRAM for feature extraction. No memory budget specified. | Downscale to 1600 long edge for feature extraction. Streaming one-at-a-time processing. Explicit memory budgets. |
+| No camera rotation handling | **Functional**: Non-stabilized camera produces rotated images. SuperPoint/LightGlue fail at 90° rotation. | Estimate heading from VO chain. Rectify images before satellite matching. SIFT fallback for rotation-heavy cases. |
+| Homography VO without terrain correction | **Functional**: GSD assumes constant altitude. No fallback for non-planar scenes. Decomposition can be unstable. | Integrate Copernicus DEM for terrain-corrected GSD. Essential matrix fallback when RANSAC inlier ratio is low. |
+| No non-match detection | **Functional**: VO failure detection relies on match count only. Misses geometrically inconsistent matches. | Triple check: match count + RANSAC inlier ratio + motion consistency with previous frames. |
+| API key authentication only | **Security**: API keys in URLs persist in logs and browser history. No SSE connection limits. No DoS protection. | JWT authentication. Short-lived SSE tokens. Rate limiting. Connection pool limits. Image size validation. |
+| Segment reconnection via satellite only | **Functional**: Floating segments with no satellite match stay permanently unresolved. | Cross-segment matching when new anchors arrive. DEM constraints. Configurable user-input timeout with auto-continue. |
+
+## Product Solution Description
+
+A Python-based GPS-denied visual navigation service that determines GPS coordinates of consecutive UAV photo centers using a hierarchical localization approach: fast visual odometry for frame-to-frame motion, two-stage satellite geo-referencing (coarse retrieval + fine matching) for absolute positioning, and factor graph optimization for trajectory refinement. The system operates as a background REST API service with real-time SSE streaming.
+
+**Core approach**: Consecutive images are matched using XFeat (fast learned features) to estimate relative motion (visual odometry). Periodically, each image is geo-referenced against satellite imagery through a two-stage process: DINOv2 global retrieval selects the best-matching satellite tile, then SuperPoint+LightGlue refines the alignment to pixel precision. A GTSAM iSAM2 factor graph fuses VO constraints, satellite anchors, and DEM terrain constraints to produce an optimized trajectory. The system handles route disconnections by treating each continuous VO chain as an independent segment, geo-referenced through satellite matching and connected via the shared WGS84 coordinate frame.
+
+```
+┌─────────────────────────────────────────────────────────────────────┐
+│                        Client (Desktop App)                         │
+│   POST /jobs (start GPS, camera params, image folder)               │
+│   GET  /jobs/{id}/stream (SSE)                                      │
+│   POST /jobs/{id}/anchor (user manual GPS input)                    │
+│   GET  /jobs/{id}/point-to-gps (image_id, pixel_x, pixel_y)        │
+└──────────────────────┬──────────────────────────────────────────────┘
+                       │ HTTP/SSE (JWT auth)
+┌──────────────────────▼──────────────────────────────────────────────┐
+│                     FastAPI Service Layer                            │
+│   Job Manager → Pipeline Orchestrator → SSE Event Emitter           │
+└──────────────────────┬──────────────────────────────────────────────┘
+                       │
+┌──────────────────────▼──────────────────────────────────────────────┐
+│                     Processing Pipeline                              │
+│                                                                      │
+│  ┌──────────────┐  ┌──────────────┐  ┌─────────────────────────┐   │
+│  │ Image        │  │  Visual      │  │ Satellite Geo-Ref       │   │
+│  │ Preprocessor │→│  Odometry    │→│ Stage 1: DINOv2 retrieval│   │
+│  │ (downscale,  │  │ (XFeat +    │  │ Stage 2: SuperPoint +   │   │
+│  │  rectify)    │  │  LightGlue) │  │   LightGlue refinement  │   │
+│  └──────────────┘  └──────────────┘  └─────────────────────────┘   │
+│         │                │                       │                   │
+│         ▼                ▼                       ▼                   │
+│  ┌──────────────────────────────────────────────────────────────┐   │
+│  │       GTSAM iSAM2 Factor Graph Optimizer                    │   │
+│  │  (VO factors + satellite anchors + DEM terrain constraints)  │   │
+│  └──────────────────────────────────────────────────────────────┘   │
+│                              │                                       │
+│  ┌───────────────────────────▼──────────────────────────────────┐   │
+│  │                  Segment Manager                              │   │
+│  │   (independent segments, cross-segment reconnection)          │   │
+│  └──────────────────────────────────────────────────────────────┘   │
+│                                                                      │
+│  ┌──────────────────────────────────────────────────────────────┐   │
+│  │          Multi-Provider Satellite Tile Cache                  │   │
+│  │  (Google Maps + Mapbox + user tiles, disk cache, DEM cache)   │   │
+│  └──────────────────────────────────────────────────────────────┘   │
+└──────────────────────────────────────────────────────────────────────┘
+```
+
+## Architecture
+
+### Component: Image Preprocessor
+
+| Solution | Tools | Advantages | Limitations | Requirements | Security | Performance | Fit |
+|----------|-------|-----------|-------------|-------------|----------|------------|-----|
+| Downscale + rectify pipeline | OpenCV resize, NumPy | Normalizes input for all downstream components. Consistent memory usage. Preserves full-res metadata for GSD. | Loses fine detail in downscaled images. | OpenCV, NumPy | Input validation on image files | <10ms per image | **Best** |
+
+**Selected**: Downscale + rectify pipeline.
+
+**Preprocessing per image**:
+1. Load image, validate format and dimensions
+2. Downscale to max 1600 pixels on longest edge (preserving aspect ratio) for feature extraction
+3. Store original resolution for GSD calculation: `GSD = (altitude × sensor_width) / (focal_length × original_width)`
+4. If estimated heading is available (from previous VO): rotate image to approximate north-up orientation for satellite matching
+5. Convert to grayscale for feature extraction
+6. Output: downscaled grayscale image + metadata (original dims, GSD, estimated heading)
+
+### Component: Feature Extraction
+
+| Solution | Tools | Advantages | Limitations | Requirements | Security | Performance | Fit |
+|----------|-------|-----------|-------------|-------------|----------|------------|-----|
+| XFeat (for VO) | accelerated_features (PyTorch) | 5x faster than SuperPoint. CPU-capable. Sparse + semi-dense matching. Used in SatLoc-Fusion. | Fewer keypoints than SuperPoint in some scenes. | PyTorch | Model weights from official source | ~15ms GPU, ~50ms CPU | **Best for VO** |
+| SuperPoint (for satellite matching) | superpoint (PyTorch) | Learned features, robust to viewpoint/illumination. Proven for satellite matching (ISPRS 2025). 256-dim descriptors. | Slower than XFeat. Not rotation-invariant. | NVIDIA GPU, PyTorch, CUDA | Model weights from official source | ~80ms GPU | **Best for satellite** |
+| SIFT (fallback) | OpenCV cv2.SIFT | Rotation-invariant. Scale-invariant. Better for high-rotation scenarios. | Slower. Less discriminative in low-texture. | OpenCV | N/A | ~200ms CPU | Rotation fallback |
+
+**Selected**: XFeat for VO, SuperPoint for satellite matching, SIFT as rotation-heavy fallback.
+
+### Component: Feature Matching
+
+| Solution | Tools | Advantages | Limitations | Requirements | Security | Performance | Fit |
+|----------|-------|-----------|-------------|-------------|----------|------------|-----|
+| LightGlue + ONNX/TensorRT | lightglue + LightGlue-ONNX | 2-4x faster than PyTorch via ONNX. Best balance of speed/accuracy. FlashAttention-2 + TopK-trick for additional 30%. | FP8 not available on RTX 2060 (Turing). Not rotation-invariant. | NVIDIA GPU, ONNX Runtime / TensorRT | Model weights from official source | ~50-100ms ONNX on RTX 2060 | **Best** |
+| SuperGlue | superglue (PyTorch) | Strong spatial context. 93% match rate. | 2x slower than LightGlue. Non-commercial license. | NVIDIA GPU, PyTorch | Model weights from official source | ~100-200ms | Backup |
+| DALGlue | dalglue (PyTorch) | 11.8% MMA improvement over LightGlue. UAV-optimized wavelet preprocessing. | Very new (2025). Limited production validation. | NVIDIA GPU, PyTorch | Model weights from official source | Comparable to LightGlue | Monitor for future |
+
+**Selected**: LightGlue with ONNX optimization. DALGlue to evaluate when mature.
+
+### Component: Visual Odometry (Consecutive Frame Matching)
+
+| Solution | Tools | Advantages | Limitations | Requirements | Security | Performance | Fit |
+|----------|-------|-----------|-------------|-------------|----------|------------|-----|
+| Homography VO with essential matrix fallback | OpenCV findHomography, findEssentialMat, decomposeHomographyMat | Homography: optimal for flat terrain. Essential matrix: handles non-planar. Known altitude resolves scale. | Homography assumes planar. Essential matrix: more complex, scale ambiguity. | OpenCV, NumPy | N/A | ~5ms for estimation | **Best** |
+| ORB-SLAM3 monocular | ORB-SLAM3 | Full SLAM with loop closure. | Heavy. Map building unnecessary. C++ dependency. | ROS (optional), C++ | N/A | — | Over-engineered |
+
+**Selected**: Homography VO with essential matrix fallback and DEM terrain correction.
+
+**VO Pipeline per frame**:
+1. Extract XFeat features from current image (~15ms)
+2. Match with previous image using LightGlue ONNX (~50ms)
+3. **Triple failure check**: match count ≥ 30 AND RANSAC inlier ratio ≥ 0.4 AND motion magnitude consistent with expected inter-frame distance (100m ± 250m to handle outliers up to 350m)
+4. If checks pass → estimate homography (cv2.findHomography with USAC_MAGSAC)
+5. If RANSAC inlier ratio < 0.6 → additionally estimate essential matrix (cv2.findEssentialMat) as quality check
+6. Decompose homography → rotation + translation
+7. Select correct decomposition (motion consistent with previous direction + positive depth)
+8. **Terrain-corrected GSD**: query Copernicus DEM at estimated position → `effective_altitude = flight_altitude - terrain_elevation` → `GSD = (effective_altitude × sensor_width) / (focal_length × original_image_width)`
+9. Convert pixel displacement to meters: `displacement_m = displacement_px × GSD`
+10. Update position: `new_pos = prev_pos + rotation @ displacement_m`
+11. Track cumulative heading for image rectification
+12. If triple failure check fails → trigger segment break
+
+### Component: Satellite Image Geo-Referencing (Two-Stage)
+
+| Solution | Tools | Advantages | Limitations | Requirements | Security | Performance | Fit |
+|----------|-------|-----------|-------------|-------------|----------|------------|-----|
+| Stage 1: DINOv2 coarse retrieval | dinov2 (PyTorch), faiss | Handles large viewpoint/domain gap. Finds correct area even with 100-200m VO drift. Semantic matching robust to seasonal change. | Coarse only (~tile-level). Needs pre-computed satellite tile embeddings. | PyTorch, faiss | Model weights from official source | ~50ms per query | **Best coarse** |
+| Stage 2: SuperPoint+LightGlue fine matching with perspective warping | SuperPoint, LightGlue-ONNX, OpenCV warpPerspective | Precise alignment. Pixel-level accuracy. Proven on satellite benchmarks. | Needs rough pose for warping. Fails without Stage 1 on large drift. | PyTorch, ONNX Runtime, OpenCV | API keys secured | ~150ms total | **Best fine** |
+
+**Selected**: Two-stage hierarchical matching.
+
+**Satellite Matching Pipeline**:
+1. Estimate approximate position from VO
+2. **Stage 1 — Coarse retrieval**:
+   a. Define search area: 500m radius around VO estimate (expand to 1km if segment just started)
+   b. Pre-compute DINOv2 embeddings for all satellite tiles in search area (cached)
+   c. Extract DINOv2 embedding from rectified UAV image
+   d. Find top-5 most similar satellite tiles using faiss cosine similarity
+3. **Stage 2 — Fine matching** (on top-5 tiles, stop on first good match):
+   a. Warp UAV image to approximate nadir view using estimated camera pose
+   b. Extract SuperPoint features from warped UAV image
+   c. Extract SuperPoint features from satellite tile (pre-computed and cached)
+   d. Match with LightGlue ONNX
+   e. **Geometric validation**: require ≥15 inliers, inlier ratio ≥ 0.3, reprojection error < 3px
+   f. If valid: estimate homography → transform image center → satellite pixel → WGS84
+   g. Report: absolute position anchor with confidence based on match quality
+4. If all 5 tiles fail Stage 2: try SIFT+LightGlue (rotation-invariant), try zoom level 17 (wider view)
+5. If still fails: mark frame as VO-only, reduce confidence, continue
+
+**Satellite matching frequency**: Every frame when available, but async — don't block VO pipeline. Satellite result arrives and gets added to factor graph retroactively.
+
+### Component: GTSAM Factor Graph Optimizer
+
+| Solution | Tools | Advantages | Limitations | Requirements | Security | Performance | Fit |
+|----------|-------|-----------|-------------|-------------|----------|------------|-----|
+| GTSAM iSAM2 factor graph | gtsam 4.2 (pip) | Incremental smoothing. Proper uncertainty propagation. Built-in GPSFactor. Backward smoothing on new evidence. Python bindings. Production-proven. | C++ backend (pip binary handles this). Learning curve for factor graph API. | gtsam==4.2, NumPy | N/A | ~5-10ms incremental update | **Best** |
+| scipy.optimize sliding window | scipy, NumPy | Simple. No external dependency. | Generic optimizer. No uncertainty. No incremental update. | SciPy, NumPy | N/A | ~10-50ms per window | Baseline only |
+
+**Selected**: GTSAM iSAM2.
+
+**Factor graph structure**:
+- **Variables**: Pose2 (x, y, heading) per image
+- **VO Factor** (BetweenFactorPose2): relative motion between consecutive frames. Noise model: diagonal with sigma proportional to `1 / inlier_ratio`. Higher inlier ratio = lower uncertainty.
+- **Satellite Anchor Factor** (GPSFactor or PriorFactorPoint2): absolute position from satellite matching. Noise model: sigma proportional to `reprojection_error × GSD`. Good match (~0.5px × 0.4m/px) = 0.2m sigma. Poor match = 5-10m sigma.
+- **DEM Terrain Factor** (custom): constrains altitude to be consistent with Copernicus DEM at estimated position. Soft constraint, sigma = 5m.
+- **Drift Limit Factor** (custom): penalizes cumulative VO displacement between satellite anchors exceeding 100m. Activated only when two anchor-to-anchor VO path exceeds threshold.
+
+**Optimizer behavior**:
+- On each new frame: add VO factor, run iSAM2.update() → ~5ms
+- On satellite match arrival: add anchor factor, run iSAM2.update() → triggers backward correction of recent poses
+- Emit updated positions via SSE after each update
+- Refinement events: when backward correction moves positions by >1m, emit "refined" SSE event
+
+### Component: Segment Manager
+
+The segment manager tracks independent VO chains and manages their lifecycle and interconnection.
+
+**Segment lifecycle**:
+1. **Start condition**: First image, OR VO triple failure check fails
+2. **Active tracking**: VO provides frame-to-frame motion within segment
+3. **Anchoring**: Satellite two-stage matching provides absolute position
+4. **End condition**: VO failure (sharp turn, outlier >350m, occlusion)
+5. **New segment**: Starts from satellite anchor or user GPS
+
+**Segment states**:
+- `ANCHORED`: At least one satellite match → HIGH confidence
+- `FLOATING`: No satellite match yet → positioned relative to start point → LOW confidence
+- `USER_ANCHORED`: User provided manual GPS → MEDIUM confidence
+
+**Enhanced segment reconnection**:
+- When a segment becomes ANCHORED, check for nearby FLOATING segments (within 500m of any anchored position in the new segment)
+- Attempt satellite-based position matching between FLOATING segment images and satellite tiles near the ANCHORED segment
+- If match found: anchor the floating segment and connect to the trajectory
+- DEM consistency check: ensure segment positions are consistent with terrain elevation
+- If no match after all frames in floating segment are tried: request user input with configurable timeout (default: 30s), then continue with best VO estimate
+
+### Component: Multi-Provider Satellite Tile Cache
+
+| Solution | Tools | Advantages | Limitations | Requirements | Security | Performance | Fit |
+|----------|-------|-----------|-------------|-------------|----------|------------|-----|
+| Multi-provider progressive cache with DEM | aiohttp, aiofiles, sqlite3, faiss | Multiple providers for coverage. Async download. DINOv2 embeddings pre-computed. DEM cached alongside tiles. | Needs internet. Provider API differences. | Google Maps Tiles API + Mapbox API keys | API keys in env vars only. Never logged. | Async, non-blocking | **Best** |
+
+**Selected**: Multi-provider progressive cache.
+
+**Provider priority**:
+1. User-provided tiles (highest priority — custom/recent imagery for the area)
+2. Google Maps (zoom 18, ~0.4m/px) — 100K free tiles/month
+3. Mapbox Satellite (zoom 16+, up to 0.3m/px) — 200K free requests/month
+
+**Cache strategy**:
+1. On job start: download tiles in 1km radius around starting GPS from primary provider
+2. Pre-compute SuperPoint features AND DINOv2 embeddings for all cached tiles
+3. As route extends: download tiles 500m ahead of estimated position
+4. **Request budgeting**: track daily API requests, switch to secondary provider at 80% of daily limit
+5. Cache structure on disk:
+   ```
+   cache/
+   ├── tiles/{provider}/{zoom}/{x}/{y}.jpg
+   ├── features/{provider}/{zoom}/{x}/{y}_sp.npz     (SuperPoint features)
+   ├── embeddings/{provider}/{zoom}/{x}/{y}_dino.npz  (DINOv2 embedding)
+   └── dem/{lat}_{lon}.tif                            (Copernicus DEM tiles)
+   ```
+6. Cache is persistent across jobs — tiles and features reused for overlapping areas
+7. **DEM cache**: download Copernicus DEM GLO-30 tiles alongside satellite tiles. 30m resolution is sufficient for terrain correction at flight altitude.
+
+**Tile download budget (revised)**:
+- Google Maps: 100,000 tiles/month free → ~50 flights at 2000 tiles each
+- Mapbox: 200,000 requests/month free → additional capacity
+- Per flight: ~2000 satellite tiles (~80MB) + ~500 DEM tiles (~20MB)
+- Combined free tier handles operational volume
+
+### Component: API & Real-Time Streaming
+
+| Solution | Tools | Advantages | Limitations | Requirements | Security | Performance | Fit |
+|----------|-------|-----------|-------------|-------------|----------|------------|-----|
+| FastAPI + SSE + JWT | FastAPI ≥0.135.0, EventSourceResponse, uvicorn, python-jose | Native SSE. Async pipeline. OpenAPI auto-generated. JWT for proper auth. | Python GIL (mitigated with asyncio + GPU-bound ops). | Python 3.11+, uvicorn | JWT auth, CORS, rate limiting | Async, non-blocking | **Best** |
+
+**Selected**: FastAPI + SSE + JWT authentication.
+
+**API Endpoints**:
+```
+POST /auth/token
+  Body: { api_key }
+  Returns: { access_token, token_type, expires_in }
+
+POST /jobs
+  Headers: Authorization: Bearer <token>
+  Body: { start_lat, start_lon, altitude, camera_params, image_folder }
+  Returns: { job_id }
+
+GET /jobs/{job_id}/stream
+  Headers: Authorization: Bearer <token>
+  SSE stream of:
+    - { event: "position", data: { image_id, lat, lon, confidence, segment_id } }
+    - { event: "refined", data: { image_id, lat, lon, confidence, delta_m } }
+    - { event: "segment_start", data: { segment_id, reason } }
+    - { event: "user_input_needed", data: { image_id, reason, timeout_s } }
+    - { event: "complete", data: { summary } }
+
+POST /jobs/{job_id}/anchor
+  Headers: Authorization: Bearer <token>
+  Body: { image_id, lat, lon }
+  Manual user GPS input for an image
+
+GET /jobs/{job_id}/point-to-gps?image_id=X&px=100&py=200
+  Headers: Authorization: Bearer <token>
+  Returns: { lat, lon, confidence }
+
+GET /jobs/{job_id}/results?format=geojson
+  Headers: Authorization: Bearer <token>
+  Returns: full results as GeoJSON or CSV (WGS84)
+```
+
+**Security measures**:
+- JWT authentication on all endpoints (short-lived tokens, 1h expiry)
+- Image folder whitelist: only paths under configured base directories allowed
+- Max image dimensions: 8000×8000 pixels
+- Max concurrent SSE connections per client: 5
+- Rate limiting: 100 requests/minute per client
+- All provider API keys in environment variables, never logged or returned in responses
+- CORS configured for known client origins only
+
+### Component: Interactive Point-to-GPS Lookup
+
+For each processed image, the system stores the estimated camera-to-ground homography. Given pixel coordinates (px, py):
+
+1. If image has satellite match: use computed homography to project (px, py) → satellite tile coordinates → WGS84. HIGH confidence.
+2. If image has only VO pose: use camera intrinsics + DEM-corrected altitude + estimated heading to ray-cast (px, py) to ground plane → WGS84. MEDIUM confidence.
+3. Confidence score derived from underlying position estimate quality.
+
+## Testing Strategy
+
+### Integration / Functional Tests
+- End-to-end pipeline test using provided 60-image sample dataset with ground truth GPS
+- Verify 80% of positions within 50m of ground truth
+- Verify 60% of positions within 20m of ground truth
+- Test sharp turn handling: simulate 90° turn with non-overlapping images
+- Test segment creation, satellite anchoring, and cross-segment reconnection
+- Test user manual anchor injection via POST endpoint
+- Test point-to-GPS lookup accuracy against known ground coordinates
+- Test SSE streaming delivers results within 1s of processing completion
+- Test with FullHD resolution images (pipeline must not fail)
+- Test with 6252×4168 images (verify downscaling and memory usage)
+- Test DINOv2 coarse retrieval finds correct satellite tile with 100m VO drift
+- Test multi-provider fallback: block Google Maps, verify Mapbox takes over
+- Test with outdated satellite imagery: verify confidence scores reflect match quality
+- Test outlier handling: 350m gap between consecutive photos
+- Test image rotation handling: apply 45° rotation to images, verify pipeline handles it
+
+### Non-Functional Tests
+- Processing speed: <5s per image on RTX 2060 (target <2s with ONNX optimization)
+- Memory: peak RAM <16GB, VRAM <6GB during 3000-image flight at max resolution
+- Memory stability: process 3000 images, verify no memory leak (stable RSS over time)
+- Concurrent jobs: 2 simultaneous flights, verify isolation and resource sharing
+- Tile cache: verify tiles and features are cached and reused across jobs
+- API: load test SSE connections (10 simultaneous clients)
+- Recovery: kill and restart service mid-job, verify job can resume from last processed image
+- DEM download: verify Copernicus DEM tiles fetched and cached correctly
+- GTSAM optimizer: verify backward correction produces "refined" events with improved positions
+
+### Security Tests
+- JWT authentication enforcement on all endpoints
+- Expired/invalid token rejection
+- Provider API keys not exposed in responses, logs, or error messages
+- Image folder path traversal prevention (attempt to access /etc/passwd via image_folder)
+- Image folder whitelist enforcement
+- Input validation: invalid GPS coordinates, negative altitude, malformed camera params
+- Rate limiting: verify 429 response after exceeding limit
+- Max SSE connection enforcement
+- Max image size validation (reject >8000px)
+- CORS enforcement: reject requests from unknown origins
+
+## References
+- [YFS90/GNSS-Denied-UAV-Geolocalization](https://github.com/YFS90/GNSS-Denied-UAV-Geolocalization) — <7m MAE with terrain-weighted constraint optimization
+- [SatLoc-Fusion (2025)](https://www.mdpi.com/2072-4292/17/17/3048) — hierarchical DINOv2+XFeat+optical flow, <15m on edge hardware
+- [CEUSP (2025)](https://arxiv.org/abs/2502.11408) — DINOv2-based cross-view UAV self-positioning
+- [Oblique-Robust AVL (IEEE TGRS 2024)](https://ieeexplore.ieee.org/iel7/36/10354519/10356107.pdf) — rotation-equivariant features for UAV-satellite matching
+- [XFeat (CVPR 2024)](https://github.com/verlab/accelerated_features) — 5x faster than SuperPoint
+- [LightGlue-ONNX](https://github.com/fabio-sim/LightGlue-ONNX) — 2-4x speedup via ONNX/TensorRT
+- [DALGlue (2025)](https://www.nature.com/articles/s41598-025-21602-5) — 11.8% MMA improvement over LightGlue for UAV
+- [SIFT+LightGlue UAV Mosaicking (ISPRS 2025)](https://isprs-archives.copernicus.org/articles/XLVIII-2-W11-2025/169/2025/) — SIFT superior for high-rotation conditions
+- [LightGlue rotation issue #64](https://github.com/cvg/LightGlue/issues/64) — confirmed not rotation-invariant
+- [LightGlue no-match issue #13](https://github.com/cvg/LightGlue/issues/13) — false matches on non-overlapping pairs
+- [GTSAM v4.2](https://github.com/borglab/gtsam) — factor graph optimization with Python bindings
+- [Copernicus DEM GLO-30](https://dataspace.copernicus.eu/explore-data/data-collections/copernicus-contributing-missions/collections-description/COP-DEM) — free 30m global DEM
+- [Google Maps Tiles API](https://developers.google.com/maps/documentation/tile/satellite) — satellite tiles, 100K free/month
+- [Mapbox Satellite](https://docs.mapbox.com/data/tilesets/reference/mapbox-satellite/) — alternative tile provider, up to 0.3m/px
+- [DINOv2 UAV Self-Localization (2025)](https://ui.adsabs.harvard.edu/abs/2025IRAL...10.2080Y/) — 86.27 R@1 on DenseUAV
+- [FastAPI SSE](https://fastapi.tiangolo.com/tutorial/server-sent-events/)
+- [Homography Decomposition Revisited (IJCV 2025)](https://link.springer.com/article/10.1007/s11263-025-02680-4)
+- [Sliding Window Factor Graph Optimization (2020)](https://www.cambridge.org/core/services/aop-cambridge-core/content/view/523C7C41D18A8D7C159C59235DF502D0/)
+
+## Related Artifacts
+- Assessment research: `_docs/00_research/gps_denied_nav_assessment/`
+- Previous AC assessment: `_docs/00_research/gps_denied_visual_nav/00_ac_assessment.md`
+- Previous comparison framework: `_docs/00_research/gps_denied_visual_nav/03_comparison_framework.md`
@@ -0,0 +1,491 @@
+# Solution Draft
+
+## Assessment Findings
+
+
+| Old Component Solution                                           | Weak Point                                                                                                                              | New Solution                                                                                                                                                                                      |
+| ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Pose2 + GPSFactor for satellite anchors                          | **Functional (Critical)**: GPSFactor works with Pose3, not Pose2. Code would fail at runtime. Custom Python DEM/drift factors are slow. | Pose2 + BetweenFactorPose2 (VO) + PriorFactorPose2 (satellite anchors). Remove DEM terrain factor and drift limit factor from graph — handle in GSD calculation and Segment Manager respectively. |
+| DINOv2 model variant unspecified + faiss GPU                     | **Performance/Memory**: No model variant chosen. faiss GPU uses ~2GB scratch. Combined VRAM could exceed 6GB.                           | DINOv2 ViT-S/14 (300MB VRAM, 50ms/img). faiss on CPU only (<1ms for ~2000 vectors). Explicit VRAM budget per model.                                                                               |
+| Heading-based rotation rectification + SIFT fallback             | **Functional**: No heading at segment start. No trigger criteria for SIFT. Multi-rotation matching not specified.                       | Three-tier: (1) segment start → 4-rotation retry {0°,90°,180°,270°}, (2) heading available → rectify, (3) all fail → SIFT+LightGlue. Trigger: SuperPoint inlier ratio < 0.15.                     |
+| "Motion consistent with previous direction" homography selection | **Functional**: Underspecified for 4 decomposition solutions. Non-orthogonal R possible. No strategy for first frame pair.              | Four-step disambiguation: positive depth → plane normal up → motion consistency → orthogonality check via SVD. First pair: depth + normal only.                                                   |
+| Raw DINOv2 CLS token + faiss cosine                              | **Performance**: Raw CLS token suboptimal for retrieval. Patch-level features capture more spatial information.                         | DINOv2 ViT-S/14 patch tokens with spatial average pooling (not just CLS). Cosine similarity via CPU faiss.                                                                                        |
+| "Async satellite matching — don't block VO"                      | **Functional**: No concrete concurrency model. Single GPU can't run two models simultaneously.                                          | Sequential GPU pipeline: VO first (~~40ms), satellite matching overlapped with next frame's VO (~~205ms). asyncio for I/O. CPU for faiss + RANSAC.                                                |
+| JWT + rate limiting + CORS                                       | **Security**: No image format validation. No Pillow CVE-2025-48379 mitigation. No SSE heartbeat. No memory-limited image loading.       | Pin Pillow ≥11.3.0. Validate magic bytes. Reject images >10,000px. SSE heartbeat 15s. asyncio.Queue event publisher. CSP headers.                                                                 |
+| Custom GTSAM drift limit factor                                  | **Functional**: Python callback per optimization step (slow). If no anchors for 50+ frames, nothing to constrain.                       | Replace with Segment Manager drift thresholds: 100m → warning, 200m → user input request, 500m → LOW confidence. Exponential confidence decay from last anchor.                                   |
+| Google Maps tile download (API key only)                         | **Functional**: Google Maps requires session tokens via createSession API, not just API key. 15K/day limit not managed.                 | Implement session token lifecycle: createSession → use token → handle expiry. Request budget tracking per provider per day.                                                                       |
+| FastAPI EventSourceResponse                                      | **Stability**: Async generator cleanup issues on shutdown. No heartbeat. No reconnection support.                                       | asyncio.Queue-based EventPublisher pattern. SSE heartbeat every 15s. Last-Event-ID support for reconnection.                                                                                      |
+
+
+## Product Solution Description
+
+A Python-based GPS-denied visual navigation service that determines GPS coordinates of consecutive UAV photo centers using a hierarchical localization approach: fast visual odometry for frame-to-frame motion, two-stage satellite geo-referencing (coarse retrieval + fine matching) for absolute positioning, and factor graph optimization for trajectory refinement. The system operates as a background REST API service with real-time SSE streaming.
+
+**Core approach**: Consecutive images are matched using XFeat (fast learned features) to estimate relative motion (visual odometry). Each image is geo-referenced against satellite imagery through a two-stage process: DINOv2 ViT-S/14 coarse retrieval selects the best-matching satellite tile using patch-level features, then SuperPoint+LightGlue refines the alignment to pixel precision. A GTSAM iSAM2 factor graph fuses VO constraints (BetweenFactorPose2) and satellite anchors (PriorFactorPose2) in local ENU coordinates to produce an optimized trajectory. The system handles route disconnections by treating each continuous VO chain as an independent segment, geo-referenced through satellite matching and connected via the shared WGS84 coordinate frame.
+
+```
+┌─────────────────────────────────────────────────────────────────────┐
+│                        Client (Desktop App)                         │
+│   POST /jobs (start GPS, camera params, image folder)               │
+│   GET  /jobs/{id}/stream (SSE)                                      │
+│   POST /jobs/{id}/anchor (user manual GPS input)                    │
+│   GET  /jobs/{id}/point-to-gps (image_id, pixel_x, pixel_y)        │
+└──────────────────────┬──────────────────────────────────────────────┘
+                       │ HTTP/SSE (JWT auth)
+┌──────────────────────▼──────────────────────────────────────────────┐
+│                     FastAPI Service Layer                            │
+│   Job Manager → Pipeline Orchestrator → SSE Event Publisher         │
+│   (asyncio.Queue-based publisher, heartbeat, Last-Event-ID)         │
+└──────────────────────┬──────────────────────────────────────────────┘
+                       │
+┌──────────────────────▼──────────────────────────────────────────────┐
+│                     Processing Pipeline                              │
+│                                                                      │
+│  ┌──────────────┐  ┌──────────────┐  ┌─────────────────────────┐   │
+│  │ Image        │  │  Visual      │  │ Satellite Geo-Ref       │   │
+│  │ Preprocessor │→│  Odometry    │→│ Stage 1: DINOv2-S patch  │   │
+│  │ (downscale,  │  │ (XFeat +    │  │   retrieval (CPU faiss)  │   │
+│  │  rectify)    │  │  XFeat      │  │ Stage 2: SuperPoint +   │   │
+│  │              │  │  matcher)   │  │   LightGlue-ONNX refine │   │
+│  └──────────────┘  └──────────────┘  └─────────────────────────┘   │
+│         │                │                       │                   │
+│         ▼                ▼                       ▼                   │
+│  ┌──────────────────────────────────────────────────────────────┐   │
+│  │       GTSAM iSAM2 Factor Graph Optimizer                    │   │
+│  │  Pose2 + BetweenFactorPose2 (VO) + PriorFactorPose2 (sat)  │   │
+│  │  Local ENU coordinates → WGS84 output                       │   │
+│  └──────────────────────────────────────────────────────────────┘   │
+│                              │                                       │
+│  ┌───────────────────────────▼──────────────────────────────────┐   │
+│  │                  Segment Manager                              │   │
+│  │   (drift thresholds, confidence decay, user input triggers)   │   │
+│  └──────────────────────────────────────────────────────────────┘   │
+│                                                                      │
+│  ┌──────────────────────────────────────────────────────────────┐   │
+│  │          Multi-Provider Satellite Tile Cache                  │   │
+│  │  (Google Maps + Mapbox + user tiles, session tokens,          │   │
+│  │   DEM cache, request budgeting)                               │   │
+│  └──────────────────────────────────────────────────────────────┘   │
+└──────────────────────────────────────────────────────────────────────┘
+```
+
+## Architecture
+
+### Component: Image Preprocessor
+
+
+| Solution                       | Tools                | Advantages                                                     | Limitations                             | Requirements  | Security                                           | Performance     | Fit      |
+| ------------------------------ | -------------------- | -------------------------------------------------------------- | --------------------------------------- | ------------- | -------------------------------------------------- | --------------- | -------- |
+| Downscale + rectify + validate | OpenCV resize, NumPy | Normalizes input. Consistent memory. Validates before loading. | Loses fine detail in downscaled images. | OpenCV, NumPy | Magic byte validation, dimension check before load | <10ms per image | **Best** |
+
+
+**Selected**: Downscale + rectify + validate pipeline.
+
+**Preprocessing per image**:
+
+1. Validate file: check magic bytes (JPEG/PNG/TIFF), reject unknown formats
+2. Read image header only: check dimensions, reject if either > 10,000px
+3. Load image via OpenCV (cv2.imread)
+4. Downscale to max 1600 pixels on longest edge (preserving aspect ratio)
+5. Store original resolution for GSD: `GSD = (effective_altitude × sensor_width) / (focal_length × original_width)` where `effective_altitude = flight_altitude - terrain_elevation` (terrain from Copernicus DEM)
+6. If estimated heading is available: rotate to approximate north-up for satellite matching
+7. If no heading (segment start): pass unrotated
+8. Convert to grayscale for feature extraction
+9. Output: downscaled grayscale image + metadata (original dims, GSD, heading if known)
+
+### Component: Feature Extraction
+
+
+| Solution                            | Tools                          | Advantages                                                                                                           | Limitations                                                             | Requirements              | Security                           | Performance          | Fit                    |
+| ----------------------------------- | ------------------------------ | -------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | ------------------------- | ---------------------------------- | -------------------- | ---------------------- |
+| XFeat (for VO)                      | accelerated_features (PyTorch) | 5x faster than SuperPoint. CPU-capable. Has built-in matcher. Semi-dense matching. Used in SatLoc-Fusion.            | Fewer keypoints than SuperPoint in some scenes. Not rotation-invariant. | PyTorch                   | Model weights from official source | ~15ms GPU, ~50ms CPU | **Best for VO**        |
+| SuperPoint (for satellite matching) | superpoint (PyTorch)           | Learned features, robust to viewpoint/illumination. Proven for satellite matching (ISPRS 2025). 256-dim descriptors. | Slower than XFeat. Not rotation-invariant.                              | NVIDIA GPU, PyTorch, CUDA | Model weights from official source | ~80ms GPU            | **Best for satellite** |
+| SIFT (rotation fallback)            | OpenCV cv2.SIFT                | Rotation-invariant. Scale-invariant. Proven SIFT+LightGlue hybrid for UAV mosaicking (ISPRS 2025).                   | Slower. Less discriminative in low-texture.                             | OpenCV                    | N/A                                | ~200ms CPU           | **Rotation fallback**  |
+
+
+**Selected**: XFeat with built-in matcher for VO, SuperPoint for satellite matching, SIFT+LightGlue as rotation-heavy fallback.
+
+**VRAM budget**:
+
+
+| Model                 | VRAM       | Loaded When                |
+| --------------------- | ---------- | -------------------------- |
+| XFeat                 | ~200MB     | Always (VO every frame)    |
+| DINOv2 ViT-S/14       | ~300MB     | Satellite coarse retrieval |
+| SuperPoint            | ~400MB     | Satellite fine matching    |
+| LightGlue ONNX FP16   | ~500MB     | Satellite fine matching    |
+| ONNX Runtime overhead | ~200MB     | When ONNX models active    |
+| **Peak total**        | **~1.6GB** | Satellite matching phase   |
+
+
+### Component: Feature Matching
+
+
+| Solution                           | Tools                   | Advantages                                                                                                    | Limitations                                          | Requirements             | Security                           | Performance           | Fit                    |
+| ---------------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | ------------------------ | ---------------------------------- | --------------------- | ---------------------- |
+| XFeat built-in matcher (VO)        | accelerated_features    | Fastest option (~15ms extract+match). Paired with XFeat extraction.                                           | Lower quality than LightGlue.                        | PyTorch                  | N/A                                | ~15ms total           | **Best for VO**        |
+| LightGlue ONNX FP16 (satellite)    | LightGlue-ONNX          | 2-4x faster than PyTorch via ONNX. FP16 works on Turing (RTX 2060).                                           | FP8 not available on Turing. Not rotation-invariant. | ONNX Runtime, NVIDIA GPU | Model weights from official source | ~50-100ms on RTX 2060 | **Best for satellite** |
+| SIFT+LightGlue (rotation fallback) | OpenCV SIFT + LightGlue | SIFT rotation invariance + LightGlue contextual matching. Proven superior for high-rotation UAV (ISPRS 2025). | Slower than SuperPoint+LightGlue.                    | OpenCV + ONNX Runtime    | N/A                                | ~250ms total          | **Rotation fallback**  |
+
+
+**Selected**: XFeat matcher for VO, LightGlue ONNX FP16 for satellite matching, SIFT+LightGlue as rotation fallback.
+
+### Component: Visual Odometry (Consecutive Frame Matching)
+
+
+| Solution                                     | Tools                                                                         | Advantages                                                                                                  | Limitations                                               | Requirements  | Security | Performance         | Fit      |
+| -------------------------------------------- | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | ------------- | -------- | ------------------- | -------- |
+| Homography VO with essential matrix fallback | OpenCV findHomography (USAC_MAGSAC), findEssentialMat, decomposeHomographyMat | Homography: optimal for flat terrain. Essential matrix: non-planar fallback. Known altitude resolves scale. | Homography assumes planar. 4-way decomposition ambiguity. | OpenCV, NumPy | N/A      | ~5ms for estimation | **Best** |
+
+
+**Selected**: Homography VO with essential matrix fallback and DEM terrain-corrected GSD.
+
+**VO Pipeline per frame**:
+
+1. Extract XFeat features from current image (~15ms)
+2. Match with previous image using XFeat built-in matcher (included in extraction time)
+3. **Triple failure check**: match count ≥ 30 AND RANSAC inlier ratio ≥ 0.4 AND motion magnitude consistent with expected inter-frame distance (100m ± 250m)
+4. If checks pass → estimate homography (cv2.findHomography with USAC_MAGSAC, confidence 0.999, max iterations 2000)
+5. If RANSAC inlier ratio < 0.6 → additionally estimate essential matrix as quality check
+6. **Decomposition disambiguation** (4 solutions from decomposeHomographyMat):
+  a. Filter by positive depth: triangulate 5 matched points, reject if behind camera
+   b. Filter by plane normal: normal z-component > 0.5 (downward camera → ground plane normal points up)
+   c. If previous direction available: prefer solution consistent with expected motion
+   d. Orthogonality check: verify R^T R ≈ I (Frobenius norm < 0.01). If failed, re-orthogonalize via SVD: U,S,V = svd(R), R_clean = U @ V^T
+   e. First frame pair in segment: use filters a+b only
+7. **Terrain-corrected GSD**: query Copernicus DEM at estimated position → `effective_altitude = flight_altitude - terrain_elevation` → `GSD = (effective_altitude × sensor_width) / (focal_length × original_image_width)`
+8. Convert pixel displacement to meters: `displacement_m = displacement_px × GSD`
+9. Update position: `new_pos = prev_pos + rotation @ displacement_m`
+10. Track cumulative heading for image rectification
+11. If triple failure check fails → trigger segment break
+
+### Component: Satellite Image Geo-Referencing (Two-Stage)
+
+
+| Solution                                 | Tools                                  | Advantages                                                                                                                       | Limitations                                                  | Requirements          | Security                           | Performance                 | Fit             |
+| ---------------------------------------- | -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | --------------------- | ---------------------------------- | --------------------------- | --------------- |
+| Stage 1: DINOv2 ViT-S/14 patch retrieval | dinov2 ViT-S/14 (PyTorch), faiss (CPU) | Fast (50ms). 300MB VRAM. Patch tokens capture spatial layout better than CLS alone. Semantic matching robust to seasonal change. | Coarse only (~tile-level). Lower precision than ViT-B/ViT-L. | PyTorch, faiss-cpu    | Model weights from official source | ~50ms extract + <1ms search | **Best coarse** |
+| Stage 2: SuperPoint+LightGlue ONNX FP16  | SuperPoint, LightGlue-ONNX, OpenCV     | Precise pixel-level alignment. Proven on satellite benchmarks. FP16 on RTX 2060.                                                 | Needs rough pose for warping. Not rotation-invariant.        | PyTorch, ONNX Runtime | N/A                                | ~150ms total                | **Best fine**   |
+
+
+**Selected**: Two-stage hierarchical matching.
+
+**Satellite Matching Pipeline**:
+
+1. Estimate approximate position from VO
+2. **Stage 1 — Coarse retrieval**:
+  a. Define search area: 500m radius around VO estimate (expand to 1km if segment just started or drift > 100m)
+   b. Pre-compute DINOv2 ViT-S/14 patch embeddings for all satellite tiles in search area. Method: extract patch tokens (not CLS), apply spatial average pooling to get a single descriptor per tile. Cache embeddings.
+   c. Extract DINOv2 ViT-S/14 patch embedding from UAV image (same pooling)
+   d. Find top-5 most similar satellite tiles using faiss (CPU) cosine similarity
+3. **Stage 2 — Fine matching** (on top-5 tiles, stop on first good match):
+  a. Warp UAV image to approximate nadir view using estimated camera pose
+   b. **Rotation handling**:
+      - If heading known: single attempt with rectified image
+      - If no heading (segment start): try 4 rotations {0°, 90°, 180°, 270°}
+   c. Extract SuperPoint features from warped UAV image
+   d. Extract SuperPoint features from satellite tile (pre-computed and cached)
+   e. Match with LightGlue ONNX FP16
+   f. **Geometric validation**: require ≥15 inliers, inlier ratio ≥ 0.3, reprojection error < 3px
+   g. If valid: estimate homography → transform image center → satellite pixel → WGS84
+   h. Report: absolute position anchor with confidence based on match quality
+4. If all 5 tiles fail Stage 2 with SuperPoint:
+  a. Try SIFT+LightGlue on top-3 tiles (rotation-invariant). Trigger: best SuperPoint inlier ratio was < 0.15.
+   b. Try zoom level 17 (wider view)
+5. If still fails: mark frame as VO-only, reduce confidence, continue
+
+**Satellite matching frequency**: Every frame when available, but async — satellite matching for frame N overlaps with VO processing for frame N+1. Satellite result arrives and gets added to factor graph retroactively via iSAM2 update.
+
+### Component: GTSAM Factor Graph Optimizer
+
+
+| Solution                         | Tools            | Advantages                                                                                                                                                  | Limitations                               | Requirements      | Security | Performance                | Fit      |
+| -------------------------------- | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------- | ----------------- | -------- | -------------------------- | -------- |
+| GTSAM iSAM2 factor graph (Pose2) | gtsam==4.2 (pip) | Incremental smoothing. Proper uncertainty propagation. Native BetweenFactorPose2 and PriorFactorPose2. Backward smoothing on new evidence. Python bindings. | C++ backend (pip binary). Learning curve. | gtsam==4.2, NumPy | N/A      | ~5-10ms incremental update | **Best** |
+
+
+**Selected**: GTSAM iSAM2 with Pose2 variables.
+
+**Coordinate system**: Local East-North-Up (ENU) centered on starting GPS. All positions computed in ENU meters, converted to WGS84 for output. Conversion: pyproj or manual geodetic math (WGS84 ellipsoid).
+
+**Factor graph structure**:
+
+- **Variables**: Pose2 (x_enu, y_enu, heading) per image
+- **Prior Factor** (PriorFactorPose2): first frame anchored at ENU origin (0, 0, initial_heading) with tight noise (sigma_xy = 5m if GPS accurate, sigma_theta = 0.1 rad)
+- **VO Factor** (BetweenFactorPose2): relative motion between consecutive frames. Noise model: `Diagonal.Sigmas([sigma_x, sigma_y, sigma_theta])` where sigma scales inversely with RANSAC inlier ratio. High inlier ratio (0.8) → sigma 2m. Low inlier ratio (0.4) → sigma 10m. Sigma_theta proportional to displacement magnitude.
+- **Satellite Anchor Factor** (PriorFactorPose2): absolute position from satellite matching. Position noise: `sigma = reprojection_error × GSD × scale_factor`. Good match (0.5px × 0.4m/px × 3) = 0.6m. Poor match = 5-10m. Heading component: loose (sigma = 1.0 rad) unless estimated from satellite alignment.
+
+**Optimizer behavior**:
+
+- On each new frame: add VO factor, run iSAM2.update() → ~5ms
+- On satellite match arrival: add PriorFactorPose2, run iSAM2.update() → backward correction
+- Emit updated positions via SSE after each update
+- Refinement events: when backward correction moves positions by >1m, emit "refined" SSE event
+- No custom Python factors — all factors use native GTSAM C++ implementations for speed
+
+### Component: Segment Manager
+
+The segment manager tracks independent VO chains, manages drift thresholds, and handles reconnection.
+
+**Segment lifecycle**:
+
+1. **Start condition**: First image, OR VO triple failure check fails
+2. **Active tracking**: VO provides frame-to-frame motion within segment
+3. **Anchoring**: Satellite two-stage matching provides absolute position
+4. **End condition**: VO failure (sharp turn, outlier >350m, occlusion)
+5. **New segment**: Starts, attempts satellite anchor immediately
+
+**Segment states**:
+
+- `ANCHORED`: At least one satellite match → HIGH confidence
+- `FLOATING`: No satellite match yet → positioned relative to segment start → LOW confidence
+- `USER_ANCHORED`: User provided manual GPS → MEDIUM confidence
+
+**Drift monitoring (replaces GTSAM custom drift factor)**:
+
+- Track cumulative VO displacement since last satellite anchor per segment
+- **100m threshold**: emit warning SSE event, expand satellite search radius to 1km, increase matching attempts per frame
+- **200m threshold**: emit `user_input_needed` SSE event with configurable timeout (default: 30s)
+- **500m threshold**: mark all subsequent positions as VERY LOW confidence, continue processing
+- **Confidence formula**: `confidence = base_confidence × exp(-drift / decay_constant)` where base_confidence is from satellite match quality, drift is distance from nearest anchor, decay_constant = 100m
+
+**Segment reconnection**:
+
+- When a segment becomes ANCHORED, check for nearby FLOATING segments (within 500m of any anchored position)
+- Attempt satellite-based position matching between FLOATING segment images and tiles near the ANCHORED segment
+- DEM consistency: verify segment elevation profile is consistent with terrain
+- If no match after all frames tried: request user input, auto-continue after timeout
+
+### Component: Multi-Provider Satellite Tile Cache
+
+
+| Solution                                  | Tools                                 | Advantages                                                                                                         | Limitations                               | Requirements                            | Security                                                      | Performance         | Fit      |
+| ----------------------------------------- | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ----------------------------------------- | --------------------------------------- | ------------------------------------------------------------- | ------------------- | -------- |
+| Multi-provider progressive cache with DEM | aiohttp, aiofiles, sqlite3, faiss-cpu | Multiple providers. Async download. DINOv2/SuperPoint features pre-computed. DEM cached. Session token management. | Needs internet. Provider API differences. | Google Maps Tiles API + Mapbox API keys | API keys in env vars only. Session tokens managed internally. | Async, non-blocking | **Best** |
+
+
+**Selected**: Multi-provider progressive cache.
+
+**Provider priority**:
+
+1. User-provided tiles (highest priority — custom/recent imagery)
+2. Google Maps (zoom 18, ~0.4m/px) — 100K free requests/month, 15K/day
+3. Mapbox Satellite (zoom 16-18, ~0.6-0.3m/px) — 200K free requests/month
+
+**Google Maps session management**:
+
+1. On job start: POST to `/v1/createSession` with API key → receive session token
+2. Use session token in all subsequent tile requests for this job
+3. Token has finite lifetime — handle expiry by creating new session
+4. Track request count per day per provider
+
+**Cache strategy**:
+
+1. On job start: download tiles in 1km radius around starting GPS from primary provider
+2. Pre-compute SuperPoint features AND DINOv2 ViT-S/14 patch embeddings for all cached tiles
+3. As route extends: download tiles 500m ahead of estimated position
+4. **Request budgeting**: track daily API requests per provider. At 80% daily limit (12,000 for Google): switch to Mapbox. Log budget status.
+5. Cache structure on disk:
+  ```
+   cache/
+   ├── tiles/{provider}/{zoom}/{x}/{y}.jpg
+   ├── features/{provider}/{zoom}/{x}/{y}_sp.npz     (SuperPoint features)
+   ├── embeddings/{provider}/{zoom}/{x}/{y}_dino.npy  (DINOv2 patch embedding)
+   └── dem/{lat}_{lon}.tif                            (Copernicus DEM tiles)
+  ```
+6. Cache persistent across jobs — tiles and features reused for overlapping areas
+7. **DEM cache**: Copernicus DEM GLO-30 tiles from AWS S3 (free, no auth). `s3://copernicus-dem-30m/`. Cloud Optimized GeoTIFFs, 30m resolution. Downloaded via HTTPS (no AWS SDK needed): `https://copernicus-dem-30m.s3.amazonaws.com/Copernicus_DSM_COG_10_{N|S}{lat}_00_{E|W}{lon}_DEM/...`
+
+**Tile download budget**:
+
+- Google Maps: 100,000/month, 15,000/day → ~7 flights/day from cache misses, ~50 flights/month
+- Mapbox: 200,000/month → additional ~100 flights/month
+- Per flight: ~~2000 satellite tiles (~~80MB) + ~~200 DEM tiles (~~10MB)
+
+### Component: API & Real-Time Streaming
+
+
+| Solution                          | Tools                                                 | Advantages                                                                                           | Limitations                          | Requirements          | Security                              | Performance         | Fit      |
+| --------------------------------- | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------ | --------------------- | ------------------------------------- | ------------------- | -------- |
+| FastAPI + SSE (Queue-based) + JWT | FastAPI ≥0.135.0, asyncio.Queue, uvicorn, python-jose | Native SSE. Queue-based publisher avoids generator cleanup issues. JWT auth. OpenAPI auto-generated. | Python GIL (mitigated with asyncio). | Python 3.11+, uvicorn | JWT, CORS, rate limiting, CSP headers | Async, non-blocking | **Best** |
+
+
+**Selected**: FastAPI + Queue-based SSE + JWT authentication.
+
+**SSE implementation**:
+
+- Use `asyncio.Queue` per client connection (not bare async generators)
+- Server pushes events to queue; client reads from queue
+- On disconnect: queue is garbage collected, no lingering generators
+- SSE heartbeat: send `event: heartbeat` every 15 seconds to detect stale connections
+- Support `Last-Event-ID` header for reconnection: include monotonic event ID in each SSE message. On reconnect, replay missed events from in-memory ring buffer (last 1000 events per job).
+
+**API Endpoints**:
+
+```
+POST /auth/token
+  Body: { api_key }
+  Returns: { access_token, token_type, expires_in }
+
+POST /jobs
+  Headers: Authorization: Bearer <token>
+  Body: { start_lat, start_lon, altitude, camera_params, image_folder }
+  Returns: { job_id }
+
+GET /jobs/{job_id}/stream
+  Headers: Authorization: Bearer <token>
+  SSE stream of:
+    - { event: "position", id: "42", data: { image_id, lat, lon, confidence, segment_id } }
+    - { event: "refined", id: "43", data: { image_id, lat, lon, confidence, delta_m } }
+    - { event: "segment_start", id: "44", data: { segment_id, reason } }
+    - { event: "drift_warning", id: "45", data: { segment_id, cumulative_drift_m } }
+    - { event: "user_input_needed", id: "46", data: { image_id, reason, timeout_s } }
+    - { event: "heartbeat", id: "47", data: { timestamp } }
+    - { event: "complete", id: "48", data: { summary } }
+
+POST /jobs/{job_id}/anchor
+  Headers: Authorization: Bearer <token>
+  Body: { image_id, lat, lon }
+
+GET /jobs/{job_id}/point-to-gps?image_id=X&px=100&py=200
+  Headers: Authorization: Bearer <token>
+  Returns: { lat, lon, confidence }
+
+GET /jobs/{job_id}/results?format=geojson
+  Headers: Authorization: Bearer <token>
+  Returns: full results as GeoJSON or CSV (WGS84)
+```
+
+**Security measures**:
+
+- JWT authentication on all endpoints (short-lived tokens, 1h expiry)
+- Image folder whitelist: resolve to canonical path (os.path.realpath), verify under configured base directories
+- Image validation: magic byte check (JPEG FFD8, PNG 89504E47, TIFF 4949/4D4D), dimension check (<10,000px per side), reject others
+- Pin Pillow ≥11.3.0 (CVE-2025-48379 mitigation)
+- Max concurrent SSE connections per client: 5
+- Rate limiting: 100 requests/minute per client
+- All provider API keys in environment variables, never logged or returned
+- CORS configured for known client origins only
+- Content-Security-Policy headers
+- SSE heartbeat prevents stale connections accumulating
+
+### Component: Interactive Point-to-GPS Lookup
+
+For each processed image, the system stores the estimated camera-to-ground transformation. Given pixel coordinates (px, py):
+
+1. If image has satellite match: use computed homography to project (px, py) → satellite tile coordinates → WGS84. HIGH confidence.
+2. If image has only VO pose: use camera intrinsics + DEM-corrected altitude + estimated heading to ray-cast (px, py) to ground plane → WGS84. MEDIUM confidence.
+3. Confidence score derived from underlying position estimate quality.
+
+## Processing Time Budget
+
+
+| Step                   | Component                                | Time           | GPU/CPU | Notes                               |
+| ---------------------- | ---------------------------------------- | -------------- | ------- | ----------------------------------- |
+| 1                      | Image load + validate + downscale        | <10ms          | CPU     | OpenCV                              |
+| 2                      | XFeat extract + match (VO)               | ~15ms          | GPU     | Built-in matcher                    |
+| 3                      | Homography estimation + decomposition    | ~5ms           | CPU     | USAC_MAGSAC                         |
+| 4                      | GTSAM iSAM2 update (VO factor)           | ~5ms           | CPU     | Incremental                         |
+| 5                      | SSE position emit                        | <1ms           | CPU     | Queue push                          |
+| **VO subtotal**        |                                          | **~36ms**      |         | **Per-frame critical path**         |
+| 6                      | DINOv2 ViT-S/14 extract (UAV image)      | ~50ms          | GPU     | Patch tokens                        |
+| 7                      | faiss cosine search (top-5 tiles)        | <1ms           | CPU     | ~2000 vectors                       |
+| 8                      | SuperPoint extract (UAV warped)          | ~80ms          | GPU     |                                     |
+| 9                      | LightGlue ONNX match (per tile, up to 5) | ~50-100ms      | GPU     | Stop on first good match            |
+| 10                     | Geometric validation + homography        | ~5ms           | CPU     |                                     |
+| 11                     | GTSAM iSAM2 update (satellite factor)    | ~5ms           | CPU     | Backward correction                 |
+| **Satellite subtotal** |                                          | **~191-236ms** |         | **Overlapped with next frame's VO** |
+| **Total per frame**    |                                          | **~230-270ms** |         | **Well under 5s budget**            |
+
+
+## Testing Strategy
+
+### Integration / Functional Tests
+
+- End-to-end pipeline test using provided 60-image sample dataset with ground truth GPS
+- Verify 80% of positions within 50m of ground truth
+- Verify 60% of positions within 20m of ground truth
+- Test sharp turn handling: simulate 90° turn with non-overlapping images
+- Test segment creation, satellite anchoring, and cross-segment reconnection
+- Test user manual anchor injection via POST endpoint
+- Test point-to-GPS lookup accuracy against known ground coordinates
+- Test SSE streaming delivers results within 1s of processing completion
+- Test with FullHD resolution images (pipeline must not fail)
+- Test with 6252×4168 images (verify downscaling and memory usage)
+- Test DINOv2 ViT-S/14 coarse retrieval finds correct satellite tile with 100m VO drift
+- Test multi-provider fallback: block Google Maps, verify Mapbox takes over
+- Test with outdated satellite imagery: verify confidence scores reflect match quality
+- Test outlier handling: 350m gap between consecutive photos
+- Test image rotation handling: apply 45° and 90° rotation, verify 4-rotation retry works
+- Test SIFT+LightGlue fallback triggers when SuperPoint inlier ratio < 0.15
+- Test GTSAM PriorFactorPose2 satellite anchoring produces backward correction
+- Test drift warning at 100m cumulative displacement without satellite anchor
+- Test user_input_needed event at 200m cumulative displacement
+- Test SSE heartbeat arrives every 15s during long processing
+- Test SSE reconnection with Last-Event-ID replays missed events
+- Test homography decomposition disambiguation for first frame pair (no previous direction)
+
+### Non-Functional Tests
+
+- Processing speed: <5s per image on RTX 2060 (target <300ms with ONNX optimization)
+- Memory: peak RAM <16GB, VRAM <6GB during 3000-image flight at max resolution
+- VRAM: verify peak stays under 2GB during satellite matching phase
+- Memory stability: process 3000 images, verify no memory leak (stable RSS over time)
+- Concurrent jobs: 2 simultaneous flights, verify isolation and resource sharing
+- Tile cache: verify tiles, SuperPoint features, and DINOv2 embeddings cached and reused
+- API: load test SSE connections (10 simultaneous clients)
+- Recovery: kill and restart service mid-job, verify job can resume from last processed image
+- DEM download: verify Copernicus DEM tiles fetched from AWS S3 and cached correctly
+- GTSAM optimizer: verify backward correction produces "refined" events
+- Session token lifecycle: verify Google Maps session creation, usage, and expiry handling
+
+### Security Tests
+
+- JWT authentication enforcement on all endpoints
+- Expired/invalid token rejection
+- Provider API keys not exposed in responses, logs, or error messages
+- Image folder path traversal prevention (attempt to access /etc/passwd via image_folder)
+- Image folder whitelist enforcement (canonical path resolution)
+- Image magic byte validation: reject non-image files renamed to .jpg
+- Image dimension validation: reject >10,000px images
+- Input validation: invalid GPS coordinates, negative altitude, malformed camera params
+- Rate limiting: verify 429 response after exceeding limit
+- Max SSE connection enforcement
+- CORS enforcement: reject requests from unknown origins
+- Content-Security-Policy header presence
+- Pillow version ≥11.3.0 verified in requirements
+
+## References
+
+- [YFS90/GNSS-Denied-UAV-Geolocalization](https://github.com/YFS90/GNSS-Denied-UAV-Geolocalization) — <7m MAE with terrain-weighted constraint optimization
+- [SatLoc-Fusion (2025)](https://www.mdpi.com/2072-4292/17/17/3048) — hierarchical DINOv2+XFeat+optical flow, <15m on edge hardware
+- [CEUSP (2025)](https://arxiv.org/abs/2502.11408) — DINOv2-based cross-view UAV self-positioning
+- [DINOv2 UAV Self-Localization (2025)](https://ui.adsabs.harvard.edu/abs/2025IRAL...10.2080Y/) — 86.27 R@1 on DenseUAV
+- [XFeat (CVPR 2024)](https://github.com/verlab/accelerated_features) — 5x faster than SuperPoint
+- [XFeat+LightGlue (HuggingFace)](https://huggingface.co/vismatch/xfeat-lightglue) — trained xfeat-lightglue models
+- [LightGlue-ONNX](https://github.com/fabio-sim/LightGlue-ONNX) — 2-4x speedup via ONNX/TensorRT, FP16 on Turing
+- [SIFT+LightGlue UAV Mosaicking (ISPRS 2025)](https://isprs-archives.copernicus.org/articles/XLVIII-2-W11-2025/169/2025/) — SIFT superior for high-rotation conditions
+- [LightGlue rotation issue #64](https://github.com/cvg/LightGlue/issues/64) — confirmed not rotation-invariant
+- [DALGlue (2025)](https://www.nature.com/articles/s41598-025-21602-5) — 11.8% MMA improvement over LightGlue for UAV
+- [SALAD: DINOv2 Optimal Transport Aggregation (2024)](https://arxiv.org/abs/2311.15937) — improved visual place recognition
+- [NaviLoc (2025)](https://www.mdpi.com/2504-446X/10/2/97) — trajectory-level optimization, 19.5m MLE, 16x improvement
+- [GTSAM v4.2](https://github.com/borglab/gtsam) — factor graph optimization with Python bindings
+- [GTSAM GPSFactor docs](https://gtsam.org/doxygen/a04084.html) — GPSFactor works with Pose3 only
+- [GTSAM Pose2 SLAM Example](https://gtbook.github.io/gtsam-examples/Pose2SLAMExample.html) — BetweenFactorPose2 + PriorFactorPose2
+- [OpenCV decomposeHomographyMat issue #23282](https://github.com/opencv/opencv/issues/23282) — non-orthogonal matrices, 4-solution ambiguity
+- [Copernicus DEM GLO-30 on AWS](https://registry.opendata.aws/copernicus-dem/) — free 30m global DEM, no auth via S3
+- [Google Maps Tiles API](https://developers.google.com/maps/documentation/tile/satellite) — satellite tiles, 100K free/month, session tokens required
+- [Google Maps Tiles API billing](https://developers.google.com/maps/documentation/tile/usage-and-billing) — 15K/day, 6K/min rate limits
+- [Mapbox Satellite](https://docs.mapbox.com/data/tilesets/reference/mapbox-satellite/) — alternative tile provider, up to 0.3m/px regional
+- [FastAPI SSE](https://fastapi.tiangolo.com/tutorial/server-sent-events/) — EventSourceResponse
+- [SSE-Starlette cleanup issue #99](https://github.com/sysid/sse-starlette/issues/99) — async generator cleanup, Queue pattern recommended
+- [CVE-2025-48379 Pillow](https://nvd.nist.gov/vuln/detail/CVE-2025-48379) — heap buffer overflow, fixed in 11.3.0
+- [FAISS GPU wiki](https://github.com/facebookresearch/faiss/wiki/Faiss-on-the-GPU) — ~2GB scratch space default, CPU recommended for small datasets
+- [Oblique-Robust AVL (IEEE TGRS 2024)](https://ieeexplore.ieee.org/iel7/36/10354519/10356107.pdf) — rotation-equivariant features for UAV-satellite matching
+
+## Related Artifacts
+
+- Previous assessment research: `_docs/00_research/gps_denied_nav_assessment/`
+- This assessment research: `_docs/00_research/gps_denied_draft02_assessment/`
+- Previous AC assessment: `_docs/00_research/gps_denied_visual_nav/00_ac_assessment.md`
+