PostalAddress

यह किसी डाक पते को दिखाता है, जैसे डाक डिलीवरी या पेमेंट के पतों के लिए. डाक पता होने पर, डाक सेवा, पी.ओ. Box या उससे मिलता-जुलता. इसका मकसद, भौगोलिक जगहों (सड़कों, शहरों, पहाड़ों) को मॉडल करना नहीं है.

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

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

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

JSON के काेड में दिखाना
{
  "revision": integer,
  "regionCode": string,
  "languageCode": string,
  "postalCode": string,
  "sortingCode": string,
  "administrativeArea": string,
  "locality": string,
  "sublocality": string,
  "addressLines": [
    string
  ],
  "recipients": [
    string
  ],
  "organization": string
}
फ़ील्ड
revision

integer

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

सभी नए संशोधन पुराने संशोधनों के साथ भी पुराने तरीके से काम करने वाले होने चाहिए.

regionCode

string

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

languageCode

string

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

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

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

postalCode

string

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

sortingCode

string

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

administrativeArea

string

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

locality

string

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

sublocality

string

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

addressLines[]

string

पते के निचले लेवल के बारे में बताने वाली अव्यवस्थित पता पंक्तियां.

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

किसी पते के स्ट्रक्चर के तौर पर, कम से कम regionCode की जानकारी होनी चाहिए. बाकी जानकारी, addressLines में दी जाती है. ऐसे पते को जियोकोडिंग के बिना भी फ़ॉर्मैट किया जा सकता है. हालांकि, पते के किसी भी कॉम्पोनेंट के बारे में तब तक कोई सेमेटिक वजह नहीं बताई जा सकती, जब तक कि उसे कम से कम कुछ हद तक हल नहीं किया जाता.

बिना क्रम के दिए गए पतों को मैनेज करने के लिए, हमारा सुझाव है कि आप सिर्फ़ regionCode और addressLines वाला पता बनाएं. इसके बाद, उसे जियोकोड करें. ऐसा करने से, यह अनुमान लगाने की ज़रूरत नहीं पड़ेगी कि पते के कौनसे हिस्से इलाके या प्रशासनिक क्षेत्र होने चाहिए.

recipients[]

string

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

organization

string

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