Visão geral
Se você não for o provedor dos feeds GTFS para o Google Maps, sua integração será somente de paradas. Para essa integração, precisamos entender como você identifica os diferentes pontos de ônibus ou estações de trem.
Especificações gerais do feed
Ao iniciar a integração, criamos um identificador exclusivo para cada
integração, por exemplo: ch_google_test (código do país, nome do parceiro,
integração) ou eu_google (código da região, nome do parceiro).
Os parceiros fornecem um arquivo com arquivos de texto no formato CSV que são aplicados por integração. Cada arquivo CSV precisa conter uma linha de cabeçalho com nomes de colunas que correspondam ao "Nome do campo" especificado na tabela de especificação do feed correspondente.
Para permitir que o parceiro faça upload de novas versões dos arquivos de paradas e mercados, nossa equipe vai compartilhar detalhes do Dropbox SFTP, um para cada tipo de arquivo, durante o processo de integração.
Especificação do feed de parada (obrigatório)
O arquivo de parada precisa ter as seguintes colunas:
| Nome do campo | Tipo (consulte GTFS) | Descrição |
|---|---|---|
stop_id |
ID (obrigatório) | O identificador exclusivo que identifica uma parada ou estação. As estações maiores devem conter apenas uma entrada. Usado ao fazer chamadas para a API do servidor do parceiro e nos links diretos de emissão de passagens. |
stop_name |
Texto (obrigatório) | Um nome legível para depuração do mapeamento de paradas, preenchimento de cache e dados de precisão de preços. |
stop_lat |
Latitude (obrigatória) | Latitude da parada. |
stop_lon |
Longitude (obrigatório) | Longitude da parada. |
Vamos usar um processo de ingestão automatizado em que os parceiros podem fornecer continuamente arquivos ZIP atualizados quando as informações contidas neles mudam. Por exemplo, um parceiro pode expandir o inventário fornecido estendendo a lista de paradas. No entanto, assim como na GTFS, os stop_ids precisam ser estáveis.
Especificação do feed de conjunto de mercados (opcional)
Com as paradas mapeadas, geramos o conjunto de mercado para essa integração (uma lista que contém pares de origem / destino populares). Você pode reduzir esse conjunto de mercados fornecendo um feed de conjunto de mercados.
O conjunto de mercado funciona como uma lista de permissões para nosso serviço de preenchimento de cache. Por padrão, se nenhum conjunto de mercados for fornecido, todos os mercados serão ativados. Se você fornecer um conjunto de mercados, apenas os mercados incluídos na lista serão consultados. Se os usuários consultarem mercados fora dessa lista de permissão, nossos sistemas ainda vão enviar uma consulta dinâmica para o mercado e a data específicos solicitados, mas não vamos tentar armazenar em cache de forma proativa.
O arquivo do conjunto de mercados precisa ter as seguintes colunas:
| Nome do campo | Tipo (consulte GTFS) | Descrição |
|---|---|---|
origin_stop_id |
ID (obrigatório) | A origem stop_id do mercado. |
destination_stop_id |
ID (obrigatório) | O stop_id de destino do mercado. |
Configuração do parceiro
Ao usar a integração somente de paradas, precisamos de mais informações para a configuração estática do parceiro, conforme descrito na seção Configuração do parceiro.
Especificação de links de indicação
O formato e os parâmetros do link para reserva (também chamado de Ticketing link) são definidos em Links para
venda de passagens
Parâmetros da API de parceiro
Os parâmetros SegmentKeys da API Partner
(GetBulkTripOptionsRequest)
são baseados na especificação de link direto. Usamos SegmentKeys, incluindo apenas from_ticketing_stop_time_id, to_ticketing_stop_time_id, service_date, boarding_time e arrival_time, deixando ticketing_trip_id vazio. Vamos especificar totalmente o trajeto, incluindo todas as baldeações, ao especificar várias SegmentKeys, uma por segmento.