Карта заполнения для полигона

[vdemidov]

А вообще, коллеги, не стоит совать в тайлохранилище чисто интерфейсные штуки, которые к нему не относятся.
В тайлохранилище координаты тайлов - это xyzv - и всё. Какие полигоны? Какие координаты? Какие проекции?

Именно. И я так же думаю.

[zed]

А просто передавать RECT не всего экрана, а только BOUNDs полигона (пути), вернее, пересечение с экраном (видимую часть).

Это и будет первый вариант, как я описал в самом начале. Rect будет несколько избыточен.

Какие полигоны? Какие координаты? Какие проекции?

Ну, можно и не полигон, можно набор точек X,Y, которые следует проверить. Это не принципиально.

Ну, я не очень в восторге от такого решения

Предложи другое? Ходить за каждым тайлом по-одному, как при закачке?

Сразу возникнет желание что бы полигон сохранялся после перезапуска программы.

В рамках данного тикета такого желания не возникает. Полигон будет "забываться" при отключении карты заполнения.

[vdemidov]

Какие полигоны? Какие координаты? Какие проекции?

Ну, можно и не полигон, можно набор точек X,Y, которые следует проверить. Это не принципиально.

Не хотелось бы. Это сильно усложняет интерфейс и реализацию.

Ну, я не очень в восторге от такого решения

Предложи другое? Ходить за каждым тайлом по-одному, как при закачке?

Запрашивать информацию о прямоугольнике, а при обработке полученных данных фильтровать по полигону.

[zed]

Запрашивать информацию о прямоугольнике, а при обработке полученных данных фильтровать по полигону.

Т.е. поставить топикстартера перед фактом, что вариант, который он запрашивает не реализуем Ок.

[vasketsov]

ИМХО возможное ускорение не оправдывает увеличения сложности реализации

Ускорение вообще под вопросом, потому что сразу же под вопросом становится попадание во внутренний кэш при микроизменениях полигона фильтрации, если тот полетит в тайлохранилище.

можно и не полигон, можно набор точек X,Y, которые следует проверить. Это не принципиально

Как раз это принципиально.
Нельзя просто так взять и получить SELECT ... FROM ... WHERE a in (a1,a2,...,aN), где N большое, обычно там где N приближается к 255 - уже не работает. И это даже не говоря об индексах, где between будет работать быстрее такого перечня значений. А про пространственные индексы (spatial), если их поддержка вдруг появится в тайлохранилище, можно сразу забыть.
Точнее, это принципиально для всех тайлохранилищ, где есть возможность группового чтения тайлов по условию, а не только по одному тайлику. Конечно там где доступ только по одному - key-value например без чтения по диапазону - там не принципиально.

И я не понимаю, почему RECT избыточен. По-моему, это как раз то что надо: позволяет быстро выполнить проверку по диапазону тайлов, если тайлохранилище это поддерживает. Если нет - ходим по одному тайлу внутри тайлохранилища, но достаточно избирательности, чтобы не обнюхивать весь экран в поисках тайлов.
Как вариант - пусть будет не RECT, а массив RECT-ов (в случае мультиполигона в него чтобы попадали границы каждого куска без учёта дырок, то есть между кусками карта строится, в дырках тоже строится). Зато по массиву RECT-ов по прежнему можно испускать SELECT ... WHERE ... between ... и ничего не просядет.
В принципе, это просто модификация метода для карты заполнения. Просто там всегда один RECT будет.
А то я вот почти уверен, что если карта заполнения по полигону будет нещадно тормозить и не будет хранимая, то пользоваться ей никто не будет.

вариант, который он запрашивает не реализуем Ок.

Ну мне вот допустим весьма очевидно, что либо вариант будет сильно тормозной, либо не то что хочет товарищ, либо только после того как карта заполнения будет хранимая.

[zed]

Нельзя просто так взять и получить

Зато можно выполнить несколько таких запросов, разбив массив на N частей. Или можно построить Rect по массиву, выполнить один запрос в СУБД и отфильтровать результат по массиву. Я не говорю, что всё надо решать "в лоб".

И есть мнение, что подавляющее большинство юзеров использует тайловый/Беркли кэш, а не СУБД. Соответственно, в большинстве случаев из хранилища выборка идёт по-тайловая и есть смысл в оптимизации запросов.

И я не понимаю, почему RECT избыточен.

Ну, объяснение на прошлой странице. По Rect мы проверяем наличие 16 тайлов, хотя нас интересует только 8. Двукратная избыточность в данном конкретном примере.

[vasketsov]

Зато можно выполнить несколько таких запросов

Можно. Но накладно.
Вот буквально сейчас полечил в одном проекте старт EXE-хи к оракловой базе. Вместо кучки запросов - один. Ничего больше не поменялось. Запуск стал не 2-3 минуты, а 5 секунд.

Или можно построить Rect по массиву, выполнить один запрос в СУБД и отфильтровать результат по массиву

Внезапно - это примерно то же, что предлагает Виктор, правда ВНЕ хранилища )))

И есть мнение, что подавляющее большинство юзеров использует тайловый/Беркли кэш, а не СУБД. Соответственно, в большинстве случаев из хранилища выборка идёт по-тайловая и есть смысл в оптимизации запросов

Во-первых, мы оба прекрасно понимаем, почему в основной ветке нет тайлохранилищ SQlite и фактически не используется СУБД. Наверняка это оттого, что файловый кэш офигенно быстрый, а бекрли меганадёжен и сломать его крайне сложно, и даже если он сломался, то никаких специальных процедур восстановления обычно не требуется. Ирония * Сарказм, если что.
Уж сколько я всю жизнь отработал с целым зоопарком СУБД и у меня нет проблемы админить любую поделку любых индусов - но всё больше люблю SQLite: база доступна под любой платформой, восстановление после сбоев автоматическое, бэкапы делаются из консоли обычным копированием файлов, быстрая карта заполнения одним запросом,... есть ровно одна проблема - доступ по сети, но я предполагаю её решать.
Во-вторых, построение карты заполнения по массиву RECT - уже достаточная оптимизация по сравнению с всеми тайлами на экране, см. текст тикета.
В-третьих, можно даже RECTы с дырками передавать, причём не обязательно сохранять связь, просто будет в случае SQL запрос вида WHERE (... between ... and ...) and (not (... between ... and ...)). Будет экономия и для файлового итератора (попали в дырку - пропуск) и для БД (экономия на io: не надо поднимать тайл и гнать его по сети).
Так что я предлагаю даунгрейдить функциональность ровно в том месте, которое не справляется: если тайлохранилище не поддерживает такие плюшки - путь и разворачивает как ему надо, пусть возможно кэширует наличие тайлов и сохраняет карту заполнения.

И я не понимаю, почему RECT избыточен.

Ну, объяснение на прошлой странице. По Rect мы проверяем наличие 16 тайлов, хотя нас интересует только 8. Двукратная избыточность в данном конкретном примере.

Не, это я понял. Я про избыточность в решении задачи.
Мне вот например не очевидно, что критерий оптимальности = минимизация суммарного количества тайлов, которое надо прочитать из тайлохранилища.
Причём это касается и оптимальности как минимизации времени работы, так и оптимальности в смысле реализации доработки и дальнейшей её поддержки, в том числе и для новых типов тайлохранилищ.

[zed]

Понял, возражений не имею. А Papazol теперь пускай сам решает, нужна ему эта фича, с такими условиями или нет.

[vasketsov]

Понял, возражений не имею

Блин. Если обидел чем - извиняй. Цели такой не было.
В любом случае все описанные проблемы с тобой никак не связаны.
Кто ж виноват, что беркли однопользовательский или SQLite по сети как клиент-сервер недостуепен?
Ты и так из беркли достаточно выжал, это лично моё мнение как разработчика. Тем более что им пользуются.

сам решает, нужна ему эта фича, с такими условиями или нет

Я подозреваю, что решать будет Виктор, что там будет. А заказчик просто смирится.
Уж больно серьёзная доработка. Причём в любом виде.

Не, существует конечно минимальная простейшая реализация:
а) признак "по всему экрану" или "по текущему выделению";
б) при построении карты заполнения туда залетает rect или от экрана или bounds от текущего выделения соответственно.
Ни тебе никаких специальных сохранений, ни изменений в интерфейсе тайлохранилища, ни в карте заполнения, лишь ОДНА галка в менюшке карты заполнения.

На втором месте по сложности - передавать массив rect-ов. Важно по сути лишь для сильно разнесённых в пространстве мультиполигонов (типа Россия < 180 и Россия >= -180). Но лично я не вижу особенных таких уж преимуществ ради одного применения в году городить массивы rect-ов.

А всё прочее - уже серьёзно.

Но что-то мне подсказывает, что даже при возможности по ПКМ быстро выделить текущее выделение по полигону, вряд ли это всех устроит.

[zed]

Блин. Если обидел чем - извиняй. Цели такой не было.

Да нет, с чего вдруг. Я же и сам за первый вариант, просто решил расставить все точки над i и обсудить все варианты.