PostalAddress

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

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

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

  • अंतरराष्ट्रीय स्तर पर इस्तेमाल किए जा सकने वाले पते के विजेट का इस्तेमाल करें, जैसे कि 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 कोड. इसका अनुमान कभी नहीं लगाया जाता. यह उपयोगकर्ता पर निर्भर करता है कि वह सही वैल्यू डाले. ज़्यादा जानकारी के लिए, https://cldr.unicode.org/ और https://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

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

string

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

string

पते की ऐसी लाइनें जो व्यवस्थित नहीं हैं और पते के निचले लेवल के बारे में बताती हैं.

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

पते को स्ट्रक्चर्ड तरीके से दिखाने के लिए, कम से कम regionCode का इस्तेमाल करना ज़रूरी है. साथ ही, बाकी की जानकारी addressLines में होनी चाहिए. जियोकोडिंग के बिना, किसी पते को काफ़ी हद तक फ़ॉर्मैट किया जा सकता है. हालांकि, पते के किसी भी कॉम्पोनेंट के बारे में तब तक कोई सटीक जानकारी नहीं दी जा सकती, जब तक कि उसे कम से कम आंशिक रूप से हल न कर लिया जाए.

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

string

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

string

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