0002716: Фильтрация меток по размеру, при получении их списка

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

(0015867) vasketsov (manager) 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 (manager) 08-05-2015 10:20	>>что передавать в запрос >Это как раз буде зависеть от того, как будет реализована геометрия для конкретного сервера, в том числе с учётом того, что навертел сам юзер. Не, я про запрос к подсистеме меток, который общий для всех реализаций. Ну очень не хочется что бы база меток знала что-то про проекции и зумы (Тот же диапазон зумов для категорий мне очень сильно не нравится, так как в разных типах пирамид зумы могут совсем не совпадать). Судя по всему нужно передавать минимальный желаемый размер объекта в градусах широты и долготы - да не везде будет одинаково, но просто для реализации фильтрации. Нужно только подумать как эти значения наиболее правильно вычислять перед запросом для конкретной проекции (зума).

(0015869) vasketsov (manager) 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 (manager) 09-05-2015 07:43	> Ибо вряд ли что столько же простое и удобное будет. Это да, именно поэтому я в глубоких раздумиях и ничего в этом вопросе не предпринимаю. Чисто теоретически можно продолжать в ГУЕ задавать зум, внутри хранить и использовать разрешение в метрах на пиксель, которые рассчитываются в строке статуса. То есть пользователь выбирает зум из зумов активной карты, а сама программа пересчитывает в метры на пиксель. Или просто перейти на задание диапазона в метрах на пиксель в ГУЕ с подсказками на ползунке по типу как в Яндекс картах (Страна, Город, Улица, Дом). > Лишь бы было некое характерное значение, да быстро, чтобы один размерчик на весь тайл в идеале получить. Только не на тайл, а на прямоугольник координат. У нас же к базе сейчас запросы идут не потайлово, а на весь экран по координатам. А вообще мысль хорошая. Добавим в запрос прямоугольника меток параметр с минимальными шириной и высотой геометрий в LonLat да и ладно. Может не идеально, но позволит отсекать лишнее еще на этапе запроса к базе.

(0016082) zed (manager) 29-06-2015 14:14	Добавил параметр, буду тренироваться на SQLite метках.

(0016092) zed (manager) 02-07-2015 13:38	Фильтрация работает в новых метках (SQLite). Для SML там особого смысла в ней нету, поскольку все данные и так находятся в памяти.

(0016095) vasketsov (manager) 02-07-2015 15:17	>Для SML там особого смысла в ней нету Разве? Смысл в том, чтобы не проецировать то, что потом скукожится в трёхпиксельную точку.

(0016096) zed (manager) 02-07-2015 17:44	А я думал, смысл в том, чтобы не тягать их с базы, как в описании тикета :) И оно точно не проверяется в том месте, где перепроецируется? Там по-моему должно было проверяться в любом случае.

(0016097) vasketsov (manager) 02-07-2015 18:07	Так оно проверяется уже после, в пикселах, разве нет?

(0016098) zed (manager) 02-07-2015 18:12	Не знаю. Но добавить фильтр в SML не составляет труда, мне просто показалось что выше по коду оно умеет не делать дурной работы. Если не умеет, как ты говоришь, то надо делать и для SML.

(0016110) vdemidov (manager) 06-07-2015 13:30	Лучше добавить фильтр и в SML. Оно проверяет размер только перед самым рендерингом путей и полигонов.

Users who viewed this issue
User List	Anonymous (3445x), hrucker (1x), zarius (1x), bk99 (1x), Papazol (1x), vasketsov (9x), zed (15x), vdemidov (6x), Tolik (1x)
Total Views	3480
Last View	24-11-2024 02:15

Issue History
Date Modified	Username	Field	Change
07-05-2015 18:52	vasketsov	New Issue
08-05-2015 08:21	vdemidov	Note Added: 0015866
08-05-2015 09:07	vasketsov	Note Added: 0015867
08-05-2015 10:20	vdemidov	Note Added: 0015868
08-05-2015 11:33	vasketsov	Note Added: 0015869
09-05-2015 07:43	vdemidov	Note Added: 0015872
14-05-2015 08:55	vdemidov	Status	new => confirmed
14-05-2015 08:55	vdemidov	Product Version	=> 151010
14-05-2015 08:55	vdemidov	Target Version	=> 141212
29-06-2015 14:14	zed	Note Added: 0016082
29-06-2015 14:16	zed	Summary	Фильтрация меток при получении их списка по размеру => Фильтрация меток по размеру, при получении их списка
02-07-2015 13:38	zed	Note Added: 0016092
02-07-2015 13:38	zed	Status	confirmed => resolved
02-07-2015 13:38	zed	Fixed in Version	=> 150915
02-07-2015 13:38	zed	Resolution	open => fixed
02-07-2015 13:38	zed	Assigned To	=> zed
02-07-2015 13:38	zed	Product Version	151010 => 141212
02-07-2015 13:38	zed	Target Version	141212 => 150915
02-07-2015 15:17	vasketsov	Note Added: 0016095
02-07-2015 17:44	zed	Note Added: 0016096
02-07-2015 18:07	vasketsov	Note Added: 0016097
02-07-2015 18:12	zed	Note Added: 0016098
06-07-2015 13:30	vdemidov	Note Added: 0016110

Relationships

SASGIS