Package google.type

इंडेक्स

LatLng

यह ऑब्जेक्ट, अक्षांश/देशांतर की जोड़ी को दिखाता है. इसे डबल के तौर पर दिखाया जाता है, ताकि अक्षांश और देशांतर की डिग्री को दिखाया जा सके. जब तक अलग से कोई जानकारी न दी जाए, तब तक इस ऑब्जेक्ट को WGS84 स्टैंडर्ड के मुताबिक होना चाहिए. वैल्यू, सामान्य की गई सीमाओं के अंदर होनी चाहिए.

फ़ील्ड
latitude

double

डिग्री में अक्षांश. यह [-90.0, +90.0] की रेंज में होना चाहिए.
longitude

double

डिग्री में देशांतर. यह [-180.0, +180.0] की रेंज में होना चाहिए.

LocalizedText

किसी भाषा में टेक्स्ट का स्थानीय भाषा में लिखा गया वर्शन.

फ़ील्ड
text

string

नीचे दिए गए language_code के हिसाब से, स्थानीय भाषा में लिखी गई स्ट्रिंग.
language_code

string

टेक्स्ट का BCP-47 भाषा कोड, जैसे कि "en-US" या "sr-Latn".

ज़्यादा जानकारी के लिए, http://www.unicode.org/reports/tr35/#Unicode_locale_identifier पर जाएं.

PostalAddress

यह किसी डाक पते को दिखाता है. जैसे, डाक या पेमेंट के पते. पते की मदद से, डाक सेवा किसी जगह, पीओ बॉक्स या इसी तरह की किसी अन्य जगह पर सामान डिलीवर कर सकती है. डाक पते का इस्तेमाल, सड़कों, कस्बों या पहाड़ों जैसी भौगोलिक जगहों को मॉडल करने के लिए नहीं किया जाता है.

आम तौर पर, उपयोगकर्ता के इनपुट या मौजूदा डेटा को इंपोर्ट करके पता बनाया जाता है. यह प्रोसेस के टाइप पर निर्भर करता है.

पता डालने या उसमें बदलाव करने के बारे में सलाह:

  • अंतरराष्ट्रीय स्तर पर इस्तेमाल किए जा सकने वाले पते के विजेट का इस्तेमाल करें. जैसे, https://github.com/google/libaddressinput.
  • उपयोगकर्ताओं को उन देशों के बाहर के फ़ील्ड में इनपुट या बदलाव करने के लिए यूज़र इंटरफ़ेस (यूआई) एलिमेंट नहीं दिखाए जाने चाहिए जहां उस फ़ील्ड का इस्तेमाल किया जाता है.

इस स्कीमा को इस्तेमाल करने के बारे में ज़्यादा जानकारी के लिए, यहां जाएं: https://support.google.com/business/answer/6397478.

फ़ील्ड
revision

int32

PostalAddress के स्कीमा में बदलाव किया गया. इसे 0 पर सेट किया जाना चाहिए, जो कि नया वर्शन है.

सभी नए वर्शन, पुराने वर्शन के साथ काम करने वाले होने चाहिए.
region_code

string

ज़रूरी है. पते में दिए गए देश/इलाके का CLDR कोड. इसकी जानकारी कभी नहीं दी जाती. यह उपयोगकर्ता पर निर्भर करता है कि वह यह पक्का करे कि वैल्यू सही है. ज़्यादा जानकारी के लिए, https://cldr.unicode.org/ और https://www.unicode.org/cldr/charts/30/supplemental/territory_information.html पर जाएं. उदाहरण: स्विट्ज़रलैंड के लिए "CH".
language_code

string

ज़रूरी नहीं. इस पते के कॉन्टेंट का BCP-47 भाषा कोड (अगर पता हो). यह अक्सर इनपुट फ़ॉर्म की यूज़र इंटरफ़ेस (यूआई) भाषा होती है. इसके अलावा, यह उस देश/इलाके में इस्तेमाल की जाने वाली भाषाओं में से किसी एक से मेल खानी चाहिए जहां का पता दिया गया है. साथ ही, यह भाषा, उस देश/इलाके में इस्तेमाल की जाने वाली भाषाओं के लिप्यंतरण से भी मेल खा सकती है. इससे कुछ देशों में फ़ॉर्मैटिंग पर असर पड़ सकता है. हालांकि, इससे डेटा के सही होने पर कोई असर नहीं पड़ता. साथ ही, इससे पुष्टि करने या फ़ॉर्मैटिंग से जुड़ी अन्य कार्रवाइयों पर कभी कोई असर नहीं पड़ेगा.

अगर यह वैल्यू पता नहीं है, तो इसे शामिल नहीं किया जाना चाहिए. इसके बजाय, ऐसी डिफ़ॉल्ट वैल्यू तय नहीं की जानी चाहिए जो शायद गलत हो.

उदाहरण: "zh-Hant", "ja", "ja-Latn", "en".
postal_code

string

ज़रूरी नहीं. पते का पिन कोड. सभी देशों में पिन कोड का इस्तेमाल नहीं किया जाता है. साथ ही, यह ज़रूरी नहीं है कि पिन कोड मौजूद हो. हालांकि, जहां इनका इस्तेमाल किया जाता है वहां पते के अन्य हिस्सों के साथ, इनकी पुष्टि करने की अतिरिक्त प्रोसेस शुरू हो सकती है. उदाहरण के लिए, अमेरिका में राज्य या पिन कोड की पुष्टि करना.
sorting_code

string

ज़रूरी नहीं. देश के हिसाब से क्रम से लगाने का अतिरिक्त कोड. इसका इस्तेमाल ज़्यादातर देशों/इलाकों में नहीं किया जाता. इसका इस्तेमाल करने पर, वैल्यू "CEDEX" जैसी स्ट्रिंग होती है. इसके बाद, संख्या (उदाहरण के लिए, "CEDEX 7") भी हो सकती है या सिर्फ़ एक संख्या हो सकती है. यह "सेक्टर कोड" (जमैका), "डिलीवरी एरिया इंडिकेटर" (मलावी) या "पोस्ट ऑफ़िस इंडिकेटर" (कोत द आइवर) को दिखाता है.
administrative_area

string

ज़रूरी नहीं. किसी देश या इलाके के डाक पते के लिए इस्तेमाल किया जाने वाला सबसे बड़ा एडमिनिस्ट्रेटिव सबडिविज़न. उदाहरण के लिए, यह कोई राज्य, प्रांत, ओब्लास्ट या प्रीफ़ेक्चर (प्रांत) हो सकता है. स्पेन के लिए, यह प्रांत है, न कि ऑटोनॉमस कम्यूनिटी (उदाहरण के लिए, "बार्सिलोना" और "कैटलोनिया" नहीं). कई देशों में, डाक पते में प्रशासनिक क्षेत्र का इस्तेमाल नहीं किया जाता. उदाहरण के लिए, स्विट्ज़रलैंड में इसे खाली छोड़ देना चाहिए.
locality

string

ज़रूरी नहीं. आम तौर पर, यह पते में शहर या कस्बे की जानकारी होती है. उदाहरण: अमेरिका का शहर, इटली का कम्यून, यूनाइटेड किंगडम का पोस्ट टाउन. दुनिया के जिन इलाकों में स्थानीयताएं ठीक से तय नहीं की गई हैं या इस स्ट्रक्चर में ठीक से फ़िट नहीं होती हैं वहां locality को खाली छोड़ें और address_lines का इस्तेमाल करें.
sublocality

string

ज़रूरी नहीं. पते का उप-इलाका. उदाहरण के लिए, यह कोई मोहल्ला, नगर या ज़िला हो सकता है.
address_lines[]

string

पते की ऐसी लाइनें जिनमें पते के निचले लेवल की जानकारी दी गई हो.

address_lines में मौजूद वैल्यू में टाइप की जानकारी नहीं होती है. साथ ही, कभी-कभी एक फ़ील्ड में कई वैल्यू हो सकती हैं. उदाहरण के लिए, "Austin, TX". इसलिए, लाइन का क्रम साफ़ तौर पर दिखना ज़रूरी है. पते की लाइनों का क्रम, पते के देश या इलाके के लिए "लिफ़ाफ़े के क्रम" के हिसाब से होना चाहिए. जिन जगहों पर यह क्रम अलग-अलग हो सकता है (उदाहरण के लिए, जापान), वहां address_language का इस्तेमाल करके इसे साफ़ तौर पर बताया जाता है. उदाहरण के लिए, बड़े से छोटे क्रम के लिए "ja" और छोटे से बड़े क्रम के लिए "ja-Latn" या "en". इस तरह, भाषा के आधार पर पते की सबसे सटीक लाइन चुनी जा सकती है.

पते के स्ट्रक्चरल फ़ॉर्मैट में कम से कम एक region_code होना चाहिए. बाकी जानकारी address_lines में होनी चाहिए. जियोकोडिंग के बिना, ऐसे पते को फ़ॉर्मैट करना काफ़ी मुश्किल होता है. हालांकि, जब तक पते के कॉम्पोनेंट को कम से कम आंशिक रूप से हल नहीं किया जाता, तब तक उनके बारे में कोई सिमैंटिक तर्क नहीं दिया जा सकता.

सिर्फ़ region_code और address_lines वाला पता बनाकर, उसे जियोकोड करना, पूरी तरह से अनस्ट्रक्चर्ड पतों को हैंडल करने का सबसे सही तरीका है. इससे यह अनुमान लगाने की ज़रूरत नहीं पड़ती कि पते के किन हिस्सों को इलाके या प्रशासनिक क्षेत्र के तौर पर इस्तेमाल किया जाना चाहिए.
recipients[]

string

ज़रूरी नहीं. पते पर मौजूद व्यक्ति. कुछ मामलों में, इस फ़ील्ड में एक से ज़्यादा लाइनों वाली जानकारी हो सकती है. उदाहरण के लिए, इसमें "देखभाल करने वाला" व्यक्ति की जानकारी शामिल हो सकती है.
organization

string

ज़रूरी नहीं. पते पर मौजूद संगठन का नाम.