Следите за использованием ключа, пока не упёрлись в лимит
Наблюдение за заголовками квоты по ходу работы показывает приближение к лимиту задолго до того, как запрос будет отклонён.
Номер квартиры, добавленный к адресу улицы, это обычная часть множества реальных адресов, и стоит разобраться, как с ним обращается геокодирование, а не удалять его перед отправкой запроса, что является распространённой, но ненужной привычкой.
Включайте номер квартиры или помещения в текстовый запрос так же, как любую другую часть адреса.
GET /v1/forward?q=Apt 4B, 350 Fifth Avenue, New York&limit=1{
"status": "ok",
"query": "Apt 4B, 350 Fifth Avenue, New York",
"results": [
{
"formatted": "350 Fifth Avenue, New York, NY",
"lat": 40.7484,
"lon": -73.9857,
"type": "address",
"precision": "house",
"confidence": 0.95,
"place_id": "es234",
"components": {"house_number": "350", "street": "Fifth Avenue", "city": "New York", "region": "NY", "country": "US"}
}
]
}Координаты, полученные при геокодировании, указывают на здание, а не на конкретное помещение в нём, поскольку у отдельных квартир нет собственного отдельного положения на карте, как у здания. Не ожидается, что часть адреса с квартирой или помещением изменит значения lat и lon, и её отсутствие в объекте components тоже ожидаемо, а не является признаком того, что входные данные были проигнорированы или обработаны неправильно.
Та же закономерность действует для адреса компании с номером офиса или этажа.
GET /v1/forward?q=Suite 200, 1 Example Plaza, Chicago&limit=1Большое офисное здание, в котором размещаются десятки отдельных компаний, всё равно геокодируется в один набор координат здания, независимо от того, какой офис указан в запросе, точно так же, как жилой дом. Всё, что отличает одного арендатора от другого в этом здании, должно храниться в ваших собственных записях, а не в координатах.
Не пытайтесь обойти отсутствие компонента помещения, самостоятельно дописывая его постфактум к почтовому индексу или другому полю компонента, например записывая почтовый индекс как «20500 Apt 4B». Это портит поле, в котором другие системы, включая вашу собственную валидацию и любые последующие поиски по адресу, ожидают только настоящий почтовый индекс. Храните номер помещения в отдельном поле, полностью отдельно от всех геокодированных компонентов.
Вместо того чтобы каждый раз включать номер помещения в геокодируемую строку адреса, храните его отдельным полем в собственной модели данных рядом с геокодированным адресом здания. Так запрос на геокодирование сосредоточен на том, что действительно влияет на результат, то есть на местоположении здания, а сведения о помещении при этом сохраняются для этикеток доставки или внутренних записей.
Курьерской или почтовой службе номер помещения нужен для фактической доставки, хотя в координатах он не участвовал. Храните обе части, геокодированные координаты здания и отдельно сохранённый номер помещения, вместе в итоговой записи о доставке, чтобы ничего не потерялось по пути.
По одному адресу здания может проживать или работать множество отдельных жильцов или арендаторов, и у всех у них одни и те же координаты и один и тот же результат поиска почтового индекса. Если вы сверяете почтовый индекс клиента с адресом, полученным прямым геокодированием, как описано в руководстве по сверке почтовых индексов, помните, что такое соотношение «многие к одному» между помещениями и зданием ожидаемо и само по себе не говорит о проблеме с данными.
Независимо от того, содержит ли адрес номер квартиры или помещения, поиск стоит один запрос, как и любой другой вызов прямого геокодирования.
Включение номера помещения в запрос ничему не вредит, и удалять его для точного геокодирования не нужно, хотя вынесение его затем в отдельное сохранённое поле делает ваши данные чище. Полный список компонентов смотрите в документации по прямому геокодированию.