चेकआउट से पहले जाँचना कि पता अपने बताए गए पिन कोड से मेल खाता है
ऑर्डर फ़ॉर्म पर पिन कोड और शहर का मेल न खाना एक छोटी सी टाइपिंग गलती लगती है, जब तक कि वह देश के बिल्कुल गलत हिस्से में भेजी गई डिलीवरी में न बदल जाए।
साइकिलिंग ऐप के लिए ऊँचाई प्रोफ़ाइल बनाना
रूट की योजना बनाने वाले साइकिल चालक किसी भी दूसरी संख्या से ज़्यादा एक संख्या की परवाह करते हैं: कितनी चढ़ाई करनी होगी। चालीस मील का समतल रास्ता और चालीस मील का पहाड़ी रास्ता पूरी तरह अलग सवारियाँ हैं, और रूट प्लानिंग के लिए बने एक साइकिलिंग ऐप को यह अंतर किसी के सवारी शुरू करने से पहले दिखाने का तरीका चाहिए था, न कि तब जब वह तीन पहाड़ियाँ चढ़ चुका हो और पछता रहा हो।
ऐप के पास रूट पहले से ही निर्देशांकों के क्रम के रूप में मौजूद थे, जिन्हें उसका अपना रूटिंग इंजन शुरुआती और अंतिम बिंदु से बनाता था। उसके पास उन बिंदुओं में से हर एक की ऊँचाई नहीं थी। /v1/elevation ने इसे सीधे हल कर दिया: इसे निर्देशांकों की एक सूची भेजिए, चाहे एक बिंदु हो या किसी रूट के साथ लंबा क्रम, और यह हर एक के लिए ज़मीन की ऊँचाई लौटाता है। अपनी लंबाई में दो सौ बिंदुओं वाला रूट दो सौ ऊँचाई मानों के रूप में वापस आया, उसी क्रम में जिसमें उन्हें भेजा गया था, तय की गई दूरी के सामने प्रोफ़ाइल के रूप में प्लॉट करने के लिए तैयार।
कुल दूरी के सामने चार्ट की गई यही सूची वह चढ़ाई चार्ट है जिसे साइकिल चालक वास्तव में देखना चाहते हैं: पहाड़ियाँ कहाँ हैं, आसपास के बिंदुओं की तुलना में चढ़ाई कितनी खड़ी दिखती है, और समतल हिस्से कहाँ हैं। ऐप ने इसका उपयोग किसी रूट की कुल ऊँचाई बढ़त निकालने के लिए किया, एक ऐसी संख्या जो यह तय करने वाले साइकिल चालकों के लिए कि कोई रूट आज़माना है या नहीं, कुल दूरी से ज़्यादा मायने रखने वाली साबित हुई।
क्योंकि किसी रूट में उसकी लंबाई के आधार पर कुछ दर्जन से लेकर कुछ सौ तक बिंदु हो सकते थे, और क्योंकि बल्क ऊँचाई अनुरोध हर बिंदु को एक बिल किए गए आइटम के रूप में गिनता है, इसलिए ऐप ने हर सवारी के लिए सबसे बारीक संभव रिज़ॉल्यूशन पर ऊँचाई माँगने के बजाय यह समायोजित किया कि वह प्रति रूट कितने बिंदुओं का नमूना लेता है। हर कुछ सौ मीटर पर नमूना लिया गया एक आसान रूट उतना ही उपयोगी प्रोफ़ाइल देता था जितना हर दस मीटर पर नमूना लिया गया रूट, और अनुरोधों की मात्रा उसका एक छोटा हिस्सा होती थी, और परिणामी चार्ट देखने वाले साइकिल चालक को यह अंतर दिखता ही नहीं था।
ऐप ने साइकिल चालक को ज़रूरत पड़ने पर किसी एक बिंदु की जाँच करने की सुविधा भी दी, यानी मैप पर कहीं भी टैप करके उस सटीक जगह की ऊँचाई देखना, जिसमें पूरे रूट के बजाय एक बिंदु वाले अनुरोध के साथ वही एंडपॉइंट उपयोग होता था। एक बिंदु और बैच, दोनों मामले एक ही कॉल से चलते हैं, जिससे ऐप का कोड सरल रहा: एक फ़ंक्शन जो निर्देशांकों की सूची लेता है और ऊँचाइयों की मेल खाती सूची लौटाता है, जिसका उपयोग तुरंत टैप और पूरे रूट प्लान, दोनों के लिए होता है।
ट्रैफ़िक इस बात से बढ़ा कि साइकिल चालकों ने कितने रूट की योजना बनाई, न कि इस बात से कि उन्होंने वास्तव में कितनी सवारियाँ कीं, क्योंकि सहेजे गए रूट की प्रोफ़ाइल केवल एक बार निकालनी होती थी। सक्रिय लेकिन बहुत बड़े नहीं उपयोगकर्ता आधार वाले ऐप के लिए इससे ऊँचाई लुकअप प्रतिदिन मुफ़्त कोटा के भीतर आराम से रहे, और अगर कोई लोकप्रिय नई सुविधा रूट प्लानिंग में उछाल लाती, तो प्रीपेड क्रेडिट अगला स्वाभाविक कदम था।
ऊँचाई उन गिने-चुने एंडपॉइंट में से एक है जहाँ असली उदाहरण देना आसान है: तटीय सवारी अपने शुरुआती बिंदुओं के लिए समुद्र तल के करीब ऊँचाई मान दिखाएगी और जैसे-जैसे रूट अंदर की ओर चढ़ता है, बढ़ते मान दिखाएगी, एक ऐसा चार्ट जो साइकिल चालक को एक नज़र में कुछ बता देता है। अनुरोध के प्रारूप और बिंदुओं की सीमा का विवरण /docs/elevation-lookup/ पर है।