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