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

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

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

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

แนวทางปฏิบัติแนะนำ GTFS - ทำตามแนวทางปฏิบัติแนะนำ เหมือนที่จำเป็น

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

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

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

ขอบเขต

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

คำแปล

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

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

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

ตัวอย่าง

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

เวลาสิ้นสุด

ต้องระบุทั้งเวลาถึง [destinations_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
  • เรามีข้อกำหนดต่อไปนี้สำหรับรหัสการจำหน่ายตั๋ว
    • รหัสการจำหน่ายตั๋วควรคงที่ (เช่น เปลี่ยนได้ไม่บ่อยด้วยเหตุผลที่ดี) ในกรณีที่รหัสตั๋วเปลี่ยนแปลง คุณต้องระบุความเข้ากันได้แบบย้อนหลัง (เป็นระยะเวลาขั้นต่ำอย่างน้อย 1 สัปดาห์)
    • ในการกำหนดพารามิเตอร์ของ SegmentKey ในคำขอ API คุณต้องระบุ ticketing_trip_id (ใน trips.txt) และ ticketing_stop_id (ใน ticketing_identifiers.txt) ระบบได้ไม่รองรับวิดีโอสำรองของ stop_sequence เนื่องจากอุปกรณ์ไม่เสถียร

GTFS-ค่าโดยสาร v1

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