متطلبات GTFS

يجب أن يقدّم الشريك خلاصة GTFS تستوفي جميع المواصفات المعايير، بالإضافة إلى تلك المذكورة أدناه. يجب أن تشمل هذه الخلاصة جميع برامج الرحلات التي يريد الشريك عرضها. سيؤدي توفير هذه المعلومات إلى عرض معلومات الجدول الزمني والمسار على Google. يُرجى العِلم أنّه بإمكان الشريك عرض معلومات إضافية حول السعر ومدى التوفّر لبعض برامج الرحلات أو كلها في الخلاصة المقدَّمة إذا أراد ذلك.

المتطلبات التلقائية

مرجع GTFS الثابت: يتم تطبيق جميع المتطلبات التلقائية.

أفضل ممارسات GTFS: يُرجى اتّباع أفضل الممارسات كما لو كانت مطلوبة.

تحميل خلاصات GTFS - يُرجى اتّباع هذه العملية لتحميل خلاصة GTFS.

التعديلات: يُرجى العِلم بأنّه بعد تحميل الخلاصات، يمكن تعديلها باتّباع العملية الموضّحة هنا. بشكل عام، قد يستغرق نشر تعديلات الخلاصة هذه بالكامل من يومين إلى 3 أيام.

متطلبات إضافية

النطاق

• يجب أن تشمل خلاصة GTFS واحدة بلدًا واحدًا أو جزءًا من بلد. يجب تقديم الرحلات التي تتجاوز حدود البلدان في خلاصات منفصلة على مستوى القارة. إذا كانت خلاصة GTFS تشمل مساحة أكبر من بلد معيّن، يُرجى التواصل مع فريق نقل السفر.
  • يجب ألا يزيد حجم الملفات المضمّنة في ملف GTFS عن 4 غيغابايت. وتُعتبر الملفات الأكبر من ذلك عادةً علامة على حدوث ممارسات سيئة، مثل تجاهل خيارات الضغط التي يوفّرها frequencies.txt أو الميزات المشابهة. قد يتسبب هذا في حدوث مشكلات أثناء المعالجة. وإذا كنت تعتقد أنك تحتاج إلى ملفات يزيد حجمها عن 4 غيغابايت، يُرجى التواصل مع فريق "نقل السفر" على عنوان البريد الإلكتروني [e-mail].
  • يجب توفير البيانات عن الفترة المستقبلية الكاملة لتشغيل الخدمات ضمن خلاصة GTFS. ولا يتم قبول تقسيم الخدمات حسب فترات زمنية مختلفة.
• يجب تضمين جميع التواريخ لعامل تشغيل معيّن في خلاصة واحدة.

الترجمات

• يمكن تقديم الترجمات عبر translations.txt، ويجب استخدامها في البلدان التي:
  • يمكن تقديم المعلومات للمستخدمين من خلال نصوص برمجية مختلفة، أو في نصوص برمجية غير اللاتينية
  • يمكن تقديم المعلومات للمستخدمين بلغات متعدّدة، أو حيث يمكن للكيانات استخدام أسماء مختلفة بتلك اللغات (على سبيل المثال: بروكسل/بروكسل/بروكسل).
• العناصر التي ستتم ترجمتها
  • أسماء الوكالات/التوقف/المسارات
  • إشارات الرحلة/التوقف

أسماء المسارات والأسماء المختصرة للرحلات وإشارات الرأس

• يجب توفير إشارات الرأس لجميع الرحلات إما في "trips.txt" (إذا بقيت إشارة الرأس ثابتة طوال الرحلة) أو في "stop_times.txt" (إذا تغيّرت إشارة الرأس خلال المراحل المختلفة من الرحلة).
• يجب أن تتطابق لافتات الرأس مع المعلومات التي قد يعثر عليها المستخدمون على الأرض. يشمل ذلك على سبيل المثال، لافتات الرأس المعروضة على المركبة أو على اللافتات.
• عندما يكون للمسار اسم، يجب تقديمه كـ long_name في routes.txt.
• عندما يكون للمسار رقم معيّن أو معرّف أبجدي رقمي ينطبق على جميع الرحلات على ذلك المسار وفي كلا الاتجاهَين، يجب تقديمه على أنّه الاسم Short_name في routes.txt.
• عندما يكون للرحلات ضمن المسار معرّفات فردية (على سبيل المثال، أرقام القطارات)، يجب تقديم هذه المعرّفات كأسماء مختصرة للرحلات.
• بالنسبة إلى خدمات المسافات الطويلة التي لا تحتوي على أرقام أو أسماء مسارات، يصبح اختيار اسم المسار مشكلة. المبدأ العام في مثل هذه المواقف هو أن الجمع بين اسم الطريق ولافتة الرأس ينبغي أن يساعد المستخدم في التعرف على المركبة بشكل واضح. على سبيل المثال، يمكن استخدام اسم الهيئة التشغيلية كاسم للمسار، بينما يجب استخدام وجهة الرحلة (إذا كانت ظاهرة على المركبة) كإشارة للرحلة.

أمثلة

• قطار "كامياني إكسبرس" للسكك الحديدية الهندية من مومباي إلى فاراناسي 11071. ملاحظة: يحدّد الرقم 11071 رحلة قطار معيّنة من مومباي إلى فاراناسي، وليس المسار نفسه.
  • routes.txt:
    • Short_name: <null>
    • long_name: Kamayani Express
  • trips.txt:
    • trip_short_name: 11071
    • لافتة الرأس: فاراناسي
• حافلة من "بوينس آيرس" إلى "قرطبة" بإدارة "حافلة تشيفالييه". ملاحظة: لا تعرض الحافلة التي تُشغّل هذه الخدمة اسم مسارًا محددًا. بدلاً من ذلك، يعرض بشكل بارز اسم وكالة التشغيل ووجهتها. لا تحتوي هذه الرحلة المحدّدة على رقم أو معرّف فردي يميّزها عن الرحلات الأخرى التي تديرها الوكالة نفسها أو التي تسلك المسار نفسه. في هذه الحالة، من المقبول استخدام "Chevallier" كاسم للوكالة (في agencies.txt) والمسار long_name (في routes.txt). ويجب استخدام الوجهة للعلامة الرئيسية. يجب أن يظلtrip_short_name فارغًا.
  • routes.txt:
    • Short_name: <null>
    • long_name: شيفالييه
  • trips.txt:
    • trip_short_name: <null>
    • لافتة الرأس: قرطبة

أوقات التوقف

يجب تقديم كل من وصول_وقت_المغادرة ووقت_المغادرة باللغة stop_times.txt.

بنية الرحلة

• يجب تقديم الرحلات البعيدة التي تخدم مدنًا/مناطق متعدّدة من البداية إلى النهاية بدون تقسيم (على سبيل المثال، أ->ب->ج وليس [أ->ب، أ->ج، ب->ج])، حيث تمثِّل "أ" و"ب" و"ج" مناطق مدن. على سبيل المثال، حافلة لمسافات طويلة تسافر من "بوينس آيرس" إلى "قرطبة" ومحطة في "روزاريو" يجب أن تكون رحلة تشمل محطات توقّف في هذه المدن الثلاث، وليس كثلاث رحلات "بينوس آيرس - روساريو" و"بوينس آيرس - قرطبة" و"روساريو - قرطبة"
• في الحالات التي يتعذّر فيها على مزود البيانات الحصول على المعلومات حول هيكل الرحلة الصحيح، يمكن تقديم رحلات مقسمة من مدينة إلى أخرى على أساس كل حالة على حدة. إذا كانت مثل هذه الرحلات من مدينة إلى أخرى تحتوي على عدة نقاط للالتقاء أو الإنزال داخل المدينة (منطقة المدينة)، لا يُسمح بتقسيم الرحلة إلى محطات توقّف، يجب إدراج جميع نقاط الاستلام وجميع نقاط التسليم في رحلة واحدة.

هياكل المحطات

بالنسبة إلى المحطات الكبيرة التي تحتوي على عدّة منصات/منصات، يجب تحديد العلاقات بين المنصّات والمحطات في الخلاصة، ويجب تحديد مساحات/منصات محدّدة من خلال الحقلplatform_code في stops.txt. يجب ربط المركبات التي تنطلق باستمرار من خليج أو منصة معيّنة بتلك الخليج أو المنصة في خلاصة GTFS. في حال تغيّرت منصة المغادرة/الوصول أو الخليج في أيام أو أوقات المغادرة المختلفة، يمكن تقديم هذه المعلومات في GTFS في الوقت الفعلي.

مواقع المحطات/المحطات

• بالنسبة إلى المحطات الكبيرة التي تحتوي على منصات أو خلجان متعددة، يجب ضبط موقع المحطة على موقع مدخل المشاة الأكثر بروزًا (إذا كانت المحطة تحتوي على مبنى أو مبنى) أو على موقع منطقة انتظار الركاب (للمحطات في الهواء الطلق).
• بالنسبة إلى المحطات الأصغر على جانب الطريق، يجب تعيين موقع المحطة على موقع عمود الحافلة عندما يمكن تحديد هويته. عندما يتعذر تحديد عمود حافل معين، يجب وضع الموقع على الجانب الصحيح من الطريق، وفي المنطقة المجاورة، الموقع الفعلي على طول الطريق (في غضون 10 أمتار) حيث تتوقف المركبة.

إضافات GTFS إضافية

هذا الإجراء مطلوب فقط للشركاء الذين يريدون عرض معلومات السعر/مدى التوفّر من خلال استخدام واجهات برمجة تطبيقات الشركاء.

إضافة Google Transit Ticketing

• على الشركاء تطبيق مواصفات إضافة تذاكر النقل العام في Google Transit، وهي مجموعة فرعية من إضافة GTFS-Ticketing.
• نفرض المتطلبات التالية على معرّفات التذاكر:
  • يجب أن تكون معرّفات التذاكر مستقرة (أي يُسمح لها بالتغيير بشكل غير منتظم لسبب وجيه). في الحالات التي تتغيّر فيها معرّفات التذاكر، يجب التوافق مع الأنظمة القديمة (لمدة لا تقلّ عن أسبوع واحد على الأقل).
  • لتحديد معلَمات segmentKey في طلبات واجهة برمجة التطبيقات، السمتان ticketing_trip_id (في trips.txt) وticketing_stop_id (في ticketing_identifiers.txt) مطلوبتان. إنّ الإجراء الاحتياطي على stop_sequence غير متاح لأنه غير ثابت.

الإصدار الأول من GTFS-Fares

يحدِّد مرجع GTFS الثابت ملفَّي fare_attributes.txt وfare_rules.txt الاختياريَين. في حال تكامل الشريك مع واجهات برمجة تطبيقات الشركاء، يجب عدم تقديم هذه الملفات.