Ismail/nodeMap
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs

Browse Source
This commit is contained in:
Ismail Ali
2025-05-27 19:41:17 +02:00
parent 257341475c
commit 97fbb6fdc1
86 changed files with 1452 additions and 1185 deletions
Download Patch File Download Diff File Expand all files Collapse all files

123
docs/components/DataSheet.md
View File

@@ -1,123 +0,0 @@
# Komponenten-Dokumentation: `DataSheet.js`
## Zweck
Die Komponente `DataSheet` dient als Kontrollzentrale für die interaktive Kartenanwendung. Sie bietet Funktionen für:
- Auswahl von Bereichen ("Stationen") aus einem Dropdown-Menü
- Steuerung der Sichtbarkeit von Layern wie POIs und Polyline (z. B. Kabelstrecken)
- Aktivierung des Editiermodus
- Steuerung von Layer-Zuständen über Redux und Recoil
---
## Position im UI
Die Komponente wird als Floating-Panel oben rechts auf der Karte angezeigt. Sie hat eine feste Breite (min/max) und ist als "Sidebar-Lightbox" implementiert.
---
## Abhängigkeiten
### Redux
- `gisStationsStaticDistrictSlice`
- `gisSystemStaticSlice`
- `mapLayersSlice`
- `polylineLayerVisibleSlice`
- `gisStationsStaticSlice`
* `poiLayerVisibleSlice`
* `zoomTriggerSlice`
* `selectedAreaSlice`
### Hooks
- `useInitGisStationsStatic()`
---
## Funktionalität im Überblick
### 1. **Bereiche Dropdown**
- Gefüllt aus `GisStationsStatic.Points`
- Wird aktualisiert, wenn sich die Redux-Daten ändern
- Bei Auswahl wird `selectedAreaState` aktualisiert
### 2. **Systemlayer-Checkboxen**
- Daten kommen aus `GisSystemStatic`
- Jeder Eintrag hat `Name` und einen intern generierten `key`
- Sichtbarkeit wird über `mapLayersState` verwaltet
- Zustand wird in `localStorage` gespeichert
### 3. **TALAS-Untermenu**
- Bei Systemname "TALAS" wird eine Untergruppe angezeigt:
- Checkbox für Polyline (Kabelstrecken)
- Sichtbarkeit auch in `localStorage`
### 4. **POI-Checkbox**
- Redux-Slice `poiLayerVisibleSlice`
- Sichtbarkeit von POI-Layern auf der Karte
### 5. **EditModeToggle**
- Eine separate Komponente
- Aktiviert/Deaktiviert den Bearbeitungsmodus (z. B. für Kontextmenü-Einträge)
- Bei aktivem EditMode sind Checkboxen deaktiviert
---
## Lokale Speicherwerte (localStorage)
Folgende Werte werden zwischen Sitzungen gespeichert:
| Key | Zweck |
| --------------------- | ---------------------------------- |
| `poiVisible` | Sichtbarkeit POI-Layer |
| `polylineVisible` | Sichtbarkeit Kabelstrecken |
| `mapLayersVisibility` | Sichtbarkeitsstatus für alle Layer |
| `editMode` | Status des Bearbeitungsmodus |
---
## Bekannte Besonderheiten
- **Fallbacks** für Redux-Selector: z. B. `|| []` bei leeren Listen
- **Fehlerprüfung** für `GisStationsStatic.Points` im useEffect
- **Doppelte Initialisierung von stationListing** (einmal aus `Points`, einmal aus `District`)
---
## Voraussetzungen für korrekte Funktion
- API-Endpunkt `/GisStationsStatic?idMap=...` muss korrekte Struktur liefern: `{ Points: [...] }`
- Redux Store muss korrekt initialisiert sein
- Hook `useInitGisStationsStatic` muss beim Mount ausgeführt werden
---
## Weiterführende Dateien
- `/hooks/useMapComponentState.js`
- `/components/EditModeToggle.js`
- Redux-Slices unter `/redux/slices/`
---
## Speicherort für Dokumentation
Empfohlenes Ziel: `/docs/DataSheet.md`
---
---
## Hinweis zur Umstellung
Diese Komponente wurde ursprünglich mit Recoil entwickelt.
Seit Version `1.1.96` ist der Zustand vollständig auf **Redux Toolkit** umgestellt.
Die Recoil-Atoms wurden entfernt und durch Redux-Slices ersetzt.

60
docs/components/MapComponent.md
View File

@@ -1,60 +0,0 @@
# 🗺️ MapComponent – Webservice-Parameter
## 🔄 URL-Parameter vom Aufrufer (z. B. TALAS.web)
Die Anwendung wird mit Kurzparametern aufgerufen:
```
http://[SERVER]:3000/?m=12&u=484
```
| Parameter | Bedeutung |
| --------- | -------------------------- |
| `m` | Map-ID (intern: `idMap`) |
| `u` | User-ID (intern: `idUser`) |
Diese Parameter werden im Code wie folgt gelesen:
```js
const params = new URLSearchParams(window.location.search);
const idMap = params.get("m");
const idUser = params.get("u");
```
---
## 🔁 Webservice-Proxy intern
Die Next.js API-Routen übernehmen die Umwandlung zu den Webservices:
```js
// Beispiel: /pages/api/gisSystemStatic.js
const targetUrl = `http://.../WebServiceMap.asmx/GisSystemStatic?idMap=${idMap}&idUser=${idUser}`;
```
➡ Die Konvertierung `m → idMap` und `u → idUser` erfolgt **nur im Backend (API-Routen)**
---
## 🧠 Hinweis für Entwickler
- `m` und `u` **immer** aus der URL im Client lesen
- Niemals `idMap` oder `idUser` direkt im Frontend erwarten
- Alle Webservice-Zugriffe im Frontend laufen über interne API-Routen `/api/...`
- Beispiel-Aufruf:
```js
fetch(`/api/gisSystemStatic?m=${idMap}&u=${idUser}`);
```
---
## 🌐 Beispiele aus der Praxis
| Umgebung | URL-Aufruf-Beispiel |
| --------------------- | ------------------------------------------------------------- |
| Entwicklungs-PC | http://10.10.0.70:3000/?m=12&u=484 |
| Test-Server via TALAS | http://10.10.0.13/talas5/MessagesMap/mapTypeC.aspx?m=12&u=484 |
---
Diese Konvention ist essenziell für einheitliche Übergabe und Backend-Kompatibilität.

44
docs/components/TestScript.md
View File

@@ -0,0 +1,44 @@
<!-- /docs/components/TestScript.md -->
# 🧪 TestScript.js
Ein einfaches React-Testskript zur Laufzeitüberprüfung von Codefragmenten in `setupPolylines.js`.
## Zweck
Dieses Skript durchsucht die geladene `setupPolylines.js`-Datei (per `raw-loader`) nach bestimmten Kontextmenüeinträgen:
- „Stützpunkt entfernen“
- „Stützpunkt hinzufügen“
## Vorgehen
- Lädt `setupPolylines.js` als Text via `!!raw-loader!`
- Nutzt reguläre Ausdrücke zur Prüfung
- Gibt Ergebnisse farblich formatiert in der Konsole aus
## Ausgaben
| Zustand | Beschreibung |
|-------------|-----------------------------------------------------|
| ✅ Test bestanden | Der gesuchte Text wurde gefunden |
| ❌ Test fehlgeschlagen | Der gesuchte Text fehlt in der Datei |
| ℹ️ Info | Neutrale Zusatzinformationen in der Konsole |
## Besonderheiten
- Kein visuelles UI – Rückmeldung nur über `console.log`
- Eignet sich als Dev-Hilfe für Refactoring oder PR-Checks
## Beispielausgabe
```plaintext
✔ Test bestanden: Der Text für 'Stützpunkt entfernen' wurde gefunden.
ℹ️ Info: Überprüfung abgeschlossen.
```
## Hinweise
- Wird automatisch beim Mount (via `useEffect`) ausgeführt
- `return null` → keine sichtbare Ausgabe

31
docs/components/contextmenu/CoordinatePopup.md Normal file
View File

@@ -0,0 +1,31 @@
<!-- /docs/components/contextmenu/CoordinatePopup.md -->
# 📌 CoordinatePopup.js
Zeigt ein modales Fenster mit Koordinateninformationen an, z. B. aus einem Kontextmenü heraus.
## Features
- Darstellung eines Koordinatenwerts (`lat,lng`)
- Kopieren in die Zwischenablage (Clipboard API + Fallback)
- Modal zentriert mit Tailwind CSS
- Zwei Buttons: „Kopieren“ und „Schließen“
## Props
| Name | Typ | Beschreibung |
|-------------|-----------|------------------------------------|
| `isOpen` | `boolean` | Steuert Sichtbarkeit des Modals |
| `coordinates` | `string` | Zu zeigende Koordinaten (z. B. `"53.2,8.1"`) |
| `onClose` | `function` | Wird bei Klick auf „Schließen“ ausgelöst |
## Design
- Tailwind-Klassen für zentriertes Layout (`fixed`, `inset-0`, `z-50`)
- Leicht animierter Button-Hover
## Interne Logik
- Nutzt `navigator.clipboard.writeText` oder Fallback mit `document.execCommand("copy")`
- Stoppt Event-Bubbling, um Klick außerhalb zu erkennen

36
docs/components/contextmenu/useMapContextMenu.md Normal file
View File

@@ -0,0 +1,36 @@
<!-- /docs/components/contextmenu/useMapContextMenu.md -->
# 🖱️ useMapContextMenu.js
Initialisiert Kontextmenüeinträge für die Leaflet-Karte.
Wird typischerweise in `initializeMap()` oder `MapComponent` verwendet.
## Kontextmenüeinträge
| Eintrag | Funktion |
|---------------------|------------------------------------------------|
| Koordinaten anzeigen | Öffnet `CoordinatePopup` mit aktueller Position |
| Reinzoomen | Zoomt 3 Stufen näher an das Zentrum heran |
| Rauszoomen | Zoomt 3 Stufen heraus |
| Hier zentrieren | Verschiebt Kartenzentrum auf Klickposition |
| POI hinzufügen | (nur bei `editMode=true`) öffnet POI-Dialog |
## Parameter
```js
addItemsToMapContextMenu(
map,
menuItemAdded,
setMenuItemAdded,
setShowCoordinatesModal,
setShowPoiModal,
setPopupCoordinates,
openPopupWithCoordinates
)
```
## Besonderheiten
- Prüft auf `localStorage.editMode` für POI-Eintrag
- FlyTo-Animationen für Zoom-Vorgänge mit dynamischer Dauer
- Modularer Aufbau: `openPopupWithCoordinates` wird extern übergeben

34
docs/components/gisPolylines/PolylineContextMenu.md Normal file
View File

@@ -0,0 +1,34 @@
<!-- /docs/components/gisPolylines/PolylineContextMenu.md -->
# 📐 PolylineContextMenu.js
Ein einfaches benutzerdefiniertes Kontextmenü zur Interaktion mit Linien (Polylinien) auf der Karte.
## Zweck
Das Menü erlaubt folgende Interaktionen:
- ➕ „Stützpunkt hinzufügen“
- ➖ „Stützpunkt entfernen“
- ❌ „Schließen“
Wird dynamisch positioniert anhand der Klickkoordinaten (`position.x`, `position.y`).
## Props
| Prop | Typ | Beschreibung |
|---------------|-----------|----------------------------------------------------|
| `position` | `{x, y}` | Position in Pixelkoordinaten (z. B. von Mausereignis) |
| `onAddPoint` | `function`| Handler für „Stützpunkt hinzufügen“ |
| `onRemovePoint` | `function` | Handler für „Stützpunkt entfernen“ |
| `onClose` | `function`| Handler zum Schließen des Menüs |
## Styling
- Absolut positioniertes `div`
- Weißer Hintergrund, schwarzer Rahmen
- Kein Tailwind – purer Inline-Style
## Verwendung
Eingebettet z. B. in `setupPolylines.js` oder `PolylineLayerManager`, um rechte Mausklicks auf Linien zu behandeln.

16
docs/components/gisPolylines/icons/CircleIcon.md Normal file
View File

@@ -0,0 +1,16 @@
<!-- /docs/components/gisPolylines/icons/CircleIcon.md -->
# 🔘 CircleIcon.js
Ein einfacher, grauer runder Marker als Stützpunkt in einer Polyline.
## Eigenschaften
- Stil: grauer Kreis mit schwarzem Rand
- Größe: 10×10 px, IconSize 25×25 px (wegen Klickfläche)
- Klasse: `custom-circle-icon`
## Verwendung
Wird in Polylinien als Zwischenpunkt gesetzt. Inaktiv, aber sichtbar.

15
docs/components/gisPolylines/icons/EndIcon.md Normal file
View File

@@ -0,0 +1,15 @@
<!-- /docs/components/gisPolylines/icons/EndIcon.md -->
# 🔲 EndIcon.js
Ein Viereck zur Markierung des Endpunkts einer Polyline.
## Eigenschaften
- Stil: graues Quadrat mit schwarzem Rand
- Größe: 14×14 px
- Klasse: `custom-end-icon`
## Verwendung
Wird am letzten Punkt einer Linie gesetzt, z. B. `lineData.coordinates[line.length - 1]`

15
docs/components/gisPolylines/icons/StartIcon.md Normal file
View File

@@ -0,0 +1,15 @@
<!-- /docs/components/gisPolylines/icons/StartIcon.md -->
# 🔺 StartIcon.js
Ein SVG-Dreieck zur Markierung des Startpunkts einer Polyline.
## Eigenschaften
- Schwarzes Dreieck mit grauem Overlay (Polygon SVG)
- Größe: 18×18 px
- Klasse: `custom-start-icon`
## Verwendung
Wird am ersten Punkt einer Polyline platziert.

20
docs/components/gisPolylines/icons/SupportPointIcons.md Normal file
View File

@@ -0,0 +1,20 @@
<!-- /docs/components/gisPolylines/icons/SupportPointIcons.md -->
# ➕➖ SupportPointIcons.js
Definiert zwei Icons für interaktive Stützpunkte in einer Polyline:
## AddSupportPointIcon
- Grüner Kreis mit weißem Rand und Pluszeichen
- `iconSize`: 24×24 px
## RemoveSupportPointIcon
- Roter Kreis mit weißem Rand und Minuszeichen
- `iconSize`: 24×24 px
## Verwendung
- Hinzufügen/Entfernen von Zwischenpunkten in der Bearbeitungsansicht (editMode)
- Marker erscheinen z. B. bei Maus-Hover oder per Kontextmenü

26
docs/components/icons/devices/overlapping/PlusRoundIcon.md Normal file
View File

@@ -0,0 +1,26 @@
<!-- /docs/components/icons/devices/overlapping/PlusRoundIcon.md -->
# ➕ PlusRoundIcon.js
Ein einfaches Leaflet-Icon, das ein rundes Pluszeichen darstellt.
Wird für zusätzliche UI-Markierungen auf Geräten oder überlappenden Icons verwendet.
## Eigenschaften
| Attribut | Wert |
|--------------|--------------------|
| `iconUrl` | `/img/plus_round.png` |
| `iconSize` | `[22, 22]` |
| `iconAnchor` | `[25, 55]` |
| `className` | `absolute top-0 left-0 z-10` (Tailwind)
## Verwendung
- Dient als Overlay-Symbol, z. B. für „Gerät hinzufügen“ oder zur Darstellung über bestehenden Icons
- Durch die `z-10`-Klasse immer im Vordergrund sichtbar
- Kombinierbar mit OverlappingMarkerSpiderfier oder Marker-Gruppen
## Hinweis
- Die Bilddatei `/img/plus_round.png` muss vorhanden sein
- Kann bei Bedarf dynamisch durch ein anderes Icon ersetzt werden

71
docs/components/mainComponent/MapComponent.md Normal file
View File

@@ -0,0 +1,71 @@
<!-- /docs/components/mainComponent/MapComponent.md -->
# 🗺️ MapComponent.js
Die zentrale React-Komponente zur Darstellung und Steuerung der Leaflet-Karte.
Bindet alle Marker, Layer, POIs, Linien und das Kontextmenü dynamisch ein.
---
## 🎯 Zweck
- Initialisiert die Leaflet-Karte (`useInitializeMap`)
- Bindet Marker & Polylinien über Redux und eigene Hooks
- Steuerung über Redux-Slices wie `selectedArea`, `zoomTrigger`, `polylineVisible`
- Kontextmenüs für Karte, POIs, Polylinien
- Unterstützung für Editierfunktionen über `editMode` (localStorage)
---
## 🧱 Hauptbestandteile
- `useEffect`-Hooks zum Laden und Aktualisieren von:
- Kartenlayern, POIs, Linien, Rechte, Systeme, Positionen
- Marker-Logik für 15+ Layergruppen (TALAS, ECI, GMA, etc.)
- Marker-Overlapping mit `OverlappingMarkerSpiderfier`
- Kontextmenüs (Karte & Polylinie)
- UI-Komponenten:
- `MapLayersControlPanel`
- `CoordinateInput`
- `CoordinatePopup`
- `AddPOIModal`, `PoiUpdateModal`, `VersionInfoModal`
---
## 🧠 Zustand & Redux
Verwendet umfangreiche Redux-Slices zur Steuerung von:
- Linienstatus, POI-Typen, POI-Icons
- Gerätesysteme & Rechte
- Sichtbarkeit einzelner Layergruppen
- Aktuelle Selektion (Area, Gerät, POI)
---
## 🔧 Lokale Steuerung
- EditMode wird aus `localStorage` gelesen
- Karte speichert Zoom & Center dauerhaft im Browser
- Kontextmenü-Einträge ändern sich je nach Rechten & Modus
---
## 🧪 Besonderheiten
- Fehlerbehandlung für `contextmenu`-Fehler eingebaut → Auto-Neuladen
- Alle Marker-Updates mit Overlapping-Check & Z-Index-Steuerung
- Linien enthalten dynamische Tooltips mit `tooltipContents`
- Initiale Datenabfrage über Redux-Thunk-Kaskade
---
## 🔗 Abhängigkeiten
- Leaflet, OverlappingMarkerSpiderfier, React-Toastify
- Redux Toolkit (Thunks + Selectors)
- Tailwind CSS für visuelles Layout
---
📄 Pfad: `/components/mainComponent/MapComponent.js`

53
docs/components/mainComponent/hooks/useInitializeMap.md Normal file
View File

@@ -0,0 +1,53 @@
<!-- /docs/components/mainComponent/hooks/useInitializeMap.md -->
# 🪄 useInitializeMap.js
Custom React-Hook zur Initialisierung der Leaflet-Karte.
Ermöglicht die einfache Übergabe aller nötigen Parameter und abstrahiert die `initializeMap(...)`-Logik.
---
## 📦 Zweck
- Führt `initializeMap(...)` nur **einmal** aus, wenn `mapRef` existiert und `map === null`
- Kapselt die Initialisierung in ein `useEffect`
---
## 🔧 Parameter
| Name | Typ | Beschreibung |
|--------------------------|------------|---------------------------------------------------|
| `map` | `LeafletMap` (Zustand) | Wird initialisiert, wenn `null` |
| `mapRef` | `ref` | Referenz auf `<div id="map">` |
| `setMap` | `function` | Callback zum Setzen der Karteninstanz |
| `setOms` | `function` | Callback für OverlappingMarkerSpiderfier |
| `setMenuItemAdded` | `function` | Wird genutzt, um mehrfaches Menü-Setup zu verhindern |
| `addItemsToMapContextMenu` | `function` | Logik zum Hinzufügen von Kontextmenüeinträgen |
| `hasRights` | `boolean` | Steuerung, ob POI-Menüs angezeigt werden dürfen |
| `setPolylineEventsDisabled` | `function` | Aktiviert/Deaktiviert Polyline-Events global |
---
## 🌐 Verwendung
In `MapComponent.js`:
```js
useInitializeMap(
map,
mapRef,
setMap,
setOms,
setMenuItemAdded,
addItemsToMapContextMenu,
hasRights,
(value) => dispatch(setDisabled(value))
);
```
---
## 📁 Quelle
Wrappt `initializeMap()` aus `/utils/initializeMap.js`

28
docs/components/pois/AddPOIModal.md Normal file
View File

@@ -0,0 +1,28 @@
<!-- /docs/components/pois/AddPOIModal.md -->
# ➕ AddPOIModal.js
Zeigt ein modales Formular an, um einen neuen POI auf der Karte zu erstellen.
Die Koordinaten (`latlng`) werden automatisch übernommen.
## Funktionen
- POI-Name, Typ und zugehöriges Gerät auswählbar
- Koordinatenanzeige (`lat`, `lng`)
- Dynamisches Laden der Gerätedaten und POI-Typen
- Fehleranzeige bei fehlgeschlagenem Speichern
- Löst `addPoiThunk` + Refresh-Trigger (`incrementTrigger`) aus
## Props
| Prop | Typ | Beschreibung |
|----------|-----------|--------------------------------------------------|
| `onClose` | `function` | Schließt das Modal |
| `map` | `Leaflet` | (optional) zum Schließen evtl. offener Popups |
| `latlng` | `object` | Koordinaten für den neuen POI |
## Redux
- `fetchPoiTypThunk`, `fetchPoiIconsDataThunk`
- `addPoiThunk`, `resetAddPoiStatus`

29
docs/components/pois/PoiUpdateModal.md Normal file
View File

@@ -0,0 +1,29 @@
<!-- /docs/components/pois/PoiUpdateModal.md -->
# ✏️ PoiUpdateModal.js
Ein Dialog zur Aktualisierung oder Löschung bestehender POIs.
## Features
- Zeigt aktuellen Namen, Beschreibung, Gerät und Typ
- Gerät und Typ auswählbar via `react-select`
- Unterstützt Löschen und Speichern von POIs
- Eingebundene Sicherheitsabfrage bei Löschen
## Props
| Prop | Typ | Beschreibung |
|------------|-----------|---------------------------------------|
| `onClose` | `function`| Schließt das Modal |
| `poiData` | `object` | Bestehende POI-Daten zur Bearbeitung |
## Redux
- `updatePoiThunk`, `deletePoiThunk`
- `fetchLocationDevicesThunk`, `fetchPoiTypThunk`
## Technisches
- Dynamische Gerätegruppenfilterung basierend auf `mapLayersVisibility`
- Formfelder mit `react-select` für bessere UX

13
docs/hooks/layers/useAreaMarkersLayer.md Normal file
View File

@@ -0,0 +1,13 @@
<!-- /docs/hooks/layers/useAreaMarkersLayer.md -->
# 🗺️ useAreaMarkersLayer.js
Lädt Bereichs-/Stationsmarker aus einer API und rendert sie auf der Karte.
## Features
- Marker mit Tooltip für Standort & Bereich
- Draggable Marker (verschiebbar)
- Automatischer API-Fetch mit `fetch(...)`
- Dynamisches Layer-Handling via localStorage ("mapLayersVisibility")
- Automatisches Speichern neuer Koordinaten per `updateAreaThunk()`

11
docs/hooks/layers/useCiscoRouterMarkersLayer.md Normal file
View File

@@ -0,0 +1,11 @@
<!-- /docs/hooks/layers/useCiscoRouterMarkersLayer.md -->
# 🌐 useCiscoRouterMarkersLayer.js
Hook zur Verwaltung aller Cisco-Router-Marker in der Leaflet-Karte.
## Funktionen
- Lädt Geräte per `createAndSetDevices(6, ...)`
- Fügt Marker hinzu & registriert Popup/Kontextmenü
- Verwendet `checkOverlappingMarkers(...)`

11
docs/hooks/layers/useDauzMarkersLayer.md Normal file
View File

@@ -0,0 +1,11 @@
<!-- /docs/hooks/layers/useDauzMarkersLayer.md -->
# 🔧 useDauzMarkersLayer.js
Spezialisierter Hook zur Verwaltung von DAUZ-Gerätemarkern (System-ID: 110)
## Verhalten
- Marker mit Popup & Kontextmenü
- Nutzung von `createAndSetDevices(...)`
- Sichtbarkeit direkt über Kartenlayer steuerbar

11
docs/hooks/layers/useDrawLines.md Normal file
View File

@@ -0,0 +1,11 @@
<!-- /docs/hooks/layers/useDrawLines.md -->
# 🧬 useDrawLines.js
Hook zur Konvertierung von GIS-Linien in kartentaugliche Koordinatenpaare.
## Schritte
- Lädt Linien mit `fetchGisLinesThunk()`
- Wandelt `points[x, y]` in Leaflet-Koordinaten `[lat, lng]` um
- Gibt `setLinePositions([...])` zurück

11
docs/hooks/layers/useEciMarkersLayer.md Normal file
View File

@@ -0,0 +1,11 @@
<!-- /docs/hooks/layers/useEciMarkersLayer.md -->
# 🛰️ useEciMarkersLayer.js
Verwaltet die Darstellung und Events für ECI-Marker (System-ID: 2)
## Features
- Kontextmenü & Popup für jeden Marker
- Erkennung überlappender Marker (`checkOverlappingMarkers`)
- Nutzung von `createAndSetDevices(...)`

11
docs/hooks/layers/useGmaMarkersLayer.md Normal file
View File

@@ -0,0 +1,11 @@
<!-- /docs/hooks/layers/useGmaMarkersLayer.md -->
# 🌡️ useGmaMarkersLayer.js
Spezialhook für GMA-Marker mit Messwertanzeige (LT, FBT, GT, RLF).
## Besonderheiten
- Tooltip enthält Temperatur-/Feuchtigkeitswerte aus Redux
- Eigenes Kontextmenü mit Zoom/Zentrieren
- Verwendet `marker.options.areaName` zur Messzuordnung

10
docs/hooks/layers/useLteModemMarkersLayer.md Normal file
View File

@@ -0,0 +1,10 @@
<!-- /docs/hooks/layers/useLteModemMarkersLayer.md -->
# 📶 useLteModemMarkersLayer.js
Steuert Marker vom Typ LTE-Modem (System-ID: 5)
## Features
- Standard-Kontextmenü + Popup
- Integration mit OMS und Overlap-Check

10
docs/hooks/layers/useMessstellenMarkersLayer.md Normal file
View File

@@ -0,0 +1,10 @@
<!-- /docs/hooks/layers/useMessstellenMarkersLayer.md -->
# 🧾 useMessstellenMarkersLayer.js
Für Messstellen-Marker (System-ID: 13)
## Verhalten
- Einfache Marker mit Tooltip
- Nutzung von `createAndSetDevices(...)` + Kontextmenü

10
docs/hooks/layers/useOtdrMarkersLayer.md Normal file
View File

@@ -0,0 +1,10 @@
<!-- /docs/hooks/layers/useOtdrMarkersLayer.md -->
# 🔍 useOtdrMarkersLayer.js
Darstellung von OTDR-Messpunkten (System-ID: 9)
## Funktionen
- Popup-Interaktion beim Hover
- Marker mit Kontextmenü via `addContextMenuToMarker`

7
docs/hooks/layers/useSiemensMarkersLayer.md Normal file
View File

@@ -0,0 +1,7 @@
# 🏭 useSiemensMarkersLayer.js
Für Siemens-Geräte (System-ID: 8).
- Marker mit Kontextmenü und Overlap-Prüfung
- Integration mit OMS
- Nutzung von `checkOverlappingMarkers(...)`

7
docs/hooks/layers/useSmsfunkmodemMarkersLayer.md Normal file
View File

@@ -0,0 +1,7 @@
# 📡 useSmsfunkmodemMarkersLayer.js
Filtert `GisSystemStatic` nach SMS Modem (System 111 oder Name).
- Icon: `/img/icons/pois/sms-funkmodem.png`
- Kontextmenü & Popup
- Sichtbarkeit über `isVisible` steuerbar

7
docs/hooks/layers/useSonstigeMarkersLayer.md Normal file
View File

@@ -0,0 +1,7 @@
# ❔ useSonstigeMarkersLayer.js
Für alle Geräte mit System-ID 200 (Sonstige).
- Klassische Leaflet-Marker
- Kontextmenü und Popup
- Nutzung von `createAndSetDevices(...)`

6
docs/hooks/layers/useTalasMarkersLayer.md Normal file
View File

@@ -0,0 +1,6 @@
# 🌐 useTalasMarkersLayer.js
Für TALAS-Systeme (System-ID: 1).
- Popup + Kontextmenü auf Marker
- Fügt Marker zuerst zu OMS, dann zu Karte hinzu

6
docs/hooks/layers/useTalasiclMarkersLayer.md Normal file
View File

@@ -0,0 +1,6 @@
# 🔗 useTalasiclMarkersLayer.js
Spezialhook für Geräte vom Typ TALASICL (System-ID: 100).
- Erstellt Marker mit Standardverhalten
- Kontextmenü, Popup, Overlap-Prüfung

6
docs/hooks/layers/useTkComponentsMarkersLayer.md Normal file
View File

@@ -0,0 +1,6 @@
# ⚙️ useTkComponentsMarkersLayer.js
Für TK-Komponenten (System-ID: 30).
- Lädt Marker via `createAndSetDevices`
- Marker-Koordinaten können debug-geloggt werden

7
docs/hooks/layers/useUlafMarkersLayer.md Normal file
View File

@@ -0,0 +1,7 @@
# 💡 useUlafMarkersLayer.js
Spezialhook für ULAF-Systeme (System-ID: 0).
- Marker mit ULAF-Icon
- Kontextmenü und Popup (statisch)
- Dynamisch generierter Popupinhalt

6
docs/hooks/layers/useWagoMarkersLayer.md Normal file
View File

@@ -0,0 +1,6 @@
# 🧰 useWagoMarkersLayer.js
Für WAGO-Systeme (System-ID: 7).
- Kontextmenü, Popup, Overlapping-Support
- OMS-Integration und Layer-Hinzufügung

7
docs/hooks/layers/useWdmMarkersLayer.md Normal file
View File

@@ -0,0 +1,7 @@
# 🔷 useWdmMarkersLayer.js
Verwaltet WDM-Marker (System-ID: 10) in Leaflet.
- Marker mit Kontextmenü
- Mouseover-Popup
- Nutzung von `createAndSetDevices(...)`

17
docs/hooks/useCreateAndSetDevices.md Normal file
View File

@@ -0,0 +1,17 @@
<!-- /docs/hooks/useCreateAndSetDevices.md -->
# 🛠️ useCreateAndSetDevices.js
Custom Hook zur Initialisierung von Leaflet-Markern für ein bestimmtes System.
Bindet `createAndSetDevices(...)` automatisch in einen `useEffect`.
## Parameter
- `systemId`: ID des Gerätesystems (z. B. 1 = TALAS)
- `setMarkersFunction`: Funktion zum Speichern der erzeugten Marker
- `GisSystemStatic`: Systemdaten aus Redux
- `priorityConfig`: Konfigurationsobjekt zur Prioritätsbewertung
## Redux
- Bezieht `polylineEventsDisabled` aus Redux zur Steuerung der Interaktivität

17
docs/hooks/useDynamicMarkerLayers.md Normal file
View File

@@ -0,0 +1,17 @@
<!-- /docs/hooks/useDynamicMarkerLayers.md -->
# 🔄 useDynamicMarkerLayers.js
Verwaltet alle Marker-Layergruppen dynamisch und modular in einem zentralen Hook.
## Funktionen
- Initialisiert LayerGroups für 15+ Gerätesysteme
- Ruft `createAndSetDevices()` pro System-ID auf
- Führt automatisch Overlap-Check aus (`checkOverlappingMarkers`)
- Speichert erzeugte Marker in `setMarkerStates`
## Voraussetzungen
- Karte (`map`) muss bereit sein
- `GisSystemStatic` + `priorityConfig` + Marker-Setter müssen übergeben werden

44
docs/hooks/useFetchPoiData.md
View File

@@ -1,44 +0,0 @@
# 📍 useFetchPoiData – Laden von POI-Typen und Icons
## Zweck
Dieser React-Hook wird im Frontend verwendet, um:
1. Alle POI-Typen (`poiTyp/readPoiTyp`)
2. Alle POI-Icons (`pois/poi-icons`)
vom Server abzurufen und sie in lokale React-Komponenten zu laden.
---
## Aufrufstruktur
```js
const API_BASE_URL = typeof window !== "undefined" ? `${window.location.protocol}//${window.location.hostname}:3000` : "";
await fetch(`${API_BASE_URL}/api/talas_v5_DB/poiTyp/readPoiTyp`);
await fetch(`${API_BASE_URL}/api/talas_v5_DB/pois/poi-icons`);
```
---
## Erklärung
Da die Anwendung produktiv über Port `80` läuft, aber die Next.js-API auf Port `3000`, wird `:3000` explizit in der URL ergänzt.
Dieser Hook funktioniert nur im Client-Browser. Die Prüfung mit `typeof window !== "undefined"` schützt davor, dass `window` im SSR-Kontext (Server-Side Rendering) undefined ist.
---
## Verhalten bei Fehlern
- Wenn die Antwort nicht `ok` ist (z. B. 404, 500), wird ein Fehler in der Console angezeigt.
- Wenn die Daten kein Array sind (für `poiTyp`), wird eine zusätzliche Validierung ausgelöst.
---
## Siehe auch
- [`MapComponent`](../components/MapComponent.md)
- `pages/api/talas_v5_DB/poiTyp/readPoiTyp.js`
- `pages/api/talas_v5_DB/pois/poi-icons.js`

15
docs/hooks/useLayerVisibility.md Normal file
View File

@@ -0,0 +1,15 @@
<!-- /docs/hooks/useLayerVisibility.md -->
# 👁️ useLayerVisibility.js
Custom Hook zur dynamischen Steuerung von Layer-Sichtbarkeit basierend auf Redux.
## Features
- Entfernt oder zeigt Marker je nach `mapLayersVisibility`
- Nutzt `OverlappingMarkerSpiderfier` (`oms`)
- Normalisiert Layer-Keys (z. B. `"GMA"` → `"gma"`)
## Intern
Verwendet `addContextMenuToMarker()` zur Kontextmenüintegration pro Marker.

19
docs/hooks/useLineData.md Normal file
View File

@@ -0,0 +1,19 @@
<!-- /docs/hooks/useLineData.md -->
# 📊 useLineData.js
Lädt Linienstatusdaten (Farben, Tooltips) aus zwei Webservices in Redux und bereitet sie auf.
## Rückgabe
- `lineColors`: Farben pro Linie basierend auf Status
- `tooltipContents`: HTML-Tooltip pro Modul/Station
## Datenquellen
- `fetchGisLinesThunk()` (Struktur)
- `fetchGisLinesStatusThunk()` (Statusdaten)
## Intern
- Nutzt Map `valueMap`, um Messwert, Schleifenwert, Meldungen zu gruppieren

18
docs/hooks/useMapComponentState.md Normal file
View File

@@ -0,0 +1,18 @@
<!-- /docs/hooks/useMapComponentState.md -->
# 🧠 useMapComponentState.js
Sammelt zentrale UI-Zustände und Redux-Daten für die `MapComponent`.
## Rückgabe
- POI-Typen + Ladezustand
- `deviceName` (z. B. erstes Gerät)
- `locationDeviceData`
- `priorityConfig`
- `menuItemAdded`, `setMenuItemAdded`
- Sichtbarkeit des POI-Layers
## Redux
- `fetchPoiTypThunk`, `fetchGisStationsStaticDistrictThunk`, `fetchPriorityConfigThunk`

16
docs/hooks/useMarkerLayers.md Normal file
View File

@@ -0,0 +1,16 @@
<!-- /docs/hooks/useMarkerLayers.md -->
# 📍 useMarkerLayers.js
Steuert das Hinzufügen oder Entfernen von Markern in ein Leaflet-Map-Layer.
## Verwendung
```js
useMarkerLayers(map, gmaMarkers, "GMA");
```
## Redux
- Liest `mapLayersVisibility` aus dem Store
- Reagiert automatisch auf Änderungen

15
docs/hooks/usePolylineTooltipLayer.md Normal file
View File

@@ -0,0 +1,15 @@
<!-- /docs/hooks/usePolylineTooltipLayer.md -->
# 💬 usePolylineTooltipLayer.js
Initialisiert und steuert Polylinien + Tooltip-Verhalten für Linienmessdaten.
## Funktion
- Nutzt `setupPolylines(...)` zur Marker- und Linienerstellung
- Tooltip-Anzeige bei `mouseover`, dynamisch positioniert
- Entfernt alte Marker und Polylinien automatisch
## Parameter (gekürzt)
- `map`, `markers`, `setMarkers`, `setPolylines`, `linePositions`, `tooltipContents`, `lineColors`, etc.

26
docs/pages/_app.md Normal file
View File

@@ -0,0 +1,26 @@
<!-- /docs/pages/_app.md -->
# 🌐 _app.js
Diese Datei stellt die Haupt-Wrap-Komponente der Next.js-App dar.
Sie initialisiert globale Provider wie den Redux Store.
## Features
- Importiert globales CSS (`styles/global.css`)
- Bindet Redux `Provider` um alle Seiten-Komponenten
- Ermöglicht Zugriff auf Store in allen Seiten
## Struktur
```jsx
<Provider store={store}>
<Component {...pageProps} />
</Provider>
```
## Pfad
```bash
/pages/_app.js
```

67
docs/pages/api.md
View File

@@ -1,67 +0,0 @@
# 📘 API-Routen in `/pages/api/`
Dieses Dokument beschreibt die internen API-Routen der Anwendung (Next.js API Routes) und erklärt die verwendeten URL-Parameter sowie Konventionen bei der Nutzung im Backend.
---
## 🔗 Übergabeparameter aus TALAS.web
Beim Aufruf der Anwendung über TALAS.web werden die folgenden URL-Parameter übergeben:
| Parameter | Bedeutung | Verwendung im Code |
|-----------|------------------|---------------------------|
| `m` | Map-ID (`idMap`) | `req.query.m` |
| `u` | User-ID (`idUser`)| `req.query.u` |
> ⚠️ Es wird bewusst **nicht** `idMap` oder `idUser` verwendet, da TALAS mit Kurzparametern arbeitet.
### Beispiel:
```ts
const idMap = req.query.m;
const idUser = req.query.u;
```
---
## 🛠 Zweck des Verzeichnisses `/pages/api/`
Alle Dateien in diesem Verzeichnis definieren serverseitige Endpunkte. Diese:
- werden **nur auf dem Server ausgeführt**
- sind über `fetch('/api/...')` vom Frontend aufrufbar
- dienen als **Proxy zu SOAP-Webservices** oder **Zugriff auf die Datenbank**
---
## 📁 Beispiel: Aufruf eines Webservice
```bash
GET /api/gisSystemStatic?m=10&u=484
```
Dieser Request wird serverseitig weitergeleitet an:
```
http://[SERVER]/talas5/ClientData/WebServiceMap.asmx/GisSystemStatic?idMap=10&idUser=484
```
---
## 📄 Übersicht interner API-Routen
| API-Route | Beschreibung |
|----------------------------------|------------------------------------------|
| `/api/gisSystemStatic` | Proxy zu WebService GisSystemStatic |
| `/api/gisStationsStaticDistrict` | Geräte-Liste inkl. Bereich |
| `/api/gisStationsMeasurements` | Live-Messwerte der Geräte |
| `/api/talas_v5_DB/pois/readLocations` | POIs aus der Datenbank (MySQL) |
| `/api/talas_v5_DB/device/getAllStationsNames` | Gerätnamen aus DB |
---
## 🔐 Sicherheitshinweis
- Kein sensibler Parameter darf hart codiert sein
- Alle Server-URLs werden über `.env.local` konfiguriert
- Nur `m` und `u` aus `req.query` verwenden – keine Fallbacks oder Defaults

45
docs/pages/api/[...path].md Normal file
View File

@@ -0,0 +1,45 @@
<!-- /docs/pages/api/[...path].md -->
# 🌐 [...path].js
Next.js API-Proxy-Handler mit `http-proxy-middleware`.
Dient als Middleware zur Weiterleitung von API-Requests an das Backend (z. B. Raspberry Pi oder Entwicklungsserver).
---
## 🔧 Funktion
- Leitet alle Requests von `/api/...` an das definierte `target` weiter
- Entfernt `/api` aus dem URL-Pfad
- Erlaubt Cross-Origin Requests mit `changeOrigin: true`
---
## Ziel-Logik
```js
const mode = process.env.NEXT_PUBLIC_API_PORT_MODE;
const target = mode === "dev" ? "http://localhost:80" : "http://localhost";
```
---
## Beispiel
- Frontend-Request: `GET /api/GisStationsStaticDistrict`
- Weitergeleitet an: `GET http://localhost:80/GisStationsStaticDistrict`
---
## Besonderheiten
- Ermöglicht portunabhängige Proxy-Nutzung über `.env`
- Setzt `logLevel: "debug"` zur Diagnose
---
## Pfad
```bash
/pages/api/[...path].js
```

77
docs/pages/api/apiProxy.md
View File

@@ -1,77 +0,0 @@
# 🌐 API Proxy – [...path].js
## Zweck
Diese Datei (`pages/api/[...path].js`) dient als **Catch-All Proxy**
für externe Webservice-Aufrufe über die Next.js API-Routing-Struktur.
Sie leitet alle Anfragen unter `/api/...` an einen Zielserver weiter.
---
## Technologie
Verwendet wird:
- [`http-proxy-middleware`](https://github.com/chimurai/http-proxy-middleware)
- Dynamische Zielauswahl basierend auf Umgebungsvariable `NEXT_PUBLIC_API_PORT_MODE`
---
## Ziel-URL-Konfiguration
```js
const mode = process.env.NEXT_PUBLIC_API_PORT_MODE;
const target =
mode === "dev"
? "http://localhost:80"
: "http://localhost"; // oder z. B. http://10.10.0.13
```
➡ Dadurch entfällt die feste Konfiguration über `NEXT_PUBLIC_SERVER_URL`.
---
## Beispiel: Weiterleitung
Request im Browser:
```
GET /api/talas5/ClientData/WebServiceMap.asmx/GisSystemStatic?idMap=12&idUser=484
```
→ wird weitergeleitet an:
```
http://localhost/talas5/ClientData/WebServiceMap.asmx/GisSystemStatic?idMap=12&idUser=484
```
---
## Verwendete Einstellungen
```js
export default createProxyMiddleware({
target,
changeOrigin: true,
pathRewrite: {
"^/api": "/", // entfernt /api aus dem Pfad
},
logLevel: "debug",
});
```
---
## Vorteile
| Punkt | Nutzen |
|---------------------------|------------------------------------------|
| Keine doppelte API-Konfiguration | ✅ `.env.local` bereinigt |
| Wiederverwendbar & flexibel | ✅ funktioniert lokal & auf Servern |
| Klar gekapselt in `[...path].js` | ✅ übersichtlich |
---
📄 Pfad: `/docs/server/pages/api/apiProxy.md`

28
docs/pages/api/talas_v5_DB/area/readArea.md Normal file
View File

@@ -0,0 +1,28 @@
<!-- /docs/pages/api/talas_v5_DB/area/readArea.md -->
# 📥 readArea.js
Liest Bereichskoordinaten (`location_coordinates`) aus der Datenbank basierend auf `idMaps` (und optional `idLocation`).
## Methode
- `GET`
## URL-Parameter
| Name | Beschreibung |
|-------------|--------------------------------------|
| `m` | Karten-ID (entspricht `idMaps`) |
| `idLocation` | (optional) ID eines bestimmten Bereichs |
## Verhalten
- Joint `location`, `location_coordinates` und `area`-Tabelle
- Gibt strukturierte Daten mit `x`, `y`, `location_name`, `area_name` zurück
- Nutzt MySQL-Pool (`getPool()`)
## Beispiel
```http
GET /api/talas_v5_DB/area/readArea?m=3
```

32
docs/pages/api/talas_v5_DB/area/updateArea.md Normal file
View File

@@ -0,0 +1,32 @@
<!-- /docs/pages/api/talas_v5_DB/area/updateArea.md -->
# 📤 updateArea.js
Aktualisiert die Koordinaten eines Bereichs (`location_coordinates`) basierend auf `idLocation` und `idMap`.
## Methode
- `PUT`
## Request-Body
```json
{
"idLocation": 12,
"idMap": 3,
"x": 53.21421,
"y": 8.43212
}
```
## Verhalten
- Führt `UPDATE location_coordinates SET x=?, y=? WHERE idLocation=? AND idMaps=?`
- Gibt bei Erfolg `success: true` zurück
- Nutzt MySQL-Pool und `connection.release()`
## Fehlerbehandlung
- 400: Fehlende Daten
- 404: Kein Eintrag gefunden
- 500: Interner Fehler

29
docs/pages/api/talas_v5_DB/device/getAllStationsNames.md Normal file
View File

@@ -0,0 +1,29 @@
<!-- /docs/pages/api/talas_v5_DB/device/getAllStationsNames.md -->
# 🧾 getAllStationsNames.js
Liefert eine Zuordnungstabelle aller Geräte-IDs (`idLD`) zu ihren Namen (`name`).
## Methode
- `GET`
## Antwortformat
```json
{
"123": "Kue 705",
"124": "Basisstation 1"
}
```
## Verhalten
- Nutzt Tabelle `location_device`
- Gibt Fehler bei leerem Ergebnis (404) oder Datenbankfehler (500)
## Pfad
```bash
/pages/api/talas_v5_DB/device/getAllStationsNames.js
```

34
docs/pages/api/talas_v5_DB/device/getDevices.md Normal file
View File

@@ -0,0 +1,34 @@
<!-- /docs/pages/api/talas_v5_DB/device/getDevices.md -->
# 🔌 getDevices.js
API-Route zum Abrufen aller Geräteinformationen aus der `devices`-Tabelle.
## Methode
- `POST` (erwartet JSON-Body mit optionalem `activeSystems`-Array)
## Verhalten
- Führt ein einfaches `SELECT * FROM devices` aus
- Nutzt Singleton-MySQL-Pool für Verbindung
- Rückgabe: JSON-Array mit allen Geräteobjekten
## Beispielantwort
```json
[
{
"id": 1,
"name": "Kue705",
"idsystem_typ": 1,
...
}
]
```
## Pfad
```bash
/pages/api/talas_v5_DB/device/getDevices.js
```

25
docs/pages/api/talas_v5_DB/gisLines/readGisLines.md Normal file
View File

@@ -0,0 +1,25 @@
<!-- /docs/pages/api/talas_v5_DB/gisLines/readGisLines.md -->
# 🧭 readGisLines.js
Liefert alle Linien aus der Tabelle `gis_lines`.
## Methode
- `GET`
## Rückgabe
- JSON-Array mit Objekten aus `gis_lines`
- Leeres Array bei keinen Treffern
## Besonderheiten
- Nutzt Singleton-Pool (`getPool()`)
- Immer HTTP 200, auch bei leerem Ergebnis
## Beispiel
```http
GET /api/talas_v5_DB/gisLines/readGisLines
```

30
docs/pages/api/talas_v5_DB/gisLines/updateLineCoordinates.md Normal file
View File

@@ -0,0 +1,30 @@
<!-- /docs/pages/api/talas_v5_DB/gisLines/updateLineCoordinates.md -->
# ✏️ updateLineCoordinates.js
Aktualisiert die `points`-Spalte einer Linie in der Tabelle `gis_lines`.
## Methode
- `POST`
## Request-Body
```json
{
"idLD": 7,
"idModul": 2,
"newCoordinates": [[53.2151, 8.4522], [53.2165, 8.4531]]
}
```
## Verhalten
- Erzeugt aus Koordinaten eine `LINESTRING(...)`
- Nutzt `ST_GeomFromText()` in MySQL
- Transaktion mit Commit/Rollback
## Fehlerfälle
- 400: Ungültige oder fehlende Felder
- 500: Datenbankfehler

26
docs/pages/api/talas_v5_DB/locationDevice/getDeviceId.md Normal file
View File

@@ -0,0 +1,26 @@
<!-- /docs/pages/api/talas_v5_DB/locationDevice/getDeviceId.md -->
# 🔍 getDeviceId.js
Gibt die Geräte-ID (`idLD`) zu einem übergebenen Gerätenamen zurück.
## Methode
- `GET`
## Parameter
| Name | Beschreibung |
|-------------|----------------------|
| `deviceName` | Der Gerätename (z. B. "Kue705") |
## Antwort
```json
{ "idLD": 27 }
```
## Fehler
- 400: Wenn `deviceName` fehlt
- 404: Gerät nicht gefunden

26
docs/pages/api/talas_v5_DB/locationDevice/locationDeviceNameById.md Normal file
View File

@@ -0,0 +1,26 @@
<!-- /docs/pages/api/talas_v5_DB/locationDevice/locationDeviceNameById.md -->
# 🏷️ locationDeviceNameById.js
Gibt den Namen eines Geräts anhand seiner ID zurück.
## Methode
- `GET`
## Parameter
| Name | Beschreibung |
|--------|------------------------|
| `idLD` | Geräte-ID (z. B. 27) |
## Antwort
```json
{ "name": "Kue705" }
```
## Fehler
- 400: Fehlender Parameter
- 404: Gerät mit ID nicht gefunden

27
docs/pages/api/talas_v5_DB/locationDevice/locationDevices.md Normal file
View File

@@ -0,0 +1,27 @@
<!-- /docs/pages/api/talas_v5_DB/locationDevice/locationDevices.md -->
# 🗂️ locationDevices.js
Gibt eine vollständige Liste aller Geräte in der Tabelle `location_device` zurück.
## Methode
- `GET`
## Verhalten
- Führt `SELECT * FROM location_device ORDER BY name` aus
- Gibt vollständige Objekte zurück
## Beispielantwort
```json
[
{
"idLD": 27,
"name": "Kue705",
"description": "...",
...
}
]
```

36
docs/pages/api/talas_v5_DB/poiTyp/readPoiTyp.md Normal file
View File

@@ -0,0 +1,36 @@
<!-- /docs/pages/api/talas_v5_DB/poiTyp/readPoiTyp.md -->
# 🗂️ readPoiTyp.js
Liefert alle verfügbaren POI-Typen aus der Tabelle `poityp`.
## Methode
- `GET`
## Rückgabe
- JSON-Array mit allen Einträgen in `poityp`
## Besonderheiten
- Gibt bei leerem Ergebnis `200` mit Warnung zurück
- Verwendet Singleton-Verbindungspool (`getPool()`)
## Beispiel
```http
GET /api/talas_v5_DB/poiTyp/readPoiTyp
```
## Antwort
```json
[
{
"idPoiTyp": 1,
"name": "Messgerät",
"icon": 12
}
]
```

25
docs/pages/api/talas_v5_DB/pois/addPoi.md Normal file
View File

@@ -0,0 +1,25 @@
<!-- /docs/pages/api/talas_v5_DB/pois/addPoi.md -->
# ➕ addPoi.js
Fügt einen neuen POI (Point of Interest) zur Datenbank hinzu.
## Methode
- `POST`
## Request-Body
```json
{
"name": "POI A",
"poiTypeId": 1,
"latitude": 53.2,
"longitude": 8.1,
"idLD": 27
}
```
## Besonderheiten
- Position wird als `POINT(longitude latitude)` gespeichert

20
docs/pages/api/talas_v5_DB/pois/deletePoi.md Normal file
View File

@@ -0,0 +1,20 @@
<!-- /docs/pages/api/talas_v5_DB/pois/deletePoi.md -->
# ❌ deletePoi.js
Löscht einen POI anhand seiner ID.
## Methode
- `DELETE`
## Query-Parameter
| Parameter | Beschreibung |
|-----------|---------------------|
| `id` | ID des POI (`idPoi`) |
## Antwort
- 200: Erfolgreich gelöscht
- 404: POI nicht gefunden

21
docs/pages/api/talas_v5_DB/pois/getPoiById.md Normal file
View File

@@ -0,0 +1,21 @@
<!-- /docs/pages/api/talas_v5_DB/pois/getPoiById.md -->
# 🔎 getPoiById.js
Gibt die Beschreibung eines POIs zurück.
## Methode
- `GET`
## Query-Parameter
| Parameter | Beschreibung |
|-----------|--------------|
| `idPoi` | POI-ID |
## Antwort
```json
{ "description": "POI A" }
```

21
docs/pages/api/talas_v5_DB/pois/poi-icons.md Normal file
View File

@@ -0,0 +1,21 @@
<!-- /docs/pages/api/talas_v5_DB/pois/poi-icons.md -->
# 🖼️ poi-icons.js
Gibt eine Liste aller POIs und ihrer zugehörigen Icon-Pfade zurück.
## Methode
- `GET`
## Datenquelle
- `poi` → `poiTyp` → `poiicons`
## Antwort
```json
[
{ "idPoi": 12, "path": "/icons/kue.svg" }
]
```

17
docs/pages/api/talas_v5_DB/pois/readAllPOIs.md Normal file
View File

@@ -0,0 +1,17 @@
<!-- /docs/pages/api/talas_v5_DB/pois/readAllPOIs.md -->
# 📋 readAllPOIs.js
Gibt alle POIs mit Positionen zurück.
## Methode
- `GET`
## Rückgabe
- JSON-Array mit `idPoi`, `description`, `idPoiTyp`, `idLD`, `position`
## Besonderheiten
- Position wird per `ST_AsText(...)` als String geliefert

23
docs/pages/api/talas_v5_DB/pois/updateLocation.md Normal file
View File

@@ -0,0 +1,23 @@
<!-- /docs/pages/api/talas_v5_DB/pois/updateLocation.md -->
# 🧭 updateLocation.js
Aktualisiert die Position (`POINT`) eines POIs.
## Methode
- `POST`
## Request-Body
```json
{
"id": 12,
"latitude": 53.2,
"longitude": 8.1
}
```
## Antwort
- 200: `{ success: true }`

25
docs/pages/api/talas_v5_DB/pois/updatePoi.md Normal file
View File

@@ -0,0 +1,25 @@
<!-- /docs/pages/api/talas_v5_DB/pois/updatePoi.md -->
# 📝 updatePoi.js
Aktualisiert Beschreibung, Typ und Gerät eines POIs.
## Methode
- `POST`
## Request-Body
```json
{
"idPoi": 12,
"description": "POI A",
"idPoiTyp": 2,
"idLD": 27
}
```
## Antwort
- 200: Erfolgreich aktualisiert
- 404: POI nicht gefunden

29
docs/pages/api/talas_v5_DB/station/getAllStationsNames.md Normal file
View File

@@ -0,0 +1,29 @@
<!-- /docs/pages/api/talas_v5_DB/station/getAllStationsNames.md -->
# 🏷️ getAllStationsNames.js
Liefert eine Mapping-Tabelle aus `idLD` → `name` aller Einträge in `location_device`.
## Methode
- `GET`
## Rückgabe
```json
{
"12": "Hauptstation",
"13": "Unterstation"
}
```
## Verhalten
- Antwort ist ein Key-Value-Objekt
- Nutzt `reduce()` zur Map-Erstellung
- Verwendet MySQL-Singleton-Pool
## Fehler
- 404: Wenn keine Daten vorhanden
- 500: Datenbankfehler

40
docs/pages/api/talas_v5_DB/station/getDevices.md Normal file
View File

@@ -0,0 +1,40 @@
<!-- /docs/pages/api/talas_v5_DB/device/getDevices.md -->
# 📦 getDevices.js
Gibt alle Geräte aus der `devices`-Tabelle zurück.
## Methode
- `POST`
## Request-Body
```json
{
"activeSystems": [1, 2, 3]
}
```
⚠️ Hinweis: Im aktuellen Code wird der Parameter `activeSystems` nicht verwendet!
## Rückgabe
- JSON-Array mit Geräteobjekten
## Beispielantwort
```json
[
{
"id": 1,
"name": "CPL V4.0",
"idsystem_typ": 1
}
]
```
## Fehler
- 404: Keine Ergebnisse
- 500: Datenbankfehler

32
docs/pages/index.md Normal file
View File

@@ -0,0 +1,32 @@
<!-- /docs/pages/index.md -->
# 🏠 index.js (Home-Seite)
Die Hauptseite der Anwendung.
Bindet dynamisch die Leaflet-Karte (`MapComponent`) und ein Testscripting-Tool (`TestScript`).
## Features
- `MapComponent` ohne SSR eingebunden
- `TestScript` prüft per Konsole Logik/Strukturen
- Lädt POI-Daten per `fetchPoiMarkersThunk()`
- Liest URL-Parameter `m` und `u`
- Unterstützt POI-Hinzufügen über `addPoiThunk(...)`
## Redux-Slices
- `poiMarkersSlice`
- `addPoiSlice`
- `poiReadFromDbTrigger`
## Struktur
```jsx
<MapComponentWithNoSSR locations={locations} onAddLocation={handleAddLocation} />
<TestScriptWithNoSSR />
```
## Besonderheiten
- Dynamisches Nachladen der POIs bei Triggeränderung
- Fehleranzeige über `addPoiStatus` + `addPoiError`

70
docs/redux/api/fromDB/fetchLocationDevices.md
View File

@@ -1,70 +0,0 @@
# 🌐 fetchLocationDevices
Diese Funktion lädt alle Geräte für einen bestimmten Standort aus der Datenbank via API-Endpunkt.
---
## 📍 Pfad
```
/redux/api/fromDB/fetchLocationDevices.js
```
---
## 📥 Funktion
```ts
export const fetchLocationDevices = async () => {
const response = await fetch("/api/talas_v5_DB/locationDevice/locationDevices");
if (!response.ok) {
throw new Error("Geräteliste konnte nicht geladen werden");
}
return await response.json();
};
```
---
## 📡 API-Endpunkt
```http
GET /api/talas_v5_DB/locationDevice/locationDevices
```
Dieser Endpunkt liefert eine JSON-Liste aller Geräte eines Standorts (z. B. für Map-Rendering, POI-Anzeige, Standortübersicht etc.).
---
## 🧪 Fehlerbehandlung
Falls der Request fehlschlägt (z. B. Statuscode ≠ 2xx), wird folgender Fehler ausgelöst:
```
"Geräteliste konnte nicht geladen werden"
```
Dies kann im Redux-Slice über den `.rejected`-Case ausgewertet werden.
---
## 🧩 Verwendung
```ts
import { fetchLocationDevices } from "@/redux/api/fromDB/fetchLocationDevices";
const result = await fetchLocationDevices();
console.log(result); // Erwartet: Array von Geräteobjekten
```
Diese Funktion wird typischerweise im Redux-Thunk `fetchLocationDevicesFromDB` verwendet:
```ts
const data = await fetchLocationDevices();
```
---
## 🔄 Zusammenhang
- Eingebunden in: [`locationDevicesFromDBSlice.js`](./locationDevicesFromDBSlice.md)
- Redux Thunk: `fetchLocationDevicesFromDB`

90
docs/redux/api/fromWebService.md
View File

@@ -1,90 +0,0 @@
# 📡 Webservices – Redux Integration (/redux/api/fromWebService)
In diesem Verzeichnis befinden sich alle Webservice-Fetch-Funktionen für die Kommunikation mit TALAS.web über SOAP-Endpunkte.
---
## Übergabe der Parameter über URL (`m`, `u`)
TALAS.web ruft die Kartenansicht in der Regel so auf:
```
http://[SERVER]:3000/?m=10&u=484
```
Daraus ergeben sich folgende Zuweisungen:
| URL-Parameter | Bedeutung | Variable im Code |
| ------------- | --------- | -------------------------------- |
| `m` | `idMap` | `const idMap = params.get("m")` |
| `u` | `idUser` | `const idUser = params.get("u")` |
### Beispiel:
```ts
const params = new URLSearchParams(window.location.search);
const idMap = params.get("m");
const idUser = params.get("u");
```
---
## Änderung am 2025-05-15
Vorher wurden Default-Werte über `.env.local` als Fallback genutzt:
```ts
const idMap = params.get("idMap") || process.env.NEXT_PUBLIC_DEFAULT_ID_MAP || "12";
```
Das wurde entfernt, um folgende Ziele zu erreichen:
- ❌ Keine fest eingetragenen Defaults im Browser sichtbar
- ✅ Verbindlichkeit: TALAS.web übergibt die Werte immer korrekt via URL
- 🔐 Sicherheit: Kein versehentliches Verwenden eines falschen Users
- 🔍 Fehler leichter erkennbar (Parameter nicht gefunden = echter Fehler)
---
## Hinweis zur Webservice-Konfiguration
Die Webservice-Basisadresse wird **nicht mehr über `.env.local` gesteuert**.
Stattdessen wird sie dynamisch im Client anhand des aktuellen Hostnamens bestimmt:
```js
const baseUrl = `${window.location.origin}/talas5/ClientData/WebServiceMap.asmx`;
```
➡ Dadurch ist kein Rebuild mehr nötig bei IP-Wechseln oder Serverumzügen.
Die Build-Version kann auf jedem Server wiederverwendet werden.
---
## Optional: Validierung einbauen
Falls gewünscht, kann ein expliziter Fehler ausgelöst werden:
```ts
if (!idMap || !idUser) {
throw new Error("Fehlende URL-Parameter: idMap oder idUser");
}
```
---
## Betroffene Dateien
Diese Änderung betrifft alle Funktionen in:
```
/redux/api/fromWebService/fetchGisStationsStatic.js
/redux/api/fromWebService/fetchGisStationsStaticDistrict.js
/redux/api/fromWebService/fetchGisStationsStatusDistrict.js
/redux/api/fromWebService/fetchGisStationsMeasurements.js
/redux/api/fromWebService/fetchGisSystemStatic.js
```
---
Diese Konvention stellt sicher, dass Webservices unabhängig von IP und Serverkonfiguration aufgerufen werden können.

61
docs/redux/api/fromWebService/README.md
View File

@@ -1,61 +0,0 @@
# 📁 Webservice-Dokumentation – fromWebService
Dieses Verzeichnis dokumentiert alle Webservice-Aufrufe,
die über `/redux/api/fromWebService/` im Projekt ausgeführt werden.
---
## 🌐 Hintergrund
Die TALAS.web-Anwendung übergibt `idMap` und `idUser` über die URL-Parameter:
```
http://<server>/talas5/MessagesMap/mapTypeC.aspx?m=12&u=484
```
Daraus entstehen Webservice-Aufrufe wie:
```
/talas5/ClientData/WebServiceMap.asmx/GisSystemStatic?idMap=12&idUser=484
```
Alle Webservices nutzen den Port 80 – auch in der Entwicklungsumgebung.
Daher wird zentral über `.env.local` gesteuert:
```env
NEXT_PUBLIC_API_PORT_MODE=dev
```
---
## 📄 Enthaltene Dokumentationen
| Dateiname | Zweck |
|----------------------------------------|--------------------------------------|
| [`fetchGisSystemStatic.md`](./fetchGisSystemStatic.md) | Systemübersicht aller Geräte |
| [`fetchGisStationsMeasurements.md`](./fetchGisStationsMeasurements.md) | Messwerte der Geräte |
| [`fetchGisStationsStatic.md`](./fetchGisStationsStatic.md) | Statische Standortinformationen |
| [`fetchGisStationsStaticDistrict.md`](./fetchGisStationsStaticDistrict.md) | Gerätestruktur je Bezirk |
| [`fetchGisStationsStatusDistrict.md`](./fetchGisStationsStatusDistrict.md) | Aktueller Gerätestatus nach Bezirk |
---
## 🔁 Verzeichnisstruktur
```bash
/docs
└── frontend
└── redux
└── api
└── fromWebService
├── fetchGisSystemStatic.md
├── fetchGisStationsMeasurements.md
├── fetchGisStationsStatic.md
├── fetchGisStationsStaticDistrict.md
├── fetchGisStationsStatusDistrict.md
└── README.md ← (diese Datei)
```
---
Diese Übersicht hilft Entwicklern beim Einstieg und zeigt, wie zentrale Webservice-Kommunikation im Projekt funktioniert.

81
docs/redux/api/fromWebService/fetchGisStationsMeasurements.md
View File

@@ -1,81 +0,0 @@
# 🌐 fetchGisStationsMeasurements – Geräte-Messwerte abrufen
## Zweck
Diese Funktion ruft Messwerte aller Geräte einer Karte ab.
Die Daten werden vom Webservice `GisStationsMeasurements` bereitgestellt.
---
## Webservice-Endpunkt
```
GisStationsMeasurements?idMap={idMap}&idUser={idUser}
```
---
## Besonderheit: Port-Steuerung per Umgebungsvariable
Die Webservices (z. B. `WebServiceMap.asmx`) laufen **immer auf Port 80** –
auch in der Entwicklungsumgebung.
Um das zu berücksichtigen, wird der Port über `.env.local` gesteuert:
```env
NEXT_PUBLIC_API_PORT_MODE=dev
```
### Beispiel (aus dem Code):
```js
const mode = process.env.NEXT_PUBLIC_API_PORT_MODE;
const apiBaseUrl =
mode === "dev"
? `${window.location.protocol}//${window.location.hostname}:80/talas5/ClientData/WebServiceMap.asmx`
: `${window.location.origin}/talas5/ClientData/WebServiceMap.asmx`;
```
---
## Parameter
| URL-Parameter | Beschreibung | Übergabe durch TALAS.web |
|---------------|--------------|---------------------------|
| `m` | Map-ID | Ja |
| `u` | User-ID | Ja |
Diese Parameter werden clientseitig aus der URL gelesen:
```js
const params = new URLSearchParams(window.location.search);
const idMap = params.get("m");
const idUser = params.get("u");
```
---
## Beispiel-Aufruf
```
http://10.10.0.13/talas5/MessagesMap/mapTypeC.aspx?m=12&u=484
```
→ ergibt folgenden Webservice-Aufruf:
```
http://10.10.0.13/talas5/ClientData/WebServiceMap.asmx/GisStationsMeasurements?idMap=12&idUser=484
```
---
## Siehe auch
- `.env.local` → `NEXT_PUBLIC_API_PORT_MODE`
- `docs/frontend/redux/api/fromWebService/fetchGisSystemStatic.md`
- API-Datei: `/redux/api/fromWebService/fetchGisStationsMeasurements.js`
---
📄 Pfad: `/docs/frontend/redux/api/fromWebService/fetchGisStationsMeasurements.md`

78
docs/redux/api/fromWebService/fetchGisStationsStatic.md
View File

@@ -1,78 +0,0 @@
# 🌐 fetchGisStationsStatic – Standortdaten der Karte abrufen
## Zweck
Diese Funktion ruft die statischen Standortinformationen aller Geräte für eine bestimmte Karte ab.
Sie nutzt den Webservice-Endpunkt `GisStationsStatic`.
---
## Webservice-Endpunkt
```
GisStationsStatic?idMap={idMap}
```
---
## Besonderheit: Port-Steuerung über Umgebungsvariable
Die Webservices laufen immer auf Port 80 – auch in der Entwicklungsumgebung.
Die Funktion erkennt dies anhand der Umgebungsvariable in `.env.local`:
```env
NEXT_PUBLIC_API_PORT_MODE=dev
```
### Codeauszug:
```js
const mode = process.env.NEXT_PUBLIC_API_PORT_MODE;
const apiBaseUrl =
mode === "dev"
? `${window.location.protocol}//${window.location.hostname}:80/talas5/ClientData/WebServiceMap.asmx`
: `${window.location.origin}/talas5/ClientData/WebServiceMap.asmx`;
```
---
## Parameter
| URL-Parameter | Beschreibung | Übergabe durch TALAS.web |
|---------------|--------------|---------------------------|
| `m` | Map-ID | Ja |
Die Map-ID wird aus der URL gelesen:
```js
const params = new URLSearchParams(window.location.search);
const idMap = params.get("m");
```
---
## Beispiel
```
http://10.10.0.13/talas5/MessagesMap/mapTypeC.aspx?m=12&u=484
```
→ wird zu:
```
http://10.10.0.13/talas5/ClientData/WebServiceMap.asmx/GisStationsStatic?idMap=12
```
---
## Siehe auch
- `.env.local` → `NEXT_PUBLIC_API_PORT_MODE`
- `fetchGisSystemStatic.md`
- `fetchGisStationsMeasurements.md`
---
📄 Pfad: `/docs/frontend/redux/api/fromWebService/fetchGisStationsStatic.md`

77
docs/redux/api/fromWebService/fetchGisStationsStaticDistrict.md
View File

@@ -1,77 +0,0 @@
# 🌐 fetchGisStationsStaticDistrict – Statische Gerätebezirksdaten abrufen
## Zweck
Diese Funktion ruft alle statischen Geräte- und Sektordaten eines bestimmten Kartenbereichs ab.
Sie basiert auf dem Webservice-Endpunkt `GisStationsStaticDistrict`.
---
## Webservice-Endpunkt
```
GisStationsStaticDistrict?idMap={idMap}&idUser={idUser}
```
---
## Portsteuerung über Umgebungsvariable
Da die Webservices in allen Umgebungen auf Port 80 laufen, wird der Zugriff über eine Umgebungsvariable gesteuert:
```env
NEXT_PUBLIC_API_PORT_MODE=dev
```
### Codebeispiel:
```js
const mode = process.env.NEXT_PUBLIC_API_PORT_MODE;
const apiBaseUrl =
mode === "dev"
? `${window.location.protocol}//${window.location.hostname}:80/talas5/ClientData/WebServiceMap.asmx`
: `${window.location.origin}/talas5/ClientData/WebServiceMap.asmx`;
```
---
## URL-Parameter
| Parameter | Beschreibung | Wird übergeben durch |
|-----------|--------------|------------------------|
| `m` | Map-ID | TALAS.web (in URL) |
| `u` | User-ID | TALAS.web (in URL) |
```js
const params = new URLSearchParams(window.location.search);
const idMap = params.get("m");
const idUser = params.get("u");
```
---
## Beispiel
```
http://10.10.0.13/talas5/MessagesMap/mapTypeC.aspx?m=12&u=484
```
→ wird übersetzt zu:
```
http://10.10.0.13/talas5/ClientData/WebServiceMap.asmx/GisStationsStaticDistrict?idMap=12&idUser=484
```
---
## Siehe auch
- `.env.local` → `NEXT_PUBLIC_API_PORT_MODE`
- `fetchGisStationsStatic.js`
- `fetchGisStationsMeasurements.js`
- `fetchGisSystemStatic.js`
---
📄 Pfad: `/docs/frontend/redux/api/fromWebService/fetchGisStationsStaticDistrict.md`

78
docs/redux/api/fromWebService/fetchGisStationsStatusDistrict.md
View File

@@ -1,78 +0,0 @@
# 🌐 fetchGisStationsStatusDistrict – Gerätestatus nach Bezirken abrufen
## Zweck
Diese Funktion ruft die aktuellen Statusdaten aller Geräte eines bestimmten Kartenbezirks ab.
Sie basiert auf dem Webservice-Endpunkt `GisStationsStatusDistrict`.
---
## Webservice-Endpunkt
```
GisStationsStatusDistrict?idMap={idMap}&idUser={idUser}
```
---
## Portsteuerung über Umgebungsvariable
Da die Webservices in allen Umgebungen über Port 80 laufen,
wird der Zugriff über eine Umgebungsvariable in `.env.local` konfiguriert:
```env
NEXT_PUBLIC_API_PORT_MODE=dev
```
### Codebeispiel:
```js
const mode = process.env.NEXT_PUBLIC_API_PORT_MODE;
const apiBaseUrl =
mode === "dev"
? `${window.location.protocol}//${window.location.hostname}:80/talas5/ClientData/WebServiceMap.asmx`
: `${window.location.origin}/talas5/ClientData/WebServiceMap.asmx`;
```
---
## URL-Parameter
| Parameter | Beschreibung | Übergabe durch TALAS.web |
|-----------|--------------|---------------------------|
| `m` | Map-ID | Ja |
| `u` | User-ID | Ja |
```js
const params = new URLSearchParams(window.location.search);
const idMap = params.get("m");
const idUser = params.get("u");
```
---
## Beispiel
```
http://10.10.0.13/talas5/MessagesMap/mapTypeC.aspx?m=12&u=484
```
→ wird übersetzt zu:
```
http://10.10.0.13/talas5/ClientData/WebServiceMap.asmx/GisStationsStatusDistrict?idMap=12&idUser=484
```
---
## Siehe auch
- `.env.local` → `NEXT_PUBLIC_API_PORT_MODE`
- `fetchGisStationsStaticDistrict.js`
- `fetchGisStationsMeasurements.js`
- `fetchGisSystemStatic.js`
---
📄 Pfad: `/docs/frontend/redux/api/fromWebService/fetchGisStationsStatusDistrict.md`

76
docs/redux/api/fromWebService/fetchGisSystemStatic.md
View File

@@ -1,76 +0,0 @@
# 🌐 fetchGisSystemStatic – Geräte-Systemdaten abrufen
## Zweck
Diese Funktion ruft die Gerätestatus-Übersicht für eine bestimmte Karte ab:
WebService-Endpunkt:
```
GisSystemStatic?idMap={idMap}&idUser={idUser}
```
---
## Besonderheit bei der URL
Die Webservices (z. B. `WebServiceMap.asmx`) laufen **immer auf Port 80**,
egal ob im Entwicklungsmodus (`localhost`, `:3000`) oder auf dem Testserver (`10.10.0.13`).
Daher wird im Code explizit `:80` gesetzt – gesteuert über die Umgebungsvariable:
```env
NEXT_PUBLIC_API_PORT_MODE=dev
```
### Beispiel (aus dem Code):
```js
const mode = process.env.NEXT_PUBLIC_API_PORT_MODE;
const apiBaseUrl = mode === "dev" ? `${window.location.protocol}//${window.location.hostname}:80/talas5/ClientData/WebServiceMap.asmx` : `${window.location.origin}/talas5/ClientData/WebServiceMap.asmx`;
```
---
## Parameter
Die Funktion liest folgende URL-Parameter ein:
| URL-Parameter | Beschreibung | Übergabe durch TALAS.web |
| ------------- | ------------ | ------------------------ |
| `m` | Map-ID | Ja |
| `u` | User-ID | Ja |
Diese werden aus der URL wie folgt gelesen:
```js
const params = new URLSearchParams(window.location.search);
const idMap = params.get("m");
const idUser = params.get("u");
```
---
## Beispiel-Aufruf
TALAS-Aufruf:
```
http://10.10.0.13/talas5/MessagesMap/mapTypeC.aspx?m=12&u=484
```
wird im Webservice-Request zu:
```
http://10.10.0.13/talas5/ClientData/WebServiceMap.asmx/GisSystemStatic?idMap=12&idUser=484
```
---
## Siehe auch
- `.env.local` → `NEXT_PUBLIC_API_PORT_MODE`
- `docs/fromWebService.md`
- API-Datei: `/redux/api/fromWebService/fetchGisSystemStatic.js`
- 📄 Pfad: `/docs/frontend/redux/api/fromWebService/fetchGisSystemStatic.md`

25
docs/redux/slices/database/locationDevicesFromDBSlice.md Normal file
View File

@@ -0,0 +1,25 @@
<!-- /docs/redux/slices/database/locationDevicesFromDBSlice.md -->
# 🧩 locationDevicesFromDBSlice.js
Redux-Slice für das Laden von Geräten aus der Datenbank-Tabelle `location_device`.
## Zustand
```js
{
devices: [],
status: "idle" | "loading" | "succeeded" | "failed",
error: string | null
}
```
## Thunk
- `fetchLocationDevicesThunk` (async)
## Selector
```js
selectLocationDevices = (state) => state.locationDevicesFromDB.devices
```

23
docs/redux/slices/database/locationDevicesSlice.md Normal file
View File

@@ -0,0 +1,23 @@
<!-- /docs/redux/slices/database/locationDevicesSlice.md -->
# 🧩 locationDevicesSlice.js
Zweite Variante des Slices für Geräte (veraltet oder parallel verwendet).
## Zustand
```js
{
data: [],
status: "idle" | "loading" | "succeeded" | "failed",
error: string | null
}
```
## Selector
```js
selectLocationDevices = (state) => state.locationDevices.data
```
⚠️ Beachte: Duplikat zu `locationDevicesFromDBSlice.js`

24
docs/redux/slices/database/priorityConfigSlice.md Normal file
View File

@@ -0,0 +1,24 @@
<!-- /docs/redux/slices/database/priorityConfigSlice.md -->
# 🧩 priorityConfigSlice.js
Lädt die Prioritätskonfiguration für Marker (z. B. zur farblichen Darstellung).
## Zustand
```js
{
data: [],
status: "idle" | "succeeded"
}
```
## Thunk
- `fetchPriorityConfigThunk`
## Selector
```js
selectPriorityConfig = (state) => state.priorityConfig.data
```

103
docs/redux/slices/db/locationDevicesFromDBSlice.md
View File

@@ -1,103 +0,0 @@
# 📦 locationDevicesFromDBSlice
Zuständig für das Laden und Speichern der Geräteinformationen pro Standort (Location) aus der Datenbank.
## 🧠 Zweck
Dieses Slice verwaltet die Geräte, die mit einem bestimmten Standort (Location) verknüpft sind.
Es nutzt ein `createAsyncThunk`, um die Daten vom Webservice bzw. von der lokalen Datenbank zu laden.
---
## 🔁 Datenfluss
1. **Dispatch `fetchLocationDevicesFromDB()`**
2. **Daten werden über `fetchLocationDevices()` geladen**
3. **Status wird aktualisiert (`loading`, `succeeded`, `failed`)**
4. **Geräte-Liste (`devices`) wird gespeichert**
---
## 🧩 Slice-Definition
```js
initialState: {
devices: [], // Geräte-Liste pro Standort
status: "idle", // "idle" | "loading" | "succeeded" | "failed"
error: null // Fehlernachricht im Fehlerfall
}
```
---
## 🔧 Actions
| Action Type | Beschreibung |
|--------------------------------------------|--------------------------------------------------|
| `fetchLocationDevicesFromDB/pending` | Startet den Ladeprozess |
| `fetchLocationDevicesFromDB/fulfilled` | Speichert die empfangenen Geräte in `devices` |
| `fetchLocationDevicesFromDB/rejected` | Speichert die Fehlermeldung in `error` |
---
## 📥 Async Thunk
```ts
export const fetchLocationDevicesFromDB = createAsyncThunk(
"locationDevicesFromDB/fetchLocationDevicesFromDB",
async () => {
return fetchLocationDevices(); // API-Aufruf aus services/api
}
);
```
Die Funktion `fetchLocationDevices()` befindet sich unter:
```
/redux/api/fromDB/fetchLocationDevices.js
```
---
## 🧪 Verwendung in Komponenten
### Beispiel mit `useSelector` & `useDispatch`
```tsx
import { useSelector, useDispatch } from "react-redux";
import { fetchLocationDevicesFromDB } from "@/redux/slices/db/locationDevicesFromDBSlice";
const dispatch = useDispatch();
const devices = useSelector((state) => state.locationDevicesFromDB.devices);
const status = useSelector((state) => state.locationDevicesFromDB.status);
useEffect(() => {
dispatch(fetchLocationDevicesFromDB());
}, []);
```
---
## 🧩 Integration im Store
```ts
import locationDevicesFromDBReducer from "./slices/db/locationDevicesFromDBSlice";
export const store = configureStore({
reducer: {
locationDevicesFromDB: locationDevicesFromDBReducer,
// weitere Slices ...
},
});
```
---
## 📌 Hinweis
Dieses Slice ist Bestandteil der neuen Redux-Architektur (ehemals Recoil)
→ siehe auch `CHANGELOG.md` Version `1.1.97` bis `1.1.98`.
```
Pfad: /redux/slices/db/locationDevicesFromDBSlice.js
```

93
docs/redux/slices/db/poiTypesSlice.md
View File

@@ -1,93 +0,0 @@
# 🧭 poiTypesSlice
Verwaltet die Point-of-Interest (POI) Typen, die vom Server bereitgestellt werden – z. B. für die Darstellung von Symbolen oder Layer-Kategorien in der Karte.
---
## 📍 Datei
```
/redux/slices/db/poiTypesSlice.js
```
---
## 📦 Initialer State
```ts
{
data: [], // Liste der POI-Typen
status: "idle" // Ladezustand: "idle" | "loading" | "succeeded" | "failed"
}
```
---
## ⚙️ Async Thunk: `fetchPoiTypes`
```ts
export const fetchPoiTypes = createAsyncThunk("poiTypes/fetchPoiTypes", async () => {
let API_BASE_URL = "";
if (typeof window !== "undefined") {
API_BASE_URL = `${window.location.protocol}//${window.location.hostname}:3000`;
} else {
API_BASE_URL = "http://localhost:3000";
}
const response = await fetch(`${API_BASE_URL}/api/talas_v5_DB/poiTyp/readPoiTyp`);
return await response.json();
});
```
---
## 🔁 Lifecycle im Slice
| Zustand | Beschreibung |
|--------------------|--------------------------------------|
| `pending` | Setzt `status = "loading"` |
| `fulfilled` | Speichert `payload` in `state.data` und setzt `status = "succeeded"` |
| `rejected` | Setzt `status = "failed"` |
---
## 🧪 Verwendung im Component
```tsx
import { useSelector, useDispatch } from "react-redux";
import { fetchPoiTypes } from "@/redux/slices/db/poiTypesSlice";
const dispatch = useDispatch();
const poiTypes = useSelector((state) => state.poiTypes.data);
const status = useSelector((state) => state.poiTypes.status);
useEffect(() => {
dispatch(fetchPoiTypes());
}, []);
```
---
## 🧩 Store Integration
```ts
import poiTypesReducer from "./slices/db/poiTypesSlice";
export const store = configureStore({
reducer: {
poiTypes: poiTypesReducer,
// weitere ...
},
});
```
---
## 🌐 API-Endpunkt
```http
GET /api/talas_v5_DB/poiTyp/readPoiTyp
```
Erwartet JSON-Antwort mit allen verfügbaren POI-Typen für die App.

64
docs/redux/store.md Normal file
View File

@@ -0,0 +1,64 @@
<!-- /docs/redux/store.md -->
# 🧠 Redux Store (store.js)
Zentrale Konfiguration des globalen Redux-Stores für die Anwendung.
Er verwaltet Zustand für Daten aus Webservices, der Datenbank und UI-Status.
---
## 🔌 Verwendung
```js
import { Provider } from "react-redux";
import { store } from "../redux/store";
<Provider store={store}>
<App />
</Provider>
```
---
## 🔁 Struktur
Der Store besteht aus drei Bereichen:
### 1. `database`
- `poiMarkers`, `addPoi`, `poiLayerVisible`
- `gisLinesFromDatabase`, `polylineLayerVisible`
- `readPoiMarkersStore`, `priorityConfig`, `locationDevicesFromDB`
### 2. `webservice`
- `gisStationsStaticDistrict`, `gisStationsStatusDistrict`, `gisSystemStatic`
- `gisStationsMeasurements`, `gisLinesStatusFromWebservice`, `userRights`
### 3. `ui / interaktiv`
- `mapLayers`, `selectedDevice`, `selectedPoi`, `selectedArea`
- `lineVisibility`, `zoomTrigger`, `urlParameter`, `polylineContextMenu`
- `polylineEventsDisabled`, `addPoiOnPolyline`
---
## ⚙️ Einrichtung
```js
export const store = configureStore({
reducer: {
selectedDevice: selectedDeviceReducer,
poiMarkers: poiMarkersReducer,
...
}
});
```
---
## 📁 Pfad
```bash
/redux/store.js
```