В любой системе, которая отвечает на вопросы, есть реальный соблазн всегда что-нибудь вернуть, вместо того чтобы признать, что на вопрос нельзя надёжно ответить. Для данных о местоположении поддаваться этому соблазну прямо вредно, потому что правдоподобный, но неверный ответ, как правило, наносит гораздо больший ущерб любому решению, которое на нём основано, чем честное признание того, что данные не позволяют дать уверенный ответ.
Если сформулировать прямо, логика проста. Пустой результат или результат, явно помеченный низкой уверенностью, хорошо спроектированное приложение может распознать и обработать осознанно: попросить пользователя уточнить запрос, применить более широкое значение по умолчанию или отметить запись для ручной проверки. Сфабрикованную догадку, которая выглядит так же, как любой другой уверенный результат, и никак не показывает, что совпадение на самом деле было слабым или неоднозначным, невозможно ни распознать, ни обработать особым образом, потому что снаружи она неотличима от действительно надёжного ответа, пока не вызовет реальную, заметную проблему где-то дальше по цепочке, которую часто трудно отследить до её настоящего источника.
Поэтому неоднозначный или неразрешимый запрос должен возвращать либо вообще никакого результата, либо результат, чей показатель confidence честно и ясно отражает реальную неопределённость, а не так, чтобы геокодер молча выбирал одного правдоподобного кандидата из нескольких и подавал его с той же видимой уверенностью, что и однозначное совпадение. Тот же принцип относится к точности: результат никогда не должен заявлять более высокий уровень точности, чем реально позволяют данные, даже если есть соблазн всегда возвращать что-то более конкретное на вид. Честно сообщить city лучше, чем сообщить house наугад.
Для всех, кто строит решения на таких данных, практический вывод такой: проектируйте своё приложение так, чтобы оно действительно ожидало пустые результаты и результаты с низкой уверенностью и корректно обрабатывало их как обычную, повседневную часть возможных ответов, а не как редкий исключительный случай, для которого обработку прикручивают отдельно и в последний момент. Форма, в которой продуман только удачный сценарий для полностью разрешённых результатов с высокой уверенностью, а для всего остального нет продуманного поведения, рано или поздно сломается непонятным образом, когда неизбежно встретит запрос, который данные действительно не могут уверенно разрешить, а это случается чаще, чем предполагает большинство первоначальных проектов.
Проверка и precision, и confidence в каждом результате, а также продуманное запасное поведение на случай, когда любой из них опускается ниже порога, который реально нужен в вашем сценарии, и есть разница между приложением, которое плавно деградирует на сложных случаях, и приложением, которое тихо распространяет плохие данные, потому что изначально не было рассчитано ни на что, кроме чистого, однозначного ответа.