SPAB — Rama de exploración: rutas turísticas por cultura mesoamericana

Fecha: 2026-09-14 · Rama: spab/rutas-culturales-mesoamerica · Proyecto: ~/nef/estado_turismo/spab-retrieval

Qué es esto y qué NO es

Otro acercamiento al turismo, desde cultura en vez de destino-estado: en vez de “¿qué tan saturado está Tulum?”, “¿qué sitios comparten narrativa maya / olmeca / teotihuacana / mexica y podrían venderse como ruta?“.

No es el Problema Prototípico. El encargo (RUTA.md) exige un solo estado — Quintana Roo, ya elegido, ya con 4 sesiones de trabajo encima. Maya cabe en Q. Roo; olmeca (Veracruz/Tabasco), teotihuacana (Edomex) y mexica (CDMX/Edomex) no. Por eso esto vive en su propia rama y su propio archivo, sin tocar data/destinos.json (los 10 destinos oficiales) ni el pipeline que ya corre para la entrega.

Qué se hizo

src/lib/schema.ts: campo cultura en Destino — enum maya | olmeca | teotihuacana | mexica, nullable, default null. Los 10 destinos originales no lo usan (no aplica: son playa/ciudad, no sitio arqueológico). tsc limpio.

data/destinos_culturales.json: 12 sitios, mismo shape que Destino, en archivo separado — el store (leerDestinos) sigue leyendo solo destinos.json; este no está conectado al pipeline todavía.

cultura	sitios
maya (5)	Chichén Itzá y Uxmal (Yuc.), Palenque (Chis.), Calakmul (Camp.), Cobá (Q. Roo)
olmeca (3)	La Venta —parque-museo, Villahermosa— (Tab.), San Lorenzo Tenochtitlán y Tres Zapotes (Ver.)
teotihuacana (1)	Teotihuacán (Edomex)
mexica (3)	Templo Mayor y Tlatelolco (CDMX), Malinalco (Edomex)

Qué NO está verificado — léelo antes de correr nada

Mismo error que casi se comete hoy con Riviera Maya y AFAC: coordenadas y claves de este archivo son de memoria, no verificadas en vivo. Antes de conectar cualquier fuente:

• lat/lon: aproximados, no contrastados contra INEGI/INAH.
• aero_iata de Palenque (PQM) y Villahermosa (VSA): de memoria, no confirmados contra AFAC/IATA hoy.
• sesnsp_cve_mun de Templo Mayor/Tlatelolco: reutiliza la clave de CDMX ya verificada en destinos.json (09015) — es la misma ciudad, no es un dato nuevo sin comprobar.
• wikipedia: títulos que deberían existir tal cual, pero no se pidió la página en vivo (a diferencia del ejercicio de hoy con Inside Airbnb y el xlsx del Monitoreo). Dos con más riesgo de título distinto: “Parque Museo de La Venta” y “San Lorenzo Tenochtitlán”.
• datatur, insideairbnb: null a propósito — DataTur no reporta ocupación de sitio arqueológico (es un centro turístico de playa/ciudad en su nomenclatura, ya se vio con Tulum/Bacalar hoy) e Inside Airbnb solo publica CDMX en México (verificado hoy también).

Qué SÍ mide algo, si esto avanza

Ocupación hotelera y DataTur no aplican a un sitio arqueológico igual que a un centro de playa. Antes de conectar fuentes, la pregunta real es qué métrica es “saturación” para un sitio INAH:

• INAH visitantes por zona arqueológica — si publica cifras públicas mensuales por sitio (a verificar, mismo ejercicio de hoy: buscar en vivo, no asumir).
• rating, reviews_conteo, menciones_caro, vistas_wikipedia — el conector googleplaces y wikipedia ya sirven para cualquier Destino con lat/lon y clave wikipedia; correrían tal cual sin cambio de código.
• Capacidad de acceso (cupo diario, no cuartos de hotel) es la variable de saturación real en un sitio arqueológico — no existe todavía en el esquema (Metrica no tiene nada parecido).

Siguiente paso, si se decide avanzar

1. Verificar en vivo (WebFetch/WebSearch, como hoy) las claves marcadas arriba antes de tratarlas como dato real.
2. Decidir la pregunta de negocio: ¿ruta de venta cruzada para la campaña de Q. Roo (ej. “Tulum + Cobá + Chichén Itzá” como corredor maya), o comparación nacional aparte del encargo?
3. Si es lo primero, el eje real es: ¿qué destinos de este archivo son candidatos de desvío de flujo desde los destinos saturados que ya tiene el encargo? Ahí Cobá es el más directo (misma región Q. Roo que Tulum, mismo problema que el plan ya nombra).