Создание возможности проверки местоположения с помощью платформы Google Maps

Цель

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

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

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

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

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

Когда следует выбирать проверку адреса или API геокодирования

Примечания к приведенной выше схеме:

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

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

Вы можете выбрать API проверки адресов вместо API геокодирования, когда:

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

Вы можете выбрать использование API геокодирования вместо проверки адреса, когда:

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

Ниже приведены некоторые примеры, демонстрирующие возможности API проверки адресов в сравнении с API геокодирования.

Пример неверного адреса

1 Fake St, Маунтин-Вью, Калифорния 94043, США

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

Поддельной улицы в Маунтин-Вью, штат Калифорния, не существует, и API проверки адреса отражает это в возвращаемых данных на уровне компонентов:

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

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

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

Используя тот же адрес с API геокодирования, можно выполнить сопоставление по слову «Калифорния», как вы видите на снимке экрана инструмента геокодирования, который вы можете опробовать здесь :

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

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

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

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

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

Взгляните на один из компонентов адреса, в котором при вводе была допущена ошибка:

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

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

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

Bollschestraße 86, 12587, DE

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

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

Bölschestraße 86, 12587 Berlin, DE

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

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

111 8th Avenue Ste 123 , Нью-Йорк, штат Нью-Йорк 10011-5201, США

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

API проверки адреса может проверить адрес PREMISE (111 8th Ave) и предоставить некоторые метаданные об объекте, включая информацию о том, что это коммерческое здание.

помещение:

"business": true

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

"dpvConfirmation": "S"

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

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

Понимание ответа API геокодирования

Обзор

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

Принцип работы API геокодирования заключается в разрешении компонентов адреса в иерархии.

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

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

ChIJwRKzf8ixD4gRHiXqucwr_HQ

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

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

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

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

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

Запрос только с указанием почтового адреса без номера дома возвращает результат в форме:

"types": [
  "route"
]

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

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

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

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

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

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

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

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

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

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

Если адрес совпадает частично, т. е. API геокодирования не смог точно идентифицировать адрес, то ответ содержит:

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

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

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

Например, запрос « 21 Henr St, Bristol, UK » вернёт частичное совпадение как для Henry Street, так и для Henrietta Street. Обратите внимание: если запрос содержит неправильно написанный адрес, API геокодирования может предложить альтернативный адрес. Предложения, полученные таким образом, не будут отмечены как частичное совпадение.

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

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

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

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

Примечание : это еще один пример того, как с помощью API проверки адреса вы получаете прямую обратную связь, если адрес не существует.

Понимание ответа API проверки адреса

Существует уже обширная документация о том, как интерпретировать ответы API проверки адресов, поэтому мы не будем вдаваться в подробности.

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

Лучшие практики

Указание географии

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

• API геокодирования — региональное смещение

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

• API проверки адреса — код региона

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

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

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

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

Примечание : обязательно ознакомьтесь с руководством по лучшим практикам геокодирования.

Заключение

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

• Точный почтовый адрес обязателен, особенно в целях обеспечения доставки.
• Известно, что входные данные низкого качества. API проверки адресов более терпим к ошибкам ввода, выделяет непроверяемые компоненты адреса и вносит исправления во входные данные.
• Для адреса требуется больше информации, например, «Жилой» или «Коммерческий» (доступно в некоторых регионах).

Следующие шаги

Загрузите технический документ «Улучшение оформления заказа, доставки и операций с использованием надежных адресов» и просмотрите вебинар «Улучшение оформления заказа, доставки и операций с использованием проверки адресов» .

Рекомендуемая дополнительная литература:

• Проверка адреса для оформления заказа в электронной торговле
• Место автозаполнения документации
• Документация API проверки адресов
• Отчеты платформы Google Maps

Авторы

Эта статья поддерживается Google. Её авторами являются следующие авторы:

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

Хенрик Валв | Инженер по решениям

Томас Англерет | Инженер по решениям

Сартак Гангули | Инженер по решениям