Versionsverwaltung

Mit der Versionsverwaltung von Aptli können Sie Karten und Schaltpläne offline bearbeiten — in U-Bahntunneln, an abgelegenen Standorten oder in Gebieten mit schlechter Netzabdeckung — und Ihre Änderungen einreichen, wenn Sie bereit sind. Das System erkennt Konflikte, wenn zwei Benutzer denselben Bereich bearbeitet haben, bewahrt eine permanente Versionshistorie für jeden Commit und stellt Administratoren eine Prüfwarteschlange zur Verfügung, bevor Feldbearbeitungen veröffentlicht werden. Diese Seite beschreibt die Verwendung der Versionssteuerelemente und die Konfliktlösung.

Schnittstelle für Versionskontrolle

Die Versionssteuerelemente befinden sich direkt in der Karten-Symbolleiste – auf dem Desktop in der ersten Symbolreihe neben der Modusauswahl und der Schaltfläche für die Datenübertragung, auf Mobilgeräten in der ersten Zeile der unteren Navigationsleiste. Das nebenstehende Bild zeigt das Desktop-Layout. Wenn Sie sich die Karten-Symbolleiste ansehen, finden Sie neben den Steuerelementen auch die Schaltfläche Datenübertragung (für Import/Export).

Versions-Symbolleiste

Primäre Steuerelemente:

Rückgängig – Die letzte Änderung in der aktuellen Sitzung rückgängig machen
Wiederherstellen – Eine rückgängig gemachte Änderung erneut anwenden
Neu synchronisieren – Daten vom Server neu laden, nicht festgeschriebene lokale Änderungen verwerfen
Einreichen – Alle nicht festgeschriebenen Änderungen an den Server übertragen

Badge für nicht festgeschriebene Änderungen:

Orangefarbenes Badge auf der Schaltfläche „Ausgewählte Features" zeigt die Anzahl der nicht festgeschriebenen Änderungen an
Wird reaktiv aktualisiert, wenn Sie Features erstellen/bearbeiten/löschen
Hilft dabei, ausstehende Arbeiten vor dem Einreichen zu verfolgen

Wie Versionierung funktioniert

(Serverimporte: Hintergrundaufgaben wie automatisierte Datenfeeds erstellen und committen ihre eigenen Versionen. Endbenutzer müssen diese nicht manuell laden – importierte Features werden einfach auf der Karte angezeigt, sobald der Auftrag abgeschlossen ist.)

Der Versions-/Commit-Ablauf

1. Entwurf erstellt     → Änderung existiert im Browser-Speicher
   ↓                     Feature hat das Flag _uncommitted
   
2. Offline bearbeiten   → Eigenschaften, Geometrie, Beziehungen ändern
   ↓                     Alle Änderungen werden lokal nachverfolgt
   
3. Einreichen           → Änderungen an den Server übertragen
   ↓                     Server erstellt Versionsdatensatz
   
4. Konfliktprüfung      → Server erkennt räumliche/ID-Konflikte
   ↓                     Option, Entwürfe anderer Benutzer anzuzeigen
   
5. Zusammenführen oder  → Änderungen akzeptieren oder rückgängig machen
   Zurücksetzen
   ↓
   
6. Version komprimiert  → Historischer Zustand für immer erhalten
                          Änderung wird dauerhafter Datensatz

Drei Systeme zur Änderungsverfolgung

Aptli verwendet je nach Workflow-Anforderungen unterschiedliche Muster:

1. Versionierte Modelle (Kartenfeatures, Layer, Schaltpläne):

Änderungen werden bis zum Einreichen im Browser-Speicher abgelegt
Das Flag _uncommitted verfolgt den Entwurfsstatus
Konflikte werden durch räumliche Analyse erkannt
Permanente Versionshistorie (wird nie gelöscht)

2. Echtzeit-Modelle (Aufträge, Berichte, Transaktionen):

Änderungen werden sofort auf dem Server gespeichert
Keine Offline-Entwürfe (Ausführung erfordert Bestätigung)
Keine Versionshistorie (Betriebsdaten)

3. Aufgaben (Hybrid):

Versioniert für die Planungsphase (Offline-Entwurf)
Echtzeit für die Ausführung (Zuweisungen umgehen Versionen)
Weitere Informationen finden Sie im Leitfaden zur Auftragsabwicklung

Verwendung der Versionssteuerelemente

Einreichen – Änderungen an den Server übertragen

Wann einreichen:

Am Ende der Arbeitssitzung (Fortschritt sichern)
Vor dem Wechsel zwischen Projekten (Änderungen beibehalten)
Nach größeren Bearbeitungen (Checkpoint erstellen)
Vor dem vollständigen Offline-Gehen (letzte Änderungen synchronisieren)

Was wird eingereicht:

Alle Features mit dem Flag _uncommitted
Layer-Änderungen
Änderungen an Schaltplan-Diagrammen
Aktualisierungen von Eigenschaften, Geometriebearbeitungen, neue Features
Alle an diese Datensätze angehängten Dateien (Fotos, Dokumente)

Hinweis: Serverseitige Importaufträge (z. B. nächtliche GeoJSON-Importe) erstellen ebenfalls automatisch Versionen. Diese erscheinen auf der Seite Admin → Versionen, und ihre Features werden für Benutzer sichtbar, sobald der Auftrag abgeschlossen ist, genau wie bei normalen Commits.

Arbeitsablauf:

1. Änderungen vornehmen (zeichnen, bearbeiten, Features importieren)
2. Anzahl des Nicht-festgeschrieben-Badges überwachen
3. Auf „Einreichen" klicken, wenn Sie bereit sind
4. Auf Konflikte prüfen (falls vorhanden)
5. Konflikte lösen oder Übermittlung akzeptieren

Registerkarte „Datenexport"

Commit anfordern & Admin-Überprüfung

Für Nicht-Administratoren fungiert die Schaltfläche „Einreichen" zunächst als Anfrage zur Überprüfung und nicht als sofortige Veröffentlichung. Wenn Sie Commit anfordern wählen, wird die Version mit submittedForReview gekennzeichnet und auf dem Server gespeichert; sie wird für andere Benutzer erst sichtbar, wenn ein Administrator sie genehmigt. Administratoren öffnen die neue Seite Admin → Versionen (siehe Administrationshandbuch), um eine Warteschlange mit ausstehenden Versionen anzuzeigen. Sie können die Version entweder committen (veröffentlichen) oder löschen. Dieser Workflow stellt sicher, dass Feldbearbeitungen überprüft werden, bevor sie auf den gemeinsamen Datensatz angewendet werden.

Dateianhänge

Alle Dateien, die Sie an einen Datensatz anhängen (Fotos, Dokumente usw.), werden lokal als Teil Ihrer aktuellen Version bereitgestellt. Sie werden automatisch hochgeladen, sobald die Version eingereicht wird, und sind im Commit-Prozess enthalten; wenn Sie Änderungen rückgängig machen oder verwerfen, werden die bereitgestellten Dateien entfernt. Technische Details zur Dateibereitstellung finden Sie in der Entwicklungsdokumentation.

Ergebnis:

Änderungen für alle Benutzer sichtbar
Versionsdatensatz auf dem Server erstellt
Flag _uncommitted entfernt
Badge-Zähler wird auf 0 zurückgesetzt

Rückgängig – Letzte Änderung rückgängig machen

Funktionsweise:

Geht die Änderungshistorie rückwärts durch
Funktioniert bei nicht festgeschriebenen lokalen Änderungen
Verwaltet den Redo-Stack (nach dem Rückgängigmachen kann wiederhergestellt werden)

Einschränkungen:

Betrifft nur Änderungen der aktuellen Sitzung
Eingereichte/committete Änderungen können nicht rückgängig gemacht werden (verwenden Sie stattdessen „Neu synchronisieren")
Der Verlauf wird beim Neuladen der Seite gelöscht

Anwendungsfälle:

„Hoppla, falsches Feature gelöscht"
„Muss einen anderen Ansatz ausprobieren"
„Feature versehentlich verschoben"

Wiederherstellen – Rückgängig gemachte Änderung erneut anwenden

Funktionsweise:

Geht den Änderungsverlauf vorwärts durch
Nur verfügbar nach „Rückgängig"
Wird gelöscht, wenn eine neue Änderung vorgenommen wird

Ablauf:

1. Rückgängig entfernt die Änderung
2. Wiederherstellen stellt sie wieder her
3. Je nach Bedarf weiter rückgängig machen/wiederherstellen
4. Neue Änderung vornehmen → löscht den Redo-Stack

Konfliktlösung

Wenn zwei Benutzer gleichzeitig dasselbe Feature bzw. dieselbe Version bearbeiten, wird oben auf der Karte eine Konfliktwarnung angezeigt.

Klicken Sie auf Konfliktdetails anzeigen, um eine Vergleichsansicht zu öffnen, in der Sie einzelne Änderungen akzeptieren oder ablehnen können. Das Verlaufsfenster hebt hervor, welche Versionen zu welcher Änderung beigetragen haben.

Offline-Warteschlangenanzeige

Bei Offline-Arbeit werden Änderungen lokal in eine Warteschlange gestellt; die Offline-Warteschlangenanzeige zeigt ausstehende Vorgänge und den Synchronisationsstatus an und ermöglicht manuelle Wiederholungsversuche.

(Screenshots der Netzwerkanzeige: offline und online)

Neu synchronisieren – Vom Server neu laden

Wann verwenden:

Alle nicht festgeschriebenen Änderungen verwerfen
Neuesten Stand vom Server laden (Arbeit anderer)
„Alles rückgängig machen" – die nukleare Option
Beschädigten lokalen Zustand beheben

⚠️ Warnung:

Alle nicht festgeschriebenen Änderungen gehen verloren
Kann nicht rückgängig gemacht werden
Vor dem Fortfahren wird eine Bestätigung verlangt

Sichere Alternative:

Zuerst einreichen, um die Arbeit zu sichern
Dann neu synchronisieren, um den neuesten Stand zu erhalten

Parallele Arbeitsabläufe: Direkt vs. Staging

Aptli unterstützt zwei Workflows für die Feature-Bearbeitung:

Direkte Bearbeitung (einfache Änderungen)

Am besten geeignet für:

Verschieben einzelner Features
Schnelle Aktualisierung von Eigenschaften
Löschen von Features
Einfache Geometrieanpassungen

So funktioniert es:

1. Feature auf der Karte oder in der Tabelle auswählen
2. Direkt bearbeiten (Ziehen, Eigenschaftenformular)
3. Änderung wird automatisch nachverfolgt
4. Bei Fertigstellung einreichen

Vorteile:

Schnell, keine Zwischenschritte
Vertrautes Muster (Bearbeitung an Ort und Stelle)
Minimaler UI-Overhead

Draw Staging (komplexe Vorgänge)

Am besten geeignet für:

Importieren externer Daten (GeoJSON-, ESRI-Dateien)
Bearbeiten komplexer Geometrien (Polygone umformen)
Stapelverarbeitungen (viele Features erstellen)
Überprüfung vor dem Festschreiben

So funktioniert es:

1. Features in Draw laden (Importe, Schaltfläche „In Draw laden")
2. Im Draw-Modus bearbeiten (umformen, teilen, zusammenführen)
3. Ziel-Layer auswählen
4. Features committen (als nicht festgeschrieben nachverfolgt)
5. Bei Fertigstellung einreichen

Vorteile:

Staging-Bereich für die Überprüfung
Erweiterte Geometrie-Werkzeuge
Trennung von Importen und echten Features
Rückgängig auf Draw-Ebene (vor dem Commit)

Farbcodierung:

Blau – Ihre ausgewählten Features, die in Draw geladen wurden
Orange – Konflikte mit anderen Benutzern (schreibgeschützt)
Standard – Importe und manuell gezeichnete Features

Konfliktlösung

Wie Konflikte entstehen

Räumliche Konflikte:

Zwei Benutzer fügen Features an derselben Stelle hinzu
Überlappende Platzierung von Infrastruktur
Konkurrierende Netzwerkdesigns

ID-Konflikte:

Dasselbe Feature wird von mehreren Benutzern bearbeitet
Unterschiedliche Eigenschaftsänderungen
Geometrieänderungen

Konflikte anzeigen

Schaltfläche „Konflikte laden" (DrawToolbar):

Ruft die nicht festgeschriebenen Änderungen anderer Benutzer ab
Zeigt sie in Draw als orangefarbene Features an
Schreibgeschützt – Entwürfe anderer können nicht festgeschrieben werden
Hilft bei der Abstimmung vor dem Einreichen

Ablauf:

1. In der DrawToolbar auf „Konflikte laden" klicken
2. Orangefarbene Features erscheinen (Entwürfe anderer)
3. Räumliche Überlappung überprüfen
4. Eigene Features bei Bedarf anpassen
5. Eigene Änderungen einreichen (Konflikte werden markiert)

Konflikte lösen

Option 1: Abstimmung mit dem Team

Sehen Sie, wer gerade bearbeitet (Konflikt zeigt die E-Mail des Benutzers)
Besprechen Sie es per Chat/Telefon
Entscheiden Sie, wer zuerst einreicht

Option 2: Sequenzielle Einreichung

Ein Benutzer reicht ein
Der andere Benutzer synchronisiert erneut
Der zweite Benutzer passt an und reicht ein

Option 3: Manuelles Zusammenführen

Konflikte laden, um beide Versionen zu sehen
Zusammengeführtes Feature manuell erstellen
Beide Benutzer synchronisieren erneut und akzeptieren die Zusammenführung

Verfolgung nicht festgeschriebener Änderungen

Features, die Sie erstellt, bearbeitet oder importiert — aber noch nicht eingereicht — haben, werden als nicht festgeschrieben verfolgt. Ein orangefarbenes Badge auf der Schaltfläche „Ausgewählte Features" zeigt die Anzahl der nicht festgeschriebenen Änderungen in Ihrer aktuellen Sitzung an.

Das Badge wird in Echtzeit aktualisiert:

Erhöht sich, wenn Sie Features aus dem Draw-Staging-Bereich committen
Wird beim Einreichen auf null zurückgesetzt
Wird beim Neu-Synchronisieren auf null zurückgesetzt (alle nicht festgeschriebenen Änderungen werden verworfen)

Nutzen Sie den Badge-Zähler als Erinnerung, regelmäßig einzureichen. Ein hoher Zähler bedeutet, dass viel Arbeit verloren gehen könnte, wenn der Browser vor dem Einreichen geschlossen wird.

Bewährte Verfahren

Wann einreichen

Empfohlene Zeitpunkte:

Am Ende jeder Arbeitssitzung
Nach Abschluss einer logischen Arbeitseinheit
Vor dem Wechsel zwischen Projekten
Wenn der Badge-Zähler „zu hoch" erscheint
Vor dem Offline-Gehen (als Checkpoint gesichert)

Zu vermeiden:

Unvollständige Arbeit einreichen (verwirrt das Team)
Nie einreichen (Risiko von Datenverlust)
Ständig einreichen (erzeugt Versionsrauschen)

Offline-Bearbeitungsstrategie

1. Vor dem Offline-Gehen synchronisieren:

1. Neu synchronisieren, um den neuesten Stand zu erhalten
2. Offline-Änderungen vornehmen
3. Nach der Rückkehr online einreichen

2. Auf Konflikte prüfen:

1. Vor größeren Bearbeitungen Konflikte laden
2. Mit sichtbaren Benutzern abstimmen
3. Nicht überlappende Arbeit zuerst einreichen

3. Regelmäßige Checkpoints:

1. Alle 30–60 Minuten einreichen
2. Schafft Wiederherstellungspunkte
3. Fortschritt mit dem Team teilen

Versionshistorie überprüfen

Überprüfen, wer was geändert hat:

Versionsdatensätze zeigen Benutzer, Zeitstempel, Vorgang
Komprimierte Versionen sind weiterhin rekonstruierbar
Prüfpfad für Compliance

Rollback-Prozess:

1. Problematische Version identifizieren
2. Neu synchronisieren auf den Stand vor dem problematischen Commit
3. Änderungen korrekt erneut durchführen
4. Neue Version einreichen

Funktion „In Draw laden"

Zweck

Ermöglicht komplexe Geometriemanipulationen, die über einfaches Drag-and-Drop hinausgehen:

Polygongrenzen umformen
Linien in Segmente teilen
Benachbarte Bereiche zusammenführen
Erweiterte Geometrieoperationen

Verwendung

Aus der Tabelle „SelectedFeatures":

1. Zeilen in der Tabelle auswählen (Kontrollkästchen)
2. Auf die Schaltfläche „In Draw laden" klicken (Stift-Symbol)
3. Features erscheinen in Draw (blau)
4. Mit den Draw-Werkzeugen bearbeiten
5. Ziel-Layer auswählen
6. Auf die Commit-Schaltfläche klicken
7. Features erhalten das Flag _uncommitted
8. Bei Fertigstellung einreichen

Styling: