Geoorganizér: model dat a synchronizace

Architektura osobního organizátoru geodat: model a synchronizace

Osobní geo-organizátor řeší úlohu strukturování osobních prostorových dat prostřednictvím jasného modelu entit. Hlavní komponenty: Bod jako atomární geometrie, Místo s metadaty, Trasa jako posloupnost bodů a Složka pro hierarchii. Tato struktura umožňuje vytvářet stromy objektů bez duplikace souřadnic, což zajišťuje reaktivitu rozhraní.

Body ukládají pouze zeměpisnou šířku, délku, výšku a UUIDv4. Nejsou závislé na jiných entitách a slouží jako referenční prvky. Každé Místo odkazuje na jeden Bod pomocí ID a přidává název, popis, fotoalba a odkazy. Trasy obsahují uspořádaný seznam ID bodů a podporují opakování pro nelineární scénáře. Složky organizují Místa a Trasy do stromů s poli parent, context a srt pro řazení.

Entity podrobně

Bod

Čistá geometrie bez kontextu. Ukládá se jako binary(16) v MariaDB/MySQL pro optimalizaci indexů. Odkazy na něj jsou řetězce UUIDv4 na frontendu.

Místo

Metadata připojená k Bodu. Příklad: ID Bodu s popisem „Altánek pro první setkání“ a albem fotek. Pozice ve stromu je určena folderid.

Trasa

Posloupnost ID Bodů s meta-popisy. Jeden Bod se může opakovat, což je vhodné pro cykly nebo návraty. Příklad: trasa „Večerní procházka“ – dům → obchod → park (několik bodů) → knihovna → dům.

Složka

Stromová struktura s poli id, parent, srt (desetinné pro pořadí), context (places nebo routes). Strom se reaktivně vytváří z plochého seznamu.

Technický stack a databáze

Backend v PHP, frontend – Vue 3 s Composition API, TypeScript, Pinia a Axios. Databáze – MariaDB/MySQL. Entity v tabulkách points, places, routes, folders.

Klíčová vlastnost – atomárnost Bodů: neznají své spotřebitele, což minimalizuje duplikáty a zjednodušuje aktualizace.

Synchronizace změn

Klient sleduje dirty-stav objektů příznaky added, updated, deleted v Pinia-store. Příklad objektu:

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

Filtrace před odesláním: pouze změněné, vylučující added+deleted v jedné relaci.

Dávkové odesílání na server

Tlačítko „Uložit“ vytvoří jeden požadavek s dávkou:

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

Server aplikuje operace v pořadí: DELETE > INSERT > UPDATE, jako mini-transakci.

Výhody přístupu:

• Minimální počet požadavků – jedna dávka na sérii úprav.
• Reaktivní UI: práce s lokální kopií dat.
• Jednoduchost serveru: jeden endpoint bez mnoha tras.
• Rozšiřitelnost: nová entita se přidá do dávky bez změn protokolu.

Co je důležité

• Atomární Body zajišťují referenční integritu bez duplikace geodat.
• Stromový model prostřednictvím Složek se reaktivně vytváří na frontendu.
• Dirty tracking + dávková synchronizace snižují síťovou zátěž.
• Stack (PHP/Vue 3/Pinia/MariaDB) vyvažuje jednoduchost a výkon.
• Otevřený projekt na GitHubu s demem pod test/test.

— Editorial Team