सीमा तक पहुँचने से पहले अपनी कुंजी के उपयोग पर नज़र रखें
काम के साथ-साथ अपने कोटा हेडर देखते रहने से पता चलता है कि कब सीमा करीब आ रही है, किसी अनुरोध के असल में अस्वीकार होने से काफ़ी पहले।
हाइकिंग या साइक्लिंग रूट के लिए ऊँचाई प्रोफ़ाइल बनाएँ
ऊँचाई प्रोफ़ाइल बस बिंदुओं की एक सूची है जिसमें हर बिंदु के साथ एक ऊँचाई जुड़ी होती है, और जिसे रूट पर तय दूरी के सामने प्लॉट किया जाता है। elevation एंडपॉइंट आपको एक ही कॉल में उतने बिंदुओं की ऊँचाई देता है जितने आप भेजें।
रूट भेजना
points पैरामीटर के साथ अक्षांश और देशांतर जोड़ियों की एक शृंखला भेजें, जोड़ियाँ पाइप से अलग हों और हर जोड़ी के भीतर मान कॉमा से अलग हों।
GET /v1/elevation?points=45.8326,6.8652|45.8400,6.8700|45.8475,6.8750{
"status": "ok",
"results": [
{"lat": 45.8326, "lon": 6.8652, "elevation_m": 1035},
{"lat": 45.8400, "lon": 6.8700, "elevation_m": 1210},
{"lat": 45.8475, "lon": 6.8750, "elevation_m": 1390}
]
}नतीजों को प्रोफ़ाइल में बदलना
results का हर आइटम उसी स्थान पर भेजे गए बिंदु से मेल खाता है। elevation_m को लगातार बिंदुओं के बीच की संचयी दूरी के साथ जोड़ें, जिसे आप खुद निर्देशांकों से निकालते हैं, और आपके पास बिना किसी और लुकअप के प्रोफ़ाइल चार्ट के x और y मान होंगे।
bulk body इस्तेमाल करने वाला एक छोटा उदाहरण
अगर आप पाइप से अलग किए गए points पैरामीटर के बजाय एक संरचित array भेजना चाहते हैं, तो /v1/elevation पर निर्देशांक ऑब्जेक्ट्स का JSON array उसी तरह POST करें जैसे दूसरे एंडपॉइंट bulk body स्वीकार करते हैं।
POST /v1/elevation
Content-Type: application/json
[{"lat": 45.8326, "lon": 6.8652}, {"lat": 45.8400, "lon": 6.8700}]दोनों ही तरीकों में लागत एक जैसी है, हर बिंदु पर एक अनुरोध, इसलिए वही रूप चुनें जो आपके पास पहले से मौजूद डेटा संरचना से बनाना आसान हो, array से बनी query string या उसी तरह बना JSON array।
बिंदुओं के बीच का अंतर चुनना
हर कुछ मीटर पर सौ GPS बिंदुओं वाले रूट को पढ़ने योग्य प्रोफ़ाइल बनाने के लिए हर एक बिंदु की ऊँचाई की ज़रूरत नहीं है। लंबे रूट पर हर बीसवाँ या पचासवाँ बिंदु लेना, या बराबर दूरी के अंतराल पर दोबारा सैंपल करना, चार्ट को स्मूद रखते हुए अनुरोधों की संख्या घटाता है, क्योंकि points पैरामीटर का हर बिंदु एक अनुरोध गिना जाता है।
एक गलती जिससे बचना चाहिए
elevation_m को सेंटीमीटर तक सटीक मानना डेटा से उससे ज़्यादा माँगना है जितना ऊँचाई प्रोफ़ाइल को चाहिए। यह मान एक स्मूद, पढ़ने योग्य प्रोफ़ाइल बनाने और एक समझदार कुल चढ़ाई निकालने के लिए पर्याप्त सटीक है, लेकिन समतल ज़मीन पर एक मीटर की दूरी वाले दो बिंदु थोड़े अलग मान लौटा सकते हैं जो असली भूभाग के बारे में कुछ नहीं बताते। अपना चार्ट और चढ़ाई की गणनाएँ इस तरह बनाएँ कि वे इस तरह के छोटे शोर को सह सकें, बजाय हर उतार-चढ़ाव को रूट की असली विशेषता मानने के।
पानी या बिना मैप वाले भूभाग पर एक खास स्थिति
खुले पानी पर या कम ऊँचाई डेटा वाले क्षेत्र में पड़ने वाला बिंदु त्रुटि के बजाय कम या सपाट मान लौटा सकता है। अगर आपके रूट में फ़ेरी से पार करना या किसी दूरदराज़ भूभाग से गुज़रता हिस्सा शामिल है, तो यह मानने के बजाय कि संख्या हमेशा ठोस ज़मीन बताती है, अपनी प्रोफ़ाइल के असामान्य रूप से सपाट हिस्सों को मैप से मिलाकर जाँच लें।
इसकी लागत क्या है
सौ बिंदुओं की प्रोफ़ाइल यानी सौ अनुरोध, जो हर कुंजी के साथ शामिल या बिना कुंजी के एक पते से मिलने वाले 2,500 प्रतिदिन मुफ़्त अनुरोधों के भीतर आराम से है। रोज़ कई उपयोगकर्ताओं को सेवा देने वाले रूट प्लानिंग टूल को फिर भी अपने कोटा हेडर पर नज़र रखनी चाहिए, क्योंकि लोकप्रिय रूट की ऊँचाई प्रोफ़ाइल अकेले लुकअप की तुलना में तेज़ी से जुड़ती हैं।
ऊँचाई डेटा एक सपाट मैप को ऐसी चीज़ में बदल देता है जिसके आधार पर हाइकर या साइक्लिस्ट सच में योजना बना सके। पैरामीटर की पूरी सूची elevation लुकअप दस्तावेज़ पेज पर है।