GBFS परिभाषाएं

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

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

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

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

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

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

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

फ़ील्ड का नाम टाइप ज़रूरी शर्त ब्यौरा
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 (डॉक किया गया और बिना डॉक वाला सिस्टम)

ज़रूरत के हिसाब से जीबीएफ़एस की खास बातें देखें.

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

फ़ील्ड का नाम टाइप ज़रूरी शर्त ब्यौरा
system_id आईडी ज़रूरी है वाहन के शेयर सिस्टम के लिए, दुनिया भर में पहचाना जाने वाला यूनीक आइडेंटिफ़ायर. इस वैल्यू का मकसद सिस्टम में कोई बदलाव नहीं करना है. हर अलग सिस्टम या भौगोलिक क्षेत्र जिसमें वाहन ऑपरेट किए जाते हैं उनका अपना System_id होना चाहिए. सिस्टम आईडी को रैंडम स्ट्रिंग के बजाय किसी खास सिस्टम से जुड़े होने की पहचान होनी चाहिए. उदाहरण के लिए, bcycle_austin या Biketown_ppx.
name स्ट्रिंग ज़रूरी है सिस्टम का नाम, जो ग्राहकों को दिखाया जाता है.
rental_apps चीज़ ज़रूरी है JSON ऑब्जेक्ट जिसमें Android और iOS के लिए, किराये की जानकारी देने वाला ऐप्लिकेशन और उनसे जुड़ी फ़ील्ड की जानकारी होती है.
rental_apps.android चीज़ कुछ शर्तों के मुताबिक ज़रूरी है इसमें, store_uri और discovery_uri के फ़ील्ड में, Android प्लैटफ़ॉर्म के लिए किराये पर लेने से जुड़े ऐप्लिकेशन को डाउनलोड करने और ऐप्लिकेशन खोजने की जानकारी शामिल होती है. अगर सिस्टम की सेवा देने वाली कंपनी के पास 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 चीज़ कुछ शर्तों के मुताबिक ज़रूरी है इसमें store_uri और discovery_uri के फ़ील्ड में, iOS प्लैटफ़ॉर्म के लिए किराये पर लेने से जुड़े ऐप्लिकेशन को डाउनलोड करने और ऐप्लिकेशन खोजने की जानकारी शामिल है. अगर सिस्टम की सेवा देने वाली कंपनी के पास 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 (डॉकलेस सिस्टम)

ज़रूरत के हिसाब से जीबीएफ़एस की खास बातें देखें.

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

फ़ील्ड का नाम टाइप ज़रूरी शर्त ब्यौरा
bikes कैटगरी ज़रूरी है फ़िलहाल, उपलब्ध बाइक की एक कैटगरी, हर उस मंज़िल पर रुकी हुई है जहां हर साइकल एक ऑब्जेक्ट है.
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 की कस्टम यूआरएल स्कीम से जुड़े लेख देखें. दिए गए rental_uris को iOS यूनिवर्सल लिंक होना चाहिए, ताकि देखने वाले ऐप्लिकेशन को मैन्युअल तरीके से उपयोगकर्ता को ऐप स्टोर पर रीडायरेक्ट मैनेज करने की ज़रूरत न पड़े. ऐसा तब होगा, जब उपयोगकर्ता के लिए सेवा देने वाली कंपनी का ऐप्लिकेशन इंस्टॉल न किया गया हो.

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

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

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

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

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

bikes[].rental_uris.web यूआरएल ज़रूरी नहीं

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

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

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

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

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

https://www.example.com/app?sid=1234567890
bikes[].vehicle_type_id आईडी ज़रूरी है वाहन की vehicle_type_id, जो vehicle_types.json सेक्शन में बताई गई है.
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 (डॉक किया गया और बिना डॉक वाला सिस्टम)

ज़रूरत के हिसाब से जीबीएफ़एस की खास बातें देखें.

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

फ़ील्ड का नाम टाइप ज़रूरी शर्त ब्यौरा
vehicle_types कैटगरी ज़रूरी है ऑब्जेक्ट की कैटगरी, जहां हर ऑब्जेक्ट, सेवा देने वाली कंपनी के कैटलॉग में एक अलग वाहन के बारे में बताता है. किसी भी तरह के वाहन के लिए सिर्फ़ एक ऑब्जेक्ट हो सकता है.
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 (डॉकलेस सिस्टम)

ज़रूरत के हिसाब से जीबीएफ़एस की खास बातें देखें.

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

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

कीमत वाले प्लान में, यह बताया जा सकता है कि यह कीमत के हिसाब से नहीं दिया गया है. इसके अलावा, यह भी बताया जा सकता है:

रेट नहीं किया गया मूल्य प्लान

यह प्लान सिंगल और एक समान किराया है.

नीचे दिए गए फ़ील्ड सेट करें:

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

यह प्लान, बिना शुल्क के ली जाने वाली कीमत है.

नीचे दिए गए फ़ील्ड सेट करें:

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

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

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

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

ऑब्जेक्ट की श्रेणी जहां हर ऑब्जेक्ट, दिए गए दूरी से जुड़े सेगमेंट के बारे में बताता है. हर सेगमेंट की 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 मान शामिल नहीं होता.

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

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

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

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

ऑब्जेक्ट की श्रेणी जहां हर ऑब्जेक्ट, दिए गए समय के हिसाब से बांटे गए सेगमेंट की जानकारी देता है. हर सेगमेंट की 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 किसी नॉन-नेगेटिव पूर्णांक पर सेट न हों.

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

अगर सेगमेंट का end किसी गैर-नेगेटिव पूर्णांक पर सेट है, तो सेगमेंट का rate तब तक फिर से लागू किया जाता है, लेकिन इसमें सेगमेंट का 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 के लिए उदाहरण 1

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

  • [0,1): 2 डॉलर
    • अगर यात्रा एक मिनट से भी कम होती है, तो उपयोगकर्ता को दो डॉलर चुकाने होंगे.
    • उदाहरण: 59-सेकंड की यात्रा
  • [1,2): 3 डॉलर
    • अगर यात्रा एक मिनट से ज़्यादा है या दो मिनट से भी कम है, तो उपयोगकर्ता को दो डॉलर + एक डॉलर = तीन डॉलर चुकाने होंगे.
    • उदाहरण: 1 मिनट की यात्रा; 1 मिनट 45 सेकंड की यात्रा
  • x मिनट की संख्या, जहां x 2 से ज़्यादा या उसके बराबर है: $3 + ($2 + $1) * (x - 2 + 1)) USD
    • अगर यात्रा दो मिनट से ज़्यादा की है या दो मिनट से कम समय की है, तो उपयोगकर्ता दो मिनट से भी कम समय के लिए 3 डॉलर चुकाएंगे. साथ ही, $1 [per_min_pricing सूची की पहली एंट्री से जारी रहेगा] + दो मिनट [per_min_pricing सूची की दूसरी एंट्री]) जिसमें दो मिनट लगेंगे.
    • उदाहरण:
      • दो मिनट वाली यात्रा का शुल्क 3 डॉलर (2 डॉलर + 1 डॉलर) = 6 डॉलर
      • 2-मिनट 30-सेकंड की यात्रा की कीमत 3 डॉलर (2 डॉलर + 1 डॉलर) = 6 डॉलर
      • तीन मिनट वाली यात्रा के लिए तीन डॉलर + ($2 + $1) * 2) = 9 डॉलर
      • 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 के लिए उदाहरण 2

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

  • खास तौर पर, असली उपयोगकर्ता से हर कि॰मी॰ के लिए 0.25 कनेडियन डॉलर और हर मिनट 0.50 कनेडियन डॉलर लिए जाते हैं.
  • ये दोनों दरें एक साथ होती हैं और एक-दूसरे पर निर्भर नहीं होती हैं.
  • इसलिए, 10 मिनट के लिए की जाने वाली एक किलोमीटर की यात्रा के लिए 9 कनेडियन डॉलर लगते हैं. विज्ञापन की कीमत नीचे दी गई है:
    • 3 डॉलर, मूल कीमत
    • $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
    }]
  }
}

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

ज़रूरत के हिसाब से जीबीएफ़एस की खास बातें देखें.

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

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

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

जियोफ़ेंस किए गए हर ज़ोन, इससे जुड़े नियम, और एट्रिब्यूट और FeatureCollection की परिभाषाएं, यहां geofencing_zones.json फ़ीड की परिभाषाओं के हिस्से के तौर पर दी गई हैं.
geofencing_zones.type स्ट्रिंग ज़रूरी है IETF RFC 7946 के मुताबिक, FeatureCollection पर सेट करें.
geofencing_zones.features कैटगरी ज़रूरी है JSON कलेक्शन, जहां JSON कलेक्शन का हर एलिमेंट, Feature ऑब्जेक्ट होता है.
geofencing_zones.features[].type स्ट्रिंग ज़रूरी है IETF RFC 7946 के मुताबिक, Feature पर सेट करें.
geofencing_zones.features[].geometry जियोJSON मल्टीपॉलीगॉन ज़रूरी है भौगोलिक JSON पॉलीगॉन, जो बताता है कि राइड अन्य सीमाओं के अलावा, कहां से शुरू, खत्म, और खत्म नहीं हो सकतीं. घड़ी की दिशा में बिंदुओं को लगाकर, पॉलीगॉन के आस-पास के इलाके को परिभाषित करता है, जबकि घड़ी से उलटी दिशा में पॉलीगॉन के बाहर का इलाका तय किया जाता है. इस बारे में ज़्यादा जानकारी के लिए, दाईं ओर मौजूद नियम देखें.
geofencing_zones.features[].properties चीज़ ज़रूरी है एक ऑब्जेक्ट जो यात्रा की भत्तियों और सीमाओं के बारे में बताता है.
geofencing_zones.features[].properties.rules कैटगरी ज़रूरी नहीं ऑब्जेक्ट की कैटगरी, जहां हर ऑब्जेक्ट एक और सिर्फ़ एक नियम के बारे में बताता है. अगर दो या उससे ज़्यादा नियम किसी तरह से ओवरलैप करते हैं, आपस में टकराते हैं या किसी तरह से आपस में टकराते हैं, तो JSON फ़ाइल के क्रम में सबसे पहले तय किए गए नियम को प्राथमिकता दी जाती है.
geofencing_zones.features[].properties.rules[].vehicle_type_id कैटगरी ज़रूरी नहीं वाहन के टाइप आईडी की कैटगरी, जहां हर एलिमेंट एक 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 (डॉक सिस्टम)

ज़रूरत के हिसाब से जीबीएफ़एस की खास बातें देखें.

इस फ़ीड में, साइकल शेयर करने के लिए सार्वजनिक स्टेशन के बारे में सामान्य जानकारी दी गई है.

फ़ील्ड का नाम टाइप ज़रूरी शर्त ब्यौरा
stations कैटगरी ज़रूरी है ऑब्जेक्ट की श्रेणी, जिसमें हर ऑब्जेक्ट एक और सिर्फ़ एक स्टेशन के बारे में बताता है.
stations[].station_id स्ट्रिंग ज़रूरी है स्टेशन का आइडेंटिफ़ायर.
stations[].name स्ट्रिंग ज़रूरी है उस स्टेशन की सार्वजनिक भाषा में स्टेशन का सार्वजनिक नाम जहां स्टेशन मौजूद है. name को स्टेशन पर लगे साइनबोर्ड पर जहां भी इस्तेमाल किया जाना चाहिए वहां बताया जाना चाहिए. साथ ही, क्रॉस स्ट्रीट या स्थानीय लैंडमार्क की मदद से स्टेशन के पते की जानकारी देनी चाहिए. "St&&tt; जैसे"Street" के लिए शॉर्ट फ़ॉर्म का इस्तेमाल न करें. ऐसा तब तक करें, जब तक कि इसका इस्तेमाल साइनबोर्ड में साफ़ तौर पर न किया गया हो. साथ ही, 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 पर स्टेशन के लिए किराये पर ऐप्लिकेशन लॉन्च करने के लिए किया जा सकता है. इस बारे में ज़्यादा जानकारी के लिए, iOS की कस्टम यूआरएल स्कीम के बारे में Apple के लेख पढ़ें. rental_uris को iOS यूनिवर्सल लिंक में शामिल किया जाना चाहिए, ताकि ऐप्लिकेशन देखने के लिए इस्तेमाल होने वाले ऐप्लिकेशन को मैन्युअल रूप से, उपयोगकर्ता के लिए ऐप्लिकेशन स्टोर पर रीडायरेक्ट को मैनेज न करना पड़े. ऐसा तब होना चाहिए, जब उपयोगकर्ता के पास ऐप्लिकेशन इंस्टॉल करने का विकल्प न हो.

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

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

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

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

https://www.example.com/app?sid=1234567890&platform=ios
stations[].rental_uris.web यूआरएल ज़रूरी नहीं

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

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

यूआरएल के लिए स्टेशन के 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 (डॉक किया हुआ सिस्टम)

ज़रूरत के हिसाब से जीबीएफ़एस की खास बातें देखें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

बूलियन, जिससे यह पता चलता है कि वह स्टेशन बाइक चलाने की सुविधा देता है या नहीं.

अगर स्टेशन फ़िलहाल बाइक लौटाने की सुविधा देता है, तो true पर सेट करें. भले ही, स्टेशन भर गया हो, लेकिन अगर यह #39;t था, तो लौटाए जाने की अनुमति देता है, 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
        },
]