banyaro/docs/OFFLINE_MAPS_PLAN.md

Offline-Karten (GL/Vektor) — Feature-Plan

Status: LIVE auf Production + Staging (Default AN auf banyaro.app/.de, Prod-Freigabe René 2026-06-07 nach bestandenen Gerätetests Runde 1+2). localhost = Leaflet/AUS. Stand: 2026-06-07. Autor: René + Claude (Design).

Umsetzungsstand (2026-06-06, v1222 auf Staging)

✅ Fertig + headless bewiesen (2026-06-05, v1213):

• map-offline.js (window.MapOffline): Region-Download (downloadAround(lat,lon,radiusKm)) → Vektorkacheln z0–14 via pmtiles.getZxy (liefert bereits dekomprimierte MVT) + Glyphs in IndexedDB (by-offline-tiles). byt://-MapLibre-Protokoll (IndexedDB-first, remote-Fallback). ~15 MB / 5 km (dekomprimiert).
• map-gl-style.js build({offline}): byt-Source statt pmtiles://.
• ui.js/map.js laden map-offline + registrieren byt. UI.loadMapLibreUI exportiert.
• Welten-FAB Segment 5: prüft im GL-Modus gespeicherte Region (nicht mehr OSM-Raster); „Fehlende nachladen" stößt MapOffline.downloadAround(GPS, 5km) an.
• Beweis: Download 97 Tiles (5 km München) → Netz AUS → 1903 Features gerendert, nicht geladene Gegend (Paris) leer; Glyphs nötig (sonst lässt MapLibre offline die ganze Kachel fallen).

✅ Follow-ups Runde 1 (2026-06-06, v1222):

• Flag-Default Staging-AN: by_offline_tiles Default AN auf staging.banyaro.app, AUS sonst; localStorage 1/0 bzw. ?tilesoffline=1/0 (boot.js) übersteuert. Default-Logik 3× synchron: map-gl-style.js _offlineEnabled(), offline-indicator.js _offlineTilesMode(), pages/map.js _offlineTilesEnabled().
• Karten-Download-Button: Speed-Dial „Karte offline speichern" (map-offline-btn, war seit FAB-Redesign verwaist) — GL-Modus → downloadAround(Kartenmitte, 5 km) mit Fortschritt in der Statusbar (Kartenmitte statt GPS: Urlaubsort vorab speicherbar); Leaflet-Modus → alter Raster-Prefetch (_cacheTiles). Sichtbarkeit gated: GL ohne Offline-Flag (= Production) zeigt den Button nicht.
• Glyph-Persistenz: Glyphs in IndexedDB (Key-Präfix f/ im Tiles-Store, kein Schema-Bump) + Protokoll byt://f/{fontstack}/{range} (IndexedDB-first, remote-Fallback); Style nutzt offline die byt-Glyph-URL → überlebt App-Updates (SW-Cache wird gepurged, IndexedDB nicht).
• Raster-Prefetch gegated: offline-indicator.js init() überspringt _prefetchTiles() im Offline-Tiles-Modus (GL nutzt das OSM-Raster nicht).

✅ Gerätetest-Befunde behoben (2026-06-06, v1223) — Gerätetest iOS BESTANDEN (Basemap+Labels offline ok):

• POI-Marker offline: downloadAround speichert zusätzlich /api/osm/pois (fast=true, liest lokale osm_pois-DB) je Typ für die Region-Bbox in IndexedDB (Key-Präfix p/<type>, Merge per id — zweite Region löscht die erste nicht). MapOffline.pois(type, bbox) filtert für den Ausschnitt; map.js Phase-1-Catch fällt offline darauf zurück. POI-Typen-Liste in map-offline.js synchron mit OSM_LAYER_MAP (pages/map.js) halten! Marker erscheinen erst nach ERNEUTEM Region-Download.
• Offline-Banner klappt 5 s nach Offline-Gang auf schmale Icon-Leiste ein (volles Banner verdeckte die Karten-Legende); Banner-Styles von index.html-Inline nach components.css konsolidiert.

✅ Runde 2 — adaptives Modell (2026-06-07, Design René 2026-06-06):

• Budget-Download statt fester Radius: downloadAround(lat, lon, {budgetMB:5}) expandiert z14-Ringe (+ Eltern z10–13, Basis z0–9 immer dabei) um den Standort, bis 5 MB GESPEICHERTE Bytes (dekomprimiert, IndexedDB) erreicht sind → Stadt ~1,5–3 km, Land ~6–10 km Radius — passend zur Funknetzdichte. CLIENT-seitig — der geplante Server-Region-Extract-Endpoint ist NICHT nötig.
• Funkloch-Gedächtnis: Tile-Remote-Miss bei aktivem GPS (map.js Recording speist MapOffline.setGps) → markDeadZone (Dedupe 2 km, Cap 50, komplett lokal, nie hochgeladen). autoFillDeadZones() lädt offene Zonen budget-getrieben nach, sobald online (Trigger: offline-indicator init +30 s, online-Event +8 s; Vorab-Check ohne GL-Stack-Load).
• Routen-Korridor: downloadCorridor(track, {bufferKm:1, capMB:50}) + Button „Offline" im Routen-Detail (rd-offline, flag-gated) — Kacheln ±1 km um den Track + Marker der Korridor-Bbox.
• Coverage-Layer: MapOffline.coverage() (GeoJSON der gespeicherten z14-Kacheln) als blauer GL-Fill-Layer; Offline-Button öffnet jetzt ein Verwaltungs-Modal (Gebiete/MB/Marker-Stats, Gebiet speichern, Bereiche ein-/ausblenden, Alles löschen per Zweiklick).
• Flag-Logik zentralisiert: boot.js window.BY.offlineTiles() (vorher 3× dupliziert).
• Meta neu: regions-Liste (Cap 30) + deadzones; region (letztes Gebiet) bleibt für Back-Compat.

✅ Gerätetest-Befunde Runde 2 behoben (v1227):

• Giftköder + vermisste Hunde offline sichtbar (René: „müssen unbedingt sichtbar sein"): Region-Download speichert zusätzlich /api/poison + /api/lost der Gegend (p/_poison, p/_lost; Reader MapOffline.alerts(kind, bbox)). map.js _loadAll fällt pro Quelle (nicht alles-oder-nichts) auf localStorage zurück — vorher verhinderte das SW-gecachte /api/places den Fallback, während die Bbox-URL /api/poison?lat=… scheiterte. lost.js merged den Region-Snapshot in beiden Offline-Pfaden.
• Korridor „unsichtbar": Logik war korrekt (Node-Stub-Test downloadCorridor/coverage bestanden) — er lag im bereits gespeicherten Gebiet. Nach dem Speichern werden die gespeicherten Bereiche jetzt blau auf der Routen-Detailkarte eingeblendet (_detailMap._gl).

✅ Runde 3 (2026-06-07):

• Offline-Indikator = pulsierendes Icon oben rechts (32 px, unterhalb der Kopfzeilen-Höhe) statt Banner über die volle Breite — verdeckte Nav-Elemente, z.B. „← Zurück" in der Routennavigation (Gerätetest René). Vollbanner weiterhin 5 s beim Offline-Gang, dann Icon.
• Rollendes Vorausladen beim Aufzeichnen: setGps() lädt alle ~400 m still die FEHLENDEN z14±2-Kacheln (+Eltern) um die Position, solange online — deckt Weg + Anfahrt schon beim ERSTEN Besuch ab (das Funkloch-Gedächtnis greift erst ab dem 2.). Kein Region-Eintrag, kein UI.
• Bereichsauswahl light: Modal-Button „Sichtbaren Ausschnitt speichern" → downloadBbox(viewport, {capMB:40}) mit Zu-groß-Schutz (>4000 z14-Kacheln → „bitte reinzoomen").
• Speicher-Cap 250 MB (Soft-Guard): totalBytes-Zähler in Meta; AUTOMATISCHE Pfade (Vorausladen, Funkloch-Autofill) stoppen über dem Cap, manuelle bleiben; navigator.storage.persist() best-effort. Echte LRU-Eviction bewusst vertagt (Kacheln werden regionsübergreifend geteilt → Eviction braucht Refcounting; bei ~8 MB/Gebiet kein Druck).
• Auto-OSM-Raster-Prefetch entfernt (offline-indicator init); _prefetchTiles/_cacheTiles bleiben nur für den manuellen Leaflet-Pfad (localhost / by_map_gl=0).
• Logik per Node-Stub-Tests verifiziert (Bbox, Zu-groß, Cap, Prefetch-Throttle, persist). Achtung Node 21+: eingebautes navigator-Global schluckt global.navigator=-Stubs — Object.defineProperty(globalThis, 'navigator', …) verwenden.

✅ Runde 4 — Minimal-Speicher-Modell (2026-06-08, Modell René): Prinzip: Gespeichert bleibt NUR, was wegen Funklöchern nötig ist + manuell Hinzugefügtes (jeweils mit allen Markern + Warnungen). Das Funkloch-Gedächtnis ist die QUELLE DER WAHRHEIT, die Kacheln sind jederzeit neu ableitbarer Cache.

• Ephemeres Vorausladen: Rolling-Prefetch-Kacheln werden bei Aufzeichnungsende GELÖSCHT, wenn die Runde kein Funkloch hatte (nur neu gespeicherte Keys; Bestand unangetastet).
• Netz-Probe bei Aufzeichnung (alle ~2 Min, /api/version, 6-s-Timeout): erkennt Funklöcher auch in BEREITS GESPEICHERTEN Gebieten — dort kommen Kacheln aus IndexedDB, es gibt keinen Remote-Miss als Signal (Lücke von René gefunden).
• clear() behält das Funkloch-Gedächtnis (Zonen → filled:false): Beim nächsten Online-Start werden Funkloch-Gebiete automatisch neu geladen, auch wenn man alles gelöscht hat.
• Start-Check mit Position: autoFillDeadZones({lat,lon,maxKm:50}) — nur Zonen im Umkreis (Speicher minimal), nächstgelegene zuerst; VERIFIZIERT gefüllte Zonen (Zentrums-Kachel da?) → fängt Löschen + iOS-Eviction ab. Pfote-Segment 5 = „alle bekannten Funkloch-Zonen gefüllt".
• Coverage-Layer zweifarbig: Funkloch-Gebiete ORANGE (#f59e0b), manuelle BLAU (#3b82f6); Legende im Offline-Modal; Regionen tragen type 'funkloch'/'gebiet'/'korridor'/'ausschnitt'.

✅ Runde 5 — Gerätetest-Feedback (2026-06-08):

• Indikator links unter die Zoom-Regler (+/−): rechts verdeckte er die Legenden-Chips.
• Flugmodus bei offener App = Funkloch-Signal: offline-Event → Position raw als Zone in IndexedDB (GL-Stack offline evtl. nicht ladbar) → wird künftig automatisch geladen.
• Ent-Funklochen: Zonen-Liste im Offline-Modal (Datum/Koordinaten/Status) mit ✕ → removeDeadZone(ts); Kacheln bleiben bis „Alles löschen".
• Warnungs-Aktualität (Frage René): _mergeStore mit Bbox-Replace — die Server-Antwort ist für die geladene Bbox autoritativ, aufgehobene Giftköder/gefundene Hunde fliegen raus (Fetch-Kreis ⊇ Bbox via ×√2; fresh=null merged nie → Offline-Fetch putzt nichts weg). Zusätzlich 24-h-Refresh der Warnungen im 50-km-Umkreis beim Start-Check.
• Routen-Korridore im Start-Check: ensureRouteCorridors(routes) — eigene Routen in Positionsnähe per Stichproben-Kacheln verifizieren, bei Lücken Korridor aus preview_track (40 Punkte, ±1-km-Puffer schluckt die Vereinfachung) neu laden. Gespeicherte Routen bleiben offline nutzbar, auch nach „Alles löschen"/Eviction. Region-Dedupe per Typ+Name.
• Stub-Tests jetzt im Repo: tests/js/test-map-offline-r*.js (s. tests/js/README.md).

✅ Runde 6 — Standort-Grundversorgung (2026-06-08): Renés Original-Modell Punkt 1 („die App holt sich am Standort die Karten- und Markerdaten bis 5 MB") war zu eng als nur-Funkloch interpretiert: Das Gebiet um die AKTUELLE POSITION ist jetzt IMMER geladen — ensureHomeArea(lat, lon) (Zentrums-Kachel-Check → bei Lücke Budget-Download, type 'standort', Cap-gated). Greift: (a) im Start-Check (raw IDB-Check ohne GL-Stack-Load), (b) SOFORT nach „Alles löschen" (Standort wird direkt neu geladen + Toast). Pfote Segment 5 = Standort-Kachel da UND Zonen im 50-km-Umkreis gefüllt (ferne Zonen zählen nicht mehr — sie laden erst vor Ort). Tests: tests/js/test-map-offline-r6.js.

✅ Runde 7 — selektives Löschen (2026-06-08, Idee René: Vorladezeit sparen): „Alles löschen" löscht nicht mehr alles-und-lädt-neu, sondern behält Standort-Gebiete (type 'standort' aus der Regions-Meta), die Korridore der gespeicherten Routen (clear({keepTracks}), Tracks via API.routes.list/preview_track), den 5-km-Umkreis der aktuellen Position, Basis-Zooms 0–9 sowie Marker/Warnungen + Glyphs. Seit v1237 bleiben auch FUNKLOCH-Gebiete (René: sonst sofort wieder Vorladezeit) — gelöscht wird NUR Manuelles ('gebiet'/'ausschnitt'). Keep-Set ist SELBSTTRAGEND aus der Region-Meta (Korridor-Track ≤60 Pkt im Eintrag, r.track; Standort-Adoption; keepTracks=[{name,track}] migriert Alt-Einträge). clear() liefert Summary {standort, funkloch, korridore} → Toast zeigt, was behalten wurde (Diagnose). Ohne Keep-Kandidaten: Komplett-Wipe (Zonen → ungefüllt). Batch-Delete in einer Transaktion. Tests: r7 (+ r6 angepasst).

🔲 Offen (Backlog):

• Echte LRU-Eviction (Refcounting/Region-Zuordnung der Kacheln), wenn Nutzer real ans Cap kommen.
• Rechteck-Zeichnen als präzisere Bereichsauswahl (Viewport-Variante deckt den Hauptfall ab).
• POIs auch beim rollenden Vorausladen (aktuell nur Kacheln; Giftköder kommen aus dem localStorage-Fallback der letzten Online-Position).

Ziel

GL-Vektorkarten offline-tauglich machen — Kernszenario Gassi/Wandern im Funkloch. Selbst-zielend (cacht wo nötig, nicht überall), speichersparsam, ohne Nutzeraufwand.

Problem (warum GL aktuell NICHT offline geht)

• PMTiles lädt per HTTP-Range (206 Partial Content). Die Cache-API kann 206 nicht speichern (cache.put() wirft) → Basemap-Kacheln landen nie im Offline-Cache.
• SW hat keine Regel für /tiles (nur für tile.openstreetmap.org = altes Raster).
• offline-indicator.js prefetcht weiterhin OSM-Raster (a.tile.openstreetmap.org), das die GL-Karte gar nicht nutzt → doppelter Regress: Raster gecacht das niemand zeigt, GL-Karte offline trotzdem leer.
• Folge offline heute: App + Daten da, aber GL-Karte = Routenlinie/Marker auf leerem Hintergrund.

Gemessene Speicher-Fakten (an echter dach.pmtiles, maxzoom=14 + Overzoom bis ~16)

Referenz-Radius = 5 km (René, 2026-06-05: „5 km genügen"). Messungen:

Gebiet	Fläche	Tiles	Größe
München (48,1/11,5), dicht — 5 km	10×10 km	82	6,4 MB
Bayerischer Wald, ländlich — 5 km	10×10 km	99	2,6 MB
(Kontext) München 10 km	20×20 km	252	15 MB
(Kontext) Bayerischer Wald 10 km	20×20 km	285	4,4 MB
(Kontext) Bayerischer Wald ~25 km	50×50 km	1.595	20 MB

→ Vektor ist ~10× sparsamer als Raster (Raster 5 km ≈ 40–120 MB). Stadt-Tiles ~2,5× dicker als Land. → 5 km ist NICHT 1/4 von 10 km (6,4 vs 15 MB) — die unteren Zoomstufen (Übersicht) sind immer dabei, unabhängig von der bbox-Größe. → Budget ≈ 7 MB (5 km dichte Stadt + Glyphs). Budget-getrieben deckt das in der Stadt ~5 km, auf dem Land ~8–10 km Radius ab (mehr Reichweite genau dort wo die Funklöcher sind). Glyphs (~1–2 MB) + Style (winzig) → ~8 MB pro Gegend. Sehr sparsam → viele Gegenden problemlos (10 ≈ 80 MB). → Messmethode (reproduzierbar): docker run --rm -v /tmp/pmt:/out protomaps/go-pmtiles:latest extract https://staging.banyaro.app/tiles/dach.pmtiles /out/x.pmtiles --bbox=W,S,E,N → Dateigröße ablesen.

Architektur

Region-Extract (budget-getrieben, NICHT fester Radius)

• PMTiles-Directory enthält pro Tile die Byte-Länge → Server kann die Größe einer Region aufsummieren OHNE die Tiles zu laden.
• Endpoint GET /tiles/region?lat=&lon=&budget=7 (MB): wächst die bbox um die Position, bis die summierte Tile-Länge ≈ Budget erreicht (Stadt → kleiner Radius, Land → großer Radius), extrahiert dann genau diese Region als region.pmtiles (ein 200er, ~7 MB). pmtiles extract (go-pmtiles) oder python-pmtiles im Container.
• Client lädt die Datei einmal → IndexedDB (Blob; 200er, anders als die 206-Ranges cachebar).
• MapLibre liest offline aus dem lokalen Blob via pmtiles:// (pmtiles.js kann aus ArrayBuffer lesen); online weiter remote dach.pmtiles (immer aktuell, ganz DACH+Anrainer). Source je nach Verbindung wählen.
• Glyphs (/fonts/*.pbf, Open Sans Regular+Semibold) mit cachen (200er, cachebar).

Adaptive Strategie (der eigentliche Clou — lernt von selbst)

1. Rollendes Vorausladen beim Aufzeichnen: Solange GPS aktiv UND Empfang da, fortlaufend Tiles um die aktuelle Position cachen. Deckt den echten Weg + die Anfahrt automatisch ab — auch beim ersten Mal, bevor man ins Funkloch läuft.
2. Funkloch-Gedächtnis: Wo echte Requests scheitern (Timeout/Fehler während aktivem GPS — NICHT navigator.onLine, das lügt bei Captive-Portal/Schwachempfang), den Bereich als „Offline nötig" markieren → priorisiert behalten, beim nächsten Online-Durchgang großzügiger nachladen. Caveat: im Funkloch selbst kann nicht geladen werden → greift ab dem 2. Besuch (Gassi = repetitiv → ok).
3. Manuelles Vorab-Laden („Offline-Inhalte laden"-Button) — zwei Modi:
   • Aktuelle Gegend (Default, Gassi): budget-getrieben um die Position (~7 MB), ein Tipp.
   • Bereich auswählen (mehrtägige Wanderung — Auto-5km reicht da nicht): Nutzer wählt ein größeres Gebiet, das ganz heruntergeladen wird. Auswahl-Optionen:
     • Karten-Ausschnitt: aktuellen Karten-Viewport (durch Zoomen/Verschieben gewählter bbox) als Download-Gebiet nehmen — simpel, kein Zeichnen nötig.
     • Rechteck ziehen auf der Karte (präziser).
     • Routen-Korridor: entlang einer Route ± Puffer (ideal für Touren, die einer Strecke folgen — viel sparsamer als eine große bbox). Verbindung zum Routen-Feature (WICHTIG, sonst hängt der Modus in der Luft): Einstieg primär AUS der Route — im Routen-Detail (routes.js _openDetail, Aktionsleiste neben GPX/Teilen/Navi) und in der Navigations-Ansicht ein Button „Route offline speichern". Nutzt den bereits geladenen route.gps_track → Korridor = alle Tiles im Puffer (z.B. 1–2 km) um den Track (nicht die ganze bbox). Zusätzlich im „Offline-Inhalte laden"-Dialog ein Modus „Aus meinen Routen wählen" (Liste der gespeicherten Routen → Korridor laden). Größen-Vorschau wie unten, vor dem Download.
   • Größen-Vorschau VOR dem Download: die Tile-Byte-Längen aus der PMTiles-Directory aufsummieren (kein Tile-Download nötig) → „~45 MB" anzeigen, Nutzer bestätigt. Schützt vor versehentlichem Riesen-Download.
   • Fortschritt + „X MB gespeichert" + Liste gespeicherter Gebiete (umbenennen/löschen/aktualisieren).
   • Im Bereichs-Modus gilt das ~7-MB-Budget NICHT (Nutzer entscheidet bewusst), aber eine sinnvolle Obergrenze + der globale Speicher-Cap greifen.

Drumherum

• Budget-Cap + LRU: Gesamtspeicher gedeckelt; selten besuchte Funkloch-Caches fallen raus.
• Privatsphäre: „Wo verliere ich Netz" = Aufenthaltsorte → komplett lokal (IndexedDB), nie hochgeladen.
• Aktualität: Offline-Region beim nächsten Online-Sein neu ziehbar (Basemap-Updates / pmtiles-Refresh).
• Aufräumen: Den alten OSM-Raster-Prefetch in offline-indicator.js ablösen/abschalten (cacht ungenutztes Raster).
• Pfoten-Offline-Indikator (Welten-FAB) anpassen: offline-indicator.js füllt 5 Pfoten-Segmente; Segment 5 „Karten-Kacheln" prüft aktuell CACHE_TILES auf ≥ N OSM-Raster-Tiles (TILE_PREFETCH z14/z13). Die GL-Karte nutzt dieses Raster NICHT → grünes Segment = falsches „Karte offline bereit". → Segment 5 umdefinieren: prüfen ob für die aktuelle Gegend eine region.pmtiles + Glyphs lokal vorliegen (statt Raster-Tile-Count). offline-fill-btn („Offline-Inhalte laden") soll dann den Region-Download anstoßen statt den Raster-Prefetch. (Bei Variante 1 „Raster-Fallback" bliebe Segment 5 wie es ist — Entscheidung hängt an der Offline-Strategie oben.)

Offene Entscheidungen / Defaults

• Budget-Default ~7 MB (Referenz 5 km Stadt; René 2026-06-05). Stadt ~5 km / Land ~8–10 km. Optional Stufe „Groß ~16 MB" (Stadt ~10 km / Land ~18–22 km) für Wandertage.
• Zoom z0–14 (Overzoom liefert Straßenebene gratis).
• Detektionssignal = echte Fetch-Timeouts bei aktivem GPS (nicht navigator.onLine).
• Speicher = IndexedDB (Blobs); MapLibre-Source-Umschaltung online/offline.

Abhängigkeiten

• GL-Tiles in Produktion (dach.pmtiles + fonts auf Prod-Volume) — Voraussetzung.
• pmtiles-Directory-Byte-Summierung (Server) + pmtiles.js Blob-Source (Client).
• WebGL-Kontext-Disziplin beachten (siehe Skill/Memory: jede GL-Karte beim Schließen remove()).

Siehe docs/TILE_SERVER_HANDOVER.md (Tile-Pipeline) + Memory project_tile_server_maintenance.

---

Weitere Karten-To-Dos (nicht offline-spezifisch)

Wetter-Chip: Niederschlag „nächste 3 Std" statt ganzer Tag — ✅ ERLEDIGT (2026-06-05, v1214)

Umgesetzt: weather.py get_weather_for_location → precip = max(h_precip[now_h:now_h+3]) (Fallback Tages-Max); Pill map.js zeigt 💧 X% (3h). Gilt auch fürs Welten-Banner (geteiltes Feld). Hinweis: forecast_days=1 → Slice am Tagesende kürzer (späte Nacht weniger Vorausschau); für volle Mitternachts-Abdeckung forecast_days=2.

(Original-Notiz:) Ist: Der Karten-Chip unten zeigt die Regenwahrscheinlichkeit als Tages-Maximum (backend/weather.py:98 → precip = daily['precipitation_probability_max'][0]; angezeigt in pages/map.js:~2598 als 💧 {w.precip_prob}%). Über den ganzen Tag gemittelt/maximiert = wenig aussagekräftig für „soll ich JETZT raus".

Soll: Den höchsten Wert der nächsten 3 Stunden (ab aktueller Stunde) zeigen.

• Die stündlichen Daten werden in weather.py bereits geladen (&hourly=precipitation_probability, Array h_precip ab Zeile ~116) — kein neuer API-Call nötig.
• Ändern: precip_prob = max(h_precip[now_idx : now_idx+3]) (aktuellen Stundenindex bestimmen wie bei der bestehenden next_rain_time-Logik). next_rain_time/Warnungen können bleiben.
• Optional Chip-Text klarstellen, dass sich der Wert auf die nächsten 3 h bezieht (z.B. 💧 {x}% (3h)).