This commit is contained in:
ISA
2025-05-28 09:51:46 +02:00
parent 65eeb95df4
commit 2946f55246
178 changed files with 4306 additions and 1 deletions

View File

@@ -1,2 +1,2 @@
// /config/appVersion
export const APP_VERSION = "1.1.198";
export const APP_VERSION = "1.1.199";

BIN
docs/docs/NodeMap.pdf Normal file

Binary file not shown.

14
docs/docs/README.md Normal file
View File

@@ -0,0 +1,14 @@
<!-- /docs/README.md -->
# Entwickler-Dokumentation
Willkommen in der technischen Dokumentation von NodeMap.
📂 Wichtige Themen:
- Webservices: `api/webservices.md`
- Redux / Fetch-Logik: `redux/api/fromWebService.md`
- Konfigurationsschema: `env/env.local.schema.md`
- Deployment: `deployment.md`
Diese Doku ist für Entwickler, die an diesem Projekt mitarbeiten oder übernehmen.

90
docs/docs/architecture.md Normal file
View File

@@ -0,0 +1,90 @@
<!-- /docs/architecture.md -->
# 🧠 Architekturübersicht NodeMap
Dieses Dokument beschreibt die technische Gesamtarchitektur des Projekts **NodeMap**, einer kartenbasierten Webanwendung zur Anzeige, Bearbeitung und Verwaltung von GIS-Daten, POIs und Gerätestatus.
---
## ⚙️ Technologie-Stack
| Komponente | Beschreibung |
| --------------------- | ---------------------------------------------------------------------- |
| **Frontend** | React 18 + Next.js (App Router) |
| **State-Management** | Redux Toolkit mit zentralem Store, Thunks & Slices |
| **UI** | Tailwind CSS + Leaflet + React-Icons |
| **Backend-Anbindung** | Webservices via `WebServiceMap.asmx` (IIS) + lokale Next.js API für DB |
| **Datenbank** | MySQL (Produktiv & Entwicklung, z.T. via Docker) |
| **Deployment** | Windows Server (IIS), optional per `nssm` als Dienst |
---
## 🗺️ Architekturüberblick
```
+------------------+ +------------------+ +------------------+
| Leaflet Map | <---> | Redux Store | <---> | Webservices |
| (Interaktivität) | | (Status & Data) | | (IIS, .asmx) |
+------------------+ +------------------+ +------------------+
^
|
v
+------------------+ +------------------+ +-------------------+
| POI-Komponenten | <---> | Redux Slices | <---> | Next.js API-Routen|
| (Add/Edit) | | (z.B. poiSlice) | | (Datenbank) |
+------------------+ +------------------+ +-------------------+
```
---
## 🔁 Datenfluss (Beispiel: POI anzeigen)
1. Leaflet-Karte lädt bei `MapComponent` Mounting
2. Redux-Thunk `fetchPoiMarkersThunk` wird ausgelöst
3. Thunk ruft `fetchPoiDataService.js` (DB) oder Webservice (IIS) auf
4. Ergebnisse werden im Slice `readPoiMarkersStoreSlice` gespeichert
5. Komponenten lesen POI-Daten über `useSelector(...)` aus dem Store
6. POIs werden als Marker in Leaflet gesetzt
---
## 📁 Schlüsselfunktionen & Module
| Bereich | Datei/Modul | Aufgabe |
| ------------- | ----------------------------------------------- | ---------------------------------------- |
| Kartenlogik | `MapComponent.js` | Zentrale Initialisierung und Layer-Logik |
| Webservices | `services/webservice/` | Kommunikation mit TALAS V5 Webservice |
| Datenbank | `services/database/` | Zugriff auf lokale Next.js-API & DB |
| POIs | `AddPOIModal.js`, `PoiUpdateModal.js` | UI für POI-Erstellung & -Bearbeitung |
| Redux | `redux/slices/`, `redux/thunks/`, `redux/store` | Globaler State, API-Steuerung |
| Konfiguration | `.env.local`, `config.js`, dynamic URLs | IP, basePath, Ports |
---
## 🧩 Besonderheiten
- **Konfigurierbarer basePath:**
Pfad wie `/talas5` ist optional und kann per `NEXT_PUBLIC_BASE_PATH` in `.env.local` gesetzt werden.
- **Rechteabhängige UI:**
Funktionen (z.B. POI bearbeiten) basieren auf Benutzerrechten (`IdRight`) vom Server.
- **Zentrale Komponentensteuerung:**
Komponenten wie `MapLayersControlPanel` oder `CoordinatePopup` kontrollieren Layer & Interaktion.
- **Kontextmenü-Logik:**
Marker & Polylinien besitzen eigene Kontextmenüs dynamisch zusammengesetzt und verwaltet.
---
## 📦 Versionierung & Builds
- Version ist in `appVersion.js` definiert → wird über `NEXT_PUBLIC_APP_VERSION` eingeblendet
- Build erfolgt via `npm run build`, Auslieferung über `.next/`
- Nicht benötigte Dateien wie `__tests__`, `docs/`, `scripts/` etc. werden nicht in den Build aufgenommen
---
## 📚 Weiterführende Dokumentation
- [`build-and-deploy.md`](./build-and-deploy.md)
- [`env.local.schema.md`](./env.local.schema.md)
- [`redux/slices/`](./redux/slices/)
- [`services/webservice/`](./services/webservice/)

View File

@@ -0,0 +1,46 @@
<!-- /docs/build-amddeploy.md -->
# 🛠 Deployment & Build-Verhalten (Next.js)
Diese Datei beschreibt, welche Projektdateien in den Build (`.next/`) aufgenommen werden und welche nicht.
Ziel: Klarheit für Onboarding, Deployment-ZIP-Erstellung oder CI/CD.
---
## 📦 Wird beim `npm run build` in `.next/` gespeichert
| Inhalt | Beschreibung |
| ---------------------- | -------------------------------------------------- |
| Kompilierte Seiten | Alle unter `/pages/` |
| API-Routen | Alles aus `pages/api/` |
| Assets aus `public/` | Werden im Build nicht verändert, aber ausgeliefert |
| CSS-Dateien (Tailwind) | Werden gebundelt und minimiert |
| `.env.local` | Wird eingelesen, aber nicht exportiert |
| JS/TS-Quellcode | Wird zu Client- und Server-Bundles kompiliert |
---
## 🧹 Wird **nicht** in `.next/` aufgenommen
| Ordner/Datei | Zweck / Grund |
| --------------------------- | -------------------------------------------- |
| `__tests__`, `__mocks__` | Nur lokal für Tests, nicht im Build |
| `cypress/` | End-to-End-Tests, nur für lokale Entwicklung |
| `scripts/` | Hilfsskripte, nicht für Runtime relevant |
| `docs/` | Dokumentation, nur für Entwickler |
| `README.md`, `CHANGELOG.md` | Doku nicht erforderlich zur Laufzeit |
| `Jenkinsfile`, `.github/` | CI/CD wird vom Buildsystem verwendet |
---
## 📂 Empfohlene Struktur für Deployment (z.B. ZIP-Upload auf Server)
Nur folgende Dateien/Ordner übertragen:
```bash
.next/
public/
package.json
package-lock.json
.env.local
```

42
docs/docs/checklist.md Normal file
View File

@@ -0,0 +1,42 @@
<!-- /docs/checklist.md -->
# 🧾 Projektpflege-Checkliste
Diese Datei dient als persönliche Gedächtnisstütze bei der Entwicklung und Pflege des Projekts.
Bevor du einen Feature-, Refactor- oder Bugfix-Commit abschließt, geh diese Liste durch:
---
## 📝 Dokumentation
- [ ] Ist `README.md` noch aktuell (Projektziel, Setup, Nutzung)?
- [ ] Wurde `CHANGELOG.md` ergänzt (mit Datum, Version, Änderung)?
- [ ] Wurde ggf. ein neuer Punkt in `/docs/` ergänzt oder aktualisiert?
- [ ] Sind Beispiel-URLs oder sensible Daten **nicht im Code**, sondern dokumentiert?
---
## 📦 Konfiguration
- [ ] Ist `.env.local` aktuell und vollständig (für Entwickler/Testserver)?
- [ ] Wird jede Konfiguration ausschließlich über `.env.local` gesteuert?
---
## ✅ Codequalität & Git
- [ ] Ist die Git-Commit-Message beschreibend und lesbar (z.B. `feat:`, `fix:`, `docs:`)?
- [ ] Wurden unnötige Debug-Logs entfernt oder per `NODE_ENV` abgesichert?
- [ ] Wurden Änderungen getestet (lokal, ggf. auf Testsystem)?
---
## 🧭 Onboarding-freundlich?
- [ ] Könnte ein neuer Entwickler mit den aktuellen Dokumenten verstehen, was wie funktioniert?
- [ ] Gibt es Hinweise zur Architektur, API-Flows oder Besonderheiten im Code?
---
Du kannst diese Checkliste in jedem Projekt beibehalten und auf deine Arbeitsweise anpassen.

View File

@@ -0,0 +1,77 @@
<!-- /docs/components/README.md -->
# 🧩 `components/` Übersicht über alle UI-Komponenten
Dieses Verzeichnis enthält die gesamten React-Komponenten der TALAS-Kartenanwendung.
Sie sind thematisch gegliedert in Teilbereiche für Kontextmenüs, POIs, Polylinien, Modale und die zentrale `MapComponent`.
---
## 📁 Strukturübersicht
```bash
components/
├── contextmenu/ # Komponenten für rechte Maustaste & Kontextaktionen
│ ├── CoordinatePopup.js
│ └── useMapContextMenu.js
├── gisPolylines/ # Polylinien (Kabelstrecken)
│ ├── PolylineContextMenu.js
│ └── icons/
│ ├── CircleIcon.js
│ ├── EndIcon.js
│ ├── StartIcon.js
│ └── SupportPointIcons.js
├── icons/devices/overlapping/ # Zusätzliche Overlap-Icons für Geräte
│ └── PlusRoundIcon.js
├── mainComponent/ # Hauptkomponenten für Karteninitialisierung
│ ├── MapComponent.js
│ └── hooks/
│ └── useInitializeMap.js
├── pois/ # POI-spezifische Modale
│ ├── AddPOIModal.js
│ └── PoiUpdateModal.js
├── uiWidgets/ # UI-Widgets
│ ├── CoordinateInput.js
│ ├── VersionInfoModal.js
│ ├── TestScript.js
│ └── mapLayersControlPanel/
│ ├── EditModeToggle.js
│ └── MapLayersControlPanel.js
```
---
## 🔎 Beschreibung der Hauptbereiche
### `contextmenu/`
Rechtsklick-Menüs für Marker, POIs, Polylinien. Steuert Anzeige & Verhalten.
### `gisPolylines/`
Komponenten für das Zeichnen, Bearbeiten und Interagieren mit Linien/Strecken.
### `mainComponent/`
Zentrale Leaflet-Map-Logik & Initialisierung via `MapComponent` und `useInitializeMap`.
### `pois/`
Modale für das Hinzufügen und Bearbeiten von POIs (Points of Interest).
### `uiWidgets/`
Komponenten wie Eingabefelder für Koordinaten-Suche, Infoboxen und Control Panel für Geräte Layers .
---
## ✅ Besonderheiten
- Verwendet **Tailwind CSS** für Styling
- Integration mit Redux, Leaflet, OverlappingMarkerSpiderfier
- Vollständig modular & testbar aufgebaut

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

View File

@@ -0,0 +1,32 @@
<!-- /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
🔙 [Zurück zur Übersicht](./README.md)

View File

@@ -0,0 +1,43 @@
<!-- /docs/components/contextmenu/README.md -->
# 🖱️ `contextmenu/` Kontextmenü-Komponenten
Dieses Verzeichnis enthält Komponenten und Hooks zur Anzeige und Steuerung von Kontextmenüs in der Leaflet-Kartenanwendung. Sie dienen der Interaktion mit POIs, Koordinaten und Layer-Objekten per Rechtsklick.
---
## 📂 Enthaltene Dateien
| Datei | Beschreibung |
| ------------------------------------------------ | ---------------------------------------------------------------------- |
| [`CoordinatePopup.js`](./CoordinatePopup.md) | Zeigt ein kleines Kontextfenster mit Koordinaten und Copy-Funktion |
| [`useMapContextMenu.js`](./useMapContextMenu.md) | Hook zur Initialisierung und Verwaltung des Kontextmenüs auf der Karte |
---
## 🔄 Verwendung
Diese Komponenten sind typischerweise eingebunden in:
- [`MapComponent.js`](../mainComponent/MapComponent.md)
- [`PolylineContextMenu.js`](../gisPolylines/PolylineContextMenu.md)
- Marker- und Linienfunktionen aus `setupDevices`, `setupPolylines`
---
## 🎯 Ziel
Ermöglicht einfache Benutzerinteraktion mit:
- Geräten
- Koordinaten
- POIs
- Streckenabschnitten
---
## 📚 Weitere Dokumentation
Alle Markdown-Dateien für Komponenten befinden sich im `/docs/components/contextmenu/` Verzeichnis.
🔙 [Zurück zu `components`](../README.md)

View File

@@ -0,0 +1,30 @@
<!-- /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
🔙 [Zurück zu contextmenu ](./README.md)

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.

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×10px, IconSize 25×25px (wegen Klickfläche)
- Klasse: `custom-circle-icon`
## Verwendung
Wird in Polylinien als Zwischenpunkt gesetzt. Inaktiv, aber sichtbar.

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×14px
- Klasse: `custom-end-icon`
## Verwendung
Wird am letzten Punkt einer Linie gesetzt, z.B. `lineData.coordinates[line.length - 1]`

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×18px
- Klasse: `custom-start-icon`
## Verwendung
Wird am ersten Punkt einer Polyline platziert.

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×24px
## RemoveSupportPointIcon
- Roter Kreis mit weißem Rand und Minuszeichen
- `iconSize`: 24×24px
## Verwendung
- Hinzufügen/Entfernen von Zwischenpunkten in der Bearbeitungsansicht (editMode)
- Marker erscheinen z.B. bei Maus-Hover oder per Kontextmenü

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

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`

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`

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`

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

View File

@@ -0,0 +1,101 @@
<!-- /docs/components/uiWidgets/CoordinateInput.md -->
# 📍 CoordinateInput.js
Die Komponente `CoordinateInput` stellt ein einfaches Eingabefeld für geografische Koordinaten (Latitude, Longitude) bereit.
Sie dient typischerweise dazu, einen bestimmten Punkt auf der Karte zu fokussieren bzw. zu markieren.
---
## 🔧 Pfad
```bash
/components/uiWidgets/CoordinateInput.js
```
---
## 🎯 Zweck
- Eingabe von Koordinaten (z.B. `53.2,8.1`)
- Übergabe dieser Koordinaten an eine Callback-Funktion zur weiteren Verarbeitung
- Positioniert sich dauerhaft in der linken oberen Ecke der Seite (z.B. zur schnellen Navigation)
---
## ⚙️ Props
| Prop | Typ | Beschreibung |
| --------------------- | ---------- | ------------------------------------------------------------------------------------- |
| `onCoordinatesSubmit` | `function` | Wird beim Abschicken des Formulars mit dem eingegebenen Koordinaten-String aufgerufen |
---
## 🧩 Interne Logik
```js
const [coordinates, setCoordinates] = useState("");
```
- Der Eingabewert wird im lokalen State gespeichert
- Beim Submit (`onSubmit`) wird `onCoordinatesSubmit(coordinates)` aufgerufen, wenn gesetzt
---
## 🧰 UI-Aufbau
- Eingabefeld für Text: Erwartet `lat,lng`
- Button: „Zu Marker zoomen“
- Position: `fixed top-5 left-5` → dauerhaft sichtbar
---
## 🎨 Gestaltung (Tailwind CSS)
| Element | Klassen |
| --------- | ---------------------------------------------------------------- |
| Container | `fixed top-5 left-5 z-50 bg-white shadow-lg rounded-lg p-4 w-72` |
| Input | `border p-2 rounded w-full mb-2` |
| Button | `bg-blue-500 text-white p-2 rounded w-full hover:bg-blue-600` |
---
## 🧪 Testfälle
| Eingabe | Erwartung |
| -------------------------- | --------------------------------------------------------- |
| `53.2,8.1` | Callback `onCoordinatesSubmit("53.2,8.1")` wird ausgelöst |
| Leer | Callback wird ausgelöst mit leerem String |
| Buttonklick | Löst `handleSubmit()` aus |
| Enter-Taste im Eingabefeld | Löst ebenfalls Submit aus |
---
## 💡 Erweiterungsideen
- Validierung des Formats (`lat,lng`) vor dem Absenden
- Automatisches Zentrieren der Leaflet-Karte in der Callback-Funktion
- Optionale Markierung des Punkts auf der Karte
---
## 📄 Verwendung
Beispiel in einer Map-Komponente:
```jsx
<CoordinateInput
onCoordinatesSubmit={(coords) => {
const [lat, lng] = coords.split(",").map(Number);
map.setView([lat, lng], 16); // Leaflet
}}
/>
```
---
## 📦 Verwandte Komponenten
- `MapComponent.js` kann die übergebenen Koordinaten zur Zentrierung oder Marker-Erstellung nutzen
---

View File

@@ -0,0 +1,92 @@
<!-- /docs/components/uiWidgets/VersionInfoModal.md -->
# 🪪 VersionInfoModal.js
Das `VersionInfoModal` ist ein modales Fenster zur Anzeige von Unternehmensinformationen und der aktuellen App-Version.
Es wird meist im Footer oder als Info-Schaltfläche in der Benutzeroberfläche eingeblendet.
---
## 🔧 Pfad
```bash
/components/uiWidgets/VersionInfoModal.js
```
---
## 🎯 Zweck
Die Komponente informiert Nutzer über:
- Die **aktuelle TALAS.Map Version**
- Die **Firmenadresse und Kontaktdaten** der Littwin Systemtechnik GmbH & Co. KG
- Eine zentral platzierte Grafik mit dem TALAS-Logo
- Eine Schaltfläche zum Schließen des Modals
---
## ⚙️ Props
| Prop | Typ | Beschreibung |
| ----------------------- | ---------- | -------------------------------------------------------------- |
| `showVersionInfoModal` | `boolean` | Steuert, ob das Modal angezeigt wird |
| `closeVersionInfoModal` | `function` | Callback zum Schließen des Modals |
| `APP_VERSION` | `string` | Versionstext (z.B. `1.1.188`), meist aus `.env.local` geladen |
---
## 💡 Verhalten
- Wird `showVersionInfoModal` auf `true` gesetzt, erscheint das Modal zentriert über einem halbtransparenten Overlay
- Klick auf den Hintergrund (schwarzes Overlay) oder auf „Schließen“ führt `closeVersionInfoModal()` aus
---
## 🧩 Inhalt im Modal
```plaintext
+--------------------------+
| [Logo_TALAS.png] |
| Littwin GmbH Adresse |
| Telefon & E-Mail |
| Version: 1.1.188 |
| [Schließen] Button |
+--------------------------+
```
---
## 🎨 Gestaltung
- Modal-Layout mit Tailwind CSS (`fixed`, `z-50`, `bg-white`, `rounded`, `shadow`)
- Schaltfläche `Schließen` reagiert auf Hover mit Farbwechsel (`hover:bg-blue-700`)
- Design folgt der UI-Ästhetik von TALAS.web
---
## 🧪 Testfälle
| Bedingung | Erwartung |
| ------------------------------- | ----------------------------------------- |
| `showVersionInfoModal = true` | Modal wird angezeigt |
| Klick auf Hintergrund | Modal wird geschlossen |
| Klick auf „Schließen“-Button | Modal wird geschlossen |
| Version `APP_VERSION = 1.1.188` | Text „TALAS.Map Version 1.1.188“ sichtbar |
---
## 📦 Verknüpfte Dateien
- `.env.local` enthält z.B. `NEXT_PUBLIC_APP_VERSION=1.1.188`
- Aufruf in `Footer` oder `Layout` zur Anzeige bei Klick auf „Version“
---
## 🛠 Verbesserungsideen
- ESC-Taste als Schließen-Funktion ergänzen
- Option für dynamische Anzeige von Changelog-Link
- Automatischer Import von Version via `process.env.NEXT_PUBLIC_APP_VERSION`
---

View File

@@ -0,0 +1,85 @@
<!-- /docs/components/uiWidgets/mapLayersControlPanel/EditModeToggle.md -->
# ✏️ EditModeToggle.js
Die Komponente `EditModeToggle` stellt einen interaktiven Umschalter für den Bearbeitungsmodus bereit.
Sie ermöglicht das Ein- und Ausschalten des Modus, in dem POIs, Polylines (Strecken) und Bereiche bearbeitet werden können.
---
## 📦 Pfad
```bash
/components/uiWidgets/mapLayersControlPanel/EditModeToggle.js
```
---
## 🧩 Zweck
Der Bearbeitungsmodus wirkt sich auf die Interaktivität der Map aus:
- Wenn **aktiv**:
- Checkboxen für Layer sind deaktiviert
- POI-Funktionen (Hinzufügen, Verschieben, Löschen) werden ermöglicht
- Wenn **inaktiv**:
- Keine Bearbeitung möglich
- UI ist auf Betrachtung beschränkt
---
## 🖱 Verhalten
Beim Klick auf das Icon:
1. Wird der lokale Zustand `editMode` umgeschaltet
2. `localStorage` speichert den neuen Status (`true` oder `false`)
3. Die Seite wird neu geladen (`window.location.reload()`), um globale Effekte zu aktivieren
---
## 🧠 Interner Zustand
```js
const [editMode, setEditMode] = useState(() => localStorage.getItem("editMode") === "true");
```
- Initialisiert aus `localStorage`
- Persistente Speicherung des Zustands browserseitig
- Aufruf in anderen Komponenten (z.B. `MapLayersControlPanel.js`) basiert ebenfalls auf diesem Wert
---
## 🧰 UI-Darstellung
- Verwendet **Material-UI-Icons**:
- 🟢 `ModeEditIcon`: Bearbeitungsmodus **aus** → wird angeboten zum **Aktivieren**
- 🔴 `EditOffIcon`: Bearbeitungsmodus **ein** → wird angeboten zum **Deaktivieren**
- Tooltip informiert den Nutzer über die jeweilige Aktion
---
## 🧪 Testfälle
| Zustand | Erwartetes Verhalten |
| ------------------ | ------------------------------------------------------ |
| `editMode = false` | Icon: ✏️ → Tooltip: „Bearbeitungsmodus aktivieren“ |
| `editMode = true` | Icon: 🚫✏️ → Tooltip: „Bearbeitungsmodus deaktivieren“ |
| Klick auf Icon | Status umschalten, Seite neu laden |
---
## 💡 Erweiterungsideen
- 🔄 Statt `window.location.reload()` → globalen Zustand über Redux-Dispatch steuern
- 📢 Feedback-Toast nach Umschalten anzeigen (z.B. „Bearbeitungsmodus aktiviert“)
- 🧩 Integration in Redux-Store zur globalen Synchronisierung ohne Reload
---
## 📄 Verwandte Komponenten
- `MapLayersControlPanel.js`: liest `localStorage.editMode` und deaktiviert Layer-Checkboxen im aktiven Modus
- `PoiUpdateModal`, `AddPOIModal`: nutzen den Bearbeitungsmodus für UI-Freigabe
---

View File

@@ -0,0 +1,150 @@
<!-- /docs/components/uiWidgets/mapLayersControlPanel/MapLayersControlPanel.md -->
# 🧭 MapLayersControlPanel.js
Dieses UI-Widget zeigt eine interaktive Steuereinheit für Layer, POIs und Stationsbereiche auf der rechten Seite der Karte.
Es ist vollständig an den Redux-Store angebunden und reagiert auf Änderungen der Layer-Sichtbarkeit, Bearbeitungsmodus und Stationsauswahl.
---
## 🔧 Pfad
```bash
/components/uiWidgets/mapLayersControlPanel/MapLayersControlPanel.js
```
---
## 📌 Zweck
Das `MapLayersControlPanel` ermöglicht Nutzern:
- Die Auswahl eines Stationsbereichs (Dropdown)
- Das Aktivieren/Deaktivieren einzelner GIS-Systeme (Checkboxen)
- Das Anzeigen von POIs oder Kabelstrecken (TALAS-spezifisch)
- Das Ein-/Ausschalten des Bearbeitungsmodus
- Die Steuerung der Karten-Zentrierung über ein Icon
---
## 🧠 Verwendete Redux-Slices
| Slice | Zweck |
| -------------------------------- | ----------------------------------------------------------- |
| `gisStationsStaticDistrictSlice` | Enthält die Gerätebereiche (mit `.Points`) |
| `gisSystemStaticSlice` | Enthält die konfigurierten GIS-Systeme mit Anzeigeerlaubnis |
| `mapLayersSlice` | Speichert die Sichtbarkeit aller Layer |
| `poiLayerVisibleSlice` | Steuert Sichtbarkeit der POIs |
| `polylineLayerVisibleSlice` | Steuert Sichtbarkeit der Kabelstrecken (TALAS) |
| `zoomTriggerSlice` | Löst Neuzentrierung der Karte aus |
| `selectedAreaSlice` | Speichert den gewählten Bereich/Station |
---
## 🔄 Logikübersicht
- **Dropdown Stationsauswahl:**
Wird dynamisch aus `GisStationsStaticDistrict.Points` befüllt
Nur eindeutige `Area_Name`, wenn `System` erlaubt ist
- **Checkboxen für Layer:**
Zeigen alle Systeme aus `GisSystemStatic`, bei denen `Allow === 1`
Sonderfall: `TALAS` erhält ein Untermenü für „Kabelstrecken“
- **Lokale Speicherung:**
Sichtbarkeiten, Bearbeitungsmodus und POI-Zustand werden in `localStorage` geschrieben und bei Initialisierung geladen
- **Bearbeitungsmodus:**
Wenn aktiv (`editMode === true`), sind Layer-Checkboxen deaktiviert
---
## 📥 Wichtige Funktionen
| Funktion | Zweck |
| -------------------------------- | ---------------------------------------- |
| `handleAreaChange()` | Setzt `selectedArea` im Redux Store |
| `handleCheckboxChange()` | Schaltet Sichtbarkeit einzelner Layer |
| `handlePolylineCheckboxChange()` | Aktiviert Sichtbarkeit von Kabelstrecken |
| `handlePoiCheckboxChange()` | Aktiviert Sichtbarkeit von POIs |
| `handleIconClick()` | Setzt Station zurück und triggert Zoom |
---
## 🧩 UI-Struktur
```plaintext
[Dropdown: Station wählen]
[🟩 EditModeToggle] [🔍 Expand-Icon]
[ ] GIS-System 1
[ ] GIS-System 2
└─ [ ] Kabelstrecken (falls "TALAS")
[ ] POIs
```
---
## 🐞 Debug-Hinweise
- Debug-Logs:
`console.log("🔍 GisStationsStaticDistrict Inhalt:", ...)`
werden ausgegeben, um sicherzustellen, dass Daten korrekt geladen wurden
- Warnungen:
Falls `.Points` nicht vorhanden ist, wird dies in der Konsole gewarnt
---
## 🛠 ToDos / Erweiterungsideen
- Checkboxen für Bereiche („Bereiche“, „Standorte“) sind bereits vorbereitet, aber auskommentiert
- Möglichkeit, Tooltips zu aktivieren/deaktivieren?
- Gruppierung von Layern nach Typ (z.B. Linien, Geräte, POIs)
---
## 📄 Verwendete Komponenten
- `EditModeToggle` Schaltfläche für Umschalten des Bearbeitungsmodus
---
## ✅ Zustand: Lokal & Global
- **Global:** `useSelector(...)` aus Redux
- **Lokal:** `useState(...)` für editMode, stationListing, systemListing
---
## 📦 LokaleStorage-Keys
| Key | Beschreibung |
| --------------------- | ------------------------------------------ |
| `poiVisible` | Sichtbarkeit der POI-Marker |
| `polylineVisible` | Sichtbarkeit der Kabelstrecken |
| `mapLayersVisibility` | Sichtbarkeiten der einzelnen Systeme |
| `editMode` | Zustand des Bearbeitungsmodus (true/false) |
---
## 🧪 Testempfehlung
- Dropdown zeigt erwartete `Area_Name`-Werte?
- Layer-Checkboxen werden korrekt gespeichert?
- Bei `TALAS` erscheint zusätzlich: „Kabelstrecken“?
- Bei Wechsel der Station wird `setSelectedArea` ausgelöst?
---
## 🧩 Verknüpfte Dateien
- `redux/slices/webservice/gisStationsStaticDistrictSlice.js`
- `redux/slices/webservice/gisSystemStaticSlice.js`
- `redux/slices/mapLayersSlice.js`
- `redux/slices/selectedAreaSlice.js`
- `redux/slices/database/polylines/polylineLayerVisibleSlice.js`
- `redux/slices/database/pois/poiLayerVisibleSlice.js`
---

View File

@@ -0,0 +1,38 @@
<!-- /docs/config/README.md -->
# ⚙️ Konfigurationsübersicht (/config)
Dieses Verzeichnis enthält zentrale Konfigurationsdateien, die das Verhalten der gesamten App steuern.
Hier sind die wichtigsten Dateien, ihre Aufgaben und Verlinkungen zur Dokumentation:
---
## 📦 [`appVersion.js`](./appVersion.md)
- Definiert die aktuelle Version der App (`APP_VERSION`)
- Wird z.B. im `VersionInfoModal` angezeigt
---
## 🗺️ [`layers.js`](./layers.md)
- Enthält alle Leaflet-Layergruppen für die Kartenanzeige
- Zentrale Steuerung der aktiven Layer: TALAS, GMA, Cisco, etc.
---
## 📁 [`paths.js`](./paths.md)
- Berechnet den Basis-Pfad aus `.env.local`
- Liefert `BASE_URL`, z.B. `/talas5`
---
## 🌐 [`urls.js`](./urls.md)
- Erzeugt dynamisch API- und Tile-URLs
- Verwendet `window.location.origin` → keine statischen Ports notwendig
---
Diese Konfiguration macht das Projekt flexibel für mehrere Hosting-Umgebungen.

View File

@@ -0,0 +1,16 @@
<!-- /docs/config/appVersion.md -->
# 📦 appVersion.js
Diese Datei exportiert die aktuelle App-Version, die an mehreren Stellen in der UI angezeigt werden kann z.B. im `VersionInfoModal`.
## Inhalt
```js
export const APP_VERSION = "1.1.193";
```
## Verwendung
- Im Footer oder Info-Fenster
- Vergleich von Client- vs. Serverversion

View File

@@ -0,0 +1,60 @@
<!-- /docs/config/config.md -->
# ⚙️ config.js zentrale Konfiguration und Umgebungssteuerung
## Zweck
Diese Datei enthält zentrale Konfigurationswerte, die abhängig von der Umgebung
(Entwicklung oder Produktion) dynamisch erzeugt werden.
---
## Ersetzungen von Umgebungsvariablen
Vorher wurden folgende `.env.local` Variablen verwendet:
- `NEXT_PUBLIC_BASE_URL`
- `NEXT_PUBLIC_SERVER_URL`
Diese wurden ersetzt durch dynamische Berechnung anhand von:
```env
NEXT_PUBLIC_API_PORT_MODE=dev
```
---
## Dynamische Berechnung von `serverURL`
Die Konfiguration entscheidet anhand des Modus:
```js
const mode = process.env.NEXT_PUBLIC_API_PORT_MODE;
const serverURL = mode === "dev" ? `${window.location.protocol}//${window.location.hostname}:80` : `${window.location.origin}`;
```
→ Dadurch funktioniert der Code ohne Anpassung bei IP-/Server-Wechseln oder Portunterschieden.
---
## Konfigurationswerte
- `USE_MOCK_API`: aktiviert lokale Mock-Daten
- `serverURL`: Basis für Webservice-Aufrufe (`/talas5/...`)
- `mapGisStationsStaticDistrictUrl`: komplette zusammengesetzte URL
- `useMockStationData`: true/false aus `.env.local`
---
## Vorteile
| Punkt | Vorteil |
| ------------------------------- | ---------------------------------------- |
| Keine festen IPs oder Ports | ✅ Weniger Fehler, einfacher Umzug |
| Einheitlich mit anderen Dateien | ✅ Gleiche Struktur wie Webservice-Setup |
| Lesbar & leicht anpassbar | ✅ Auch ohne Doku sofort verständlich |
---
📄 Pfad: `/docs/frontend/config/config.md`

View File

@@ -0,0 +1,21 @@
<!-- /docs/config/layers.md -->
# 🗺️ layers.js
Diese Datei definiert alle verfügbaren Leaflet-Layergruppen im Projekt.
Sie werden global als `MAP_LAYERS` exportiert und enthalten alle Systemtypen (TALAS, GMA, OTDR etc.).
## Struktur
```js
export const MAP_LAYERS = {
TALAS: new L.layerGroup(),
...
lineLayer: new L.LayerGroup(),
};
```
## Verwendung
- Initialisierung der Leaflet-Karte
- Zuweisung von Markern und Linien

19
docs/docs/config/paths.md Normal file
View File

@@ -0,0 +1,19 @@
<!-- /docs/config/paths.md -->
# 📁 paths.js
Berechnet den sauberen `BASE_URL`-Pfad basierend auf `.env.local → NEXT_PUBLIC_BASE_PATH`.
Entfernt führende und abschließende Slashes.
## Beispiel
Wenn `NEXT_PUBLIC_BASE_PATH = "/talas5/"`, wird `BASE_URL = "/talas5"` gesetzt.
```js
const BASE_PATH = basePathRaw.replace(/^\/|\/$/g, "");
export const BASE_URL = BASE_PATH ? `/${BASE_PATH}` : "";
```
## Nutzung
- Für konsistente Pfadangaben im gesamten Projekt

18
docs/docs/config/urls.md Normal file
View File

@@ -0,0 +1,18 @@
<!-- /docs/config/urls.md -->
# 🌐 urls.js
Diese Datei berechnet dynamisch URLs basierend auf `window.location.origin`.
Alle Endpunkte (API, Tiles, Server) werden ohne Port oder Hardcoding erzeugt.
## Exportierte Konstanten
- `BASE_URL``/api`
- `SERVER_URL` → Hostname ohne Port (für Links)
- `PROXY_TARGET` → z.B. `http://hostname:4000`
- `OFFLINE_TILE_LAYER` → Offline-Kachelpfad
- `MAP_TILES_LAYER` → Alias für `OFFLINE_TILE_LAYER`
## Hinweis
Alle Berechnungen erfolgen nur **clientseitig** (`typeof window !== "undefined"`).

7
docs/docs/env.local..md Normal file
View File

@@ -0,0 +1,7 @@
<!-- /docs/env.local -->
### /docs/env.local.schema.md
- `NEXT_PUBLIC_API_HOST` → Webservice-DNS oder IP
- `NEXT_PUBLIC_API_BASE_PATH` → z.B. `talas5`, per Deployment steuerbar
- `DB_NAME` → hängt vom Kundenprojekt ab

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()`

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(...)`

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

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

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(...)`

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

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

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ü

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`

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(...)`

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

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(...)`

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

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

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

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

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

View File

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

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

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

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.

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

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`

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

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.

View File

@@ -0,0 +1,56 @@
<!-- /docs/nssm-exe-installation.md -->
````markdown
- Als Administrator Eingabeaufforderung oder PowerShell öffnen
- Navigiere zu dem NodeMap Projekt Verzeichnis:
```shell
C:\Users\Administrator>cd C:\inetpub\wwwroot\talas5\nodeMap
```
````
- Befehl zum Erstellen eines Dienstes:
Führen Sie den folgenden Befehl aus, um einen neuen Dienst zu erstellen:
```shell
nssm.exe install NodeMapService
```
Nachdem Sie diesen Befehl ausgeführt haben, öffnet sich ein NSSM-Dialogfenster.
**Dienstkonfiguration:**
In dem geöffneten NSSM-Dialogfenster müssen Sie einige Parameter angeben:
- **Path:** Der Pfad zur ausführbaren Datei, die der Dienst ausführen soll.
```shell
C:\inetpub\wwwroot\talas5\nodeMap\StartNodeApp.bat
```
- **Startup directory:** Das Verzeichnis, in dem die Anwendung gestartet werden soll.
```shell
C:\inetpub\wwwroot\talas5\nodeMap
```
- **Arguments:** kann leer gelassen werden.
- Dienst starten:
Sobald der Dienst erstellt wurde, können Sie ihn starten.
Das können Sie entweder über die Eingabeaufforderung oder über die Diensteverwaltung von Windows tun.
Um den Dienst über die Eingabeaufforderung zu starten, verwenden Sie den folgenden Befehl:
```shell
nssm.exe start DienstName
```
---
- **Dienst bearbeiten:**
```shell
nssm.exe edit NodeMapService
```
- **Dienst entfernen:**
```shell
nssm.exe remove NodeMapService confirm
```
dauert bis 1 Minute
```
```

26
docs/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
```

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
```

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
```

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

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
```

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
```

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
```

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

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

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

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": "...",
...
}
]
```

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
}
]
```

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

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

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" }
```

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" }
]
```

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

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 }`

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

View File

@@ -0,0 +1,83 @@
<!-- Datei: /docs/pages/api/talas_v5_DB/priorityConfig.md -->
# 📊 API: /api/talas_v5_DB/priorityConfig
Diese API liefert die Konfigurationsdaten für Prioritäten (z.B. „critical“, „minor“) aus der Tabelle `prio`.
Sie wird u.a. für Meldungsanzeigen, Filter und Leaflet-Marker-Priorisierung verwendet.
---
## 📍 Anwendung in Leaflet Marker-Priorität bei Überlappung
Die `level`-Werte dieser Konfiguration steuern die **Darstellungsreihenfolge überlappender Marker** in Leaflet:
- Marker mit **höherer Priorität** (`level = 1`, z.B. `critical`) werden **oben** dargestellt
- Marker mit **niedriger Priorität** (`level = 100`, `101`) werden **weiter hinten** gezeichnet
- Dadurch bleiben wichtige Meldungen stets sichtbar, selbst bei POI-Überlagerung
Diese Sortierung wird z.B. bei OverlappingMarkerSpiderfier oder Clustern angewendet.
---
## 🔗 Route
- **Pfad:** `/api/talas_v5_DB/priorityConfig`
- **Methode:** `GET`
- **Beschreibung:** Gibt alle aktiven Prioritätsstufen inkl. Farbcodes zurück
---
## 🧾 Beispielantwort
**Test-URL:** [`/api/talas_v5_DB/priorityConfig`](http://10.10.0.70:3000/api/talas_v5_DB/priorityConfig)
```json
[
{ "idprio": 0, "level": 100, "name": "kein", "color": "#ffffff" },
{ "idprio": 1, "level": 101, "name": "gut", "color": "#99CC00" },
{ "idprio": 5, "level": 1, "name": "critical", "color": "#FF0000" },
{ "idprio": 7, "level": 2, "name": "major", "color": "#FF9900" },
{ "idprio": 9, "level": 3, "name": "minor", "color": "#FFFF00" },
{ "idprio": 10, "level": 4, "name": "system", "color": "#FF00FF" },
{ "idprio": 12, "level": 0, "name": "Stationsausfall", "color": "#FF6600" }
]
```
📦 Datenstruktur
Feld Typ Beschreibung
idprio number Eindeutige ID der Priorität
level number Prioritätsstufe (1 = hoch, 100 = niedrig)
name string Bezeichnung (z.B. "minor", "system", "Stationsausfall")
color string HEX-Farbcode (z.B. #FF0000) zur visuellen Darstellung
⚙️ Datenquelle
Tabelle: prio
SQL-Abfrage:
sql
SELECT idprio, level, name, color FROM prio;
Backend: verwendet getPool() aus utils/mysqlPool.js
## 🔗 Verwendet in
| Datei | Zweck |
| ----------------------------- | ------------------------------------------------------------------- |
| `fetchPriorityConfigThunk.js` | Holt Prioritätsdaten über API und reicht sie an Redux weiter |
| `priorityConfigSlice.js` | Speichert die geladenen Prioritätsdaten im Redux-Store |
| `MapComponent.js` | Dispatcht Thunk zum Laden der Daten beim Start |
| `useMapComponentState.js` | Liest `priorityConfig` aus Redux und gibt es an Marker-Setup weiter |
| `createAndSetDevices.js` | Erzeugt Marker mit `zIndexOffset` basierend auf Priorität |
| `useCreateAndSetDevices.js` | Hook zur Initialisierung von Geräten auf der Karte |
| `useDynamicMarkerLayers.js` | Verwaltet Marker-Layer dynamisch (inkl. Z-Priorität) |
❌ Fehlerbehandlung
Bei DB- oder Verbindungsfehlern:
json
Copy
Edit
{ "error": "Fehler bei der Abfrage" }
HTTP-Statuscode: 500

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

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/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`

View File

@@ -0,0 +1,40 @@
<!-- /docs/redux/slices/database/area/updateAreaSlice.md -->
# 🧩 updateAreaSlice.js
Redux-Slice zur Verwaltung des Update-Zustands beim Aktualisieren eines Bereichs (Area).
---
## Zustand
```js
{
status: "idle" | "loading" | "succeeded" | "failed",
error: string | null
}
```
---
## Thunk
- `updateAreaThunk`: Führt den API-Call zum Speichern von `x`, `y` für `idLocation` & `idMaps` durch.
---
## Aktionen
- `resetUpdateAreaStatus()`: Setzt Status auf `"idle"` und entfernt Fehler
---
## Verwendung
In der Komponente `useAreaMarkersLayer.js` beim Ziehen und Speichern von Stationsmarkern.
---
## Fehlerbehandlung
- Fehlernachricht wird in `error` gespeichert, falls `updateAreaThunk` fehlschlägt.

View File

@@ -0,0 +1,45 @@
<!-- /docs/redux/slices/database/locationDevicesSlice.md -->
# 🧩 locationDevicesSlice.js
Redux-Slice zur Verwaltung von Standortgeräten (Devices) aus der Tabelle `location_device`.
---
## Zustand
```js
{
data: [],
status: "idle" | "loading" | "succeeded" | "failed",
error: string | null
}
```
---
## Thunks
- `fetchLocationDevicesThunk`: Lädt Geräte aus der API
---
## Aktionen
- `clearLocationDevices()`: Löscht Geräte-Array und setzt Status zurück
---
## Selektoren
```js
selectLocationDevices = (state) => state.locationDevices.data;
selectLocationDeviceStatus = (state) => state.locationDevices.status;
```
---
## Besonderheiten
- Zustand wird bei `pending`, `fulfilled` und `rejected` aktualisiert
- Fehlernachricht wird in `error` gespeichert

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
```

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`

View File

@@ -0,0 +1,3 @@
# 🧩 addPoiOnPolylineSlice.js
Redux-Slice zur Verwaltung von addPoiOnPolyline.

View File

@@ -0,0 +1,3 @@
# 🧩 addPoiSlice.js
Redux-Slice zur Verwaltung von addPoi.

View File

@@ -0,0 +1,3 @@
# 🧩 currentPoiSlice.js
Redux-Slice zur Verwaltung von currentPoi.

View File

@@ -0,0 +1,3 @@
# 🧩 poiIconsDataSlice.js
Redux-Slice zur Verwaltung von POIIconsData.

View File

@@ -0,0 +1,3 @@
# 🧩 poiLayerVisibleSlice.js
Redux-Slice zur Verwaltung von POILayerVisible.

View File

@@ -0,0 +1,3 @@
# 🧩 poiMarkersSlice.js
Redux-Slice zur Verwaltung von POIMarkers.

View File

@@ -0,0 +1,3 @@
# 🧩 poiReadFromDbTriggerSlice.js
Redux-Slice zur Verwaltung von POIReadFromDbTrigger.

View File

@@ -0,0 +1,3 @@
# 🧩 poiTypSlice.js
Redux-Slice zur Verwaltung von POITyp.

View File

@@ -0,0 +1,3 @@
# 🧩 poiTypesSlice.js
Redux-Slice zur Verwaltung von POITypes.

View File

@@ -0,0 +1,3 @@
# 🧩 readPoiMarkersStoreSlice.js
Redux-Slice zur Verwaltung von readPoiMarkersStore.

View File

@@ -0,0 +1,3 @@
# 🧩 selectedPoiSlice.js
Redux-Slice zur Verwaltung von selectedPoi.

View File

@@ -0,0 +1,25 @@
<!-- /docs/redux/slices/database/polylines/gisLinesSlice.md -->
# 🧩 gisLinesSlice.js
Verwaltet alle Linienobjekte, die aus der Datenbank (`gis_lines`) gelesen wurden.
## Zustand
```js
{
data: [],
status: "idle" | "loading" | "succeeded" | "failed",
error: string | null
}
```
## Thunk
- `fetchGisLinesThunk()`
## Selector
```js
selectGisLines = (state) => state.gisLines.data
```

View File

@@ -0,0 +1,25 @@
<!-- /docs/redux/slices/database/polylines/polylineContextMenuSlice.md -->
# 🧩 polylineContextMenuSlice.js
Verwaltet den Zustand des Kontextmenüs bei Polylinien (z.B. Stützpunkt hinzufügen/entfernen).
## Zustand
```js
{
isOpen: false,
position: { lat, lng } | null,
forceClose: false,
timerStart: number | null,
countdown: number,
countdownActive: boolean
}
```
## Aktionen
- `openPolylineContextMenu(payload)`
- `closePolylineContextMenu()`
- `updateCountdown()`
- `forceCloseContextMenu()`

View File

@@ -0,0 +1,16 @@
<!-- /docs/redux/slices/database/polylines/polylineEventsDisabledSlice.md -->
# 🧩 polylineEventsDisabledSlice.js
Steuert, ob Interaktionen mit Polylinien (z.B. Ziehen, Klicks) temporär deaktiviert sind.
## Zustand
```js
{ disabled: boolean }
```
## Aktionen
- `setDisabled(boolean)`
- `toggleDisabled()`

View File

@@ -0,0 +1,21 @@
<!-- /docs/redux/slices/database/polylines/polylineLayerVisibleSlice.md -->
# 🧩 polylineLayerVisibleSlice.js
Steuert die Sichtbarkeit des Polylinienlayers auf der Karte.
## Zustand
```js
{ visible: boolean }
```
## Aktion
- `setPolylineVisible(boolean)`
## Selector
```js
selectPolylineVisible = (state) => state.polylineLayerVisible.visible
```

Some files were not shown because too many files have changed in this diff Show More