概览
如果您不是 Google 地图的 GTFS Feed 提供方，则您的集成属于仅限站点。对于此集成，我们需要了解您如何识别不同的火车或公交车站。
常规 Feed 规范
在开始集成时，我们会为每个集成创建一个唯一标识符，例如：ch_google_test（国家/地区代码、合作伙伴名称、集成）或 eu_google（地区代码、合作伙伴名称）。
合作伙伴提供一个包含 CSV 格式文本文件的文件，这些文件会按集成应用。每个 CSV 文件都必须包含一个标题行，其中包含的列名称必须与相应 Feed 规范表中指定的“字段名称”一致。
为了让合作伙伴能够上传新的停靠站和市场文件版本，我们的团队将在初始配置流程中分享 SFTP Dropbox 详细信息，每种文件类型对应一个。
停止 Feed 规范（必需）
公交站文件应包含以下列：
| 字段名称 | 类型（请参阅 GTFS） | 说明 |
|---|---|---|
stop_id |
ID（必需） | 用于标识某个停靠站或车站的唯一标识符。较大的站应仅包含一个条目。此 ID 在调用合作伙伴服务器 API 时以及在票务深层链接中使用。 |
stop_name |
文字（必需） | 用于调试停靠站映射、缓存填充和价格准确性数据的人类可读名称。 |
stop_lat |
纬度（必需） | 经停点的纬度。 |
stop_lon |
经度（必需） | 经停点的经度。 |
我们将使用自动化注入流程，合作伙伴可以在其中持续提供更新后的 ZIP 文件，以便在其中包含的信息发生变化时进行更新。例如，合作伙伴可以通过延长停靠站列表来扩大所提供的广告资源。不过，与 GTFS 类似，stop_ids 应该保持稳定。
市场集 Feed 规范（可选）
根据映射的经停点，我们为相应集成生成市场集（包含热门出发地 / 目的地对的列表）。然后，您可以选择通过提供市场集 Feed 来减少此市场集。
市场集充当缓存填充服务的许可名单。默认情况下，如果未提供任何市场集，则会启用所有市场。如果您提供市场集，则系统只会查询列表中包含的市场。如果用户查询此许可名单之外的市场，我们的系统仍会针对所请求的特定市场和日期发送实时查询，但我们不会尝试主动缓存结果。
市场集文件应包含以下列：
| 字段名称 | 类型（请参阅 GTFS） | 说明 |
|---|---|---|
origin_stop_id |
ID（必需） | 市场的原产地 stop_id。 |
destination_stop_id |
ID（必需） | 市场的目的地 stop_id。 |
合作伙伴配置
如果使用仅停止集成，我们需要静态合作伙伴配置的额外信息，如合作伙伴配置部分中所述。
引荐链接规范
预订链接（也称为 Ticketing link）的格式和参数在票务链接中定义
Partner API 参数
合作伙伴 API (GetBulkTripOptionsRequest) 的 SegmentKeys 参数基于深层链接规范。我们使用仅包含 from_ticketing_stop_time_id、to_ticketing_stop_time_id、service_date、boarding_time 和 arrival_time 的 SegmentKeys，使 ticketing_trip_id 为空。我们将通过指定多个 SegmentKey（每个细分一个），完整指定路线，包括所有换乘。