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

Цель

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fake St не существует в Маунтин-Вью, штат Калифорния, и 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, Лондон , 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 проверки адреса возвращает флаг, указывающий на то, что в поле было внесено исправление. С помощью этого флага можно реализовать бизнес-логику, чтобы дважды проверить исправление у поставщика данных, например у покупателя при оформлении заказа в электронной торговле.

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

Большештрассе 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

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 , это все равно может быть для вас правильным результатом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

Рекомендуемое дальнейшее чтение:

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

Авторы

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

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

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

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

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