सीमा तक पहुँचने से पहले अपनी कुंजी के उपयोग पर नज़र रखें
काम के साथ-साथ अपने कोटा हेडर देखते रहने से पता चलता है कि कब सीमा करीब आ रही है, किसी अनुरोध के असल में अस्वीकार होने से काफ़ी पहले।
एक आसान "निकटतम ऑफ़िस" खोजक बनाएँ
कुछ गिने-चुने ऑफ़िसों वाली कंपनी को "मेरे सबसे पास कौन-सा ऑफ़िस है" का जवाब देने के लिए कुछ भी जटिल नहीं चाहिए, बस एक जियोकोडिंग अनुरोध और एक ऐसी सूची से छोटी-सी तुलना जो शायद ही कभी बदलती है।
इनपुट की जियोकोडिंग
विज़िटर चाहे पता टाइप करे या पिन कोड, निर्देशांक पाने के लिए उसकी जियोकोडिंग करें।
GET /v1/forward?q=Berlin, Germany&limit=1{
"status": "ok",
"results": [
{"formatted": "Berlin, Germany", "lat": 52.5200, "lon": 13.4050, "type": "locality", "precision": "city", "confidence": 0.85, "place_id": "bl456", "components": {"city": "Berlin", "country": "DE"}}
]
}अपनी ऑफ़िस सूची से तुलना
अपने ऑफ़िसों के निर्देशांक अपने कोड या कॉन्फ़िगरेशन में एक छोटी, तय सूची के रूप में रखें, क्योंकि यह शायद ही कभी बदलती है और हर बार इसके लिए अलग लुकअप की ज़रूरत नहीं होती।
offices = [
{"name": "Berlin", "lat": 52.5170, "lon": 13.3888},
{"name": "Paris", "lat": 48.8566, "lon": 2.3522},
{"name": "London", "lat": 51.5074, "lon": -0.1278}
]मानक haversine फ़ॉर्मूले से विज़िटर के निर्देशांकों से हर ऑफ़िस तक की दूरी निकालें, फिर दूरी के अनुसार क्रम लगाएँ और सबसे नज़दीकी मिलान लौटाएँ।
दूसरा उदाहरण: टाइप-अहेड फ़ील्ड जोड़ना
एक सादे टेक्स्ट बॉक्स के बजाय, लोकेशन फ़ील्ड के पीछे /v1/autocomplete लगाने से विज़िटर टाइप करते समय सुझाई गई जगहों में से चुन सकता है, जिससे किसी टाइपो के कारण अनपेक्षित जियोकोडिंग नतीजा आने की संभावना घटती है। सुझाव चुने जाने के बाद, उसके place_id या उसके टेक्स्ट को उसी फ़ॉरवर्ड जियोकोडिंग प्रक्रिया से हल करने पर नतीजा सीधे ऊपर बताई गई उसी दूरी की तुलना में पहुँच जाता है।
शहर-स्तर के मिलान को संभालना
ध्यान दें कि ऊपर के उदाहरण में precision "house" के बजाय "city" है, क्योंकि विज़िटर ने केवल शहर का नाम दर्ज किया था। ऑफ़िस खोजक के लिए यह ठीक है, जहाँ लक्ष्य किसी सटीक इमारत का पता लगाना नहीं, बल्कि कुछ विकल्पों में से निकटतम ऑफ़िस चुनना है। यहाँ मोटी precision को उस तरह विशेष रूप से संभालने की ज़रूरत नहीं है जैसी डिलीवरी पते के लिए हो सकती है।
एक आम गलती जिससे बचना चाहिए
जब कोई भौतिक ऑफ़िस खुले, बंद हो या कहीं और जाए, तो अपने कोड में ऑफ़िसों की तय सूची अपडेट करना न भूलें। क्योंकि यह सूची API में नहीं, बल्कि आपके अपने कॉन्फ़िगरेशन में रहती है, इसलिए इसका चुपचाप पुराना पड़ जाना आसान है, जिससे विज़िटर बिना किसी संकेत के किसी बंद जगह की ओर भेजे जाते हैं या कोई नया ऑफ़िस हर तुलना से पूरी तरह छूट जाता है। इस सूची को एक बार के सेटअप चरण के बजाय अपनी नियमित कंटेंट समीक्षा का हिस्सा मानें।
एक खास स्थिति: अस्पष्ट जगह का नाम
कोई छोटा जगह का नाम कभी-कभी एक से ज़्यादा असली स्थानों से मेल खा सकता है, जैसे ऐसा नाम जो किसी देश और कहीं और के किसी असंबंधित क्षेत्र दोनों का हो। countries पैरामीटर देकर संभावित मिलानों को उन्हीं देशों तक सीमित करने से, जहाँ आपके वास्तव में ऑफ़िस हैं, इस तरह की अस्पष्टता दुनिया के बिल्कुल दूसरे छोर पर हल होने से बच जाती है।
सिर्फ़ निकटतम से ज़्यादा दिखाना
सिर्फ़ एक निकटतम ऑफ़िस के बजाय दो या तीन सबसे नज़दीकी ऑफ़िस दिखाने से किसी क्षेत्रीय सीमा के पास के विज़िटर को वह ऑफ़िस चुनने का मौका मिलता है जो वास्तव में उसके लिए सही हो, जैसे ऐसा ऑफ़िस जिसकी भाषा या समय क्षेत्र बेहतर मेल खाता हो, भले ही वह दूरी में थोड़ा ज़्यादा हो।
इसकी लागत क्या है
हर खोज एक जियोकोडिंग अनुरोध है। आपकी ऑफ़िस सूची से तुलना बाद में पूरी तरह आपके अपने कोड में होती है और आपके अनुरोधों की गिनती में कुछ नहीं जोड़ती। ऐसा पेज, लगातार ट्रैफ़िक के साथ भी, हर कुंजी के साथ शामिल 2,500 प्रतिदिन मुफ़्त अनुरोधों के भीतर आराम से रहता है।
इस तरह बने निकटतम ऑफ़िस खोजक को हर विज़िटर खोज पर ठीक एक अनुरोध चाहिए, और तुलना का असली लॉजिक पूरी तरह आपकी तरफ़ रहता है। अनुरोध के फ़ॉर्मेट की जानकारी फ़ॉरवर्ड जियोकोडिंग दस्तावेज़ में है।