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

Цель

Часто возникает необходимость проверки местоположения места. В Google Maps Platform есть несколько различных сервисов, которые могут помочь вам в этом варианте использования. Этот документ поможет вам выбрать между двумя основными сервисами проверки местоположения — API проверки адресов и API геокодирования.

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

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

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

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

Address-Validation-vs-Geocoding

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

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

alt_text

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

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

76 Buckingamm Palace Road, Лондон , SW1W 9TQ, Великобритания

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

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

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

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

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

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

Большештрассе 86, 12587, Германия

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

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

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

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

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

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

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

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

"types": [
  "route"
]

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

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

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

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

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

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

Если Geocoding API возвращает location_type ROOFTOP или RANGE_INTERPOLATED , это не обязательно означает, что адрес существует. Аналогично, если Geocoding 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. Обратите внимание, что если запрос содержит неправильно написанный компонент адреса, Geocoding API может предложить альтернативный адрес. Предложения, инициированные таким образом, не будут помечены как частичное совпадение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

Участники

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

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

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

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

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