GBFS की परिभाषाएं

इस सेक्शन में आगे बढ़ने से पहले, अगर आपने अब तक ऐसा नहीं किया है, तो पुष्टि करें कि आपने फ़ीड बनाने के लिए, माइक्रोमोबिलिटी की सुविधा देने वाली कंपनियों के साथ काम करने वाले सिस्टम चुने हों.

यहां दिए गए सेक्शन में, हर हेडर का फ़ॉर्मैट यह है: Required|Optional|Conditionally required: Feed name (System supported). इन सिस्टम पर काम करता है:

  • डॉक किया गया सिस्टम
  • डॉकलेस सिस्टम
  • डॉक किए गए और बिना डॉक किए गए सिस्टम

Google के साथ इंटिग्रेट करने के लिए, सिर्फ़ वे फ़ाइलें उपलब्ध कराएं जिनकी ज़रूरत आपके फ़ीड के सिस्टम के लिए है. साथ ही, ज़रूरी फ़ील्ड के बारे में बताएं. ये फ़ील्ड, फ़ीड के अलग-अलग सेक्शन में शामिल होने चाहिए. शर्त के साथ ज़रूरी फ़ील्ड के बारे में दिशा-निर्देश पाने के लिए, फ़ील्ड का ब्यौरा देखें. आपके पास ऐसे वैकल्पिक फ़ील्ड भी तय करने का विकल्प होता है जिनसे ज़्यादा जानकारी मिलती है और लोगों को बेहतर अनुभव मिलता है.

माइक्रोमोबिलिटी फ़ीड के लिए ज़रूरी हेडर

माइक्रोमोबिलिटी फ़ीड ऐसे फ़ीड होते हैं जिनमें डॉक्ड या डॉकलेस माइक्रोमोबिलिटी स्ट्रक्चर्ड डेटा होता है. इस लेख में इसके बारे में बताया गया है.

सभी फ़ीड में, JSON ऑब्जेक्ट के टॉप लेवल पर, यहां दी गई टेबल में शामिल फ़ील्ड हमेशा मौजूद होने चाहिए. इन्हें GBFS का सामान्य हेडर कहा जाता है.

फ़ील्ड का नाम टाइप आवश्यकता ब्यौरा
last_updated टाइमस्टैम्प ज़रूरी है POSIX टाइमस्टैंप, जो 1 जनवरी, 1970 को 00:00:00 यूटीसी से सेकंड की संख्या बताता है.

इसे उस समय पर सेट किया जाता है जब फ़ीड में मौजूद डेटा को आखिरी बार अपडेट किया गया था.
ttl सकारात्मक पूर्णांक ज़रूरी है यह एक नॉन-नेगेटिव पूर्णांक होता है. यह फ़ीड को अपडेट करने में बचे हुए समय को सेकंड में दिखाता है.

अगर डेटा को एक ही दर पर अपडेट करना है, तो इस वैल्यू को 0 पर सेट करें.
data JSON ज़रूरी है JSON, जिसमें हर फ़ीड के लिए डेटा फ़ील्ड शामिल होते हैं.

उदाहरण के लिए, एक एग्रीगेट किया गया free_bike_status.json फ़ीड, जिसमें सामान्य GBFS हेडर के बारे में बताया गया है, इस तरह का हो सकता है:

{
    "ttl": 30,
    "last_updated": 1576123774,
    "data": {
        "bikes": [ ... ]  // GBFS free bike status objects.
    }
}

ज़रूरी है: system_information.json (डॉक और डॉकलेस सिस्टम)

ज़रूरत के हिसाब से, GBFS स्पेसिफ़िकेशन देखें.

इस फ़ीड में सिस्टम ऑपरेटर के बारे में जानकारी दी जाती है.

फ़ील्ड का नाम टाइप आवश्यकता ब्यौरा
system_id आईडी ज़रूरी है वाहन शेयर करने की सुविधा देने वाले सिस्टम के लिए, दुनिया भर में यूनीक आइडेंटिफ़ायर. यह वैल्यू, सिस्टम के चालू रहने तक एक जैसी रहती है. हर सिस्टम या भौगोलिक क्षेत्र के लिए, system_id अलग होना चाहिए. सिस्टम आईडी को किसी खास सिस्टम से जुड़ा हुआ माना जाना चाहिए, न कि रैंडम स्ट्रिंग के तौर पर. उदाहरण के लिए, bcycle_austin या biketown_pdx.
name स्ट्रिंग ज़रूरी है सिस्टम का नाम, जो खरीदारों को दिखता है.
rental_apps ऑब्जेक्ट ज़रूरी है यह एक JSON ऑब्जेक्ट है. इसमें Android और iOS के लिए, किराये पर उपलब्ध कराने वाले ऐप्लिकेशन की जानकारी होती है. यह जानकारी, उनके फ़ील्ड में मौजूद होती है.
rental_apps.android ऑब्जेक्ट कुछ शर्तों के मुताबिक ज़रूरी है इसमें Android प्लैटफ़ॉर्म के लिए, किराये पर उपलब्ध ऐप्लिकेशन को डाउनलोड करने और ऐप्लिकेशन ढूंढने से जुड़ी जानकारी होती है. यह जानकारी store_uri और discovery_uri फ़ील्ड में मौजूद होती है. अगर सिस्टम प्रोवाइडर के पास Android पर चलने वाला रेंटल ऐप्लिकेशन है, तो यह फ़ील्ड ज़रूरी है.
rental_apps.android.store_uri यूआरआई ज़रूरी है वह यूआरआई जहां से किराये पर लिया गया Android ऐप्लिकेशन डाउनलोड किया जा सकता है. आम तौर पर, यह Google Play जैसे किसी ऐप्लिकेशन स्टोर का यूआरआई होता है. अगर यूआरआई, Google Play जैसे किसी ऐप्लिकेशन स्टोर पर ले जाता है, तो हमारा सुझाव है कि यूआरआई, Android के सबसे सही तरीकों का पालन करे. इससे, ऐप्लिकेशन देखने वाला व्यक्ति सीधे तौर पर यूआरआई को वेबसाइट के बजाय, नेटिव ऐप्लिकेशन स्टोर ऐप्लिकेशन पर खोल सकता है.
rental_apps.android.discovery_uri यूआरआई ज़रूरी है your_custom_scheme://your/path/here फ़ॉर्मैट वाला यूआरआई. PackageManager.queryIntentActivities() इस यूआरआई का इस्तेमाल करके यह पता लगाया जा सकता है कि डिवाइस पर किराये पर लिया गया Android ऐप्लिकेशन इंस्टॉल है या नहीं.
rental_apps.ios ऑब्जेक्ट कुछ शर्तों के मुताबिक ज़रूरी है इसमें iOS प्लैटफ़ॉर्म के लिए, किराये पर उपलब्ध ऐप्लिकेशन को डाउनलोड करने और ऐप्लिकेशन ढूंढने से जुड़ी जानकारी होती है. यह जानकारी store_uri और discovery_uri फ़ील्ड में मौजूद होती है. अगर सिस्टम उपलब्ध कराने वाली कंपनी के पास iOS के लिए किराये पर वाहन देने वाला ऐप्लिकेशन है, तो यह फ़ील्ड ज़रूरी है.
rental_apps.ios.store_uri यूआरआई ज़रूरी है वह यूआरआई जहां से किराये पर लिया गया iOS ऐप्लिकेशन डाउनलोड किया जा सकता है. आम तौर पर, यह Apple App Store जैसे किसी ऐप्लिकेशन स्टोर का यूआरआई होता है. अगर यूआरआई, Apple App Store जैसे किसी ऐप्लिकेशन स्टोर पर ले जाता है, तो हमारा सुझाव है कि यूआरआई, iOS के सबसे सही तरीकों का पालन करे. इससे, वीडियो देखने वाला ऐप्लिकेशन, वेबसाइट के बजाय सीधे तौर पर नेटिव ऐप्लिकेशन स्टोर ऐप्लिकेशन पर यूआरआई खोल सकता है.
rental_apps.ios.discovery_uri यूआरआई ज़रूरी है your_custom_scheme:// फ़ॉर्मैट वाला यूआरआई. UIApplication canOpenURL: इस यूआरआई का इस्तेमाल यह पता लगाने के लिए कर सकता है कि डिवाइस पर किराये पर उपलब्ध iOS ऐप्लिकेशन इंस्टॉल है या नहीं.

ज़रूरी है: free_bike_status.json (डॉकलेस सिस्टम)

ज़रूरत के हिसाब से, GBFS स्पेसिफ़िकेशन देखें.

इस फ़ीड में, उपलब्ध फ़्री-स्टैंडिंग वाहनों की जगह की जानकारी और एट्रिब्यूट तय किए जाते हैं. निजता की वजहों से, किराये पर दिए गए वाहन इस फ़ीड में नहीं दिखने चाहिए.

फ़ील्ड का नाम टाइप आवश्यकता ब्यौरा
bikes Array ज़रूरी है फ़िलहाल उपलब्ध, रोकी गई बाइकों की कैटगरी. इसमें हर बाइक एक ऑब्जेक्ट होती है.
bikes[].bike_id आईडी ज़रूरी है बाइक का आइडेंटिफ़ायर.

निजता की सुरक्षा के लिए, हर यात्रा के बाद आईडी को रैंडम स्ट्रिंग में बदला जा सकता है.
bikes[].lat अक्षांश ज़रूरी है बाइक का WGS 84 अक्षांश, दशमलव डिग्री फ़ॉर्मैट में.
bikes[].lon देशांतर ज़रूरी है दशमलव डिग्री फ़ॉर्मैट में बाइक का WGS 84 देशांतर.
bikes[].is_reserved बूलियन ज़रूरी है बाइक को फ़िलहाल रिज़र्व किया गया है या नहीं. इसके लिए, यह जानकारी दी गई है:
  • अगर बाइक को फ़िलहाल रिज़र्व किया गया है, तो इसे true पर सेट करें.
  • अगर बाइक को फ़िलहाल बुक नहीं किया गया है, तो इसे false पर सेट करें.
bikes[].is_disabled बूलियन ज़रूरी है बाइक फ़िलहाल बंद है या खराब है. इसके लिए, यह जानकारी दी जाती है:
  • अगर फ़िलहाल बाइक बंद है, तो उसे true पर सेट करें.
  • अगर फ़िलहाल बाइक बंद नहीं है, तो इसे false पर सेट करें.
bikes[].rental_uris ऑब्जेक्ट ज़रूरी है यह एक JSON ऑब्जेक्ट है. इसमें Android, iOS, और वेब के लिए किराये पर उपलब्ध कॉन्टेंट के यूआरआई, उनके फ़ील्ड में शामिल होते हैं.
bikes[].rental_uris.android यूआरआई कुछ शर्तों के मुताबिक ज़रूरी है यह एक यूआरआई है, जिसे Android ऐप्लिकेशन को पास किया जा सकता है. इसमें android.intent.action.VIEW Android इंटेंट होता है, ताकि Android डीप लिंक काम कर सकें. rental_uris के तौर पर Android ऐप्लिकेशन लिंक उपलब्ध कराना ज़रूरी है. इससे, अगर उपयोगकर्ता ने कॉन्टेंट उपलब्ध कराने वाला ऐप्लिकेशन इंस्टॉल नहीं किया है, तो कॉन्टेंट देखने वाले ऐप्लिकेशन को उपयोगकर्ता को ऐप्लिकेशन स्टोर पर रीडायरेक्ट करने की सुविधा को मैन्युअल तरीके से मैनेज करने की ज़रूरत नहीं पड़ेगी.

यह यूआरआई, किसी एक बाइक का डीप लिंक होना चाहिए. यह ऐसा सामान्य रेंटल पेज नहीं होना चाहिए जिसमें एक से ज़्यादा बाइक की जानकारी शामिल हो. डीप लिंक पर क्लिक करने के बाद, उपयोगकर्ता को सीधे बाइक पर ले जाना होगा. इसके लिए, किसी भी तरह के प्रॉम्प्ट, इंटरस्टीशियल पेज या लॉगिन का इस्तेमाल नहीं किया जा सकता. पक्का करें कि लोगों को बाइक दिखे, भले ही उन्होंने कभी ऐप्लिकेशन न खोला हो.

साइकिल के लिए यूआरआई में bike_id शामिल करना ज़रूरी नहीं है. हालांकि, पार्टनर के पास उस साइकिल की पहचान करने का कोई दूसरा तरीका होना चाहिए. उदाहरण के लिए, किराये पर बाइक देने वाला ऐप्लिकेशन, यूआरआई में अन्य आइडेंटिफ़ायर का इस्तेमाल करके बाइक की खास तौर पर पहचान कर सकता है.

अगर पार्टनर के पास Android पर किराये पर कार देने वाला ऐप्लिकेशन है, तो इस फ़ील्ड की जानकारी देना ज़रूरी है.

उपलब्ध कराना ज़रूरी है.

Android ऐप्लिकेशन के लिंक का उदाहरण:

https://www.example.com/app?sid=1234567890&platform=android
bikes[].rental_uris.ios यूआरआई कुछ शर्तों के मुताबिक ज़रूरी है ऐसा यूआरआई जिसका इस्तेमाल iOS पर, बाइक रेंटल ऐप्लिकेशन को लॉन्च करने के लिए किया जा सकता है. इस बारे में ज़्यादा जानने के लिए, Apple का यह लेख पढ़ें: iOS कस्टम यूआरएल स्कीम. rental_uris के तौर पर iOS यूनिवर्सल लिंक उपलब्ध कराए जाने चाहिए, ताकि अगर उपयोगकर्ता के पास सेवा देने वाले का ऐप्लिकेशन इंस्टॉल न हो, तो उसे ऐप्लिकेशन स्टोर पर रीडायरेक्ट करने के लिए, ऐप्लिकेशन को मैन्युअल तरीके से मैनेज न करना पड़े.

यह यूआरआई, किसी एक बाइक का डीप लिंक होना चाहिए. यह ऐसा सामान्य रेंटल पेज नहीं होना चाहिए जिसमें एक से ज़्यादा बाइक की जानकारी शामिल हो. डीप लिंक पर क्लिक करने के बाद, उपयोगकर्ता को सीधे बाइक पर ले जाना होगा. इसके लिए, किसी भी तरह के प्रॉम्प्ट, इंटरस्टीशियल पेज या लॉगिन का इस्तेमाल नहीं किया जा सकता. पक्का करें कि लोगों को बाइक दिखे, भले ही उन्होंने कभी ऐप्लिकेशन न खोला हो.

बाइक के लिए यूआरआई में bike_id शामिल करना ज़रूरी नहीं है. हालांकि, पार्टनर के पास उस बाइक की पहचान करने का कोई दूसरा तरीका होना चाहिए. उदाहरण के लिए, किराये पर बाइक देने वाला ऐप्लिकेशन, यूआरआई में मौजूद अन्य आइडेंटिफ़ायर का इस्तेमाल करके बाइक की खास तौर पर पहचान कर सकता है.

अगर पार्टनर के पास iOS पर चलने वाला रेंटल ऐप्लिकेशन है, तो यह फ़ील्ड भरना ज़रूरी है.

देना ज़रूरी है.

iOS यूनिवर्सल लिंक का उदाहरण:

https://www.example.com/app?sid=1234567890&platform=ios

bikes[].rental_uris.web URL वैकल्पिक

ऐसा यूआरएल जिसका इस्तेमाल वेब ब्राउज़र, इस वाहन को किराए पर लेने के बारे में ज़्यादा जानकारी दिखाने के लिए कर सकता है.

यह यूआरएल, किसी एक बाइक का डीप लिंक होना चाहिए. यह ऐसा सामान्य रेंटल पेज नहीं होना चाहिए जिसमें एक से ज़्यादा बाइक की जानकारी शामिल हो. डीप लिंक पर क्लिक करने के बाद, उपयोगकर्ता को सीधे बाइक पर ले जाना होगा. इसके लिए, किसी भी तरह के प्रॉम्प्ट, इंटरस्टीशियल पेज या लॉगिन का इस्तेमाल नहीं किया जा सकता. पक्का करें कि लोगों को बाइक दिखे, भले ही उन्होंने कभी ऐप्लिकेशन न खोला हो.

बाइक के यूआरएल में bike_id शामिल करना ज़रूरी नहीं है. इसके अलावा, Android या iOS के लिए किराये पर उपलब्ध बाइक के यूआरएल के सिमैंटिक कन्वेंशनल का पालन करना भी ज़रूरी नहीं है. किराये पर बाइक देने वाला ऐप्लिकेशन, यूआरएल में मौजूद अन्य आइडेंटिफ़ायर का इस्तेमाल कर सकता है. इससे बाइक की खास तौर पर पहचान की जा सकती है.

अगर इस फ़ील्ड को सेट नहीं किया जाता है, तो इसका मतलब है कि वेब ब्राउज़र के लिए डीप लिंक काम नहीं करते.

उदाहरण वैल्यू:

https://www.example.com/app?sid=1234567890
bikes[].vehicle_type_id आईडी ज़रूरी है vehicle_types.json सेक्शन में बताए गए तरीके के मुताबिक, वाहन का vehicle_type_id.
bikes[].pricing_plan_id आईडी ज़रूरी है किराये के प्लान का आइडेंटिफ़ायर. यह प्लान तब लागू होता है, जब इस तरह के वाहन को system_pricing_plans.json सेक्शन में बताए गए तरीके से किराये पर लिया जाता है.
bikes[].current_range_meters सकारात्मक फ़्लोट कुछ शर्तों के मुताबिक ज़रूरी है अगर वाहन से जुड़ी vehicle_type की परिभाषा में मोटर शामिल है, तो इस फ़ील्ड की ज़रूरत होती है.

इस एट्रिब्यूट की वैल्यू, मीटर में वह सबसे ज़्यादा दूरी सेट करें जो वाहन, रीचार्ज या रिफ़्यूल किए बिना तय कर सकता है. यह दूरी, वाहन के मौजूदा चार्ज या ईंधन के लेवल के हिसाब से तय की जाती है.
bikes[].last_reported टाइमस्टैम्प वैकल्पिक इस फ़ील्ड की वैल्यू, उस समय के हिसाब से सेट की जाती है जब वाहन ने ऑपरेटर के बैकएंड को अपनी स्थिति की जानकारी दी थी.

यहां free_bike_status.json का उदाहरण दिया गया है:

"bikes": [{
    "bike_id": "xyz123",
    "lat": 12.34,
    "lon": 56.78,
    "is_reserved": true,
    "is_disabled": false,
    "rental_uris":{
      "android": "https://www.example.com/app?sid=1234567890&platform=android",
      "ios": "https://www.example.com/app?sid=1234567890&platform=ios",
      "web": "https://www.example.com/app?sid=1234567890"
    },
    "vehicle_type_id": "scooter_electric",
    "pricing_plan_id": "sydneyPlan1",
    "current_range_meters": 4500,
    "last_reported": 1434054678
},
{
    "bike_id": "abc123",
    "lat": 1.34,
    "lon": 146.78,
    "is_reserved": false,
    "is_disabled": true,
    "rental_uris":{
      "android": "https://www.example.com/app?sid=1234567890&platform=android",
      "ios": "https://www.example.com/app?sid=1234567890&platform=ios",
      "web": "https://www.example.com/app?sid=1234567890"
    },
    "vehicle_type_id": "bike_manual",
    "pricing_plan_id": "sydneyPlan1",
    "last_reported": 1434054241
}
]

ज़रूरी है: vehicle_types.json (डॉक और डॉकलेस सिस्टम)

ज़रूरत के हिसाब से, GBFS स्पेसिफ़िकेशन देखें.

इस फ़ीड में, अलग-अलग तरह के वाहनों की जानकारी दी जाती है. इस बारे में free_bike_status.json सेक्शन में बताया गया है.

फ़ील्ड का नाम टाइप आवश्यकता ब्यौरा
vehicle_types Array ज़रूरी है ऑब्जेक्ट की एक कैटगरी. इसमें हर ऑब्जेक्ट, सेवा देने वाली कंपनी के कैटलॉग में मौजूद अलग-अलग तरह के वाहनों के बारे में बताता है. किसी वाहन के टाइप के लिए, सिर्फ़ एक ऑब्जेक्ट हो सकता है.
vehicle_types[].vehicle_type_id आईडी ज़रूरी है किसी वाहन के टाइप के लिए यूनीक आइडेंटिफ़ायर.
vehicle_types[].form_factor Enum ज़रूरी है यह एक enum है, जो वाहन के सामान्य फ़ॉर्म फ़ैक्टर को दिखाता है. फ़िलहाल, मान्य वैल्यू की इस सूची में से कोई वैल्यू चुनें:
  • bicycle
  • scooter
  • other
vehicle_types[].propulsion_type Enum ज़रूरी है यह एक enum है, जो वाहन के प्राइमरी प्रोपल्शन टाइप को दिखाता है. फ़िलहाल, मान्य वैल्यू की इस सूची में से:
  • human: पैडल या पैर से चलाने की सुविधा
  • electric_assist: सिर्फ़ इंसानी ताकत के साथ चलने पर पावर मिलती है
  • electric: इसमें बैटरी से चलने वाली मोटर के साथ थ्रॉटल मोड होता है
  • combustion: इसमें थ्रॉटल मोड होता है और यह गैस इंजन से चलने वाली मोटर से चलता है
vehicle_types[].max_range_meters सकारात्मक फ़्लोट कुछ शर्तों के मुताबिक ज़रूरी है अगर propulsion_type को human पर सेट नहीं किया गया है, तो इसका मतलब है कि वाहन में मोटर है. इसलिए, इस फ़ील्ड की वैल्यू देना ज़रूरी है.

यह वैल्यू, मीटर में उस दूरी पर सेट की जाती है जो वाहन, पूरी तरह से चार्ज होने या पूरी तरह से ईंधन भरने के बाद, बिना रिचार्ज किए या बिना ईंधन भरे तय कर सकता है.

यहां vehicle_types.json का उदाहरण दिया गया है:

"vehicle_types": [
  {
    "vehicle_type_id": "bike_manual",
    "form_factor": "bicycle",
    "propulsion_type": "human"
  },
  {
    "vehicle_type_id": "scooter_electric",
    "form_factor": "scooter",
    "propulsion_type": "electric",
    "max_range_meters": 10000
  }
]

ज़रूरी है: system_pricing_plans.json (बिना डॉक वाला सिस्टम)

ज़रूरत के हिसाब से, GBFS स्पेसिफ़िकेशन देखें.

इस फ़ीड में, अलग से खड़े किए गए वाहनों के लिए किराया प्लान तय किए जाते हैं. हम चाहते हैं कि सेवा देने वाली कंपनियां, अलग से खड़े वाहनों के लिए कीमत की जानकारी दिखाएं.

फ़ील्ड का नाम टाइप आवश्यकता ब्यौरा
plans Array ज़रूरी है ऑब्जेक्ट का कलेक्शन, जिसमें हर ऑब्जेक्ट किसी कीमत वाले प्लान के बारे में बताता है.
plans[].plan_id आईडी ज़रूरी है यह एक स्ट्रिंग होती है. यह कीमत वाले प्लान के लिए यूनीक आइडेंटिफ़ायर को दिखाती है. यह प्लान, सेवा देने वाली कंपनी ऑफ़र करती है.
plans[].url URL वैकल्पिक वह यूआरएल जो असली उपयोगकर्ताओं को कीमत की योजना के बारे में ज़्यादा जानकारी देता है.
plans[].currency स्ट्रिंग ज़रूरी है कीमत प्लान के लिए, ISO 4217 स्टैंडर्ड.
plans[].price सकारात्मक फ़्लोट ज़रूरी है

कीमत के प्लान को, बिना रेटिंग वाला या रेटिंग वाला प्लान के तौर पर तय किया जाना चाहिए:

रेटिंग न किया गया कीमत वाला प्लान

इस प्लान के लिए, एक बार में पूरा पेमेंट करना होता है.

यह फ़ील्ड सेट करें:

  • price: पूरी यात्रा का तय किया गया किराया.
रेट किया गया कीमत प्लान

यह प्लान, लीनियर रेट प्राइस वाला प्लान है.

यह फ़ील्ड सेट करें:

  • price: यह मूल किराया है, जो हर यात्रा के लिए सिर्फ़ एक बार लिया जाता है.

इनमें से किसी एक या दोनों फ़ील्ड को सेट करें:

  • per_km_pricing: यात्रा का किराया, जो प्रति किलोमीटर के हिसाब से तय किया जाता है.
  • per_min_pricing: यात्रा की कीमत, जो हर मिनट के हिसाब से तय की जाती है.
plans[].per_km_pricing Array कुछ शर्तों के मुताबिक ज़रूरी है

अगर किराया, तय की गई दूरी के हिसाब से तय होता है और उसे किलोमीटर में दिखाया जाता है, तो इस फ़ील्ड की ज़रूरत होती है.

ऑब्जेक्ट का एक कलेक्शन, जिसमें हर ऑब्जेक्ट, दूरी के हिसाब से बांटे गए सेगमेंट के बारे में बताता है. हर सेगमेंट की start वैल्यू, अगले सेगमेंट की start वैल्यू से कम या उसके बराबर होनी चाहिए.

दिए गए प्लान की कुल कीमत तय करने के लिए, दिए गए प्लान की plans[].price वैल्यू को plans[].per_km_pricing और plans[].per_min_pricing में मौजूद सेगमेंट के लिए, जोड़ी गई कीमतों में जोड़ें.

अगर यह फ़ील्ड सेट नहीं किया जाता है, तो दूरी के हिसाब से किराये में कोई बदलाव नहीं होता. इसलिए, कुल किराये में कोई भी बदलाव शामिल नहीं किया जाता.
plans[].per_km_pricing[].start सकारात्मक पूर्णांक ज़रूरी है किलोमीटर की वह संख्या जिसके बाद से सेगमेंट के लिए शुल्क लगना शुरू होता है. इस फ़ील्ड को शामिल वैल्यू पर सेट किया जाता है. यह वैल्यू, सेगमेंट की रेंज शुरू करती है. इसलिए, तय किए गए किलोमीटर पूरे होने के बाद, rate का शुल्क एक बार लिया जाता है.
plans[].per_km_pricing[].rate फ़्लोट ज़रूरी है हर interval के लिए लिया जाने वाला शुल्क, जो सेगमेंट के start से शुरू होता है. अगर इस फ़ील्ड को नेगेटिव नंबर पर सेट किया जाता है, तो यात्री को छूट मिलती है.
plans[].per_km_pricing[].interval सकारात्मक पूर्णांक ज़रूरी है

यह किलोमीटर में वह इंटरवल होता है जिस पर सेगमेंट का rate अनिश्चित काल के लिए फिर से लागू किया जाता है. ऐसा तब तक होता है, जब तक सेगमेंट के end को किसी गैर-ऋणात्मक पूर्णांक पर सेट नहीं किया जाता.

rate को हर interval की शुरुआत में एक बार फिर से लागू किया जाता है. साथ ही, दूरी को पूर्णांक में बदलने पर विचार नहीं किया जाता.

अगर सेगमेंट का end कोई नॉन-नेगेटिव पूर्णांक है, तो सेगमेंट का rate, सेगमेंट के end वैल्यू तक फिर से लागू होता है. हालांकि, इसमें सेगमेंट का end वैल्यू शामिल नहीं होता.

अगर इस फ़ील्ड को 0 पर सेट किया जाता है, तो rate को सेगमेंट के start पर सिर्फ़ एक बार चार्ज किया जाता है.
plans[].per_km_pricing[].end सकारात्मक पूर्णांक वैकल्पिक

किलोमीटर की वह संख्या जिसके बाद सेगमेंट के लिए rate लागू नहीं होता. इस फ़ील्ड को एक्सक्लूसिव वैल्यू पर सेट किया जाता है. यह वैल्यू, सेगमेंट की रेंज को खत्म करती है. उदाहरण के लिए, अगर end को 40 पर सेट किया जाता है, तो rate 40 किलोमीटर पर लागू नहीं होता.

अगर यह फ़ील्ड सेट नहीं है या खाली है, तो यात्रा खत्म होने तक सेगमेंट के लिए rate का शुल्क लिया जाता है. इसके अलावा, इसके बाद आने वाले किसी भी अतिरिक्त सेगमेंट के लिए भी शुल्क लिया जाता है.
plans[].per_min_pricing Array कुछ शर्तों के मुताबिक ज़रूरी है

अगर कीमत, बीता हुआ समय (मिनटों में दिखाया गया) के हिसाब से तय होती है, तो इस फ़ील्ड को भरना ज़रूरी है.

ऑब्जेक्ट का कलेक्शन, जिसमें हर ऑब्जेक्ट, समय के हिसाब से बांटे गए सेगमेंट के बारे में बताता है. हर सेगमेंट की start वैल्यू, अगले सेगमेंट की start वैल्यू से कम या उसके बराबर होनी चाहिए.

दिए गए प्लान की कुल कीमत तय करने के लिए, दिए गए प्लान की plans[].price वैल्यू को plans[].per_km_pricing और plans[].per_min_pricing में मौजूद सेगमेंट के लिए, जोड़ी गई कीमतों में जोड़ें.

अगर यह फ़ील्ड सेट नहीं किया जाता है, तो समय के हिसाब से किराये में बदलाव नहीं होता है. इसलिए, कुल किराये में कोई भी बदलाव शामिल नहीं किया जाता है.
plans[].per_min_pricing[].start फ़्लोट ज़रूरी है यह वह समय होता है जिसके बाद सेगमेंट के लिए शुल्क लगना शुरू होता है. इस फ़ील्ड को शामिल वैल्यू पर सेट किया जाता है. यह वैल्यू, सेगमेंट की रेंज शुरू करती है. इसलिए, तय किए गए मिनट पूरे होने के बाद, rate से एक बार शुल्क लिया जाएगा.
plans[].per_min_pricing[].rate फ़्लोट ज़रूरी है हर interval के लिए लिया जाने वाला शुल्क. यह दर, सेगमेंट के start से शुरू होती है. अगर इस फ़ील्ड को नेगेटिव नंबर पर सेट किया जाता है, तो यात्री को छूट मिलती है.
plans[].per_min_pricing[].interval सकारात्मक पूर्णांक ज़रूरी है

यह वह समयावधि है जिसके बाद सेगमेंट का rate फिर से लागू होता है. यह तब तक लागू होता रहता है, जब तक सेगमेंट का end किसी गैर-ऋणात्मक पूर्णांक पर सेट नहीं होता.

rate को हर interval की शुरुआत में एक बार फिर से लागू किया जाता है. साथ ही, यात्रा के समय को राउंड ऑफ़ नहीं किया जाता है.

अगर सेगमेंट का end कोई नॉन-नेगेटिव पूर्णांक है, तो सेगमेंट का rate, सेगमेंट के end वैल्यू तक फिर से लागू होता है. हालांकि, इसमें सेगमेंट का end वैल्यू शामिल नहीं होता.

अगर इस फ़ील्ड को 0 पर सेट किया जाता है, तो rate को सेगमेंट के start पर सिर्फ़ एक बार चार्ज किया जाता है.
plans[].per_min_pricing[].end सकारात्मक पूर्णांक वैकल्पिक

यह वह समय है जब सेगमेंट के लिए rate लागू नहीं होता. इस फ़ील्ड को एक्सक्लूसिव वैल्यू पर सेट किया जाता है. यह वैल्यू, सेगमेंट की रेंज को खत्म करती है. उदाहरण के लिए, अगर end को 20 पर सेट किया जाता है, तो rate अब 20 मिनट पर लागू नहीं होता.

अगर यह फ़ील्ड सेट नहीं है या खाली है, तो यात्रा खत्म होने तक सेगमेंट के लिए rate का शुल्क लिया जाता है. इसके अलावा, इसके बाद आने वाले किसी भी अतिरिक्त सेगमेंट के लिए भी शुल्क लिया जाता है.

system_pricing_plans.json के उदाहरण

इस सेक्शन में, जानकारी देने वाले system_pricing_plans.json कोड सैंपल दिए गए हैं. हर उदाहरण के लिए, काम की जानकारी और नतीजे भी दिए गए हैं.

system_pricing_plans.json के लिए पहला उदाहरण

कीमत के प्लान के इस सैंपल कोड में, यात्रा की अवधि के आधार पर शुल्क दिखाया गया है. यह शुल्क इन समयावधियों के लिए है:

  • [0,1): 2 डॉलर
    • अगर यात्रा एक मिनट से कम है, तो उपयोगकर्ता को 2 डॉलर चुकाने होंगे.
    • उदाहरण: 59 सेकंड की यात्रा
  • [1,2): 3 डॉलर
    • अगर यात्रा एक मिनट या उससे ज़्यादा, लेकिन दो मिनट से कम है, तो उपयोगकर्ता को 2 डॉलर + 1 डॉलर = 3 डॉलर चुकाने होंगे.
    • उदाहरण: एक मिनट की यात्रा; एक मिनट 45 सेकंड की यात्रा
  • x मिनट, जहां x की वैल्यू 2 से ज़्यादा या इसके बराबर है: 300 रुपये + ((200 रुपये + 100 रुपये) * (x - 2 + 1)) भारतीय रुपये
    • अगर यात्रा दो मिनट या इससे ज़्यादा की है, तो उपयोगकर्ता को दो मिनट से कम की यात्रा के लिए 3 डॉलर चुकाने होंगे. साथ ही, दो मिनट के बाद की हर मिनट की यात्रा के लिए, उसे (per_min_pricing सूची की पहली एंट्री से जारी है) 1 डॉलर + (per_min_pricing सूची की दूसरी एंट्री) 2 डॉलर चुकाने होंगे.
    • उदाहरण:
      • दो मिनट की यात्रा का किराया 3 डॉलर + (2 डॉलर + 1 डॉलर) = 6 डॉलर
      • ढाई मिनट की यात्रा का किराया 3 डॉलर + (2 डॉलर + 1 डॉलर) = 6 डॉलर
      • तीन मिनट की यात्रा का किराया 300 रुपये + ((200 रुपये + 100 रुपये) * 2) = 900 रुपये
      • 10 मिनट की यात्रा का किराया 3 डॉलर + (($2 + $1) * 9) = 30 डॉलर
{
  "plans": {
    "plan_id": "plan1",
    "currency": "USD",
    "price": 2,
    "per_min_pricing": [
      {
          "interval": 1,
          "rate": 1,
          "start": 1
      },
      {
          "interval": 1,
          "rate": 2,
          "start": 2
      }
    ],
  }
}

system_pricing_plans.json के लिए दूसरा उदाहरण

इस उदाहरण में, हम ऐसे प्राइसिंग प्लान के लिए कोड का सैंपल दिखाते हैं जिसमें मिनट और किलोमीटर, दोनों के हिसाब से शुल्क लिया जाता है:

  • खास तौर पर, आखिरी उपयोगकर्ता से हर किलोमीटर के लिए 0.25 कैनेडियन डॉलर और हर मिनट के लिए 0.50 कैनेडियन डॉलर का शुल्क लिया जाता है.
  • ये दोनों दरें एक साथ लागू होती हैं और एक-दूसरे पर निर्भर नहीं होती हैं.
  • इसलिए, एक किलोमीटर की यात्रा के लिए 900 रुपये का शुल्क लगता है. इस शुल्क का ब्यौरा यहां दिया गया है:
    • 300 रुपये, मूल कीमत
    • 0.25 डॉलर * 2. यह शुल्क, यात्रा की शुरुआत में एक बार और 1 कि॰मी॰ की दूरी तय करने के बाद एक बार लिया जाता है.
    • 0.5 डॉलर * 11. यह शुल्क हर मिनट की शुरुआत में एक बार लिया जाता है. शुल्क 0 सेकंड से शुरू होता है. आखिरी इंटरवल के लिए 10 मिनट का शुल्क लिया जाता है.
{
  "plans": {
    "plan_id": "plan2",
    "currency": "CAD",
    "price": 3,
    "per_km_pricing": [{
      "start": 0,
      "rate": 0.25,
      "interval": 1
    }],
    "per_min_pricing": [{
      "start": 0,
      "rate": 0.50,
      "interval": 1
    }]
  }
}

कुछ शर्तों के मुताबिक ज़रूरी है: geofencing_zones.json (डॉक और बिना डॉक वाला सिस्टम)

ज़रूरत के हिसाब से, GBFS स्पेसिफ़िकेशन देखें.

इस फ़ीड से, फ़्री-स्टैंडिंग वाहनों के लिए जियोफ़ेंसिंग डेटा तय किया जाता है. जियोफ़ेंसिंग के डेटा में, भौगोलिक सीमाएं शामिल होती हैं. इनसे यह पता चलता है कि वाहनों को कहां से यात्रा शुरू करने और कहां खत्म करने की अनुमति है. साथ ही, यह भी पता चलता है कि वाहन किस रफ़्तार से चल सकते हैं. यह रफ़्तार, वाहन की ज़्यादा से ज़्यादा रफ़्तार या उस सड़क की रफ़्तार सीमा होती है जिस पर वाहन चल रहा है. इनमें से जो भी कम हो उसे रफ़्तार सीमा माना जाता है. ड्राइवरों को स्थानीय कानूनों और अध्यादेशों का पालन करना होगा.

हम इस डेटा का इस्तेमाल इसलिए करते हैं, ताकि जब कोई व्यक्ति किसी रूट को खोजे, तो अगर यात्रा का आखिरी हिस्सा किसी खास जियोफ़ेंस से बाहर हो, तो माइक्रोट्रांसपोर्टेशन के नतीजे को फ़िल्टर कर दिया जाए. अगर जियोफ़ेंस की जानकारी नहीं दी जाती है, तो Google यह मानता है कि सेवा के लिए कोई सीमा तय नहीं की गई है.

फ़ील्ड का नाम टाइप आवश्यकता ब्यौरा
geofencing_zones ऑब्जेक्ट ज़रूरी है IETF RFC 7946 के मुताबिक, FeatureCollection ऑब्जेक्ट एक ऐसा ऑब्जेक्ट होता है जिसमें features नाम का फ़ील्ड होता है. features की वैल्यू, एक JSON कलेक्शन है. JSON ऐरे का हर एलिमेंट, एक Feature ऑब्जेक्ट होता है.

यहां हर जियोफ़ेंस किए गए ज़ोन, उससे जुड़े नियमों और एट्रिब्यूट, और FeatureCollection की परिभाषाओं के बारे में बताया गया है. ये geofencing_zones.json फ़ीड की परिभाषाओं का हिस्सा हैं.
geofencing_zones.type स्ट्रिंग ज़रूरी है FeatureCollection पर सेट किया गया है. इसके बारे में IETF RFC 7946 में बताया गया है.
geofencing_zones.features Array ज़रूरी है यह एक JSON कलेक्शन है. इसमें JSON कलेक्शन का हर एलिमेंट, Feature ऑब्जेक्ट होता है.
geofencing_zones.features[].type स्ट्रिंग ज़रूरी है Feature पर सेट किया गया है. इसके बारे में IETF RFC 7946 में बताया गया है.
geofencing_zones.features[].geometry GeoJSON मल्टीपॉलीगॉन ज़रूरी है यह एक GeoJSON Multipolygon है. इससे यह पता चलता है कि किन जगहों पर यात्राएं शुरू, खत्म या पूरी नहीं की जा सकतीं. साथ ही, इससे अन्य पाबंदियों के बारे में भी पता चलता है. पॉइंट को घड़ी की सुई की दिशा में व्यवस्थित करने से, पॉलीगॉन से घिरा हुआ क्षेत्र तय होता है. वहीं, घड़ी की सुई की उलटी दिशा में व्यवस्थित करने से, पॉलीगॉन के बाहर का क्षेत्र तय होता है. इस बारे में ज़्यादा जानकारी के लिए, राइट-हैंड रूल देखें.
geofencing_zones.features[].properties ऑब्जेक्ट ज़रूरी है यह एक ऐसा ऑब्जेक्ट है जो यात्रा के भत्ते और पाबंदियों के बारे में बताता है.
geofencing_zones.features[].properties.rules Array वैकल्पिक ऑब्जेक्ट का कलेक्शन. इसमें हर ऑब्जेक्ट, सिर्फ़ एक नियम के बारे में बताता है. अगर दो या उससे ज़्यादा नियम ओवरलैप होते हैं, टकराते हैं या किसी अन्य तरीके से एक-दूसरे से मेल नहीं खाते हैं, तो JSON फ़ाइल में सबसे पहले तय किए गए नियम को प्राथमिकता दी जाती है.
geofencing_zones.features[].properties.rules[].vehicle_type_id Array वैकल्पिक वाहन के टाइप आईडी का कलेक्शन. इसमें हर एलिमेंट एक vehicle_type_id होता है. इस पर कोई भी पाबंदी लागू होनी चाहिए. अगर कोई vehicle_type_id नहीं दिया गया है, तो पाबंदियां सभी तरह के वाहनों पर लागू होंगी.
geofencing_zones.features[].properties.rules[].ride_allowed बूलियन ज़रूरी है यह जानकारी कि क्या "बिना डॉक की गई" साइकल राइड, ज़ोन में शुरू और खत्म की जा सकती है. जैसे:
  • अगर बिना डॉक की गई साइकल की सवारी, ज़ोन में शुरू और खत्म की जा सकती है, तो इसे true पर सेट करें.
  • अगर बिना डॉक की गई बाइक राइड, false के तौर पर सेट किए गए ज़ोन में शुरू और खत्म नहीं हो सकती.

यहां geofencing_zones.json का उदाहरण दिया गया है:

"geofencing_zones":{
  "type":"FeatureCollection",
  "features":[{
    "type":"Feature",
    "properties":{
      "rules":[{
        "vehicle_type_id":"scooter",
        "ride_allowed": false
      }]
    },
    "geometry":{
      "type":"MultiPolygon",
      "coordinates":[[[
        [-122.66780376434326, 45.49896266763551],
        [-122.66810417175292, 45.49824825558575],
        [-122.66830801963805, 45.49632305799116],
        [-122.66780376434326, 45.49896266763551]
      ]]]
    }
  }]
}

ज़रूरी है: station_information.json (डॉक किया गया सिस्टम)

ज़रूरत के हिसाब से, GBFS स्पेसिफ़िकेशन देखें.

इस फ़ीड में, सार्वजनिक तौर पर बाइक शेयर करने की सुविधा देने वाले स्टेशनों के बारे में सामान्य जानकारी दी जाती है.

फ़ील्ड का नाम टाइप आवश्यकता ब्यौरा
stations Array ज़रूरी है ऑब्जेक्ट का कलेक्शन, जिसमें हर ऑब्जेक्ट सिर्फ़ एक स्टेशन के बारे में बताता है.
stations[].station_id स्ट्रिंग ज़रूरी है स्टेशन का आइडेंटिफ़ायर.
stations[].name स्ट्रिंग ज़रूरी है स्टेशन का सार्वजनिक नाम, उस शहर की स्थानीय भाषा में जिसमें स्टेशन मौजूद है. name वही होना चाहिए जो स्टेशन पर लगे साइनेज पर लिखा है. अगर साइनेज उपलब्ध नहीं है, तो इसमें स्टेशन की जगह की जानकारी होनी चाहिए. इसके लिए, क्रॉस स्ट्रीट या स्थानीय लैंडमार्क का इस्तेमाल किया जा सकता है. "स्ट्रीट" के लिए "St." जैसे छोटे रूप का इस्तेमाल न करें. ऐसा तब तक न करें, जब तक कि इसका इस्तेमाल साइनेज में साफ़ तौर पर न किया गया हो. साथ ही, name में छोटे-बड़े अक्षरों का इस्तेमाल किया जाना चाहिए. इसमें जगहों के नाम को बड़े अक्षर से शुरू करने के लिए स्थानीय मानकों का पालन किया जाना चाहिए. साथ ही, इसे पूरी तरह से कैपिटल लेटर में नहीं लिखा जाना चाहिए.
stations[].lat अक्षांश ज़रूरी है स्टेशन का WGS 84 अक्षांश, दशमलव डिग्री फ़ॉर्मैट में.
stations[].lon देशांतर ज़रूरी है स्टेशन का WGS 84 देशांतर, दशमलव डिग्री फ़ॉर्मैट में.
stations[].capacity सकारात्मक पूर्णांक वैकल्पिक यह एक नॉन-नेगेटिव पूर्णांक होता है. इससे स्टेशन पर इंस्टॉल किए गए डॉकिंग पॉइंट की कुल संख्या के बारे में पता चलता है. इसमें उपलब्ध और अनुपलब्ध, दोनों तरह के डॉकिंग पॉइंट शामिल होते हैं.
stations[].rental_uris ऑब्जेक्ट ज़रूरी है

यह एक JSON ऑब्जेक्ट है. इसमें Android, iOS, और वेब के लिए किराये पर उपलब्ध कॉन्टेंट के यूआरआई, उनके संबंधित फ़ील्ड में मौजूद होते हैं.

इन यूआरआई को तय करने पर, ये उन डिफ़ॉल्ट डीप लिंक को बदल देते हैं जिन्हें सेवा देने वाली कंपनी को शामिल करते समय सेट किया गया था.
stations[].rental_uris.android यूआरआई कुछ शर्तों के मुताबिक ज़रूरी है

यह एक यूआरआई है, जिसे Android ऐप्लिकेशन में android.intent.action.VIEW Android इंटेंट के साथ पास किया जा सकता है, ताकि Android डीप लिंक काम कर सकें. rental_uris के तौर पर Android ऐप्लिकेशन लिंक उपलब्ध कराया जाना चाहिए, ताकि अगर उपयोगकर्ता ने कॉन्टेंट उपलब्ध कराने वाला ऐप्लिकेशन इंस्टॉल नहीं किया है, तो कॉन्टेंट देखने वाले ऐप्लिकेशन को उपयोगकर्ता को ऐप्लिकेशन स्टोर पर रीडायरेक्ट करने की प्रोसेस को मैन्युअल तरीके से मैनेज न करना पड़े.

यह यूआरआई, किसी स्टेशन के लिए खास तौर पर डीप लिंक होना चाहिए. यह ऐसा सामान्य रेंटल पेज नहीं होना चाहिए जिसमें एक से ज़्यादा स्टेशन की जानकारी शामिल हो. डीप लिंक, उपयोगकर्ता को सीधे स्टेशन पर ले जाना चाहिए. इसके लिए, किसी प्रॉम्प्ट, इंटरस्टीशियल पेज या लॉगिन की ज़रूरत नहीं होनी चाहिए. पक्का करें कि उपयोगकर्ताओं को स्टेशन दिखे, भले ही उन्होंने कभी ऐप्लिकेशन न खोला हो.

स्टेशन के लिए यूआरआई में station_id शामिल करना ज़रूरी नहीं है. हालांकि, पार्टनर के पास स्टेशन की पहचान करने का कोई दूसरा तरीका होना चाहिए. उदाहरण के लिए, किराये पर वाहन देने वाला ऐप्लिकेशन, स्टेशन की खास तौर पर पहचान करने के लिए यूआरआई में अन्य आइडेंटिफ़ायर का इस्तेमाल कर सकता है.

अगर पार्टनर के पास Android पर किराये पर कार देने वाला ऐप्लिकेशन है, तो इस फ़ील्ड की जानकारी देना ज़रूरी है.

Android ऐप्लिकेशन के लिंक का उदाहरण:

https://www.example.com/app?sid=1234567890&platform=android
stations[].rental_uris.ios यूआरआई कुछ शर्तों के मुताबिक ज़रूरी है

यह एक यूआरआई है. इसका इस्तेमाल iOS पर, स्टेशन के लिए किराये पर उपलब्ध ऐप्लिकेशन को लॉन्च करने के लिए किया जा सकता है. इस बारे में ज़्यादा जानने के लिए, Apple का iOS कस्टम यूआरएल स्कीम के बारे में लेख पढ़ें. उपलब्ध कराया गया rental_uris iOS यूनिवर्सल लिंक होना चाहिए, ताकि वीडियो देखने वाले ऐप्लिकेशन को उपयोगकर्ता को ऐप्लिकेशन स्टोर पर रीडायरेक्ट करने की सुविधा को मैन्युअल तरीके से मैनेज न करना पड़े. ऐसा तब होता है, जब उपयोगकर्ता ने कॉन्टेंट उपलब्ध कराने वाले ऐप्लिकेशन को इंस्टॉल नहीं किया होता है.

यह यूआरआई, किसी स्टेशन के लिए खास तौर पर डीप लिंक होना चाहिए. यह ऐसा सामान्य रेंटल पेज नहीं होना चाहिए जिसमें एक से ज़्यादा स्टेशन की जानकारी शामिल हो. डीप लिंक, उपयोगकर्ता को सीधे स्टेशन पर ले जाना चाहिए. इसके लिए, किसी प्रॉम्प्ट, इंटरस्टीशियल पेज या लॉगिन की ज़रूरत नहीं होनी चाहिए. पक्का करें कि उपयोगकर्ताओं को स्टेशन दिखे, भले ही उन्होंने कभी ऐप्लिकेशन न खोला हो.

स्टेशन के लिए, यूआरआई में station_id शामिल करना ज़रूरी नहीं है. किराये पर वाहन देने वाला ऐप्लिकेशन, स्टेशन की खास तौर पर पहचान करने के लिए यूआरआई में अन्य आइडेंटिफ़ायर का इस्तेमाल कर सकता है.

अगर पार्टनर के पास iOS पर चलने वाला रेंटल ऐप्लिकेशन है, तो यह फ़ील्ड भरना ज़रूरी है.

iOS यूनिवर्सल लिंक का उदाहरण:

https://www.example.com/app?sid=1234567890&platform=ios
stations[].rental_uris.web URL वैकल्पिक

ऐसा यूआरएल जिसका इस्तेमाल वेब ब्राउज़र, इस स्टेशन पर वाहन किराए पर लेने के बारे में ज़्यादा जानकारी दिखाने के लिए कर सकता है.

यह यूआरएल, किसी स्टेशन का डीप लिंक होना चाहिए. यह ऐसा सामान्य रेंटल पेज नहीं होना चाहिए जिसमें एक से ज़्यादा स्टेशनों की जानकारी शामिल हो. डीप लिंक ऐसा होना चाहिए जो उपयोगकर्ता को सीधे स्टेशन पर ले जाए. इसके लिए, किसी भी तरह के प्रॉम्प्ट, इंटरस्टीशियल पेज या लॉगिन की ज़रूरत नहीं होनी चाहिए. पक्का करें कि उपयोगकर्ताओं को स्टेशन दिखे, भले ही उन्होंने कभी ऐप्लिकेशन न खोला हो.

स्टेशन के लिए, यूआरएल में station_id शामिल करना ज़रूरी नहीं है. इसके अलावा, Android या iOS के लिए रेंटल यूआरएल के सिमैंटिक कन्वेंशनल का पालन करना भी ज़रूरी नहीं है. किराए पर वीडियो उपलब्ध कराने वाला ऐप्लिकेशन, यूआरएल में ऐसे अन्य आइडेंटिफ़ायर का इस्तेमाल कर सकता है जो स्टेशन की खास तौर पर पहचान करते हैं.

अगर इस फ़ील्ड को सेट नहीं किया जाता है, तो इसका मतलब है कि वेब ब्राउज़र के लिए डीप लिंक काम नहीं करते.

उदाहरण वैल्यू:

https://www.example.com/app?sid=1234567890

यहां station_information.json का उदाहरण दिया गया है:

"stations": [
  {
    "station_id": "597",
    "name": "Silverthorne Road, Battersea",
    "lat": 51.472865,
    "lon": -0.148059,
    "capacity": 10,
    "rental_uris": {
        "android": "https://www.example.com/app?sid=1234567890&platform=android",
        "ios": "https://www.exampleexample.com/app?sid=1234567890&platform=ios",
        "web": "https://www.example.com/app?sid=1234567890&platform=web"
    }
  },
]

ज़रूरी है: station_status.json (डॉक किया गया सिस्टम)

ज़रूरत के हिसाब से, GBFS स्पेसिफ़िकेशन देखें.

इस फ़ीड में, सार्वजनिक बाइक शेयरिंग स्टेशनों की मौजूदा स्थिति के बारे में अप-टू-डेट जानकारी होती है.

फ़ील्ड का नाम टाइप आवश्यकता ब्यौरा
stations Array ज़रूरी है ऑब्जेक्ट का कलेक्शन. इसमें हर ऑब्जेक्ट, सिर्फ़ एक स्टेशन के बारे में बताता है.
stations[].station_id स्ट्रिंग ज़रूरी है स्टेशन का आइडेंटिफ़ायर.
stations[].num_bikes_available सकारात्मक पूर्णांक ज़रूरी है

यह एक नॉन-नेगेटिव पूर्णांक है. यह स्टेशन पर मौजूद उन बाइकों की संख्या दिखाता है जो ठीक से काम कर रही हैं और जिन्हें किराए पर दिया जा सकता है.

यह पता लगाने के लिए कि स्टेशन पर फ़िलहाल साइकल किराए पर मिलती हैं या नहीं, आपको स्टेशन के is_renting फ़ील्ड की जांच करनी होगी. साथ ही, बूलियन वैल्यू के तौर पर सही वैल्यू ढूंढनी होगी.
stations[].vehicle_types_available Array वैकल्पिक

ऑब्जेक्ट का ऐसा कलेक्शन जो वाहनों की कुल संख्या के बारे में बताता है. साथ ही, स्टेशन पर उपलब्ध हर तरह के वाहन के हिसाब से उनकी संख्या के बारे में भी बताता है. हर ऑब्जेक्ट, उससे जुड़े वाहन के टाइप के लिए वाहनों की कुल संख्या को मॉडल करता है. इन ऑब्जेक्ट में मौजूद वाहनों की कुल संख्या, num_bikes_available फ़ील्ड में दी गई वैल्यू से मेल खानी चाहिए.
stations[].vehicle_types_available[].vehicle_type_id आईडी ज़रूरी है

स्टेशन पर उपलब्ध हर तरह के वाहन की vehicle_type_id. इसके बारे में vehicle_types.json में बताया गया है.
stations[].vehicle_types_available[].count सकारात्मक पूर्णांक ज़रूरी है

स्टेशन पर मौजूद vehicle_type_id के लिए उपलब्ध वाहनों की कुल संख्या. यह संख्या, vehicle_types.json में दी गई जानकारी के मुताबिक होती है.
stations[].num_docks_available सकारात्मक पूर्णांक कुछ शर्तों के मुताबिक ज़रूरी है

अगर स्टेशन पर डॉकिंग की सुविधा अनलिमिटेड नहीं है, तो इस फ़ील्ड की वैल्यू देना ज़रूरी है. उदाहरण के लिए, वर्चुअल स्टेशन में डॉकिंग की असीमित क्षमता होती है और इस फ़ील्ड की ज़रूरत नहीं होती.

यह एक नॉन-नेगेटिव पूर्णांक होता है. इससे स्टेशन पर मौजूद, काम कर रहे डॉक की कुल संख्या के बारे में पता चलता है. इन डॉक में वाहन वापस रखे जा सकते हैं.

यह पता लगाने के लिए कि स्टेशन पर फ़िलहाल बाइक वापस ली जा रही हैं या नहीं, आपको स्टेशन के is_returning फ़ील्ड की जांच करनी होगी. साथ ही, true बूलियन वैल्यू ढूंढनी होगी.
stations[].is_installed बूलियन ज़रूरी है

यह बूलियन वैल्यू है. इससे पता चलता है कि स्टेशन फ़िलहाल सड़क पर है और इंस्टॉल किया गया है या नहीं.

अगर स्टेशन को सड़क पर इंस्टॉल किया गया है, तो true पर सेट करें.

अगर स्टेशन सड़क पर इंस्टॉल नहीं किया गया है, तो false पर सेट करें.
stations[].is_renting बूलियन ज़रूरी है

यह बूलियन वैल्यू बताती है कि स्टेशन पर फ़िलहाल साइकल किराए पर मिलती हैं या नहीं.

अगर स्टेशन पर फ़िलहाल किराये पर साइकल मिलती हैं, तो इसे true पर सेट करें. अगर स्टेशन खाली भी है, लेकिन किराये पर लेने की अनुमति दी गई है, तो is_renting को true पर सेट किया जाता है.

अगर स्टेशन पर फ़िलहाल साइकल किराये पर नहीं मिलती हैं, तो false पर सेट करें.
stations[].is_returning बूलियन ज़रूरी है

यह एक बूलियन है. इससे पता चलता है कि स्टेशन पर फ़िलहाल साइकल वापस ली जाती हैं या नहीं.

अगर स्टेशन पर फ़िलहाल बाइक वापस लेने की सुविधा उपलब्ध है, तो true पर सेट करें. अगर स्टेशन में जगह नहीं है, लेकिन अगर जगह होती, तो बाइक को लौटाया जा सकता था, तो is_returning को true पर सेट किया जाता है.

अगर स्टेशन पर फ़िलहाल बाइक लौटाने की सुविधा उपलब्ध नहीं है, तो false पर सेट करें.

यहां station_status.json का उदाहरण दिया गया है:

"stations": [
        {
          "station_id": "2",
          "num_bikes_available": 6,
          "vehicle_types_available": [
            {
              "vehicle_type_id" : "scooter_electric",
              "count" : 2
            },
            {
              "vehicle_type_id" : "bike_manual",
              "count" : 4
            }
          ],
          "num_docks_available": 30,
          "is_installed": true,
          "is_renting": true,
          "is_returning": true,
          "last_reported": 1576119631
        },
]