Descripción general
Si no eres el proveedor de los feeds de GTFS para Google Maps, tu integración será de solo paradas. Para esta integración, necesitamos comprender cómo identificas las diferentes paradas de tren o autobús.
Especificaciones generales del feed
Cuando iniciamos 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 el socio suba nuevas versiones de los archivos de paradas y mercados, nuestro equipo compartirá los detalles de la carpeta de Dropbox de SFTP, uno 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 tickets. |
stop_name |
Texto (obligatorio) | Es un nombre legible para depurar la asignación de paradas, el llenado de caché y los datos de precisión de precios. |
stop_lat |
Latitud (obligatorio) | Latitud de la parada. |
stop_lon |
Longitud (obligatorio) | Es la longitud de la parada. |
Usaremos un proceso de transferencia automatizado en el que los socios podrán proporcionar de forma continua 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 conjunto de mercados (opcional)
Con las paradas mapeadas, generamos el conjunto de mercado para esta integración (una lista que contiene pares de origen y destino populares). Desde allí, puedes reducir este conjunto de mercados si proporcionas un feed de conjunto 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 realizan búsquedas sobre mercados fuera de esta lista de entidades permitidas, nuestros sistemas seguirán enviando una búsqueda en vivo para el mercado y la fecha específicos solicitados, pero no intentaremos almacenarla en caché de forma proactiva.
El archivo de configuración del mercado 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 del socio
Cuando se usa la integración de solo parada, necesitamos información adicional para la configuración estática del socio, como se describe en la sección Configuración del socio.
Especificación de vínculos de referencia
El formato y los parámetros del vínculo para reservar (también llamado Ticketing link) se definen en Vínculos de venta de entradas.
Parámetros de la API de socio
Los parámetros SegmentKeys de la API de Partner (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 completamente la ruta, incluidos todos los trasbordos, con varias SegmentKeys, una por segmento.