Présentation
Si vous n'êtes pas le fournisseur des flux GTFS pour Google Maps, votre intégration est Arrêt uniquement. 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 colonnes qui correspondent au "Nom du champ" spécifié dans le tableau de spécifications du flux correspondant.
Pour permettre au partenaire d'importer de nouvelles versions des fichiers d'arrêts et de marchés, notre équipe partagera les informations de la boîte de dépôt SFTP, une pour chaque type de fichier, lors du processus d'intégration.
Spécification du flux d'arrêts (obligatoire)
Le fichier des arrêts doit contenir les colonnes suivantes :
| Nom du champ | Type (voir GTFS) | Description |
|---|---|---|
stop_id |
ID (obligatoire) | Identifiant unique d'un arrêt ou d'une station. Les grandes gares ne doivent contenir qu'une seule entrée. Il est utilisé lors des appels à votre API Partner Server et dans les liens profonds vers les tickets. |
stop_name |
Texte (obligatoire) | Nom lisible pour le débogage des données de cartographie des arrêts, de remplissage du cache et de précision 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é permettant aux partenaires de 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écifications du flux d'ensemble de marchés (facultatif)
À partir des arrêts mappés, nous générons l'ensemble de marché 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'ensemble 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 ceux inclus dans la liste feront l'objet d'une requête. 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 la mettre en cache de manière proactive.
Le fichier d'ensemble de marchés doit contenir les colonnes suivantes :
| Nom du champ | Type (voir GTFS) | Description |
|---|---|---|
origin_stop_id |
ID (obligatoire) | L'origine stop_id du marché. |
destination_stop_id |
ID (obligatoire) | Destination stop_id du marché. |
Configuration des partenaires
Lorsque vous utilisez l'intégration d'arrêts uniquement, nous avons besoin d'informations supplémentaires pour la configuration statique du partenaire, comme indiqué dans la section sur la configuration du partenaire.
Spécifications 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 Partner
Les paramètres SegmentKeys de l'API Partner (GetBulkTripOptionsRequest) sont basés sur la spécification des liens profonds. Nous utilisons des SegmentKeys, y compris uniquement 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 toutes les correspondances, en spécifiant plusieurs SegmentKeys, une par segment.