2.5 Formatos de archivo para datos geoespaciales

La elección del formato de archivo para almacenar rutas determina qué herramientas pueden abrir el archivo, si la geometría se representa con fidelidad, y qué tan bien se integra con los flujos de procesamiento de GTFS. Elegir el formato adecuado evita conversiones innecesarias y errores o posibles pérdidas de información.

Tipos de geometría para rutas

Una ruta de transporte público, en términos geoespaciales, es una línea, una secuencia ordenada de coordenadas que forman un trayecto. Hay dos tipos principales de geometría lineal que conviene conocer.

LineString es una línea continua: una secuencia de puntos conectados sin interrupciones. Es el tipo adecuado para una ruta cuyo trayecto va de un extremo al otro sin saltos.

MultiLineString es una colección de segmentos de línea que conviven como un solo feature. Se usa cuando la ruta no puede representarse como una sola línea continua — por ejemplo, si pasa por un tramo donde hay una separación física (como una vía rápida que obliga a una desviación), si tiene ramales, o si el trayecto de ida y vuelta se almacenan juntos.

En la práctica, si un trayecto es continuo de inicio a fin, usar LineString. Si tiene segmentos discontinuos, usar MultiLineString. Aunque técnicamente es posible tener una sola linea en un MultiLineString, lo cual a veces pasa al exportar desde ciertas herramientas, es mejor cambiarlo al tipo LineString.

Un archivo por trayecto

La convención recomendada para proyectos de transporte público es guardar un trayecto por archivo: el trayecto de ida en un archivo, el de retorno en otro. Esto hace que cada archivo sea independiente de otros, fácil de editar y de reemplazar.

rutas/
├── ruta-01-ida.geojson
├── ruta-01-retorno.geojson
├── ruta-02-ida.geojson
├── ruta-02-retorno.geojson
└── ...

Almacenar todas las rutas de una ciudad en un solo archivo es conveniente para consultas globales, pero complica la edición individual y aumenta el riesgo de introducir errores al modificar una sola ruta dentro de un archivo grande. Un archivo por trayecto también facilita el control de versiones: el historial de cambios de cada trayecto queda en su propio archivo.

Dirección del trazado

Las coordenadas de un LineString no son solo una lista de puntos — tienen un orden, y ese orden define el sentido de marcha. Si una ruta va de Terminal Norte a Centro, la primera coordenada del trazado debe estar en Terminal Norte y la última en Centro.

Esto importa directamente en GTFS: el archivo shapes.txt contiene los mismos puntos ordenados mediante shape_pt_sequence, y ese orden debe corresponder al sentido de operación del vehículo. Un trazado con las coordenadas en orden invertido produce una ruta que las aplicaciones de tránsito muestran recorrida en sentido contrario.

El error es más común de lo que parece, como por ejemplo al digitalizar manualmente en un mapa es fácil trazar de regreso sin notarlo.

En Ohtli es posible visualizar la dirección del trayecto directamente y voltearla (invertirla) desde la interfaz cuando se detecta que el orden de las coordenadas está incorrecto.

Sistema de referencia de coordenadas

Las coordenadas geográficas pueden expresarse en distintos sistemas, y usar el sistema equivocado hace que los datos aparezcan en el lugar incorrecto del mundo.

WGS84 (EPSG:4326) es el estándar de GPS y mapas web: latitud y longitud en grados decimales. Un punto en el centro de la Ciudad de México se ve como −99.1332, 19.4326.

Los sistemas proyectados, como UTM o ITRF2008 (usado en cartografía oficial de México, EPSG:6372), expresan la posición en metros desde un punto de referencia. El mismo punto en UTM zona 14N se ve como algo parecido a X: 484,000 / Y: 2,150,000 — números grandes que no parecen coordenadas geográficas.

Los archivos que provienen de dependencias de gobierno en México frecuentemente llegan en ITRF2008/UTM, a veces sin documentar el sistema. Una forma rápida de detectarlo: si los valores de las coordenadas son números mayores a 360 o negativos con cinco o seis dígitos antes del decimal, el archivo está en un sistema proyectado y necesita reproyectarse antes de usarse.

GeoJSON es siempre WGS84 según la especificación vigente (RFC 7946, 2016) — esto es una ventaja porque elimina toda ambigüedad sobre el sistema utilizado. Sin embargo, la especificación anterior (2008) permitía declarar un CRS distinto mediante un campo crs en el archivo. Algunas herramientas todavía permiten exportar GeoJSON con proyecciones no estándar usando ese mecanismo. En la práctica esto significa que un archivo .geojson no garantiza automáticamente que las coordenadas estén en WGS84: si proviene de una fuente desconocida o si los valores no tienen el rango esperado (entre −180/180 para longitud y −90/90 para latitud), conviene verificar si contiene un campo crs antes de usarlo.

Shapefile depende del archivo .prj para declarar su CRS; si ese archivo se pierde al mover o compartir la carpeta, la geometría queda geográficamente huérfana y no hay forma confiable de saber en qué sistema está.

Para convertir entre sistemas, QGIS incluye la función Reproyectar capa (Vector → Herramientas de gestión de datos), y la herramienta de línea de comandos ogr2ogr permite hacerlo con un solo comando.

Formatos de archivo

GeoJSON

El formato más usado para datos geoespaciales en proyectos web y de análisis. Es texto plano estructurado como JSON, lo que significa que puede abrirse y leerse con cualquier editor de texto.

Características principales:

• Un solo archivo .geojson
• Siempre usa WGS84 (EPSG:4326) como sistema de referencia de coordenadas
• Soporta propiedades adicionales (properties) en cada feature para guardar metadatos como el ID de ruta, el nombre o el sentido
• Compatible con prácticamente todas las herramientas GIS modernas, APIs web y bibliotecas de mapas

Es el formato de trabajo recomendado para almacenar rutas en este tipo de proyectos. La especificación completa está documentada en la RFC 7946.

Propiedades recomendadas

El bloque properties de cada feature es el lugar para guardar los metadatos que conectan el archivo geoespacial con el resto del sistema — especialmente con GTFS. Los campos mínimos recomendados para un archivo de ruta son:

Campo	Descripción	Relación con GTFS
route_id	Identificador de la ruta	routes.txt → route_id
shape_id	Identificador de la geometría; por convención, igual al nombre del archivo sin extensión	shapes.txt y trips.txt → shape_id
direction	Texto legible: "ida" o "retorno"	Uso interno, sin campo directo en GTFS
direction_id	Numérico: 0 para ida, 1 para retorno	trips.txt → direction_id
route_short_name	Nombre corto del servicio visible al usuario	routes.txt → route_short_name

Un feature mínimo con propiedades completas se ve así:

{
  "type": "Feature",
  "geometry": { "type": "LineString", "coordinates": [[...], [...]] },
  "properties": {
    "route_id": "r01",
    "shape_id": "r01-ida",
    "direction": "ida",
    "direction_id": 0,
    "route_short_name": "Ruta 1"
  }
}

Incluir estas propiedades desde el inicio evita tener que abrir y editar cada archivo después cuando se genera el GTFS.

KML / KMZ

KML (Keyhole Markup Language) es un formato XML originalmente diseñado para Google Earth. KMZ es la versión comprimida (zip) del mismo formato.

Es útil para visualización: permite definir estilos visuales (colores, grosor de línea, iconos) directamente en el archivo. Sin embargo, no es adecuado como formato de intercambio de datos para análisis o procesamiento, ya que muchas herramientas GIS lo soportan solo parcialmente.

Además, la representación gráfica —estilos, colores u otros elementos de visualización— debería mantenerse separada de los datos geoespaciales en sí. Mantener la visualización independiente permite reutilizar los mismos datos en múltiples contextos (mapas web, análisis, impresión) sin incorporar decisiones de estilo en el archivo de datos, evita la duplicación y facilita el mantenimiento y la internacionalización de símbolos y leyendas.

Shapefile

El Shapefile es el formato heredado de ESRI y durante décadas fue el estándar de facto en sistemas de información geográfica. Surgió a finales de los años noventa como parte del ecosistema de Esri y rápidamente se convirtió en el mecanismo universal de intercambio espacial entre dependencias gubernamentales, consultoras, universidades y proveedores de software GIS.

Aún hoy sigue siendo extremadamente común en:

• Portales de datos abiertos gubernamentales
• Licitaciones y entregables institucionales
• Catastros y planeación urbana
• Dependencias ambientales
• Consultoras de ingeniería
• Equipos que continúan operando sobre herramientas GIS tradicionales

Parte de su permanencia se debe a que prácticamente cualquier software geoespacial puede leerlo:

• ArcGIS Pro
• QGIS
• AutoCAD Map 3D
• Librerías GDAL/OGR
• Software CAD y ETL geoespacial

Sin embargo, el formato refleja decisiones técnicas de hace más de 25 años y sus limitaciones son ampliamente conocidas.

La primera es estructural: un “Shapefile” realmente no es un solo archivo. Es un conjunto coordinado de archivos relacionados. Como mínimo requiere:

• .shp → geometrías;
• .shx → índice espacial;
• .dbf → tabla de atributos.

Frecuentemente también incluye:

• .prj → sistema de referencia espacial;
• .cpg → codificación de caracteres;
• .sbn / .sbx → índices espaciales;
• .xml → metadatos.

Esto provoca problemas operativos constantes:

• Archivos faltantes
• Aroyecciones perdidas
• Errores de codificación
• Datasets “rotos” al moverlos manualmente

Compartir un Shapefile implica mover todos los componentes juntos y mantener exactamente el mismo nombre base.

Otra limitación histórica importante es la tabla de atributos. El formato DBF heredado impone restricciones:

• Nombres de columna limitados a 10 caracteres
• Tipos de datos reducidos
• Soporte muy limitado para Unicode
• Problemas frecuentes con acentos y caracteres especiales
• Precisión numérica limitada en ciertos flujos

Esto obliga a abreviaciones crípticas como:

• nom_ruta
• id_tramo
• sentido_a

y genera datasets difíciles de interpretar o documentar correctamente.

También existen límites físicos y funcionales:

• Tamaño máximo aproximado de 2 GB por archivo
• Rendimiento deficiente en datasets muy grandes
• Ausencia de topología nativa
• Incapacidad para almacenar múltiples capas en un solo contenedor
• Soporte deficiente para fechas y tiempo
• Sin soporte real para estructuras complejas o datos jerárquicos

Además, cada Shapefile solo puede contener un único tipo geométrico: Puntos, líneas o polígonos. No puede mezclar geometrías heterogéneas de forma limpia como sí ocurre en formatos más modernos.

Por eso, para proyectos nuevos generalmente se recomienda utilizar otras alternativas más modernas.

En la práctica, el Shapefile hoy suele utilizarse principalmente por compatibilidad institucional. Continúa siendo útil cuando:

• Una dependencia gubernamental lo exige explícitamente
• Existe interoperabilidad con sistemas heredados
• El flujo depende de software antiguo
• El destinatario no puede consumir formatos modernos

Fuera de esos casos, rara vez es la mejor opción técnica para nuevos proyectos.

GeoPackage

GeoPackage es un archivo SQLite con extensión .gpkg. Es el reemplazo moderno del Shapefile: un solo archivo que puede contener múltiples capas geométricas y tablas de atributos sin las limitaciones del Shapefile.

Es la opción recomendada cuando se intercambia información con equipos GIS que trabajan con herramientas como QGIS o ArcGIS, ya que supera al Shapefile en todos los aspectos técnicos mientras mantiene compatibilidad amplia.

CSV con geometría

Un archivo CSV puede contener datos geoespaciales de dos formas:

• Columnas de coordenadas (latitud, longitud): práctico para datos de puntos, no sirve directamente para líneas.
• Columna WKT (Well-Known Text): una columna de texto que describe la geometría como LINESTRING(...). Permite representar líneas en un CSV, aunque requiere que la herramienta receptora sepa interpretarlo.

Es el formato más simple pero también el más limitado para datos de rutas. Útil para paradas o puntos de control, menos adecuado para trayectos.

GTFS shapes.txt

shapes.txt es el archivo de GTFS que describe la geometría de los trayectos como una secuencia de puntos con un identificador (shape_id) y un número de orden (shape_pt_sequence). No es un formato GIS de propósito general — es específicamente la forma en que GTFS codifica trayectos para consumo por aplicaciones de tránsito.

Los trayectos se almacenan en GeoJSON durante el trabajo de campo y procesamiento; shapes.txt es el resultado de exportar esos trayectos al estándar GTFS.

Comparativa

Formato	Archivos	CRS	Capas múltiples	Legible	Usar cuando
GeoJSON	1 .geojson	WGS84 fijo	No	Sí	Trabajo diario, web, GTFS
KML / KMZ	1	WGS84	No	Sí (verbose)	Solo visualización
Shapefile	3–8	Flexible (.prj)	No	No	Compatibilidad institucional
GeoPackage	1 .gpkg	Flexible	Sí	No	Intercambio con equipos GIS
CSV	1	Implícito	No	Sí	Paradas y puntos
GTFS shapes.txt	1	WGS84	No	Sí	Salida final a apps de tránsito

Precisión de coordenadas

Las coordenadas geográficas se expresan en grados decimales. Cada dígito decimal adicional aumenta la precisión, pero el rendimiento práctico disminuye rápidamente:

Decimales	Precisión aproximada
1	~11 km
2	~1.1 km
3	~111 m
4	~11 m
5	~1.1 m
6	~0.11 m
7	~1.1 cm
8	~1.1 mm

Para rutas de transporte público, 6 decimales es más que suficiente ya que los vehículos no operan con precisión de centímetros. Muchas herramientas de exportación generan por defecto 14 o 15 decimales, lo que solo aumenta el tamaño del archivo sin beneficio real.

Recomendación para proyectos de transporte público

• Formato de trabajo: GeoJSON con un archivo por trayecto, nombrado con el identificador de ruta y la dirección (ruta-01-ida.geojson, ruta-01-retorno.geojson).
• Intercambio con equipos GIS: GeoPackage evita las limitaciones de columnas del Shapefile y es un solo archivo.
• Evitar: KML/KMZ y Shapefile para intercambio de datos para proyectos nuevos salvo que el destinatario lo requiera explícitamente.