ข้อกําหนดของ GTFS

พาร์ทเนอร์ควรระบุฟีด GTFS ที่เป็นไปตามข้อกำหนดมาตรฐานทั้งหมด รวมถึงข้อกำหนดที่ระบุไว้ด้านล่าง ฟีดนี้ควรครอบคลุมแผนการเดินทางทั้งหมด ที่พาร์ทเนอร์ต้องการแสดง การให้ข้อมูลนี้จะช่วยให้ ข้อมูลตารางเวลาและเส้นทางปรากฏใน Google โปรดทราบว่าพาร์ทเนอร์อาจเลือกที่จะแสดงข้อมูลราคาและความพร้อมจำหน่ายสินค้าเพิ่มเติมสำหรับแผนการเดินทางบางส่วนหรือทั้งหมดในฟีดที่ระบุ หากต้องการ

ข้อกำหนดเริ่มต้น

ข้อมูลอ้างอิง GTFS แบบคงที่ - ใช้ข้อกำหนดเริ่มต้นทั้งหมด

แนวทางปฏิบัติแนะนำสำหรับ GTFS - โปรดทำตามแนวทางปฏิบัติแนะนำราวกับว่าเป็นข้อกำหนด

การอัปโหลดฟีด GTFS - โปรดทำตามกระบวนการนี้เพื่ออัปโหลดฟีด GTFS

การอัปเดต: โปรดทราบว่าเมื่ออัปโหลดฟีดแล้ว คุณจะอัปเดตฟีดได้โดยทำตามกระบวนการที่อธิบายไว้ที่นี่ โดยทั่วไป การอัปเดตฟีดเหล่านี้อาจใช้เวลา 2-3 วันจึงจะเผยแพร่ได้อย่างสมบูรณ์

ข้อกำหนดเพิ่มเติม

ขอบเขต

• ฟีด GTFS เดียวต้องครอบคลุมประเทศเดียวหรือส่วนหนึ่งของประเทศ คุณต้องระบุการเดินทางที่ข้ามพรมแดนประเทศในฟีดระดับทวีปแยกกัน หากฟีด GTFS ครอบคลุมพื้นที่ที่ใหญ่กว่าประเทศ โปรดติดต่อทีมการเดินทาง
  • ไฟล์ภายในไฟล์ GTFS ZIP ควรมีขนาดไม่เกิน 4 GB โดยปกติแล้ว ไฟล์ที่มีขนาดใหญ่กว่านี้มักเป็นสัญญาณของแนวทางปฏิบัติที่ไม่ดี เช่น การไม่สนใจตัวเลือกการบีบอัดที่frequencies.txt หรือฟีเจอร์ที่คล้ายกันมีให้ ซึ่งอาจทำให้เกิดปัญหาในระหว่างการประมวลผล หากคิดว่าคุณต้องการไฟล์ที่มีขนาดใหญ่กว่า 4 GB โปรดติดต่อทีม Travel Transport ที่ [e-mail]
  • ควรระบุข้อมูลสำหรับระยะเวลาการดำเนินงานในอนาคตทั้งหมดของบริการภายในฟีด GTFS พร้อมกับการอัปเดตข้อมูล GTFS แต่ละครั้ง เราไม่อนุญาตให้แบ่งกลุ่ม บริการตามระยะเวลาที่ต่างกัน
• วันที่ทั้งหมดสำหรับผู้ให้บริการรายหนึ่งๆ ต้องอยู่ในฟีดเดียว

คำแปล

• คุณสามารถใช้ translations.txt เพื่อแปลภาษาได้ และจะต้องแปลภาษาในประเทศที่มีเงื่อนไขต่อไปนี้
  • ระบบอาจให้ข้อมูลแก่ผู้ใช้ในสคริปต์ต่างๆ หรือในสคริปต์ ที่ไม่ใช่ละติน
  • ข้อมูลแก่ผู้ใช้อาจมีให้ในหลายภาษา หรือในกรณีที่ หน่วยงานอาจใช้การตั้งชื่อที่แตกต่างกันในภาษาเหล่านั้น (เช่น Brussels/Brussel/Bruxelles)
• เอนทิตีที่จะแปล
  • ชื่อเอเจนซี/ป้ายจอดรถ/เส้นทาง
  • ป้ายหน้ารถ/ป้ายหยุดรถ

ชื่อเส้นทาง ชื่อย่อของการเดินทาง และป้ายหน้ารถ

• ต้องระบุป้ายหน้ารถสำหรับการเดินทางทั้งหมดใน trips.txt (หากป้ายหน้ารถยังคงเหมือนเดิมตลอดการเดินทาง) หรือใน stop_times.txt (หากป้ายหน้ารถเปลี่ยนไปในระหว่างการเดินทาง ในระยะต่างๆ)
• ป้ายเหนือศีรษะควรตรงกับข้อมูลที่ผู้ใช้อาจเห็นบนพื้น เช่น ป้ายหน้ารถที่แสดงบนยานพาหนะหรือบนป้าย
• เมื่อเส้นทางมีชื่อ จะต้องระบุเป็น long_name ใน routes.txt
• เมื่อเส้นทางมีตัวระบุที่เป็นตัวเลขหรือตัวอักษรและตัวเลขที่เฉพาะเจาะจงซึ่งใช้กับ การเดินทางทั้งหมดในเส้นทางนั้นและทั้ง 2 ทิศทาง จะต้องระบุเป็น short_name ใน routes.txt
• เมื่อการเดินทางภายในเส้นทางมีตัวระบุแต่ละรายการ (เช่น หมายเลขรถไฟ) คุณต้องระบุตัวระบุดังกล่าวเป็นชื่อย่อของการเดินทาง
• สำหรับบริการระยะไกลที่ไม่มีหมายเลขหรือชื่อเส้นทาง การเลือกชื่อเส้นทางจะกลายเป็นปัญหา หลักเกณฑ์ทั่วไปในสถานการณ์เช่นนี้ คือการใช้ชื่อเส้นทางร่วมกับป้ายหน้ารถจะช่วยให้ ผู้ใช้ระบุยานพาหนะได้อย่างชัดเจน เช่น อาจใช้ชื่อของ หน่วยงานที่ดำเนินการเป็นชื่อเส้นทาง ขณะที่ปลายทางของ การเดินทาง (หากแสดงในยานพาหนะ) ควรใช้เป็นป้ายหน้ารถของการเดินทาง

ตัวอย่าง

• รถไฟด่วนกมายานีของทางรถไฟอินเดีย หมายเลข 11071 จากมุมไบไปพาราณสี หมายเหตุ: หมายเลข 11071 ระบุการเดินทางด้วยรถไฟจากมุมไบไปยังพาราณสี ไม่ใช่ เส้นทางเอง
  • routes.txt:
    • short_name: <empty>
    • long_name: Kamayani Express
  • trips.txt:
    • trip_short_name: 11071
    • ป้ายหน้ารถ: พาราณสี
• รถประจำทางจากบัวโนสไอเรสไปกอร์โดบาที่ดำเนินการโดย Chevallier Bus หมายเหตุ: รถประจำทาง ที่ให้บริการนี้จะไม่แสดงชื่อเส้นทางที่เฉพาะเจาะจง แต่จะแสดงชื่อของเอเจนซีที่ดำเนินการและปลายทางอย่างชัดเจนแทน การเดินทางนี้ไม่มีหมายเลข/ตัวระบุเฉพาะที่แยกความแตกต่างจากการเดินทางอื่นๆ ที่ดำเนินการโดยเอเจนซีเดียวกันหรือให้บริการในเส้นทางเดียวกัน ในกรณีนี้ คุณสามารถใช้ "Chevallier" เป็นทั้งชื่อเอเจนซี (ใน agencies.txt) และ long_name ของเส้นทาง (ใน routes.txt) ได้ ควรใช้ปลายทาง สำหรับป้ายหน้ารถ ส่วน trip_short_name ควรปล่อยว่างไว้
  • routes.txt:
    • short_name: <empty>
    • long_name: Chevallier
  • trips.txt:
    • trip_short_name: <empty>
    • ป้ายหน้ารถ: Córdoba

เวลาสิ้นสุด

ต้องระบุทั้ง arrival_time และ departure_time ใน stop_times.txt

โครงสร้างการเดินทาง

• การเดินทางระยะไกลที่ให้บริการในหลายเมือง/พื้นที่ควรระบุตั้งแต่ต้นจนจบโดยไม่มีการแบ่งส่วน (เช่น A->B->C ไม่ใช่ [A->B,A->C,B->C]) โดยที่ A, B, C คือพื้นที่ในเมือง ตัวอย่างเช่น รถบัสระยะไกลที่เดินทางจาก บัวโนสไอเรสไปยังกอร์โดบา โดยมีจุดจอดในโรซาริโอ ควรแสดงเป็นการ เดินทางที่มีจุดจอดใน 3 เมืองนี้ ไม่ใช่เป็นการเดินทาง 3 รายการ "บัวโนสไอเรส - โรซาริโอ" "บัวโนสไอเรส - กอร์โดบา" และ "โรซาริโอ - กอร์โดบา"
• ในกรณีที่ผู้ให้บริการข้อมูลไม่สามารถรับข้อมูลเกี่ยวกับโครงสร้างการเดินทางที่ถูกต้อง เราอาจให้ข้อมูลการเดินทางแบบเมืองต่อเมืองที่แบ่งกลุ่มเป็นกรณีๆ ไป หากการเดินทางจากเมืองหนึ่งไปยังอีกเมืองหนึ่งมีจุดรับหรือจุดส่งหลายจุดภายในเมือง (พื้นที่เมือง) จะไม่อนุญาตให้แบ่งส่วนจากจุดหนึ่งไปยังอีกจุดหนึ่ง โดยควรระบุจุดรับทั้งหมดและจุดส่งทั้งหมดในการเดินทางครั้งเดียว

โครงสร้างสถานี

สำหรับสถานีขนาดใหญ่ที่มีชานชาลา/ช่องจอดหลายแห่ง คุณต้องระบุความสัมพันธ์ระหว่างสถานีกับชานชาลาในฟีด และต้องระบุช่องจอด/ชานชาลาที่เฉพาะเจาะจงผ่านฟิลด์ platform_code ใน stops.txt ยานพาหนะที่ออกเดินทางหรือมาถึงชานชาลาหรือท่าจอดรถที่เฉพาะเจาะจงอย่างสม่ำเสมอควรลิงก์กับชานชาลาหรือท่าจอดรถนั้นในฟีด GTFS หากชานชาลาหรือช่องจอดรถขาออกหรือขาเข้ามีการเปลี่ยนแปลงในวัน/เวลาออกเดินทางที่ต่างกัน คุณสามารถระบุข้อมูลนี้ใน GTFS แบบเรียลไทม์ ได้

ตำแหน่งสถานี/ป้ายจอดรถ

• สำหรับสถานีขนาดใหญ่ที่มีชานชาลาหรือช่องจอดหลายช่อง ควรตั้งค่าตำแหน่งของ สถานีเป็นตำแหน่งทางเข้าสำหรับคนเดินเท้าที่โดดเด่นที่สุด (หากสถานีมีอาคารหรือโครงสร้าง) หรือเป็นตำแหน่ง ของพื้นที่รอผู้โดยสาร (สำหรับสถานีกลางแจ้ง)
• สำหรับป้ายจอดรถขนาดเล็กที่อยู่ข้างถนน ควรตั้งค่าตำแหน่งของป้ายจอดรถเป็นตำแหน่งของเสารถประจำทางเมื่อระบุได้ เมื่อระบุเสารถประจำทางที่เฉพาะเจาะจงไม่ได้ คุณควรวางตำแหน่ง ไว้ที่ด้านที่ถูกต้องของถนน และภายในบริเวณใกล้เคียงกับตำแหน่งจริง ตามถนน (ควรอยู่ภายใน 10 ม.) ที่ยานพาหนะจอด

ส่วนขยาย GTFS เพิ่มเติม

จำเป็นสำหรับพาร์ทเนอร์ที่ต้องการแสดงข้อมูลราคา/ห้องว่างโดย ใช้ API ของพาร์ทเนอร์เท่านั้น

ส่วนขยายการจำหน่ายตั๋ว Google แผนการเดินทาง

• พาร์ทเนอร์ควรใช้ ข้อกำหนดเฉพาะของส่วนขยายการจำหน่ายตั๋ว Google แผนการเดินทาง ซึ่งเป็นส่วนย่อยของส่วนขยาย GTFS-Ticketing
• เรากำหนดข้อกำหนดต่อไปนี้สำหรับรหัสการออกตั๋ว
  • รหัสการออกตั๋วควรคงที่ (เช่น อนุญาตให้เปลี่ยนแปลงได้ไม่บ่อยนักด้วยเหตุผลที่สมควร) ในกรณีที่รหัสการออกตั๋วมีการเปลี่ยนแปลง คุณจะต้องมีความเข้ากันได้แบบย้อนหลัง (เป็นระยะเวลาขั้นต่ำอย่างน้อย 1 สัปดาห์)
  • หากต้องการกำหนดพารามิเตอร์ของ SegmentKey ในคำขอ API ticketing_trip_id (ใน trips.txt) และ ticketing_stop_id (ใน ticketing_identifiers.txt) ต้องระบุ stop_sequence ไม่รองรับการเปลี่ยนไปใช้เครือข่ายอื่นเนื่องจากไม่เสถียร

GTFS-Fares v1

การอ้างอิง GTFS แบบคงที่จะระบุไฟล์ fare_attributes.txt และ fare_rules.txt ที่ไม่บังคับ หากพาร์ทเนอร์ผสานรวมกับ API ของพาร์ทเนอร์ คุณไม่ควรระบุไฟล์เหล่านี้