2.2 Gestión de archivos

Trazabilidad del dato

La trazabilidad (o linaje del dato) es la capacidad de conocer toda la historia de un conjunto de datos — de dónde vino, qué transformaciones sufrió, quién lo modificó y cuándo. Es la diferencia entre saber que un archivo existe y saber cómo llegó a ser lo que es.

En proyectos de transporte público esto es concreto y práctico. Si una ruta aparece con un trayecto incorrecto en la aplicación de navegación, la trazabilidad permite responder esas preguntas. ¿El error estaba en el archivo GPS original? ¿Ocurrió durante el procesamiento? ¿Se introdujo al generar el GTFS? Sin ese rastro, la depuración se convierte en trabajo detectivesco.

Mantener trazabilidad no requiere herramientas complejas. Estas son algunas prácticas simples para implementarla.

• Conservar los archivos fuente originales sin modificar, en una carpeta separada.
• Registrar en un archivo de bitácora qué se hizo, cuándo y por qué en cada procesamiento importante.
• Usar nombres de archivo con fecha para que las versiones sean identificables cronológicamente.
• Documentar de dónde provienen los datos adquiridos externamente (fuente, fecha de descarga, condiciones de uso).

La trazabilidad también es útil ante auditorías o cuestionamientos. Si alguien pregunta cómo se calculó la cobertura de una ruta o de dónde proviene cierto horario, el equipo puede responder con evidencia.

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.

Nomenclatura semántica para archivos de rutas

Para archivos de rutas geoespaciales conviene ir un paso más allá de la fecha: el nombre del archivo debe codificar la identidad de la ruta y su dirección. Esto crea una correspondencia directa con los identificadores de GTFS y elimina la ambigüedad sobre qué contiene cada archivo.

La estructura recomendada es:

{route_id}-{dirección}.geojson

Por ejemplo:

rutas/
├── r01-ida.geojson
├── r01-retorno.geojson
├── r02-ida.geojson
├── r02-retorno.geojson

Por qué esta estructura funciona con GTFS

En GTFS, la geometría de un trayecto se almacena en shapes.txt bajo un shape_id. La convención es que el nombre del archivo (sin extensión) sea exactamente ese shape_id. De esta forma, al generar el GTFS, la relación entre el archivo fuente y el registro en la base de datos es inmediata y no requiere documentación adicional.

r01-ida.geojson   →   shape_id: r01-ida   →   direction_id: 0 en trips.txt
r01-retorno.geojson → shape_id: r01-retorno → direction_id: 1 en trips.txt

El trip_id no forma parte del nombre del archivo porque múltiples viajes distintos (diferentes horarios a lo largo del día) comparten la misma geometría. El archivo representa la forma del trayecto, no un viaje específico.

Concepto GTFS	Archivo	Nota
route_id	prefijo del nombre	La ruta como la conocen los pasajeros
shape_id	nombre del archivo sin extensión	Usado en shapes.txt y en trips.txt
direction_id	sufijo -ida / -retorno	0 = ida, 1 = retorno
trip_id	no está en el nombre	Múltiples viajes comparten la misma geometría

El route_id que se use en el nombre del archivo debe ser el mismo que se usará en routes.txt. Definirlo desde el inicio, antes de crear los archivos, evita tener que renombrar todo cuando se genere el GTFS.

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.