Подтвердить адрес – примеры

В этом документе описывается ряд реальных сценариев, в которых API проверки адресов предоставляет сигналы ответа для адресов, требующих подтверждения от вашей системы. Приведённые здесь примеры иллюстративны, но не исчерпывают весь спектр. Подробнее см. в разделе «Обзор рабочего процесса» в разделе «Создание логики проверки» .

Распространенные примеры: подтвердить

Следующий пример иллюстрирует случай мегаполисов с похожими названиями улиц. Предположим, пользователь хочет ввести адрес здания Google D в Киркленде, штат Вашингтон, США . Однако вместо Киркленда он случайно вводит Сиэтл .

Адрес введен Область
Здание D, 451 7th Avenue South, Сиэтл, Вашингтон 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 все равно может сделать правильный вывод, даже если во входных данных отсутствует только один компонент из следующих типов:

  • Город
  • Состояние
  • Почтовый индекс
  • Страна

Например, клиент указывает действительный почтовый адрес ресторана McDonald's в Спрингфилде, штат Массачусетс, но забывает указать город и указывает почтовый индекс без четырехзначного расширения.

Адрес введен Область
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 Сен-Тибери Франция

Вердикт по неожиданному компоненту адреса не подтверждён 

{
  "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
}

Неожиданный компонент адреса, который подтвержден

Этот пример иллюстрирует включение графства Великобритании в указанный адрес, что является распространённой практикой. Однако это не является требованием почтовой службы Великобритании и фактически игнорируется. См. postoffice.co.uk и раздел «Как адресовать почтовые отправления в Великобритании и за рубежом» .

В результате, когда клиент указывает графство в своем адресе в Великобритании, служба оценивает это как неожиданные данные.

Адрес введен Область
33 Dunalley St, Челтнем, Глостершир, GL50 4AP Великобритания

Вердикт по неожиданному компоненту адреса, который был подтвержден IS 

{
   "inputGranularity": "PREMISE",
   "validationGranularity": "PREMISE",
   "geocodeGranularity": "PREMISE"
}

В данном случае address_complete оценивается как false, а анализ компонента address выявляет неожиданный флаг.

{
  "componentName": {
    "text": "Gloucestershire",
    "languageCode": "en"
  },
  "componentType": "administrative_area_level_2",
  "confirmationLevel": "CONFIRMED",
  "unexpected": true
}

Хотя графство Глостершир указано верно для введённого адреса, сам адрес имеет неверный формат. Напомним, что API проверки адресов также проверяет правильность форматирования информации.