GraphHopper: движок маршрутов, который можно встроить в свой продукт

Расчёт маршрута кажется мелочью до того момента, когда за него приходит счёт. Пока запросов сотня в день, любой облачный картографический сервис бесплатен. На десяти тысячах в день это уже статья расходов, а на ста тысячах — повод считать, во что обойдётся своё.

Про то, как поднять свою картографию отдельным сервисом, у меня есть отдельный разбор. Здесь — про другой сценарий: когда движок нужен не рядом с продуктом, а внутри него.

Что это такое

GraphHopper считает по данным OpenStreetMap расстояние, время в пути, пошаговые инструкции поворотов и характеристики дороги между двумя и более точками. Написан на Java, существует с 2012 года, больше семи тысяч коммитов, правки приходят ежедневно. Для инфраструктурного компонента возраст и активность важнее любого списка возможностей: движок маршрутов — это то, что должно работать годами без вашего участия.

Разворачивается двумя способами. Как отдельный веб-сервер, к которому обращаются по сети, — вариант, когда движок обслуживает несколько систем сразу. Или как библиотека Java прямо внутри вашего приложения — когда сетевого вызова не хочется вовсе.

Лицензия, из-за которой его и выбирают

GraphHopper распространяется под Apache 2.0. Соседний по нише OpenRouteService — под GPL-3.0. Функционально они близки настолько, что сравнивать по возможностям почти бессмысленно, а сам OpenRouteService вырос из GraphHopper и ссылается на него в документации.

Разница проявляется ровно в одном сценарии — когда вы делаете продукт на продажу.

Если вы поднимаете сервис для себя и пользуетесь им внутри компании, лицензия не имеет значения: обязательства копилефта в этом случае не возникают. Но если движок маршрутов становится частью вашего приложения, которое вы поставляете клиентам, GPL требует раскрыть исходный код производной работы. Apache 2.0 такого требования не содержит — достаточно сохранить уведомление об авторстве.

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

Общественный транспорт и рельеф

Вторая причина смотреть в эту сторону — то, чего у соседей нет.

GraphHopper умеет работать с данными GTFS — это открытый формат, в котором транспортные предприятия публикуют маршруты и расписания. Практически это означает, что движок строит маршрут с пересадками: дошёл до остановки, доехал на автобусе, пересел, дошёл пешком. Для сервисов, где пользователь без машины, это принципиально другой класс задачи, и обычные автомобильные движки её не решают вообще.

Второе — данные о высотах рельефа. На плоской местности разницы нет. В городе с перепадами она заметна: пеший или велосипедный маршрут, проложенный без учёта подъёмов, формально короче, а фактически неудобен. Для велопроката, курьеров на велосипедах и туристических сервисов это влияет на качество ответа сильнее, чем точность расчёта секунд.

Кому это нужно

Разработчикам продуктов с маршрутами внутри. Системы для логистики, полевых бригад, курьерских служб — везде, где расчёт маршрута часть вашего приложения, а не внешний сервис.

Компаниям с большим потоком расчётов. Точка окупаемости своего движка наступает там, где счёт за облачный API становится заметным в смете. Считать надо не по числу пользователей, а по числу запросов: один пользователь, перестраивающий маршрут двадцать раз, стоит как двадцать.

Сервисам без автомобиля в сценарии. Городские приложения, туристические маршруты, всё, где пользователь передвигается на транспорте и пешком.

Кому не нужно. Если у вас на сайте карта с точками филиалов и кнопкой «построить маршрут» — своего движка не надо, хватит виджета. Своё имеет смысл там, где расчёт маршрута является частью работы системы, а не картинкой на странице.

Собрать такой контур и посчитать, окупится ли он в вашем объёме, я могу под ключ: открытый стек под ключ.

Что учесть до внедрения

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

Подготовка данных требует ресурсов. Перед работой карта региона обрабатывается в служебный формат, и это разовая, но заметная нагрузка на память. Планировать сервер надо по этому этапу, а не по обычной работе.

Обновление карты — регулярная задача. Дороги меняются, и выгрузка OpenStreetMap должна обновляться по расписанию. Это тот самый пункт, который забывают, а через год удивляются, почему маршрут ведёт через закрытый проезд.

Оптимизация развоза — отдельная задача. Движок считает маршрут между точками, но не решает, в каком порядке объехать тридцать адресов пятью машинами. Для этого нужен отдельный компонент, и он у меня разобран отдельно: оптимизация маршрутов доставки.

Частые вопросы

Нужно ли платить за данные OpenStreetMap?

Нет, данные открыты. Но у них своя лицензия с требованием указывать источник, и это требование надо выполнять в интерфейсе продукта.

Насколько это тяжело для сервера?

Зависит от размера региона. Один город — умеренно, страна целиком — это уже серьёзная машина. Практический подход: брать выгрузку ровно по той территории, где работаете, а не по всей России на всякий случай.

Можно ли считать маршруты для грузовиков с ограничениями?

Профили под разные типы транспорта настраиваются, включая учёт ограничений по массе и габаритам, — но только там, где эти ограничения есть в самих данных карты. Отсутствие знака в OpenStreetMap движок не восполнит.

Что будет, если проект перестанут развивать?

Лицензия Apache 2.0 оставляет вам право пользоваться и дорабатывать текущую версию бессрочно. Для инфраструктурного компонента это и есть главная страховка — в отличие от облачного API, который может изменить условия в одностороннем порядке.

Коротко о главном

Движок маршрутов выбирают не по списку функций — у соседей по нише он почти одинаковый. Выбирают по двум вещам. Лицензия определяет, можете ли вы встроить движок в продукт на продажу и не раскрывать свой код: Apache 2.0 позволяет, GPL — нет. Поддержка расписаний транспорта определяет, решаете ли вы задачу для пользователя без машины.

Всё остальное — данные и их регулярное обновление, а это работа, которая не заканчивается вместе с внедрением.

Что предлагаю конкретно. Скажите, сколько расчётов маршрута в день у вас происходит сейчас и где они живут — в вашем продукте или рядом с ним. Посчитаем, окупается ли своё, и если да, соберу контур с обновлением карты по расписанию. Напишите в Telegram, MAX или VK.