Zapier या Make ऑटोमेशन को नए जियोकोडिंग होस्ट पर माइग्रेट करना
जियोकोडिंग चरण पर बने नो-कोड ऑटोमेशन के लिए कस्टम कोड से अलग माइग्रेशन तरीका चाहिए। यह बदलाव कैसे संभालें, यहाँ बताया गया है।
Nominatim को खुद होस्ट करना बनाम होस्टेड ड्रॉप-इन का उपयोग
Nominatim को खुद होस्ट करना एक जायज़ और अच्छी तरह दस्तावेज़ित रास्ता है, और बहुत से संगठन इसे सफलतापूर्वक चलाते हैं, खास तौर पर वे जिनके पास जियोकोडिंग इन्फ्रास्ट्रक्चर को पूरी तरह अपने नेटवर्क के भीतर रखने की ठोस वजहें हैं। लेकिन इसका समझौता असली है और इसे टालने के बजाय साफ़ कहना चाहिए: आप OpenStreetMap डेटा एक्सट्रैक्ट डाउनलोड और इंपोर्ट करने, स्वीकार्य गति से क्वेरी देने के लिए पर्याप्त डिस्क स्पेस और मेमोरी का इंतज़ाम करने, OpenStreetMap के अपडेट होने के साथ उस डेटा को ठीक-ठाक ताज़ा रखने, और सर्वर को उतने अपटाइम के साथ चलाने की ज़िम्मेदारी लेते हैं जितने की आपके एप्लिकेशन को ज़रूरत है।
इनमें से कुछ भी इस अर्थ में कठिन नहीं है कि वह अस्पष्ट हो या उसके दस्तावेज़ न हों। यह इस अर्थ में कठिन है कि यह लगातार चलने वाला काम है। खुद होस्ट किया गया Nominatim इंस्टेंस जो लॉन्च के दिन अच्छा काम कर रहा था, एक साल बाद अपनी प्रासंगिकता खो सकता है अगर किसी ने अपडेट प्रक्रिया शेड्यूल नहीं की, और यह पता लगाने के लिए कि कोई खास पता सही तरह मैच होना क्यों बंद हो गया, Nominatim सॉफ़्टवेयर और मूल OpenStreetMap डेटा की परिपाटियों, दोनों को समझना पड़ता है।
होस्ट किया गया ड्रॉप-इन विकल्प इस ऑपरेशनल परत को पूरी तरह हटा देता है, इस कीमत पर कि आपका जियोकोडिंग ट्रैफ़िक आपके अपने इन्फ्रास्ट्रक्चर के बजाय किसी तीसरे पक्ष के इन्फ्रास्ट्रक्चर से गुज़रता है। यहाँ असल फ़ैसला यही है, यह सवाल नहीं कि एक विकल्प सीधे-सीधे बेहतर है।
My Geocode का Nominatim कम्पैटिबिलिटी होस्ट ठीक वही रिस्पॉन्स संरचना देता है जो खुद होस्ट किया गया या सार्वजनिक Nominatim इंस्टेंस लौटाता है: स्ट्रिंग के रूप में display_name, lat और lon, और OpenStreetMap के अपने फ़ील्ड नामों, जैसे suburb और postcode, वाला एक address ऑब्जेक्ट, जिसमें सिर्फ़ कॉपीराइट, शर्तें और गोपनीयता का टेक्स्ट अलग है। संदर्भ जानकारी /compatibility/nominatim/ पर है। खुद होस्ट किए गए इंस्टेंस के लिए लिखे कोड में सिर्फ़ होस्ट और ऑथेंटिकेशन बदलने की ज़रूरत होनी चाहिए, क्योंकि फ़ील्ड संरचना वैसी ही रहती है।
कोई भी रास्ता चुनने से पहले कुछ सवालों का ईमानदारी से जवाब देना चाहिए:
- क्या आपके संगठन के पास अनुपालन या डेटा रेज़िडेंसी की कोई खास वजह है जो सेल्फ़-होस्टिंग से पूरी होती है और होस्ट की गई सेवा से नहीं
- खुद होस्ट किए गए इंस्टेंस के रखरखाव में अभी कितना इंजीनियरिंग समय लगता है, और वह समय कहीं और लगाने पर कितना मूल्यवान होता
- क्या आपका ट्रैफ़िक इतना ऊँचा और स्थिर है कि इन्फ्रास्ट्रक्चर की लागत पहले से उचित है, या यह इस तरह घटता-बढ़ता है कि प्रति अनुरोध या सब्सक्रिप्शन की अनुमान लगाने लायक लागत इसे ज़्यादा साफ़ तरीके से संभालती है
अगर जवाब खुद होस्ट किए गए इन्फ्रास्ट्रक्चर से हटने की ओर इशारा करता है, तो होस्ट की गई सेवा पर ऑथेंटिकेशन एक कुंजी से होता है जो X-API-Key, Authorization: Bearer, HTTP Basic auth या एक क्वेरी पैरामीटर के रूप में भेजी जाती है, और यह उस User-Agent आधारित उपयोग नीति की जगह लेता है जिसकी अपेक्षा सार्वजनिक Nominatim इंस्टेंस रखता है। मूल्य निर्धारण में बिना कुंजी के प्रतिदिन 2,500 मुफ़्त अनुरोध, हर कुंजी पर प्रतिदिन 2,500 और मुफ़्त अनुरोध (नेटवर्क के हिसाब से गिने जाते हैं), फिर €0.0001 प्रति अनुरोध पर प्रीपेड क्रेडिट या €50 प्रति माह की Unlimited कुंजी शामिल है, वही दर जो प्लेटफ़ॉर्म के हर दूसरे एंडपॉइंट की है। कई टीमों के लिए, सर्वर की लागत, इंजीनियरिंग रखरखाव के समय और अनुरोधों की मात्रा का इस मूल्य निर्धारण से हिसाब लगाना, सवाल को किसी भी तरफ़ सुलझाने का सबसे तेज़ तरीका है।