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

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