Следите за использованием ключа, пока не упёрлись в лимит
Наблюдение за заголовками квоты по ходу работы показывает приближение к лимиту задолго до того, как запрос будет отклонён.
Не у каждого адреса есть номер дома. Сельские маршруты, некоторые новые застройки и известные достопримечательности часто называют без него, и запрос на геокодирование, построенный с расчётом на то, что номер дома будет всегда, неправильно поймёт, как выглядит корректный результат для таких случаев.
GET /v1/forward?q=Golden Gate Bridge, San Francisco&limit=1{
"status": "ok",
"query": "Golden Gate Bridge, San Francisco",
"results": [
{
"formatted": "Golden Gate Bridge, San Francisco, CA",
"lat": 37.8199,
"lon": -122.4783,
"type": "address",
"precision": "street",
"confidence": 0.9,
"place_id": "gb567",
"components": {"city": "San Francisco", "region": "CA", "country": "US"}
}
]
}Обратите внимание, что здесь в components нет поля house_number, а precision имеет значение «street», а не «house». И то и другое ожидаемо для адреса, у которого действительно нет номера дома, и не является признаком неудачного или частичного поиска.
Воспринимайте precision как описание того, насколько конкретно совпадение, а не как индикатор ошибки. Точность «house» означает, что совпадение указывает на конкретное здание. Точность «street» означает, что совпадение указывает на улицу или точку на ней без привязки к конкретному зданию, и это совершенно правильно для достопримечательности или адреса, у которого действительно нет номера дома.
GET /v1/forward?q=Central Park, New York&limit=1Такое именованное общественное место обычно распознаётся со значением type шире, чем «address», и с точностью, отражающей область, а не отдельную точку, а объект components может содержать только город и регион. Это та же закономерность, что и в примере с мостом: реальный полезный результат, честно описанный как охватывающий область, а не конкретное здание, потому что именно на это и ссылался запрос.
Если сейчас валидация вашей формы требует наличия поля house_number, прежде чем признать адрес полным, эта проверка будет ошибочно отклонять законные сельские адреса и достопримечательности. Основывайте критерии приёма на том, соответствуют ли confidence и precision тому, что вам действительно нужно, а не требуйте заполнения каждого конкретного компонента.
Не приравнивайте пустой объект components или объект, в котором нет нескольких полей, к неудачному запросу. Неудачный запрос возвращается со статусом ошибки и кодом ошибки, описанными в документации по ошибкам. Успешный результат с неполными компонентами это другой, совершенно нормальный исход, и если смешивать их при обработке ошибок, корректные адреса будут записываться в журнал и обрабатываться как сбои.
Для адреса без номера дома лучше показать клиенту отформатированный результат для подтверждения, чем сразу отклонить отправленную форму. Так реальный адрес остаётся пригодным к использованию, а действительно некорректные данные по-прежнему отсеиваются на других этапах.
Обратное геокодирование координаты, находящейся в открытой сельской местности или на воде, точно так же может вернуть более грубую точность и меньше заполненных компонентов, чем координата, попадающая в контур конкретного здания. В документации по обратному геокодированию описаны те же значения precision для этого направления.
Адрес без номера дома стоит тот же один запрос, что и любой другой поиск прямого геокодирования. Отсутствие компонентов никак не влияет на то, как запрос списывается с вашего дневного лимита или баланса.
Правильная обработка в основном сводится к тому, чтобы читать precision и confidence так, как они задуманы, а не предполагать, что у каждого корректного адреса должны быть заполнены все компоненты. В документации по прямому геокодированию подробно объясняется каждое поле.