Arquitectura de un Organizador Personal de Geodatos: Modelo y Sincronización
Un organizador personal de geodatos aborda el desafío de estructurar datos espaciales personales mediante un modelo de entidades claro. Los componentes clave incluyen: Punto como geometría atómica, Lugar con metadatos, Ruta como secuencia de puntos y Carpeta para jerarquía. Esta estructura permite construir árboles de objetos sin duplicar coordenadas, garantizando reactividad en la interfaz.
Los Puntos almacenan solo latitud, longitud, altitud y un UUIDv4. Son independientes de otras entidades y sirven como elementos de referencia. Cada Lugar referencia un único Punto por ID, añadiendo nombre, descripción, álbumes de fotos y enlaces. Las Rutas contienen una lista ordenada de IDs de puntos, admitiendo repeticiones para escenarios no lineales. Las Carpetas organizan Lugares y Rutas en árboles con campos parent, context y srt para ordenación.
Entidades en Detalle
Punto
Geometría pura sin contexto. Almacenado como binary(16) en MariaDB/MySQL para optimización de índices. Las referencias a él son cadenas UUIDv4 en el frontend.
Lugar
Metadatos adjuntos a un Punto. Ejemplo: un ID de Punto con una descripción como "Glorieta para la primera cita" y un álbum de fotos. La posición en el árbol se determina por folderid.
Ruta
Secuencia de IDs de Punto con metadescripciones. Un solo Punto puede repetirse, adecuado para bucles o retornos. Ejemplo: ruta "Paseo nocturno" — casa → tienda → parque (múltiples puntos) → biblioteca → casa.
Carpeta
Estructura de árbol con campos id, parent, srt (fraccional para orden), context (places o routes). El árbol se construye de forma reactiva desde una lista plana.
Tecnologías y Base de Datos
Backend en PHP, frontend — Vue 3 con Composition API, TypeScript, Pinia y Axios. Base de datos — MariaDB/MySQL. Entidades en tablas points, places, routes, folders.
Característica clave — atomicidad de los Puntos: no conocen a sus consumidores, minimizando duplicación y simplificando actualizaciones.
Sincronización de Cambios
El cliente rastrea estados sucios de objetos con banderas added, updated, deleted en el almacén Pinia. Objeto de ejemplo:
{
"id": "e7c6c8c4-4e3b-4d2f-8b61-8c9eaa2c1d51",
"title": "Glorieta",
"pointid": "a2c17b8f...",
"added": false,
"updated": true,
"deleted": false
}
Filtrado antes de enviar: solo objetos cambiados, excluyendo added+deleted en la misma sesión.
Envío por Lotes al Servidor
El botón "Guardar" forma una única solicitud con un lote:
{
"userid": "...",
"sessionid": "...",
"data": {
"points": [...],
"places": [...],
"routes": [...],
"folders": [...]
}
}
El servidor aplica operaciones en orden: DELETE > INSERT > UPDATE, como una mini-transacción.
Ventajas de este enfoque:
- Número mínimo de solicitudes — un lote por serie de ediciones.
- Interfaz reactiva: trabajar con una copia local de datos.
- Simplicidad del servidor: un endpoint sin múltiples rutas.
- Escalabilidad: nuevas entidades añadidas al lote sin cambios de protocolo.
Conclusiones Clave
- Los Puntos atómicos garantizan integridad referencial sin duplicar geodatos.
- El modelo de árbol mediante Carpetas se construye de forma reactiva en el frontend.
- El rastreo de cambios sucios + sincronización por lotes reducen la carga de red.
- La pila (PHP/Vue 3/Pinia/MariaDB) equilibra simplicidad y rendimiento.
- Proyecto de código abierto en GitHub con demo bajo test/test.
— Editorial Team
Aún no hay comentarios.