Prácticas recomendadas de GTFS

Referencia principal de GTFS

Estas son las prácticas recomendadas para describir los servicios de transporte público en la Especificación general de feeds de transporte público (GTFS). Estas prácticas se sintetizaron a partir de la experiencia de los miembros del grupo de trabajo de prácticas recomendadas de GTFS y de las recomendaciones de GTFS específicas para aplicaciones. A fin de obtener más información, consulta las Preguntas frecuentes.

Estructura del documento

Las prácticas se organizan en tres secciones principales:

Preguntas frecuentes

¿Por qué son importantes estas prácticas recomendadas de GTFS?

Estos son los objetivos de las prácticas recomendadas de GTFS:

  • Mejorar la experiencia del usuario final de las apps de transporte público
  • Permitir una amplia interoperabilidad de datos para facilitarles a los desarrolladores de software la implementación y escalación de aplicaciones, productos y servicios
  • Facilitar el uso de GTFS en varias categorías de aplicaciones (más allá de su enfoque original en la planificación de viajes)

Sin un conjunto coordinado de prácticas recomendadas de GTFS, varias aplicaciones que utilizan GTFS pueden establecer requisitos y expectativas de manera desarticulada, lo que genera que se diversifiquen los requisitos y los conjuntos de datos específicos de la aplicación, y se reduzca la interoperabilidad. Antes de la implementación de las prácticas recomendadas, había más ambigüedad y desacuerdos respecto de lo que se considera datos de GTFS formados correctamente.

¿Cómo se desarrollaron? ¿Quién las desarrolló?

El desarrollo de estas prácticas recomendadas estuvo a cargo de un grupo de trabajo de 17 organizaciones involucradas en la especificación GTFS, incluidos proveedores de apps y consumidores de datos, proveedores de transporte público y asesores con una participación extensa en GTFS. Rocky Mountain Institute convocó y facilitó el grupo de trabajo.

Los miembros del grupo de trabajo votaron las prácticas recomendadas. La mayoría se aprobó por votación unánime. En una menor proporción, estas prácticas se aprobaron por el voto de la gran mayoría de las organizaciones.

¿Por qué no se decidió cambiar solo la referencia de GTFS?

Buena pregunta. El proceso de examinar la especificación, el uso de datos y las necesidades realmente generó algunos cambios en la especificación (consulta las solicitudes de extracción cerradas en GitHub). Las modificaciones de la referencia de la especificación están sujetas a un nivel más alto de análisis y comentarios en comparación con las prácticas recomendadas. Sin embargo, todavía era necesario acordar un conjunto claro de prácticas recomendadas.

El grupo de trabajo prevé que algunas prácticas recomendadas de GTFS finalmente formarán parte de la referencia principal de GTFS.

¿Las herramientas de validación de GTFS verifican el cumplimiento de estas prácticas recomendadas?

Por el momento, ninguna herramienta de validación verifica el cumplimiento de todas las prácticas recomendadas. Determinadas herramientas de validación verifican el cumplimiento de algunas de estas prácticas recomendadas. Si deseas obtener una lista de las herramientas de validación de GTFS, consulta Pruebas de feeds. Si creas una herramienta de validación de GTFS que hace referencia a estas prácticas recomendadas, envía un correo electrónico a gtfs@rmi.org.

Represento a una empresa de transporte público. ¿Qué pasos puedo seguir para que nuestros proveedores de servicios de software sigan estas prácticas recomendadas?

Indícales a tus proveedores de servicios de software que consulten estas prácticas recomendadas. Te recomendamos que les proporciones la URL de las prácticas recomendadas de GTFS, así como la referencia principal de la especificación, como parte de los requisitos para la creación del software que produce el feed de GTFS.

¿Qué debo hacer si noto que un feed de datos de GTFS no cumple con estas prácticas recomendadas?

Identifica el contacto del feed mediante los campos feed_contact_email o feed_contact_url propuestos de feed_info.txt, en caso de que existan, o busca la información de contacto en el sitio web de la empresa de transporte público o del productor del feed. Cuando informes el problema al productor del feed, incluye el vínculo de la práctica recomendada específica de GTFS. Consulta Cómo vincular este documento.

Me gustaría proponer una modificación o incorporación a las prácticas recomendadas. ¿Cómo lo hago?

Envía un correo electrónico a gtfs@rmi.org o abre un problema o una solicitud de extracción en el repositorio de prácticas recomendadas de GTFS de GitHub.

¿Cómo puedo participar?

Envía un correo electrónico a gtfs@rmi.org.

Publicación y prácticas generales de los conjuntos de datos

Recomendaciones generales
Los conjuntos de datos se deben publicar en una URL permanente y pública, incluido el nombre del archivo ZIP (p. ej., www.agency.org/gtfs/gtfs.zip). Lo ideal sería que la URL se pueda descargar directamente, sin la necesidad de acceder al archivo, para facilitar la descarga mediante aplicaciones de software de consumo. Si bien se recomienda (y es la práctica más común) crear un conjunto de datos de GTFS que pueda descargarse abiertamente, en el caso de que un proveedor de datos necesite controlar el acceso a la especificación GTFS por cuestiones relacionadas con una licencia o por otros motivos, lo recomendable es controlar el acceso mediante claves de API, las cuales facilitarán las descargas automáticas.
Los datos de GTFS se publican en iteraciones para que un solo archivo en una ubicación estable siempre contenga la última descripción oficial del servicio de una empresa (o empresas) de transporte público.
Mantén identificadores (campos de ID) constantes para stop_id, route_id y agency_id en todas las iteraciones de datos siempre que sea posible.
Un conjunto de datos de GTFS debe contener el servicio actual y el próximo (lo que a veces se denomina conjunto de datos "combinado"). La función de combinación de la herramienta transitfeed de Google se puede usar para crear un conjunto de datos combinado a partir de dos feeds GTFS diferentes.
  • En todo momento, el conjunto de datos de GTFS publicado debe ser válido durante, al menos, los 7 días siguientes y, en el mejor de los casos, por el período en que el operador tenga la certeza de que el servicio seguirá funcionando de acuerdo con el horario.
  • Si es posible, el conjunto de datos de GTFS debe cubrir, al menos, los siguientes 30 días de servicio.
Quita los servicios antiguos (calendarios vencidos) del feed.
Si habrá una modificación del servicio en 7 días o menos, expresa ese cambio mediante un feed GTFS en tiempo real (avisos sobre el servicio o actualizaciones de viaje) en lugar de un conjunto de datos de GTFS estático.
Los datos de GTFS alojados en el servidor web se deben configurar para informar correctamente la fecha de modificación del archivo (consulta HTTP/1.1 - RCF 2616, en la sección 14.29).

Recomendaciones organizadas por archivo

En esta sección, se muestran las prácticas recomendadas organizadas por archivo y campo, de acuerdo con la referencia de GTFS.

Todos los archivos

Nombre del campo Recomendación
Combinación de mayúsculas y minúsculas Todas las strings de texto orientadas a los clientes (incluidos los nombres de paradas, los nombres de rutas y las señales de destino) deben combinar mayúsculas y minúsculas (no MAYÚSCULAS SOSTENIDAS), y seguir las convenciones locales para el uso de mayúsculas en nombres de lugares en las pantallas que pueden mostrar caracteres en minúsculas.
Ejemplos:
Brighton Churchill Square
Villiers-sur-Marne
Market Street
Abreviaturas Evita el uso de abreviaturas en el feed para los nombres y otros tipos de texto (p. ej., Av. para Avenida), a menos que la ubicación se conozca por su nombre abreviado (p. ej., "Aeropuerto JFK"). Es posible que las abreviaturas causen problemas de accesibilidad para el software de lectores de pantalla y las interfaces de usuario de voz. El software de consumo puede diseñarse para convertir correctamente las palabras completas en abreviaturas a fin de facilitar la visualización, pero la conversión de abreviaturas a palabras completas tiene más probabilidades de generar errores.

agency.txt

Nombre del campo Recomendación
agency_id Debe incluirse, aun si solo hay una empresa en el feed. (Consulta también la recomendación para incluir agency_id en routes.txt y fare_attributes.txt).
agency_lang Debe incluirse.
agency_phone Debe incluirse, a menos que no exista ningún teléfono de atención al cliente.
agency_email Debe incluirse, a menos que no exista ningún correo electrónico de atención al cliente.
agency_fare_url Debe incluirse, a menos que la empresa no cobre ningún tipo de tarifa.

Ejemplos:

  • Varias empresas de autobuses pequeñas prestan los servicios de autobús. Sin embargo, hay una empresa grande que se encarga de programar los horarios y vender los boletos, y que, desde la perspectiva de los usuarios, es responsable de los servicios de autobús. Esa empresa grande debe definirse como empresa en el feed. Incluso si los datos se dividen internamente entre diferentes operadores de autobuses pequeños, debería definirse solo una empresa en el feed.
  • El proveedor del feed administra el portal de venta de boletos, pero hay distintas empresas que realmente operan los servicios, y los usuarios las identifican como responsables. Las empresas que operan los servicios deben definirse como empresas en el feed.

stops.txt

Nombre del campo Recomendación
stop_id Las paradas que se encuentran en ubicaciones físicas distintas (es decir, diferentes ubicaciones precisas designadas para que los vehículos en rutas designadas se detengan, que se pueden distinguir por señales, cobertizos o cualquier otra información pública, ubicadas en diferentes esquinas o que representan diferentes áreas de abordaje, como una plataforma o una dársena, incluso si están cerca unas de otras) deben tener un stop_id diferente.
stop_id es un ID interno que no se muestra a los pasajeros.
Mantén valores coherentes de stop_id para las mismas paradas en las iteraciones de datos (consulta Publicación y prácticas generales de los conjuntos de datos).
stop_name El campo stop_name debe coincidir con el nombre público de la empresa para la parada, la estación o el área de abordaje, p. ej., lo que figura en un horario, se publica en línea o se presenta en la ubicación.
Si no hay un nombre de parada publicado, sigue convenciones coherentes para los nombres de paradas en todo el feed.
Evita usar abreviaturas, excepto para los lugares que son más conocidos por un nombre abreviado. Consulta la sección Abreviaturas (n.º 2) en Todos los archivos.
Proporciona nombres de paradas con una combinación de mayúsculas y minúsculas, de acuerdo con las convenciones locales y según la recomendación para todos los campos de texto orientados a los clientes.
De forma predeterminada, el campo stop_name no debe contener palabras genéricas o redundantes, como "Estación" o "Parada", pero sí se permiten algunos casos excepcionales.
  • Cuando estas palabras forman parte del nombre (Estación Alameda)
  • Cuando el campo stop_name es demasiado genérico (por ejemplo, si es el nombre de la ciudad), "Estación", "Terminal" y otras palabras hacen que el significado sea claro
stop_lat y stop_lon Las ubicaciones de paradas deben ser lo más precisas posible; deben tener un margen de error de no más de cuatro metros en comparación con la posición real.
Las ubicaciones de paradas deben colocarse muy cerca del carril peatonal por el que los pasajeros abordarán (es decir, del lado correcto de la calle).
Si una ubicación de parada se comparte entre feeds de datos distintos (p. ej., dos empresas usan exactamente la misma parada o área de abordaje), usa los mismos campos stop_lat y stop_lon para ambas paradas a fin de indicar que la parada es compartida.
stop_code stop_code debe incluirse en GTFS si hay números de parada o identificadores cortos orientados a los pasajeros.
parent_station y location_type Muchas estaciones o terminales tienen varias áreas de abordaje (que, según el medio de transporte, pueden ser dársenas de autobús, plataformas, muelles, puertas o cualquier otro término). En esos casos, los productores de feeds deben describir las estaciones, las áreas de abordaje (también conocidas como paradas secundarias) y su relación.
  • La estación o terminal debe definirse como un registro en stops.txt con el valor location_type = 1.
  • Cada área de abordaje debe definirse como una parada con el valor location_type = 0. El campo parent_station debe hacer referencia al stop_id de la estación en la que se encuentra el área de abordaje.
Al definir los nombres de la estación y las paradas secundarias, utiliza nombres que los pasajeros reconozcan y que les permitan identificar la estación y el área de abordaje (la dársena de autobús, la plataforma, el muelle, la puerta, etcétera).
Nombre de la estación principal Nombre de la parada secundaria
Chicago Union Station Plataforma 19 de Chicago Union Station
San Francisco Ferry Building Terminal Puerta E de San Francisco Ferry Building Terminal
Downtown Transit Center Dársena B de Downtown Transit Center

routes.txt

Nombre del campo Recomendación
agency_id Debe incluirse si se define en agency.txt.
route_short_name Incluye route_short_name si hay una designación breve del servicio. Debería ser el nombre por el que los pasajeros conocen el servicio y no debe tener más de 12 caracteres.
route_long_name La definición de la referencia de la especificación: Este nombre suele ser más descriptivo que el nombre que se indica en route_short_name y suele incluir el destino o la parada de la ruta. Se debe especificar, al menos, uno de los valores route_short_name o route_long_name, o bien ambos, si corresponde. Si la ruta no tiene un nombre largo, especifica un route_short_name y usa una string vacía como valor para este campo.

Estos son ejemplos de tipos de nombres largos:

Recorrido o corredor principal
Nombre de la ruta Forma Empresa
"N"/"Judah" route_short_name/
route_long_name
Muni, en San Francisco
"6"/"ML King Jr Blvd" route_short_name/
route_long_name
TriMet, en Portland, Oregón
"6"/"Nation: Étoile" route_short_name/
route_long_name
RATP, en París, Francia
"U2"/"Pankow: Ruhleben" route_short_name/
route_long_name
BVG, en Berlín, Alemania
Descripción del servicio
"Transporte del área de Hartwell"
route_long_name no debe contener el valor de route_short_name.
Incluye la designación completa, con una identidad del servicio cuando se propaga route_long_name. Ejemplos:
Identidad del servicio Recomendación Ejemplos
"MAX Light Rail"
TriMet, en Portland, Oregón
El route_long_name debe incluir la marca (MAX) y la designación específica de la ruta. "Línea roja de MAX"
"Línea azul de MAX"
"Rapid Ride"
ABQ Ride, en Albuquerque, Nuevo México
El route_long_name debe incluir la marca (Rapid Ride) y la designación específica de la ruta. "Línea roja de Rapid Ride"
"Línea azul de Rapid Ride"
route_id Todos los viajes de una ruta con un nombre determinado deben hacer referencia al mismo route_id.
  • Las diferentes direcciones de una ruta no deben separarse en distintos valores de route_id.
  • Los diferentes intervalos de operación de una ruta no deben separarse en distintos valores de route_id, es decir que no debes crear registros diferentes en routes.txt para los servicios "Downtown AM" y "Downtown PM".
Si un grupo de rutas incluye ramales con nombres distintos (p. ej., 1A y 1B), sigue las recomendaciones del caso de ramales de la ruta para determinar los valores de route_short_name y route_long_name.
route_color y route_text_color Deben ser coherentes con la señalización y la información impresa y en línea que se brinda a los clientes (y, por lo tanto, no se deben incluir si no existen en otros lugares).

trips.txt

  • Consulta el caso especial de rutas en bucle: Las rutas en bucle son casos en los que los viajes comienzan y terminan en la misma parada, a diferencia de las rutas lineales, que tienen dos terminales distintas. Sigue estas prácticas específicas para describir las rutas en bucle. Consulta la sección Rutas en bucle.
  • Consulta el caso especial de rutas de lazo: Las rutas de lazo son un híbrido de recorridos lineales y en bucle, en las que los vehículos viajan en bucle solo en una parte de la ruta. Sigue estas prácticas específicas para describir las rutas de lazo. Consulta la sección Rutas de lazo.
Nombre del campo Recomendación
trip_headsign No ingreses nombres de ruta (que coincidan con route_short_name y route_long_name) en los campos trip_headsign o stop_headsign.
Debe contener el destino, la dirección o algún otro texto de designación del viaje presente en la señal de destino del vehículo que pueda usarse para distinguir los viajes de una ruta. La coherencia con la información sobre la dirección que se muestra en el vehículo es el objetivo principal y prevaleciente para determinar qué señales de destino se proporcionan en los conjuntos de datos de GTFS. Solo se debe incluir otro tipo de información si no afecta este objetivo principal. Si las señales de destino cambian durante un viaje, anula el valor de trip_headsign con stop_times.stop_headsign. A continuación, se incluyen recomendaciones para algunos casos posibles:
Tabla de ejemplos:
Descripción de la ruta Recomendación
2A. Solo el destino Proporciona la terminal de destino, p. ej., "Transit Center", "Portland City Center" o "Jantzen Beach".
2B. Destino con puntos de referencia Indica <destino> por <punto de referencia>, p. ej., "Highgate por Charing Cross". Si se quitan los puntos de referencia de la señal de destino que se muestra a los pasajeros una vez que el vehículo pasa por esos puntos, usa stop_times.stop_headsign para establecer una señal de destino actualizada.
2C. Nombre de lugar regional con paradas locales Si habrá varias paradas en la ciudad o el municipio de destino, usa stop_times.stop_headsign una vez que llegues a la ciudad de destino.
2D. Solo la dirección Indica la dirección mediante el uso de términos como "Sentido norte", "Hacia el centro", "En sentido horario" o alguna otra indicación similar.
2E. Dirección con destino Indica <dirección> hacia <nombre de la terminal>, p. ej., "Sentido sur hacia San José".
2F. Dirección con destino y puntos de referencia Indica <dirección> por <punto de referencia> hacia <destino>, p. ej., "Sentido norte por Charing Cross hacia Highgate".
La señal de destino no debe comenzar con las palabras "A" o "Hacia".
direction_id Si hay viajes en una ruta que recorren direcciones opuestas, diferencia esos grupos de viajes mediante el campo direction_id, con los valores 0 y 1.
Usa los valores 0 y 1 de forma coherente en todo el conjunto de datos. Por ejemplo:
  • Si 1 = Ida en la ruta roja, entonces 1 = Ida en la ruta verde
  • Si 1 = Sentido norte en la ruta X, entonces 1 = Sentido norte en la ruta Y
  • Si 1 = Sentido horario en la ruta X, entonces 1 = Sentido horario en la ruta Y

stop_times.txt

Rutas en bucle: Las rutas en bucle requieren consideraciones especiales para stop_times. (Consulta la sección Rutas en bucle).

Nombre del campo Recomendación
pickup_type y drop_off_type Los viajes que no generan ingresos y que no proporcionan un servicio a los pasajeros deben marcarse con el valor 1 en pickup_type y drop_off_type para todas las filas de stop_times.
En los viajes que generan ingresos, los "puntos temporales" internos para supervisar el rendimiento operativo y otros lugares, como los estacionamientos, en los que los pasajeros no pueden abordar, deben marcarse como pickup_type = 1 (recogida de pasajeros no disponible) y drop_off_type = 1 (parada para bajar pasajeros no disponible).
timepoint Debe proporcionarse el campo timepoint. Indica qué valores de stop_times el operador intentará respetar estrictamente (timepoint=1) y especifica que los otros horarios de parada son estimaciones (timepoint=0).
arrival_time y departure_time Los campos arrival_time y departure_time deben especificar valores de tiempo siempre que sea posible, incluidos los horarios estimados o interpolados no vinculantes entre puntos temporales.
stop_headsign

Los valores de stop_headsign anulan los de trip_headsign (en trips.txt). Se deben proporcionar valores stop_headsign cuando el texto que se muestra en la señal de destino cambia durante un viaje. Los valores de stop_headsign no se transfieren a las siguientes paradas y, por lo tanto, esos valores deben repetirse si la señal de destino de la parada permanece igual. En general, los valores de las señales de destino también deben corresponderse con las señales de las estaciones.

En los siguientes casos, usar "Sentido sur" confundiría a los clientes porque ese término no se utiliza en las señales de la estación.

En Nueva York, para los 2 con sentido sur:
En las filas de stop_times.txt: Usa un valor de stop_headsign:
Hasta llegar a Manhattan Manhattan & Brooklyn
Hasta llegar a Downtown Downtown & Brooklyn
Hasta llegar a Brooklyn Brooklyn
Cuando se llega a Brooklyn Brooklyn (New Lots Av)
En Boston, para la línea roja con sentido sur, para el ramal Braintree:
En las filas de stop_times.txt: Usa un valor de stop_headsign:
Hasta llegar a Downtown Inbound to Braintree
Cuando se llega a Downtown Braintree
Después de Downtown Outbound to Braintree
shape_dist_traveled Se debe proporcionar shape_dist_traveled para las rutas con bucles o superposiciones (el vehículo cruza o recorre la misma parte del alineamiento en un viaje). Consulta la recomendación de shapes.shape_dist_traveled.

calendar.txt

Nombre del campo Recomendación
Todos los campos calendar_dates.txt solo debe contener una cantidad limitada de excepciones al horario. El servicio con horarios regulares debe configurarse mediante calendar.txt.
Si incluyes un campo calendar.service_name, también puedes aumentar la legibilidad humana de GTFS, aunque esto no se adopte en la especificación.

calendar_dates.txt

Nombre del campo Recomendación
Todos los campos calendar_dates.txt solo debe contener una cantidad limitada de excepciones al horario. El servicio con horarios regulares debe configurarse mediante calendar.txt.
Si incluyes un campo calendar.service_name, también puedes aumentar la legibilidad humana de GTFS, aunque esto no se adopte en la especificación.

fare_attributes.txt

Nombre del campo Recomendación
Todos los campos agency_id debe incluirse en fare_attributes.txt si el campo está incluido en agency.txt.
Si el sistema de tarifas no se puede modelar con exactitud, déjalo en blanco para evitar una mayor confusión.
Incluye tarifas (fare_attributes.txt y fare_rules.txt) y modélalas de la forma más exacta posible. En los casos excepcionales en los que las tarifas no se puedan modelar con exactitud, la tarifa se debe representar como más costosa en lugar de menos costosa, para que los clientes no intenten abordar con una tarifa insuficiente. Si la gran mayoría de las tarifas no pueden modelarse correctamente, no incluyas información sobre las tarifas en el feed.

fare_rules.txt

Nombre del campo Recomendación
Todos los campos agency_id debe incluirse en fare_attributes.txt si el campo está incluido en agency.txt.
Si el sistema de tarifas no se puede modelar con exactitud, déjalo en blanco para evitar una mayor confusión.
Incluye tarifas (fare_attributes.txt y fare_rules.txt) y modélalas de la forma más exacta posible. En los casos excepcionales en los que las tarifas no se puedan modelar con exactitud, la tarifa se debe representar como más costosa en lugar de menos costosa, para que los clientes no intenten abordar con una tarifa insuficiente. Si la gran mayoría de las tarifas no pueden modelarse correctamente, no incluyas información sobre las tarifas en el feed.

shapes.txt

Nombre del campo Recomendación
Todos los campos Lo ideal sería que, para los alineamientos que se comparten (es decir, los casos en los que las rutas 1 y 2 operan en el mismo tramo de ruta o recorrido), la parte compartida coincida exactamente. Esto ayuda a crear una cartografía de transporte público de alta calidad.
Los alineamientos deben seguir la línea central de la vía por la que se desplaza el vehículo. Puede ser la línea central de la calle si no hay carriles designados, o bien la línea central del lado de la ruta con el sentido en que se mueve el vehículo.

Los alineamientos no deben desviarse hasta una parada sobre un cordón, una plataforma ni un área de abordaje.
shape_dist_traveled

Se debe proporcionar en los archivos shapes.txt y stop_times.txt si un alineamiento incluye un bucle o una superposición (el vehículo cruza o recorre la misma parte del alineamiento en un viaje).

Una ruta con superposición

Si un vehículo vuelve a recorrer o cruza el alineamiento de la ruta en determinados puntos durante el transcurso de un viaje, el valor de shape_dist_traveled es importante para aclarar cómo se relacionan las partes de los puntos en shapes.txt con los registros en stop_times.txt.

El campo shape_dist_traveled permite que la empresa especifique con exactitud cómo se ajustan las paradas del archivo stop_times.txt a su respectiva forma. Un valor común para el campo shape_dist_traveled es la distancia desde el principio de la forma que el vehículo recorre (como una lectura del odómetro).
  • Los alineamientos de rutas (en shapes.txt) deben estar a no más de 100 metros de las ubicaciones de las paradas de un viaje.
  • Simplifica los alineamientos para que shapes.txt no contenga puntos ajenos (es decir, quita los puntos adicionales en tramos de línea recta; consulta el debate sobre el problema de simplificación de la línea).

feed_info.txt

Debe incluirse feed_info.txt, con todos los campos que se indican a continuación.

Nombre del campo Recomendación
feed_start_date y feed_end_date Deben incluirse
feed_version Debe incluirse
feed_contact_email y feed_contact_url Proporciona al menos uno

frequencies.txt

Nombre del campo Recomendación
Todos los campos Se ignoran los horarios de parada reales de los viajes a los que hace referencia frequencies.txt; solo los intervalos de tiempo de viaje entre paradas son importantes para los viajes basados en la frecuencia. Por motivos de claridad o legibilidad humana, se recomienda que el horario de la primera parada de un viaje al que se hace referencia en frequencies.txt comience a las 00:00:00 (primer valor de arrival_time de 00:00:00).
block_id Se puede proporcionar para viajes basados en la frecuencia.

transfers.txt

transfers.transfer_type puede ser uno de los cuatro valores definidos en la especificación GTFS. Las siguientes definiciones de transfer_type corresponden a la especificación GTFS, con algunas recomendaciones adicionales.

Nombre del campo Recomendación
transfer_type 0 o (vacío): Indica el punto de trasbordo recomendado entre rutas.

Si hay varias oportunidades de trasbordo que incluyen una opción superior (es decir, una estación de transporte público con servicios adicionales o una estación con plataformas o áreas de abordaje adyacentes o conectadas), especifica un punto de trasbordo recomendado.

1: Indica el punto de trasbordo programado entre dos rutas. El vehículo que sale espera al que llega con el tiempo suficiente para que un pasajero pueda realizar un trasbordo entre rutas.

Este tipo de trasbordo anula un intervalo obligatorio para realizar trasbordos de forma segura. A modo de ejemplo, Google Maps supone que los pasajeros necesitan 3 minutos para realizar un trasbordo de manera segura. Otras aplicaciones pueden asumir otros valores de forma predeterminada.

2: Indica que se requiere una cantidad mínima de tiempo para realizar un trasbordo entre la llegada y la salida a fin de garantizar una conexión. El tiempo requerido para dicho transbordo se especifica en min_transfer_time.

Especifica el tiempo de trasbordo mínimo si hay obstrucciones y otros factores que pueden aumentar el tiempo de viaje entre paradas.

3: Indica que no es posible realizar trasbordos entre rutas en esta ubicación.

Especifica este valor si no es posible realizar trasbordos debido a barreras físicas o si estos son riesgosos o inseguros debido a cruces complicados o áreas sin acceso a la red peatonal.

Si se permite permanecer en el mismo vehículo para realizar trasbordos entre viajes, la última parada del viaje que llega debe ser la misma que la primera parada del viaje que sale.

Recomendaciones organizadas por caso

En esta sección, se analizan casos particulares que tienen implicaciones en archivos y campos.

Rutas en bucle

En las rutas en bucle, los viajes de los vehículos comienzan y terminan en la misma ubicación (a veces, una estación de transporte público o de trasbordos). Por lo general, los vehículos funcionan de forma continua y permiten que los pasajeros permanezcan en el vehículo mientras este continúa su recorrido.

Abajo: Ruta en bucle. El vehículo regresa al punto de partida en un viaje. Algunas rutas en bucle ofrecen viajes en una dirección y otras, en dos direcciones.
Ruta en bucle

Por lo tanto, se deben aplicar las recomendaciones de las señales de destino para mostrar a los pasajeros la dirección hacia la que se dirige el vehículo.

Para indicar que la dirección del viaje cambia, proporciona stop_headsigns en el archivo stop_times.txt. El valor de stop_headsign describe la dirección de los viajes que salen de la parada para la que se definió. Agregar stop_headsigns a cada parada de un viaje te permite cambiar la información de la señal de destino durante un viaje.

No definas un solo viaje circular en el archivo stop_times.txt para una ruta que opera entre dos extremos (como cuando el mismo autobús hace el recorrido de ida y vuelta). En cambio, divide el viaje en dos direcciones diferentes.

Ejemplos de modelos de viaje circular:

Viaje circular en el que la señal de destino cambia en cada parada:

Trip_id arrival_time departure_time stop_id stop_sequence stop_headsign
trip_1 06:10:00 06:10:00 stop_A 1 "B"
trip_1 06:15:00 06:15:00 stop_B 2 "C"
trip_1 06:20:00 06:20:00 stop_C 3 "D"
trip_1 06:25:00 06:25:00 stop_D 4 "E"
trip_1 06:30:00 06:30:00 stop_E 5 "A"
trip_1 06:35:00 06:35:00 stop_A 6 ""

Viaje circular con dos señales de destino:

Trip_id arrival_time departure_time stop_id stop_sequence stop_headsign
trip_1 06:10:00 06:10:00 stop_A 1 "outbound"
trip_1 06:15:00 06:15:00 stop_B 2 "outbound"
trip_1 06:20:00 06:20:00 stop_C 3 "outbound"
trip_1 06:25:00 06:25:00 stop_D 4 "inbound"
trip_1 06:30:00 06:30:00 stop_E 5 "inbound"
trip_1 06:35:00 06:35:00 stop_F 6 "inbound"
trip_1 06:40:00 06:40:00 stop_A 7 ""
Nombre del campo Recomendación
trips.trip_id Modela el recorrido de ida y vuelta completo para el bucle con un solo viaje.
stop_times.stop_id Incluye la primera o la última parada dos veces en stop_times.txt para el viaje que es un bucle. Consulta un ejemplo a continuación. En una ruta en bucle, es posible que el primer y el último viaje no hagan el recorrido completo. Incluye también esos viajes.
trip_id stop_id stop_sequence
9000 101 1
9000 102 2
9000 103 3
9000 101 4
trips.direction_id Si el bucle funciona en direcciones opuestas (es decir, en sentido horario y en sentido antihorario), designa direction_id como 0 o 1.
trips.block_id Indica viajes en bucle continuos con el mismo block_id.

Rutas de lazo

Las rutas de lazo combinan aspectos de una ruta en bucle y una ruta lineal.

Abajo: Las rutas de lazo son rutas en bucle de A hacia A por B con tres secciones:
  • recorrido lineal desde A hacia B
  • bucle desde y hacia B
  • recorrido lineal desde B hacia A
Ruta de lazo
Ejemplos:
Rutas de metro (Chicago)
Rutas de autobús desde los suburbios hacia el centro (St. Albert o Edmonton)
Línea marrón de CTA (sitio web de CTA y TransitFeeds)
Nombre del campo Recomendación
trips.trip_id La extensión total de un "viaje de ida y vuelta de un vehículo" (consulta la imagen arriba) consiste en viajar desde A hacia B y desde B hacia A. Un recorrido de ida y vuelta completo de un vehículo se puede expresar de las siguientes maneras:
  • Un solo valor o registro de trip_id en trips.txt
  • Varios valores o registros de trip_id en trips.txt, con el viaje continuo indicado por block_id
  • stop_times.stop_headsign Las paradas del recorrido A-B estarán disponibles en ambas direcciones. stop_headsign facilita la distinción de la dirección del viaje. Por lo tanto, se recomienda proporcionar stop_headsign para esos viajes.
    Ejemplos:
    "A por B"
    "A"
    Línea púrpura de la Autoridad de Tránsito de Chicago
    "Sentido sur hacia el bucle"
    "Sentido norte por el bucle"
    "Sentido norte hacia Linden"
    Líneas de autobús del Servicio de Transporte Público de Edmonton, aquí la 39
    "Rutherford"
    "Century Park"
    trip.trip_headsign La señal de destino del viaje debe ser una descripción global del viaje, como se muestra en los horarios. Puede ser "Linden hacia Linden por el bucle" (ejemplo de Chicago) o "A hacia A por B" (ejemplo genérico).

    Ramales

    Algunas rutas pueden incluir ramales. Los ramales comparten alineamientos y paradas, pero cada uno también tiene paradas y secciones de alineamientos diferentes. La relación entre los ramales puede indicarse mediante nombres de ruta, señales de destino y nombres cortos de viajes de acuerdo con los lineamientos adicionales que se incluyen a continuación.

    Abajo: Tres posibles configuraciones de ramales de ruta. El alineamiento principal se indica en negro. El ramal se indica en color dorado.
    Configuraciones de ramales de ruta
    Nombre del campo Recomendación
    Todos los campos Para asignar nombres a las rutas con ramales, se recomienda seguir otros materiales de información para los pasajeros. A continuación, se incluyen descripciones y ejemplos de dos casos:
    Si los horarios y las señales en la vía pública representan dos rutas con nombres diferentes (p. ej., 1A y 1B), ingrésalo de esta forma en la especificación GTFS mediante los campos route_short_name o route_long_name. Por ejemplo, las rutas 2, 2A y 2B del sistema de transporte público GoDurham comparten un alineamiento común a lo largo de la mayor parte de la ruta, pero varían en diversos aspectos.
    • La ruta 2 es el servicio principal que funciona la mayoría de las horas.
    • La ruta 2 incluye un desvío en Main Street por la noche, los domingos y los feriados.
    • Las rutas 2A y 2B operan durante el día, de lunes a sábado.
    • La ruta 2B incluye paradas adicionales en un desvío del alineamiento de la ruta compartida.
    Si la información que proporciona la empresa describe los ramales como una ruta con el mismo nombre, usa los campos trips.trip_headsign, stop_times.stop_headsign o trips.trip_short_name. Por ejemplo, la ruta 300 de GoTriangle viaja a diferentes ubicaciones según la hora del día. Durante las horas pico, se agregan tramos adicionales a la ruta estándar para los trabajadores que entran a la ciudad y salen de esta.

    Acerca de este documento

    Objetivos

    Estos son los objetivos de las prácticas recomendadas de la especificación GTFS:

    • Ofrecer una mayor interoperabilidad de los datos de transporte público
    • Mejorar la experiencia del usuario final en las apps de transporte público
    • Facilitar a los desarrolladores de software el proceso de implementación y escalación de aplicaciones, productos y servicios
    • Facilitar el uso de GTFS en varias categorías de aplicaciones (más allá de su enfoque original en la planificación de viajes)

    Cómo proponer o corregir prácticas recomendadas de GTFS publicadas

    Las aplicaciones y las prácticas de GTFS evolucionan, por lo que es posible que sea necesario modificar este documento periódicamente. Si deseas proponer una modificación para este documento, abre una solicitud de extracción en el repositorio de prácticas recomendadas de GTFS de GitHub y explica los motivos del cambio. También puedes enviar tus comentarios por correo electrónico a specifications@mobilitydata.org.

    Cómo vincular este documento

    Incluye un vínculo a este documento para proporcionar a los productores de feeds una guía sobre la formación correcta de datos de GTFS. Cada recomendación individual tiene un vínculo de anclaje. Haz clic en la recomendación para obtener la URL del vínculo de anclaje de la página.

    Si una aplicación que usa la especificación GTFS incluye requisitos o recomendaciones para las prácticas de datos de GTFS que no se describen aquí, se recomienda publicar un documento con esos requisitos o recomendaciones a fin de complementar estas prácticas recomendadas comunes.

    Grupo de trabajo de prácticas recomendadas de GTFS

    En 2016-2017, Rocky Mountain Institute convocó un grupo de trabajo de prácticas recomendadas de GTFS conformado por proveedores de transporte público, desarrolladores de aplicaciones que usan GTFS, asesores y organizaciones académicas, a fin de definir prácticas y expectativas comunes para los datos de GTFS. Estos son algunos de los miembros que conformaron este grupo de trabajo:

    Actualmente, la Organización Internacional de MobilityData mantiene este documento.