Saltar a contenido

Referencia de GTFS Realtime

Un feed GTFS Realtime permite a las agencias de transporte proporcionar a los consumidores información en tiempo real sobre las interrupciones de su servicio (estaciones cerradas, líneas no operativas, retrasos importantes, etc.) la ubicación de sus vehículos y las horas de arrival previstas.

La versión 2.0 de la especificación de los piensos se discute y documenta en este sitio. Las versiones válidas son "2.0", "1.0".

Término Definiciones

Requerido

En GTFS v2.0 y superiores, la columna Required describe qué campos debe proporcionar un productor para que los datos de tránsito sean válidos y tengan sentido para una aplicación consumidora.

En el campo Required se utilizan los siguientes valores:

  • Obligatorio: Este campo debe ser proporcionado por un productor de feeds GTFS.
  • Requeridocondicionalmente: Este campo es necesario en determinadas condiciones, que se indican en la descripción del campo. Fuera de estas condiciones, el campo es opcional.
  • Opcional: Este campo es opcional y no es necesario que lo implementen los productores. Sin embargo, si los datos están disponibles en los sistemas de localización automática de vehicle subyacentes (por ejemplo, VehiclePosition timestamp) se recomienda que los productores proporcionen estos campos opcionales cuando sea posible.

Tenga en cuenta que los requisitos semánticos no se definieron en la versión 1.0 GTFS, por lo que los feeds con gtfs_realtime_version de 1 pueden no cumplir estos requisitos (véase la propuesta de requisitos semánticos para más detalles).

Cardinalidad

La cardinalidad representa el número de elementos que se pueden proporcionar para un campo concreto, con los siguientes valores:

Consulte siempre los campos Obligatorio y Descripción para ver si un campo es obligatorio, condicionalmente obligatorio u opcional. Consulte GTFS-realtime/proto/GTFS-realtime.proto">GTFS.proto para conocer la cardinalidad del búfer de protocolo.

Tipos de datos del búfer de protocolo

Los siguientes tipos de datos del buffer de protocolo se utilizan para describir los elementos de alimentación:

  • message: Tipo complejo
  • enum: Lista de valores fijos

Campos experimentales

Los campos etiquetados como experimentales están sujetos a cambios y aún no han sido adoptados formalmente en la especificación. Un campo experimental puede ser adoptado formalmente en el futuro.

Índice de elementos

Elementos

message FeedMessage

El contenido de un mensaje message alimentación. Cada message del feed se obtiene como respuesta a una petición HTTP GET apropiada. Un feed en tiempo real se define siempre en relación con un feed GTFS existente. Todos los identificadores de entity se resuelven con respecto al feed GTFS.

Campos

Nombre del campo Tipo Requerido Cardinalidad Descripción
header FeedHeader Exigida Uno Metadatos sobre este feed y su message.
entity FeedEntity Condicionalmente obligatorio Muchos Contenido del feed. Si hay información en tiempo real disponible para el sistema de tránsito, este campo debe ser proporcionado. Si este campo está EMPTY, los consumidores deben asumir que no hay información en tiempo real disponible para el sistema.

message FeedHeader

Metadatos sobre un feed, incluidos en los mensajes del feed.

Campos

Nombre del campo Tipo Exigida Cardinalidad Descripción
gtfs_realtime_version string Exigida Uno Versión de la especificación del feed. La versión actual es la 2.0.
Incrementality Incrementality Exigida Uno
timestamp uint64 Exigida Uno Esta timestamp identifica el momento en que se ha creado el contenido de este feed (en tiempo time servidor). En time POSIX (es decir, número de segundos desde el 1 de enero de 1970 00:00:00 UTC). Para evitar la desviación de time entre los sistemas que producen y consumen información en tiempo real, se recomienda encarecidamente obtener timestamp de un servidor de time. Es completamente aceptable utilizar servidores de estrato 3 o incluso de estratos inferiores, ya que las diferencias de time de hasta un par de segundos son tolerables.

enum Incrementality

Determina si la obtención actual es incremental.

  • FULL_DATASET: esta actualización del feed sobrescribirá toda la información en tiempo real precedente para el feed. Por lo tanto, se espera que esta actualización proporcione una instantánea FULL de toda la información en tiempo real conocida.
  • DIFFERENTIAL: actualmente, este modo no está soportado y el comportamiento no está especificado para las alimentaciones que utilizan este modo. Hay discusiones en la GTFS-realtime">lista de correo de GTFS-realtime">GTFS Realtime Realtime en torno a la especificación completa del comportamiento del modo DIFFERENTIAL y la documentación se actualizará cuando esas discusiones estén finalizadas.

Valores

Valor
FULL_DATASET
DIFFERENTIAL

message FeedEntity

Definición (o actualización) de una entity en el feed de tránsito. Si la entity no se está eliminando, debe rellenarse exactamente uno de los campostrip_update',vehicle,Alert' yShape'.

Campos

Nombre del campo Tipo Exigida Cardinalidad Descripción
id string Exigida Uno Identificador único para esta entity. Los ids se utilizan sólo para proporcionar soporte Incrementality. Las entidades reales referenciadas por el feed deben ser especificadas por selectores explícitos (ver EntitySelector más abajo para más INFO).
is_deleted bool Opcional Uno Si esta entity debe ser eliminada. Sólo debe proporcionarse para los feeds con Incrementality de DIFFERENTIAL - este campo NO debe proporcionarse para los feeds con Incrementality de FULL_DATASET.
trip_update TripUpdate Requerido condicionalmente Uno Datos sobre los retrasos de departure en tiempo real de un trip. Debe proporcionarse al menos uno de los campos trip_update, vehicle, Alert, o Shape - todos estos campos no pueden estar EMPTY.
vehicle VehiclePosition Requerido condicionalmente Uno Datos sobre la Position en tiempo real de un vehicle. Debe proporcionarse al menos uno de los campos trip_update, vehicle, Alert, o Shape - todos estos campos no pueden estar EMPTY.
Alert Alert Requerido condicionalmente Uno Datos sobre la Alert en tiempo real. Debe proporcionarse al menos uno de los campos trip_update, vehicle, Alert, o Shape - todos estos campos no pueden estar EMPTY.
Shape Shape Requerido condicionalmente Uno Datos sobre las formas ADDED en tiempo real, como por ejemplo para un DETOUR. Se debe proporcionar al menos uno de los campos trip_update, vehicle, Alert, o Shape - todos estos campos no pueden estar EMPTY.

Precaución: este campo sigue siendo experimentaly está sujeto a cambios. Es posible que se adopte formalmente en el futuro.

message TripUpdate

Actualización en tiempo real del progreso de un vehicle a lo largo de un trip. Por favor, consulte también la discusión general de las trip-updates">entidades de actualización de trip-updates">trip trip-updates">trip.

Dependiendo del valor de ScheduleRelationship, un TripUpdate puede especificar

  • Un trip que procede a lo largo del horario.
  • Un trip que procede a lo largo de una ruta pero que no tiene un horario fijo.
  • Un trip que ha sido ADDED o eliminado con respecto al horario.
  • Un nuevo trip que es una copia de un trip existente en GTFS estático. Se ejecutará en la fecha y time servicio especificada en TripProperties.

Las actualizaciones pueden ser para eventos futuros, previstos de arrival, o para eventos pasados que ya ocurrieron. En la mayoría de los casos, la información sobre eventos pasados es un valor medido, por lo que se recomienda que su valor de uncertainty sea 0. Aunque puede haber casos en los que esto no se cumpla, por lo que se permite tener un valor de uncertainty diferente de 0 para los eventos pasados. Si la uncertainty de una actualización no es 0, o bien la actualización es una predicción aproximada para un trip que no se ha completado o la medición no es precisa o la actualización era una predicción para el pasado que no ha sido verificada después de que el evento ocurriera.

Si un vehicle está sirviendo a varios viajes dentro del mismo bloque (para más información sobre viajes y bloques, consulte GTFS trips.txt):

  • el feed debe incluir un TripUpdate para el trip que está siendo servido por el vehicle. Se anima a los productores a incluir TripUpdates para uno o más viajes después del trip actual en el bloque de este vehicle si el productor confía en la calidad de las predicciones para estos trip futuros. La inclusión de múltiples TripUpdates para el mismo vehicle evita la aparición de predicciones para los pasajeros cuando el vehicle pasa de un trip a otro y también ofrece a los pasajeros un aviso anticipado de los retrasos que afectan a los viajes posteriores (por ejemplo, cuando el delay conocido supera los tiempos de escala previstos entre los viajes).
  • no se requiere que las entidades TripUpdate respectivas sean ADDED a la alimentación en el mismo orden en que están SCHEDULED en el bloque. Por ejemplo, si hay viajes con trip_ids 1, 2 y 3 que pertenecen todos a un bloque, y el vehicle realiza el trip 1, luego trip 2 y luego el trip 3, las entidades trip_update pueden aparecer en cualquier orden - por ejemplo, se permite agregar el trip 2, luego el trip 1 y luego trip 3.

Tenga en cuenta que la actualización puede describir un trip que ya ha finalizado. Para end, basta con proporcionar una actualización para la última parada del trip. Si la time de arrival a la última parada es pasada, el cliente concluirá que todo el trip es pasado (es posible, aunque sin consecuencias, proporcionar también actualizaciones para las paradas anteriores). Esta opción es más relevante para un trip que ha finalizado antes de lo previsto, pero según el horario, el trip sigue en curso en el time actual. Si se eliminan las actualizaciones de este trip, el cliente podría suponer que el trip sigue en curso. Tenga en cuenta que el proveedor de alimentación puede, pero no está obligado, a purgar las actualizaciones pasadas - este es un caso en el que esto sería prácticamente útil.

Campos

Nombre del campo Tipo Exigida Cardinalidad Descripción
trip TripDescriptor Exigida Uno El trip al que se aplica este message. Puede haber como máximo una entity TripUpdate por cada instancia de trip real. Si no hay ninguna, significa que no hay información de predicción disponible. Esto significa no significa que el trip está progresando según lo previsto.
vehicle VehicleDescriptor Opcional Uno Información adicional sobre el vehicle que está sirviendo este trip.
stop_time_update StopTimeUpdate Condicionado Muchos Actualizaciones de los StopTimes del trip (tanto las futuras, es decir, las predicciones, como en algunos casos, las pasadas, es decir, las que ya han ocurrido). Las actualizaciones deben estar ordenadas por stop_sequence, y se aplican a todas las paradas siguientes del trip hasta la siguiente stop_time_update especificada. Debe proporcionarse al menos una actualización stop_time_update hora de parada para el trip, a menos que laschedule_relationship sea CANCELED o DUPLICATED - si el trip está CANCELED, no es necesario proporcionar actualizaciones de hora de parada. Si el trip es DUPLICATED, puede proporcionarse stop_time_updates para indicar información en tiempo real para el nuevo trip.
timestamp uint64 Opcional Uno El momento más reciente en el que se midió el progreso en tiempo real del vehicle para estimar los StopTimes en el futuro. Cuando se proporcionan StopTimes en el pasado, las horas de arrival pueden ser anteriores a este valor. En time POSIX (es decir, el número de segundos desde el 1 de enero de 1970 00:00:00 UTC).
delay int32 Opcional Uno La desviación del horario actual para el trip. delay retraso sólo debe especificarse cuando la predicción se da en relación con algún horario existente en GTFS.
Eldelay (en segundos) puede ser positivo (lo que significa que el vehicle está retrasado) o negativo (lo que significa que el vehicle está adelantado). un delay de 0 significa que el vehicle está exactamente time.
La información dedelay en StopTimeUpdates tiene prioridad sobre la información de delay trip de viaje, de manera que el delay trip sólo se propaga hasta la siguiente parada a lo largo del trip con un valor de delay StopTimeUpdate especificado.
Se recomienda encarecidamente a los proveedores de información que proporcionen un valor detimestamp TripUpdate. que indique cuándo se actualizó por última vez el valor de delay, con el fin de evaluar la frescura de los datos.

Precaución: este campo sigue siendo experimentaly está sujeto a cambios. Es posible que se adopte formalmente en el futuro.
trip_properties TripProperties Opcional Uno Proporciona las propiedades actualizadas del trip.

Precaución: este message sigue siendo experimentaly está sujeto a cambios. Puede adoptarse formalmente en el futuro.

message StopTimeEvent

Información de tiempo para un único evento previsto (ya sea de arrival o de departure). El tiempo consiste en el delay y/o el time estimado, y uncertainty.

  • Eldelay debe usarse cuando la predicción se da en relación con algún horario existente en GTFS.
  • Eltime debe indicarse tanto si hay un horario previsto como si no. Si se especifican tanto el time como delay retraso, time tendrá prioridad (aunque normalmente, el time, si se da para un trip SCHEDULED, debería ser igual al time SCHEDULED en GTFS + delay).

Launcertainty se aplica igualmente al time y al delay. La uncertainty especifica aproximadamente el error esperado en el delay real (pero tenga en cuenta que aún no definimos su significado estadístico preciso). Es posible que la uncertainty sea 0, por ejemplo para los trenes que se conducen bajo control de tiempo por ordenador.

Campos

Nombre del campo Tipo Exigida Cardinalidad Descripción
delay int32 Condicionado Uno Eldelay (en segundos) puede ser positivo (lo que significa que el vehicle está retrasado) o negativo (lo que significa que el vehicle está adelantado). un delay de 0 significa que el vehicle está exactamente time. Tanto el delay como la time deben indicarse dentro de un StopTimeEvent - ambos campos no pueden estar EMPTY.
time int64 Condicionado Uno Evento como time absoluto. En time POSIX (es decir, número de segundos desde el 1 de enero de 1970 00:00:00 UTC). En un StopTimeEvent debe proporcionarse el delay o la time - ambos campos no pueden estar EMPTY.
uncertainty int32 Opcional Uno Si se omite la uncertainty, se interpreta como desconocida. Para especificar una predicción completamente segura, establezca su uncertainty en 0.

message StopTimeUpdate

Actualización en tiempo real de los eventos de arrival y/o departure de una parada determinada en un trip. Consulte también la discusión general sobre las actualizaciones de la time de la parada en la documentación de trip-updates">las entidades message-tripdescriptor">TripDescriptor y trip-updates">trip Updates.

Las actualizaciones pueden ser suministradas tanto para eventos pasados como futuros. El productor puede, aunque no es obligatorio, eliminar los eventos pasados.

La actualización está vinculada a una parada específica a través de stop_sequence o stop_id, por lo que uno de estos campos debe estar necesariamente establecido. Si el mismo stop_id es visitado más de una vez en un trip, entonces stop_sequence debe ser proporcionado en todos los StopTimeUpdates para ese stop_id en ese trip.

Campos

Nombre del campo Tipo Exigida Cardinalidad Descripción
stop_sequence uint32 Condicionado Uno Debe ser el mismo que en stop_times.txt en el feed GTFS correspondiente. Se debe proporcionar stop_sequence o stop_id dentro de un StopTimeUpdate - ambos campos no pueden ser EMPTY. stop_sequence es necesario para los viajes que visitan el mismo stop_id más de una vez (por ejemplo, un bucle) para desambiguar para qué parada es la predicción. Si StopTimeProperties.assigned_stop_id está rellenado, entonces stop_sequence debe estar rellenado.
stop_id string Condicionado Uno Debe ser el mismo que en stops.txt en el feed GTFS correspondiente. La stop_sequence o el stop_id deben ser proporcionados dentro de un StopTimeUpdate - ambos campos no pueden estar EMPTY. Si StopTimeProperties.assigned_stop_id se rellena, es preferible omitir stop_id y utilizar sólo stop_sequence. Si StopTimeProperties.assigned_stop_id y stop_id se rellenan, stop_id debe coincidir con assigned_stop_id.
arrival StopTimeEvent Condicionado Uno Si schedule_relationship es EMPTY o SCHEDULED, debe proporcionarse la arrival o la departure dentro de un StopTimeUpdate - ambos campos no pueden estar EMPTY. arrival y departure pueden estar EMPTY cuando schedule_relationship es SKIPPED. Si schedule_relationship es NO_DATA, la arrival y la departure deben estar EMPTY.
departure StopTimeEvent Condicionado Uno Si schedule_relationship es EMPTY o SCHEDULED, la arrival o la departure debe proporcionarse dentro de un StopTimeUpdate - ambos campos no pueden estar EMPTY. arrival y departure pueden estar EMPTY cuando schedule_relationship es SKIPPED. Si schedule_relationship es NO_DATA, la arrival y la departure deben estar EMPTY.
departure_occupancy_status OccupancyStatus Opcional Uno Estado previsto de la ocupación de los pasajeros del vehicle inmediatamente después de departure salida de la parada indicada. Si se proporciona, debe indicarse stop_sequence. Para proporcionar departure_occupancy_status sin proporcionar ninguna predicción de arrival o departure en tiempo real, rellene este campo y establezca StopTimeUpdate.schedule_relationship = NO_DATA.

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Puede adoptarse formalmente en el futuro.
schedule_relationship ScheduleRelationship Opcional Uno La relación por defecto es SCHEDULED.
stop_time_properties StopTimeProperties Opcional Uno Actualizaciones en tiempo real para ciertas propiedades definidas en GTFS stop_times.txt

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Puede adoptarse formalmente en el futuro.

enum ScheduleRelationship

La relación entre este StopTime y el horario estático.

Valores

Valor Comentario
SCHEDULED El vehicle está procediendo de acuerdo con su horario estático de paradas, aunque no necesariamente de acuerdo con los tiempos del horario. Este es el por defecto comportamiento. Debe proporcionarse al menos uno de arrival y otro de departure. Los viajes basados en la frecuenciaGTFS frequencies.txt con exact_times = 0) no deben tener un valor SCHEDULED y deben utilizar UNSCHEDULED en su lugar.
SKIPPED La parada se SKIPPED, es decir, el vehicle no se detendrá en esta parada. la arrival y la departure son opcionales. Cuando se establece SKIPPED no se propaga a las paradas subsiguientes del mismo trip (es decir, el vehicle se detendrá en las paradas subsiguientes del trip a menos que esas paradas también tengan un stop_time_update con schedule_relationship: SKIPPED). delay de una parada anterior en el trip hace se propaga sobre la SKIPPED parada. En otras palabras, si un stop_time_update con una arrival o departure predicción no se establece para una parada posterior a la SKIPPED parada, la predicción anterior a la SKIPPED se propagará a la parada posterior a la SKIPPED y a las paradas posteriores del trip hasta que se proporcione un stop_time_update para una parada posterior.
NO_DATA No se dan datos para esta parada. Indica que no hay información de tiempo real disponible. Cuando se establece NO_DATA se propaga a través de las paradas subsiguientes, por lo que es la forma recomendada de especificar a partir de qué parada no se dispone de información de cronometraje en tiempo real. Cuando se establece NO_DATA no se debe suministrar ni la arrival ni la departure.
UNSCHEDULED El vehicle está realizando un trip basado en la frecuenciaGTFS frequencies.txt con exact_times = 0). Este valor no debe utilizarse para viajes que no estén definidos en GTFS frequencies. frequencies.txt, o viajes en GTFS frequencies.txt.txt con exact_times = 1. Los viajes que contienen stop_time_updates con schedule_relationship: UNSCHEDULED también deben establecer el TripDescriptor schedule_relationship: UNSCHEDULED

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Puede adoptarse formalmente en el futuro.

message StopTimeProperties

Actualización en tiempo real de ciertas propiedades definidas en GTFS stop_times.txttxt.

Atención: este message es todavía experimental y está sujeto a cambios. Es posible que se adopte formalmente en el futuro.

Campos

Nombre del campo Tipo Exigida Cardinalidad Descripción
assigned_stop_id string Opcional Uno Admite la asignación de paradas en tiempo real. Se refiere a un stop_id definido en el GTFS stops.txt.
El nuevo assigned_stop_id no debe dar lugar a una experiencia de trip significativamente diferente para el usuario end que el stop_id definidos en GTFS stop_times.txt. En otras palabras, el usuario end no debería ver esta nueva stop_id como un "cambio inusual" si la nueva parada se presentó dentro de una aplicación sin ningún contexto adicional. Por ejemplo, este campo está destinado a ser utilizado para la asignación de plataformas utilizando una stop_id que pertenece a la misma estación que la parada originalmente definida en GTFS GTFS stop_times.txt.
Para asignar una parada sin proporcionar ninguna predicción de arrival o departure en tiempo real, rellene este campo y establezca StopTimeUpdate.schedule_relationship = NO_DATA.
Si este campo está poblado StopTimeUpdate.stop_sequence debe ser rellenado y StopTimeUpdate.stop_id no debe poblarse. Las asignaciones de paradas deben reflejarse también en otros campos GTFS GTFS (p. ej, VehiclePosition.stop_id).

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Puede adoptarse formalmente en el futuro.

message TripProperties

Define las propiedades actualizadas del trip

Atención: este message es todavía experimental y está sujeto a cambios. Es posible que se adopte formalmente en el futuro.
.

Campos

Nombre del campo Tipo Exigida Cardinalidad Descripción
trip_id string Condicionado Uno Define el identificador de un nuevo trip que es un duplicado de un trip existente definido en (CSV) GTFS trips.txt pero que start en una fecha y/o time servicio diferente (definida mediante TripProperties.start_date y TripProperties.start_time). Véase la definición de trips.trip_id en (CSV) GTFS. Su valor debe ser diferente de los utilizados en el (CSV) GTFS. Este campo es necesario si schedule_relationship es DUPLICATEDEn caso contrario, este campo no debe rellenarse y será ignorado por los consumidores.

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Puede adoptarse formalmente en el futuro.
start_date string Condicionado Uno Fecha de servicio en la que se realizará el trip DUPLICATED. Debe proporcionarse en formato AAAAMMDD. Este campo es necesario si schedule_relationship es DUPLICATEDEn caso contrario, este campo no debe rellenarse y será ignorado por los consumidores.

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Puede adoptarse formalmente en el futuro.
start_time string Requerido condicionalmente Uno Define la time de start del trip cuando es DUPLICATED. Véase la definición de stop_times.departure_time en (CSV) GTFS. Las horas de arrival y departure SCHEDULED para el trip DUPLICATED se calculan en base al desfase entre el trip original departure_time y este campo. Por ejemplo, si un trip GTFS tiene la parada A con un departure_time de 10:00:00 y la parada B con departure_time de 10:01:00y este campo se rellena con el valor de 10:30:00la parada B del trip DUPLICATED tendrá un valor SCHEDULED departure_time de 10:31:00. Predicción en tiempo real delay se aplican a este time calculado para determinar la time prevista. Por ejemplo, si se proporciona una departure delay de 30 para la parada B, la hora time departure prevista es 10:31:30. Los valores de predicción en tiempo real time Los valores de predicción en tiempo real no tienen ningún desplazamiento aplicado e indican la time prevista tal y como se ha proporcionado. Por ejemplo, si se proporciona una departure time que representa las 10:31:30 para la parada B, la time de departure prevista es 10:31:30Este campo es necesario si schedule_relationship es DUPLICATEDEn caso contrario, este campo no debe rellenarse y será ignorado por los consumidores.

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Puede adoptarse formalmente en el futuro.
shape_id string Opcional Uno Especifica la Shape de la trayectoria del vehicle para este trip cuando difiere de la original. Se refiere a una Shape definida en el GTFS (CSV) o a una nueva entity Shape en una alimentación en tiempo real. Véase la definición del trips.shape_id en (CSV) GTFS.

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Puede adoptarse formalmente en el futuro.

message VehiclePosition

Información de posicionamiento en tiempo real para un vehicle determinado.

Campos

Nombre del campo Tipo Exigida Cardinalidad Descripción
trip TripDescriptor Opcional Uno El trip que este vehicle está sirviendo. Puede ser EMPTY o parcial si el vehicle no puede identificarse con una instancia de trip determinada.
vehicle VehicleDescriptor Opcional Uno Información adicional sobre el vehicle que está sirviendo este trip. Cada entrada debe tener un único id vehicle.
Position Position Opcional Uno Position actual de este vehicle.
current_stop_sequence uint32 Opcional Uno El índice de la secuencia de paradas de la parada actual. El significado de current_stop_sequence (es decir, la parada a la que se refiere) viene determinado por current_status. Si falta current_status se asume IN_TRANSIT_TO.
stop_id string Opcional Uno Identifica la parada actual. El valor debe ser el mismo que en stops.txt en el feed GTFS correspondiente. Si StopTimeProperties.assigned_stop_id se utiliza para asignar un stop_id, este campo también debe reflejar el cambio en stop_id.
current_status VehicleStopStatus Opcional Uno El estado exacto del vehicle con respecto a la parada actual. Se ignora si falta current_stop_sequence.
timestamp uint64 Opcional Uno Momento en el que se midió la Position del vehicle. En time POSIX (es decir, número de segundos desde el 1 de enero de 1970 00:00:00 UTC).
congestion_level CongestionLevel Opcional Uno
occupancy_status OccupancyStatus Opcional Uno El estado de ocupación de los pasajeros del vehicle o del vagón. Si multi_carriage_details se rellena con el estado de OccupancyStatus por vagón, este campo debe describir todo el vehicle teniendo en cuenta todos los vagones que aceptan pasajeros.

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Puede adoptarse formalmente en el futuro.
occupancy_percentage uint32 Opcional Uno Valor porcentual que indica el grado de ocupación de los pasajeros en el vehicle. El valor 100 debe representar la ocupación máxima total para la que se diseñó el vehicle, incluida la capacidad de asientos y de pie, y que permiten las normas de explotación vigentes. El valor puede ser superior a 100 si hay más pasajeros que la capacidad máxima diseñada. La precisión de occupancy_percentage debe ser lo suficientemente baja como para que no se pueda hacer un seguimiento de los pasajeros que suben o bajan del vehicle. Si multi_carriage_details se rellena con occupancy_percentage por vagón, este campo debe describir todo el vehicle teniendo en cuenta todos los vagones que aceptan pasajeros.

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Puede adoptarse formalmente en el futuro.
multi_carriage_details CarriageDetails Opcional Muchos Detalles de los vagones múltiples de este vehicle dado. La primera aparición representa el primer vagón del vehicle, teniendo en cuenta el sentido actual de la marcha. El número de apariciones del campo multi_carriage_details representa el número de vagones del vehicle. También incluye los vagones no embarcables, como los motores, los vagones de MAINTENANCE, etc., ya que proporcionan información valiosa a los pasajeros sobre dónde situarse en un andén.

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Puede adoptarse formalmente en el futuro.

enum VehicleStopStatus

Valores

Valor Comentario
INCOMING_AT El vehicle está a punto de llegar a la parada (en una pantalla de parada, el símbolo vehicle suele parpadear).
STOPPED_AT El vehicle está parado en la parada.
IN_TRANSIT_TO El vehicle ha salido de la parada anterior y está en tránsito.

enum CongestionLevel

Nivel deCONGESTION que está afectando a este vehicle.

Valores

Valor
UNKNOWN_CONGESTION_LEVEL
RUNNING_SMOOTHLY
STOP_AND_GO
CONGESTION
SEVERE_CONGESTION

enum OccupancyStatus

El estado de ocupación de los pasajeros para el vehicle o el vagón.

Los productores individuales pueden no publicar todos los valores de OccupancyStatus. Por lo tanto, los consumidores no deben asumir que los valores de OccupancyStatus siguen una escala lineal. Los consumidores deben representar los valores de OccupancyStatus como el estado indicado y previsto por el productor. Del mismo modo, los productores deben utilizar los valores de OccupancyStatus que correspondan a los estados reales de ocupación del vehicle.

Para describir los niveles de ocupación de los pasajeros en una escala lineal, véase occupancy_percentage.

Atención: este campo es todavía experimental y está sujeto a cambios. Es posible que se adopte formalmente en el futuro.

Valores

Valor Comentario
EMPTY El vehicle se considera EMPTY según la mayoría de las medidas, y tiene pocos o ningún pasajero a bordo, pero sigue aceptando pasajeros.
MANY_SEATS_AVAILABLE El vehicle o vagón tiene un gran número de asientos disponibles. La cantidad de asientos libres del total de asientos disponibles para que se considere lo suficientemente grande como para entrar en esta categoría se determina a discreción del productor.
FEW_SEATS_AVAILABLE El vehicle o vagón tiene un número reducido de asientos disponibles. La cantidad de asientos libres del total de asientos disponibles para ser considerados lo suficientemente pequeños como para caer en esta categoría se determina a discreción del productor.
STANDING_ROOM_ONLY El vehicle o vagón sólo puede acoger actualmente a pasajeros de pie.
CRUSHED_STANDING_ROOM_ONLY El vehicle o vagón sólo puede acomodar actualmente a pasajeros de pie y tiene un espacio limitado para ellos.
FULL El vehicle se considera FULL según la mayoría de las medidas, pero puede seguir permitiendo el embarque de pasajeros.
NOT_ACCEPTING_PASSENGERS El vehicle o vagón no acepta pasajeros. El vehicle o vagón suele aceptar pasajeros para embarcar.
NO_DATA_AVAILABLE El vehicle o vagón no tiene datos de ocupación disponibles en ese time.
NOT_BOARDABLE El vehicle o vagón no es embarcable y nunca acepta pasajeros. Útil para vehículos o vagones especiales (motor, vagón de MAINTENANCE, etc...).

message CarriageDetails

Detalles específicos del vagón, utilizados para los vehículos compuestos por varios vagones.

Precaución: este message es todavía experimental y está sujeto a cambios. Es posible que se adopte formalmente en el futuro.

Campos

Nombre del campo Tipo Exigida Cardinalidad Descripción
id string Opcional Uno Identificación del vagón. Debe ser única por vehicle.

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Puede adoptarse formalmente en el futuro.
label string Opcional Uno label visible para el usuario que puede mostrarse al pasajero para ayudar a identificar el transporte. Ejemplo: "7712", "Vagón ABC-32", etc.
Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Puede adoptarse formalmente en el futuro.
occupancy_status OccupancyStatus Opcional Uno Estado de ocupación de este vagón, en este vehicle. El valor por defecto es NO_DATA_AVAILABLE.

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Puede adoptarse formalmente en el futuro.
occupancy_percentage int32 Opcional Uno Porcentaje de ocupación para este vagón determinado, en este vehicle. Sigue las mismas reglas que "VehiclePosition.occupancy_percentage". Utilice -1 en caso de que no haya datos disponibles para este vagón determinado.

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Puede adoptarse formalmente en el futuro.
carriage_sequence uint32 Exigida Uno Identifica el orden de este vagón con respecto a los demás vagones de la lista de CarriageStatus del vehicle. El primer vagón en el sentido de la marcha debe tener un valor de 1. El segundo valor corresponde al segundo vagón en el sentido de la marcha y debe tener un valor de 2, y así sucesivamente. Por ejemplo, el primer vagón en el sentido de la marcha tiene un valor de 1. Si el segundo vagón en el sentido de la marcha tiene un valor de 3, los consumidores descartarán los datos de todos los vagones (es decir, el campo multi_carriage_details ). Los vagones sin datos deben representarse con un número válido de carriage_sequence y los campos sin datos deben omitirse (alternativamente, esos campos también podrían incluirse y establecerse con los valores "sin datos").

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Puede adoptarse formalmente en el futuro.

message Alert

Una Alert que indica algún tipo de incidente en la red de transporte público.

Campos

Nombre del campo Tipo Exigida Cardinalidad Descripción
active_period TimeRange Opcional Muchos time en el que la Alert debe mostrarse al usuario. Si falta, la Alert se mostrará mientras aparezca en el feed. Si se indican varios intervalos, la Alert se mostrará durante todos ellos.
informed_entity EntitySelector Exigida Muchos Entidades a cuyos usuarios debemos notificar esta Alert. Se debe proporcionar al menos una informed_entity.
Cause Cause Opcional Uno
Effect Effect Opcional Uno
url TranslatedString Opcional Uno La url que proporciona información adicional sobre la Alert.
header_text TranslatedString Exigida Uno header de la Alert. Esta string texto plano se resaltará, por ejemplo, en negrita.
description_text TranslatedString Obligatorio Uno Descripción de la Alert. Esta string texto plano se formateará como cuerpo de la Alert (o se mostrará en una solicitud explícita de "expansión" por parte del usuario). La información de la descripción debe añadirse a la información de la header.
tts_header_text TranslatedString Opcional Uno text que contiene la header de la Alert que se utilizará para las implementaciones de texto a text. Este campo es la versión de texto a text de header_text. Debe contener la misma información que header_text pero formateada de manera que pueda leerse como texto a text(por ejemplo, se eliminan las abreviaturas, se deletrean los números, etc.)
tts_description_text TranslatedString Opcional Uno text que contiene una descripción de la Alert que se utilizará para las implementaciones de texto a text. Este campo es la versión de texto a text de description_text. Debe contener la misma información que description_text pero formateada de manera que pueda leerse como texto a text(por ejemplo, se han eliminado las abreviaturas, se han deletreado los números, etc.)
severity_level SeverityLevel Opcional Uno Gravedad de la Alert.
image TranslatedImage Opcional Uno TranslatedImage que se mostrará junto al text Alert alerta. Se utiliza para explicar visualmente el Effect Alert alerta de un DETOUR, el cierre de una estación, etc. La image debe mejorar la comprensión de la Alert y no debe ser la única ubicación de la información esencial. Se desaconsejan los siguientes tipos de imágenes: image que contengan principalmente text, imágenes de marketing o de marca que no añadan información adicional.

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Puede adoptarse formalmente en el futuro.
image_alternative_text TranslatedString Opcional Uno text que describe el aspecto de la image vinculada en el image (por ejemplo, en caso de que la image no pueda mostrarse o el usuario no pueda ver la image por razones de accesibilidad). Consulte la especificación HTML para text texto alternativo de image imagen.

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Es posible que se adopte formalmente en el futuro.

enum Cause

Cause de esta Alert.

Valores

Valor
UNKNOWN_CAUSE
OTHER_CAUSE
TECHNICAL_PROBLEM
STRIKE
DEMONSTRATION
ACCIDENT
HOLIDAY
WEATHER
MAINTENANCE
CONSTRUCTION
POLICE_ACTIVITY
MEDICAL_EMERGENCY

enum Effect

El Effect de este problema en la entity afectada.

Valores

Valor
NO_SERVICE
REDUCED_SERVICE
SIGNIFICANT_DELAYS
DETOUR
ADDITIONAL_SERVICE
MODIFIED_SERVICE
OTHER_EFFECT
UNKNOWN_EFFECT
STOP_MOVED
NO_EFFECT
ACCESSIBILITY_ISSUE

enum SeverityLevel

La gravedad de la Alert.

Atención: este campo es todavía experimental y está sujeto a cambios. Es posible que se adopte formalmente en el futuro.

Valores

Valor
UNKNOWN_SEVERITY
INFO
WARNING
SEVERE

message TimeRange

Un intervalo de time. El intervalo se considera activo en el time t si t es mayor o igual que la time de start y menor que la time de end.

Campos

Nombre del campo Tipo Obligatorio Cardinalidad Descripción
start uint64 Requerido condicionalmente Uno time destart, en time POSIX (es decir, número de segundos desde el 1 de enero de 1970 00:00:00 UTC). Si falta, el intervalo comienza en menos infinito. Si se proporciona un TimeRange, se debe proporcionar el start o el end - ambos campos no pueden estar EMPTY.
end uint64 Requerido condicionalmente Uno timeend, en time POSIX (es decir, número de segundos desde el 1 de enero de 1970 00:00:00 UTC). Si falta, el intervalo termina en el infinito. Si se proporciona un TimeRange, se debe proporcionar el start o el end - ambos campos no pueden estar EMPTY.

Position del_message_

Position geográfica de un vehicle.

Campos

Nombre del campo Tipo Obligatorio Cardinalidad Descripción
latitude float Obligatorio Uno Grados Norte, en el sistema de coordenadas WGS-84.
longitude float Obligatorio Uno Grados Este, en el sistema de coordenadas WGS-84.
bearing float Opcional Uno bearing, en grados, en el sentido de las agujas del reloj desde el Norte verdadero, es decir, 0 es Norte y 90 es Este. Puede ser el bearing de la brújula o la dirección hacia la siguiente parada o ubicación intermedia. No debe deducirse de la secuencia de posiciones anteriores, que los clientes pueden calcular a partir de datos anteriores.
odometer double Opcional Uno Valorodometer, en metros.
speed float Opcional Uno speed momentánea medida por el vehicle, en metros por segundo.

message TripDescriptor

Un descriptor que identifica una única instancia de un trip GTFS.

Para especificar una única instancia de trip, en muchos casos basta con un trip_id. Sin embargo, los siguientes casos requieren información adicional para resolver una única instancia de trip:

  • Para los viajes definidos en frequencies.txt, se requieren start_date y start_time además de trip_id
  • Si el trip dura más de 24 horas, o se retrasa de tal manera que podría colisionar con un trip SCHEDULED al día siguiente, entonces se requiere start_date además de trip_id
  • Si no se puede proporcionar el campo trip_id, se deben proporcionar route_id, direction_id, start_date y start_time

En todos los casos, si se proporciona route_id además de trip_id, entonces el route_id debe ser el mismo route_id asignado al trip dado en GTFS trips.txt.

El campo trip_id no puede utilizarse, por sí mismo o en combinación con otros campos de TripDescriptor, para identificar varias instancias de trip. Por ejemplo, un TripDescriptor nunca debe especificar trip_id por sí mismo para viajes GTFS frequencies.txt.txt exact_times=0 porque start_time también se requiere para resolver una única instancia de trip que comienza a una time específica del día. Si el TripDescriptor no se resuelve a una única instancia de trip (es decir, se resuelve a cero o múltiples instancias de trip ), se considera un error y la entity que contiene el TripDescriptor erróneo puede ser descartada por los consumidores.

Tenga en cuenta que si no se conoce trip_id, los identificadores de secuencia de estación en TripUpdate no son suficientes, y también deben proporcionarse los stop_ids. Además, deben proporcionarse las horas absolutas de arrival.

TripDescriptor.route_id no puede utilizarse dentro de un EntitySelector de Alert para especificar una Alert de toda la ruta que afecte a todos los viajes de una ruta - utilice EntitySelector.route_id en su lugar.

Campos

Nombre del campo Tipo Obligatorio Cardinalidad Descripción
trip_id string Requerido condicionalmente Uno El trip_id del feed GTFS al que se refiere este selector. Para los viajes no basados en la frecuencia (viajes no definidos en GTFS frequencies.txt), este campo es suficiente para identificar de forma exclusiva el trip. Para los viajes basados en la frecuencia definida en GTFS frequencies.txt.txt, se requiere trip_id, start_time y start_date. Para los viajes basados en SCHEDULED horario (viajes no definidos en GTFS frequencies frequencies.txttxt), trip_id sólo puede omitirse si el trip puede identificarse de forma exclusiva mediante una combinación de route_id, direction_id, start_time y start_date, y se proporcionan todos esos campos. Cuando schedule_relationship es DUPLICATED dentro de un TripUpdate, el trip_id identifica el trip de la GTFS estática que se va a DUPLICATED. Cuando schedule_relationship se DUPLICATED dentro de un VehiclePosition, el trip_id identifica el nuevo trip duplicado y debe contener el valor del TripUpdate correspondiente.TripProperties.trip_id.
route_id string Requerido condicionalmente Uno El route_id del GTFS al que se refiere este selector. Si se omite trip_id, route_id, direction_id, start_time y schedule_relationship=SCHEDULED deben establecerse para identificar una instancia de trip. TripDescriptor.route_id no debe utilizarse dentro de un EntitySelector de Alert para especificar una Alert de toda la ruta que afecte a todos los viajes de una ruta - utilice EntitySelector.route_id en su lugar.
direction_id uint32 Requerido condicionalmente Uno El direction_id del archivo GTFS feed trips.txt, que indica la dirección del viaje para los viajes a los que se refiere este selector. Si se omite trip_id, se debe proporcionar direction_id.

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Es posible que se adopte formalmente en el futuro.
start_time string Requerido condicionalmente Uno La time de start inicialmente SCHEDULED de esta instancia de trip. Cuando trip_id corresponde a un trip no basado en la frecuencia, este campo debe omitirse o ser igual al valor de la alimentación GTFS. Cuando el trip_id corresponde a un trip basado en frecuencias definido en GTFS frequencies.txt, start_time hora de inicio es necesaria y debe especificarse para las actualizaciones del trip y las posiciones de vehicle. Si el trip corresponde a exact_times=1 registro GTFS, entonces start_time debe ser algún múltiplo (incluyendo cero) de headway_secs más tarde que frequencies. frequencies.txt start_time para el período de time correspondiente. Si el trip corresponde a exact_times=0, entonces su start_time puede ser arbitrario, e inicialmente se espera que sea la primera departure del trip. Una vez establecida, la hora start_time inicio de este trip basado en exact_times=0 debe considerarse inmutable, incluso si la primera time de departure cambia -- ese cambio de time puede reflejarse en cambio en un StopTimeUpdate. Si se omite trip_id, debe proporcionarse start_time. El formato y la semántica del campo es el mismo que el de GTFSfrequencies.txt, por ejemplo, 11:15:35 o 25:15:35.
start_date string Requerido condicionalmente Uno La fecha de start de esta instancia de trip en formato AAAAMMDD. En el caso de los viajes SCHEDULED (viajes no definidos en GTFS frequencies.txtxt), este campo debe proporcionarse para desambiguar los viajes que se retrasan tanto como para colisionar con un trip SCHEDULED en un día siguiente. Por ejemplo, para un tren que sale a las 8:00 y a las 20:00 todos los días, y que tiene un retraso de 12 horas, habría dos viajes distintos a la misma time. Este campo puede proporcionarse pero no es obligatorio para los horarios en los que tales colisiones son imposibles - por ejemplo, un servicio que funciona con un horario en el que un vehicle que llega una hora tarde ya no se considera relacionado con el horario. Este campo es obligatorio para los viajes basados en la frecuencia definida en GTFS frequencies.txt. Si se omite trip_id, debe indicarse start_date.
schedule_relationship ScheduleRelationship Opcional Uno La relación entre este trip y el horario estático. Si se proporciona TripDescriptor en una Alert EntitySelectorEn el caso de que se indique un intervalo de tiempo, el schedule_relationship el campo es ignorado por los consumidores al identificar la instancia de trip correspondiente.

enum ScheduleRelationship

La relación entre este trip y el horario estático. Si un trip se realiza de acuerdo con un horario temporal, no reflejado en GTFS, entonces no debe marcarse como SCHEDULED, sino como ADDED.

Valores

Valor Comentario
SCHEDULED trip que se está realizando de acuerdo con su horario GTFS Schedule, o está lo suficientemente cerca del trip SCHEDULED como para ser asociado a él.
ADDED Un trip extra que fue ADDED además de un horario en marcha, por ejemplo, para reemplazar un vehicle roto o para responder a una carga repentina de pasajeros. NOTA: Actualmente, el comportamiento no está especificado para las alimentaciones que utilizan este modo. Hay discusiones en el GitHub de GTFS (1) (2) (3) en torno a la especificación completa o a la eliminación de los viajes ADDED y la documentación se actualizará cuando estas discusiones hayan finalizado.
UNSCHEDULED Un trip que se está ejecutando sin horario asociado - este valor se utiliza para identificar los viajes definidos en GTFS frequencies.txt frequencies.txt txt con exact_times = 0. No debe utilizarse para describir los viajes no definidos en GTFS frequencies.txt, o viajes en GTFS frequencies.txt con exact_times = 1. Los viajes con schedule_relationship: UNSCHEDULED también deben establecer todos los StopTimeUpdates schedule_relationship: UNSCHEDULED
CANCELED Un trip que existía en el horario pero fue eliminado.
DUPLICATED Un nuevo trip que es el mismo que un trip SCHEDULED existente, excepto por la fecha y time de start del servicio. Se utiliza con TripUpdate.TripProperties.trip_id, TripUpdate.TripProperties.start_date, y TripUpdate.TripProperties.start_time para copiar un trip existente desde GTFS estático pero start una fecha y/o time de inicio de servicio diferente. La duplicación de un trip está permitida si el servicio relacionado con el trip original en (CSV) GTFS (en calendar.txt o calendar_dates.txt) está operando dentro de los próximos 30 días. El trip que se va a DUPLICATED se identifica mediante TripUpdate.TripDescriptor.trip_id.

Esta enumeración no modifica el trip existente referenciado por TripUpdate.TripDescriptor.trip_id - si un productor quiere cancelar el trip original, debe publicar un TripUpdate con el valor de CANCELED. Viajes definidos en GTFS frequencies.txt con exact_times que esté EMPTY o sea igual a 0 no pueden ser DUPLICATED. El VehiclePosition.TripDescriptor.trip_id para el nuevo trip debe contener el valor correspondiente de TripUpdate.TripProperties.trip_id y VehiclePosition.TripDescriptor.ScheduleRelationship también debe ser igual a DUPLICATED.

Los productores y consumidores existentes que utilizaban la enumeración ADDED para representar viajes DUPLICATED deben seguir la guía de migración para pasar a la enumeración DUPLICATED.

message VehicleDescriptor

Información de identificación del vehicle que realiza el trip.

Campos

Nombre del campo Tipo Obligatorio Cardinalidad Descripción
id string Opcional Uno Identificación interna del sistema del vehicle. Debe ser único por vehicle, y se utiliza para el seguimiento del vehicle a medida que avanza por el sistema. Esta id no debe ser visible para el end final; para ello, utilice la etiqueta label campo
label string Opcional Uno label visible para el usuario, es decir, algo que debe mostrarse al pasajero para ayudarle a identificar el vehicle correcto.
license_plate string Opcional Uno La matrícula del vehicle.

message EntitySelector

Un selector para una entity en un feed GTFS. Los valores de los campos deben corresponder a los campos apropiados en el feed GTFS. Debe darse al menos un especificador. Si se dan varios, deben interpretarse como unidos por el operador lógico AND. Además, la combinación de especificadores debe coincidir con la información correspondiente en el feed GTFS. En otras palabras, para que una Alert se aplique a una entity en GTFS debe coincidir con todos los campos EntitySelector proporcionados. Por ejemplo, un EntitySelector que incluya los campos route_id: " 5 " y route_type: " 3 " se aplica sólo al bus route_id route_id: "5 " - no se aplica a ninguna otra ruta de route_type route_type: "3". Si un productor quiere que una Alert se aplique a route_id route_id: "5 " así como a route_type route_type: "3 ", deberá proporcionar dos EntitySelectors distintos, uno que haga referencia a route_id route_id: "5 " y otro que haga referencia a route_type route_type: "3".

Debe darse al menos un especificador - todos los campos de un EntitySelector no pueden ser EMPTY.

Campos

Nombre del campo Tipo Obligatorio Cardinalidad Descripción
agency_id string Requerido condicionalmente Uno El agency_id del feed GTFS al que se refiere este selector.
route_id string Requerido condicionalmente Uno El route_id del GTFS al que se refiere este selector. Si se proporciona direction_id, también debe proporcionarse route_id.
route_type int32 Requerido condicionalmente Uno El route_type del GTFS al que hace referencia este selector.
direction_id uint32 Requerido condicionalmente Uno El direction_id del archivo GTFS feed trips.txt, utilizado para seleccionar todos los viajes en una dirección para una ruta, especificada por route_id. Si se proporciona direction_id, también debe proporcionarse route_id.

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Es posible que se adopte formalmente en el futuro.
trip TripDescriptor Requerido condicionalmente Uno La instancia de trip de la GTFS a la que se refiere este selector. Este TripDescriptor debe resolver una única instancia de trip en los datos GTFS (por ejemplo, un productor no puede proporcionar sólo un trip_id para viajes exact_times=0). Si el campo ScheduleRelationship se rellena dentro de este TripDescriptor, será ignorado por los consumidores cuando intenten identificar el trip GTFS.
stop_id string Requerido condicionalmente Uno El stop_id de la alimentación GTFS a la que se refiere este selector.

message TranslatedString

Un message internacionalizado que contiene versiones por idioma de un fragmento de text o una url. Se recogerá una de las cadenas de un message. La resolución procede como sigue: Si el language de la interfaz de usuario coincide con el código de language de una Translation, se elige la primera Translation que coincida. Si el language por defecto de la interfaz de usuario (por ejemplo, el inglés) coincide con el código de language de una Translation, se elige la primera Translation que coincida. Si alguna Translation tiene un código de language no especificado, se elige esa Translation.

Campos

Nombre del campo Tipo Obligatorio Cardinalidad Descripción
Translation Translation Obligatorio Muchos Se debe proporcionar al menos una Translation.

traducción Translation_message_

Una string localizada asignada a un language.

Nombre del campo Tipo Obligatorio Cardinalidad Descripción
text string Obligatorio Uno Una string UTF-8 que contiene el message.
language string Requerido condicionalmente Uno Código de language BCP-47. Puede omitirse si se desconoce el language o si no se realiza ninguna internacionalización para el feed. Se permite que como máximo una Translation tenga una etiqueta de language no especificada - si hay más de una Translation, se debe proporcionar el language.

message TranslatedImage

Un message internacionalizado que contiene versiones por idioma de una image. Se recogerá una de las imágenes de un message. La resolución procede como sigue: Si el language de la interfaz de usuario coincide con el código de language de una Translation, se elige la primera Translation que coincida. Si el language de la interfaz de usuario por defecto (por ejemplo, el inglés) coincide con el código de language de una Translation, se elige la primera Translation que coincida. Si alguna Translation tiene un código de language no especificado, se elige esa Translation.

Precaución: este message es todavía experimental y está sujeto a cambios. Es posible que se adopte formalmente en el futuro.

Campos

Nombre del campo Tipo Obligatorio Cardinalidad Descripción
localized_image LocalizedImage Obligatorio Muchos Debe proporcionarse al menos una image localizada.

message LocalizedImage

Una url de image localizada asignada a un language.

Nombre del campo Tipo Obligatorio Cardinalidad Descripción
url string Obligatorio Uno string que contiene una url que enlaza con una image. La image enlazada debe ser inferior a 2MB. Si una image cambia de forma suficientemente significativa como para que se requiera una actualización en el lado del consumidor, el productor debe actualizar la url a una nueva.

La url debe ser una url completa que incluya http:// o https://, y cualquier carácter especial en la url debe ser escapado correctamente. Véase lo siguiente url para una descripción de cómo crear valores de url totalmente cualificados.
media_type string Obligatorio Uno Tipo de medio IANA como para especificar el tipo de image que se mostrará. El tipo debe start por "image/"
language string Requerido condicionalmente Uno Código de language BCP-47. Puede omitirse si se desconoce el language o si no se realiza ninguna internacionalización para el feed. Se permite que como máximo una Translation tenga una etiqueta de language no especificada - si hay más de una Translation, se debe proporcionar el language.

Shape del_message_

Describe la trayectoria física que sigue un vehicle cuando la Shape no forma parte del GTFS(CSV), como en el caso de un DETOUR ad-hoc. Las formas pertenecen a los viajes y consisten en una polilínea codificada para una transmisión más eficiente. No es necesario que las formas intercepten la ubicación de las paradas con exactitud, pero todas las paradas de un trip deben encontrarse a una pequeña distancia de la Shape de ese trip, es decir, cerca de los segmentos de línea recta que conectan los puntos de Shape.

Atención: este message es todavía experimental y está sujeto a cambios. Es posible que se adopte formalmente en el futuro.
.

Campos

Nombre del campo Tipo Obligatorio Cardinalidad Descripción
shape_id string Obligatorio Uno Identificador de la Shape. Debe ser diferente de cualquier shape_id definido en el GTFS(CSV).

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Es posible que se adopte formalmente en el futuro.
encoded_polyline string Obligatorio Uno Representación polilínea codificada de la Shape. Esta polilínea debe contener al menos dos puntos. Para más información sobre las polilíneas codificadas, véase https://developers.google.com/maps/documentation/utilities/polylinealgorithm

Precaución: este campo sigue siendo experimentaly está sujeta a cambios. Es posible que se adopte formalmente en el futuro.