Saltar a contenido

Mejores prácticas de GTFS Schedule

Se trata de prácticas recomendadas para describir los servicios de transporte público en la General Transit Feed Specification. Estas prácticas se han sintetizado a partir de la experiencia de los miembros del grupo de trabajo de las mejores prácticas y de las recomendaciones de prácticas GTFS específicas para cada aplicación.

Para más información, consulte las Preguntas frecuentes.

Estructura del documento

Las prácticas están organizadas en cuatro secciones principales:

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

  • Los conjuntos de datos deben publicarse en una URL pública y permanente, incluyendo el nombre del archivo zip. (por ejemplo, www.agency.org/gtfs/gtfs.zip). Idealmente, la URL debería poder descargarse directamente sin necesidad de iniciar sesión para acceder al archivo, para facilitar la descarga por parte de las aplicaciones de software consumidoras. Aunque se recomienda (y es la práctica más habitual) que un conjunto de datos GTFS pueda descargarse abiertamente, si un proveedor de datos necesita controlar el acceso a GTFS por razones de licencia o de otro tipo, se recomienda controlar el acceso al conjunto de datos GTFS mediante claves API, lo que facilitará las descargas automáticas.
  • Los datosGTFS se publican en iteraciones, de modo que un único archivo en una ubicación estable contiene siempre la última descripción oficial del servicio de una agencia de transporte (o agencias).
  • Mantener identificadores persistentes (campos id) para stop_id, route_id, y agency_id a través de iteraciones de datos siempre que sea posible.
  • Un conjunto de datos GTFS debe contener el servicio actual y el próximo (a veces denominado conjunto de datos "fusionado"). La función de fusión de la herramienta Google transitfeed puede utilizarse para crear un conjunto de datos fusionado a partir de dos fuentes GTFS diferentes.
    • En cualquier momento, el conjunto de datos GTFS publicado debe ser válido durante al menos los próximos 7 días, e idealmente durante todo el tiempo que el operador confíe en que el Schedule seguirá funcionando.
    • Si es posible, el conjunto de datos GTFS debería cubrir al menos los próximos 30 días de servicio.
  • Eliminar los servicios antiguos (calendarios caducados) del feed.
  • Si una modificación del servicio entrará en vigencia en 7 días o menos, exprese este cambio de servicio a través de un feed GTFS-realtime (avisos de servicio o actualizaciones de viaje) en lugar de un conjunto de datos GTFS estático.
  • El servidor web que aloja los datos GTFS debe estar configurado para informar correctamente de la fecha de modificación del archivo (véase HTTP/1.1 - Request for Comments 2616, en la sección 14.29).

Recomendaciones prácticas organizadas por expediente

Esta sección muestra las prácticas organizadas por archivo y campo, alineándose con la referencia.

Todos los archivos

Nombre del campo Recomendación
Mayúsculas y minúsculas Todas las cadenas de texto orientadas al cliente (incluidos los nombres de las paradas, los nombres de las rutas y las señales de cabeza) deben utilizar mayúsculas y minúsculas (no TODAS LAS MAYÚSCULAS), siguiendo las convenciones locales para el uso de mayúsculas en los nombres de lugares en pantallas capaces de mostrar caracteres en minúsculas.
Ejemplos:
Brighton Churchill Square
Villiers-sur-Marne
Calle del Mercado
Abreviaturas Evite el uso de abreviaturas en los nombres y otros textos (por ejemplo, St. para calle) a menos que un lugar se llame por su nombre abreviado (por ejemplo, "Aeropuerto JFK"). Las abreviaturas pueden ser problemáticas para la accesibilidad del software de lectura de pantalla y las interfaces de usuario de voz. El software de consumo puede diseñarse para convertir de forma fiable las palabras completas en abreviaturas para su visualización, pero la conversión de abreviaturas en palabras completas es más propensa a errores.

agency.txt

Nombre del campo Recomendación
agency_id Debe incluirse, incluso si sólo hay una agencia en el feed. (Véase también la recomendación de incluir agency_id en routes.txt y fare_attributes.txt)
agency_phone Debe incluirse a menos que no exista un teléfono de atención al cliente.
agency_email Debe incluirse a menos que no exista un correo electrónico de atención al cliente.
agency_fare_url Debe incluirse a menos que la agencia esté totalmente libre de tarifas.

Ejemplos:

  • Los servicios de autobús son gestionados por varias agencias pequeñas. Pero hay una gran agencia que es responsable de la programación y la emisión de billetes y, desde la perspectiva del usuario, responsable de los servicios de autobús. Incluso si los datos se dividen internamente por diferentes operadores de autobuses pequeños, sólo debería haber una agencia definida en el feed.

  • El proveedor del feed gestiona el portal de venta de billetes, pero hay diferentes agencias que realmente operan los servicios y que los usuarios conocen como responsables. Las agencias que realmente operan los servicios deberían definirse como agencias dentro del feed.

stops.txt

Nombre del campo Recomendación
stop_name Cuando no haya un nombre de parada publicado, siga las convenciones de nomenclatura de las paradas en todo el feed.
Por defecto, stop_name no debe contener palabras genéricas o redundantes como "Estación" o "Parada", pero se permiten algunos casos extremos.
  • Cuando forma parte del nombre (Union Station, Central Station
  • Cuando el stop_name es demasiado genérico (por ejemplo, si es el nombre de la ciudad). "Estación", "Terminal" u otras palabras aclaran el significado.
stop_lat & stop_lon Las ubicaciones de las paradas deben ser lo más precisas posible. Las ubicaciones de las paradas deben tener un error de no más de cuatro metros en comparación con la posición real de la parada.
Las ubicaciones de las paradas deben situarse muy cerca del derecho de paso de los peatones donde subirá el pasajero (es decir, el lado correcto de la calle).
Si una ubicación de parada se comparte a través de fuentes de datos separadas (es decir, dos agencias utilizan exactamente la misma parada / instalación de embarque), indique que la parada se comparte utilizando exactamente el mismo stop_lat y stop_lon para ambas paradas.
parent_station & location_type Muchas estaciones o terminales tienen múltiples instalaciones de embarque (dependiendo del modo, pueden llamarse bahía de autobuses, plataforma, muelle, puerta u otro término). En estos casos, los productores de alimentos deben describir las estaciones, las instalaciones de embarque (también llamadas paradas secundarias) y su relación.
  • La estación o terminal debe definirse como un registro en stops.txt con location_type = 1.
  • Cada instalación de embarque debe definirse como una parada con location_type = 0. El sitio web parent_station debe hacer referencia al campo stop_id de la estación en la que se encuentra la instalación de embarque.
Al nombrar la estación y las paradas secundarias, establezca nombres que sean bien reconocidos por los usuarios, y que puedan ayudar a los usuarios a identificar la estación y la instalación de embarque (bahía de autobuses, plataforma, muelle, puerta, etc.).
Nombre de la estación padreNombre de la parada secundaria
Estación Chicago UnionChicago Union Station Andén 19
San Francisco Ferry Building TerminalTerminal del Edificio del Ferry de San Francisco Puerta E
Centro de tránsito del centro de la ciudadCentro de tránsito del centro de la ciudad Bahía B

routes.txt

Nombre del campo Recomendación
agency_id Debería incluirse, aunque sólo haya una agencia en el feed. (Véase también la recomendación de incluir agency_id en agency.txt y fare_attributes.txt)
route_short_name Incluya route_short_name si hay una designación breve del servicio. Debe ser el nombre de pasajero comúnmente conocido del servicio, de no 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_corto_de_la_ruta y suele incluir el destino o la parada de la ruta. Al menos uno de los dos nombres nombre_corto_de_la_ruta o nombre_largo_de_la_ruta debe ser especificado, o potencialmente ambos si es apropiado. Si la ruta no tiene un nombre largo, especifique un nombre_corto_de_la_ruta y utilice una cadena vacía como valor para este campo.
A continuación se muestran ejemplos de tipos de nombres largos:
Ruta o corredor primario
Nombre de la rutaFormularioAgencia
"N"/"Judah"nombre_corto_de_la_ruta/
nombre_largo_de_la_ruta		Muni, en San Francisco
"6"/"ML King Jr Blvd"nombre_corto_de_la_ruta/
nombre_largo_de_la_ruta		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
“Hartwell Area Shuttle“
route_long_name no debe contener el route_short_name.
Incluya la designación completa, incluida la identidad del servicio, al rellenar route_long_name. Ejemplos:
Identidad de servicioRecomendaciónEjemplos
"Metro Ligero MAX"
TriMet, en Portland, Oregón		El nombre_largo_de_la_ruta debe incluir la marca (MAX) y la designación de la ruta específica"Línea roja MAX" "Línea azul MAX"
"Rapid Ride"
ABQ Ride, en Albuquerque, Nuevo México		El nombre_largo_de_la_ruta debe incluir la marca (Rapid Ride) y la designación de la ruta específica"Rapid Ride Red Line"
"Rapid Ride Blue Line"
route_id Todos los viajes de una ruta con nombre deben hacer referencia a la misma route_id.
  • Las diferentes direcciones de una ruta no deben separarse en diferentes route_id valores.
  • Los diferentes periodos de funcionamiento de una ruta no deben separarse en valores diferentes route_id es decir, no se deben crear registros diferentes en routes.txt para los servicios "Centro AM" y "Centro PM").
    		•
    Si un grupo de rutas incluye ramas con nombres distintos (por ejemplo, 1A y 1B), siga las recomendaciones de la ruta ramas caso para determinar route_short_name y route_long_name.
    route_color & route_text_color Deben ser coherentes con la señalización y la información impresa y en línea para los clientes (y, por tanto, no se incluyen si no existen en otros lugares).

    trips.txt

    • Véase 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 terminaciones distintas. Las rutas en bucle deben describirse siguiendo prácticas específicas. Véase el caso de las rutas en bucle.
    • Véase el caso especial de las rutas de lazo: Las rutas de lazo son un híbrido de las geometrías lineales y de bucle, en las que los vehículos viajan en bucle sólo durante una parte de la ruta. Las rutas de lazo deben describirse siguiendo prácticas específicas. Véase el caso de las rutas Lasso.
    Nombre del campo Recomendación
    trip_headsign No proporcione los nombres de las rutas (que coincidan con route_short_name y route_long_name) en la trip_headsign o stop_headsign campos.
    Debe contener el destino, la dirección y/u otro texto de designación del viaje mostrado en la señal de cabeza del vehículo que pueda utilizarse para distinguir entre los viajes de una ruta. La coherencia con la información sobre la dirección mostrada en el vehículo es el objetivo principal y primordial para determinar las señales de cabeza suministradas en los conjuntos de datos GTFS. Sólo debe incluirse otra información si no compromete este objetivo principal. Si las señales de cabeza cambian durante un viaje, anule trip_headsign con stop_times.stop_headsign. A continuación se ofrecen recomendaciones para algunos casos posibles:
    Descripción de la rutaRecomendación
    2A. Sólo destinoIndique el destino final. Por ejemplo, "Centro de tránsito", "Centro de la ciudad de Portland" o "Jantzen Beach">.
    2B. Destinos con waypoints vía " Highgate vía Charing Cross". Si los waypoints se eliminan de la señal de cabeza que se muestra a los pasajeros después de que el vehículo pase por esos waypoints, utilice stop_times.stop_headsign para establecer una señal de cabeza actualizada.>
    2C. Nombre de lugar regional con paradas localesSi habrá múltiples paradas dentro de la ciudad o municipio de destino, utilice stop_times.stop_headsign una vez alcanzada la ciudad de destino.>
    2D. Sólo direcciónIndíquelo utilizando términos como "dirección norte", "dirección interior", "dirección de las agujas del reloj" o direcciones similares.>
    2E. Dirección con destino por ejemplo, "En dirección sur hacia San José">.
    2F. Dirección con destino y waypoints vía a ("En dirección norte vía Charing Cross a Highgate").>
    No comience una señal de cabeza con las palabras "A" o "Hacia".
    direction_id Utilice los valores 0 y 1 de forma coherente en todo el conjunto de datos.
    • Si 1 = En dirección a la ruta roja, entonces 1 = En dirección a la ruta verde
    • Si 1 = hacia el Norte en la ruta X, entonces 1 = hacia el Norte en la ruta Y
    • Si 1 = en el sentido de las agujas del reloj en la ruta X, entonces 1 = en el sentido de las agujas del reloj en la ruta Y

    stop_times.txt

    Rutas en bucle: Las rutas en bucle requieren consideraciones especiales sobre los tiempos de parada. (Ver: Caso de ruta en bucle)

    Nombre del campo Recomendación
    pickup_type & drop_off_type Los viajes no rentables (sin salida) que no prestan servicio de pasajeros deben marcarse con pickup_type y drop_off_type valor de 1 para todas las stop_times filas.
    En los viajes con ingresos, los "puntos de cronometraje" internos para supervisar el rendimiento operativo y otros lugares, como los garajes, en los que un pasajero no puede subir, deben marcarse con pickup_type = 1 (no hay recogida disponible) y drop_off_type = 1 (no se puede bajar).
    timepoint El campo timepoint debería proporcionarse. Especifica qué stop_times de parada intentará respetar estrictamente el operador (timepoint=1), y que otros tiempos de parada son estimaciones (timepoint=0).
    arrival_time & departure_time arrival_time y departure_time deben especificar valores de tiempo siempre que sea posible, incluyendo tiempos estimados o interpolados no vinculantes entre puntos de tiempo.
    stop_headsign En general, los valores de las cabeceras deben corresponder también a las señales de las estaciones.

    En los casos siguientes, "Southbound" induciría a error a los clientes porque no se utiliza en las señales de las estaciones.
    En NYC, para los 2 que van en dirección sur:
    Para stop_times.txt filas:Utilice stop_headsign valor:
    Hasta llegar a ManhattanManhattan y Brooklyn
    Hasta que se alcance el centro de la ciudadCentro y Brooklyn
    Hasta que se llegue a BrooklynBrooklyn
    Una vez alcanzado BrooklynBrooklyn (Av. New Lots)
    En Boston, para la Línea Roja en dirección sur, para el ramal de Braintree:
    Para stop_times.txt filas:Utilice stop_headsign valor:
    Hasta que se alcance el centro de la ciudadEn dirección a Braintree
    Una vez que se llega al centro de la ciudadBraintree
    Después del centro de la ciudadEn dirección a Braintree
    shape_dist_traveled shape_dist_traveled debe proporcionarse para las rutas que tienen bucle o inlining (el vehículo cruza o viaja sobre la misma porción de alineación en un viaje). Véase la shapes.shape_dist_traveled recomendación.

    calendar.txt

    Nombre del campo Recomendación
    Todos los campos Incluyendo un calendar.service_name también puede aumentar la legibilidad humana de GTFS, aunque esto no se adopta en la especificación.

    calendar_dates.txt

    Nombre del campo Recomendación
    Todos los campos La inclusión de un calendar.service_name también puede aumentar la legibilidad humana de GTFS, aunque esto no se adopta en la especificación.

    fare_attributes.txt

    Nombre del campo Recomendación
    agency_id Debería incluirse, aunque sólo haya una agencia en el feed. (Véase también la recomendación de incluir agency_id en agency.txt y routes.txt)
    Si un sistema de tarifas no puede ser modelado con precisión, evite más confusión y déjelo en blanco.
    Incluir tarifas (fare_attributes.txt y fare_rules.txt) y modelarlas con la mayor precisión posible. En los casos extremos en los que las tarifas no puedan modelarse con precisión, la tarifa debe representarse como más cara en lugar de menos cara para que los clientes no intenten embarcar con una tarifa insuficiente. Si la gran mayoría de las tarifas no pueden modelarse correctamente, no incluya la información sobre las tarifas en el feed.

    fare_rules.txt

    Nombre del campo Recomendación
    Todos los campos Si un sistema de tarifas no puede ser modelado con precisión, evite más confusión y déjelo en blanco.
    Incluir tarifas (fare_attributes.txt y fare_rules.txt) y modelarlas con la mayor precisión posible. En los casos extremos en los que las tarifas no pueden modelarse con precisión, la tarifa debe representarse como más cara en lugar de menos cara para que los clientes no intenten embarcar con una tarifa insuficiente. Si la gran mayoría de las tarifas no se pueden modelar correctamente, no incluya la información sobre las tarifas en el feed.

    shapes.txt

    Nombre del campo Recomendación
    Todos los campos Lo ideal es que para las alineaciones compartidas (es decir, en el caso de que las rutas 1 y 2 operen en el mismo segmento de carretera o vía), la parte compartida de la alineación debe coincidir exactamente. Esto ayuda a facilitar una cartografía de tránsito de alta calidad.
    Las alineaciones deben seguir la línea central del derecho de paso por el que circula el vehículo. Puede tratarse de la línea central de la calle si no hay carriles designados, o de la línea central del lado de la calzada que circula en la dirección del vehículo.

    Las alineaciones no deben "saltar" a una parada en la acera, plataforma o lugar de embarque.
    shape_dist_traveled Deben proporcionarse en ambos shapes.txt y stop_times.txt si una alineación incluye un bucle o una entrada (el vehículo cruza o viaja sobre la misma porción de alineación en un viaje).
    Si un vehículo vuelve a recorrer o cruza la alineación de la ruta en algunos puntos en el curso de un viaje, shape_dist_traveled es importante aclarar cómo las porciones de los puntos en shapes.txt alineación se corresponden con los registros en stop_times.txt.
    El shape_dist_traveled campo permite a la agencia especificar exactamente cómo las paradas en el stop_times.txt archivo encajan en su forma respectiva. Un valor común a utilizar para el shape_dist_traveled es la distancia desde el principio de la forma tal y como la recorrió el vehículo (piense en algo parecido a la lectura del cuentakilómetros).
  • Las alineaciones de las rutas (en shapes.txt) deben estar dentro de los 100 metros de las ubicaciones de las paradas a las que sirve un viaje.
  • Simplifique las alineaciones para que shapes.txt no contenga puntos extra (es decir, eliminar los puntos extra en los segmentos de líneas rectas; véase la discusión del problema de la simplificación de líneas).
    		•

    frequencies.txt

    Nombre del campo Recomendación
    Todos los campos Los tiempos de parada reales se ignoran para los viajes referenciados por frequencies.txtsólo los intervalos de tiempo entre paradas son significativos para los viajes basados en la frecuencia. Para mayor claridad y legibilidad, se recomienda que la primera parada de un viaje referenciado en frequencies.txt comience a las 00:00:00 (primer valor de arrival_time valor de 00:00:00).
    block_id Puede proporcionarse para los viajes basados en la frecuencia.

    transfers.txt

    transfers.transfer_type puede ser uno de los cuatro valores definidos en el GTFS. Estas definiciones de transfer_type se citan a continuación en la especificación GTFS, en cursiva, con recomendaciones prácticas adicionales.

    Nombre del campo Recomendación
    transfer_type 0 o (vacío): Este es un punto de transferencia recomendado entre rutas.
    Si hay varias oportunidades de transbordo que incluyen una opción superior (es decir, un centro de tránsito con servicios adicionales o una estación con instalaciones/plataformas de embarque adyacentes o conectadas), especifique un punto de transbordo recomendado.
    1: Se trata de un punto de transbordo temporizado entre dos rutas. Se espera que el vehículo que sale espere al que llega, con tiempo suficiente para que el pasajero pueda hacer el transbordo entre rutas.
    Este tipo de transbordo anula un intervalo necesario para realizar los transbordos de forma fiable. Como ejemplo, Google Maps asume que los pasajeros necesitan 3 minutos para hacer un transbordo con seguridad. Otras aplicaciones pueden asumir otros valores por defecto.
    2: Este traslado requiere un tiempo mínimo entre la llegada y la salida para garantizar la conexión. El tiempo necesario para el traslado se especifica con min_transfer_time.
    Especifique el tiempo mínimo de transferencia si hay obstáculos u otros factores que aumenten el tiempo de viaje entre las paradas.
    3: No es posible realizar transbordos entre rutas en esta ubicación.
    Especifique este valor si los transbordos no son posibles debido a barreras físicas, o si se hacen inseguros o complicados por cruces de calles difíciles o vacíos en la red peatonal.
    Si se permiten los transbordos en bloque entre trayectos, la última parada del trayecto de llegada debe ser la misma que la primera parada del trayecto de salida.

    feed_info.txt

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

    Nombre del campo Recomendación
    feed_start_date & feed_end_date Debe incluirse
    feed_version Debe incluirse
    feed_contact_email & feed_contact_url Proporcione al menos un

    Recomendaciones prácticas organizadas por casos

    Esta sección cubre casos particulares con implicaciones a través de archivos y campos.

    Rutas en bucle

    En las rutas en bucle, los viajes de los vehículos comienzan y terminan en el mismo lugar (a veces un centro de tránsito o de transferencia). Los vehículos suelen funcionar de forma continua y permiten que los pasajeros permanezcan a bordo mientras el vehículo continúa su bucle.

    Por lo tanto, deben aplicarse las recomendaciones de las señales de cabeza para mostrar a los pasajeros la dirección en la que va el vehículo.

    Para indicar el cambio de dirección de la marcha, proporcione stop_headsigns en el archivo stop_times.txt. El stop_headsign describe la dirección de los viajes que salen de la parada para la que está definido. Añadir señales de parada a cada parada de un viaje le permite cambiar la información de la señal de cabeza a lo largo de un viaje.

    No defina un único viaje circular en el archivo stop_times.txt para una ruta que opera entre dos puntos finales (como cuando el mismo autobús va y viene). En su lugar, divida el viaje en dos direcciones de viaje separadas.

    Ejemplos de modelado de viajes circulares:

    • Viaje circular con cambio de señal de cabeza en cada parada
    trip_id hora_de_llegada hora de salida stop_id stop_sequence signo_de_cabeza_de_parada
    viaje_1 06:10:00 06:10:00 parada_A 1 "B"
    trip_1 06:15:00 06:15:00 parada_B 2 "C"
    viaje_1 06:20:00 06:20:00 parada_C 3 "D"
    viaje_1 06:25:00 06:25:00 parada_D 4 "E"
    viaje_1 06:30:00 06:30:00 parada_E 5 "A"
    viaje_1 06:35:00 06:35:00 stop_A 6 ""
    • Viaje circular con dos señales de cabeza
    trip_id hora_de_llegada hora_de_salida stop_id stop_sequence stop_headsign
    viaje_1 06:10:00 06:10:00 stop_A 1 "de salida"
    viaje_1 06:15:00 06:15:00 parada_B 2 "outbound"
    viaje_1 06:20:00 06:20:00 stop_C 3 "de salida"
    viaje_1 06:25:00 06:25:00 stop_D 4 "de entrada"
    viaje_1 06:30:00 06:30:00 stop_E 5 "de entrada"
    viaje_1 06:35:00 06:35:00 parada_F 6 "de entrada"
    trip_1 06:40:00 06:40:00 stop_A 7 ""
    Nombre del campo Recomendación
    trips.trip_id Modelar el viaje completo de ida y vuelta para el bucle con un solo viaje.
    stop_times.stop_id Incluya la primera/última parada dos veces en stop_times.txt para el viaje que es un bucle. Ejemplo de ello. A menudo, una ruta en bucle puede incluir primeros y últimos viajes que no recorren el bucle completo. Incluya también estos viajes.
    trip_idstop_idstop_sequence
    90001011
    90001022
    90001033
    90001014
    trips.direction_id Si el bucle funciona en direcciones opuestas (es decir, en el sentido de las agujas del reloj y en sentido contrario), designe direction_id como 0 o 1.
    trips.block_id Indique los viajes de bucle continuo con el mismo block_id.

    Rutas de lazo

    Las rutas Lasso combinan aspectos de una ruta de bucle y de una ruta direccional.

    Ejemplos:
    Rutas de metro (Chicago)
    Rutas del suburbano al centro de la ciudad (St. Albert o Edmonton)
    Línea marrón de la CTA (Sitio web de la CTA y TransitFeeds)
    Nombre del campo Recomendación
    trips.trip_id La extensión completa de un "viaje de ida y vuelta en vehículo" (véase la ilustración arriba) consiste en el viaje de A a B a B y de vuelta a A. Un viaje de ida y vuelta completo del vehículo puede ser expresado por:
  • A único trip_id valor/registro en trips.txt
  • Múltiples trip_id valores/registros en trips.txt, con un viaje continuo indicado por block_id.
    		•
    stop_times.stop_headsign Las paradas a lo largo del tramo A-B serán recorridas en ambas direcciones. stop_headsign facilita la distinción del sentido de la marcha. Por lo tanto, se recomienda proporcionar stop_headsign se recomienda para estos viajes.ejemplo_tabla:
    Ejemplos:
    "A vía B"
    "A"
    Chicago Transit Authority's Línea Púrpura
    "Dirección sur hacia el Bucle"
    "En dirección norte vía Loop"
    "En dirección norte hacia Linden"
    Líneas de autobús del Servicio de Tránsito de Edmonton, aquí el 39
    "Rutherford"
    "Century Park"
    trip.trip_headsign La cabecera del viaje debe ser una descripción global del viaje, como la que se muestra en los horarios. Podría ser "Linden a Linden vía Loop" (ejemplo de Chicago), o "A a A vía B" (ejemplo genérico).

    Bifurcaciones

    Algunas rutas pueden incluir ramificaciones. La alineación y las paradas se comparten entre estas ramas, pero cada una de ellas también sirve a paradas y secciones de alineación distintas. La relación entre los ramales puede indicarse mediante el nombre de la ruta, las señales de cabecera y el nombre abreviado del viaje, utilizando las siguientes directrices.

    Nombre del campo Recomendación
    Todos los campos Al nombrar los ramales, se recomienda seguir otros materiales de información al pasajero. A continuación se describen y ejemplifican dos casos:
    Si los horarios y la señalización en la calle representan dos rutas con nombres distintos (por ejemplo, 1A y 1B), preséntelo como tal en el GTFS, utilizando los campos route_short_name y/o route_long_name campos. Ejemplo: GoDurham Transit las rutas 2, 2A y 2B comparten una alineación común a lo largo de la mayor parte del recorrido, pero varían en varios aspectos diferentes.
    • La ruta 2 es el servicio principal, que funciona la mayoría de las horas.
    • La ruta 2 incluye un desvío en las noches de Main Street, los domingos y los días festivos.
    • Las rutas 2A y 2B funcionan en horario diurno de lunes a sábado.
    • La ruta 2B sirve paradas adicionales en una desviación de la ruta de alineación compartida.
    Si la información proporcionada por la agencia describe los ramales como la misma ruta con nombre, utilice los trips.trip_headsign, stop_times.stop_headsigny/o trips.trip_short_name campos. Ejemplo: GoTriangle ruta 300 viaja a diferentes lugares dependiendo de la hora del día. Durante las horas punta se añaden tramos adicionales a la ruta estándar para acomodar a los trabajadores que entran y salen de la ciudad.

    Preguntas frecuentes (FAQ)

    ¿Por qué son importantes estas Buenas Prácticas GTFS GTFS?

    Los objetivos de las Buenas Prácticas del GTFS son

    • Mejorar la experiencia del usuario final en las aplicaciones de transporte público
    • Apoyar una amplia interoperabilidad de datos para facilitar a los desarrolladores de software el despliegue y la ampliació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 unas Buenas Prácticas de GTFS coordinadas, varias aplicaciones GTFSFS pueden establecer requisitos y expectativas de forma descoordinada, lo que conduce a requisitos divergentes y conjuntos de datos específicos de la aplicación y a una menor interoperabilidad. Antes de la publicación de las Buenas Prácticas, existía una mayor ambigüedad y desacuerdo en lo que constituye un dato GTFS correctamente formado.

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

    Estas mejores prácticas fueron desarrolladas por un grupo de trabajo de 17 organizaciones involucradas en GTFSFS, incluyendo proveedores de aplicaciones y consumidores de datos, proveedores de transporte y consultores con amplia participación en GTFS. El grupo de trabajo fue convocado y facilitado por el Rocky Mountain Institute.

    Los miembros del Grupo de Trabajo votaron cada una de las Buenas Prácticas. La mayoría de las Buenas Prácticas fueron aprobadas por unanimidad. En una minoría de casos, las Buenas Prácticas fueron aprobadas por una gran mayoría de organizaciones.

    ¿Por qué no cambiar simplemente la referencia GTFS?

    ¡Buena pregunta! El proceso de examen de la Especificación, el uso de los datos y las necesidades ha dado lugar a algunos cambios en la Especificación (véanse las solicitudes de extracción cerradas en GitHub). Las modificaciones de las referencias de la Especificación están sujetas a un mayor nivel de escrutinio y comentarios que las Mejores Prácticas. Sin embargo, sigue siendo necesario acordar un conjunto claro de recomendaciones de buenas prácticas.

    El grupo de trabajo prevé que algunas Buenas Prácticas GTFS acabarán formando parte del núcleo de la referencia GTFS.

    ¿Las herramientas de validación de GTFS comprueban la conformidad con estas prácticas recomendadas?

    Actualmente, ninguna herramienta de validación verifica el cumplimiento de todas las mejores prácticas. Varias herramientas de validación verifican el cumplimiento de algunas de estas mejores prácticas. Para obtener una lista de herramientas de validación GTFS, consulte GTFS Validators. Si escribe una herramienta de validación GTFS que haga referencia a estas mejores prácticas, envíe un correo electrónico a specifications@mobilitydata.org.

    Represento a una agencia de transporte. ¿Qué medidas puedo tomar para que nuestros proveedores de servicios de software y vendedores sigan estas Mejores Prácticas?

    Remita a su proveedor de servicios de software a estas Buenas Prácticas. Recomendamos hacer referencia a la URL de las mejores prácticas GTFS, así como a la referencia de las especificaciones básicas en la adquisición de software GTFS.

    ¿Qué debo hacer si observo que una fuente de datos GTFS no se ajusta a estas Mejores Prácticas?

    Identifique el contacto para el feed, utilizando los campos feed_contact_email o feed_contact_url propuestos en feed_info.txt si existen, o buscando la información de contacto en el sitio web de la agencia de tránsito o del productor del feed. Cuando comunique el problema al productor de piensos, enlace a la Buena Práctica GTFS específica que se esté discutiendo. (Véase "Enlace a este documento").

    Me gustaría proponer una modificación/adición a las Mejores Prácticas. ¿Cómo puedo hacerlo?

    Envíe un correo electrónico a specifications@mobilitydata.org o abra una incidencia o solicitud de extracción en el repositorio de mejores prácticas de GitHub GTFS.

    ¿Cómo puedo participar?

    Envíe un correo electrónico a specifications@mobilitydata.org.

    Acerca de este documento

    Objetivos

    Los objetivos del mantenimiento de las Buenas Prácticas GTFS son

    • Apoyar una mayor interoperabilidad de los datos de tránsito
    • Mejorar la experiencia del usuario final en las aplicaciones de transporte público
    • Facilitar a los desarrolladores de software el despliegue y la ampliació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 modificar las Buenas Prácticas GTFS publicadas

    Las aplicaciones y prácticas de GTFS evolucionan, por lo que es posible que este documento deba modificarse de vez en cuando. Para proponer una enmienda a este documento, abra una solicitud de extracción en el repositorio GitHub de mejores prácticas de GTFS y abogue por el cambio. También puede enviar cualquier comentario por correo electrónico a specifications@mobilitydata.org.

    Enlaces a este documento

    Por favor, enlace aquí para proporcionar a los productores de alimentación una guía para la correcta formación de los datos GTFS. Cada recomendación individual tiene un enlace de anclaje. Haga clic en la recomendación para obtener la URL del enlace de anclaje en la página.

    Si una aplicación GTFSFS hace requisitos o recomendaciones para las prácticas de datos GTFS que no se describen aquí, se recomienda publicar un documento con esos requisitos o recomendaciones para complementar estas mejores prácticas comunes.

    Grupo de Trabajo de Mejores PrácticasGTFS

    El Grupo de Trabajo de Mejores Prácticas de GTFS fue convocado por el Rocky Mountain Institute en 2016-17, formado por proveedores de transporte público, desarrolladores de aplicaciones GTFS, consultores y organizaciones académicas para definir prácticas y expectativas comunes para los datos de GTFS.Los miembros de este grupo de trabajo fueron:

    Actualmente, este documento es mantenido por MobilityData.