|
Notes |
|
|
|
|
Тут возникает вопрос как же это лучше определять и что передавать в запрос чтобы можно было отсеять. И в функциях для работы с геометриями той же MySql нет функции для получения или проверки размеров MBR. |
|
|
|
|
>как же это лучше определять
Пока не думал даже.
>нет функции для получения или проверки размеров MBR
Ты уверен в этом? Там целое ведро функций должно быть для реализации требований OGC. Пока что все, кто поддерживают расширения spatial совместимым с OGC образом, имеют такие функции.
В любом случае, если говорить про метки в СУБД, я буду генерить скрипты исходя из того, что умеет конкретный сервер. То есть, где-то будет только геометрия (у многих нет типа типа box) с индексом, где-то ровно наоборот, индекс по полю типа box, а геометрия как BLOB и без индекса, потому что геометрические типы не имеют общего предка и их нельзя пихать в одно поле одной таблы, где-то промежуточные варианты с двумя point в качестве bounds. Так что это не вопрос выбора конкретного сервера СУБД, это вопрос выжимания из него всего что он может. А если возможны разные варианты на одном типе СУБД, то придётся поддерживать разные, смотря чего юзер выберет. Их же всё равно немного, всего лишь 4 варианта получается.
А если говорить про сейчас - то bounds есть и в SML и в SQLite3.
>что передавать в запрос
Это как раз буде зависеть от того, как будет реализована геометрия для конкретного сервера, в том числе с учётом того, что навертел сам юзер.
Например, это может быть максимальная сторона bounds для SML.
ЕМНИП, для SQLite3 такое тоже прокатит, там есть вроде как неагрегатный max по нескольким полям, хотя может и путаю.
По остальным надо смотреть, есть особенности конкретной реализации. Например, есть варианты, когда можно смотреть пересечение не mbr а реальной геометрии, многие это поддерживают. А есть варианты, когда геометрия поддерживается, а R-tree нет ))))))).
Также некоторые СУБД позволяют выполнить генерализацию геометрии прямо при чтении её из базы, что разумеется тоже может быть полезно ради уменьшения числа вершин при огромных масштабах, но также требует некого критерия, когда выполнять это, а когда не надо.
И если честно, меня больше волнует именно критерий отображения.
То есть, нужна функция, вида F(zoom,...) = L, где L - минимальный линейный(?) размер для отображения сложных геометрий. А остальное потом допишем руками по месту, если это будет давать выигрыш. |
|
|
|
|
>>что передавать в запрос
>Это как раз буде зависеть от того, как будет реализована геометрия для конкретного сервера, в том числе с учётом того, что навертел сам юзер.
Не, я про запрос к подсистеме меток, который общий для всех реализаций. Ну очень не хочется что бы база меток знала что-то про проекции и зумы (Тот же диапазон зумов для категорий мне очень сильно не нравится, так как в разных типах пирамид зумы могут совсем не совпадать). Судя по всему нужно передавать минимальный желаемый размер объекта в градусах широты и долготы - да не везде будет одинаково, но просто для реализации фильтрации. Нужно только подумать как эти значения наиболее правильно вычислять перед запросом для конкретной проекции (зума). |
|
|
|
|
>диапазон зумов для категорий мне очень сильно не нравится
Мне как бы тоже зум там не нравится, но не сильно, потому что он фактически сейчас может играть роль универсальной шкалы видимости меток. Со всеми её (такой шкалы) минусами, но тем не менее. Либо тогда надо вообще отказываться от настройки видимости объектов в зависимости от зума. Ибо вряд ли что столько же простое и удобное будет.
>для конкретной проекции (зума)
Может быть исходить из диапазона lonlat для отображаемого тайла? То есть, берём разность координат, делим её на размер тайла карты (получим грубо сколько в пиксель попадает), ну и умножаем, скажем, на 4 (а можно ещё с косинусом средней широты поиграться). Можно же грубо. Лишь бы было некое характерное значение, да быстро, чтобы один размерчик на весь тайл в идеале получить.
А про MySQL да, чё-то маловато там функций (собственно, и mbr там polygon). У PostgreSQL есть например:
height(box) - vertical size of box
width(box) - horizontal size of box
И box занимает меньше, чем полигон.
Ну да это фигня, в крайнем случае проверить на клиенте можно будет, всё равно это быстрее, чем создавать ненужный объект. |
|
|
|
|
> Ибо вряд ли что столько же простое и удобное будет.
Это да, именно поэтому я в глубоких раздумиях и ничего в этом вопросе не предпринимаю. Чисто теоретически можно продолжать в ГУЕ задавать зум, внутри хранить и использовать разрешение в метрах на пиксель, которые рассчитываются в строке статуса. То есть пользователь выбирает зум из зумов активной карты, а сама программа пересчитывает в метры на пиксель. Или просто перейти на задание диапазона в метрах на пиксель в ГУЕ с подсказками на ползунке по типу как в Яндекс картах (Страна, Город, Улица, Дом).
> Лишь бы было некое характерное значение, да быстро, чтобы один размерчик на весь тайл в идеале получить.
Только не на тайл, а на прямоугольник координат. У нас же к базе сейчас запросы идут не потайлово, а на весь экран по координатам.
А вообще мысль хорошая. Добавим в запрос прямоугольника меток параметр с минимальными шириной и высотой геометрий в LonLat да и ладно. Может не идеально, но позволит отсекать лишнее еще на этапе запроса к базе. |
|
|
|
(0016082)
|
|
zed
|
|
29-06-2015 14:14
|
|
|
Добавил параметр, буду тренироваться на SQLite метках. |
|
|
|
(0016092)
|
|
zed
|
|
02-07-2015 13:38
|
|
|
Фильтрация работает в новых метках (SQLite). Для SML там особого смысла в ней нету, поскольку все данные и так находятся в памяти. |
|
|
|
|
>Для SML там особого смысла в ней нету
Разве?
Смысл в том, чтобы не проецировать то, что потом скукожится в трёхпиксельную точку. |
|
|
|
(0016096)
|
|
zed
|
|
02-07-2015 17:44
|
|
А я думал, смысл в том, чтобы не тягать их с базы, как в описании тикета :)
И оно точно не проверяется в том месте, где перепроецируется? Там по-моему должно было проверяться в любом случае. |
|
|
|
|
|
Так оно проверяется уже после, в пикселах, разве нет? |
|
|
|
(0016098)
|
|
zed
|
|
02-07-2015 18:12
|
|
|
Не знаю. Но добавить фильтр в SML не составляет труда, мне просто показалось что выше по коду оно умеет не делать дурной работы. Если не умеет, как ты говоришь, то надо делать и для SML. |
|
|
|
|
|
Лучше добавить фильтр и в SML. Оно проверяет размер только перед самым рендерингом путей и полигонов. |
|