Présentation
Si vous n'êtes pas le fournisseur des flux GTFS pour Google Maps, votre intégration est limitée aux arrêts. Pour cette intégration, nous devons comprendre comment vous identifiez les différents arrêts de train ou de bus.
Spécifications générales du flux
Lorsque vous commencez l'intégration, nous créons un identifiant unique pour chaque intégration, par exemple : ch_google_test (code pays, nom du partenaire, intégration) ou eu_google (code région, nom du partenaire).
Les partenaires fournissent un fichier contenant des fichiers texte au format CSV qui sont appliqués par intégration. Chaque fichier CSV doit contenir une ligne d'en-tête avec des noms de colonne qui correspondent au "Nom du champ" spécifié dans le tableau de spécification du flux correspondant.
Pour permettre aux partenaires d'importer de nouvelles versions des fichiers d'arrêts et de marchés, notre équipe partagera les informations de la Dropbox SFTP (une pour chaque type de fichier) lors du processus d'intégration.
Spécification du flux d'arrêts (obligatoire)
Le fichier d'arrêts doit contenir les colonnes suivantes :
| Nom du champ | Type (voir GTFS) | Description |
|---|---|---|
stop_id |
ID (obligatoire) | Identifiant unique qui identifie un arrêt ou une gare. Les gares plus grandes ne doivent contenir qu'une seule entrée. Cet identifiant est utilisé lorsque vous appelez l'API de votre serveur partenaire et dans les liens profonds de billetterie. |
stop_name |
Texte (obligatoire) | Nom lisible pour le débogage du mappage des arrêts, le remplissage du cache et les données sur l'exactitude des prix. |
stop_lat |
Latitude (obligatoire) | Latitude de l'arrêt. |
stop_lon |
Longitude (obligatoire) | Longitude de l'arrêt. |
Nous utiliserons un processus d'ingestion automatisé dans lequel les partenaires pourront fournir en continu des fichiers ZIP mis à jour lorsque les informations qu'ils contiennent changent. Par exemple, un partenaire peut étendre l'inventaire fourni en allongeant la liste des arrêts. Toutefois, comme pour GTFS, les stop_ids doivent être stables.
Spécification du flux d'ensembles de marchés (facultatif)
Avec les arrêts mappés, nous générons l'ensemble de marchés pour cette intégration (une liste contenant les paires origine / destination populaires). Vous pouvez ensuite réduire cet ensemble de marchés en fournissant un flux d'ensembles de marchés.
L'ensemble de marchés sert de liste d'autorisation pour notre service de remplissage du cache. Par défaut, si aucun ensemble de marchés n'est fourni, tous les marchés sont activés. Si vous fournissez un ensemble de marchés, seuls les marchés inclus dans la liste seront interrogés. Si les utilisateurs interrogent des marchés en dehors de cette liste d'autorisation, nos systèmes enverront toujours une requête en direct pour le marché et la date demandés, mais nous n'essaierons pas de les mettre en cache de manière proactive.
Le fichier d'ensembles de marchés doit contenir les colonnes suivantes :
| Nom du champ | Type (voir GTFS) | Description |
|---|---|---|
origin_stop_id |
ID (obligatoire) | stop_id d'origine du marché. |
destination_stop_id |
ID (obligatoire) | stop_id de destination du marché. |
Configuration des partenaires
Lorsque vous utilisez l'intégration limitée aux arrêts, nous avons besoin d'informations supplémentaires pour la configuration statique des partenaires, comme indiqué dans la section Configuration des partenaires.
Spécification des liens de parrainage
Le format et les paramètres du lien de réservation (également appelé
Ticketing link) sont définis dans Liens
de billetterie
Paramètres de l'API partenaire
Les paramètres SegmentKeys de l'API partenaire
(GetBulkTripOptionsRequest)
sont basés sur la spécification des liens profonds. Nous utilisons
SegmentKeys qui n'incluent
que from_ticketing_stop_time_id, to_ticketing_stop_time_id,
service_date, boarding_time et arrival_time, en laissant
ticketing_trip_id vide. Nous spécifierons entièrement l'itinéraire, y compris tous les transferts, en spécifiant plusieurs SegmentKeys, un par segment.