Опубликовано: 22.09.2026 | Источник: CNews (новости)

Алгоритмы маршрутизации в ВКР: чему учит «Легкий режим» 2ГИС

25 марта 2026 года в 2ГИС появился «Легкий режим»: сервис строит маршрут без сложных перекрёстков и развязок. Формально это UX-фича, но под ней лежит вполне дипломная задача — модификация функции стоимости маршрута и перестройка графа дорожной сети под другую целевую функцию. Целевая аудитория — неопытные водители и те, кто устал тратить внимание на манёвры.

Почему это важно для выпускника ИТ-направления? Классический «кратчайший путь» давно перестал быть единственным критерием качества в навигации. Если вы делаете ВКР по информационным системам, геоинформатике, прикладной математике или разработке ПО, у вас появляется свежий, проверяемый и легко защищаемый кейс: не «сделать карту», а сменить целевую функцию и доказать, что решение работает. Это ровно тот тип задачи, где видны и архитектура, и алгоритмы, и метрики — а значит, есть что показать комиссии.

Три темы ВКР, которые растут прямо из этой новости

Тема 1. Модификация функции стоимости маршрута с учётом сложности манёвров

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

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

формализовать понятие «сложный манёвр» (угол поворота, число полос, наличие левого поворота через встречный поток, тип развязки);
построить модифицированную функцию стоимости и адаптировать алгоритм Дейкстры / A*;
провести вычислительный эксперимент на открытых данных OpenStreetMap;
сравнить полученные маршруты с эталонными по числу манёвров и времени в пути.

Структура: Глава 1 — обзор алгоритмов маршрутизации и моделей дорожных графов; Глава 2 — проектирование функции стоимости и структуры данных; Глава 3 — экспериментальная оценка и анализ компромисса «время против простоты».

Тема 2. Сервис построения «спокойных» маршрутов как микросервис с открытым API

Актуальность: навигационные функции всё чаще встраиваются в чужие продукты — от каршеринга до логистики. Умение спроектировать такой сервис как отдельный компонент с контрактом API — прямой запрос индустрии.

Цель: спроектировать и реализовать сервис маршрутизации с настраиваемым профилем сложности.

спроектировать REST/JSON-контракт с параметром профиля (быстрый / простой / без левых поворотов);
развернуть граф дорожной сети в PostGIS + pgRouting либо поднять GraphHopper/Valhalla;
реализовать кэширование популярных запросов и оценить прирост по latency;
упаковать сервис в контейнер, описать развёртывание.

Структура: Глава 1 — анализ существующих решений и стандартов качества ПО; Глава 2 — архитектура сервиса, схемы взаимодействия, диаграммы классов и последовательностей; Глава 3 — тестирование, расчёт экономики внедрения.

Тема 3. Методика оценки качества и производительности навигационного сервиса

Актуальность: «Легкий режим» — это ещё и вопрос: как измерить, что маршрут стал «проще»? Без метрики любая фича — маркетинг.

Цель: разработать набор метрик и методику нагрузочного тестирования сервиса маршрутизации.

определить метрики качества маршрута (доля манёвров на километр, число конфликтных точек, отклонение по времени);
сформировать тестовый набор запросов на основе публичных данных;
провести нагрузочное тестирование и снять зависимости latency от числа одновременных пользователей;
оценить соответствие требованиям по восстанавливаемости и доступности.

Структура: Глава 1 — теория метрик и стандарты качества; Глава 2 — стенд, инструменты сбора телеметрии, схема эксперимента; Глава 3 — результаты, графики, выводы и рекомендации.

Аналитическая глава: как превратить новость в обоснование выбора стека

В первой главе почти всегда требуется сравнительный анализ. Здесь новость о «Легком режиме» работает как аргумент: современные навигаторы оперируют не «одним оптимальным маршрутом», а семейством профилей. Значит, ваш стек должен поддерживать кастомные веса и штрафы за манёвры, а не только стандартный автомобильный профиль.

Решение	Профили и кастомные веса	Порог входа	Когда выбирать в ВКР
pgRouting (PostGIS)	Пользовательские SQL-функции стоимости, гибко	Низкий, если вы уже работаете с SQL	Учебный прототип, акцент на алгоритме и запросах
OSRM	Ограниченно, требуется сборка с профилем	Средний	Нужна высокая скорость отдачи маршрутов
GraphHopper	Гибкие кастомные модели стоимости	Средний	Исследование разных функций стоимости
Valhalla	Богатая модель манёвров и стоимости поворотов	Средний/высокий	Тема близка к «легкому режиму» — штрафы за манёвры

Отдельно проговорите в тексте главы, почему вы не берёте закрытое коммерческое решение. Это ожидаемый вопрос на защите, и ответ «данные и алгоритм должны быть воспроизводимы» звучит гораздо сильнее, чем «так проще».

Проектная часть: что рисовать и как описывать интеграцию

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

стоимость(ребро, манёвр):
    c = длина * k_тип_дороги
    c += штраф_поворота(угол, наличие_светофора)
    c += штраф_левого_поворота * признак_встречного_потока
    c += штраф_смены_полосы * число_полос
    если профиль == "простой":
        c += штраф_сложности_развязки * уровень_развязки
    вернуть c

Дальше — схема компонентов: слой приёма запросов, слой построения маршрута, кэш, хранилище графа, слой телеметрии. На диаграмме последовательностей покажите путь одного запроса с профилем «простой» и точку, где подставляются веса. Не забудьте про формальную сторону: техническое задание удобно оформлять с опорой на ГОСТ 34.602-89, а требования к качеству — по ISO/IEC 25010 (функциональная полнота, производительность, удобство использования).

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

Тестирование и метрики: чем доказать, что «легкий режим» действительно легче

Самое слабое место студенческих работ по этой теме — отсутствие измеримого результата. «Маршруты стали проще» — это не результат. Результат выглядит так:

Метрика	Как считать	Куда писать
Манёвров на 1 км	Число поворотов / длина маршрута	Сравнение профилей, таблица результатов
Отклонение по времени	(T_простой − T_быстрый) / T_быстрый	Компромисс «простота против времени»
Latency 95-го процентиля	Замер на нагрузочном стенде	Глава с тестированием
Доля успешных запросов	2xx / общее число запросов	Требования к надёжности
Время восстановления после сбоя	Сценарий отказа компонента	Раздел про отказоустойчивость

Для сбора телеметрии достаточно трассировки запросов и метрик — здесь пригодится OpenTelemetry: вы получаете распределённые трейсы без привязки к конкретному вендору. А воспроизводимость экспериментов удобно обеспечивать через CI/CD-пайплайн: прогон тестового набора на каждый коммит и автоматическая запись метрик в отчёт.

Типичные ошибки студентов

Подмена понятий без обоснования. Пишут «используем облачный сервис», не различая IaaS, PaaS и SaaS, и не объясняя, почему это влияет на архитектуру. Как избежать: добавьте таблицу сравнения моделей обслуживания и один абзац про эксплуатационные последствия выбора.
Отсутствие метрик эффективности. Работа заканчивается словами «система работает корректно». Как избежать: заранее выпишите 4–5 измеримых показателей и покажите их до и после оптимизации.
Игнорирование требований ГОСТ при оформлении ТЗ. Разделы технического задания идут в произвольном порядке, часть обязательных пунктов отсутствует. Как избежать: сверьте структуру ТЗ с ГОСТ 34.602-89 и вынесите его в приложение.

Чему вы научитесь на такой теме

Формализовывать нечёткое требование («ездить спокойно») в набор числовых штрафов и ограничений.
Работать с графами дорожной сети, открытыми геоданными и пространственными индексами.
Обосновывать выбор стека не вкусовщиной, а критериями: гибкость весов, скорость отклика, сложность сопровождения.
Строить нагрузочные эксперименты и корректно интерпретировать процентили, а не только среднее.
Оформлять техническую документацию так, чтобы её можно было защитить, а не «пережить».

Ответы на частые вопросы

Обязательно ли писать код в дипломе по этой теме?

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

Где брать данные и метрики для расчётов?

Основа — открытые картографические данные: выгрузка участка города, из которой вы собираете граф. Данные о трафике можно заменить синтетической моделью с явно описанными допущениями. Метрики производительности вы снимаете сами на своём стенде — это как раз та часть, которую невозможно «списать».

Сколько времени займёт реализация?

Прототип с алгоритмом и экспериментом — ориентировочно 60–90 часов работы. Сервис с API, кэшем, контейнеризацией и нагрузочным тестированием — от 120 часов. Разница в основном в инфраструктурной части, а не в алгоритме.

Как оформлять UML-диаграммы и схемы?

Диаграммы компонентов и последовательностей — самый понятный формат для комиссии. Главное правило: на схеме должны быть только те элементы, которые упоминаются в тексте. Если на диаграмме есть блок «кэш», в тексте должен быть абзац про политику кэширования и её влияние на latency.

Чек-лист: что проверить перед сдачей

Задачи во введении дословно совпадают с выводами по главам.
У каждой цифры в тексте есть источник или описание методики измерения.
Есть сравнительная таблица решений и обоснование выбранного варианта.
Присутствуют схема архитектуры и хотя бы одна диаграмма последовательностей.
Техническое задание оформлено с учётом ГОСТ 34.602-89.
Требования к качеству сформулированы измеримо, а не оценочно.
Ссылки на источники оформлены единообразно и проверены на доступность.

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

Материал подготовлен экспертами компании. Мы помогаем студентам с 2010 года: от выбора темы и архитектуры до финального оформления по ГОСТ. Если вам нужна ВКР на заказ под вашу специальность или разбор уже начатой работы, наши специалисты готовы подсказать, где слабое место и как его закрыть.

Последнее обновление: 2026-09-22