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:
- Publicación y prácticas generales de los conjuntos de datos: Estas prácticas se relacionan con la estructura general de los conjuntos de datos de GTFS y con la forma en que estos se publican.
- Recomendaciones organizadas por archivo: Las recomendaciones se organizan por archivo y campo de la especificación GTFS para vincular fácilmente las prácticas con la referencia oficial de GTFS.
- Recomendaciones organizadas por caso: En casos particulares, como las rutas de bucle, es posible que las prácticas recomendadas se deban aplicar en varios archivos y campos. Esas recomendaciones se consolidan en esta sección.
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 amplia participación 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 enmiendas a 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 abiertamente descargable, 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.
|
| 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-realtime (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, ubicaciones precisas diferentes 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.
|
|||||||||
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.
|
||||||||
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).
|
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 Estos son ejemplos de tipos de nombres largos:
|
||||||||||||||||||||
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:
|
|||||||||||||||||||||
route_id |
Todos los viajes de una ruta con un nombre determinado deben hacer referencia al mismo route_id.
|
||||||||||||||||||||
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 las 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:
|
|||||||||||||||
| 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:
|
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
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. |
||||||||||||
|
|||||||||||||
|
|||||||||||||
| 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 precisión, se debe indicar el precio más alto en lugar del más bajo, para evitar que los clientes 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 precisión, se debe indicar el precio más alto en lugar del más bajo, para evitar que los clientes 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 
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 |
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).
|
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 duración del 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 |
Si hay varias oportunidades de transbordo 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 transbordo recomendado. |
Cada consumidor de datos calcula la cantidad de tiempo que necesita para este intervalo a través de su propio algoritmo. Si este valor es insuficiente o si hay otras condiciones que el consumidor no consideró, puedes anular los cálculos de tiempo después de establecer |
|
Especifica el tiempo de trasbordo mínimo si hay obstrucciones y otros factores que pueden aumentar el tiempo de viaje entre paradas. |
|
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.
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.
|
|||||||||||||||
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.
- recorrido lineal desde A hacia B
- bucle desde y hacia B
- recorrido lineal desde B hacia A
| 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:
trip_id en trips.txttrip_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.
|
||||||||||
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.
| 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.
|
|
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 el ingreso y egreso de trabajadores de la ciudad. |
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 enmendar 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ó a 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 para definir prácticas y expectativas comunes para los datos de GTFS. Estos son algunos de los miembros que conformaron este grupo de trabajo:
- Cambridge Systematics
- Capital Metro
- Center for Urban Transportation Research at University of South Florida
- Conveyal
- IBI Group
- Mapzen
- Microsoft
- Moovel
- Oregon Department of Transportation
- Swiftly
- Transit
- Trillium
- TriMet
- Banco Mundial
Actualmente, la Organización Internacional de MobilityData mantiene este documento.