GEO Area Pipeline · OpenTopo / OsmAnd
Lokale Kartenpakete und nachvollziehbare Gebietsdefinitionen: WGS84-BBoxes, OpenTopoMap-XYZ-Tiles, OsmAnd-SQLite und validierter Area-Import in Map Geometry.
Problem
Ausgangslage
Downloadabdeckung, lokale Kartencontainer und metrische Analysegebiete werden leicht verwechselt. Gebiete müssen reproduzierbar definiert und importiert werden, ohne fremde Projektobjekte oder ihre Herkunft zu überschreiben.
Constraints
Randbedingungen
- Strikte WGS84-BBox-/Zoomvalidierung und Tilebudget
- Providerrechte und Attribution; keine Offline-Erlaubnis durch bloßes Rate-Limit
- Getrennte Tile- und Geometrieausgaben
- Expliziter Analyseursprung und konservative 249-km-Vorprüfung
- Dry-Run, Backup, stabile Objektidentitäten und idempotente Updates
Solution
Lösung
Eine Standardbibliothek-Python-Pipeline definiert Gebiete, plant Rasterpakete und prüft SQLite-/PNG-Bestände. Ein separater Export überführt BBoxes als geografische WGS84-Polygone in den Map-geometry-v1-Vertrag; das gespeicherte JSON wird manuell in Map Geometry importiert. Tilepakete und Browser-Tilecache bleiben unabhängig.
Architecture
Architektur
- regions.json: BBox / Zoom / Tilebudget
- XYZ → SQLite .sqlitedb für OsmAnd
- Resume mit Build-Vertrag / read-only Paketprüfung
- WGS84-Polygonexport mit BBox-/Zoom-Provenienz
- Map-geometry-v1-Validierung / stabiler Quellschlüssel
- Optionaler expliziter Auto-Origin / AEQD-Reichweitengate
- Atomare JSON-Writes / geprüfte Backups / Paketmanifest
Result
Resultat
Der BBox-Export und der kontrollierte Ursprungwechsel sind lokal implementiert. Der Auto-Origin-Bericht vom 10.10.2026 dokumentiert 75 Tests und Gegenprüfung mit der Map-Geometry-Engine; diese Prüfungen werden hier berichtet, nicht erneut ausgeführt. Die .sqlitedb wird nicht direkt von Map Geometry gelesen. Weitere Geo-/ROS-Adapter sind Integrationsmöglichkeiten, keine nachgewiesene durchgehende Datenleitung; ein aktueller OsmAnd-Zielgerätetest fehlt.