أفضل الممارسات المتعلّقة بـ GTFS

مواصفات الخلاصة العامة للنقل العام (GTFS)

هذه الممارسات مقترَحة لوصف خدمات النقل العام في مواصفات الخلاصة العامة للنقل العام (GTFS). تم تجميع هذه الممارسات من تجربة أعضاء مجموعة عمل أفضل ممارسات مواصفات الخلاصة العامة للنقل العام (GTFS) واقتراحات ممارسة مواصفات الخلاصة العامة للنقل العام (GTFS) الخاصة بالتطبيقات. ولمزيد من المعلومات الأساسية، يُرجى الاطّلاع على الأسئلة الشائعة.

بنية المستند

ويتم تنظيم الممارسات في ثلاثة أقسام أساسية:

الأسئلة الشائعة

ما هي أهمية أفضل ممارسات GTFS؟

أهداف أفضل ممارسات GTFS هي:

  • تحسين تجربة العملاء لدى المستخدمين في تطبيقات وسائل النقل العام
  • إتاحة إمكانية التشغيل التفاعلي للبيانات العامة لتسهيل على مطوّري البرامج نشر التطبيقات والمنتجات والخدمات وتوسيع نطاقها
  • تسهيل استخدام مواصفات الخلاصة العامة للنقل العام (GTFS) في فئات التطبيقات المختلفة (بخلاف التركيز الأساسي على التخطيط للرحلة)

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

وكيف تم تطويرها؟ من طوّر هذه الشخصيات؟

طوّرت مجموعة عمل من 17 مؤسسة تشارك في مواصفات الخلاصة العامة للنقل العام (GTFS) أفضل الممارسات هذه، بما في ذلك مزوّدو التطبيقات ومستهلكو البيانات ومقدّمو خدمات النقل العام والمستشارون الذين لديهم مشاركة شاملة في مواصفات الخلاصة العامة للنقل العام. تم عقد مجموعة العمل هذه وتسهيلها من خلال معهد جبل روكي.

صوّت أعضاء مجموعة العمل على كل واحدة من أفضل الممارسات. وقد تمت الموافقة على معظم أفضل الممارسات من خلال تصويت شهير. في حالات نادرة، تمت الموافقة على أفضل الممارسات من قِبل أغلب المؤسسات.

لماذا لا يتم تغيير مرجع GTFS فقط؟

هذا سؤال وجيه. وقد أدّت عملية فحص المواصفات واستخدام البيانات واحتياجاتها إلى حدوث بعض التغييرات في المواصفات (راجِع طلبات سحب البيانات المغلقة في GitHub). وتخضع تعديلات المواصفات المرجعية ل شريط تدقيق أعلى وتعليقات أفضل الممارسات. ومع ذلك، كانت هناك حاجة إلى الموافقة على مجموعة واضحة من اقتراحات "أفضل الممارسات".

تتوقّع مجموعة العمل أن تصبح بعض أفضل ممارسات مواصفات الخلاصة العامة للنقل العام (GTFS) جزءًا من مرجع "خدمات الخلاصة العامة للنقل العام" الأساسي.

هل تتحقّق أدوات التحقّق من مواصفات الخلاصة العامة للنقل العام (GTFS) من التوافق مع أفضل الممارسات هذه؟

ليست هناك أداة للتحقق من الصحة تعمل حاليًا على التحقق من توافق جميع أفضل الممارسات. وتتحقّق العديد من أدوات التحقّق من التوافق مع بعض أفضل الممارسات هذه. للاطّلاع على قائمة بأدوات التحقّق من مواصفات الخلاصة العامة للنقل العام (GTFS)، راجِع اختبار الخلاصات. إذا كتبت أداة للتحقق من صحة GTFS تشير إلى أفضل الممارسات هذه، يُرجى إرسال رسالة إلكترونية إلى gtfs@rmi.org.

أنا أمثل مؤسسة نقل عام. ما هي الخطوات التي يمكنني اتخاذها حتى يتّبع مورّدو خدمات البرامج والمورّدون أفضل الممارسات هذه؟

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

ما الذي يجب فعله إذا لاحظت أنّ خلاصة بيانات GTFS لا تتوافق مع أفضل الممارسات هذه؟

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

أريد اقتراح تعديل أو إضافة إلى أفضل الممارسات. كيف يمكنني إجراء هذا؟

يمكنك إرسال رسالة إلكترونية إلى gtfs@rmi.org أو فتح مشكلة أو سحب طلب في تقرير "أفضل ممارسات GTFS لأفضل الممارسات".

كيف يمكنني المشاركة؟

البريد الإلكتروني gtfs@rmi.org.

نشر مجموعة البيانات والممارسات العامة

الاقتراحات العامة
يجب نشر مجموعات البيانات على عنوان URL دائم ومتاح للجميع، بما في ذلك اسم ملف ZIP. (على سبيل المثال، www.agency.org/gtfs/gtfs.zip). من المفترض أن يكون عنوان URL قابلاً للتنزيل مباشرةً بدون الحاجة إلى تسجيل الدخول للوصول إلى الملف، وذلك لتسهيل التنزيل من خلال استخدام التطبيقات البرمجية. على الرغم من أنّه من المستحسن (وأكثر الممارسات شيوعًا) جعل مجموعة بيانات GTFS قابلة للتنزيل بشكل عام، إذا كان موفّر البيانات يحتاج إلى التحكم في الوصول إلى GTFS للترخيص أو لأسباب أخرى، ننصح بالتحكّم في الوصول إلى مجموعة بيانات GTFS باستخدام مفاتيح واجهة برمجة التطبيقات، والتي ستسهّل عمليات التنزيل التلقائية.
يتم نشر بيانات مواصفات الخلاصة العامة للنقل العام (GTFS) في تكرارات بحيث يحتوي ملف واحد في موقع ثابت دائمًا على أحدث وصف رسمي لخدمة النقل العام (أو الوكالات).
الاحتفاظ بالمعرّفات الدائمة (حقول المعرّف) في stop_id وroute_id وagency_id عند تكرار البيانات متى أمكن.
يجب أن تحتوي مجموعة بيانات GTFS واحدة على الخدمة الحالية والقادمة (تسمى أحيانًا مجموعة بيانات "مدمجة"). يمكن استخدام دالة الدمج في أداة النقل العام من Google لإنشاء مجموعة بيانات مدمجة من خلاصتَين مختلفتَين من مواصفات الخلاصة العامة للنقل العام (GTFS).
  • في أي وقت، يجب أن تكون مجموعة بيانات مواصفات الخلاصة العامة للنقل العام (GTFS) المنشورة صالحة لمدة 7 أيام على الأقل، ويُفضَّل أن يستمر التشغيل في الجدول الزمني على النحو المعتاد.
  • إن أمكن، يجب أن تغطي مجموعة بيانات مواصفات الخلاصة العامة للنقل العام (GTFS) لمدة 30 يومًا على الأقل من الخدمة.
إزالة الخدمات القديمة (التقاويم المنتهية الصلاحية) من الخلاصة.
إذا بدأ تعديل خدمة خلال 7 أيام أو أقل، اعرِض تغيير هذه الخدمة من خلال خلاصة GTFS-الوقت الفعلي (تنبيهات الخدمة أو إشعارات الرحلات) بدلاً من مجموعة بيانات GTFS الثابتة.
يجب إعداد خادم الويب الذي يستضيف بيانات GTFS للإبلاغ عن تاريخ تعديل الملف بشكل صحيح (راجع HTTP/1.1 - طلب التعليقات 2616، ضمن القسم 14.29).

الاقتراحات التدريبية المنظّمة حسب الملف

يعرض هذا القسم الممارسات المنظَّمة حسب الملف والحقل، بما يتوافق مع مرجع مواصفات الخلاصة العامة للنقل العام.

كل الملفات

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

وكالة txt.

اسم الحقل الإجراء المقترَح
agency_id يجب تضمينها، حتى إذا كانت هناك وكالة واحدة فقط في الخلاصة. (اطّلِع أيضًا على اقتراح بتضمين agency_id في routes.txt و fare_attributes.txt).
agency_lang يجب تضمينها.
agency_phone ويجب تضمينها ما لم يتوفّر رقم هاتف لخدمة العملاء هذا.
agency_email ويجب تضمينها ما لم يتوفّر عنوان بريد إلكتروني لخدمة العملاء هذه.
agency_fare_url يجب تضمينها ما لم تكن الوكالة معفاة تمامًا من الأسعار.

أمثلة:

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

stop.txt

اسم الحقل الإجراء المقترَح
stop_id إنّ المحطات التي تقع في مواقع جغرافية مختلفة (أي المواقع الجغرافية المختلفة والمحدّدة للمركبات) على الطرق المخصّصة للإيقاف، والتي يمكن تمييزها باللافتات أو الملاجئ أو غيرها من المعلومات العامة، التي تقع في زوايا مختلفة من الشارع أو تمثّل منشأة مختلفة للصعود إلى الطائرة، مثل منصة أو حافلة، حتى لو كانت قريبة من بعضها البعض.stop_id
stop_id هو معرّف داخلي لا يمكن عرضه للركّاب.
حافِظ على اتساق stop_id في المحطات نفسها على مستوى تكرارات البيانات (اطّلِع على نشر مجموعة البيانات والممارسات العامة).
stop_name يجب أن تتطابق السمة stop_name مع الاسم العلني للوكالة في محطة التوقّف أو المحطة أو منشأة الصعود إلى الطائرة، على سبيل المثال المحتوى المطبوع على جدول زمني و/أو المنشور على الإنترنت و/أو المقدّم في الموقع الجغرافي.
في حال عدم توفّر اسم للمحطة المنشورة، اتّبِع اصطلاحات التسمية نفسها في جميع أقسام الخلاصة.
تجنَّب استخدام الاختصارات باستثناء الأماكن التي غالبًا ما تُعرف باسم الاسم المختصر. يمكنك الاطّلاع على الاختصارات (رقم 2) ضمن كل الملفات.
قدِّم أسماء محطات توقف في حال استخدام الأحرف المختلطة، وذلك وفقًا للاصطلاحات المحلية، وذلك وفقًا لاقتراح جميع الحقول النصية الموجّهة للعملاء.
بشكل تلقائي، يجب ألا تحتوي السمة stop_name على كلمات عامة أو متكررة، مثل "محطة" أو "إيقاف"، لكن يُسمح باستخدام بعض حالات الأحرف.
  • عندما يكون جزءًا من الاسم (محطة الاتحاد، المحطة المركزية)
  • عندما تكون السمة stop_name عامة جدًا (على سبيل المثال، إذا كانت اسم المدينة). "المحطة" أو "محطة الدفع" أو كلمات أخرى تجعل المعنى واضحًا.
stop_lat وstop_lon يجب أن تكون مواقع الإيقاف دقيقة قدر الإمكان. يجب أن تحتوي مواقع الإيقاف على خطأ لا يزيد عن أربعة أمتار عند مقارنتها بموضع الإيقاف الفعلي.
ويجب وضع المواقع الجغرافية لمحطّات التوقّف بالقرب من الجانب الأيمن من الطريق حيث يصعد الراكب (أي إلى الجانب الأيمن من الشارع).
إذا تمّت مشاركة الموقع الجغرافي لمحطة توقّف في خلاصات بيانات منفصلة (أي أنّ وكالتَين تستخدمان محطّتَي التوقّف / مرفق الصعود نفسهما)، عليك الإشارة إلى أنّه تتمّ مشاركة محطّة التوقّف من خلال استخدام محطّتَي stop_lat وstop_lon نفسيهما بالضبط.
stop_code يجب تضمين السمة stop_code في مواصفات الخلاصة العامة للنقل العام (GTFS) في حال توفّر أرقام محطّة للركّاب أو معرّفات قصيرة.
parent_station وlocation_type تحتوي العديد من المحطات أو محطات الدفع على مرافق متعددة للصعود إلى الطائرة (حسب وسيلة النقل، وقد يُطلق عليها اسم "خليج الحافلات" أو المنصة أو الرصيف أو البوابة أو غيرها من العبارات). وفي هذه الحالات، يجب أن يصف منتجو الخلاصات المحطات ومرافق الصعود إلى الطائرة (التي تُعرف أيضًا باسم محطات توقّف الأطفال) وعلاقتها.
  • يجب تحديد المحطة أو الوحدة الطرفية كسجلّ في stops.txt باستخدام location_type = 1.
  • ويجب تحديد كل منشأة لصعود الطائرة كمحطة مع location_type = 0 . ويجب أن يشير الحقل parent_station إلى stop_id للمحطة التي يقع فيها مرفق الصعود إلى الطائرة.
عند تسمية المحطة والطفل، توقف عن تعيين أسماء معروفة للركّاب ويمكن أن تساعد الراكبين في تحديد المحطة ومنشأة الصعود على متن الطائرة (خليج الحافلة والمنصة والرصيف وما إلى ذلك).
اسم المحطة الرئيسية اسم محطة توقُّف الطفل
محطة شيكاغو يونيون المنصة 19 لمحطة شيكاغو
محطة عبّارات سان فرانسيسكو بوابة محطة عبّارات سان فرانسيسكو
مركز النقل العام في وسط المدينة وسط مدينة الخليج (ب) في وسط المدينة

المسارات.txt

اسم الحقل الإجراء المقترَح
agency_id يجب أن يتم تضمينها إذا تم تحديدها في agency.txt.
route_short_name يمكنك تضمين route_short_name في حال وجود تصنيف خدمة مختصر. ويجب أن يكون هذا الاسم هو اسم الراكب المعروف للخدمة الذي لا يزيد عن 12 حرفًا.
route_long_name التعريف الوارد في مرجع المواصفات: يُعد هذا الاسم أكثر وصفًا بشكل عام من route_short_name، وغالبًا ما يتضمّن وجهة المسار أو محطّته. يجب تحديد سمة واحدة على الأقل من route_short_name أو route_long_name أو ربما إذا كان ذلك مناسبًا. إذا لم يكن للمسار اسم طويل، يُرجى تحديد route_short_name واستخدام سلسلة فارغة كقيمة لهذا الحقل.

في ما يلي أمثلة على أنواع الأسماء الطويلة:

مسار أو طريق سفر أساسي
اسم المسار النموذج وكالة
"N"/"جودا" route_short_name/
route_long_name		 مني في سان فرانسيسكو
“6“/“ML King Jr Blvd” route_short_name/
route_long_name		 TriMet، في بورتلاند، أو
"6"/"الأمة - إيتوال" route_short_name/
route_long_name		 شهادة RATP في باريس في فرنسا
"U2"/ "Pankow – رولبين" route_short_name/
route_long_name		 BVG في برلين وألمانيا
وصف الخدمة
"حافلة منطقة هارتويل"
يجب ألا يحتوي route_long_name على route_short_name.
يجب تضمين التصنيف الكامل، بما في ذلك الهوية عن الخدمة، عند تعبئة route_long_name. أمثلة:
هوية الخدمة الإجراء المقترَح أمثلة
"MAX Light Rail"
TriMet في بورتلاند أوريغون		 يجب أن تتضمّن السمة route_long_name العلامة التجارية (MAX) وتصنيف المسار المحدّد. "MAX Red Line"
"MAX Blue Line"
"الذهاب في جولة سريعة"
مع شركة ABQ في مدينة ألبوكيركي في نيو مكسيكو		 يجب أن تتضمّن السمة route_long_name العلامة التجارية (رحلة سريعة) وتصنيف المسار المحدّد. "خط أحمر سريع للرحلات"
"الخط الأزرق للرحلات السريعة"
route_id يجب أن تشير كل الرحلات في مسار معيّن إلى النوع route_id نفسه.
  • يجب عدم فصل الاتجاهات المختلفة للمسار إلى قيم route_id مختلفة.
  • يجب ألّا يتم تقسيم النطاقات المختلفة لتشغيل المسار إلى قيم route_id مختلفة، أي أنّه لا يتم إنشاء سجلات مختلفة في routes.txt لخدمات "downdown AM" و"Downtown PM".
إذا كانت مجموعة المسارات تتضمّن فروعًا تحمل اسمًا مميزًا (مثل 1A و1B)، اتّبِع الاقتراحات في حالة مسار الفروع لتحديد route_short_name وroute_long_name.
route_color وroute_text_color يجب أن يكون هذا العنوان متّسقًا مع اللافتات والمعلومات المطبوعة على الإنترنت والمتعلّقة بالعملاء (وبالتالي لا يتم تضمينه في حال عدم توفّره في أماكن أخرى).

Trips.txt

  • الاطّلاع على الحالة الخاصة لمسارات التكرار: مسارات التكرار هي الحالات التي تبدأ فيها الرحلات وتنتهي عند نفس المحطة، على عكس المسارات الخطية التي تتضمن محطتين مختلفتين. ويجب وصف مسارات التكرار باتّباع ممارسات معيّنة. راجِع حالة مسار الجولة.
  • الاطّلاع على حالة خاصة لمسارات "لاسو": مسارات لاسو هي مزيج من أشكال هندسية دائرية ومتكرّرة تتنقل فيها المركبات بشكل متكرر لجزء فقط من المسار. يجب وصف مسارات Lasso باتّباع ممارسات معيّنة. اطّلِع على حالة مسار "لاسو".
اسم الحقل الإجراء المقترَح
trip_headsign لا تقدّم أسماء مسارات (متطابقة مع route_short_name وroute_long_name) في الحقلين trip_headsign أو stop_headsign.
يجب أن يحتوي على وجهة و/أو اتجاه و/أو نص تصنيف رحلة آخر ظاهر على عنوان المركبة ويمكن استخدامه للتمييز بين الرحلات في المسار. إنّ الهدف المتّبع مع معلومات الاتجاهات المعروضة على المركبة هو الهدف الأساسي والمحدّد لتحديد العناوين الرئيسية المقدَّمة في مجموعات بيانات مواصفات الخلاصة العامة للنقل العام (GTFS). ويجب تضمين المعلومات الأخرى فقط إذا لم تحدّد هذا الهدف الأساسي. إذا تغيّرت سماعات الرأس أثناء الرحلة، يمكنك إلغاء السمة trip_headsign باستخدام السمة stop_times.stop_headsign. في ما يلي اقتراحات لبعض الحالات المحتملة:
example_table:
وصف المسار الإجراء المقترَح
2 (أ). الوجهة فقط أدخِل وجهة المحطة، مثل "مركز النقل العام" أو "مركز مدينة بورتلاند" أو "شاطئ جانتزن".
2 (ب). الوجهات التي تحتوي على نقاط طريق <destination> عبر <waypoint> "طريق مرتفع عبر تشارينغ كروس": في حال تمت إزالة نقاط توجيه من عرض العنوان على الركّاب بعد مرور المركبة على نقاط الطريق هذه، استخدِم stop_times.stop_headsign لضبط رأس رأس معدَّل.
2ج. اسم مكان إقليمي مع محطات محلية إذا كانت هناك محطات متعددة داخل المدينة أو الحي المقصودة، استخدِم stop_times.stop_headsign بعد الوصول إلى المدينة الوجهة.
2D الاتجاهات فقط يمكنك الإشارة إلى استخدام عبارات مثل "شمالاً" أو "الوارد" أو "في اتجاه عقارب الساعة" أو اتجاهات مشابهة.
2- الاتجاهات مع الوجهة <direction> إلى <terterm name>، مثل "جنوبًا إلى الإسكندرية".
2 و- الاتجاهات مع الوجهة ونقاط الطريق <direction> عبر <waypoint> إلى <destination> ("شمالاً عبر شارينغ كروس" إلى "هايغيت")
لا تبدأ برأس رأس مع عبارة "إلى" أو "نحو".
direction_id إذا كانت الرحلات في خدمة مسار قبالة الاتجاهات، حدِّد هذه المجموعات من الرحلات مع الحقل direction_id باستخدام القيمتَين 0 و1.
تستخدم القيم 0 و1 بشكل متّسق في مجموعة البيانات، أي
  • إذا كان 1 = الصادر على المسار الأحمر، ثم 1 = العنوان الصادر على المسار الأخضر
  • إذا 1 = الشمال على الطريق X، ثم 1 = الشمال على الطريق Y
  • إذا كان 1 = في اتجاه عقارب الساعة على الطريق X ثم 1 = في اتجاه عقارب الساعة على المسار Y

إيقاف_أوقات.txt

مسارات التكرار: تتطلب مسارات التكرار اعتبارات stop_times خاصة. (راجِع ما يلي: حالة مسار التكرار)

اسم الحقل الإجراء المقترَح
pickup_type وdrop_off_type بالنسبة إلى الرحلات التي لا تحقّق أرباحًا، والتي لا تقدّم خدمة الركّاب، يجب وضع علامة عليها على أنّها pickup_type وقيمة drop_off_type تبلغ 1 لجميع صفوف stop_times.
بالنسبة إلى رحلات الأرباح، يجب وضع علامة pickup_type = 1 على النقاط (النقاط الداخلية) لمراقبة الأداء التشغيلي، وأماكن أخرى، مثل المرآب الذي لا يمكن لراكب الصعود إليه (بدون توفّر خدمة استلام الطلب) وdrop_off_type = 1 (لا تتوفّر محطة لمغادرة الطائرة).
timepoint يجب ملء الحقل timepoint. ويحدِّد السمة stop_times التي سيحاول عامل التشغيل التقيُّد بها (timepoint=1)، وأن أوقات التوقف الأخرى هي تقديرات (timepoint=0).
arrival_time وdeparture_time ويجب أن يحدّد الحقلان arrival_time وdeparture_time قيمًا زمنية عندما يكون ذلك ممكنًا، بما في ذلك الأوقات المقدّرة أو غير المقتطعة بين النقاط الزمنية.
stop_headsign

تلغي القيم stop_headsign القيم trip_headsign (في trips.txt). ويجب تقديم القيم stop_headsign عندما يتغيّر النص المعروض على عنوان الرأس أثناء الرحلة. ويُرجى العِلم أنّ قيم السمة stop_headsign لا "تتغيّر" في المحطات اللاحقة، وبالتالي يجب تكرار القيم إذا ظلّت علامة الرأس توقفًا. وبشكل عام، يجب أن تتوافق قيم رأس الصفحة أيضًا مع اللافتات في المحطات.

في الحالات الموضّحة في ما يلي، قد يضلّل الخط الجنوبي مأكولات العملاء لأنه لا يتم استخدامه في لافتات المحطة.
فِي نْيُويُورْكْ، لِمُغَادْرِتِينِ الْلِّي سَيُصْبِحْ فِي الْجَنُوبْ:
بالنسبة إلى stop_times.txt صف: استخدام القيمة stop_headsign:
إلى أن تصل إلى مانهاتن Manhattan & Brooklyn
حتى يتم الوصول إلى وسط المدينة Downtown & Brooklyn
حتى يتم بلوغ بروكلين Brooklyn
بمجرد الوصول إلى بروكلين Brooklyn (New Lots Av)
في بوسطن، بالنسبة إلى الخط الأحمر المتوجّه إلى الجنوب، بالنسبة إلى فرع "براينتري":
بالنسبة إلى stop_times.txt صف: استخدام القيمة stop_headsign:
حتى يتم الوصول إلى وسط المدينة Inbound to Braintree
عند الوصول إلى وسط المدينة Braintree
بعد وسط المدينة Outbound to Braintree
form_dist_traveled يجب توفير السمة shape_dist_traveled للمسارات التي لها تكرار أو مضمّنة (تعبر المركبة أو تقطع الجزء نفسه من المحاذاة في رحلة واحدة). اطّلِع على اقتراح shapes.shape_dist_traveled.

calendar.txt

اسم الحقل الإجراء المقترَح
جميع الحقول يجب أن يحتوي calendar_dates.txt على عدد محدود من الاستثناءات للجدول الزمني. يجب إعداد الخدمة المجدوَلة بانتظام باستخدام calendar.txt.
ويمكن أن يؤدي تضمين الحقل calendar.service_name أيضًا إلى زيادة سهولة قراءة محتوى GTFS، إلا أن ذلك لا يتم اعتماده في المواصفات.

calendar_dates.txt

اسم الحقل الإجراء المقترَح
جميع الحقول يجب أن يحتوي calendar_dates.txt على عدد محدود من الاستثناءات للجدول الزمني. يجب إعداد الخدمة المجدوَلة بانتظام باستخدام calendar.txt.
ويمكن أن يؤدي تضمين الحقل calendar.service_name أيضًا إلى زيادة سهولة قراءة محتوى GTFS، إلا أن ذلك لا يتم اعتماده في المواصفات.

price_attributes.txt

اسم الحقل الإجراء المقترَح
جميع الحقول يجب تضمين السمة agency_id في fare_attributes.txt إذا كان الحقل مضمّنًا في agency.txt.
إذا تعذّر وضع نموذج لنظام دقيق، تجنّب أي التباس و اتركه فارغًا.
يجب تضمين الأسعار (fare_attributes.txt وfare_rules.txt) ووضع نماذج لها بدقة قدر الإمكان. وفي الحالات الحادة التي لا يمكن فيها وضع نماذج الأسعار بدقة، يجب تمثيلها على أنّها أكثر تكلفة وليست أقل تكلفة، بحيث لا يحاول العملاء الصعود إلى الطائرة بدون سعر كافٍ. إذا تعذّر وضع نماذج للغالبية العظمى من الأسعار بشكل صحيح، يُرجى عدم تضمين معلومات الأسعار في الخلاصة.

transaction_rule.txt

اسم الحقل الإجراء المقترَح
جميع الحقول يجب تضمين السمة agency_id في fare_attributes.txt إذا كان الحقل مضمّنًا في agency.txt.
إذا تعذّر وضع نموذج لنظام دقيق، تجنّب أي التباس و اتركه فارغًا.
يجب تضمين الأسعار (fare_attributes.txt وfare_rules.txt) ووضع نماذج لها بدقة قدر الإمكان. وفي الحالات الحادة التي لا يمكن فيها وضع نماذج الأسعار بدقة، يجب تمثيلها على أنّها أكثر تكلفة وليست أقل تكلفة، بحيث لا يحاول العملاء الصعود إلى الطائرة بدون سعر كافٍ. إذا تعذّر وضع نماذج للغالبية العظمى من الأسعار بشكل صحيح، يُرجى عدم تضمين معلومات الأسعار في الخلاصة.

أشكال ملفات.txt

اسم الحقل الإجراء المقترَح
جميع الحقول ومن الناحية المثالية، بالنسبة إلى المحاذاة التي تتم مشاركتها (أي في الحالات التي يعمل فيها المساران 1 و2 على الجزء نفسه من الطريق أو المسار)، يجب أن يتطابق الجزء المشترك من المحاذاة تمامًا. يساعد ذلك في تسهيل عملية رسم خرائط النقل العام العالية الجودة.
يجب أن تتبع المحاذاة خط المنتصف على يمين الطريق الذي تنتقل إليه المركبة. يمكن أن يكون هذا الخط هو وسط الشارع إذا لم تكن هناك ممرات محدّدة، أو خط المنتصف على جانب الطريق الذي يتحرك في الاتجاه الذي تتحرك فيه المركبة.

يجب ألا "تضبط" الطرقات على نقطة رصيف أو محطة أو موقع صعود الطائرة.
shape_dist_traveled

يجب توفير السمة في كل من السمتَين shapes.txt وstop_times.txt إذا كانت المحاذاة تتضمن تكرارًا أو مضمّنًا (المركبة التي تتقاطع أو تنتقل فوق الجزء نفسه من المحاذاة في رحلة واحدة).

مسار مضمّن

إذا كانت المركبة تسير في تقاطع المسار أو تتقاطع معه عند انعقاد نقاط خلال رحلة، shape_dist_traveled من المهم توضيح كيفية ارتباط أجزاء النقاط في shapes.txt بالسجلات في stop_times.txt.

أمّا في الحقل shape_dist_traveled، فهو يسمح للوكالة بتحديد الطريقة التي تتناسب بها محطّة الملف في stop_times.txt مع الشكل المناسب لها. وهناك قيمة شائعة يمكن استخدامها في الحقل shape_dist_traveled، وهي المسافة التي تفصل بين بداية المركبة انطلاقًا من المسافة التي قطعتها المركبة (مثلاً، قراءة عداد المسافة).
  • يجب أن تكون محاذاة المسار (في shapes.txt) على بُعد 100 متر من مواقع التوقّف التي يتم عرض الرحلة فيها.
  • عليك تبسيط المحاذاة بحيث لا يحتوي shapes.txt على نقاط غير ضرورية (أي إزالة النقاط الإضافية على الأجزاء المستقيمة). راجِع مناقشة مشكلة تبسيط الخطوط.

Feed_info.txt

يجب تضمين feed_info.txt، مع جميع الحقول أدناه.

اسم الحقل الإجراء المقترَح
feed_start_date وfeed_end_date يجب تضمينها
feed_version يجب تضمينها
feed_contact_email وfeed_contact_url يُرجى إدخال إجابة واحدة على الأقل.

الترددات.txt

اسم الحقل الإجراء المقترَح
جميع الحقول يتم تجاهل أوقات التوقّف الفعلية للرحلات التي أشار إليها frequencies.txt، مع العلم أنّ الفواصل الزمنية للرحلات بين محطات التوقف فقط هي مهمة. للتوضيح/سهولة القراءة بالنسبة إلى المستخدمين، ننصح بأن تبدأ وقت الإيقاف الأول للرحلة المُشار إليها في frequencies.txt في تمام الساعة 00:00:00 (القيمة arrival_time الأولى من 00:00:00).
block_id يمكن توفيرها للرحلات المستندة إلى التردد.

يجري ملف ads.txt

يمكن أن تكون السمة transfers.transfer_type إحدى القيم الأربع المحدّدة في مواصفات الخلاصة العامة للنقل العام (GTFS). ويمكن اقتباس تعريفات transfer_type هذه من مواصفات مواصفات الخلاصة العامة للنقل العام (GTFS) أدناه، مع اقتراحات تدريب إضافية.

اسم الحقل الإجراء المقترَح
transfer_type 0 أو (فارغ): تُعدّ هذه نقطة نقل مقترَحة بين المسارات.

إذا كانت تتوفّر عدة فرص نقل تتضمّن خيارًا ممتازًا (مثل مركز نقل عام فيه وسائل راحة إضافية أو محطة تتضمّن مرافق/منصات قريبة أو متصلة)، يمكنك تحديد نقطة نقل مُقترَحة.
1: هذه نقطة نقل محدَّدة زمنيًا بين مسارَين. ويُتوقّع أن تنتظر المركبة المغادرة عند وصول الرحلة، مع توفير وقت كافٍ لنقل الراكب بين المسارات.

ويحتسب كل مستهلك بيانات المدة الزمنية التي يحتاجها هذا الفاصل الزمني من خلال خوارزميته الخاصة. إذا كانت هذه القيمة غير كافية، أو إذا كانت هناك شروط أخرى لم يأخذها المستهلك في الاعتبار، يمكنك إلغاء العمليات الحسابية المتعلّقة بالوقت بعد ضبط السمة transfer_type على 2 وتحديد الحد الأدنى بالثواني للمدّة الزمنية المسموح بها في min_transfer_time.
2: تتطلّب عملية النقل هذه الحد الأدنى من الوقت بين الوصول والمغادرة لضمان الاتصال. يتم تحديد الوقت المطلوب للنقل من قِبل min_transfer_time.

تحدّد الحد الأدنى لمدة النقل إذا كانت هناك عوائق أو عوامل أخرى تزيد من وقت التنقّل بين المحطات.
3: لا يمكن استخدام وسائل النقل بين المسارات في هذا الموقع الجغرافي.

حدِّد هذه القيمة إذا تعذّر إجراء عمليات النقل بسبب العوائق الجسدية، أو إذا كانت غير آمنة أو معقدة بسبب عبور الطرقات الصعبة أو فجوات في شبكة المشاة.
إذا تم السماح بعمليات النقل بين المقاعد (الحظر) بين الرحلات، يجب أن تكون المحطة الأخيرة من رحلة الوصول هي نفسها المحطة الأولى من رحلة المغادرة.

الاقتراحات التدريبية المنظّمة حسب الحالة

يتناول هذا القسم بعض الحالات مع آثار على الملفات والحقول.

مسارات التكرار

في مسارات التكرار، تبدأ رحلات المركبات وتنتهي في الموقع الجغرافي نفسه (أحيانًا مركز نقل عام أو نقل عام). تعمل المركبات عادةً بشكل مستمر وتتيح للركّاب البقاء على متنها فيما تستمر المركبة في التكرار.

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

لذلك، يجب تطبيق اقتراحات الرأس من أجل عرض اتّجاه الرحلات على الطريق.

للإشارة إلى اتجاه السفر المتغيّر، قدِّم stop_headsigns في ملف stop_times.txt. يصف stop_headsign اتجاه الرحلات المغادرة من المحطة التي تم تحديدها لها. تتيح لك إضافة stop_headsigns في كل محطة توقّف تغيير معلومات رأس الصفحة على طول الرحلة.

لا تحدّد رحلة دائرية واحدة في ملف stop_times.txt للمسار الذي يعمل بين نقطتَي نهاية (مثلاً، عند ذهاب الحافلة ذهابًا وإيابًا). وبدلاً من ذلك، قسِّم الرحلة إلى اتجاهين منفصلين للرحلة.

أمثلة على وضع نماذج للرحلات الدائرية:

جولة دائرية مع تغيير رأس كل محطة:

Trip_id arrival_time departure_time stop_id stop_sequence stop_headsign
trip_1 06:10:00 06:10:00 stop_A 1 "ب"
trip_1 06:15:00 06:15:00 stop_B 2 "ج"
trip_1 06:20:00 06:20:00 stop_C 3 "D"
trip_1 06:25:00 06:25:00 stop_D 4 "هـ"
trip_1 06:30:00 06:30:00 stop_E 5 "أ"
trip_1 06:35:00 06:35:00 stop_A 6 "

رحلة دائرية برأسين رأسيين:

Trip_id arrival_time departure_time stop_id stop_sequence stop_headsign
trip_1 06:10:00 06:10:00 stop_A 1 "صادر"
trip_1 06:15:00 06:15:00 stop_B 2 "صادر"
trip_1 06:20:00 06:20:00 stop_C 3 "صادر"
trip_1 06:25:00 06:25:00 stop_D 4 "الواردة"
trip_1 06:30:00 06:30:00 stop_E 5 "الواردة"
trip_1 06:35:00 06:35:00 stop_F 6 "الواردة"
trip_1 06:40:00 06:40:00 stop_A 7 "
اسم الحقل الإجراء المقترَح
trips.trip_id يمكنك تصميم نموذج ذهاب وعودة كامل للحلقة برحلة واحدة.
stop_times.stop_id أدرِج المحطة الأولى/الأخيرة مرتين في stop_times.txt للرحلة المتكرّرة. مثال أدناه. غالبًا ما يتضمّن المسار الدائري الرحلات الأولى والأخيرة التي لا تسافر في الحلقة بأكملها. ويمكنك تضمين هذه الرحلات أيضًا.
trip_id stop_id stop_sequence
9000 101 1
9000 102 2
9000 103 3
9000 101 4
trips.direction_id إذا كانت الحلقة تعمل في اتجاهين معاكسَين (أي في اتجاه عقارب الساعة عكس اتجاه عقارب الساعة)، حدِّد direction_id على أنّها 0 أو 1.
trips.block_id الإشارة إلى الرحلات المتكرّرة باستخدام السمة block_id نفسها

مسارات لاسو

تجمع مسارات لاسو بين جوانب مسار دائري ومسار اتجاهي.

أسفل ما يلي: مسارات "لاسو" هي مسارات متكرّرة من "أ" إلى "أ" من خلال ثلاثة أقسام:
  • مستقيمًا من "أ" إلى "ب"
  • تكرار من وإلى "ب"
  • مستقيمًا من
مسار لاسو
أمثلة:
مسارات مترو الأنفاق (شيكاغو)
ضاحية للحافلات إلى مسارات وسط المدينة (سانت ألبرت أو إدمونتون)
CTA Brown Line (الموقع الإلكتروني للحثّ على اتخاذ إجراء وخلاصات النقل العام)
اسم الحقل الإجراء المقترَح
trips.trip_id يتألف النطاق الكامل من "تذكرة ذهاب وعودة للمركبة" (راجِع الرسم التوضيحي أعلاه) من السفر من "أ" إلى "ب" ثم إلى "أ". يمكن إظهار رحلة ذهاب وعودة للمركبة بالكامل من خلال:
  • قيمة/سجلّ trip_id واحد في trips.txt
  • عدّة trip_id قيم/سجلّات باللغة trips.txt، مع تحديد السفر المستمر حسب block_id
    		•
    stop_times.stop_headsign سيتم تمرير المحطات على طول القسم أ-ب في كلا الاتجاهين. تسهّل السمة stop_headsign اتجاه السفر. لذلك، ننصح بتقديم stop_headsign لهذه الرحلات.
    أمثلة:
    "A عبر B"
    "أ"
    خط أرجواني لهيئة النقل العام في شيكاغو
    "جنوبًا إلى حلقة"
    "شمالاً عبر حلقة"
    "شمالاً إلى ليندن"
    خطوط حافلات النقل العام في "إدمونتون" هنا، 39
    "روثفورد"
    "متنزّه سنتري"
    trip.trip_headsign يجب أن يكون عنوان الرأس للرحلة وصفًا عالميًا للرحلة، كما هو معروض في الجداول الزمنية. يمكن أن تكون القيمة "ليندن إلى ليندن من خلال التكرار" (مثال على طريقة شيكاغو) أو "أ إلى أ من ب" (مثال عام).

    أغصان

    قد تتضمن بعض المسارات أغصان. تتم مشاركة المحاذاة ومحطات التوقف بين هذه الفرع، ولكن كل منها يعرض أيضًا محطات وأقسام محاذاة مختلفة. يمكن الإشارة إلى العلاقة بين الفرعين من خلال أسماء المسارات ورؤوس الرأس والاسم المختصر للرحلة، وذلك باستخدام الإرشادات الإضافية أدناه.

    أدناه: ثلاث إعدادات محتملة لفروع المسارات. المحاذاة الأساسية باللون الأسود. غصن زهري ملون.
    إعدادات فروع المسار
    اسم الحقل الإجراء المقترَح
    جميع الحقول في مسارات التسمية الفرعية، ننصح باتّباع مواد أخرى لمعلومات الركّاب. في ما يلي أوصاف وأمثلة لحالتين:
    إذا كانت الجداول الزمنية واللافتات في الشارع تمثّل مسارَين يحملان اسمًا مميزًا (مثل 1A و1B)، يجب عرضهما على النحو التالي في GTFS، باستخدام حقلي route_short_name و/أو route_long_name. على سبيل المثال: تتشارك المسارات مثل 2 و2أ و2ب في منصّة جودهام ترانزيت محاذاة مشتركة في معظم المسار، ولكنها تختلف في عدة جوانب مختلفة.
    • الطريق 2 هو الخدمة الأساسية، وتعمل في معظم الساعات.
    • يتضمن المسار 2 انحرافًا في ليالي الشارع الرئيسي، أيام الأحد، والعطلات.
    • يعمل المساران 2A و2B خلال ساعات النهار من الاثنين إلى السبت.
    • يقدم المسار 2B محطات إضافية في انحراف مسار المحاذاة الذي تمت مشاركته.
    إذا كانت المعلومات التي تقدّمها الوكالة تصف الفرع بهذا المسار نفسه، استخدِم الحقول trips.trip_headsign و/أو stop_times.stop_headsign و/أو trips.trip_short_name. على سبيل المثال، ينتقل مسار GoTriangle 300 إلى مواقع جغرافية مختلفة حسب الوقت من اليوم. وخلال ساعات الذروة، تتم إضافة المزيد من الأرجل إلى المسار العادي لاستيعاب العاملين في المدينة ومغادرتها.

    لمحة عن هذا المستند

    الأهداف

    أهداف الحفاظ على أفضل ممارسات مواصفات الخلاصة العامة للنقل العام (GTFS) هي:

    • إتاحة إمكانية التشغيل التفاعلي لبيانات النقل العام بشكل أفضل
    • تحسين تجربة العملاء النهائيين في تطبيقات وسائل النقل العام
    • سهِّل على مطوّري البرامج نشر التطبيقات والمنتجات والخدمات وتوسيع نطاقها.
    • تسهيل استخدام مواصفات الخلاصة العامة للنقل العام (GTFS) في فئات التطبيقات المختلفة (بخلاف التركيز الأساسي على التخطيط للرحلة)

    كيفية اقتراح أفضل ممارسات "GTFS" المنشورة أو تعديلها

    تتطوّر تطبيقات GTFS وممارساته، لذا قد يحتاج هذا المستند إلى تعديل من حين لآخر. لاقتراح تعديل على هذا المستند، افتح طلبًا بالسحب في مستودع GTFS لأفضل الممارسات وشجِّع على إجراء التغيير. ويمكنك إرسال أي تعليقات عبر البريد الإلكتروني إلى specifications@mobilitydata.org.

    جارٍ الربط بهذا المستند

    يُرجى الربط هنا لتزويد منتجي الخلاصة بالإرشادات المتعلقة بصياغة بيانات GTFS بشكل صحيح. يحتوي كل اقتراح فردي على رابط إلى موضع ثابت. انقر على الاقتراح للحصول على عنوان URL لرابط الارتساء في الصفحة.

    إذا كان أحد التطبيقات التي تستخدم مواصفات الخلاصة العامة للنقل العام (GTFS) يقدم متطلبات أو اقتراحات بشأن ممارسات بيانات مواصفات الخلاصة العامة للنقل العام (GTFS) التي لم يتم وصفها هنا، ننصح بنشر مستند يتضمن هذه المتطلبات أو الاقتراحات يُكمِّل أفضل الممارسات الشائعة هذه.

    مجموعة عمل أفضل ممارسات GTFS

    شكّلت مجموعة Rocky Mountain Institute مجموعة عمل لأفضل الممارسات في GTFS في 2016-2017، وتضم مقدّمي خدمات نقل عام ومطوّري تطبيقات ومستشارين ومؤسسات أكاديمية في GTFS لتحديد الممارسات الشائعة والتوقعات المتعلقة ببيانات GTFS. يشمل أعضاء مجموعة العمل هذه ما يلي:

    اليوم، تحتفظ هذا المؤسسة بـ منظمة MobilityData الدولية.