सीमा तक पहुँचने से पहले अपनी कुंजी के उपयोग पर नज़र रखें
काम के साथ-साथ अपने कोटा हेडर देखते रहने से पता चलता है कि कब सीमा करीब आ रही है, किसी अनुरोध के असल में अस्वीकार होने से काफ़ी पहले।
फ़्री-टेक्स्ट पता फ़ील्ड को संरचित हिस्सों में पार्स करें
एक अकेला फ़्री टेक्स्ट पते का फ़ील्ड इकट्ठा करना आसान है और बाद में उसके साथ काम करना मुश्किल, खास तौर पर जब आपको शहर के हिसाब से फ़िल्टर करना हो या क्षेत्र के हिसाब से समूह बनाना हो। फ़ॉरवर्ड जियोकोडिंग पते को निर्देशांकों में बदलने के साथ-साथ आपके लिए पार्सिंग भी कर देती है।
फ़्री टेक्स्ट भेजना
GET /v1/forward?q=1600 Pennsylvania Avenue, Washington, DC 20500&limit=1{
"status": "ok",
"query": "1600 Pennsylvania Avenue, Washington, DC 20500",
"results": [
{
"formatted": "1600 Pennsylvania Avenue NW, Washington, DC 20500",
"lat": 38.8977,
"lon": -77.0365,
"type": "address",
"precision": "house",
"confidence": 0.97,
"place_id": "def456",
"components": {"house_number": "1600", "street": "Pennsylvania Avenue NW", "city": "Washington", "region": "DC", "postcode": "20500", "country": "US"}
}
]
}घटकों को अलग-अलग सहेजना
components ऑब्जेक्ट मिल जाने के बाद, केवल मूल फ़्री टेक्स्ट स्ट्रिंग रखने के बजाय हर फ़ील्ड को उसके अपने डेटाबेस कॉलम में लिखें। इससे ग्राहक रिकॉर्ड को शहर या क्षेत्र के हिसाब से फ़िल्टर करना, सटीक क्षेत्रीय रिपोर्ट बनाना, और यह पुष्टि करना संभव होता है कि कोई पिन कोड और शहर सच में एक साथ मेल खाते हैं, और इनमें से कुछ भी एक अकेली असंरचित स्ट्रिंग पर व्यावहारिक नहीं है।
दूसरा उदाहरण: किसी अलग फ़ॉर्मैट वाला पता
पते की संरचना हर जगह एक जैसी नहीं होती। यूनाइटेड किंगडम का कोई पता US शैली के region की जगह county के साथ हल हो सकता है, और किसी नाम वाली इमारत के लिए house_number जैसा घटक पूरी तरह गायब हो सकता है। एक ही शैली का अनुरोध भेजना हर देश के लिए काम करता है, लेकिन आपको असल में वापस मिलने वाली घटक कुंजियाँ अलग हो सकती हैं, इसलिए अपना स्टोरेज स्कीमा ऐसा बनाएँ जो किसी घटक के न होने को सह सके, बजाय यह मानने के कि हर देश हर बार ठीक वही सेट भरेगा।
एक आम गलती जिससे बचना चाहिए
यह धारणा हार्डकोड न करें कि हर नतीजे में house_number, street, city, region और postcode, सभी होंगे, और फिर इनमें से किसी एक के बिना वाले हर पते को पार्सिंग एरर न मानें। एक पूरी तरह सही पता, खास तौर पर मकान नंबर वाले शहरी ग्रिड के बाहर, जायज़ तौर पर कुछ खाली फ़ील्ड के साथ लौट सकता है। घटकों के पूरे सेट के इर्द-गिर्द सख्त सत्यापन बनाने से ग्राहकों का वह असली इनपुट अस्वीकार हो जाएगा जिसे एंडपॉइंट ने सही तरह पार्स किया था।
मूल टेक्स्ट को भी रखना
मूल फ़्री टेक्स्ट इनपुट को हटाने के बजाय पार्स किए गए घटकों के साथ सहेजें। अगर कोई घटक अधूरा लौटता है या किसी ग्राहक को बाद में कुछ सुधारना हो, तो मूल टेक्स्ट पास होने से दोबारा पार्स करना या हाथ से सुधार करना आसान हो जाता है।
आंशिक पार्स को संभालना
हर पता हर घटक भरे हुए हल नहीं होता। कोई ग्रामीण पता बिना house_number के लौट सकता है, और कोई छोटा शहर बिना अलग region मान के। गायब घटक फ़ील्ड को पार्सिंग की विफलता के बजाय जायज़ तौर पर खाली मानें, और जब आपको चाहिए वाला कोई खास घटक मौजूद न हो, तो दिखाने के लिए formatted स्ट्रिंग का इस्तेमाल करें।
एक से ज़्यादा संभावित मिलान को संभालना
limit को 1 से ऊपर करने पर कई संभावित परिणाम लौटते हैं, जो इस क्रम में होते हैं कि हर परिणाम फ़्री टेक्स्ट से कितना अच्छा मेल खाता है। यह तब उपयोगी है जब आप चुपचाप सबसे ऊपर वाले मेल को अपनाने के बजाय ग्राहक को चुनने के लिए एक छोटी सूची दिखाना चाहते हैं। यह पूरी तरह स्वचालित पार्सिंग और पूरी तरह मैनुअल एंट्री फ़ॉर्म के बीच एक उचित बीच का रास्ता है, ख़ासकर उन पतों के लिए जिन्हें आपकी कॉन्फ़िडेंस सीमा वरना अनिश्चित के रूप में चिह्नित कर देती।
इसकी लागत क्या है
इस तरह किसी फ़्री-टेक्स्ट फ़ील्ड को पार्स करने में प्रति पता एक अनुरोध लगता है, बिल्कुल किसी भी अन्य फ़ॉरवर्ड जियोकोडिंग लुकअप की तरह। फ़्री-टेक्स्ट पतों की किसी मौजूदा टेबल को साफ़ करने वाला बैकफ़िल जॉब पूरी टेबल को एक बल्क अनुरोध के रूप में चला सकता है, प्रति पंक्ति एक अनुरोध।
फ़्री टेक्स्ट को संरचित फ़ील्ड में बदलना किसी पते को जियोकोड करने का एक स्वाभाविक परिणाम है, कोई अतिरिक्त चरण नहीं। फ़ॉरवर्ड जियोकोडिंग दस्तावेज़ में वे सभी घटक सूचीबद्ध हैं जो यह एंडपॉइंट लौटा सकता है।