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