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