GTFS Realtime Referência

Uma alimentação GTFS Realtime permite que as agências de trânsito forneçam aos consumidores informações em tempo real sobre interrupções em seus serviços (estações fechadas, linhas não operando, atrasos importantes, etc.) localização de seus veículos, e horários de arrival previstos.

A versão 2.0 da especificação da alimentação é discutida e documentada neste site. As versões válidas são "2.0", "1.0".

Definições do termo

Obrigatório

Em GTFS v2.0 e superiores, a coluna Requerida descreve quais campos devem ser fornecidos por um produtor para que os dados de trânsito sejam válidos e façam sentido para uma aplicação consumidora.

Os seguintes valores são usados no campo Obrigatório:

• Necessário: Este campo deve ser fornecido por um produtor de alimentação GTFS.
• Condicionalmente requerido: Este campo é obrigatório sob certas condições, que estão delineadas no campo Descrição. Fora destas condições, o campo é opcional.
• Opcional: Este campo é opcional e não é necessário que seja implementado pelos produtores. Entretanto, se os dados estiverem disponíveis nos sistemas automáticos de localização de vehicle subjacentes (por exemplo, timestamp VehiclePosition ), recomenda-se que os produtores forneçam estes campos opcionais quando possível.

Observe que os requisitos semânticos não foram definidos na versão 1.0 do GTFS, e portanto os feeds com gtfs_realtime_version de 1 podem não atender a esses requisitos (veja a proposta de requisitos semânticos para detalhes).

Cardinalidade

A cardinalidade representa o número de elementos que podem ser fornecidos para um determinado campo, com os seguintes valores:

• Um - Um único elemento pode ser fornecido para este campo. Este mapa do Protocolo Buffer requer e cardinalities opcionais.
• Muitos - Muitos elementos (0, 1, ou mais) podem ser fornecidos para este campo. Este mapa ao Protocolo Tampão de Carcterísticas repetidas.

Sempre faça referência aos campos Obrigatório e Descrição para ver quando um campo é obrigatório, condicionalmente obrigatório, ou opcional. Favor referir-se ao GTFS-realtime/proto/GTFS-realtime.proto">GTFS.proto para a cardinalidade do Protocolo Buffer.

Tipos de dados de buffer de protocolo

Os seguintes tipos de dados de buffer de protocolo são usados para descrever os elementos de alimentação:

• message: Tipo complexo
• enum: Lista de valores fixos

Campos experimentais

Os campos rotulados como experimentais estão sujeitos a mudanças e ainda não foram formalmente adotados na especificação. Um campo experimental pode ser formalmente adotado no futuro.

Índice de Elementos

• FeedMessage
  • FeedHeader
    • Incrementality
  • FeedEntity
    • TripUpdate
      • TripDescriptor
        • ScheduleRelationship
      • VehicleDescriptor
        • WheelchairAccessible
      • StopTimeUpdate
        • StopTimeEvent
        • ScheduleRelationship
        • StopTimeProperties
      • TripProperties
    • VehiclePosition
      • TripDescriptor
        • ScheduleRelationship
      • VehicleDescriptor
        • WheelchairAccessible
      • Position
      • VehicleStopStatus
      • CongestionLevel
      • OccupancyStatus
      • CarriageDetails
    • Alert
      • TimeRange
      • EntitySelector
        • TripDescriptor
          • ScheduleRelationship
      • Cause
      • Effect
      • TranslatedString
        • Translation
      • SeverityLevel

Elementos

FeedMessage_message_

O conteúdo de uma message alimentação. Cada message no fluxo é obtida como uma resposta a uma solicitação HTTP GET apropriada. Um feed em tempo real é sempre definido em relação a um feed GTFS existente. Todos os ids da entity são resolvidos com relação ao feed GTFS.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
header	FeedHeader	Obrigatório	Um	Metadados sobre esta message alimentação e alimentação.
entity	FeedEntity	Condicionalmente obrigatório	Muitos	Conteúdo da ração. Se houver informaçõestime disponíveis para o sistema de trânsito, este campo deve ser fornecido. Se este campo for EMPTY, os consumidores devem assumir que não há informaçãotime disponível para o sistema.

FeedHeader_message_

Metadados sobre uma alimentação, incluídos nas mensagens de alimentação.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
gtfs_realtime_version	string	Obrigatório	Um	Versão da especificação da alimentação. A versão atual é a 2.0.
Incrementality	Incrementality	Obrigatório	Um
timestamp	uint64	Obrigatório	Um	Este timestamp identifica o momento em que o conteúdo desta alimentação foi criado (em time servidor). No time POSIX (ou seja, número de segundos desde 1º de janeiro de 1970 00:00:00 UTC). Para evitar a distorção de time entre sistemas que produzem e consomem informações em tempo real, é altamente recomendável derivar o timestamp de um servidor de time. É completamente aceitável usar servidores de estratos 3 ou até mesmo servidores de estratos mais baixos, já que diferenças de time de até alguns segundos são toleráveis.

enum Incrementality

Determina se o fetch atual é incremental.

• FULL_DATASET: esta atualização de alimentação sobregravará todas as informações anteriores em tempo real da alimentação. Assim, espera-se que esta atualização forneça um instantâneo FULL de todas as informações conhecidas em tempo real.
• DIFFERENTIAL: atualmente, esta modalidade não tem suporte e o comportamento não é especificado para as rações que utilizam esta modalidade. Há discussões na GTFS-realtime">lista de discussãoGTFS Realtime em tempo real em torno da especificação completa do comportamento do modo DIFFERENTIAL e a documentação será atualizada quando essas discussões forem finalizadas.

Valores

Valor
FULL_DATASET
DIFFERENTIAL

FeedEntity_message_

Uma definição (ou atualização) de uma entity na alimentação em trânsito. Se a entity não estiver sendo apagada, exatamente um dos campostrip_update',vehicle',Alert' eShape' deve ser preenchido.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
id	string	Obrigatório	Um	Identificador único de alimentação para esta entity. As identificações são utilizadas apenas para fornecer suporte de Incrementality. As entidades reais referenciadas pelo feed devem ser especificadas por seletores explícitos (veja EntitySelector abaixo para mais INFO).
is_deleted	bool	Opcional	Um	Se esta entity deve ser excluída. Deve ser fornecido somente para rações com Incrementality de DIFFERENTIAL - este campo NÃO deve ser fornecido para rações com Incrementality de FULL_DATASET.
trip_update	TripUpdate	Condicionalmente necessário	Um	Dados sobre os atrasos de departure em tempo real de uma trip. Pelo menos um dos campos trip_update, vehicle, Alert, ou Shape deve ser fornecido - todos estes campos não podem ser EMPTY.
vehicle	VehiclePosition	Condicionalmente necessário	Um	Dados sobre a Position em tempo real de um vehicle. Pelo menos um dos campos trip_update, vehicle, Alert, ou Shape deve ser fornecido - todos estes campos não podem ser EMPTY.
Alert	Alert	Condicionalmente necessário	Um	Dados sobre o Alert em tempo real. Pelo menos um dos campos trip_update, vehicle, Alert, or Shape deve ser fornecido - todos estes campos não podem ser EMPTY.
Shape	Shape	Condicionalmente necessário	Um	Dados sobre as formas em tempo real ADDED, como para um DETOUR. Pelo menos um dos campos trip_update, vehicle, Alert, ou Shape deve ser fornecido - todos estes campos não podem ser EMPTY. Cuidado: este campo ainda é experimentale sujeito a mudanças. Pode ser adotado formalmente no futuro.

message TripUpdate

Atualização em tempo real sobre o progresso de um vehicle ao longo de uma trip. Por favor, consulte também a discussão geral das trip-updates">entidades de atualização datrip.

Dependendo do valor do ScheduleRelationship, uma TripUpdate pode especificar:

• Uma trip que se realiza ao longo do cronograma.
• Uma trip que prossegue ao longo de uma rota, mas não tem um horário fixo.
• Uma trip que tenha sido ADDED ou removida com relação ao horário.
• Uma nova trip que é uma cópia de uma trip existente em GTFS estático. Ela será executada na data e time serviço especificada em TripProperties.

As atualizações podem ser para eventos futuros, previstos de arrival, ou para eventos passados que já ocorreram. Na maioria dos casos, a informação sobre eventos passados é um valor medido, portanto, recomenda-se que seu valor de uncertainty seja 0. Embora possa haver casos em que isso não aconteça, é permitido ter um valor de uncertainty diferente de 0 para eventos passados. Se a uncertainty uma atualização não for 0, ou a atualização é uma previsão aproximada para uma trip que não foi concluída ou a medição não é precisa ou a atualização foi uma previsão para o passado que não foi verificada após a ocorrência do evento.

Se um vehicle estiver servindo várias viagens dentro do mesmo bloco (para mais informações sobre viagens e blocos, consulte o GTFS trips.txt):

• a alimentação deve incluir uma TripUpdate para a trip que está sendo servida atualmente pelo vehicle. Os produtores são encorajados a incluir TripUpdate para uma ou mais viagens após a trip atual no bloco deste vehicle se o produtor estiver confiante na qualidade das previsões para estas trip futuras. A inclusão de várias TripUpdates para o mesmo vehicle evita a previsão "pop-in" para os motociclistas quando o vehicle transita de uma trip para outra e também dá aos motociclistas um aviso prévio de atrasos que impactam as viagens posteriores (por exemplo, quando o delay conhecido excede os tempos de parada planejados entre as viagens).
• as respectivas entidades TripUpdate não precisam ser ADDED à alimentação na mesma ordem em que são SCHEDULED no bloco. Por exemplo, se houver viagens com trip_ids 1, 2, e 3 que pertençam todas a um bloco, e o vehicle viajar trip 1, então trip 2, e então trip 3, as entidades trip_update podem aparecer em qualquer ordem - por exemplo, adicionando trip 2, então trip 1, e então trip 3 é permitida.

Note que a atualização pode descrever uma trip que já foi concluída. Para end, basta fornecer uma atualização para a última parada da trip. Se a time de arrival na última parada estiver no passado, o cliente concluirá que toda a trip está no passado (é possível, embora inconseqüente, fornecer também atualizações para as paradas anteriores). Esta opção é mais relevante para uma trip que tenha sido concluída antes do horário, mas de acordo com o horário, a trip ainda está prosseguindo no time atual. A remoção das atualizações para esta trip poderia fazer o cliente assumir que a trip ainda está prosseguindo. Note que é permitido, mas não exigido, que o fornecedor de ração purgue as atualizações passadas - este é um caso em que isto seria praticamente útil.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
trip	TripDescriptor	Obrigatório	Um	A trip à qual esta message se aplica. Pode haver, no máximo, uma entity TripUpdate para cada instância de trip real. Se não houver nenhuma, isso significa que não há informações de previsão disponíveis. Ela faz não significam que a trip está progredindo de acordo com o cronograma.
vehicle	VehicleDescriptor	Opcional	Um	Informações adicionais sobre o vehicle que está servindo esta trip.
stop_time_update	StopTimeUpdate	Condicionalmente necessário	Muitos	Atualizações para StopTimes para a trip (tanto futuras, ou seja, previsões, como em alguns casos, passadas, ou seja, aquelas que já aconteceram). As atualizações devem ser ordenadas por stop_sequence, e se aplicam a todas as seguintes paradas da trip até a próxima stop_time_update especificada. Pelo menos uma stop_time_update deve ser fornecida para a trip, a menos queschedule_relationship seja CANCELED ou DUPLICATED - se a trip for CANCELED, nenhuma data_de_utilização_de_tempo_de_parada precisa ser fornecida. Se a trip for DUPLICATED, podem ser fornecidas datas_de_atualização_parada para indicar informaçõestime para a nova trip.
timestamp	uint64	Opcional	Um	O momento mais recente em que o progresso do vehicletime foi medido para estimar os StopTimes no futuro. Quando são fornecidos os StopTimes no passado, os tempos de arrival podem ser anteriores a este valor. No time POSIX (ou seja, o número de segundos desde 1º de janeiro de 1970 00:00:00 UTC).
delay	int32	Opcional	Um	O desvio do cronograma atual para a trip. delay só deve ser especificado quando a previsão for dada em relação a algum cronograma existente no GTFS. delay (em segundos) pode ser positivo (significando que o vehicle está atrasado) ou negativo (significando que o vehicle está adiantado em relação ao horário). delay de 0 significa que o vehicle está exatamente no time. As informações dedelay no StopTimeUpdate têm precedência sobre as informações de delay trip, de modo que o delay trip só é propagado até a próxima parada ao longo da trip com um valor de delay do StopTimeUpdate especificado. Os fornecedores de alimentação são fortemente encorajados a fornecer um valor detimestamp indicando quando o valor do delay foi atualizado pela última vez, a fim de avaliar o frescor dos dados. Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.
trip_properties	TripProperties	Opcional	Um	Fornece as propriedades atualizadas para a trip. Cuidado: Cuidado: esta message ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.

message StopTimeEvent

Informações de tempo para um único evento previsto ( arrival ou departure). O cronograma consiste em delay e/ou time estimado, e uncertainty.

• Odelay deve ser usado quando a previsão é dada em relação a algum cronograma existente no GTFS.
• Otime deve ser dado se há ou não uma previsão de horário. Se tanto time como o delay forem especificados, time terá precedência (embora normalmente, time, se dado para uma trip SCHEDULED, deve ser igual ao time SCHEDULED em GTFS + delay).

uncertainty se aplica igualmente tanto ao time quanto ao delay. A uncertainty especifica aproximadamente o erro esperado no delay real (mas note que ainda não definimos seu significado estatístico preciso). É possível que a uncertainty seja 0, por exemplo, para trens que são dirigidos sob controle de tempo computadorizado.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
delay	int32	Condicionalmente necessário	Um	delay (em segundos) pode ser positivo (significando que o vehicle está atrasado) ou negativo (significando que o vehicle está adiantado). delay de 0 significa que o vehicle está exatamente na time. O delay ou o time deve ser fornecido dentro de um StopTimeEvent - ambos os campos não podem ser EMPTY.
time	int64	Condicionalmente necessário	Um	Evento como time absoluto. Na time POSIX (ou seja, número de segundos desde 1º de janeiro de 1970 00:00:00 UTC). O delay ou o time deve ser fornecido dentro de um StopTimeEvent - ambos os campos não podem ser EMPTY.
uncertainty	int32	Opcional	Um	Se a uncertainty for omitida, ela é interpretada como desconhecida. Para especificar uma previsão completamente certa, defina sua uncertainty para 0.

message StopTimeUpdate

Atualização em tempo real para eventos de arrival e/ou departure para uma determinada parada em uma trip. Consulte também a discussão geral das atualizações de time parada no message-tripdescriptor">TripDescriptor e na documentação trip-updates">das entidades de atualização datrip.

As atualizações podem ser fornecidas tanto para eventos passados como futuros. É permitido ao produtor, embora não seja necessário, abandonar eventos passados.

A atualização está ligada a uma parada específica através de stop_sequence ou stop_id, portanto um destes campos deve necessariamente ser definido. Se o mesmo stop_id for visitado mais de uma vez em uma trip, então o stop_sequence deve ser fornecido em todas as StopTimeUpdates para aquele stop_id naquela trip.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
stop_sequence	uint32	Condicionalmente necessário	Um	Deve ser o mesmo que em stop_times.txt na alimentação GTFS correspondente. Tanto o stop_sequence quanto o stop_id devem ser fornecidos dentro de um StopTimeUpdate - ambos os campos não podem ser EMPTY. stop_sequence é necessário para viagens que visitam o mesmo stop_id mais de uma vez (por exemplo, um loop) para desambiguar para qual stop_id a previsão é destinada. Se StopTimeProperties.assigned_stop_id é povoada, então stop_sequence devem ser povoados.
stop_id	string	Condicionalmente necessário	Um	Deve ser o mesmo que em stops.txt na alimentação correspondente do GTFS. Tanto o stop_sequence quanto o stop_id devem ser fornecidos dentro de um StopTimeUpdate - ambos os campos não podem ser EMPTY. Se StopTimeProperties.assigned_stop_id é povoada, é preferível omitir stop_id e usar apenas stop_sequence. Se StopTimeProperties.assigned_stop_id e stop_id são povoados, stop_id deve combinar assigned_stop_id.
arrival	StopTimeEvent	Condicionalmente necessário	Um	Se o schedule_relationship for EMPTY ou SCHEDULED, tanto a arrival quanto a departure devem ser fornecidas dentro de um StopTimeUpdate - ambos os campos não podem ser EMPTY. arrival e departure podem ser EMPTY quando o schedule_relationship for SKIPPED. Se o schedule_relationship é NO_DATA, a arrival e a departure devem ser EMPTY.
departure	StopTimeEvent	Condicionalmente necessário	Um	Se o schedule_relationship for EMPTY ou SCHEDULED, tanto a arrival quanto a departure devem ser fornecidas dentro de um StopTimeUpdate - ambos os campos não podem ser EMPTY. arrival e departure podem ser EMPTY quando o schedule_relationship for SKIPPED. Se o schedule_relationship é NO_DATA, a arrival e a departure devem ser EMPTY.
departure_occupancy_status	OccupancyStatus	Opcional	Um	O estado previsto de ocupação do vehicle pelos passageiros imediatamente após a departure da parada em questão. Se fornecido, a stop_sequence deve ser fornecida. Para fornecer o departure_occupancy_status sem fornecer qualquer previsão de arrival ou departuretime, preencha este campo e defina StopTimeUpdate.schedule_relationship = NO_DATA. Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.
schedule_relationship	ScheduleRelationship	Opcional	Um	A relação padrão é SCHEDULED.
stop_time_properties	StopTimeProperties	Opcional	Um	Atualizações em tempo real para certas propriedades definidas dentro do GTFS stop_times.txt Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.

enum ScheduleRelationship

A relação entre este StopTime e o cronograma estático.

Valores

Valor	Comente
SCHEDULED	O vehicle está procedendo de acordo com seu cronograma estático de paradas, embora não necessariamente de acordo com os horários do cronograma. Este é o padrão comportamento. Pelo menos uma de arrival e departure deve ser providenciada. Viagens baseadas em freqüênciaGTFS frequencies.txt com tempo_exato = 0) não devem ter um valor SCHEDULED e devem usar UNSCHEDULED em seu lugar.
SKIPPED	A parada é SKIPPED, ou seja, o vehicle não irá parar nesta parada. arrival e departure são opcionais. Quando ajustado SKIPPED não é propagado para paradas subseqüentes na mesma trip (ou seja, o vehicle irá parar em paradas subseqüentes na trip, a menos que essas paradas também tenham um stop_time_update com schedule_relationship: SKIPPED). delay de uma parada anterior na trip faz propagar sobre o SKIPPED parar. Em outras palavras, se um stop_time_update com um arrival ou departure não é feita uma previsão para uma parada após a SKIPPED parar, a previsão a montante do SKIPPED parada será propagada até a parada após a SKIPPED e paradas subseqüentes na trip até uma stop_time_update para uma parada subseqüente é fornecida.
NO_DATA	Não são fornecidos dados para esta parada. Isso indica que não há informações de tempo real disponíveis. Quando a opção NO_DATA é propagada através de paradas subseqüentes, esta é a forma recomendada de especificar de qual parada você não tem informações de tempo real. Quando NO_DATA é definido, nem a arrival nem a departure devem ser fornecidas.
UNSCHEDULED	O vehicle está operando uma trip baseada em freqüênciaGTFS frequencies.txtGTFS frequencies.txt com tempo_exato = 0). Este valor não deve ser usado para viagens que não estão definidas em frequencies.txt GTFS frequencies.txt, ou viagens em frequencies.txt GTFS frequencies.txt com tempos_exatos = 1. Viagens contendo stop_time_updates com schedule_relationship: UNSCHEDULED também deve definir o TripDescriptor schedule_relationship: UNSCHEDULED Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.

message StopTimeProperties

Atualização em tempo real para certas propriedades definidas dentro do GTFS stop_times.txt.

Cuidado: esta message ainda é experimental, e está sujeita a mudanças. Ela pode ser adotada formalmente no futuro.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
assigned_stop_id	string	Opcional	Um	Apoia as tarefas de paradatime. Refere-se a um stop_id definido no GTFS stops.txt. O novo assigned_stop_id não deve resultar em uma experiência de trip significativamente diferente para o usuário end do que a stop_id definido no GTFS stop_times.txt. Em outras palavras, o usuário end não deve ver este novo stop_id como uma "mudança incomum" se a nova parada foi apresentada dentro de um aplicativo sem qualquer contexto adicional. Por exemplo, este campo destina-se a ser usado para atribuições de plataformas usando um stop_id que pertence à mesma estação que a parada originalmente definida no GTFS stop_times.txt. Para atribuir uma parada sem fornecer qualquer previsão de arrival ou departuretime, povoar este campo e definir StopTimeUpdate.schedule_relationship = NO_DATA. Se este campo for populado, StopTimeUpdate.stop_sequence deve ser povoada e StopTimeUpdate.stop_id não deve ser povoada. As atribuições de parada também devem ser refletidas em outros campos GTFS(por exemplo VehiclePosition.stop_id). Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.

message TripProperties

Define as propriedades atualizadas da trip

Cuidado: esta message ainda é experimental, e está sujeita a mudanças. Ela poderá ser adotada formalmente no futuro.
.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
trip_id	string	Condicionalmente necessário	Um	Define o identificador de uma nova trip que é uma duplicata de uma trip existente definida em (CSV) GTFS trips.txt, mas que start em uma data e/ou time de serviço diferente (definida usando TripProperties.start_date e TripProperties.start_time). Ver definição de trips.trip_id em (CSV) GTFS. Seu valor deve ser diferente dos utilizados no (CSV) GTFS. Este campo é obrigatório se schedule_relationship é DUPLICATEDCaso contrário, este campo não deve ser povoado e será ignorado pelos consumidores. Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.
start_date	string	Condicionalmente necessário	Um	Data de serviço na qual a trip DUPLICATED será executada. Deve ser fornecido no formato AAAAMMDD. Este campo é obrigatório se schedule_relationship é DUPLICATEDCaso contrário, este campo não deve ser populado e será ignorado pelos consumidores. Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.
start_time	string	Condicionalmente necessário	Um	Define a time start da trip quando esta é DUPLICATED. Ver definição de stop_times.departure_time em (CSV) GTFS. Os horários de arrival e departure SCHEDULED para a trip DUPLICATED são calculados com base na compensação entre a trip original departure_time e este campo. Por exemplo, se uma trip GTFS tem parada A com um departure_time de 10:00:00 e parar B com departure_time de 10:01:00e este campo é povoado com o valor de 10:30:00A parada B na trip DUPLICATED terá um SCHEDULED departure_time de 10:31:00. Previsão em tempo real delay são aplicados a este time programação calculado para determinar o time previsto. Por exemplo, se uma departure delay de 30 está previsto para a parada B, então a time prevista time departure é 10:31:30. Previsão em tempo real time não têm nenhuma compensação aplicada a eles e indicam o time previsto, conforme previsto. Por exemplo, se uma departure time representando 10:31:30 está previsto para a parada B, então a time prevista time departure é 10:31:30Este campo é obrigatório se schedule_relationship é DUPLICATEDCaso contrário, este campo não deve ser populado e será ignorado pelos consumidores. Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.
shape_id	string	Opcional	Um	Especifica a Shape do trajeto do vehicle para esta trip quando ela difere da original. Refere-se a uma Shape definida no GTFS (CSV) ou uma nova entity Shape em uma alimentaçãotime. Ver definição de trips.shape_id em (CSV) GTFS. Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.

message VehiclePosition

Informações de posicionamento em tempo real para um determinado vehicle.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
trip	TripDescriptor	Opcional	Um	A trip que este vehicle está servindo. Pode ser EMPTY ou parcial se o vehicle não puder ser identificado com uma determinada instância de trip.
vehicle	VehicleDescriptor	Opcional	Um	Informações adicionais sobre o vehicle que está servindo esta trip. Cada entrada deve ter um único id vehicle.
Position	Position	Opcional	Um	Position atual deste vehicle.
current_stop_sequence	uint32	Opcional	Um	O índice da seqüência de parada da parada atual. O significado da current_stop_sequence (ou seja, a parada a que se refere) é determinado pelo current_status. Se o current_status está faltando IN_TRANSIT_TO é assumido.
stop_id	string	Opcional	Um	Identifica a parada atual. O valor deve ser o mesmo que em stops.txt na alimentação correspondente do GTFS. Se StopTimeProperties.assigned_stop_id é usado para atribuir um stop_ideste campo também deve refletir a mudança em stop_id.
current_status	VehicleStopStatus	Opcional	Um	O status exato do vehicle em relação à parada atual. Ignorado se falta current_stop_sequence.
timestamp	uint64	Opcional	Um	Momento no qual a Position do vehicle foi medida. Na time POSIX (ou seja, número de segundos desde 1º de janeiro de 1970 00:00:00 UTC).
congestion_level	CongestionLevel	Opcional	Um
occupancy_status	OccupancyStatus	Opcional	Um	O estado de ocupação dos passageiros para o vehicle ou para o transporte. Se o multi_carriage_details for preenchido com o OccupancyStatus por vagão, então este campo deve descrever o vehicle inteiro com todas as carruagens aceitando passageiros considerados. Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.
occupancy_percentage	uint32	Opcional	Um	Um valor percentual que indica o grau de ocupação dos passageiros no vehicle. O valor 100 deve representar a ocupação máxima total para a qual o vehicle foi projetado, incluindo tanto a capacidade em lugares sentados quanto em pé, e os regulamentos operacionais atuais permitem. O valor pode exceder 100 se houver mais passageiros do que a capacidade máxima projetada. A precisão da occupancy_percentage deve ser suficientemente baixa para que os passageiros individuais não possam ser rastreados ao embarcar ou desembarcar no vehicle. Se os multi_carriage_details são preenchidos com a occupancy_percentage, então este campo deve descrever o vehicle inteiro com todas as carruagens aceitando passageiros considerados. Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.
multi_carriage_details	CarriageDetails	Opcional	Muitos	Detalhes sobre as múltiplas carruagens deste vehicle dado. A primeira ocorrência representa a primeira carruagem do vehicle, dada a direção atual da viagem. O número de ocorrências do campo multi_carriage_details representa o número de carruagens do vehicle. Ele também inclui as carruagens não navegáveis, como motores, carruagens de MAINTENANCE, etc... pois elas fornecem informações valiosas aos passageiros sobre onde ficar em uma plataforma. Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.

enum VehicleStopStatus

Valores

Valor	Comentário
INCOMING_AT	O vehicle está prestes a chegar à parada (em uma tela de parada, o símbolo do vehicle normalmente pisca).
STOPPED_AT	O vehicle está de pé na parada.
IN_TRANSIT_TO	O vehicle já partiu da parada anterior e está em trânsito.

enum CongestionLevel

Nível deCONGESTION que está afetando este vehicle.

Valores

Valor
UNKNOWN_CONGESTION_LEVEL
RUNNING_SMOOTHLY
STOP_AND_GO
CONGESTION
SEVERE_CONGESTION

enum OccupancyStatus

O estado de ocupação de passageiros para o vehicle ou para o transporte.

Os produtores individuais não podem publicar todos os valores do OccupancyStatus. Portanto, os consumidores não devem assumir que os valores do OccupancyStatus seguem uma escala linear. Os consumidores devem representar os valores da OccupancyStatus como o estado indicado e pretendido pelo produtor. Da mesma forma, os produtores devem usar os valores do OccupancyStatus que correspondem aos estados reais de ocupação do vehicle.

Para descrever os níveis de ocupação dos passageiros em uma escala linear, veja occupancy_percentage.

Cuidado: este campo ainda é experimental, e está sujeito a mudanças. Ele pode ser adotado formalmente no futuro.

Valores

Valor	Comentário
EMPTY	O vehicle é considerado EMPTY pela maioria das medidas, e tem poucos ou nenhum passageiro a bordo, mas ainda aceita passageiros.
MANY_SEATS_AVAILABLE	O vehicle ou carro tem um grande número de assentos disponíveis. A quantidade de assentos livres do total de assentos disponíveis para ser considerada suficientemente grande para se enquadrar nesta categoria é determinada a critério do produtor.
FEW_SEATS_AVAILABLE	O vehicle ou carro tem um pequeno número de assentos disponíveis. A quantidade de assentos livres do total de assentos disponíveis para ser considerada suficientemente pequena para se enquadrar nesta categoria é determinada a critério do produtor.
STANDING_ROOM_ONLY	Atualmente, o vehicle ou carro pode acomodar apenas passageiros em pé.
CRUSHED_STANDING_ROOM_ONLY	Atualmente, o vehicle ou carro pode acomodar apenas passageiros em pé e tem espaço limitado para eles.
FULL	O vehicle é considerado FULL pela maioria das medidas, mas ainda pode estar permitindo o embarque de passageiros.
NOT_ACCEPTING_PASSENGERS	O vehicle ou carro não está aceitando passageiros. O vehicle ou carruagem geralmente aceita passageiros para embarque.
NO_DATA_AVAILABLE	O vehicle ou carro não tem nenhum dado de ocupação disponível naquele time.
NOT_BOARDABLE	O vehicle ou carro não pode ser embarcado e nunca aceita passageiros. Útil para veículos ou carruagens especiais (motor, transporte de MAINTENANCE, etc...).

message CarriageDetails

Detalhes específicos do carro, utilizado para veículos compostos de várias carruagens.

Cuidado: esta message ainda é experimental, e está sujeita a mudanças. Ela pode ser adotada formalmente no futuro.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
id	string	Opcional	Um	Identificação do transporte. Deve ser único por vehicle. Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.
label	string	Opcional	Um	label visível do usuário que pode ser mostrada ao passageiro para ajudar a identificar o transporte. Exemplo: "7712", "Carro ABC-32", etc... Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.
occupancy_status	OccupancyStatus	Opcional	Um	Status de ocupação para este dado transporte, neste vehicle. O padrão é definido para NO_DATA_AVAILABLE. Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.
occupancy_percentage	int32	Opcional	Um	Porcentagem de ocupação para este determinado transporte, neste vehicle. Segue as mesmas regras que "VehiclePosition.occupancy_percentage". Use -1 no caso de não haver dados disponíveis para este determinado transporte. Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.
carriage_sequence	uint32	Obrigatório	Um	Identifica a ordem deste transporte em relação às outras carruagens da lista de estado do transporte do vehicle. O primeiro carro no sentido da marcha deve ter o valor 1. O segundo valor corresponde ao segundo carro no sentido da marcha e deve ter o valor 2, e assim por diante. Por exemplo, o primeiro carro no sentido da marcha tem um valor 1. Se o segundo carro no sentido da marcha tem um valor 3, os consumidores descartarão dados para todos os carros (isto é, o campo multi_carriage_details ). As carruagens sem dados devem ser representadas com um número de carriage_sequence válido e os campos sem dados devem ser omitidos (alternadamente, esses campos também poderiam ser incluídos e definidos para os valores "sem dados"). Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.

Alert_message_

Um Alert, indicando algum tipo de incidente na rede de transporte público.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
active_period	TimeRange	Opcional	Muitos	time em que o Alert deve ser mostrado ao usuário. Se faltar, o Alert será mostrado desde que apareça na alimentação. Se forem dados múltiplos intervalos, o Alert será mostrado durante todos eles.
informed_entity	EntitySelector	Obrigatório	Muitos	Entidades cujos usuários devemos notificar sobre este Alert. Pelo menos uma informed_entity deve ser fornecida.
Cause	Cause	Opcional	Um
Effect	Effect	Opcional	Um
url	TranslatedString	Opcional	Um	A url que fornece informações adicionais sobre o Alert.
header_text	TranslatedString	Obrigatório	Um	header para o Alert. Esta string texto simples será destacada, por exemplo, em negrito.
description_text	TranslatedString	Obrigatório	Um	Descrição para o Alert. Esta string texto simples será formatada como o corpo do Alert (ou mostrada em uma solicitação explícita de "expansão" por parte do usuário). As informações na descrição devem ser adicionadas às informações do header.
tts_header_text	TranslatedString	Opcional	Um	text contendo o header do Alert a ser usado para implementações de text. Este campo é a versão text do header_text. Ele deve conter as mesmas informações do header_text, mas formatado de forma que possa ser lido como text(por exemplo, abreviações removidas, números escritos, etc.).
tts_description_text	TranslatedString	Opcional	Um	text contendo uma descrição do Alert a ser usado para implementações de text. Este campo é a versão text do description_text. Ele deve conter as mesmas informações do description_text, mas formatado de forma que possa ser lido como text(por exemplo, abreviações removidas, números soletrados, etc.).
severity_level	SeverityLevel	Opcional	Um	Severidade do Alert.
image	TranslatedImage	Opcional	Um	TranslatedImage a ser exibida ao longo do text Alert. Usada para explicar visualmente o Effect de Alert de um DETOUR, fechamento de estação, etc. A image deve melhorar a compreensão do Alert e não deve ser o único local de informação essencial. Os seguintes tipos de imagens são desencorajados: image contendo principalmente text, marketing ou imagens de marca que não acrescentam nenhuma informação adicional. Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.
image_alternative_text	TranslatedString	Opcional	Um	text descrevendo a aparência da image vinculada no image (por exemplo, caso a image não possa ser exibida ou o usuário não consiga ver a image por razões de acessibilidade). Veja o HTML especificação para text image alt. Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.

enum a Cause

Cause deste Alert.

Valores

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

Effect_enum_

O Effect deste problema sobre a entity afetada.

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

A gravidade do Alert.

Cuidado: este campo ainda é experimental, e está sujeito a mudanças. Ele pode ser adotado formalmente no futuro.

Valores

Valor
UNKNOWN_SEVERITY
INFO
WARNING
SEVERE

message TimeRange

Um intervalo de time. O intervalo é considerado ativo no time t se t for maior ou igual ao time start e menor que o time end.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
start	uint64	Condicionalmente necessário	Um	hora timestart, na time POSIX (ou seja, número de segundos desde 1º de janeiro de 1970 00:00:00 UTC). Se faltar, o intervalo começa no infinito negativo. Se for fornecido um TimeRange, tanto o start quanto o end devem ser fornecidos - ambos os campos não podem ser EMPTY.
end	uint64	Condicionalmente necessário	Um	timeend, no time POSIX (ou seja, número de segundos desde 1º de janeiro de 1970 00:00:00 UTC). Se faltar, o intervalo termina em mais infinito. Se um TimeRange for fornecido, tanto o start quanto o end devem ser fornecidos - ambos os campos não podem ser EMPTY.

Position_message_

Uma Position geográfica de um vehicle.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
latitude	float	Obrigatório	Um	Graus Norte, no sistema de coordenadas WGS-84.
longitude	float	Obrigatório	Um	Graus Leste, no sistema de coordenadas WGS-84.
bearing	float	Opcional	Um	bearing, em graus, no sentido horário do Norte verdadeiro, ou seja, 0 é Norte e 90 é Leste. Este pode ser o bearing da bússola, ou a direção para a próxima parada ou local intermediário. Isto não deve ser deduzido da seqüência de posições anteriores, que os clientes podem computar a partir de dados anteriores.
odometer	double	Opcional	Um	valorodometer, em metros.
speed	float	Opcional	Um	speed momentânea medida pelo vehicle, em metros por segundo.

message TripDescriptor

Um descritor que identifica uma única instância de uma trip GTFS.

Para especificar uma única instância de trip, em muitos casos um trip_id por si só é suficiente. Entretanto, os seguintes casos requerem informações adicionais para serem resolvidos para uma única instância de trip:

• Para viagens definidas em frequencies.txt, são necessárias start_date e start_time, além do trip_id
• Se a trip durar mais de 24 horas, ou se for atrasada de tal forma que colida com uma trip SCHEDULED no dia seguinte, então a start_date é necessária, além do trip_id
• Se o campo trip_id não puder ser fornecido, então o route_id, direction_id, start_date, e start_time devem ser todos fornecidos

Em todos os casos, se o route_id for fornecido além do trip_id, então o route_id deve ser o mesmo route_id atribuído a uma determinada trip em GTFS trips.txt

O campo trip_id não pode, por si só ou em combinação com outros campos TripDescriptor, ser usado para identificar múltiplas instâncias de trip. Por exemplo, um TripDescriptor nunca deve especificar o trip_id por si só para frequencies.txt GTFS frequencies.txt exatamente_tempo=0 viagens porque o start_time também é necessário para resolver para uma única instância de trip começando em uma time específica do dia. Se o TripDescriptor não resolve para uma única instância de trip (ou seja, resolve para zero ou múltiplas instâncias de trip ), ele é considerado um erro e a entity contendo o TripDescriptor errado pode ser descartada pelos consumidores.

Observe que se o trip_id não for conhecido, então os ids de seqüência de estação no TripUpdate não são suficientes, e os stop_ids também devem ser fornecidos. Além disso, os horários absolutos de arrival devem ser fornecidos.

TripDescriptor.route_id. não pode ser usado dentro de um EntitySelector Alert para especificar um Alert toda a rota que afeta todas as viagens para uma rota - use o EntitySelector.route_id. em vez disso.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
trip_id	string	Condicionalmente necessário	Um	O trip_id do feed GTFS ao qual este seletor se refere. Para viagens não baseadas em freqüência (viagens não definidas em frequencies.txt GTFS frequencies.txt), este campo é suficiente para identificar a trip de forma única. Para viagens baseadas em freqüência definidas em frequencies.txt GTFS frequencies.txt, trip_id, start_time e start_date são todas necessárias. Para viagens SCHEDULED(viagens não definidas em freqüências GTFS. frequencies.txt), trip_id só pode ser omitido se a trip puder ser identificada exclusivamente por uma combinação de route_id, direction_id, start_time e start_date, e todos esses campos são fornecidos. Quando o schedule_relationship é DUPLICATED dentro de uma TripUpdate, o trip_id identifica a trip a partir do GTFS estático a ser DUPLICATED. Quando o schedule_relationship é DUPLICATED dentro de uma VehiclePosition, o trip_id identifica a nova trip duplicada e deve conter o valor para a TripUpdate correspondente.TripProperties.trip_id.
route_id	string	Condicionalmente necessário	Um	A route_id do GTFS a que este seletor se refere. Se omitir trip_id, route_id, direction_id, start_time, e schedule_relationship=SCHEDULED devem ser todos definidos para identificar uma instância de trip. TripDescriptor.route_id não deve ser usado dentro de um EntitySelector Alert para especificar um Alert toda a rota que afeta todas as viagens para uma rota - use o EntitySelector.route_id em seu lugar.
direction_id	uint32	Condicionalmente necessário	Um	O direction_id do arquivo GTFS feed trips.txt, indicando a direção da viagem para as viagens a que este seletor se refere. Se o trip_id for omitido, o direction_id deve ser fornecido. Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.
start_time	string	Condicionalmente necessário	Um	A time start inicial desta instância da trip. Quando o trip_id corresponde a uma trip não baseada em freqüência, este campo deve ser omitido ou ser igual ao valor na alimentação GTFS. Quando o trip_id corresponde a um trip baseado em freqüência definida em frequencies.txt GTFS frequencies.txt, a start_time é requerida e deve ser especificada para atualizações de trip e posições do vehicle. Se a trip corresponder a tempos_exatos=1 registro GTFS, então start_time deve ser algum múltiplo (incluindo zero) de avanço_segundo_de_vigilância posterior às frequencies.txt start_time para o período de time correspondente. Se a trip corresponder a horas_exatas=0, então sua start_time pode ser arbitrária, e espera-se inicialmente que seja a primeira departure da trip. Uma vez estabelecido, a start_time desta trip baseada na_tempo_exato_da_freqüência deve ser considerada imutável, mesmo se a primeira time departure mudar - essa mudança de time pode, em vez disso, ser refletida em um StopTimeUpdate. Se o trip_id for omitido, a start_time deve ser fornecida. O formato e a semântica do campo é o mesmo do GTFSfrequencies.txt, por exemplo, 11:15:35 ou 25:15:35.
start_date	string	Condicionalmente necessário	Um	A data de start desta instância de trip no formato AAAAMMDD. Para viagens SCHEDULED (viagens não definidas em frequencies.txt GTFS frequencies.txt), este campo deve ser fornecido para desambiguar viagens que são tão tardias que colidem com uma trip SCHEDULED em um dia seguinte. Por exemplo, para um trem que parte das 8:00 e 20:00 todos os dias, e está 12 horas atrasado, haveria duas viagens distintas na mesma time. Este campo pode ser fornecido mas não é obrigatório para horários nos quais tais colisões são impossíveis - por exemplo, um serviço que funciona em horário horário em que um vehicle que está uma hora atrasado não é mais considerado como relacionado ao horário. Este campo é obrigatório para viagens baseadas na freqüência definida no GTFS frequencies.txt Se o trip_id for omitido, a start_date deve ser fornecida.
schedule_relationship	ScheduleRelationship	Opcional	Um	A relação entre esta trip e o cronograma estático. Se o TripDescriptor for fornecido em um Alert EntitySelectoro schedule_relationship campo é ignorado pelos consumidores ao identificar a instância de trip correspondente.

enum ScheduleRelationship

A relação entre esta trip e o horário estático. Se uma trip é feita de acordo com o horário temporário, não refletido no GTFS, então ela não deve ser marcada como SCHEDULED, mas sim como ADDED.

Valores

Valor	Comentário
SCHEDULED	trip que esteja funcionando de acordo com sua GTFS Schedule, ou que esteja suficientemente próxima da trip SCHEDULED para ser associada a ela.
ADDED	Uma trip extra que foi ADDED além de um horário de funcionamento, por exemplo, para substituir um vehicle quebrado ou para responder a uma carga repentina de passageiros. OBSERVAÇÃO: Atualmente, o comportamento não é especificado para alimentadores que utilizam este modo. Há discussões sobre o GTFS GitHub (1) (2) (3) ao redor da especificação completa ou depreciação de viagens ADDED e a documentação será atualizada quando essas discussões forem finalizadas.
UNSCHEDULED	Uma trip que esteja em execução sem horário associado - este valor é usado para identificar viagens definidas em frequencies.txt GTFS frequencies.txt com tempos_exatos = 0. Não deve ser usado para descrever viagens não definidas em frequencies.txt GTFS frequencies.txt, ou viagens em frequencies.txt GTFS frequencies.txt com tempos_exatos = 1. Viagens com schedule_relationship: UNSCHEDULED também deve definir todas as atualizações do StopTimeUpdates schedule_relationship: UNSCHEDULED
CANCELED	Uma trip que existia na programação, mas que foi removida.
DUPLICATED	Uma nova trip que é a mesma que uma trip SCHEDULED já existente, exceto pela data e time start serviço. Usada com TripUpdate.TripProperties.trip_id, TripUpdate.TripProperties.start_datee TripUpdate.TripProperties.start_time para copiar uma trip existente do GTFS estático, mas start em uma data e/ou time de serviço diferente. A duplicação de uma trip é permitida se o serviço relacionado com a trip original em (CSV) GTFS (em calendar.txt ou calendar_dates.txt) está operando dentro dos próximos 30 dias. A trip a ser DUPLICATED é identificada através TripUpdate.TripDescriptor.trip_id. Esta enumeração não modifica a trip existente referenciada por TripUpdate.TripDescriptor.trip_id - se um produtor quiser cancelar a trip original, ele deve publicar uma TripUpdate com o valor de CANCELED. Viagens definidas em GTFS frequencies.txt com exact_times que é EMPTY ou igual a 0 não pode ser DUPLICATED. O VehiclePosition.TripDescriptor.trip_id para a nova trip deve conter o valor correspondente de TripUpdate.TripProperties.trip_id e VehiclePosition.TripDescriptor.ScheduleRelationship também deve ser ajustado para DUPLICATED. Os produtores e consumidores existentes que utilizavam a enumeração ADDED para representar as viagens DUPLICATED devem seguir o guia de migração para a transição para a enumeração DUPLICATED.

message VehicleDescriptor

Informações de identificação para o vehicle que realiza a trip.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
id	string	Opcional	Um	Identificação do sistema interno do vehicle. Deve ser único por vehicle, e é usado para rastrear o vehicle à medida que este avança pelo sistema. Esta id não deve ser tornada visível para o end; para este fim, use o label campo
label	string	Opcional	Um	label visível do usuário, ou seja, algo que deve ser mostrado ao passageiro para ajudar a identificar o vehicle correto.
license_plate	string	Opcional	Um	A placa de identificação do vehicle.

message EntitySelector

Um seletor para uma entity em uma alimentação GTFS. Os valores dos campos devem corresponder aos campos apropriados na alimentação GTFS. Pelo menos um especificador deve ser fornecido. Se forem dados vários, eles devem ser interpretados como sendo unidos pelo operador lógico AND. Além disso, a combinação de especificadores deve corresponder às informações correspondentes na alimentação GTFS. Em outras palavras, para que um Alert seja aplicado a uma entity no GTFS, ele deve corresponder a todos os campos do EntitySelector fornecidos. Por exemplo, um EntitySelector que inclua os campos route_id: "5" e o route_type: "3" se aplica somente ao route_id: ônibus " 5 " - não se aplica a nenhuma outra rota do route_type_id: "3". Se um produtor quiser que um Alert seja aplicado ao route_id: " 5 ", bem como o route_type: " 3", ele deve fornecer dois EntitySelectors separados, um referenciando route_id: " 5" e outro route_type de referência : "3".

Pelo menos um especificador deve ser dado - todos os campos em um EntitySelector não podem ser EMPTY.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
agency_id	string	Condicionalmente necessário	Um	A agency_id da alimentação GTFS a que este seletor se refere.
route_id	string	Condicionalmente necessário	Um	O route_id do GTFS a que este seletor se refere. Se o direction_id for fornecido, o route_id também deve ser fornecido.
route_type	int32	Condicionalmente necessário	Um	O route_type do GTFS a que este seletor se refere.
direction_id	uint32	Condicionalmente necessário	Um	O direction_id do arquivo GTFS feed trips.txt, usado para selecionar todas as viagens em uma direção para uma rota, especificada pelo route_id. Se o direction_id for fornecido, o route_id também deve ser fornecido. Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.
trip	TripDescriptor	Condicionalmente necessário	Um	A instância da trip do GTFS a que este seletor se refere. Este TripDescriptor deve resolver para uma única instância de trip nos dados do GTFS (por exemplo, um produtor não pode fornecer apenas um trip_id para trip_id exatas = 0 viagens). Se o campo ScheduleRelationship for preenchido dentro deste TripDescriptor, ele será ignorado pelos consumidores quando tentarem identificar a trip GTFS.
stop_id	string	Condicionalmente necessário	Um	O stop_id da alimentação GTFS a que este seletor se refere.

message TranslatedString

Uma message internacionalizada contendo versões por idioma de um trecho de text ou uma url. Uma das cordas de uma message será capturada. A resolução procede da seguinte forma: Se o language da IU corresponder ao código do language de uma Translation, a primeira Translation correspondente será escolhida. Se um language padrão da IU (por exemplo, inglês) corresponder ao código do language de uma Translation, a primeira Translation correspondente será escolhida. Se alguma Translation tiver um código de language não especificado, essa Translation é escolhida.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
Translation	Translation	Obrigatório	Muitos	Pelo menos uma Translation deve ser fornecida.

Translation_message_

Uma string localizada mapeada para um language.

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
text	string	Obrigatório	Um	Uma string UTF-8 contendo a message.
language	string	Condicionalmente necessário	Um	Um código de language BCP-47. Pode ser omitido se o language for desconhecido ou se não for feita nenhuma internacionalização para a alimentação. No máximo uma Translation pode ter uma etiqueta de language não especificada - se houver mais de uma Translation, o language deve ser fornecido.

message TranslatedImage

Uma message internacionalizada contendo versões por idioma de uma image. Uma das imagens de uma message será capturada. A resolução prossegue como a seguir: Se o language da IU corresponder ao código do language de uma Translation, a primeira Translation correspondente será escolhida. Se um language padrão da IU (por exemplo, inglês) corresponder ao código do language de uma Translation, a primeira Translation correspondente será escolhida. Se alguma Translation tiver um código de language não especificado, essa Translation é escolhida.

Cuidado: esta message ainda é experimental, e está sujeita a mudanças. Ela pode ser adotada formalmente no futuro.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
localized_image	LocalizedImage	Obrigatório	Muitos	Pelo menos uma image localizada deve ser fornecida.

message LocalizedImage

Uma url image localizada mapeada para um language.

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
url	string	Obrigatório	Um	Umstring contendo uma url vinculada a uma image. A image vinculada deve ter menos de 2MB. Se uma image mudar de forma significativa o suficiente para que seja necessária uma atualização do lado do consumidor, o produtor deve atualizar a url para uma nova. O url deve ser um url totalmente qualificado que inclua http:// ou https://, e quaisquer caracteres especiais no url devem ser corretamente gravados. Veja o seguinte url para uma descrição de como criar valores url totalmente qualificados.
media_type	string	Obrigatório	Um	Tipo de mídia IANA como para especificar o tipo de image a ser exibida. O tipo deve start com "image/".
language	string	Condicionalmente necessário	Um	Código de language BCP-47. Pode ser omitido se o language for desconhecido ou se não for feita nenhuma internacionalização para a alimentação. No máximo uma Translation pode ter uma etiqueta de language não especificada - se houver mais de uma Translation, o language deve ser fornecido.

Shape_message_

Descreve o caminho físico que um vehicle toma quando a Shape não faz parte do GTFS(CSV), como por exemplo para um DETOUR ad-hoc. As formas pertencem a Trips e consistem em uma polilinha codificada para uma transmissão mais eficiente. As formas não precisam interceptar exatamente a localização das Paradas, mas todas as Paradas em uma trip devem ficar a uma pequena distância da Shape para essa trip, ou seja, perto dos segmentos de linha reta que conectam os pontos de Shape.

Cuidado: esta message ainda é experimental, e está sujeita a mudanças. Ela poderá ser adotada formalmente no futuro.
.

Campos

Nome do campo	Tipo	Obrigatório	Cardinalidade	Descrição
shape_id	string	Obrigatório	Um	Identificador da Shape. Deve ser diferente de qualquer shape_id definido no (CSV) GTFS. Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.
encoded_polyline	string	Obrigatório	Um	Representação codificada da Shape em polilinha. Esta polilinha deve conter pelo menos dois pontos. Para mais informações sobre as polilinhas codificadas, consulte https://developers.google.com/maps/documentation/utilities/polylinealgorithm Cuidado: Cuidado: este campo ainda é experimentale está sujeita a mudanças. Pode ser adotado formalmente no futuro.