Yêu cầu về GTFS

Đối tác phải cung cấp nguồn cấp dữ liệu GTFS đáp ứng tất cả các quy cách tiêu chuẩn, cộng với những quy cách được liệt kê bên dưới. Nguồn cấp dữ liệu này phải bao gồm tất cả các hành trình mà đối tác muốn hiển thị. Việc cung cấp thông tin này sẽ giúp thông tin về lịch trình và tuyến đường xuất hiện trên Google. Xin lưu ý rằng đối tác có thể chọn hiển thị thêm thông tin về giá và tình trạng còn hàng cho một số hoặc tất cả các hành trình trong nguồn cấp dữ liệu được cung cấp nếu họ muốn.

Yêu cầu mặc định

Tài liệu tham khảo về GTFS tĩnh – áp dụng tất cả các yêu cầu mặc định.

Các phương pháp hay nhất về GTFS – vui lòng làm theo các phương pháp hay nhất như thể đó là yêu cầu bắt buộc.

Tải nguồn cấp dữ liệu GTFS lên - vui lòng làm theo quy trình này để tải nguồn cấp dữ liệu GTFS lên.

Thông tin cập nhật: Xin lưu ý rằng sau khi tải lên, bạn có thể cập nhật nguồn cấp dữ liệu theo quy trình được mô tả tại đây. Nhìn chung, các thông tin cập nhật nguồn cấp dữ liệu này có thể mất 2 đến 3 ngày để được truyền tải đầy đủ.

Yêu cầu khác

Phạm vi

• Một nguồn cấp dữ liệu GTFS phải bao gồm một quốc gia hoặc một phần của một quốc gia. Các chuyến đi xuyên biên giới quốc gia phải được cung cấp trong các nguồn cấp dữ liệu riêng biệt trên toàn lục địa. Nếu nguồn cấp dữ liệu GTFS bao gồm bất kỳ khu vực nào lớn hơn một quốc gia, vui lòng liên hệ với Nhóm vận tải du lịch.
  • Các tệp trong tệp zip GTFS phải có kích thước nhỏ hơn 4 GB. Các tệp có kích thước lớn hơn thường là dấu hiệu của các phương pháp không hay, chẳng hạn như bỏ qua các tuỳ chọn nén do frequencies.txt hoặc các tính năng tương tự cung cấp. Điều này có thể gây ra vấn đề trong quá trình xử lý. Nếu bạn cho rằng mình cần các tệp có kích thước lớn hơn 4 GB, vui lòng liên hệ với Nhóm vận tải du lịch tại [e-mail].
  • Dữ liệu cho toàn bộ khoảng thời gian hoạt động trong tương lai của các dịch vụ trong nguồn cấp dữ liệu GTFS phải được cung cấp cùng với mỗi lần cập nhật dữ liệu GTFS. Chúng tôi không chấp nhận việc phân đoạn dịch vụ theo các khoảng thời gian khác nhau.
• Tất cả các ngày của một nhà điều hành nhất định phải có trong một nguồn cấp dữ liệu.

Bản dịch

• Bạn có thể cung cấp bản dịch bằng translations.txt và bản dịch sẽ là bắt buộc ở những quốc gia mà:
  • Thông tin cho người dùng có thể được cung cấp bằng nhiều hệ thống chữ viết hoặc bằng các hệ thống chữ viết khác ngoài hệ thống chữ Latinh
  • Thông tin cho người dùng có thể được cung cấp bằng nhiều ngôn ngữ hoặc khi các thực thể có thể sử dụng tên gọi khác nhau bằng những ngôn ngữ đó (ví dụ: Brussels/Brussel/Bruxelles)
• Các thực thể cần được dịch
  • tên cơ quan/trạm/tuyến
  • bảng chỉ dẫn chuyến đi/trạm

Tên tuyến, tên ngắn của chuyến đi và bảng chỉ dẫn

• Bạn phải cung cấp bảng chỉ dẫn cho tất cả các chuyến đi trong trips.txt (nếu bảng chỉ dẫn vẫn nhất quán trong suốt chuyến đi) hoặc trong stop_times.txt (nếu bảng chỉ dẫn thay đổi trong các giai đoạn khác nhau của chuyến đi).
• Bảng chỉ dẫn phải khớp với thông tin mà người dùng có thể tìm thấy trên thực tế. Ví dụ: bảng chỉ dẫn hiển thị trên phương tiện hoặc trên biển báo.
• Khi một tuyến có tên, bạn phải cung cấp tên đó dưới dạng long_name trong routes.txt.
• Khi một tuyến có số hoặc giá trị nhận dạng chữ và số cụ thể áp dụng cho tất cả các chuyến đi trên tuyến đó và theo cả hai hướng, bạn phải cung cấp số hoặc giá trị nhận dạng đó dưới dạng short_name trong routes.txt.
• Khi các chuyến đi trong tuyến có giá trị nhận dạng riêng lẻ (ví dụ: số tàu), bạn phải cung cấp các giá trị nhận dạng đó dưới dạng tên ngắn của chuyến đi.
• Đối với các dịch vụ đường dài không có số hoặc tên tuyến, việc chọn tên tuyến sẽ trở nên khó khăn. Nguyên tắc chung trong những trường hợp như vậy là sự kết hợp giữa tên tuyến và bảng chỉ dẫn sẽ giúp người dùng xác định phương tiện một cách rõ ràng. Ví dụ: tên của cơ quan điều hành có thể được dùng làm tên tuyến, trong khi điểm đến của chuyến đi (nếu hiển thị trên phương tiện) phải được dùng làm bảng chỉ dẫn chuyến đi.

Ví dụ

• Tàu tốc hành Kamayani của Đường sắt Ấn Độ số 11071 từ Mumbai đến Varanasi. Lưu ý: số 11071 xác định một chuyến tàu cụ thể từ Mumbai đến Varanasi, chứ không phải bản thân tuyến đường.
  • routes.txt:
    • short_name: <empty>
    • long_name: Kamayani Express
  • trips.txt:
    • trip_short_name: 11071
    • headsign: Varanasi
• Xe buýt từ Buenos Aires đến Córdoba do Chevallier Bus vận hành. Lưu ý: Xe buýt vận hành dịch vụ này không hiển thị tên tuyến cụ thể. Thay vào đó, xe buýt hiển thị nổi bật tên của cơ quan điều hành và điểm đến. Chuyến đi cụ thể này không có số/giá trị nhận dạng riêng biệt để phân biệt với các chuyến đi khác do cùng một cơ quan vận hành hoặc phục vụ cùng một tuyến. Trong trường hợp đó, bạn có thể sử dụng "Chevallier" làm tên cơ quan (trong agencies.txt) và tên dài của tuyến (long_name) (trong routes.txt). Bạn nên sử dụng điểm đến cho bảng chỉ dẫn. trip_short_name phải để trống.
  • routes.txt:
    • short_name: <empty>
    • long_name: Chevallier
  • trips.txt:
    • trip_short_name: <empty>
    • headsign: Córdoba

Thời gian dừng

Bạn phải cung cấp cả arrival_time và departure_time trong stop_times.txt.

Cấu trúc chuyến đi

• Các chuyến đi đường dài phục vụ nhiều thành phố/khu vực phải được cung cấp từ đầu đến cuối mà không có phân đoạn (ví dụ: A->B->C chứ không phải [A->B,A->C,B->C]), trong đó A, B, C là các khu vực thành phố. Ví dụ: một xe buýt đường dài di chuyển từ Buenos Aires đến Córdoba, có một điểm dừng ở Rosario phải được biểu thị là một chuyến đi có các điểm dừng ở 3 thành phố này, chứ không phải là 3 chuyến đi "Buenos Aires – Rosario", "Buenos Aires – Córdoba" và "Rosario – Córdoba"
• Trong trường hợp nhà cung cấp dữ liệu không thể lấy được thông tin về cấu trúc chuyến đi chính xác, các chuyến đi được phân đoạn từ thành phố này sang thành phố khác có thể được cung cấp theo từng trường hợp. Nếu các chuyến đi từ thành phố này sang thành phố khác có nhiều điểm đón hoặc trả khách trong một thành phố (khu vực thành phố), thì bạn không được phân đoạn từ điểm dừng này sang điểm dừng khác. Tất cả các điểm đón và tất cả các điểm trả khách phải được liệt kê trong một chuyến đi.

Cấu trúc nhà ga

Đối với các nhà ga lớn có nhiều sân ga/vịnh đỗ, bạn phải chỉ định mối quan hệ giữa nhà ga và sân ga trong nguồn cấp dữ liệu, đồng thời xác định các vịnh đỗ/sân ga cụ thể thông qua trường platform_code trong stops.txt. Các phương tiện thường xuyên khởi hành từ hoặc đến một vịnh đỗ hoặc sân ga cụ thể phải được liên kết với vịnh đỗ hoặc sân ga đó trong nguồn cấp dữ liệu GTFS. Nếu sân ga hoặc vịnh đỗ khởi hành hoặc đến thay đổi vào các ngày/thời gian khởi hành khác nhau, bạn có thể cung cấp thông tin này trong GTFS theo thời gian thực.

Vị trí nhà ga/trạm

• Đối với các nhà ga lớn có nhiều sân ga hoặc vịnh đỗ, vị trí của nhà ga phải được đặt thành vị trí của lối vào dành cho người đi bộ nổi bật nhất (nếu nhà ga có toà nhà hoặc cấu trúc) hoặc thành vị trí của khu vực chờ của hành khách (đối với các nhà ga ngoài trời).
• Đối với các trạm nhỏ hơn ở bên đường, vị trí của trạm phải được đặt thành vị trí của cột xe buýt khi có thể xác định được. Khi không thể xác định được cột xe buýt cụ thể, vị trí phải được đặt ở đúng bên đường và trong khu vực lân cận vị trí thực tế dọc theo đường (lý tưởng nhất là trong vòng 10 m) nơi phương tiện dừng lại.

Các tiện ích GTFS khác

Chỉ bắt buộc đối với những đối tác muốn hiển thị thông tin về giá/tình trạng còn hàng bằng cách triển khai các API của đối tác.

Tiện ích Bán vé phương tiện công cộng của Google

• Đối tác nên triển khai quy cách tiện ích Bán vé phương tiện công cộng của Google. Đây là một tập hợp con của tiện ích GTFS-Bán vé.
• Chúng tôi áp đặt các yêu cầu sau đối với Mã bán vé:
  • Mã bán vé phải ổn định (tức là được phép thay đổi không thường xuyên, vì một lý do chính đáng). Trong trường hợp mã bán vé thay đổi, bạn phải đảm bảo khả năng tương thích ngược (trong khoảng thời gian tối thiểu là ít nhất 1 tuần).
  • Để xác định các tham số của SegmentKey trong yêu cầu API, bạn phải cung cấp ticketing_trip_id (trong trips.txt) và ticketing_stop_id (trong ticketing_identifiers.txt). Hệ thống không được hỗ trợ phương án dự phòng trên stop_sequence vì phương án này không ổn định.

GTFS-Giá vé phiên bản 1

Tài liệu tham khảo về GTFS tĩnh chỉ định các tệp fare_attributes.txt và fare_rules.txt không bắt buộc. Nếu đối tác tích hợp với các API của đối tác, thì bạn không nên cung cấp các tệp này.