Sobre el proyecto
El problema
Un estudio de mapeo sistemático (SMS) analizó 101 investigaciones sobre el Tourist Trip Design Problem (TTDP) publicadas entre 2019 y 2025 en Scopus, Web of Science, IEEE Xplore y ACM Digital Library.
El hallazgo principal: el 91,1% (92 de 101 estudios) ignora completamente la accesibilidad en su diseño algorítmico. Solo 1 estudio implementa restricciones formales de inclusividad. Sin embargo, el 29,7% utiliza fuentes de datos que ya contienen metadatos de accesibilidad (etiquetas wheelchair de OpenStreetMap, campos de Google Maps), sin incorporarlos al modelo.
La brecha no es técnica: es de priorización en el diseño. La capacidad algorítmica existe (metaheurísticas en el 55,4% de los estudios, ILP en el 17,8%), pero no se aplica a inclusividad.
La propuesta
Este sistema integra por primera vez tres dominios que existían como silos separados:
- Datos de accesibilidad — acceso en silla de ruedas, tipo de superficie, pendientes calculadas por DEM, bordillos, pavimento táctil
- Routing para silla de ruedas — OpenRouteService self-hosted con perfil wheelchair y datos de elevación
- Optimización de itinerarios — VROOM como solver VRP con modelo de fatiga acumulada post-procesado
Se formula un nuevo problema de optimización: AC-OP-PDC (Accessibility-Constrained Orienteering Problem with Path-Dependent Costs), formalmente distinto del Orienteering Problem clásico por tres propiedades: subgrafos inducidos por el perfil funcional, costes dependientes de la ruta por fatiga acumulada, y factibilidad dinámica.
Arquitectura técnica
El sistema se despliega como 6 servicios Docker orquestados con Docker Compose detrás de un proxy inverso Traefik:
| Componente | Tecnología | Función |
|---|---|---|
| Backend API | Django 5 + DRF + GeoDjango | REST API con ORM espacial |
| BD espacial | PostgreSQL 16 + PostGIS 3.4 | Índices GiST, queries espaciales |
| Routing | OpenRouteService v9 self-hosted | Perfil wheelchair, elevación, superficie |
| Optimización | VROOM (integrado en ORS) | VRP con prioridades y time windows |
| Cache/Broker | Redis 7 | Cache de rutas ORS + broker Celery |
| Frontend | Next.js 15 + TypeScript + Tailwind | WCAG AAA, react-leaflet, Web Speech API |
Pipeline de 4 etapas
Stage 1 — Matching y scoring
Filtra los POIs factibles según el perfil funcional del usuario (e.g., wheelchair=true descarta POIs sin acceso) y calcula una puntuación multicriterio:
T = interés turístico, A = compatibilidad accesibilidad, V = duración de visita normalizada, F = penalización por esfuerzo
Stage 2 — Optimización VRP (VROOM)
VROOM resuelve el Vehicle Routing Problem para secuenciar los POIs factibles. Se codifican las puntuaciones como prioridades (score × 100), la duración de visita como service time, y el presupuesto temporal como time window del vehículo. Cuando VROOM no está disponible, se aplica un fallback greedy ordenado por prioridad.
Stage 3 — Routing accesible (ORS)
OpenRouteService calcula rutas wheelchair entre POIs consecutivos. El perfil wheelchair aplica restricciones de pendiente, tipo de superficie, ancho de vía y bordillos. Las rutas incluyen geometría GeoJSON con datos de elevación. Se cachean en Redis con TTL de 24h (hash MD5 de coordenadas). Si wheelchair falla, se usa foot-walking como fallback con advertencia.
Stage 4 — Post-procesamiento de fatiga
Se recalcula la fatiga acumulada sobre la ruta real y se insertan paradas de descanso cuando se excede el umbral del usuario:
| Asfalto | 0.00 | Empedrado regular | 0.15 |
| Losas | 0.05 | Empedrado irregular | 0.25 |
| Hormigón | 0.02 | Arena | 0.40 |
Factor de esfuerzo: bajo = 1.0×, medio = 2.0×, alto = 4.0×. Cuando la fatiga supera el umbral se inserta una parada de descanso y el acumulador se reinicia.
Datos de Granada
Ciudad piloto: Granada, España. Seleccionada por su terreno extremo (Albaicín con pendiente media del 13,1% y empedrado irregular), disponibilidad de datos de accesibilidad, y contexto institucional. Datos verificados en abril de 2026:
| Dato | Cantidad | Fuente |
|---|---|---|
| POIs importados | 1.252 | OSM + OpenRTA |
| POIs con datos wheelchair | 898 | OSM Overpass |
| Segmentos de calle con pendiente | 25.873 | IGN MDT02 (DEM LiDAR) |
| Elementos de pavimento táctil | 5.409 | OSM Overpass |
| Bordillos catalogados | 1.469 | OSM Overpass |
| Pendiente media de la red viaria | 4,14% | Calculado desde DEM |
| Segmentos con pendiente >6% | 20,5% | Calculado desde DEM |
Licencias: OpenStreetMap (ODbL), OpenRTA Junta de Andalucía (CC BY 4.0), IGN MDT02 (reutilización libre).
Accesibilidad del sistema
- Objetivo WCAG 2.1 nivel AAA
- 4 temas de color: claro, oscuro, alto contraste claro, alto contraste oscuro
- Entrada por voz (Web Speech API) con conversación guiada por IA
- Narración por voz (TTS) del itinerario paso a paso
- Navegación completa por teclado (atajos Alt+1-4, Alt+M, Alt+H)
- Landmarks ARIA, regiones live, skip links
- Vista de lista como alternativa al mapa para usuarios con discapacidad visual
- Touch targets mínimos de 48px
Equipo
- Sixto Valdés-Elizalde — Desarrollo e investigación
Departamento de Ingeniería del Software, Universidad de Granada - Dr. Carlos Rodríguez-Domínguez — Director
Departamento de Ingeniería del Software, Universidad de Granada - Dr. Miguel J. Hornos — Director
Departamento de Ingeniería del Software, Universidad de Granada
Contexto académico
- Programa académico
- Máster Universitario en Desarrollo de Software, Universidad de Granada
- Estudio de Mapeo Sistemático base
- “Inclusividad algorítmica en la planificación de itinerarios turísticos basada en IA: un estudio de mapeo sistemático” — 101 estudios, 2019–2025. Valdés-Elizalde, Rodríguez-Domínguez, Hornos, Silva Pérez.