सीमा तक पहुँचने से पहले अपनी कुंजी के उपयोग पर नज़र रखें
काम के साथ-साथ अपने कोटा हेडर देखते रहने से पता चलता है कि कब सीमा करीब आ रही है, किसी अनुरोध के असल में अस्वीकार होने से काफ़ी पहले।
अपार्टमेंट या यूनिट नंबर वाले पते जियोकोड करें
सड़क के पते में जोड़ा गया अपार्टमेंट नंबर बहुत से वास्तविक पतों का सामान्य हिस्सा है, और अनुरोध भेजने से पहले उसे हटा देने के बजाय, जो एक आम लेकिन अनावश्यक आदत है, यह समझना बेहतर है कि जियोकोडिंग लुकअप उसे कैसे संभालता है।
पूरा पता भेजना
अपार्टमेंट या यूनिट नंबर को फ़्री-टेक्स्ट क्वेरी के हिस्से के रूप में शामिल करें, ठीक वैसे ही जैसे पते का कोई और हिस्सा।
GET /v1/forward?q=Apt 4B, 350 Fifth Avenue, New York&limit=1{
"status": "ok",
"query": "Apt 4B, 350 Fifth Avenue, New York",
"results": [
{
"formatted": "350 Fifth Avenue, New York, NY",
"lat": 40.7484,
"lon": -73.9857,
"type": "address",
"precision": "house",
"confidence": 0.95,
"place_id": "es234",
"components": {"house_number": "350", "street": "Fifth Avenue", "city": "New York", "region": "NY", "country": "US"}
}
]
}यूनिट नंबर निर्देशांकों में क्यों नहीं दिखता
जियोकोडिंग लुकअप से मिले निर्देशांक किसी इमारत की पहचान करते हैं, उसके भीतर की किसी खास यूनिट की नहीं, क्योंकि अलग-अलग अपार्टमेंट की अपनी कोई अलग मैप की गई लोकेशन नहीं होती, जैसी किसी इमारत की होती है। पते के अपार्टमेंट या यूनिट वाले हिस्से से lat और lon की वैल्यू बदलने की उम्मीद नहीं की जाती, और components ऑब्जेक्ट में उसका न होना भी अपेक्षित है, यह इस बात का संकेत नहीं है कि इनपुट को अनदेखा किया गया या गलत तरीके से संभाला गया।
दूसरा उदाहरण: किसी व्यावसायिक इमारत में सुइट नंबर
सुइट या मंज़िल नंबर वाले व्यावसायिक पते पर भी यही पैटर्न लागू होता है।
GET /v1/forward?q=Suite 200, 1 Example Plaza, Chicago&limit=1दर्जनों अलग-अलग व्यवसायों वाली एक बड़ी ऑफ़िस इमारत भी इमारत के एक ही निर्देशांकों पर जियोकोड होती है, चाहे क्वेरी में किसी भी सुइट का नाम हो, ठीक वैसे ही जैसे कोई अपार्टमेंट इमारत। उस इमारत के भीतर एक किरायेदार को दूसरे से अलग करने वाली कोई भी जानकारी आपके अपने रिकॉर्ड में होनी चाहिए, निर्देशांकों में नहीं।
एक आम गलती जिससे बचना चाहिए
यूनिट घटक की कमी को बाद में खुद पिन कोड या किसी और घटक फ़ील्ड में जोड़कर पूरा करने की कोशिश न करें, जैसे पिन कोड को "20500 Apt 4B" के रूप में लिखना। ऐसा करने से वह फ़ील्ड दूषित हो जाता है जिससे दूसरे सिस्टम, जिनमें आपका अपना सत्यापन और आगे होने वाले पता लुकअप शामिल हैं, सिर्फ़ असली पिन कोड होने की उम्मीद करते हैं। यूनिट नंबर को उसके अपने फ़ील्ड में रखें, जो हर जियोकोड किए गए घटक से पूरी तरह अलग हो।
यूनिट नंबर को अलग से सहेजना
हर बार जियोकोड किए जाने वाले पते की स्ट्रिंग में यूनिट नंबर को मिलाने के बजाय, उसे अपने डेटा मॉडल में जियोकोड किए गए इमारत के पते के साथ उसके अपने फ़ील्ड के रूप में सहेजें। इससे जियोकोडिंग अनुरोध उसी पर केंद्रित रहता है जो वास्तव में परिणाम को प्रभावित करता है, यानी इमारत की लोकेशन, और साथ ही डिलीवरी लेबल या आंतरिक रिकॉर्ड के लिए यूनिट की जानकारी भी सुरक्षित रहती है।
जब डिलीवरी के लिए यह मायने रखता है
कूरियर या डाक सेवा को वास्तविक डिलीवरी के लिए यूनिट नंबर की ज़रूरत होती है, भले ही निर्देशांकों में उसकी कोई भूमिका न रही हो। दोनों हिस्सों, यानी जियोकोड किए गए इमारत के निर्देशांक और अलग से सहेजे गए यूनिट नंबर, को अंतिम डिलीवरी रिकॉर्ड में एक साथ रखें ताकि इस प्रक्रिया में कुछ भी न खोए।
एक विशेष मामला जो जानने लायक है
एक ही इमारत के पते पर बड़ी संख्या में अलग-अलग निवासी या किरायेदार हो सकते हैं, जो सभी एक ही निर्देशांक और एक ही पिन कोड लुकअप परिणाम साझा करते हैं। अगर आप किसी ग्राहक के पिन कोड का फ़ॉरवर्ड जियोकोड किए गए पते से मिलान कर रहे हैं, जैसा कि पिन कोड क्रॉस-चेक गाइड में बताया गया है, तो याद रखें कि यूनिटों और एक इमारत के बीच यह कई-से-एक का संबंध अपेक्षित है और अपने आप में डेटा की किसी समस्या का संकेत नहीं है।
लागत पर कोई असर नहीं
पते में अपार्टमेंट या यूनिट नंबर हो या न हो, लुकअप पर फिर भी एक ही अनुरोध लगता है, ठीक किसी भी दूसरी फ़ॉरवर्ड जियोकोडिंग कॉल की तरह।
क्वेरी में यूनिट नंबर शामिल करने से कोई नुकसान नहीं होता, और सटीक जियोकोडिंग के लिए उसे हटाना ज़रूरी नहीं है, हालाँकि बाद में उसे उसके अपने सहेजे गए फ़ील्ड में अलग करने से आपका डेटा ज़्यादा साफ़ रहता है। घटकों की पूरी सूची के लिए फ़ॉरवर्ड जियोकोडिंग दस्तावेज़ देखें।