Проверка соответствия адреса указанному почтовому индексу до оформления заказа
Несовпадение почтового индекса и города в форме заказа выглядит мелкой опечаткой, пока не превращается в доставку совсем в другую часть страны.
Построение зон доставки вокруг склада
Региональная сеть продуктовых магазинов открыла второй склад, и прежде чем обещать доставку в тот же день, ей нужно было ответить на простой вопрос: до каких клиентов действительно можно добраться от нового здания за разумное время в пути, а каких по-прежнему лучше обслуживать с исходной площадки.
Первой попыткой было провести эту границу вручную, циркулем и с примерной оценкой расстояния по дорогам, и получилась зона доставки, которая выглядела разумно, а работала плохо. До некоторых адресов внутри круга было сорок минут езды по единственной ведущей к ним дороге. Другие, чуть за его пределами, оказывались ближе, чем показывала карта.
Более правильный подход начинается с преобразования адресов в координаты. Запрос к /v1/forward принимает адрес и возвращает совпадение, включая поля широты и долготы, то есть структурированное местоположение, которое нужно для расчёта расстояния, вместо названия улицы, которое инструменту маршрутизации приходится угадывать. Адрес склада геокодируется один раз. Каждый адрес заказа из списка клиентов геокодируется в том же пакете, поскольку пакетный запрос считает каждый адрес одной оплачиваемой единицей, а не взимает плату за вызов.
Когда координаты есть с обеих сторон, расстояние по прямой от склада до каждого клиента становится простым расчётом, который может выполнить собственная система сети. Зоны перестали быть нарисованным от руки кругом и стали границей, построенной по реальным обслуживаемым точкам и автоматически обновляемой при появлении каждого нового адреса клиента. Когда фактический радиус работы склада потребовалось сократить из-за того, что сроки доставки начали срываться, границу можно было перестроить по тем же данным, а не перерисовывать на глаз.
Обратное направление тоже было важно. У службы поддержки иногда были только координаты из приложения доставки, без чистого адреса, и нужно было понять, к какой зоне и какому магазину относится эта точка. /v1/reverse принимает пару координат и возвращает компоненты адреса для этого места, превращая метку на карте обратно в то, что может использовать таблица маршрутизации склада.
Для всего этого сети не пришлось создавать или лицензировать картографическую платформу. Геокодирование было единственным недостающим звеном, и оно подключилось к логистическому ПО, которое компания уже использовала у себя. При открытии нового склада повторно геокодировали несколько тысяч адресов, а затем каждый день геокодировался небольшой поток новых заказов, с запасом в пределах бесплатной дневной квоты, которой пользуется большинство компаний такого размера, и с возможностью перейти на предоплаченный баланс, если объём заказов вырастет.
Этот урок применим не только к доставке продуктов. Любому бизнесу, который проводит границу обслуживания вокруг физической точки, будь то склад, ремонтная база или бригада монтажа в тот же день, нужны те же две вещи: надёжный способ превратить адрес в координату и надёжный способ превратить координату обратно в адрес, когда данные приходят с другой стороны. И то и другое даёт один и тот же ключ.
Форматы запросов и ответов для обоих эндпоинтов описаны на страницах /docs/forward-geocoding/ и /docs/reverse-geocoding/.