Integración continua

Descripción general

Si no eres el proveedor de los feeds de GTFS para Google Maps, tu integración es solo de paradas. Para esta integración, necesitamos comprender cómo identificas las diferentes paradas de tren o autobús.

Especificaciones generales del feed

Cuando se inicia la integración, creamos un identificador único para cada integración, por ejemplo: ch_google_test (código de país, nombre del socio, integración) o eu_google (código de región, nombre del socio).

Los socios proporcionan un archivo que contiene archivos de texto en formato CSV que se aplican por integración. Cada archivo CSV debe contener una fila de encabezado con nombres de columna que coincidan con el "Nombre del campo" especificado en la tabla de especificaciones del feed correspondiente.

Para permitir que los socios suban versiones nuevas de los archivos de paradas y mercados, nuestro equipo compartirá los detalles de la carpeta de Dropbox SFTP (una para cada tipo de archivo) durante el proceso de incorporación.

Especificación del feed de paradas (obligatorio)

El archivo de paradas debe contener las siguientes columnas:

Nombre del campo Tipo (consulta GTFS) Descripción
stop_id ID (obligatorio) Es el identificador único que identifica una parada o estación. Las estaciones más grandes solo deben contener una entrada. Se usa cuando se realizan llamadas a la API del servidor de socios y en los vínculos directos de emisión de boletos.
stop_name Texto (obligatorio) Es un nombre legible por humanos para depurar la asignación de paradas, el llenado de caché y los datos de precisión de precios.
stop_lat Latitud (obligatorio) Es la latitud de la parada.
stop_lon Longitud (obligatorio) Es la longitud de la parada.

Usaremos un proceso de ingesta automatizado en el que los socios puedan proporcionar continuamente archivos ZIP actualizados cuando cambie la información que contienen. Por ejemplo, un socio puede expandir el inventario proporcionado extendiendo la lista de paradas. Sin embargo, al igual que en GTFS, los stop_ids deben ser estables.

Especificación del feed de conjuntos de mercados (opcional)

Con las paradas asignadas, generamos el conjunto de mercados para esta integración (una lista que contiene pares de origen y destino populares). Desde allí, tienes la opción de reducir este conjunto de mercados proporcionando un feed de conjuntos de mercados.

El conjunto de mercados actúa como una lista de entidades permitidas para nuestro servicio de llenado de caché. De forma predeterminada, si no se proporciona ningún conjunto de mercados, se habilitan todos los mercados. Si proporcionas un conjunto de mercados, solo se consultarán los mercados incluidos en la lista. Si los usuarios consultan mercados fuera de esta lista de entidades permitidas, nuestros sistemas seguirán enviando una consulta en tiempo real para el mercado y la fecha solicitados, pero no intentaremos almacenarlos en caché de forma proactiva.

El archivo de conjuntos de mercados debe contener las siguientes columnas:

Nombre del campo Tipo (consulta GTFS) Descripción
origin_stop_id ID (obligatorio) Es el stop_id de origen del mercado.
destination_stop_id ID (obligatorio) Es el stop_id de destino del mercado.

Configuración de socio

Cuando se usa la integración solo de paradas, requerimos información adicional para la configuración de socio estática, como se describe en la sección Configuración de socio.

El formato y los parámetros del vínculo de reserva (también llamado Ticketing link) se definen en Vínculos de emisión de boletos

Parámetros de la API de socios

Los parámetros SegmentKeys para la API de socios (GetBulkTripOptionsRequest) se basan en la especificación de vínculos directos. Usamos SegmentKeys que incluyen solo from_ticketing_stop_time_id, to_ticketing_stop_time_id, service_date, boarding_time y arrival_time, y dejamos ticketing_trip_id vacío. Especificaremos por completo la ruta, incluidas todas las transferencias, especificando varios SegmentKeys, uno por segmento.