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

Цель

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

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

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

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

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

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

Примечания к схеме выше

• Вариант использования с взаимодействием пользователя – это когда пользователь присутствует и взаимодействует с результатами.
• Places Autocomplete – это 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, то можно найти соответствие для "Калифорнии", как показано на скриншоте инструмента геокодирования, который можно попробовать здесь:

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

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

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

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

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

premises:

"business": true

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

"dpvConfirmation": "S"

Значение dpvConfirmation, равное S, означает, что адрес подтвержден на уровне 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, чтобы сместить область поиска в сторону Канады. Обратите внимание, что при использовании параметра regionBiasing результаты из указанного региона будут только предпочтительными. Вы по-прежнему можете получать результаты из других регионов.

• 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 более терпим к ошибкам ввода, выделяет непроверяемые компоненты адреса и исправляет входные данные.
• Для адреса требуется дополнительная информация, например тип адреса (жилой или коммерческий; доступно в некоторых регионах).

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

Скачайте технический документ Improve checkout, delivery, and operations with reliable addresses (Как улучшить оформление заказов, доставку и работу с помощью надежных адресов) и посмотрите вебинар Improving checkout, delivery, and operations with Address Validation (Как улучшить оформление заказов, доставку и работу с помощью Address Validation) .

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

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

Авторы

Google поддерживает эту статью. Его написали следующие авторы:

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

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

Тома Англаре | Разработчик решений

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