atmrOS

Das ehrliche ctOS. Eine dunkle Karte Bayerns, die offene Geodaten zu einer Infrastruktur-Ebene verschmilzt — mit Gedächtnis, und jede Anzeige nennt ihre Quelle.

---

Was ist atmrOS?

Wie das ctOS aus Watch Dogs — nur ehrlich. atmrOS legt die unsichtbare Verkabelung einer Region als ein Gesamtbild auf eine dunkle Karte: Sendemasten, Strommasten, Umspannwerke, Ladesäulen, Überwachungskameras, Türme, Tankstellen. Kein Single-Purpose-Finder, sondern die Verknüpfung vieler offener Quellen zu einer Ebene.

Drei Dinge machen es aus:

• Eine Ebene. Verschiedene Objekttypen aus OpenStreetMap, verschmolzen und gemeinsam filterbar — nicht sieben getrennte Apps.
• Mit Gedächtnis. Es wird nie ein Zustand gespeichert, sondern immer Beobachtungen mit Zeitstempel. Daraus fallen Live-Ansicht, Archiv und Änderungen über Zeit (NEU / GEÄNDERT / GELÖSCHT / WIEDER) aus einer Tabelle.
• Ehrlich. Jedes Objekt trägt im Profiler-Panel seine Quelle + Stand-Datum und einen Deep-Link zurück zu OpenStreetMap. Und es misst nur Systeme, nie Menschen — eine Überwachungskamera ist ein Objekt; wer gefilmt wird, ist es nie.

Ehrlichkeit im Detail: Ein Kirchturm läuft hier nicht als „Sendemast" durch. man_made=tower/mast und power=substation sind zu grob, deshalb erfasst atmrOS den Untertyp (tower:type, substation) und macht ihn filterbar — Kirch-/Wehrtürme, Ortsnetzstationen usw. sind klar getrennt.

Die Kette

Das Herzstück ist eine lückenlose Pipeline:

1. SAMMELN     Geofabrik Bayern-PBF laden (Last-Modified-gesteuert)
2. FILTERN     relevante Objekttypen extrahieren (osmium)
3. ROHLAGER    gefilterte Objekte als Parquet + SHA-256-Manifest (unantastbar)
4. SPEICHERN   als zeitgestempelte Beobachtungen in PostGIS
5. VERKNÜPFEN  alle Objekte in EINER Ebene
6. ERINNERN    Diff gegen letzten Scan → change_event
7. ZEIGEN      dunkle Vektorkarte, Klick → Profiler-Panel mit Quelle

Architektur

Dienst	Rolle
pipeline (Python + osmium)	SAMMELN · FILTERN · ROHLAGER · SPEICHERN · ERINNERN
db (PostgreSQL 16 + PostGIS 3.4)	object / observation / change_event
api (FastAPI)	Vektor-Tiles via ST_AsMVT, Objekt-Panel, Stats, Änderungen
web (Astro SSR + MapLibre GL)	dunkle Karte, Filter-Legende, Profiler-Panel, Änderungsansicht

pipeline/   Ingest (osmium) + Diff-Logik + Rohlager
db/init/    Kernschema
api/app/    FastAPI-Endpunkte
web/src/    Astro-Seiten + MapLibre-Logik
deploy/     systemd-Timer für den Nightly-Ingest
docs/       DEPLOY.md · BASEMAP.md

Schnellstart

Voraussetzung: Docker + Docker Compose.

cp .env.example .env      # Secrets erzeugen (siehe Kommentare in der Datei)
docker compose up -d db api web
docker compose run --rm ingest        # einmal die ganze Kette laufen lassen

Standardmäßig ist ein Login-Gate aktiv (ATMROS_LAUNCHED=false) → man sieht eine Coming-soon-Seite; über /unlock mit Passwort kommt man an die App. Vollständige Anleitung (Reverse-Proxy, Timer, TLS): docs/DEPLOY.md.

API-Endpunkte

Endpunkt	Zweck
GET /tiles/{z}/{x}/{y}.pbf	Mapbox Vector Tile (ST_AsMVT), nur sichtbare Objekte
GET /object/{osm_type}/{osm_id}	Panel-Daten inkl. Historie + Quelle
GET /stats	Counts pro Kategorie und Untertyp + aktueller Stand
GET /changes?since=	Änderungen (change_event) für die Änderungsansicht
GET /status	ob gerade ein Ingest läuft
GET /health	Liveness

Datenmodell — ein Modell, drei Ansichten

Eine neue observation-Zeile entsteht nur, wenn sich der Attribut-Hash gegenüber der letzten Beobachtung ändert. Re-Runs desselben Extrakts erzeugen also keine Dubletten. Verschwundene Objekte werden nicht gelöscht, sondern als abwesend markiert (present=false) — kommt ein Objekt zurück, ist das ein WIEDER-Ereignis.

• Live = neueste Beobachtung je Objekt (nur präsente)
• Archiv = alle Beobachtungen über Zeit
• Änderungen = Differenz zweier aufeinanderfolgender Scans

Datenquellen & Lizenz

• Geodaten: OpenStreetMap via Geofabrik (Bayern-Extrakt). Lizenz ODbL — „© OpenStreetMap-Mitwirkende". Diese Namensnennung ist in der App eingebaut und bei jeder Weiterverwendung erforderlich.
• Basemap: selbst gehostete Protomaps-Kacheln (.pmtiles), Style im Repo unter web/public/basemap/. Siehe docs/BASEMAP.md.

Grundregeln (nicht verhandelbar)

1. Systeme messen, niemals Menschen. Nur Infrastruktur-Objekte, keine Personendaten.
2. Jede Anzeige trägt ihre Quelle + Stand-Datum. Die Kern-Signatur des Projekts.
3. Das Rohlager ist unantastbar. Einmal geschrieben, nie verändert — SHA-256-Kette als Beweis.
4. Lückenlosigkeit vor Features. Der Ingest schreibt in einer Transaktion; bei Fehler bricht die Kette sauber ab, statt halb zu committen.

Status

Schritt 1 – die Kette läuft. ✅ Real gegen das volle Bayern-PBF verifiziert (94.780 Objekte). Karte, Filter, Profiler-Panel mit Quelle.

Schritt 2 – Gedächtnis & Automatik. ✅

• Diff-Logik (change_event: NEU/GEÄNDERT/GELÖSCHT/WIEDER) + present-Modell
• Änderungsansicht (/changes, Liste + Pink-Highlight auf der Karte)
• Last-Modified-gesteuerter Nightly-Ingest (systemd-Timer, holt nur bei neuem Stand)
• „Daten werden aktualisiert"-Banner + „neuer Stand"-Toast (kein Reload nötig)

Denkbar als Nächstes: Archiv-/Zeitreise-Ansicht, Zweitquellen andocken (Bundesnetzagentur-EMF, OpenChargeMap-Anreicherung), Dichte-/Heatmap-Verdichtung.

Über

Eine Fähigkeit von MultaEnhavo. Design: Dark, technisch, ctOS-Anmutung — lesbar und ernst, kein Glitch-Cosplay. Die Akzentfarbe Pink markiert echte Auffälligkeiten (NEU/GEÄNDERT), nicht als Dauer-Deko.

Lizenz: Geodaten © OpenStreetMap-Mitwirkende (ODbL). Der Projektcode steht unter der vom Betreiber gewählten Lizenz (siehe LICENSE, falls vorhanden).