Маршрут построен: как разработать систему городской навигации для электросамокатов

Почему самокатам нужны собственные маршруты, а не автомобильные

Первая причина, по которой самокаты требуют отдельных маршрутов — для них действуют свои правила дорожного движения. Электросамокаты, как сегвеи и моноколеса, относятся к средствам индивидуальной мобильности (СИМ), которым можно ездить по велодорожкам, велополосам и тротуарам. Если такой возможности нет, то по обочине или правому краю проезжей части дороги со скоростным режимом не более 60 км/ч. Это приходится учитывать при построении маршрута.

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

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

Где брать данные

Все это не значит, что нужно изобретать велосипед и строить систему навигации с нуля. За основу навигационные сервисы обычно берут открытые данные проекта Open Street Map (OSM) — городские карты, которые создаются пользователями и дают представление о транспортной инфраструктуре.

OSM хороши тем, что у них есть разные типы объектов и инфраструктуры, которые можно «включать» и «выключать»: дорога, тротуар, пешеходный переход, велодорожка и так далее. Это дает возможность убирать из маршрута ненужные нам объекты.

Например, самокату нельзя ездить по автомагистралям: тогда мы выключаем соответствующий слой и тем самым запрещаем строить маршрут через автомагистрали. То же самое работает в отношении велодорожек и тротуаров, если мы делаем маршрутизатор для автомобилей или любых автодорог, если речь о пешеходах. В результате мы получаем систему фильтров, которая отражает особенности конкретного вида транспорта.

Следующий шаг — добавить к открытым данным внутреннюю информацию. У нас каждый самокат оснащен IoT модулем собственной разработки, который постоянно собирает телеметрические данные об устройстве: отслеживает геолокацию с помощью GPS, состояние самоката, его готовность к поездкам и многое другое. Модуль в режиме реального времени отправляет такие данные в облачный сервис компании.

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

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

Кроме того, датчики могут собирать данные не только о геолокации, но и о состоянии дороги: например, если самокат, грубо говоря, трясет в поездке, это может сигнализировать о некачественном дорожном покрытии или ямах. Все датчики находятся в IoT-модуле. В частности, они собирают информацию о силе и частоте «ударов» самоката при движении. Такие данные также хранятся в облачной системе.

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

Еще нюанс — тепловые карты нужно постоянно обновлять: дорожная инфраструктура меняется, появляются новые велодорожки, новые инфраструктурные объекты. И все это нужно учитывать в маршрутах.

По теме. Самокатчик нарушил ПДД: что грозит владельцу кикшеринга

Как собрать команду

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

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

Изначально мы собрали команду маршрутизатора по образу и подобию других продуктовых команд. То есть там был продакт, разработчики, аналитики и стандартный флоу: родилось бизнес-требование, мы его обсудили, нарезали на задачи, выполнили их, проанализировали результат. Взлетело — отлично, нет — думаем дальше.

Мы не учли, что для создания картографического сервиса много времени и ресурсов нужно тратить на кропотливую работу с данными. Буквально открывать карты и вручную проверять: точно ли сработал фильтр, действительно ли там есть велодорожка, верно ли она стыкуется со следующей. В команде таких сервисов обычно есть джуниор-картографы, студенты или вчерашние студенты, которые и занимаются этой важной работой. Мы не учли этот момент в самом начале, поэтому столкнулись с чередой новичковых ошибок, что приводило к не самому лучшему качеству некоторых маршрутов.

В итоге мы изменили состав команды, сместив фокус на стек картографии и геоаналитики. Это помогло нам добиться идеального микса компетенций и ресурсов. Теперь в команде маршрутизатора и работы с картой около 15 человек, некоторые из которых привлекаются частично в нужные моменты разработки. Из них 7 человек — геоаналитики, картографы и продуктовые аналитики, 8 — продуктовая команда: менеджер по продукту, Java, Python, Go разработчики, разработчики мобильных приложений (iOS, Android), UX/UI дизайнер, QA инженер.

На какие этапы поделить работу

Саму работу лучше всего строить от простого к сложному.

Как это было у нас:

1. Сначала мы сделали функцию поиска адреса в приложении без построения маршрута.
2. Добавили возможность построить пеший маршрут до ближайшего самоката с оценкой времени на дорогу.
3. Разработали полноценный маршрутизатор, который прокладывает дорогу до нужной точки с учетом специфики езды на электросамокатах — это нынешний этап.
4. Следующий шаг — добавить функцию навигатора, который будет «вести» пользователя по построенному маршруту с голосовыми подсказками, как в классических навигаторах.

Время, которое уйдет на работу, зависит от размера команды, ее компетенций и объема имеющихся данных. У нас весь процесс разработки от создания команды до внедрения занял около 9 месяцев. Но была предыстория: мы уже пробовали подступиться к созданию собственного маршрутизатора ранее и даже участвовали с этой задачей на хакатонах. Там мы искали ребят, которых заинтересует эта идея и которые предложат свежее решение.

Что делать дальше

Как и для многих продуктов, особенно тех, что рассчитаны на широкую аудиторию, работу над маршрутизатором нельзя завершить. Маршруты нужно постоянно дорабатывать, анализируя, где людям действительно удобно ездить, а где нет. Это бесконечный процесс улучшения, который подпитывается обратной связью, новыми данными о пользовательских поездках и городской инфраструктуре.

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

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

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