Клуб API Карт

Клуб API Карт

Оптимизация точек полилинии

Пост в архиве.

Кто может объяснить, как в действительности оптимизируется полилиния при создании объекта из файла XML? То, что совпадающие идущие подряд точки переходят в одну, я уже знаю. Но если в файле записана LineString, состоящая из многих чередующихся точек, она тоже переходит в объект из двух точек. Почему?

А в объекте GPX такое тоже происходит? Кто-нибудь экспериментировал с ним?

11 комментариев
Авторизуйтесь, чтобы оставить комментарий
thekashey
28 января 2016, 06:04

смысл алгоритма - убрать незначимые точки.

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

Если у вас круг из 100000 точек - тут сложенее но понятнее - на каждом зуме требуется столько точек, сколько пикселей будет в отрисованной кривой. Больше вы просто не заметите.

В итоге оптимизатор кушает не совпадаюшие точки - если у вас есть точки 1,2,3 то он смотрит на отклонение точки 2 от прямой 1-3.

Если нужен сам агоритм - посмотрите сюда

vshameev
28 января 2016, 06:04

И что, на разных зумах число считанных точек разное?

thekashey
28 января 2016, 06:04

в этом один из смыслов

vshameev
28 января 2016, 06:04

А обойти эту оптимизацию можно? В рамках Яндекса? Или надо писать что-нибудь свое?

thekashey
28 января 2016, 06:04

Если грузите через YML\GPX - никак. Данные прийдут уже обработанные

Fedor Golubev
28 января 2016, 06:04
А зачем вам ее обходить?
Какую задачу вам это мешает решить?
vshameev
28 января 2016, 06:04

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

Fedor Golubev
28 января 2016, 06:04
Оптимизация происходит только в рамках LineString и LinearRing, что в принципе позволяет решать задачу в рамках xml структуру, описав каждую точку в виде отдельного GeoObject. Что правда приведет к разрастанию объема и потребует пост-обработку в виде обхода этих объектов и построения по их координатам полилинии.

Альтерантивой действительно может быть что-то свое. Тут вы уже вольны сами описать в подходящей вашим данным форме.

Со своей стороны, подумаем о режиме обработки без симплификации, но ничего не обещаю, вы первый кому это понадобилось.
vshameev
28 января 2016, 06:04

Да, вопрос объема присутствует.

А  трек в GPX оптимизируется? Там ведь присутствует время, что позволяет различать точки?

Fedor Golubev
28 января 2016, 06:04
* теги rte преобразуются в ломаные, вершинами которых выступают rtept
* теги trkseg преобразуются в ломаные, вершинами которых выступают trkpt
* gpxStartTime и gpxEndTime - добавляются для rte и trkseg, значения полей берутся из первой и последней точки маршрута (отрезка), время промежуточных точек игнорируется

http://api.yandex.ru/maps/jsapi/doc/ref/reference/gpx.xml
vshameev
28 января 2016, 06:04

Все понятно, спасибо.