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 thông số kỹ thuật tiêu chuẩn, cùng với các thông số được liệt kê dưới đây. 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 giới thiệu. Việc cung cấp thông tin này sẽ cho phép thông tin về lịch trình và tuyến đường hiển thị trên Google. Xin lưu ý rằng đối tác có thể chọn hiển thị thông tin bổ sung về giá và tình trạng phò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 GTFS tĩnh – tất cả các yêu cầu mặc định được áp dụng.

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 theo yêu cầu.

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.

Nội dung cập nhật: Xin lưu ý rằng sau khi tải nguồn cấp dữ liệu lên, bạn có thể cập nhật nguồn cấp dữ liệu theo quy trình mô tả tại đây. Nhìn chung, những nội dung cập nhật này cho nguồn cấp dữ liệu có thể mất 2 đến 3 ngày để có hiệu lực hoàn toàn.

Yêu cầu khác

Phạm vi

• Mỗi 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 nguồn cấp dữ liệu riêng biệt trên toàn châu lục. Nếu nguồn cấp dữ liệu GTFS bao gồm phạm vi 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ó dung lượng dưới 4 GB. Các tệp lớn hơn kích thước này thường là dấu hiệu của phương thức không hợp lệ, chẳng hạn như bỏ qua các tuỳ chọn nén do frequencies.txt cung cấp hoặc các tính năng tương tự. Điều này có thể gây ra sự cố trong quá trình xử lý. Nếu bạn cho rằng mình cần tệp lớn hơn 4 GB, vui lòng liên hệ với nhóm Travel Transport theo địa chỉ [e-mail].
  • Bạn phải cung cấp dữ liệu cho toàn bộ giai đoạn hoạt động sau này của các dịch vụ trong nguồn cấp dữ liệu GTFS trong mỗi lần cập nhật dữ liệu GTFS. Bạn không được phép phân đoạn dịch vụ theo những khoảng thời gian khác nhau.
• Tất cả ngày của một toán tử cụ thể phải có trong một nguồn cấp dữ liệu duy nhất.

Bản dịch

• Bản dịch có thể được cung cấp qua translations.txt và sẽ bắt buộc ở những quốc gia:
  • Thông tin cho người dùng có thể được cung cấp bằng các chữ viết khác nhau hoặc trong các chữ viết không phải chữ viết Latinh
  • Thông tin cho người dùng có thể được cung cấp bằng nhiều ngôn ngữ hoặc trong trường hợp pháp nhân có thể sử dụng cách đặt tên khác bằng các ngôn ngữ đó (ví dụ: Brussels/Brussel/Bruxelles)
• Đối tượng sẽ được dịch
  • tên đại lý/điểm dừng/tuyến đường
  • dấu hiệu cho biết đã đi/dừng

Tên tuyến đường, tên ngắn về chuyến đi và biển hiệu

• Bạn phải cung cấp biển hiệu cho tất cả các chuyến đi trong trips.txt (nếu dấu hiệu vẫn nhất quán trong suốt chuyến đi) hoặc trong stop_times.txt (nếu dấu hiệu đó thay đổi trong các giai đoạn khác nhau của chuyến đi).
• Biển hiệu phải khớp với thông tin mà người dùng có thể tìm thấy trên mặt đất. Ví dụ: biển báo đầu xe hiển thị trên xe hoặc trên biển báo giao thông.
• Khi một tuyến đường có tên, bạn phải cung cấp tên long_name trong routes.txt.
• Khi một tuyến đường có một 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 đường đó và trong cả hai hướng, thì giá trị nhận dạng đó phải được cung cấp dưới dạng short_name trong routes.txt.
• Khi các chuyến đi trong tuyến đường có giá trị nhận dạng riêng lẻ (ví dụ: số tàu), các giá trị nhận dạng đó phải được cung cấp 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 đường, việc chọn tên tuyến sẽ trở nên khó khăn. Nguyên tắc chung trong những tình huống như vậy là tổ hợp tên tuyến đường và biển hiệu sẽ giúp người dùng xác định xe 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 đường, trong khi điểm đến của chuyến đi (nếu hiển thị trên xe) phải được sử dụng làm dấu hiệu chuyến đi.

Ví dụ

• Chuyến tàu nhanh Kamayani 11071 của Indian Rails 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 chính tuyến đường đó.
  • routes.txt:
    • short_name: <trống>
    • long_name: Kamayani Express
  • trips.txt:
    • Trip_short_name: 11071
    • biển hiệu: Varanasi
• Một chiếc xe buýt từ Buenos Aires đến Córdoba do Chevallier điều 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 đường cụ thể. Thay vào đó, tên của đơn vị điều hành và đích đến của đơn vị vận hành đó sẽ xuất hiện nổi bật. Chuyến đi cụ thể này không có số/mã nhận dạng riêng lẻ để phân biệt với các chuyến đi khác do cùng một công ty điều hành hoặc phân phát cùng một tuyến đường. Trong trường hợp đó, bạn có thể sử dụng "Chevallier" làm cả tên công ty quảng cáo (trong agencies.txt) và tuyến đường long_name (trong routes.txt). Bạn nên sử dụng đích đến cho dấu đầu. trip_short_name nên được để trống.
  • routes.txt:
    • short_name: <trống>
    • long_name: Chevallier
  • trips.txt:
    • Trip_short_name: <trống>
    • dấu hiệu: Córdoba

Thời gian ngừng

Bạn phải cung cấp cả thời gian đến và thời gian khởi hành 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 toàn diện mà không 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à khu vực thành phố. Ví dụ: đối với một chuyến xe buýt đường dài khởi hành từ Buenos Aires đến Córdoba, có điểm dừng tại Rosario phải được biểu thị dưới dạng một chuyến đi gồm các điểm dừng ở 3 thành phố này, chứ không phải là ba 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ể có được thông tin về cấu trúc chính xác của chuyến đi, các chuyến đi thành phố đến thành phố được phân đoạn có thể được cung cấp theo từng trường hợp. Nếu những chuyến đi như vậy từ thành phố đến thành phố có nhiều điểm trả khách trong một thành phố (khu vực thành phố), thì bạn không được phép phân đoạn điểm dừng – tất cả các điểm đón và điểm trả xe phải được liệt kê trong một chuyến đi duy nhất.

Kết cấu nhà ga

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

Vị trí nhà ga/điểm dừng

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

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 mở rộng Bán vé đi 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é đi phương tiện công cộng của Google, đây là một tập hợp con của phần mở rộng Bán vé GTFS.
• Chúng tôi áp dụng các yêu cầu sau đây đối với mã bán vé:
  • Mã bán vé phải cố định (nghĩa là không được thay đổi 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 sẽ phải sử dụng khả năng tương thích ngược (trong khoảng thời gian tối thiểu là 1 tuần).
  • Để xác định tham số của SegmentKey trong các yêu cầu API, bạn bắt buộc phải có ticketing_trip_id (trong trips.txt) và ticketing_stop_id (trong ticketing_identifiers.txt). Tính năng dự phòng trên stop_sequence không được hỗ trợ vì không ổn định.

GTFS-Fares phiên bản 1

Tham chiếu GTFS tĩnh chỉ định các tệp fare_attributes.txt và fare_rules.txt không bắt buộc. Nếu một đố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.