Ошибка API геокодирования Google?

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

Например

 https://maps.googleapis.com/maps/api/geocode/json?address=1+route+d%27Arlon%2C8399+Windhof%2CLuxembourg&key={Your-API-Key}&language=fr

что правильно находит хит, как и ожидалось. Однако,

 https://maps.googleapis.com/maps/api/geocode/json?address=1+route+d%27Arlon%2C83992+Windhof%2CGermany&key={Your-API-Key}&language=fr

тоже находит попадание, хотя и с возвращаемым partial_match = true.

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

Как это может быть чем-то кроме ошибки, я не могу себе представить. Однако изначально я просто предполагал, что буду проверять такие проблемы, попросив пользователя проверить предоставленный адрес, если будет обнаружено, что partial_match присутствует.

Однако простая проверка этого приводит к ложным срабатываниям. Возьмите URL-адрес

https://maps.googleapis.com/maps/api/geocode/json?address=2+route+d%27Arlon%2C8552+Oberpallen%2CLuxembourg&key={Your-API-Key}&language=fr

возвращает 2 Route d'Arlon, 8552 Oberpallen, Luxembourg, который, насколько я могу судить, является точно таким же адресом, который я указал, но API геокодирования ВСЕ ЕЩЕ возвращает partial_match.

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

  • Почему мой третий пример выше возвращает partial_match, когда все вроде бы в порядке?
  • С какой стати API возвращает что-либо, кроме статуса ошибки, когда я умышленно указываю ему неправильную страну и почтовый индекс?

google-geocoding-api
person DroidOS    schedule 31.08.2016    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

house no, street, zip code, place, country OR street house no,zip code place, country OR street, house no, place, zip code, country OR

.... .

Лучшей практикой было бы

  • Защитите различные компоненты адреса - даже бит house no + street как отдельные поля от пользователя.
  • На сервере выстраивайте всю адресную строку так, как вам нравится — API геокодирования более чем способен справиться с мелкими нюансами, такими как post code before place, post code after place, missing commas, too many commas и т. д.
  • Если API возвращает status = OK, ни в коем случае не полагайтесь ни на поля formatted_address, ни на partial_result. Вместо этого перестройте весь адрес в выбранном вами формате, используя address_components часть результата.
  • Выполните нечувствительное к строке сравнение адреса, который вы отправили в API, и адреса, который вы только что создали.
  • Продолжайте принимать адрес только в том случае, если вы получите идеальное совпадение.

Имейте в виду, что порядок компонентов адреса в address_components может различаться, поэтому ищите компоненты с записью types[0], установленной на street_number, route, locality, postal_code и country. Наконец, пробелы могут разрушить самые лучшие схемы, поэтому, прежде чем сравнивать что-либо, сделайте

trim(preg_replace('/\s+/',' ', $str));

чтобы убедиться, что вы избавились от всех нежелательных пробелов.

person DroidOS    schedule 31.08.2016