এই দস্তাবেজটি অনেকগুলি বাস্তব-বিশ্বের পরিস্থিতি বর্ণনা করে যেখানে ঠিকানা যাচাইকরণ API ঠিকানাগুলির জন্য প্রতিক্রিয়া সংকেত প্রদান করে যা আপনার সিস্টেম থেকে একটি নিশ্চিত আচরণের নিশ্চয়তা দেয়৷ প্রসঙ্গটির জন্য আপনার বৈধতা যুক্তি তৈরি করুন - এ ওয়ার্কফ্লো ওভারভিউ দেখুন।
সাধারণ উদাহরণ: নিশ্চিত করুন
নিচের উদাহরণটি একই রকম রাস্তার নামের সাথে মেট্রোপলিটন এলাকার ক্ষেত্রে চিত্রিত করে। ধরুন একজন ব্যবহারকারী কির্কল্যান্ড, WA, মার্কিন যুক্তরাষ্ট্রে Google বিল্ডিং ডি- এর ঠিকানা লিখতে চান৷ যাইহোক, শহর হিসাবে কার্কল্যান্ডের পরিবর্তে, তারা অসাবধানতাবশত সিয়াটলে প্রবেশ করে।
ঠিকানা দেওয়া হয়েছে | অঞ্চল |
---|---|
বিল্ডিং D, 451 7th Avenue South, Seattle, WA 98033 | মার্কিন |
প্রতিস্থাপিত ডেটার জন্য রায়
নীচের উদাহরণটি প্রতিক্রিয়া থেকে গুরুত্বপূর্ণ সংকেতগুলির উপর জোর দেয়।
{
"inputGranularity": "SUB_PREMISE",
"validationGranularity": "PREMISE_PROXIMITY",
"geocodeGranularity": "PREMISE_PROXIMITY",
"addressComplete": true,
"hasUnconfirmedComponents": true
"hasReplacedComponents": true
}
PREMISE_PROXIMITY
একটি বিল্ডিং-স্তরের ঠিকানার প্রক্সিমেশন নির্দেশ করে, কিন্তু SUB_PREMISE
এর মতো বিস্তারিত নয়, যা ইনপুটে দেওয়া গ্রানুলারিটি। প্রতিক্রিয়াটিতে অনিশ্চিত এবং প্রতিস্থাপিত উভয় উপাদানই রয়েছে, তাই সংমিশ্রণটি এটিকে নিশ্চিত বিভাগে নির্দেশ করে।
ঠিকানা উপাদানগুলির একটি প্রশ্ন উদ্বেগের নিম্নলিখিত ক্ষেত্রগুলি প্রকাশ করে:
{
"componentName": {
"text": "451",
},
"componentType": "street_number",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
...
{
"componentName": {
"text": "98104",
},
"componentType": "postal_code",
"confirmationLevel": "CONFIRMED",
"replaced": true
}
...
{
"componentName": {
"text": "Building D",
"language_code": "en"
},
"componentType": "subpremise",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
.......
"unconfirmedComponentTypes": [
"street_number",
"subpremise"
]
এই ক্ষেত্রে, ঠিকানা যাচাইকরণ এপিআই সিয়াটলে প্রদত্ত ঠিকানার কাছাকাছি আনুমানিকতা খুঁজে পেয়েছে এবং এটি সিয়াটেল ঠিকানার সমাধান করার জন্য জিপ কোড, একটি উচ্চ-স্তরের উপাদান প্রতিস্থাপন করেছে। এটি একটি বৈধ প্রতিস্থাপন হতে পারে, তবে উপাদানগুলি অনিশ্চিত হওয়ার সাথে সাথে, এটি নিশ্চিত করা বোধগম্য যে ব্যবহারকারী সিয়াটেল ঠিকানা লিখতে চান এবং কার্কল্যান্ডের মতো অন্য কিছু নয়।
এজ-কেস উদাহরণ: নিশ্চিত করুন
নিম্নলিখিত উদাহরণগুলি নিম্নলিখিত এজ কেস প্রকারগুলিকে চিত্রিত করে:
- ক্ষুদ্র অনুমান যা নিশ্চিত করা হয়েছে । ঠিকানা যাচাইকরণ এপিআই দেশ, পোস্টাল কোড বা রাজ্যকে অনুমান করে, তবে বাকি সবকিছু সরবরাহ করা এবং নিশ্চিত করা হয়। গ্রানুলারিটি এবং কনফার্মেশন লেভেল উভয়ের সংমিশ্রণ একটি গৌণ অনুমানের জন্য তৈরি করে যা নিশ্চিত ক্রিয়ার প্রয়োজন হয় না।
- অপ্রত্যাশিত ঠিকানা উপাদান নিশ্চিত করা হয়নি । অনিশ্চিত ঠিকানা উপাদান ঠিকানা ঝুঁকি স্তর যোগ. এটি একটি নিশ্চিতকরণের নিশ্চয়তা দিতে পারে।
- অপ্রত্যাশিত ঠিকানা উপাদান যা নিশ্চিত করেছে । সঠিক ঠিকানার জন্য উপাদানটি কঠোরভাবে প্রয়োজন হয় না এবং ঠিকানা যাচাইকরণ API এটিকে আউটপুট থেকে সরিয়ে দেয়। ফর্ম্যাটিং সমস্যাগুলি সাধারণত নিশ্চিতকরণের নিশ্চয়তা দেয় না।
ক্ষুদ্র অনুমান যা নিশ্চিত করা হয়েছে
আরও দানাদার স্তরের নিশ্চিত ডেটার সাথে মিলিত হলে, যদি ইনপুটটি নিম্নলিখিত ধরণেরগুলির মধ্যে শুধুমাত্র একটি উপাদান অনুপস্থিত থাকে তবে API এখনও একটি সঠিক অনুমান করতে পারে:
- শহর
- রাজ্য
- পোস্টাল কোড
- দেশ
উদাহরণস্বরূপ, একজন গ্রাহক ম্যাসাচুসেটসের স্প্রিংফিল্ডে একটি ম্যাকডোনাল্ডস রেস্টুরেন্টের জন্য একটি বৈধ রাস্তার ঠিকানা প্রদান করেন, কিন্তু শহরে প্রবেশ করতে ভুলে যান এবং 4-সংখ্যার এক্সটেনশন ছাড়াই একটি জিপ কোড প্রদান করেন।
ঠিকানা দেওয়া হয়েছে | অঞ্চল |
---|---|
1402 অ্যালেন সেন্ট, এমএ 01118 | মার্কিন |
নিখোঁজ শহরের জন্য রায়
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"addressComplete": true,
"hasInferredComponents": true
}
এমন পরিস্থিতিতে যেখানে ঠিকানা যাচাইকরণ API একটি বিতরণযোগ্য ঠিকানা তৈরি করার জন্য উচ্চ-স্তরের উপাদানগুলিকে অনুমান করে, আপনি উচ্চ স্তরের আস্থা রাখতে পারেন যে সিস্টেম থেকে ডেটা সঠিক। এর কারণ হল যে অনুমানকৃত উপাদানগুলি একটি বিস্তৃত ভৌগলিক অঞ্চলের প্রতিনিধিত্ব করে তা নিশ্চিত হওয়া ঠিকানা উপাদানগুলির সাথে আরও সহজে মিলে যায় যা আরও দানাদার। এমনকি যেসব দেশে শহরের নাম পুনরাবৃত্তি হয়, যেমন মার্কিন যুক্তরাষ্ট্রে স্প্রিংফিল্ড, এর সাথে মিলিত অন্যান্য উপাদানগুলি একটি অনন্য ঠিকানা প্রদান করতে পারে।
উপরের আমাদের উদাহরণ ব্যবহার করে, সমস্ত ঠিকানা উপাদান জুড়ে একটি স্ক্যান দেখায় যে প্রতিটি উপাদান নিশ্চিত করা হয়েছে, যার মানে এটি ঠিকানা যাচাইকরণ API দ্বারা সংরক্ষিত ডেটার সাথে মেলে, এবং পরিষেবাটি দুটি উচ্চ-স্তরের উপাদানগুলিকেও অনুমান করে৷
{
"componentName": {
"text": "Springfield",
"languageCode": "en"
},
"componentType": "locality",
"confirmationLevel": "CONFIRMED",
"inferred": true
},
{
"componentName": {
"text": "1806"
},
"componentType": "postal_code_suffix",
"confirmationLevel": "CONFIRMED",
"inferred": true
}
অপ্রত্যাশিত ঠিকানা উপাদান নিশ্চিত করা হয়নি
উপাদানগুলি নিশ্চিত না হলে এই দৃশ্যটি পরীক্ষা করার গুরুত্বকে ব্যাখ্যা করে। যদি একটি ঠিকানা উপাদান অপ্রত্যাশিত হয়, ঠিকানা যাচাইকরণ API এটিকে আউটপুট থেকে সরিয়ে দেয়। এই ক্ষেত্রে, আপনি আপনার ঝুঁকির স্তর এবং আত্মবিশ্বাসের স্তরের উপর নির্ভর করে ঠিকানাটি গ্রহণ করতে পারেন বা গ্রাহকের সাথে এটি পুনরায় নিশ্চিত করতে পারেন৷
উদাহরণস্বরূপ, একটি ঠিকানা এমন একটি অঞ্চলের হতে পারে যেখানে গ্রাহকরা প্রায়ই পোস্টাল কর্তৃপক্ষের দ্বারা উপেক্ষা করে ক্ষতিকারক তথ্য প্রবেশ করান, সেক্ষেত্রে আপনি ঠিকানাটি গ্রহণ করবেন৷ যাইহোক, কিছু ক্ষেত্রে একটি অপ্রমাণিত উপাদান গ্রাহক যা চান তা নাও হতে পারে।
ঠিকানা দেওয়া হয়েছে | অঞ্চল |
---|---|
1 Rue Grenache, la caritat 2, 34630 Saint-Thibery | ফ্রান্স |
অপ্রত্যাশিত ঠিকানা উপাদানের জন্য রায় নিশ্চিত করা হয়নি
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"unconfirmedComponents": true
}
অপ্রমাণিত উপাদান সহ একটি রায় ছাড়াও, ঠিকানা যাচাইকরণ API নিম্নলিখিত বিন্যাসিত ঠিকানা প্রদান করে:
"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",
অনিশ্চিত উপাদানগুলির জন্য একটি স্ক্যান দেখায় যে API ফেরত ঠিকানা থেকে la caritat 2 সরিয়ে দিয়েছে:
{
"componentName": {
"text": "la caritat 2",
"languageCode": "fr"
},
"componentType": "sublocality_level_1",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
"unexpected": true
}
অপ্রত্যাশিত ঠিকানা উপাদান যা IS নিশ্চিত করেছে৷
এই উদাহরণটি সরবরাহ করা ঠিকানায় একটি UK কাউন্টির অন্তর্ভুক্তির চিত্র তুলে ধরে, যা একটি সাধারণ অভ্যাস। যাইহোক, এটি ইউকে পোস্টাল কর্তৃপক্ষের দ্বারা একটি প্রয়োজনীয়তা নয় এবং মূলত উপেক্ষা করা হয়। দেখুন postoffice.co.uk এবং কিভাবে UK এবং আন্তর্জাতিক মেইল এড্রেস করবেন ।
ফলস্বরূপ, যখন একজন গ্রাহক একটি UK ঠিকানায় একটি কাউন্টি প্রদান করে, পরিষেবাটি এটিকে অপ্রত্যাশিত ইনপুট হিসাবে মূল্যায়ন করে।
ঠিকানা দেওয়া হয়েছে | অঞ্চল |
---|---|
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP | যুক্তরাজ্য |
অপ্রত্যাশিত ঠিকানা উপাদানের জন্য রায় যা IS নিশ্চিত করেছে
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE"
}
এখানে, address_complete
মিথ্যা মূল্যায়ন করে এবং ঠিকানা উপাদানের একটি বিশ্লেষণ একটি অপ্রত্যাশিত পতাকা প্রকাশ করে।
{
"componentName": {
"text": "Gloucestershire",
"languageCode": "en"
},
"componentType": "administrative_area_level_2",
"confirmationLevel": "CONFIRMED",
"unexpected": true
}
যদিও প্রবেশ করা ঠিকানার জন্য Gloucestershire সঠিক কাউন্টি, ঠিকানাটি নিজেই ভুলভাবে ফরম্যাট করা হয়েছে। মনে রাখবেন যে ঠিকানা যাচাইকরণ API সঠিক বিন্যাসের জন্য তথ্য মূল্যায়ন করে।
,এই দস্তাবেজটি অনেকগুলি বাস্তব-বিশ্বের পরিস্থিতি বর্ণনা করে যেখানে ঠিকানা যাচাইকরণ API ঠিকানাগুলির জন্য প্রতিক্রিয়া সংকেত প্রদান করে যা আপনার সিস্টেম থেকে একটি নিশ্চিত আচরণের নিশ্চয়তা দেয়৷ প্রসঙ্গটির জন্য আপনার বৈধতা যুক্তি তৈরি করুন - এ ওয়ার্কফ্লো ওভারভিউ দেখুন।
সাধারণ উদাহরণ: নিশ্চিত করুন
নিচের উদাহরণটি একই রকম রাস্তার নামের সাথে মেট্রোপলিটন এলাকার ক্ষেত্রে চিত্রিত করে। ধরুন একজন ব্যবহারকারী কির্কল্যান্ড, WA, মার্কিন যুক্তরাষ্ট্রে Google বিল্ডিং ডি- এর ঠিকানা লিখতে চান৷ যাইহোক, শহর হিসাবে কার্কল্যান্ডের পরিবর্তে, তারা অসাবধানতাবশত সিয়াটলে প্রবেশ করে।
ঠিকানা দেওয়া হয়েছে | অঞ্চল |
---|---|
বিল্ডিং D, 451 7th Avenue South, Seattle, WA 98033 | মার্কিন |
প্রতিস্থাপিত ডেটার জন্য রায়
নীচের উদাহরণটি প্রতিক্রিয়া থেকে গুরুত্বপূর্ণ সংকেতগুলির উপর জোর দেয়।
{
"inputGranularity": "SUB_PREMISE",
"validationGranularity": "PREMISE_PROXIMITY",
"geocodeGranularity": "PREMISE_PROXIMITY",
"addressComplete": true,
"hasUnconfirmedComponents": true
"hasReplacedComponents": true
}
PREMISE_PROXIMITY
একটি বিল্ডিং-স্তরের ঠিকানার প্রক্সিমেশন নির্দেশ করে, কিন্তু SUB_PREMISE
এর মতো বিস্তারিত নয়, যা ইনপুটে দেওয়া গ্রানুলারিটি। প্রতিক্রিয়াটিতে অনিশ্চিত এবং প্রতিস্থাপিত উভয় উপাদানই রয়েছে, তাই সংমিশ্রণটি এটিকে নিশ্চিত বিভাগে নির্দেশ করে।
ঠিকানা উপাদানগুলির একটি প্রশ্ন উদ্বেগের নিম্নলিখিত ক্ষেত্রগুলি প্রকাশ করে:
{
"componentName": {
"text": "451",
},
"componentType": "street_number",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
...
{
"componentName": {
"text": "98104",
},
"componentType": "postal_code",
"confirmationLevel": "CONFIRMED",
"replaced": true
}
...
{
"componentName": {
"text": "Building D",
"language_code": "en"
},
"componentType": "subpremise",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
.......
"unconfirmedComponentTypes": [
"street_number",
"subpremise"
]
এই ক্ষেত্রে, ঠিকানা যাচাইকরণ এপিআই সিয়াটলে প্রদত্ত ঠিকানার কাছাকাছি আনুমানিকতা খুঁজে পেয়েছে এবং এটি সিয়াটেল ঠিকানার সমাধান করার জন্য জিপ কোড, একটি উচ্চ-স্তরের উপাদান প্রতিস্থাপন করেছে। এটি একটি বৈধ প্রতিস্থাপন হতে পারে, তবে উপাদানগুলি অনিশ্চিত হওয়ার সাথে সাথে, এটি নিশ্চিত করা বোধগম্য যে ব্যবহারকারী সিয়াটেল ঠিকানা লিখতে চান এবং কার্কল্যান্ডের মতো অন্য কিছু নয়।
এজ-কেস উদাহরণ: নিশ্চিত করুন
নিম্নলিখিত উদাহরণগুলি নিম্নলিখিত এজ কেস প্রকারগুলিকে চিত্রিত করে:
- ক্ষুদ্র অনুমান যা নিশ্চিত করা হয়েছে । ঠিকানা যাচাইকরণ এপিআই দেশ, পোস্টাল কোড বা রাজ্যকে অনুমান করে, তবে বাকি সবকিছু সরবরাহ করা এবং নিশ্চিত করা হয়। গ্রানুলারিটি এবং কনফার্মেশন লেভেল উভয়ের সংমিশ্রণ একটি গৌণ অনুমানের জন্য তৈরি করে যা নিশ্চিত ক্রিয়ার প্রয়োজন হয় না।
- অপ্রত্যাশিত ঠিকানা উপাদান নিশ্চিত করা হয়নি । অনিশ্চিত ঠিকানা উপাদান ঠিকানা ঝুঁকি স্তর যোগ. এটি একটি নিশ্চিতকরণের নিশ্চয়তা দিতে পারে।
- অপ্রত্যাশিত ঠিকানা উপাদান যা নিশ্চিত করেছে । সঠিক ঠিকানার জন্য উপাদানটি কঠোরভাবে প্রয়োজন হয় না এবং ঠিকানা যাচাইকরণ API এটিকে আউটপুট থেকে সরিয়ে দেয়। ফর্ম্যাটিং সমস্যাগুলি সাধারণত নিশ্চিতকরণের নিশ্চয়তা দেয় না।
ক্ষুদ্র অনুমান যা নিশ্চিত করা হয়েছে
আরও দানাদার স্তরের নিশ্চিত ডেটার সাথে মিলিত হলে, যদি ইনপুটটি নিম্নলিখিত ধরণেরগুলির মধ্যে শুধুমাত্র একটি উপাদান অনুপস্থিত থাকে তবে API এখনও একটি সঠিক অনুমান করতে পারে:
- শহর
- রাজ্য
- পোস্টাল কোড
- দেশ
উদাহরণস্বরূপ, একজন গ্রাহক ম্যাসাচুসেটসের স্প্রিংফিল্ডে একটি ম্যাকডোনাল্ডস রেস্টুরেন্টের জন্য একটি বৈধ রাস্তার ঠিকানা প্রদান করেন, কিন্তু শহরে প্রবেশ করতে ভুলে যান এবং 4-সংখ্যার এক্সটেনশন ছাড়াই একটি জিপ কোড প্রদান করেন।
ঠিকানা দেওয়া হয়েছে | অঞ্চল |
---|---|
1402 অ্যালেন সেন্ট, এমএ 01118 | মার্কিন |
নিখোঁজ শহরের জন্য রায়
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"addressComplete": true,
"hasInferredComponents": true
}
এমন পরিস্থিতিতে যেখানে ঠিকানা যাচাইকরণ API একটি বিতরণযোগ্য ঠিকানা তৈরি করার জন্য উচ্চ-স্তরের উপাদানগুলিকে অনুমান করে, আপনি উচ্চ স্তরের আস্থা রাখতে পারেন যে সিস্টেম থেকে ডেটা সঠিক। এর কারণ হল যে অনুমানকৃত উপাদানগুলি একটি বিস্তৃত ভৌগলিক অঞ্চলের প্রতিনিধিত্ব করে তা নিশ্চিত হওয়া ঠিকানা উপাদানগুলির সাথে আরও সহজে মিলে যায় যা আরও দানাদার। এমনকি যেসব দেশে শহরের নাম পুনরাবৃত্তি হয়, যেমন মার্কিন যুক্তরাষ্ট্রে স্প্রিংফিল্ড, এর সাথে মিলিত অন্যান্য উপাদানগুলি একটি অনন্য ঠিকানা প্রদান করতে পারে।
উপরের আমাদের উদাহরণ ব্যবহার করে, সমস্ত ঠিকানা উপাদান জুড়ে একটি স্ক্যান দেখায় যে প্রতিটি উপাদান নিশ্চিত করা হয়েছে, যার মানে এটি ঠিকানা যাচাইকরণ API দ্বারা সংরক্ষিত ডেটার সাথে মেলে, এবং পরিষেবাটি দুটি উচ্চ-স্তরের উপাদানগুলিকেও অনুমান করে৷
{
"componentName": {
"text": "Springfield",
"languageCode": "en"
},
"componentType": "locality",
"confirmationLevel": "CONFIRMED",
"inferred": true
},
{
"componentName": {
"text": "1806"
},
"componentType": "postal_code_suffix",
"confirmationLevel": "CONFIRMED",
"inferred": true
}
অপ্রত্যাশিত ঠিকানা উপাদান নিশ্চিত করা হয়নি
উপাদানগুলি নিশ্চিত না হলে এই দৃশ্যটি পরীক্ষা করার গুরুত্বকে ব্যাখ্যা করে। যদি একটি ঠিকানা উপাদান অপ্রত্যাশিত হয়, ঠিকানা যাচাইকরণ API এটিকে আউটপুট থেকে সরিয়ে দেয়। এই ক্ষেত্রে, আপনি আপনার ঝুঁকির স্তর এবং আত্মবিশ্বাসের স্তরের উপর নির্ভর করে ঠিকানাটি গ্রহণ করতে পারেন বা গ্রাহকের সাথে এটি পুনরায় নিশ্চিত করতে পারেন৷
উদাহরণস্বরূপ, একটি ঠিকানা এমন একটি অঞ্চলের হতে পারে যেখানে গ্রাহকরা প্রায়ই পোস্টাল কর্তৃপক্ষের দ্বারা উপেক্ষা করে ক্ষতিকারক তথ্য প্রবেশ করান, সেক্ষেত্রে আপনি ঠিকানাটি গ্রহণ করবেন৷ যাইহোক, কিছু ক্ষেত্রে একটি অপ্রমাণিত উপাদান গ্রাহক যা চান তা নাও হতে পারে।
ঠিকানা দেওয়া হয়েছে | অঞ্চল |
---|---|
1 Rue Grenache, la caritat 2, 34630 Saint-Thibery | ফ্রান্স |
অপ্রত্যাশিত ঠিকানা উপাদানের জন্য রায় নিশ্চিত করা হয়নি
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"unconfirmedComponents": true
}
অপ্রমাণিত উপাদান সহ একটি রায় ছাড়াও, ঠিকানা যাচাইকরণ API নিম্নলিখিত বিন্যাসিত ঠিকানা প্রদান করে:
"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",
অনিশ্চিত উপাদানগুলির জন্য একটি স্ক্যান দেখায় যে API ফেরত ঠিকানা থেকে la caritat 2 সরিয়ে দিয়েছে:
{
"componentName": {
"text": "la caritat 2",
"languageCode": "fr"
},
"componentType": "sublocality_level_1",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
"unexpected": true
}
অপ্রত্যাশিত ঠিকানা উপাদান যা IS নিশ্চিত করেছে৷
এই উদাহরণটি সরবরাহ করা ঠিকানায় একটি UK কাউন্টির অন্তর্ভুক্তির চিত্র তুলে ধরে, যা একটি সাধারণ অভ্যাস। যাইহোক, এটি ইউকে পোস্টাল কর্তৃপক্ষের দ্বারা একটি প্রয়োজনীয়তা নয় এবং মূলত উপেক্ষা করা হয়। দেখুন postoffice.co.uk এবং কিভাবে UK এবং আন্তর্জাতিক মেইল এড্রেস করবেন ।
ফলস্বরূপ, যখন একজন গ্রাহক একটি UK ঠিকানায় একটি কাউন্টি প্রদান করে, পরিষেবাটি এটিকে অপ্রত্যাশিত ইনপুট হিসাবে মূল্যায়ন করে।
ঠিকানা দেওয়া হয়েছে | অঞ্চল |
---|---|
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP | যুক্তরাজ্য |
অপ্রত্যাশিত ঠিকানা উপাদানের জন্য রায় যা IS নিশ্চিত করেছে
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE"
}
এখানে, address_complete
মিথ্যা মূল্যায়ন করে এবং ঠিকানা উপাদানের একটি বিশ্লেষণ একটি অপ্রত্যাশিত পতাকা প্রকাশ করে।
{
"componentName": {
"text": "Gloucestershire",
"languageCode": "en"
},
"componentType": "administrative_area_level_2",
"confirmationLevel": "CONFIRMED",
"unexpected": true
}
যদিও প্রবেশ করা ঠিকানার জন্য Gloucestershire সঠিক কাউন্টি, ঠিকানাটি নিজেই ভুলভাবে ফরম্যাট করা হয়েছে। মনে রাখবেন যে ঠিকানা যাচাইকরণ API সঠিক বিন্যাসের জন্য তথ্য মূল্যায়ন করে।