Geoorganizer: Datenmodell und Synchronisation

Architektur eines persönlichen Geodaten-Organizers: Modell und Synchronisierung

Ein persönlicher Geodaten-Organizer löst die Herausforderung, persönliche räumliche Daten durch ein klares Entitätsmodell zu strukturieren. Zu den Schlüsselkomponenten gehören: Punkt als atomare Geometrie, Ort mit Metadaten, Route als Punktfolge und Ordner für die Hierarchie. Diese Struktur ermöglicht den Aufbau von Objektbäumen ohne Koordinatenduplikate und gewährleistet reaktionsfähige Benutzeroberflächen.

Punkte speichern nur Breitengrad, Längengrad, Höhe und eine UUIDv4. Sie sind unabhängig von anderen Entitäten und dienen als Referenzelemente. Jeder Ort verweist über eine ID auf einen einzelnen Punkt und fügt einen Namen, eine Beschreibung, Fotoalben und Links hinzu. Routen enthalten eine geordnete Liste von Punkt-IDs und unterstützen Wiederholungen für nicht-lineare Szenarien. Ordner organisieren Orte und Routen in Bäumen mit Eltern-, Kontext- und Sortierfeldern.

Entitäten im Detail

Punkt

Reine Geometrie ohne Kontext. Wird als binary(16) in MariaDB/MySQL für Indexoptimierung gespeichert. Referenzen darauf sind UUIDv4-Strings im Frontend.

Ort

Metadaten, die an einen Punkt angehängt sind. Beispiel: Eine Punkt-ID mit einer Beschreibung wie "Pavillon für das erste Treffen" und einem Fotoalbum. Die Position im Baum wird durch die Ordner-ID bestimmt.

Route

Sequenz von Punkt-IDs mit Metabeschreibungen. Ein einzelner Punkt kann wiederholt werden, geeignet für Schleifen oder Rückwege. Beispiel: Route "Abendspaziergang" – Zuhause → Laden → Park (mehrere Punkte) → Bibliothek → Zuhause.

Ordner

Baumstruktur mit Feldern ID, Eltern-ID, Sortierung (Bruchzahl für Reihenfolge) und Kontext (Orte oder Routen). Der Baum wird reaktiv aus einer flachen Liste aufgebaut.

Tech-Stack und Datenbank

Backend in PHP, Frontend – Vue 3 mit Composition API, TypeScript, Pinia und Axios. Datenbank – MariaDB/MySQL. Entitäten in Tabellen points, places, routes, folders.

Schlüsselmerkmal – Atomarität der Punkte: Sie kennen ihre Verbraucher nicht, minimieren Duplikate und vereinfachen Aktualisierungen.

Synchronisierung von Änderungen

Der Client verfolgt veränderte Zustände von Objekten mit Flags hinzugefügt, aktualisiert, gelöscht im Pinia-Store. Beispielobjekt:

{
	"id": "e7c6c8c4-4e3b-4d2f-8b61-8c9eaa2c1d51",
	"title": "Pavillon",
	"pointid": "a2c17b8f...",
	"added": false,
	"updated": true,
	"deleted": false
}

Filterung vor dem Senden: Nur geänderte Objekte, ausgenommen hinzugefügt+gelöscht in derselben Sitzung.

Batch-Senden an den Server

Der "Speichern"-Button bildet eine einzelne Anfrage mit einem Batch:

{
	"userid": "...",
	"sessionid": "...",
	"data": {
		"points": [...],
		"places": [...],
		"routes": [...],
		"folders": [...]
	}
}

Der Server wendet Operationen in Reihenfolge an: LÖSCHEN > EINFÜGEN > AKTUALISIEREN, als Mini-Transaktion.

Vorteile dieses Ansatzes:

• Minimale Anzahl von Anfragen – ein Batch pro Bearbeitungsserie.
• Reaktive Benutzeroberfläche: Arbeiten mit einer lokalen Datenkopie.
• Server-Einfachheit: Ein Endpunkt ohne mehrere Routen.
• Skalierbarkeit: Neue Entitäten werden zum Batch hinzugefügt ohne Protokolländerungen.

Wichtige Erkenntnisse

• Atomare Punkte gewährleisten referenzielle Integrität ohne Geodaten-Duplikate.
• Baummodell über Ordner wird reaktiv im Frontend aufgebaut.
• Änderungsverfolgung + Batch-Synchronisierung reduzieren Netzwerklast.
• Stack (PHP/Vue 3/Pinia/MariaDB) balanciert Einfachheit und Leistung.
• Open-Source-Projekt auf GitHub mit Demo unter test/test.

— Editorial Team