SASGIS

Веб-картография и навигация


View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002716SAS.ПланетаРефакторингpublic07-05-2015 18:5206-07-2015 13:30
Reportervasketsov 
Assigned Tozed 
PrioritynormalSeverityminorReproducibilityN/A
StatusresolvedResolutionfixed 
PlatformWindowsOS7OS VersionUltimate
Product Version141212 
Target Version150915Fixed in Version150915 
Summary0002716: Фильтрация меток по размеру, при получении их списка
DescriptionПоскольку для меток хранится bounds, проблем быть не должно.

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

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

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

Касается только полигонов и полилиний.
TagsNo tags attached.
Attached Files

- Relationships

-  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 (3122x), hrucker (1x), zarius (1x), bk99 (1x), Papazol (1x), vasketsov (9x), zed (15x), vdemidov (6x), Tolik (1x)
Total Views 3157
Last View 28-03-2024 21:29

- 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



Copyright © 2007 - 2024 SAS.Planet Team