Новое в Karta

WebGL JS API

Очередная порция плюшек в нашем WebGL-продукте.

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

В дальнейшем при вызове, например, setCenter он уже учтёт это смещение.

Конечно, переключатель этажей у нас был и раньше, но на первом переключить этажи было нельзя. Теперь у нас есть FloorControl — и можно бегать по этажам сколько угодно.

Менять этажи можно и из кода — для этого сделали метод setFloorPlanLevel с набором событий, которые позволяют отслеживать появление и скрытие этажей и их смену из кода.

Внимательный читатель прошлых Доставили воскликнет: «Так у вас есть теперь редактор стилей карты, вот бы и этажи раскрасить!». И будет прав — уже скоро мы добавим и эту возможность.

Ещё интересная штука — плагин кластеризации для HTML-маркеров. Маркера у нас двух типов: WebGL-маркер и HTML-маркер. Вторые позволяют вставлять в маркер любую HTML-страничку. И если для первого типа маркеров у нас кластеризация была давно, то для второй появилась только сейчас.

И, наконец, маленький улучшайзер: теперь можно немного кастомизировать отрисовку построенного маршрута. Например, сделать подложку или нарисовать ореол вокруг него.

И бонус-трек с полезными мелочами:

1. Максимальные границы методом map.setMaxBounds.
2. Новый класс LngLatBoundsClass, в который добавим удобные методы для работы с границами в долготе и широте. Пока добавили только extend — он расширяет уже существующий «баунд» так, чтобы он включил новую точку.

Navi

От визуальных карт идём к роутинговым сценариям. Больше хардкора богу хардкора!

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

DistanceMatrix у нас уже был и раньше, но сейчас мы над ним плотно поработали, чтобы сделать его ещё лучше.

1. Ускорили производительность алгоритма расчёта до 400 мс в общем случае (зависит от размерности).
2. Увеличили возможную размерность матриц. В текущей боевой версии есть ограничение 10×10 — мы повысили размерность до 50×50 с сохранением скорости работы. Но в целом готовы обрабатывать и матрицы бо́льшей размерности.
3. Добавили возможность считать матрицы для точек, которые находятся в разных городах, — то есть теперь умеем в межрегиональные построения.
4. Добавили новые функциональные возможности в алгоритм расчёта маршрутов:
   • фильтры грунтовых и платных дорог и паромных переправ для автомобильных маршрутов;
   • фильтры грунтовых дорог, магистральных улиц и паромных переправ для пешеходных маршрутов;
   • сделали разные режимы построения маршрутов: с учётом текущих пробок, по статистике на указанное время, кратчайшие маршруты.

И отдельно — про исключение объектов на маршруте. Бывают ситуации, когда нужно построить маршрут и при этом избежать определённые области. Например, незапланированные массовые мероприятия. Мы сделали так, чтобы в API вместе с запросом можно было передать набор геометрий, через которые маршруты не проходить не будут.

Для этого в сервисы Routing & Directions, Directions Pairs и Distance Matrix добавили новый параметр exclude. Он описывает область (точку, полилинию или полигон и буфер вокруг них), которую нужно избегать. Этот параметр работает в режимах «автомобиль» и «пешеход».

Сделали два режима: soft и hard. Soft — это мягкое избегание. Стараемся избежать, если маршрут легко позволяет это сделать, а время в пути меняется нерадикально. В некоторых случаях может пересекать геометрию. При степени избегания soft-оверхеда на скорость работы сервиса почти нет.

Hard — это гарантированное избегание. Если путь проходит через hard-зону, то нам придётся перебрать больше рёбер, тем самым потратим больше времени на построение решения. Конечно, скорость работы будет зависеть от размера зоны и точек, через которые проходит предполагаемый маршрут.

Ещё одно новшество — учёт вектора направления. Для построения маршрутов движущихся авто важно учитывать направление его движения (азимут), чтобы выбрать правильную стартовую точку. В городских условиях GPS может давать разброс — тогда навигатор выберет неверный азимут и построит некорректный маршрут.

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

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

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

Пока этот режим доступен только в Routing&Directions API, но до конца апреля ожидаем его появление в Directions Pairs и Distance Matrix.

Ещё одна новинка — Reverse isoline. Обычный isoline — это построение многоугольника из точек, которые можно достичь за указанное время, если выехать из центральной точки. Например, нужно понять, до каких целевых точек курьер может добраться на авто с учётом пробок за 15 минут. У Reverse isoline — обратная задача. То есть цель — не из центра до точки, а наоборот, из точек многоугольника до центра за указанное время.

Помимо запуска Reverse Isoline мы поставили цель по времени ответа, чтобы единичные 30-минутные оболочки рассчитывались быстрее 600 мс. Время расчёта области зависит от параметров запроса (пешком или на авто, ограничение по времени маршрута), а также от насыщенности дорожного графа. Самые тяжёлые — запросы на автомобильные оболочки в центре Москвы. Для них мы смогли достичь показателя 440 мс для 95-го перцентиля времён расчёта и 500 мс для 99-го.

И последнее на сегодня — режим такси. Этот вид транспорта приравнивают к общественному транспорту и в большинстве городов таким машинам можно ездить по выделенным полосам. Поэтому мы решили добавить их в наши роутинговые сценарии.

В методы Routing & Directions, Directions Pairs и Distance Matrix запустили новый тип маршрутизации taxi и добавили информацию о полосах для общественного транспорта в граф.

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

Будем улучшать Karta и дальше. Подпишитесь на наш телеграм-канал — и тогда ни одна новая фича, релиз или продукт Karta не пройдёт мимо.