الزامات GTFS

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

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

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

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

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

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

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

محدوده

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

ترجمه ها

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

نام مسیرها، نام‌های کوتاه سفر و نشانه‌ها

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

مثال ها

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

توقف زمان

در stop_times.txt هر دو ورود_time و departure_time باید ارائه شوند.

ساختار سفر

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

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

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

مکان های ایستگاه/ایستگاه

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

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

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

افزونه Google Transit Ticketing

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

GTFS-Fares v1

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