Geoorganizer : modèle de données et synchronisation

Architecture d'un Organisateur de Géodonnées Personnelles : Modèle et Synchronisation

Un organisateur de géodonnées personnelles répond au défi de structurer des données spatiales personnelles grâce à un modèle d'entités clair. Les composants clés incluent : Point comme géométrie atomique, Lieu avec métadonnées, Itinéraire comme séquence de points, et Dossier pour la hiérarchie. Cette structure permet de construire des arbres d'objets sans dupliquer les coordonnées, garantissant la réactivité de l'interface.

Les Points stockent uniquement la latitude, la longitude, l'altitude et un UUIDv4. Ils sont indépendants des autres entités et servent d'éléments de référence. Chaque Lieu référence un seul Point par son ID, en ajoutant un nom, une description, des albums photo et des liens. Les Itinéraires contiennent une liste ordonnée d'IDs de points, supportant les répétitions pour des scénarios non linéaires. Les Dossiers organisent les Lieux et Itinéraires en arbres avec des champs parent, contexte et srt pour le tri.

Entités en Détail

Point

Géométrie pure sans contexte. Stocké en binary(16) dans MariaDB/MySQL pour l'optimisation des index. Les références sont des chaînes UUIDv4 côté frontend.

Lieu

Métadonnées attachées à un Point. Exemple : Un ID de Point avec une description comme "Kiosque pour la première rencontre" et un album photo. La position dans l'arbre est déterminée par folderid.

Itinéraire

Séquence d'IDs de Points avec méta-descriptions. Un même Point peut se répéter, adapté aux boucles ou retours. Exemple : itinéraire "Promenade du soir" — maison → magasin → parc (plusieurs points) → bibliothèque → maison.

Dossier

Structure arborescente avec les champs id, parent, srt (fractionnel pour l'ordre), contexte (lieux ou itinéraires). L'arbre est construit réactivement à partir d'une liste plate.

Stack Technique et Base de Données

Backend en PHP, frontend — Vue 3 avec Composition API, TypeScript, Pinia et Axios. Base de données — MariaDB/MySQL. Entités dans les tables points, places, routes, folders.

Caractéristique clé — atomicité des Points : ils ignorent les consommateurs, minimisant la duplication et simplifiant les mises à jour.

Synchronisation des Modifications

Le client suit les états modifiés des objets avec des drapeaux ajouté, mis à jour, supprimé dans le store Pinia. Exemple d'objet :

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

Filtrage avant envoi : uniquement les objets modifiés, excluant ajouté+supprimé dans la même session.

Envoi par Lots au Serveur

Le bouton "Enregistrer" forme une seule requête avec un lot :

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

Le serveur applique les opérations dans l'ordre : SUPPRIMER > INSÉRER > METTRE À JOUR, comme une mini-transaction.

Avantages de cette approche :

• Nombre minimal de requêtes — un lot par série de modifications.
• Interface réactive : travail sur une copie locale des données.
• Simplicité serveur : un seul endpoint sans multiples routes.
• Évolutivité : nouvelles entités ajoutées au lot sans changer le protocole.

Points Clés à Retenir

• Les Points atomiques garantissent l'intégrité référentielle sans duplication des géodonnées.
• Le modèle arborescent via Dossiers est construit réactivement côté frontend.
• Suivi des modifications + synchronisation par lots réduisent la charge réseau.
• Stack (PHP/Vue 3/Pinia/MariaDB) équilibre simplicité et performance.
• Projet open-source sur GitHub avec démo sous test/test.

— Editorial Team