SASGIS - SAS.Планета
View Issue Details
0002716SAS.ПланетаРефакторингpublic07-05-2015 18:5206-07-2015 13:30
vasketsov 
zed 
normalminorN/A
resolvedfixed 
Windows7Ultimate
141212 
150915150915 
0002716: Фильтрация меток по размеру, при получении их списка
Поскольку для меток хранится bounds, проблем быть не должно.

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

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

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

Касается только полигонов и полилиний.
No tags attached.
Issue History
07-05-2015 18:52vasketsovNew Issue
08-05-2015 08:21vdemidovNote Added: 0015866
08-05-2015 09:07vasketsovNote Added: 0015867
08-05-2015 10:20vdemidovNote Added: 0015868
08-05-2015 11:33vasketsovNote Added: 0015869
09-05-2015 07:43vdemidovNote Added: 0015872
14-05-2015 08:55vdemidovStatusnew => confirmed
14-05-2015 08:55vdemidovProduct Version => 151010
14-05-2015 08:55vdemidovTarget Version => 141212
29-06-2015 14:14zedNote Added: 0016082
29-06-2015 14:16zedSummaryФильтрация меток при получении их списка по размеру => Фильтрация меток по размеру, при получении их списка
02-07-2015 13:38zedNote Added: 0016092
02-07-2015 13:38zedStatusconfirmed => resolved
02-07-2015 13:38zedFixed in Version => 150915
02-07-2015 13:38zedResolutionopen => fixed
02-07-2015 13:38zedAssigned To => zed
02-07-2015 13:38zedProduct Version151010 => 141212
02-07-2015 13:38zedTarget Version141212 => 150915
02-07-2015 15:17vasketsovNote Added: 0016095
02-07-2015 17:44zedNote Added: 0016096
02-07-2015 18:07vasketsovNote Added: 0016097
02-07-2015 18:12zedNote Added: 0016098
06-07-2015 13:30vdemidovNote Added: 0016110

Notes
(0015866)
vdemidov   
08-05-2015 08:21   
Тут возникает вопрос как же это лучше определять и что передавать в запрос чтобы можно было отсеять. И в функциях для работы с геометриями той же MySql нет функции для получения или проверки размеров MBR.
(0015867)
vasketsov   
08-05-2015 09:07   
>как же это лучше определять
Пока не думал даже.

>нет функции для получения или проверки размеров MBR
Ты уверен в этом? Там целое ведро функций должно быть для реализации требований OGC. Пока что все, кто поддерживают расширения spatial совместимым с OGC образом, имеют такие функции.

В любом случае, если говорить про метки в СУБД, я буду генерить скрипты исходя из того, что умеет конкретный сервер. То есть, где-то будет только геометрия (у многих нет типа типа box) с индексом, где-то ровно наоборот, индекс по полю типа box, а геометрия как BLOB и без индекса, потому что геометрические типы не имеют общего предка и их нельзя пихать в одно поле одной таблы, где-то промежуточные варианты с двумя point в качестве bounds. Так что это не вопрос выбора конкретного сервера СУБД, это вопрос выжимания из него всего что он может. А если возможны разные варианты на одном типе СУБД, то придётся поддерживать разные, смотря чего юзер выберет. Их же всё равно немного, всего лишь 4 варианта получается.

А если говорить про сейчас - то bounds есть и в SML и в SQLite3.

>что передавать в запрос
Это как раз буде зависеть от того, как будет реализована геометрия для конкретного сервера, в том числе с учётом того, что навертел сам юзер.
Например, это может быть максимальная сторона bounds для SML.
ЕМНИП, для SQLite3 такое тоже прокатит, там есть вроде как неагрегатный max по нескольким полям, хотя может и путаю.
По остальным надо смотреть, есть особенности конкретной реализации. Например, есть варианты, когда можно смотреть пересечение не mbr а реальной геометрии, многие это поддерживают. А есть варианты, когда геометрия поддерживается, а R-tree нет ))))))).

Также некоторые СУБД позволяют выполнить генерализацию геометрии прямо при чтении её из базы, что разумеется тоже может быть полезно ради уменьшения числа вершин при огромных масштабах, но также требует некого критерия, когда выполнять это, а когда не надо.
И если честно, меня больше волнует именно критерий отображения.
То есть, нужна функция, вида F(zoom,...) = L, где L - минимальный линейный(?) размер для отображения сложных геометрий. А остальное потом допишем руками по месту, если это будет давать выигрыш.
(0015868)
vdemidov   
08-05-2015 10:20   
>>что передавать в запрос
>Это как раз буде зависеть от того, как будет реализована геометрия для конкретного сервера, в том числе с учётом того, что навертел сам юзер.
Не, я про запрос к подсистеме меток, который общий для всех реализаций. Ну очень не хочется что бы база меток знала что-то про проекции и зумы (Тот же диапазон зумов для категорий мне очень сильно не нравится, так как в разных типах пирамид зумы могут совсем не совпадать). Судя по всему нужно передавать минимальный желаемый размер объекта в градусах широты и долготы - да не везде будет одинаково, но просто для реализации фильтрации. Нужно только подумать как эти значения наиболее правильно вычислять перед запросом для конкретной проекции (зума).
(0015869)
vasketsov   
08-05-2015 11:33   
>диапазон зумов для категорий мне очень сильно не нравится
Мне как бы тоже зум там не нравится, но не сильно, потому что он фактически сейчас может играть роль универсальной шкалы видимости меток. Со всеми её (такой шкалы) минусами, но тем не менее. Либо тогда надо вообще отказываться от настройки видимости объектов в зависимости от зума. Ибо вряд ли что столько же простое и удобное будет.

>для конкретной проекции (зума)
Может быть исходить из диапазона lonlat для отображаемого тайла? То есть, берём разность координат, делим её на размер тайла карты (получим грубо сколько в пиксель попадает), ну и умножаем, скажем, на 4 (а можно ещё с косинусом средней широты поиграться). Можно же грубо. Лишь бы было некое характерное значение, да быстро, чтобы один размерчик на весь тайл в идеале получить.

А про MySQL да, чё-то маловато там функций (собственно, и mbr там polygon). У PostgreSQL есть например:
height(box) - vertical size of box
width(box) - horizontal size of box
И box занимает меньше, чем полигон.
Ну да это фигня, в крайнем случае проверить на клиенте можно будет, всё равно это быстрее, чем создавать ненужный объект.
(0015872)
vdemidov   
09-05-2015 07:43   
> Ибо вряд ли что столько же простое и удобное будет.
Это да, именно поэтому я в глубоких раздумиях и ничего в этом вопросе не предпринимаю. Чисто теоретически можно продолжать в ГУЕ задавать зум, внутри хранить и использовать разрешение в метрах на пиксель, которые рассчитываются в строке статуса. То есть пользователь выбирает зум из зумов активной карты, а сама программа пересчитывает в метры на пиксель. Или просто перейти на задание диапазона в метрах на пиксель в ГУЕ с подсказками на ползунке по типу как в Яндекс картах (Страна, Город, Улица, Дом).

> Лишь бы было некое характерное значение, да быстро, чтобы один размерчик на весь тайл в идеале получить.
Только не на тайл, а на прямоугольник координат. У нас же к базе сейчас запросы идут не потайлово, а на весь экран по координатам.
А вообще мысль хорошая. Добавим в запрос прямоугольника меток параметр с минимальными шириной и высотой геометрий в LonLat да и ладно. Может не идеально, но позволит отсекать лишнее еще на этапе запроса к базе.
(0016082)
zed   
29-06-2015 14:14   
Добавил параметр, буду тренироваться на SQLite метках.
(0016092)
zed   
02-07-2015 13:38   
Фильтрация работает в новых метках (SQLite). Для SML там особого смысла в ней нету, поскольку все данные и так находятся в памяти.
(0016095)
vasketsov   
02-07-2015 15:17   
>Для SML там особого смысла в ней нету
Разве?
Смысл в том, чтобы не проецировать то, что потом скукожится в трёхпиксельную точку.
(0016096)
zed   
02-07-2015 17:44   
А я думал, смысл в том, чтобы не тягать их с базы, как в описании тикета :)

И оно точно не проверяется в том месте, где перепроецируется? Там по-моему должно было проверяться в любом случае.
(0016097)
vasketsov   
02-07-2015 18:07   
Так оно проверяется уже после, в пикселах, разве нет?
(0016098)
zed   
02-07-2015 18:12   
Не знаю. Но добавить фильтр в SML не составляет труда, мне просто показалось что выше по коду оно умеет не делать дурной работы. Если не умеет, как ты говоришь, то надо делать и для SML.
(0016110)
vdemidov   
06-07-2015 13:30   
Лучше добавить фильтр и в SML. Оно проверяет размер только перед самым рендерингом путей и полигонов.