Wetterdienst

docker/README.md

@@ -7,7 +7,8 @@ cd docker
 JWT_SECRET=<zufälliger-langer-string> docker compose up -d
 ```
 
-Alle Server-Daten (Ereignis-Logs, Snapshots, Anhänge, Nutzer) liegen im Named Volume `api-data` –
+Alle Server-Daten (Ereignis-Logs, Snapshots, Anhänge, Nutzer, Schulstandorte und Wetter-Cache)
+liegen im Named Volume `api-data` –
 bei Neustarts/Updates bleibt es erhalten. Bewusst **kein** Bind-Mount auf einen Host-Pfad: bei
 Git-basierten Deployments (z. B. Dokploy) wird das Checkout-Verzeichnis bei jedem Redeploy neu
 geklont, ein dort liegendes `./data` wäre dabei jedes Mal leer (siehe TODO.md 10.2.4 für den
@@ -74,6 +75,16 @@ Endpunkte sind zusätzlich global auf 120 Anfragen pro Minute je IP begrenzt. An
 15 MB Anfragegröße gedeckelt (Kestrel `MaxRequestBodySize`), einzelne Dateien clientseitig
 zusätzlich auf 10 MB (`IAttachmentStorage.MaxSizeBytes`).
 
+## Schulstandort und Wetter
+
+Die authentifizierten Endpunkte unter `/api/school` geocodieren eine Schuladresse einmalig über
+Nominatim/OpenStreetMap und laden danach ausschließlich mit den ermittelten Koordinaten
+MOSMIX-Vorhersagen und CAP-Warnungen des DWD. Ergebnisse werden gecacht; bei einem vorübergehenden
+DWD-Ausfall liefert der Server den letzten erfolgreichen Stand. Für eine eigene Installation sollte
+`GEOCODING_USER_AGENT` auf eine Kennung mit eigener Kontakt-Webseite gesetzt werden, beispielsweise
+`LehrerApp-Server/1.0 (+https://schule.example)`. Der Container benötigt ausgehenden HTTPS-Zugriff
+auf `nominatim.openstreetmap.org`, `www.dwd.de` und `opendata.dwd.de`.
+
 ## Deployment über Dokploy
 
 Kein manuelles Bauen/Hochladen nötig – Dokploy zieht das Repo direkt per Git und baut das Image