सीमा तक पहुँचने से पहले अपनी कुंजी के उपयोग पर नज़र रखें
काम के साथ-साथ अपने कोटा हेडर देखते रहने से पता चलता है कि कब सीमा करीब आ रही है, किसी अनुरोध के असल में अस्वीकार होने से काफ़ी पहले।
GPX रूट फ़ाइल में ऊँचाई का डेटा जोड़ें
फ़ोन या साधारण GPS डिवाइस से रिकॉर्ड की गई GPX फ़ाइल में ऊँचाई के मान अक्सर पूरी तरह गायब होते हैं या साफ़ तौर पर गलत होते हैं, क्योंकि उपभोक्ता GPS की ऊँचाई रीडिंग आमतौर पर उसके दर्ज अक्षांश और देशांतर से कहीं कम भरोसेमंद होती है।
बिंदु निकालना
GPX फ़ाइल के ट्रैक पॉइंट पार्स करें, हर एक से केवल अक्षांश और देशांतर निकालें, और ऊँचाई के वे मौजूदा मान हटा दें जिन्हें आप बदलने वाले हैं।
<trkpt lat="45.8326" lon="6.8652"><ele>1050</ele></trkpt>सही ऊँचाई लुकअप करना
निकाले गए निर्देशांक /v1/elevation को भेजें, छोटी फ़ाइल के लिए points पैरामीटर से या बड़ी फ़ाइल के लिए बल्क POST array से।
POST /v1/elevation
Content-Type: application/json
[{"lat": 45.8326, "lon": 6.8652}, {"lat": 45.8400, "lon": 6.8700}]{
"status": "ok",
"results": [
{"lat": 45.8326, "lon": 6.8652, "elevation_m": 1035},
{"lat": 45.8400, "lon": 6.8700, "elevation_m": 1210}
]
}दूसरा उदाहरण: एक ट्रेलहेड की जाँच
हर उपयोग के लिए पूरा ट्रैक प्रोसेस करना ज़रूरी नहीं। हाइक का विवरण प्रकाशित करने से पहले एक ही कॉल ट्रेलहेड पर ऊँचाई की पुष्टि कर देती है।
GET /v1/elevation?lat=45.8326&lon=6.8652यह एक एंट्री के साथ उसी आकार का परिणाम लौटाता है, जो पूरी GPX फ़ाइल को छुए बिना ट्रेल नोट्स में बताए गए शुरुआती या अंतिम ऊँचाई के आँकड़े की त्वरित जाँच के लिए उपयोगी है।
मान वापस लिखना
परिणाम उसी क्रम में लौटते हैं जिसमें आपने निर्देशांक भेजे थे, इसलिए स्थिति के आधार पर मिलान करते हुए elevation_m को हर ट्रैक पॉइंट के ele टैग में वापस लिखें, मूल दर्ज मान की जगह लुकअप किया गया मान रखते हुए।
<trkpt lat="45.8326" lon="6.8652"><ele>1035</ele></trkpt>एक आम गलती जिससे बचना चाहिए
एक ही जॉब में points क्वेरी पैरामीटर फ़ॉर्मेट और बल्क POST बॉडी को मिलाकर इस्तेमाल न करें, जब तक कि आप परिणामों को ट्रैक पॉइंट से वापस मिलाने के तरीके में एकरूप न हों। points पैरामीटर और JSON array दोनों परिणाम दिए गए क्रम में लौटाते हैं, लेकिन एक बिंदु के निर्देशांक क्वेरी पैरामीटर से और बाकी बल्क POST से लेना, फिर दोनों रिस्पॉन्स सेट को स्पष्ट निर्देशांक मिलान के बजाय अनुमान के आधार पर जोड़ना, वापस लिखी गई फ़ाइल में एक स्थान खिसकने वाली (off-by-one) गलती लाने का आसान तरीका है।
कितने बिंदुओं को समृद्ध करना है, यह तय करना
एक GPX फ़ाइल में छोटे अंतराल पर दर्ज हज़ारों ट्रैक पॉइंट हो सकते हैं। हर एक को समृद्ध करना प्रति बिंदु एक अनुरोध है, जो लंबे रिकॉर्ड किए गए ट्रैक पर बढ़ जाता है। ऊँचाई लुकअप से पहले मोटे अंतराल पर डाउनसैंपल करना, फिर बीच के बिंदुओं के लिए लुकअप किए गए मानों के बीच इंटरपोलेट करना, अनुरोधों की संख्या घटाते हुए भी सटीक दिखने वाली प्रोफ़ाइल बनाने का उचित तरीका है।
एक खास मामला: तटीय और निचले बिंदु
तटरेखा के साथ या किसी निचले डेल्टा से गुज़रने वाला ट्रैक वैध रूप से शून्य या उसके आसपास का elevation_m मान लौटा सकता है, या कभी-कभी समुद्र तल से नीचे की ज़मीन के लिए छोटी ऋणात्मक संख्या। इनमें से कोई भी त्रुटि नहीं है। शून्य के आसपास के मान को खराब डेटा पॉइंट मानकर हटाने के बजाय उस इलाके की संभावित वास्तविक रीडिंग मानें।
इसकी लागत क्या है
हर समृद्ध किया गया बिंदु एक अनुरोध है। कुछ सौ बिंदुओं वाला सामान्य हाइकिंग ट्रैक, जो कहीं बड़ी मूल रिकॉर्डिंग से डाउनसैंपल किया गया हो, हर कुंजी के साथ शामिल 2,500 प्रतिदिन मुफ़्त अनुरोधों के भीतर आराम से रहता है।
इस तरह ऊँचाई का डेटा साफ़ करने से फ़ोन से रिकॉर्ड किया गया अस्थिर ट्रैक साझा करने या विश्लेषण करने लायक बन जाता है। ऊँचाई लुकअप दस्तावेज़ में points पैरामीटर और बल्क अनुरोध फ़ॉर्मेट दोनों का वर्णन है।