सीमा तक पहुँचने से पहले अपनी कुंजी के उपयोग पर नज़र रखें
काम के साथ-साथ अपने कोटा हेडर देखते रहने से पता चलता है कि कब सीमा करीब आ रही है, किसी अनुरोध के असल में अस्वीकार होने से काफ़ी पहले।
बिना मकान नंबर वाले पतों को संभालें
हर पते में मकान नंबर नहीं होता। ग्रामीण रास्ते, कुछ नई बस्तियाँ और जाने-माने लैंडमार्क अक्सर बिना मकान नंबर के बताए जाते हैं, और हर बार मकान नंबर की उम्मीद पर बना जियोकोडिंग अनुरोध यह गलत समझेगा कि इनके लिए वैध परिणाम कैसा दिखता है।
मकान नंबर के बिना रिस्पॉन्स कैसा दिखता है
GET /v1/forward?q=Golden Gate Bridge, San Francisco&limit=1{
"status": "ok",
"query": "Golden Gate Bridge, San Francisco",
"results": [
{
"formatted": "Golden Gate Bridge, San Francisco, CA",
"lat": 37.8199,
"lon": -122.4783,
"type": "address",
"precision": "street",
"confidence": 0.9,
"place_id": "gb567",
"components": {"city": "San Francisco", "region": "CA", "country": "US"}
}
]
}ध्यान दें कि यहाँ components में कोई house_number फ़ील्ड नहीं है, और precision में "house" के बजाय "street" लिखा है। ऐसे पते के लिए, जिसमें सच में मकान नंबर नहीं है, ये दोनों बातें अपेक्षित हैं, विफल या अधूरे लुकअप के संकेत नहीं।
precision को सही ढंग से पढ़ना
precision को एरर संकेतक के रूप में नहीं, बल्कि इस विवरण के रूप में देखें कि मिलान कितना सटीक है। "house" precision का मतलब है कि मिलान किसी खास इमारत तक रिज़ॉल्व हुआ। "street" precision का मतलब है कि वह किसी सड़क या उस पर किसी बिंदु तक रिज़ॉल्व हुआ, किसी सटीक इमारत को तय किए बिना, जो किसी लैंडमार्क या सच में मकान नंबर से रहित पते के लिए बिल्कुल सही है।
दूसरा उदाहरण: एक जाना-माना सार्वजनिक स्थान
GET /v1/forward?q=Central Park, New York&limit=1इस तरह का नाम वाला सार्वजनिक स्थान आम तौर पर ऐसे रिज़ॉल्व होता है कि type "address" से ज़्यादा व्यापक किसी चीज़ पर सेट होता है और precision किसी एक बिंदु के बजाय एक क्षेत्र को दर्शाता है, साथ में एक components ऑब्जेक्ट जिसमें सिर्फ़ शहर और क्षेत्र हो सकते हैं। यह पुल वाले उदाहरण जैसा ही पैटर्न है: एक वास्तविक, उपयोगी परिणाम जिसे ईमानदारी से किसी खास इमारत के बजाय एक क्षेत्र को कवर करने वाला बताया गया है, क्योंकि क्वेरी वास्तव में उसी की बात कर रही थी।
सत्यापन लॉजिक को उसी हिसाब से बदलना
अगर आपका फ़ॉर्म सत्यापन फ़िलहाल किसी पते को पूरा मानने से पहले house_number फ़ील्ड की मौजूदगी ज़रूरी करता है, तो वह जाँच वैध ग्रामीण पतों और लैंडमार्क को गलत तरीके से अस्वीकार कर देगी। हर खास घटक के भरे होने की शर्त रखने के बजाय स्वीकृति के मानदंड इस पर आधारित रखें कि confidence और precision आपकी वास्तविक ज़रूरत से मेल खाते हैं या नहीं।
एक आम गलती जिससे बचना चाहिए
खाली components ऑब्जेक्ट, या कई फ़ील्ड से रहित ऑब्जेक्ट, को विफल अनुरोध के बराबर न मानें। विफल अनुरोध एक एरर स्टेटस और एक एरर कोड के साथ लौटता है, जिसका वर्णन एरर दस्तावेज़ में है। कम घटकों वाला सफल परिणाम एक अलग, पूरी तरह सामान्य नतीजा है, और अपनी एरर हैंडलिंग में दोनों को मिला देने से वैध पते विफलताओं के रूप में लॉग होंगे और वैसे ही माने जाएँगे।
ग्राहकों को अस्वीकार करने के बजाय पुष्टि करने देना
बिना मकान नंबर वाले पते के लिए, सबमिशन को सीधे अस्वीकार करने के बजाय फ़ॉर्मैट किया गया परिणाम पुष्टि के लिए ग्राहक को वापस दिखाना बेहतर काम करता है। इससे एक असली पता उपयोग लायक बना रहता है, जबकि वास्तव में खराब इनपुट दूसरी जगहों पर फिर भी पकड़ा जाता है।
उल्टी दिशा में भी यही पैटर्न है
खुले ग्रामीण इलाके या पानी में स्थित किसी निर्देशांक की रिवर्स जियोकोडिंग भी, किसी खास इमारत के क्षेत्र पर स्थित निर्देशांक की तुलना में, कम बारीक precision और कम भरे हुए घटकों के साथ लौट सकती है। रिवर्स जियोकोडिंग दस्तावेज़ उस दिशा से यही precision वैल्यू बताते हैं।
लागत वही रहती है
बिना मकान नंबर वाले पते पर भी किसी भी दूसरे फ़ॉरवर्ड जियोकोडिंग लुकअप की तरह एक ही अनुरोध लगता है। घटकों का न होना इस पर कोई असर नहीं डालता कि अनुरोध का बिल आपके दैनिक कोटा या क्रेडिट बैलेंस से कैसे कटता है।
इसे सही ढंग से संभालना मुख्य रूप से precision और confidence को उनके इच्छित अर्थ में पढ़ने के बारे में है, यह मानने के बजाय कि हर वैध पते में हर घटक पूरी तरह भरा होना चाहिए। फ़ॉरवर्ड जियोकोडिंग दस्तावेज़ हर फ़ील्ड को विस्तार से समझाते हैं।