متطلبات GTFS

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

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

مرجع مواصفات الخلاصة العامة للنقل العام (GTFS) الثابت: يتم تطبيق جميع المتطلبات التلقائية.

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

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

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

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

النطاق

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

الترجمات

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

أسماء الطرق والأسماء المختصرة للرحلات ولوحات الوجهات

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

أمثلة

• Indian Railways Kamayani Express Train 11071 from Mumbai to Varanasi. ملاحظة: يشير الرقم 11071 إلى رحلة قطار محدّدة من مومباي إلى فاراناسي، وليس إلى المسار نفسه.
  • routes.txt:
    • short_name: <empty>
    • long_name: Kamayani Express
  • trips.txt:
    • trip_short_name: 11071
    • headsign: Varanasi
• حافلة من بوينس آيرس إلى قرطبة تديرها شركة Chevallier Bus ملاحظة: لا يعرض الحافلة التي كانت تقدّم هذه الخدمة اسم مسار معيّن. ويعرض بدلاً من ذلك اسم الوكالة المشغّلة ووجهتها بشكل بارز. لا تتضمّن هذه الرحلة رقمًا أو معرّفًا فرديًا يميزها عن الرحلات الأخرى التي تديرها الوكالة نفسها أو التي تسلك المسار نفسه. في هذه الحالة، يمكن استخدام "Chevallier" كاسم الوكالة (في agencies.txt) واسم المسار long_name (في routes.txt). يجب استخدام الوجهة في headsign، ويجب أن يظل trip_short_name فارغًا.
  • routes.txt:
    • short_name: <empty>
    • long_name: Chevallier
  • trips.txt:
    • trip_short_name: <empty>
    • headsign: Córdoba

أوقات التوقف

يجب تقديم كلّ من arrival_time وdeparture_time بتنسيق stop_times.txt.

بنية الرحلة

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

بُنى المحطات

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

المواقع الجغرافية للمحطات

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

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

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

إضافة بيع التذاكر في Google Transit

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

الإصدار 1 من GTFS-Fares

يحدّد مرجع "مواصفات الخلاصة العامة غير المتغيّرة للنقل العام" الملفَّين الاختياريَّين fare_attributes.txt وfare_rules.txt. إذا كان أحد الشركاء يستخدم واجهات برمجة التطبيقات الخاصة بالشركاء، يجب عدم تقديم هذه الملفات.