GTFS Schedule में नियोजित परिवहन सेवा का विवरण होता है। GTFS Realtime, जिसे अक्सर GTFS-RT कहा जाता है, सेवा के अद्यतन जानकारी प्रदान करता है। GBFS साझा मोबिलिटी सेवाओं का वर्णन करता है, विशेषकर उनके स्टेशन और प्रकाशित स्ट्रीम के अनुसार उपलब्ध वाहन। अपना फॉर्मेट उस सवाल के आधार पर चुनें जो आपकी एप्लिकेशन हल करनी चाहिए।
ये फॉर्मेट डेटा को व्यवस्थित करते हैं; वे हर जगह इसका उपलब्ध होना या हर स्ट्रीम की गुणवत्ता की गारंटी नहीं देते।
नियोजित सेवा का प्रतिनिधित्व करने के लिए GTFS
एक GTFS Schedule सेट टेबल फ़ाइलों का संग्रह है जिसमें ऑपरेटर, स्टॉप, लाइनें, यात्राएं और उनके समय जैसे विवरण होते हैं। कैलेंडर से पता चलता है कि कौन से दिन सेवा प्रदान की जाती है। ये फाइलें पहचानकर्ताओं द्वारा जुड़ी होती हैं। GTFS Schedule संदर्भ.
यह उन सवालों का उत्तर देता है जैसे "यह स्टॉप कहाँ है?" या "इस सेवा के लिए कौन सा समय निर्धारित है?"। किसी समय-सारणी को समझने के लिए, आपको कैलेंडर और फाइलों के बीच के संबंधों को व्याख्यायित करना होगा।
केवल स्टॉप की सूची पढ़ना यात्राओं को पुनर्निर्मित करने के लिए पर्याप्त नहीं है। इसके विपरीत, एक स्टॉप की स्थिति बिना समय-सारणी दिखाए भी उपयोगी हो सकती है।
GTFS-RT सेवा की जानकारी को अपडेट करने के लिए
GTFS Realtime अपडेटेड यात्राओं, वाहन की स्थितियों और अलर्ट प्रदान कर सकता है। यात्रा अपडेट में सड़क पारगमन, परिवर्तन आदि शामिल हैं। स्ट्रीमिंग के लिए Protocol Buffers नामक संरचित सीरियलाइजेशन फॉर्मेट का उपयोग होता है। GTFS Realtime परिचय.
एक प्रदाता कुछ श्रेणियाँ प्रकाशित कर सकता है बिना सभी दूसरों के। एक पोजीशन स्ट्रीम का होना सभी स्टॉप के लिए अनुमानित समय की गारंटी नहीं देता।
इंटरफ़ेस के लिए, नियोजित यात्रा और अपडेटेड अनुमान को अलग करें। हमारा गाइड सैद्धांतिक और वास्तविक समय की समय-सारणी उपयोगकर्ता के दृष्टिकोण से यह अंतर समझाता है।
GBFS साझा मोबिलिटी के लिए
GBFS JSON स्ट्रीम का उपयोग साझा मोबिलिटी सेवा का वर्णन करने के लिए करता है। सिस्टम और संस्करण के हिसाब से, वे स्टेशन, उनकी स्थिति, वाहन और अन्य सेवा विशेषता प्रदान कर सकते हैं। दस्तावेज़ीकरण में विशेष रूप से स्टेशन की जानकारी और उपलब्धता की स्थिति होती है। GBFS दस्तावेज़ीकरण.
अपने एप्लिकेशन में निश्चित स्थानों को तेजी से बदलने वाली स्थितियों से अलग रखें। व्याख्या के दौरान फॉर्मेट का संस्करण और उपयुक्त टाइमस्टैम्प रखें।
एक उपलब्धता स्ट्रीम बुकिंग या अनलॉकिंग API नहीं है। यह सेवा की खोज में मदद करता है; किराया संबंधित सेवा द्वारा पूरा किया जाता है।
उपयोग मामले के अनुसार तुलना करें
| ज़रूरत | देखने के लिए फॉर्मेट |
|---|---|
| नियोजित स्टॉप और लाइनें वर्णित करने के लिए | GTFS Schedule |
| नियोजित यात्राओं और सेवा वाले दिनों की व्याख्या के लिए | GTFS Schedule |
| यात्राओं को अपडेट करने या सेवा की जानकारी प्राप्त करने के लिए | GTFS-RT, प्रकाशित स्ट्रीम के अनुसार |
| साझा मोबिलिटी स्टेशन या वाहनों का स्थान पता करने के लिए | GBFS, प्रकाशित डेटा के अनुसार |
डिजाइन का उदाहरण: एक मानचित्र ट्राम स्टॉप और बाइक स्टेशन दिखाता है। यह स्थानों के लिए संरचनात्मक डेटा और बाइक की उपलब्धता के लिए नवीनतम स्थितियाँ उपयोग करता है। दोनों परतों को अलग-अलग कैशिंग और अपडेट की जरूरत होती है।
प्रत्येक स्रोत की सीमाएं जानने की योजना बनाएं
संस्करण, वैकल्पिक फ़ील्ड, कवरेज और उपयोग अधिकार जांचें। एक पहचानकर्ता केवल उसके संदर्भ में अर्थपूर्ण होता है: दो प्रदाता एक जैसे स्ट्रिंग का उपयोग अलग इकाइयों के लिए कर सकते हैं।
गुम या पुरानी डेटा की भी योजना बनाएं। अनुपलब्ध स्ट्रीम से खाली सूची को सेवा की अनुपस्थिति के रूप में न दिखाएँ। अज्ञात जानकारी को चुपचाप शून्य से न बदलें।
डायरेक्ट स्ट्रीम्स या API का उपयोग करना
सीधे इंटीग्रेशन में डेटा इकट्ठा करने, सत्यापित करने और व्याख्या करने की जिम्मेदारी आपके ऊपर होती है। API सामान्य अनुबंध प्रदान कर सकता है, लेकिन कवरेज, चेतावनी और शर्तें पढ़ना आवश्यक है।
ROOTE के पहले उपयोग के लिए देखें कैसे एक API के साथ पास के स्टॉप खोजें. अपनी इंटरफेस की ज़रूरत से शुरू करें, फिर वास्तव में उपलब्ध क्षेत्रों की जांच करें।
अंश पढ़ना और एक वास्तुकला चुनना
GTFS Schedule में, stop_times.txt का एक अंश एक ट्रिप, एक स्टॉप और एक निर्धारित गुजरने को जोड़ता है। नीचे दिया गया संक्षिप्त उदाहरण शिक्षण उद्देश्यों के लिए है: यह पूर्ण GTFS सेट नहीं है और इसके पहचानकर्ता trips.txt, stops.txt और कैलेंडरों से जुड़े होने चाहिए।
GTFS Realtime के लिए, उपयोगी इकाई खोजें: एक TripUpdate एक गुजरने को अपडेट कर सकती है, एक VehiclePosition स्थिति का वर्णन करती है, और एक Alert सेवा सूचना भेजती है। वाहन की स्थिति स्वचालित रूप से आगमन का अनुमान नहीं होती। प्रेषित प्रारूप Protocol Buffers है; डायग्नोस्टिक JSON प्रतिनिधित्व संदर्भ बाइनरी प्रवाह नहीं है।
GBFS में, station_information स्टेशन बताते हैं जबकि station_status उनके प्रकाशित स्थिति को दर्शाता है। कुछ काउंटरों के नाम और उपलब्ध फाइलें संस्करण के अनुसार भिन्न होती हैं। नीचे दिया गया JSON अंश GBFS 2.3 और इसके num_bikes_available तथा num_docks_available फ़ील्ड्स को दर्शाता है; उदाहरण लेने से पहले संस्करण जांचें।
स्थान का एक नक्शा संरचनात्मक डेटा से शुरू हो सकता है। अगली आने वाली ट्रिप्स के लिए स्क्रीन को फिर आवश्यक अपडेट और स्पष्ट रूप से नियोजित बैकअप चाहिए। उपलब्ध साइकिलों का स्क्रीन काउंटर्स, किराए की शर्तें और समय की वैधता को संभालना चाहिए। ये तीन स्क्रीन स्वतः एक ही कैश नीति साझा नहीं करते।
# Extrait pédagogique de stop_times.txt
trip_id,arrival_time,departure_time,stop_id,stop_sequence
trip_demo,08:10:00,08:10:00,stop_demo,1
# Extrait pédagogique de station_status en GBFS 2.3
{
"station_id": "station_demo",
"num_bikes_available": 3,
"num_docks_available": 7,
"is_installed": true,
"is_renting": true,
"is_returning": true,
"last_reported": 1720000000
}साइकिल उपलब्धता और उसकी ताज़गी को स्वरूपित करना
अपने प्रोडक्ट के लिए एक API या MCP चुनना
अक्सर पूछे जाने वाले प्रश्न
क्या GTFS में स्वचालित रूप से वास्तविक समय होता है?
नहीं। GTFS Schedule नियोजित सेवा दर्शाता है; अपडेटेड जानकारी अन्य स्ट्रीम जैसे GTFS-RT पर निर्भर करती है।
क्या GBFS से बाइक अनलॉक कर सकते हैं?
यह सेवा और उसके सार्वजनिक डेटा का वर्णन करता है। किराया ऑपरेटर की क्षमताओं से होता है।
क्या एक मानक फॉर्मेट पूर्ण कवरेज सुनिश्चित करता है?
नहीं। फॉर्मेट संरचना परिभाषित करता है; कवरेज और प्रकाशित जानकारी स्रोतों पर निर्भर करती है।