Клуб API Карт

Ломанная с большим количеством точек

Пост в архиве.
Здравствуйте. Есть задача отображения маршрута объекта по точкам из базы. Использую
YMaps.Polyline, но при большом количестве точек (больше 10 тыс.) возникают
непонятного происхождения ошибки в отображении, при масштабировании или при передвижении карты.
Подскажите, может быть эту задачу нужно решать более оптимальным способом?
Почитал про активные области, но если я правильно понял - они в основном используются для статических, заранее известных объектов?
Буду признателен за ответ.
16 комментариев
Михаил Королев
28 января 2016, 06:59

 При таких объёмах JavaScript работает с мегабайтами кода, это неправильно.


Я это при рисовании треков в GRS-Помощник-е решил оптимизацией самого трека. - После загрузки запускается процесс пост-обработки данных в БД вычисляющий прямолинейные участки и исключающий ненужные точки из выдачи.

Дело в том, что хотелось бы дать пользователю возможность получать информацию по каждой точке: время, скорость и т.п. Поэтому исключение точек подходит, как крайний вариант.
Михаил Королев
28 января 2016, 06:59
а я и не удаляю все точки, а выключаю их. можно грузить разную детализацию на разных масштабах. но не грузить "всё сразу" - это очень много.
А на сколько быстрый по времени процесс оптимизации трека? И сколько точек в среднем, в процентном соотношении будет исключено при оптимизации?
Вариант выгрузки трека в YMapsML, с последующим отображением на карте не рассматривали? Может быть это будет быстрее?
Михаил Королев
28 января 2016, 06:59

зависит от кол-ва точек в треке. может занимать несколько минут но чаще

у меня треки выгружаются именно в YMapsML


скажем трек с 40 тыс точек просто не покажется будет ошибка таймаута, а после оптимизации в нём останется 10-12 тыс - и он "летает".


вот вам реальный пример в обсуждении в клубе МЯК:


http://clubs.ya.ru/mobilemaps/replies.xml?item_no=39445

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

Далее наступает пора отображения - надо найти один или более сегментов трека которые видны на карте именно в данный момент. Если 90% трека именно сейчас не видны - их НЕ НАДО показывать.

Далее берем один из треков(надеюсь понятно что после обрезки их может на экране быть несколько) и запускаете алгоритм симплификации линии. Точность представления можно менять, но 2-3 пикселя - нормально. Можно и в 5-10 поставить в некоторых случаях.
Тру гуру настраивают этот параметер на основе заменения времени отображения одного из треков - если ясно видно что клиент тупит(ИЕ6 на слабом проце ) - можно крутить параметер в одну строну.
А если у вас 16 процесорный i10 - в другую.

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

Задача - известен номер опорной точки 1 и номер опорной точки два. Отображаемое растояние между ними, реальное(по кривой трека), а также растояние от одной точки до курсора.
Требуется найти сооветсвуещее растояние на исходных данных и получить , как говориться, best-match - порядоковый индекс записи в исходном треке.

Радоваться.
Для меня пока сложноват этот вариант. Я в javascript  новичок. Может быть позже попробую.  В любом случае спасибо за подсказку.
Лучше выгружать треки в YMapsML. Ломаные, описанные в нем,  будут симплифицироваться автоматически.

Собственно, так и делает Михаил Королев.
Спасибо. Попробую реализовать этот вариант.
Эхехе, нет бы нормальную подсистему геометрии зарелизить
всмысле открыть исходный код симплификации?
или написать jsvascript'а которые будет делать симплификацию на клиенте?
Я бы сделал симплификацию и обрезку по viewport одним из свойствов самого Y полигона. Чтобы не то чтобы работало "из-коробки" - работало по умолчанию.
Есть же такие "странные" функции типа растояние с учетом кривизны. А другие полезные весчи - просто закопаны.

Насчет js на клиенте, ежели кто не видел поста полугодовой давности - http://www.kashey.ru/pages/maps/reduce_polygon_test.php
Обрезка по viewport есть.
Автоматической симплификации нет, кажется что она всегда проиграет предсимплификации. Твой пример с тысячей точек хорош, но как быть, когда захотят добавить 3 полилинии по 10 тысяч точек? Вообщем-то ты в чем-то прав, автоматическая симплификация уменьшит проблему. Но не решит, и именно это останавливает нас от реализации. Меня лично смущает половинчатость решения.
Можно и не автоматической, а просто как свойство полигона, или метод( в конвертере ему самое место, например под названием optimizeLineToRenderTarget.. хотя не, убиться можно :) )

Насчет половинчатого решения - вроде как ЯК для самых хреновых случаев рендерит полигон аш на сервере. В принципе к хреновым случаях теоритически можно отнести не  тупой девайс, а еще и крутой полигон :)
В крайнем случае - заcanvasить

>проиграет предсимплификации
окей, я создаю полигон, как мне его провести через проиграет "предсимплификацию"

Заметь - если грузить через YML - данная операция будет выполнена всегда( но тебе наверное лучше знать), а вот если пользователь апи чуть более "крут" и работает на нижнем уровне с полигонами - облом.
жизнь не справедлива
мы сейчас готовы брать стажеров, если найдется попрошу написать модуль симплификации, но результат не обещаю