الزامات GTFS

شریک باید یک فید GTFS ارائه دهد که تمام مشخصات استاندارد، به علاوه موارد ذکر شده در زیر را داشته باشد. این فید باید تمام برنامه‌های سفری را که شریک می‌خواهد نمایش دهد، پوشش دهد. ارائه این اطلاعات، امکان نمایش اطلاعات برنامه و مسیر را در گوگل فراهم می‌کند. توجه داشته باشید که شریک می‌تواند در صورت تمایل، اطلاعات قیمت و موجودی اضافی را برای برخی یا تمام برنامه‌های سفر در فید ارائه شده نمایش دهد.

الزامات پیش‌فرض

مرجع ایستا GTFS - تمام الزامات پیش‌فرض اعمال می‌شوند.

بهترین شیوه‌های GTFS - لطفاً از بهترین شیوه‌ها طوری پیروی کنید که انگار الزامی هستند.

آپلود فیدهای GTFS - لطفاً این فرآیند را برای آپلود فید GTFS دنبال کنید.

به‌روزرسانی‌ها: توجه داشته باشید که پس از بارگذاری فیدها، می‌توان آن‌ها را طبق فرآیندی که در اینجا توضیح داده شده است، به‌روزرسانی کرد. به‌طورکلی، انتشار کامل این به‌روزرسانی‌های فید می‌تواند ۲ تا ۳ روز طول بکشد.

الزامات اضافی

محدوده

  • یک فید GTFS واحد باید یک کشور یا بخشی از یک کشور را پوشش دهد. سفرهایی که از مرزهای یک کشور عبور می‌کنند باید در فیدهای جداگانه در سطح قاره ارائه شوند. اگر یک فید GTFS چیزی بزرگتر از یک کشور را پوشش می‌دهد، لطفاً با تیم حمل و نقل مسافرتی تماس بگیرید.
    • فایل‌های درون فایل زیپ GTFS باید کوچکتر از ۴ گیگابایت باقی بمانند. فایل‌های بزرگتر از این معمولاً نشانه‌ای از رویه‌های نادرست هستند، مانند نادیده گرفتن گزینه‌های فشرده‌سازی ارائه شده توسط frequencies.txt یا ویژگی‌های مشابه. این ممکن است در حین پردازش مشکلاتی ایجاد کند. اگر فکر می‌کنید به فایل‌های بزرگتر از ۴ گیگابایت نیاز دارید، لطفاً با تیم Travel Transport از طریق transport-help@google.com تماس بگیرید.
    • داده‌های مربوط به کل دوره آتی عملکرد خدمات در یک فید GTFS باید با هر به‌روزرسانی داده‌های GTFS ارائه شود. تقسیم‌بندی خدمات بر اساس دوره‌های زمانی مختلف قابل قبول نیست.
  • تمام تاریخ‌های مربوط به یک اپراتور خاص باید در یک فید واحد قرار گیرند.

ترجمه‌ها

  • ترجمه‌ها می‌توانند با استفاده از translations.txt ارائه شوند و در کشورهایی که:
    • اطلاعات به کاربران ممکن است با خط‌های مختلف یا با خط‌هایی غیر از لاتین ارائه شود
    • اطلاعات به کاربران ممکن است به چندین زبان ارائه شود، یا در مواردی که نهادها ممکن است از نامگذاری‌های مختلفی در آن زبان‌ها استفاده کنند (مثلاً بروکسل/بروکسل/بروکسل)
  • موجودیت‌هایی که باید ترجمه شوند
    • نام آژانس/ایستگاه/مسیر
    • تابلوهای راهنمای سفر/ایست

نام مسیرها، نام‌های اختصاری سفر و تابلوهای راهنما

  • علائم راهنمایی و رانندگی باید برای همه سفرها یا در trips.txt (اگر علائم راهنمایی و رانندگی در طول سفر ثابت بماند) یا در stop_times.txt (اگر علائم راهنمایی و رانندگی در مراحل مختلف سفر تغییر کند) ارائه شوند.
  • تابلوهای راهنما باید با اطلاعاتی که کاربران ممکن است روی زمین پیدا کنند، مطابقت داشته باشند. به عنوان مثال، تابلوهای راهنما که روی وسیله نقلیه یا روی تابلوهای راهنما نمایش داده می‌شوند.
  • وقتی مسیری نام دارد، باید آن را به صورت long_name در routes.txt ارائه دهد.
  • وقتی یک مسیر دارای یک شماره یا شناسه الفبایی-عددی خاص است که برای همه سفرهای آن مسیر و در هر دو جهت اعمال می‌شود، باید به عنوان short_name در routes.txt ارائه شود.
  • وقتی سفرهای درون مسیر دارای شناسه‌های مجزا (مثلاً شماره قطار) هستند، چنین شناسه‌هایی باید به عنوان نام‌های کوتاه سفر ارائه شوند.
  • برای سرویس‌های مسافت طولانی که شماره یا نام مسیر ندارند، انتخاب نام مسیر مشکل‌ساز می‌شود. دستورالعمل کلی در چنین شرایطی این است که ترکیبی از نام مسیر و تابلوی راهنما باید به کاربر کمک کند تا وسیله نقلیه را به طور واضح شناسایی کند. به عنوان مثال، نام آژانس عامل می‌تواند به عنوان نام مسیر استفاده شود، در حالی که مقصد سفر (در صورت نمایش روی وسیله نقلیه) باید به عنوان تابلوی راهنمای سفر استفاده شود.

مثال‌ها

  • قطار سریع‌السیر کامایانی شماره ۱۱۰۷۱ راه‌آهن هند از بمبئی به بنارس. توجه: شماره ۱۱۰۷۱ یک سفر قطاری خاص از بمبئی به بنارس را مشخص می‌کند، نه خود مسیر.
    • مسیرها.txt:
      • short_name: <خالی>
      • long_name: کامایانی اکسپرس
    • سفرها.txt:
      • نام_کوتاه_سفر: ۱۱۰۷۱
      • نشان سر: واراناسی
  • اتوبوسی از بوئنوس آیرس به کوردوبا که توسط شرکت اتوبوسرانی Chevallier اداره می‌شود. توجه: اتوبوسی که این سرویس را ارائه می‌دهد، نام مسیر خاصی را نمایش نمی‌دهد. در عوض، نام آژانس عامل و مقصد آن را به طور برجسته نمایش می‌دهد. این سفر خاص شماره/شناسه جداگانه‌ای ندارد که آن را از سایر سفرهایی که توسط همان آژانس اداره می‌شوند یا در همان مسیر خدمات ارائه می‌دهند، متمایز کند. در این صورت، استفاده از "Chevallier" هم به عنوان نام آژانس (در agencies.txt ) و هم به عنوان long_name مسیر (در routes.txt ) قابل قبول است. مقصد باید برای علامت سر استفاده شود. trip_short_name باید خالی بماند.
    • مسیرها.txt:
      • short_name: <خالی>
      • نام طولانی: شوالیه
    • سفرها.txt:
      • نام کوتاه سفر: <خالی>
      • نشان سر: کوردوبا

زمان‌های توقف

هر دو پارامتر arrival_time و depart_time باید در stop_times.txt ارائه شوند.

ساختار سفر

  • سفرهای بین شهری که به چندین شهر/منطقه خدمات ارائه می‌دهند، باید به صورت سرتاسری و بدون تقسیم‌بندی ارائه شوند (مثلاً A->B->C نه [A->B,A->C,B->C])، که در آن A، B، C مناطق شهری هستند. به عنوان مثال، یک اتوبوس بین شهری که از بوئنوس آیرس به کوردوبا سفر می‌کند و در روزاریو توقف دارد، باید به عنوان یک سفر با توقف در این سه شهر نمایش داده شود، نه به عنوان سه سفر «بوئنوس آیرس - روزاریو»، «بوئنوس آیرس - کوردوبا» و «روزاریو - کوردوبا»
  • در مواردی که ارائه‌دهنده داده‌ها قادر به کسب اطلاعات در مورد ساختار صحیح سفر نباشد، سفرهای شهر به شهر ممکن است به صورت موردی و بخش‌بندی‌شده ارائه شوند. اگر چنین سفرهای شهر به شهری دارای چندین نقطه سوار یا پیاده شدن در یک شهر (منطقه شهری) باشند، بخش‌بندی ایستگاه به ایستگاه مجاز نیست - همه نقاط سوار و پیاده شدن باید در یک سفر واحد فهرست شوند.

سازه‌های ایستگاه

برای ایستگاه‌های بزرگ که چندین سکو/محل توقف دارند، روابط ایستگاه-سکو باید در فید مشخص شود و سکوها/محل‌های توقف خاص باید از طریق فیلد platform_code در stops.txt شناسایی شوند. وسایل نقلیه‌ای که به طور مداوم از یک سکوی توقف یا توقف خاص حرکت می‌کنند یا به آن می‌رسند، باید در فید GTFS به آن سکوی توقف یا توقف مرتبط شوند. اگر سکوی توقف یا توقف در روزها/زمان‌های مختلف حرکت تغییر کند، این اطلاعات را می‌توان به صورت آنی در GTFS ارائه داد.

مکان‌های ایستگاه/توقف

  • برای ایستگاه‌های بزرگ که دارای چندین سکو یا جایگاه هستند، مکان ایستگاه باید مطابق با برجسته‌ترین ورودی عابر پیاده (در صورتی که ایستگاه دارای ساختمان یا سازه باشد) یا مطابق با محل انتظار مسافر (برای ایستگاه‌های فضای باز) تنظیم شود.
  • برای ایستگاه‌های کوچک‌تر در کنار جاده، محل ایستگاه باید در محل تیرک اتوبوس، زمانی که قابل شناسایی باشد، تنظیم شود. هنگامی که یک تیرک اتوبوس خاص قابل شناسایی نباشد، محل باید در سمت صحیح جاده و در مجاورت محل واقعی در امتداد جاده (در حالت ایده‌آل، در فاصله ۱۰ متری) که وسیله نقلیه توقف می‌کند، قرار گیرد.

افزونه‌های اضافی GTFS

فقط برای شرکایی که می‌خواهند اطلاعات قیمت/موجودی را با پیاده‌سازی APIهای شریک منتشر کنند، الزامی است.

افزونه‌ی فروش بلیط گوگل ترنسلیت

  • شرکا باید مشخصات افزونه‌ی بلیط‌فروشی گوگل ترانزیت را که زیرمجموعه‌ای از افزونه‌ی GTFS-Ticketing است، پیاده‌سازی کنند.
  • ما الزامات زیر را برای شناسه‌های بلیط اعمال می‌کنیم:
    • شناسه‌های بلیط باید پایدار باشند (یعنی به دلایل موجه، به ندرت تغییر کنند). در مواردی که شناسه‌های بلیط تغییر می‌کنند، سازگاری با نسخه‌های قبلی الزامی خواهد بود (حداقل برای یک دوره ۱ هفته‌ای).
    • برای تعیین پارامترهای SegmentKey در درخواست‌های API، ticketing_trip_id (در trips.txt ) و ticketing_stop_id (در ticketing_identifiers.txt ) مورد نیاز هستند. جایگزین stop_sequence پشتیبانی نمی‌شود زیرا پایدار نیست.

GTFS-Fares نسخه ۱

مرجع Static GTFS فایل‌های اختیاری fare_attributes.txt و fare_rules.txt را مشخص می‌کند. اگر یک شریک با APIهای شریک ادغام شود، این فایل‌ها نباید ارائه شوند.