2. Ciclo de vida de los datos

Antes de entrar a los detalles técnicos del mapeo y la creación de datos de transporte, vale la pena detenerse a pensar en algo más general — qué significa gestionar datos de manera responsable y sostenible.

Los datos no son un producto terminado. Son algo vivo que cambia, se corrige, se actualiza y, a veces, se archiva. Entender eso desde el principio evita problemas comunes como archivos con nombres confusos, versiones contradictorias circulando por correo electrónico, o información desactualizada que nadie sabe si ya fue corregida.

El ciclo de vida de los datos

Cualquier conjunto de datos, independientemente de su tema, pasa por una serie de etapas desde que se crea hasta que deja de usarse. Entender este ciclo ayuda a planificar mejor el trabajo y a no tratar cada tarea como si fuera aislada.

Creación o captura. Cuando los datos entran al sistema por primera vez, ya sea desde un trabajo de campo, una fuente existente (un documento oficial, una hoja de cálculo heredada) o algún proceso automatizado. En el caso del transporte público, esto suele ser el levantamiento de rutas en campo.

Procesamiento. Una vez capturados, los datos normalmente se procesan. Los datos crudos rara vez están listos para usarse directamente; se revisan, limpian, organizan y transforman al formato necesario. Un archivo GPX grabado desde el celular, por ejemplo, necesita procesarse antes de convertirse en una ruta publicable.

Almacenamiento. define dónde y cómo viven los datos — una carpeta compartida, una hoja de cálculo en Google Sheets, un repositorio. Esa decisión afecta quién puede acceder a ellos, con qué facilidad se actualizan y qué tan fácil es recuperarlos después.

Una distinción importante en esta etapa es separar los datos de trabajo de los datos de salida. Los datos de trabajo son los archivos con los que el equipo opera directamente — capas geográficas en GeoJSON, tablas de horarios en hojas de cálculo, trazas GPS. Los datos de salida son los formatos que se generan a partir de esos datos de trabajo para ser publicados o consumidos por otras herramientas. El GTFS, por ejemplo, es un formato de salida — se produce desde los datos de trabajo, no se usa como formato de almacenamiento interno. Intentar trabajar directamente sobre los archivos GTFS (.txt dentro de un .zip) complica el proceso y aumenta el riesgo de errores. Los datos fuente deben mantenerse en formatos editables; el GTFS se genera cuando hay algo que publicar.

Uso y aprovechamiento. Cuando los datos se consultan, analizan o publican. En transporte público esto puede significar generar un mapa, alimentar una aplicación de navegación o responder una pregunta de planeación.

Actualización. Es la etapa que con más frecuencia se descuida es la . La realidad cambia, una ruta modifica su recorrido, una parada desaparece, se añade un nuevo servicio. Los datos deben reflejar esos cambios; si no lo hacen, dejan de ser útiles y pueden volverse activamente problemáticos.

Archivo Finalmente, cuando los datos ya no son vigentes, se guardan para referencia histórica. Guardar versiones anteriores puede ser útil para entender cómo ha cambiado el sistema con el tiempo.

Eliminación También es necesario considerar que a veces es necesario eliminar los datos por temas de protección de datos o política interna.

Pensar los datos de manera holística

Un error frecuente en proyectos de datos es trabajar con archivos individuales de manera aislada, sin pensar en cómo se relacionan entre sí ni en quién más los va a usar.

Los datos de transporte público no son una excepción. Una ruta no es solo una línea en un mapa, sino algo conectado a paradas, horarios, tarifas y a la información de la agencia que la opera. Si se modifica una parada, esa modificación afecta a todas las rutas que pasan por ella. Si cambia el nombre de una línea, ese cambio debe reflejarse de manera consistente en todos los archivos que la mencionan.

Pensar holísticamente significa hacerse preguntas como:

• ¿Cómo se relaciona este dato con otros datos del sistema?
• ¿Quién más va a usar estos datos y para qué?
• ¿Qué pasa en el resto del sistema si este dato cambia?
• ¿Están todos los archivos usando la misma referencia para este elemento?

Esta perspectiva es especialmente importante cuando más de una persona trabaja con los mismos datos. Sin ella, es fácil que cada quien mantenga su propia versión de la verdad.

Nomenclatura de archivos y carpetas

Nombrar bien los archivos es una de las cosas más simples que se pueden hacer para evitar confusión, y una de las que más se descuida. Cualquier equipo que haya trabajado con archivos llamados version_final.xlsx, version_final_2.xlsx o version_final_ESTA_SÍ_QUE_SÍ.xlsx conoce el problema.

La primera regla es no usar “final” en el nombre de ningún archivo, porque siempre habrá una versión más reciente. La alternativa es incluir la fecha en formato ISO (AAAA-MM-DD) al inicio o al final del nombre; eso hace que los archivos se ordenen cronológicamente de manera automática en cualquier sistema operativo.

rutas_zamora_2024-03-15.geojson     ✓ OK
rutas_zamora_final.geojson          ✗ No OK
rutas_zamora_marzo.geojson          ✗ No OK (¿qué año?)

También conviene evitar espacios en los nombres de archivo, ya que pueden causar problemas en algunas herramientas, y usar en su lugar guiones bajos o guiones medios. El nombre debe ser descriptivo pero conciso — lo ideal es que diga qué contiene el archivo, de dónde viene y cuándo fue generado, sin necesidad de abrirlo.

Igual de importante es mantener una estructura de carpetas consistente. Una organización clara de carpetas es tan importante como los nombres de los archivos:

transporte-zamora/
├── datos-fuente/          ← archivos originales, sin modificar
├── procesados/            ← versiones limpias y editadas
├── publicados/            ← versiones que se han publicado oficialmente
└── archivo/               ← versiones antiguas que ya no están vigentes

Una buena práctica relacionada es mantener un flujo de trabajo no destructivo, es decir, que los datos originales nunca se modifican directamente. Cuando se necesita limpiar, transformar o corregir un archivo, se trabaja sobre una copia y el original se conserva intacto en la carpeta de datos fuente. Esto permite volver al punto de partida en cualquier momento si algo sale mal durante el procesamiento, y también sirve como evidencia de dónde vino cada dato.

Versionado

El versionado es la práctica de llevar un registro de los cambios que se hacen a los datos a lo largo del tiempo, de manera que siempre sea posible saber qué cambió, cuándo y por qué.

La forma más sencilla es usar fechas en los nombres de los archivos y mantener las versiones anteriores en una carpeta de archivo en lugar de sobreescribir el archivo existente. Esto no requiere ninguna herramienta especial.

Para datos que se editan en plataformas colaborativas –por ejemplo en Google Sheets– la plataforma guarda automáticamente un historial de cambios que permite ver quién modificó qué y cuándo, y restaurar versiones anteriores si es necesario.

Una convención útil es numerar las versiones con el esquema v1.0 para la primera versión completa y publicada, v1.1 para correcciones menores o actualizaciones pequeñas, y v2.0 para cambios significativos en la estructura o en la cobertura. Lo importante no es el sistema exacto que se use, sino que el equipo acuerde uno y lo aplique de manera consistente.

Gobernanza de datos

La gobernanza de datos es el conjunto de acuerdos, responsabilidades y procesos que definen cómo se crean, mantienen y usan los datos dentro de una organización. En contextos municipales con equipos pequeños, no necesita ser un sistema complejo, pero sí debe estar claro.

Para empezar, debe quedar definido quién es responsable de cada conjunto de datos, es decir, quién los actualiza, quién aprueba cambios y quién responde si hay un error. También debe haber un canal claro para reportar errores — cuando alguien detecta que un dato está mal, debe saber a quién avisar y en cuánto tiempo se espera una corrección.

El acceso también importa. No todos necesitan poder editar todos los archivos; separar quién puede leer y quién puede modificar reduce el riesgo de errores accidentales. Y los datos deben revisarse con cierta periodicidad — trimestral o semestralmente, según la dinámica del sistema — para detectar desactualizaciones antes de que se conviertan en un problema.

Por último, lo que se hace debe quedar documentado. En el sector público es frecuente que los equipos cambien: termina una administración, alguien se va a otro puesto, el técnico que hizo el levantamiento ya no está. Si el proceso solo existe en la memoria de las personas que lo hicieron, el conocimiento se va con ellas. Documentar puede ser tan simple como un archivo de texto con notas sobre qué decisiones se tomaron y por qué, o un registro de cambios con fecha guardado en un lugar accesible para el equipo. No hace falta un sistema sofisticado, pero sí que exista algo. Es la diferencia entre un proyecto que sobrevive al equipo que lo inició y uno que hay que empezar desde cero cada vez.

En la práctica, para un municipio que está empezando, la gobernanza puede ser tan simple como un documento de una página que responda estas preguntas y un canal de comunicación claro entre las personas involucradas.