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

[Papazol]

Когда-то были две похожие хотелки: http://www.sasgis.org/mantis/view.php?id=891 и http://www.sasgis.org/mantis/view.php?id=1030. Пора бы их реализовать. Скажу сразу, кэширование мне не требуется. Только построение карты для указанного полигона на указанном масштабе. Естественно, для указанной карты. Если к данной теме присоединится zOn, который хотел кэширования, то будем обсуждать.

[zed]

Скажу сразу, кэширование мне не требуется.

Т.е. речь о карте заполнения в текущем её виде, только применённой к полигону? Она будет перестраиваться точно так же, как и обычная карта заполнения: при смене зума/карты - полностью, а при движении карты - квадратами, размером в тайл на текущем зуме.

Возможны 2 варианта реализации:
1. относительно простой и быстрый, но фильтрация будет квадратами, а не тайлами
2. сложный, с предварительным рефакторингом интерфейса тайлохранилищ, но с по-тайловой фильтрацией

К примеру, для полигона как на скриншоте, и карты +1 (на скриншоте зелёные квадраты) получим:
0. Без фильтра. Допустим у нас на экране 50 тайлов текущего зума, при этом видно, что полигон пересекает 4 из них. Каждый тайл текущего зума, это 4 запроса в хранилище на наличие тайла на +1 зуме. Значит, без фильтра по полигину у нас получается 50*4=200 запросов.
1. С фильтром по первому варианту - тут мы рассматриваем только тайлы, которые полигон пересекает на текущем зуме, т.е. получаем 4*4=16 запросов.
2. С фильтром по второму варианту будет ровно столько запросов, сколько теоретичеки может быть тайлов внутри полигона на +1 зуме, а это всего 8 штук.

Image 1.jpg

И наверное нужно учитывать вопрос производительности - на сложных полигонах возможно будет тратиться много времени на определение попадает ли тайл в полигон и нужно ли ходить на диск за информацией о нём. Не думаю, что это будет медленнее, чем просто сходить на диск, но фильтр будет не бесплатный. Экономя ресурсы диска, мы будем нагружать процессор.

[vasketsov]

Поскольку всё равно в итоге такую карту заполнения надо будет кэшировать, а кэширование выполняется на том зуме, на котором она показывается, то есть на текущем, предлагаю делать простой вариант с определеним границ тайлов только на текущем зуме. Тогда при повторных обращениях можно будет поднимать её из кэша просто по наличию её для данного тайла. И не смотреть, а не сместился ли узел границы полигона на один тайл на зуме N+m и не надо ли полностью перестроить весь целый тайл в кэше из-за этого по новой части нижележащих тайлов.

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

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

[zed]

Лично я, тоже за первый вариант и даже готов его реализовать.

[Papazol]

Вообще-то мечталось как раз о втором (сложном) варианте, когда запрашиваться будут только тайлы, входящие в полигон. Это, конечно, в том случае, если карту заполнения строить каждый раз по-новой.
А ведь при загрузке выделенной области как раз запрашиваются только тайлы, входящие в полигон. Использовать это нельзя?

[zed]

Использовать это нельзя?

Можно, но будет не очень эффективно.

[vdemidov]

0. Без фильтра. Допустим у нас на экране 50 тайлов текущего зума, при этом видно, что полигон пересекает 4 из них. Каждый тайл текущего зума, это 4 запроса в хранилище на наличие тайла на +1 зуме. Значит, без фильтра по полигину у нас получается 50*4=200 запросов.

Маленькая поправка. К самому тайлохранилищу будет 50 запросов, а вот превратится ли каждый из этих запросов в 4 обращения к файлововй системе или останется 1 запрос к базе данных это уже дело исключительно конкретной реализации тайлохранилища.

PS: Я тоже за первый вариант реализации. Я только не знаю как оформить в ГУЕ выбор полигона для фильтрации. Как вариант включить фильтрацию по последнему выделению.

[zed]

Я тоже за первый вариант реализации.

А если делать по второму, то вводить в интерфейс тайлохранилища дополнительный спец-метод? Или модифицировать существующий ByRect, пропихнув туда полигон для фильтрации запросов?

Я только не знаю как оформить в ГУЕ выбор полигона для фильтрации.

ПКМ по полигону - построить карту заполнения. Если карта заполнения была ещё не включена, то она включится для текущего зума (+0) и карты, в противном случае будут использоваться уже выбранные параметры. Как-то так.
А внутрях завести Changeable интерфейс с полигоном, который будет слушать рисовалка карты заполнения и учитывать его при необходимости (ну или просто передавать в тайлохранилище - смотря на каком этапе делать фильтр).

[vasketsov]

Можно ничего не делать в тайлохранилище и ничего не вводить.
А просто передавать RECT не всего экрана, а только BOUNDs полигона (пути), вернее, пересечение с экраном (видимую часть).
И ничего не поменяется, просто карта будет строиться не по всему экрану.
В случае мультиполигона - будет строиться и вне его и в дырках.
В случае наклоненной полилинии - сильно вокруг неё.

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

[vdemidov]

А если делать по второму, то вводить в интерфейс тайлохранилища дополнительный спец-метод? Или модифицировать существующий ByRect, пропихнув туда полигон для фильтрации запросов?

Ну, я не очень в восторге от такого решения. ИМХО возможное ускорение не оправдывает увеличения сложности реализации и связности разных частей приложения.

ПКМ по полигону - построить карту заполнения. Если карта заполнения была ещё не включена, то она включится для текущего зума (+0) и карты, в противном случае будут использоваться уже выбранные параметры. Как-то так.
А внутрях завести Changeable интерфейс с полигоном, который будет слушать рисовалка карты заполнения и учитывать его при необходимости (ну или просто передавать в тайлохранилище - смотря на каком этапе делать фильтр).

Сразу возникнет желание что бы полигон сохранялся после перезапуска программы. Пихать его в ini не стоит (полигон может быть дофига каким большим) - то есть придется городить огород с аналогом LastSelection.hlg, c его асинхронным чтением/записью и тд.