Сравнение проверки адреса и геокодирования

Цель

Часто возникает необходимость подтвердить местоположение места. В платформе Google Карт есть несколько сервисов, которые могут помочь вам в этом случае. Этот документ поможет вам выбрать между двумя основными сервисами проверки местоположения – Address Validation API и Geocoding API.

Address Validation API – это сервис платформы Google Карт, который помогает клиентам проверять точность адресов.

Геокодирование с помощью Geocoding API – это процесс преобразования адресов в географические координаты, которые можно использовать для размещения маркеров на карте или позиционирования карты.

Общие сведения о различиях между Address Validation API и Geocoding API можно найти здесь.

Попробуйте прямо сейчас. Перейдите в консоль Google Cloud и включите Address Validation API и Places API.

Когда выбирать Address Validation API, а когда – Geocoding API

Примечания к схеме:

• Взаимодействие с пользователем – это когда пользователь взаимодействует с результатами.
• Автозаполнение мест – это JavaScript API, который подходит для интеграции с пользовательскими интерфейсами.
• Возможно, вы знаете о проблемах с качеством данных в существующих адресах. Поэтому, даже если вам нужны только геокоды, рекомендуется пропустить адреса через Address Validation API, чтобы исправить наборы данных.

Существует множество ситуаций, когда вы можете выбрать один продукт вместо другого, основываясь на приведенном выше дереве решений. Но в других ситуациях для достижения целей может потребоваться использование обоих продуктов.

Address Validation API лучше использовать вместо Geocoding API в следующих случаях:

• Существует высокая вероятность сомнительных данных или случаев, когда получение неверного адреса будет иметь негативные последствия. Это связано с тем, что Address Validation API предоставляет больше информации о том, почему входные данные не привели к высокоточному результату.
• Вам нужно исправить ошибки в запросе пользователя (например, опечатки или пропущенные поля), чтобы повысить вероятность получения точного результата.
• Address Validation API возвращает больше метаданных для целевого региона, чем Geocoding API, например классификацию типа здания (жилое или коммерческое).

Geocoding API лучше использовать вместо Address Validation API в следующих случаях:

• Ваша основная цель – получить местоположение адреса, а точность отдельных адресов может быть некритичной.
  • Например, вы можете создать тепловую карту на основе большого набора данных.
• Вам нужны подробные сведения о пункте назначения, например о входах в здание, его контурах или точках посадки и высадки (доступны в методе SearchDestinations в Geocoding API версии 4).
• Вам нужно глобальное решение, а Address Validation API доступен не во всех целевых регионах.

Ниже приведены примеры, демонстрирующие возможности Address Validation API по сравнению с Geocoding API.

Пример недопустимого адреса

1 Fake St, Mountain View, CA 94043, USA

Address Validation API разбивает эти данные на отдельные компоненты адреса (улица, город, штат и т. д.). Кроме того, вы можете получить подробную информацию о том, почему адрес недействителен, вплоть до уровня PREMISE.

Улицы Fake St в Маунтин-Вью нет, и Address Validation API отражает это в возвращаемых сведениях на уровне компонентов:

{
  "componentName": {
    "text": "Fake St",
    "languageCode": "en"
   },
   "componentType": "route",
   "confirmationLevel":"UNCONFIRMED_BUT_PLAUSIBLE"
 }

В этом случае важно проверить свойство confirmationLevel. Возвращая UNCONFIRMED_BUT_PLAUSIBLE для Fake St, API определяет, что у улицы может быть такое название, но его невозможно сопоставить с подтверждающими адресными данными.

Используя результат API в качестве обратной связи, можно сделать вывод, что проблема заключается в компоненте улицы (Fake St).

Если использовать тот же адрес с Geocoding API, он сможет найти совпадение с Калифорнией, как показано на следующем скриншоте из инструмента Geocoder:

Однако в результате геокодирования будет возвращен весь штат, а не конкретный адрес, и вы не получите никаких сообщений о том, какие компоненты входных данных были ошибочными.

Пример орфографической ошибки

76 Buckingamm Palace Road, Londn, SW1W 9TQ, GB

В адресе выше есть две орфографические ошибки: одна в названии улицы, а другая – в названии населенного пункта.

API Address Validation и Geocoding API могут исправить эти ошибки и выдать правильный результат: 76 Buckingham Palace Road, London, SW1W 9TQ. Однако Address Validation API может предоставить больше информации о процессе.

Посмотрите на один из компонентов адреса, который был введен с ошибкой:

{
  "componentName": {
    "text": "Buckingham Palace Road",
    "languageCode": "en"
        },
        "componentType": "route",
        "confirmationLevel": "CONFIRMED",
        "spellCorrected": true
     }
}

Address Validation API возвращает флаг, указывающий, что в поле было внесено исправление. На основе этого флага можно реализовать бизнес-логику, чтобы перепроверить исправление у поставщика данных, например у клиента при оформлении заказа в интернет-магазине.

Пример отсутствия данных и орфографической ошибки

Bollschestraße 86, 12587, DE

В адресе выше допущена ошибка в названии улицы и не указан город (Берлин).

Address Validation API может исправить обе эти ошибки и возвращает геокод уровня PREMISE и адрес, подтвержденный до уровня PREMISE:

Bölschestraße 86, 12587 Berlin, DE

Geocoding API не может успешно преодолеть ошибки ввода в этом случае и возвращает результат ZERO_RESULTS.

Пример дополнительных метаданных адреса

111 8th Avenue Ste 123, New York, NY 10011-5201, US

Этот адрес правильный, за исключением номера офиса (Ste 123), которого нет в здании.

Address Validation API может проверить адрес до уровня PREMISE (111 8th Ave) и предоставить некоторые метаданные об объекте, в том числе о том, что это коммерческая

помещения:

"business": true

Кроме того, значение dpvConfirmation, возвращаемое в ответе как часть uspsData, равно S:

"dpvConfirmation": "S"

Значение S в поле dpvConfirmation указывает, что адрес подтвержден на уровне PREMISE, но номер квартиры или офиса, указанный во входных данных, не связан с этим адресом.

Geocoding API не может предоставить эту информацию.

Как интерпретировать ответ Geocoding API

Обзор

Если вы используете Geocoding API, результат геокодирования содержит различные подсказки в ответе, которые можно использовать для понимания деталей предоставленного адреса.

Geocoding API обрабатывает компоненты адреса в иерархическом порядке.

Например, 123 Example Street, Chicago, 60007, USA разрешается в следующем порядке:

/ Example Street/ Chicago/ 60007/ USA будут оцениваться в указанном порядке. Первое совпадение в этом случае – Чикаго, а точнее, почтовый индекс 60007. Поэтому для этого почтового индекса возвращается следующий идентификатор места:

ChIJwRKzf8ixD4gRHiXqucwr_HQ

Ответ Geocode API содержит следующую информацию:

        "partial_match": true,
           "place_id": "ChIJwRKzf8ixD4gRHiXqucwr_HQ",
           "types": [
               "postal_code"
           ]

Geocoding API может подтвердить, к какому типу мест относится этот адрес. Список types адресов, возвращаемых Geocoding API, можно найти здесь.

Если ни один из компонентов входных данных не распознан, API возвращает:

{
   "results": [],
   "status": "ZERO_RESULTS"
}

Если в запросе указать только почтовый адрес без номера дома, результат будет иметь следующий вид:

"types": [
  "route"
]

Это означает, что Geocoding API не удалось найти или сопоставить номер дома.

Примечание. Чтобы узнать, существует ли адрес, проверьте, заданы ли какие-либо параметры (например, types, partial_match, results, status)) в ответе Geocoding API. Это постепенно повысит уровень достоверности того, что адрес существует, но не сделает его на 100 % точным. Вот почему нам нужен Address Validation API.

Вы можете использовать описанные выше методы, чтобы повысить уверенность в точности адреса, полученного из ответа Geocoding API. Однако, в отличие от Address Validation API, Geocoding API не возвращает точные данные, позволяющие определить точность результата.

Тип местоположения

Чтобы правильно понять этот раздел, вам нужно знать, какие типы местоположений могут возвращаться в ответе Geocoding API:

• ROOFTOP указывает, что результат содержит точный геокод, для которого у нас есть геоданные с точностью до почтового адреса.
• RANGE_INTERPOLATED указывает, что результат содержит приближенное значение (обычно на дороге), полученное при помощи интерполяции двух точных значений (например, перекрестков). Интерполированные результаты обычно возвращаются, если для почтового адреса недоступны геокоды номеров зданий.
• GEOMETRIC_CENTER указывает, что возвращаемый результат является геометрическим центром результата, такого как ломаная линия (например, улица) или многоугольник (регион).
• APPROXIMATE указывает, что результат не относится ни к одному из перечисленных выше типов.

Если Geocoding API возвращает location_type со значением ROOFTOP или RANGE_INTERPOLATED, это не обязательно означает, что адрес существует. Аналогично, если Geocoding API возвращает флаг partial_match со значением true, это все равно может быть нужный вам результат.

Такие ложные совпадения очень сложно устранить с помощью Geocoding API. Как минимум, вы можете реализовать базовую проверку страны и населенного пункта в запросе и ответе. Ещё лучше сравнить фактические почтовые адреса на наличие опечаток и/или неполного адреса.

Примечание. Если вы решите использовать Geocoding API, рекомендуем регулярно проверять качество данных между исходным запросом и ответом Geocoding API.

Частичное и ложное совпадение

Если адрес совпадает частично, то есть Geocoding API не может точно определить адрес, ответ содержит:

"partial_match": true,
"types": [
           "locality",
           "political"
         ]

Ещё важнее, чем типы местоположений, учитывать, когда в ответе присутствует partial_match = true. partial_match – указывает, что Geocoding API не вернул точное соответствие для исходного запроса, хотя и обнаружил частичное совпадение с запрашиваемым адресом.

Рекомендуется проверить исходный запрос на наличие в нем неполного адреса. В большинстве случаев частичные совпадения возникают при использовании почтовых адресов, которые отсутствуют в местности, указанной в запросе. Частичные совпадения могут также возвращаться для запросов, в которых имеется соответствие нескольким местоположениям в пределах одной местности.

Например, запрос "21 Henr St, Bristol, UK" вернет частично совпадающие результаты "улица Лизюкова" и "улица Лизы Чайкиной". Обратите внимание: если запрос содержит ошибки в написании адреса, Geocoding API может предложить альтернативный адрес. Такие предложения не будут помечены как частичные совпадения.

Синтетические адреса

Geocoding API может возвращать местоположения для "синтетических" адресов, которые не существуют как точные местоположения в базе данных Google.

В таких случаях объект ответа часто содержит длинный идентификатор места и следующее свойство: geometry.location_type=APPROXIMATE.

Если вы видите эти индикаторы в ответе, пометьте введенный адрес как недействительный и попробуйте проверить его другим способом.

Примечание. Это ещё один пример того, как Address Validation API позволяет сразу узнать, что адрес не существует.

Как интерпретировать ответ Address Validation API

У нас уже есть подробная документация о том, как интерпретировать ответы Address Validation API, поэтому мы не будем останавливаться на этом.

• Обзор объекта ответа можно найти здесь.
• Демонстрация, иллюстрирующая различные компоненты ответа, доступна здесь.
• В документе Проверка адреса при оформлении заказа подробно описано, как отличить правильные адреса от неправильных.

Рекомендации

Как указать географические данные

При вызове Address Validation API или Geocoding API рекомендуется ограничить географическую область поиска адреса. В двух API это реализовано по-разному:

• Geocoding API – привязка к региону

  Если вы знаете, что геокоды будут находиться в определенной стране, вы получите гораздо лучшие результаты, используя привязку к региону. Например, если вы выполняете геокодирование в Канаде, рекомендуем добавить в запросы параметр &region=ca, чтобы сместить область поиска в сторону Канады. Обратите внимание, что при использовании параметра region biasing результаты из указанного региона будут только предпочтительными. Вы по-прежнему можете получать результаты за пределами региона.

• Address Validation API – код региона

  Аналогично, Address Validation API выдает более точные результаты, если в запросе передается код ISO2 с использованием поля regionCode.

Сохранение идентификаторов мест

Вы можете сохранить идентификатор места из платформы Google Карт в своей базе данных в качестве атрибута записи о местоположении. Запрос Find Place нужно отправлять только один раз для каждого идентификатора места. Впрочем, вы можете искать идентификатор места каждый раз, когда пользователь запрашивает сведения о транзакции.

Чтобы поддерживать актуальность информации в своей базе данных, обновляйте идентификаторы мест каждые 12 месяцев с помощью запроса информации о месте с параметром place_id.

Примечание. Обязательно ознакомьтесь с рекомендациями по геокодированию.

Заключение

В этом документе описаны основные различия между Address Validation API и Geocoding API. Итак, Address Validation API рекомендуется использовать в следующих случаях:

• Укажите точный почтовый адрес, чтобы мы могли доставлять вам корреспонденцию.
• Входные данные низкого качества. Address Validation API менее чувствителен к ошибкам ввода, выделяет непроверяемые компоненты адреса и исправляет входные данные.
• Для адреса требуется дополнительная информация, например тип здания (жилое или коммерческое). Доступно в некоторых регионах.

Дальнейшие действия

Скачайте технический документ Проверка адресов снижает вероятность ошибок при оформлении и доставке покупок и посмотрите вебинар Проверка адресов снижает вероятность ошибок при оформлении и доставке покупок .

Дополнительные сведения

• Проверка адреса при оформлении заказа в интернет-магазине
• Документация по автозаполнению мест
• Документация по Address Validation API
• Отчеты по платформе Google Карт

Авторы

Google поддерживает эту статью. Ниже перечислены авторы, которые изначально написали его.

Основные авторы:

Хенрик Вальве (Henrik Valve) | разработчик решений

Тома Англаре (Thomas Anglaret) | разработчик решений

Сартак Гангули (Sarthak Ganguly) | разработчик решений