SASGIS

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

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

Запрашиваем и выполняем хотелки к SAS.Планете вне очереди

Модераторы: vdemidov, Tolik

Правила форума
Настоятельно рекомендуем ознакомиться с правилами раздела платных услуг ТУТ.

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

Сообщение vdemidov » 02 июн 2015, 13:07

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

Именно. И я так же думаю.
Чтобы понять программу, вы должны стать одновременно и машиной, и программой.
Аватара пользователя
vdemidov
Гуру
 
Сообщения: 1687
Зарегистрирован: 12 дек 2008, 13:10
Откуда: Киев
Благодарил (а): 191 раз.
Поблагодарили: 136 раз.

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

Сообщение zed » 02 июн 2015, 13:12

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

Это и будет первый вариант, как я описал в самом начале. Rect будет несколько избыточен.
vasketsov писал(а):Какие полигоны? Какие координаты? Какие проекции?

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

Предложи другое? Ходить за каждым тайлом по-одному, как при закачке?
vdemidov писал(а):Сразу возникнет желание что бы полигон сохранялся после перезапуска программы.

В рамках данного тикета такого желания не возникает. Полигон будет "забываться" при отключении карты заполнения.
zed
Гуру
 
Сообщения: 2888
Зарегистрирован: 16 авг 2008, 20:21
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение vdemidov » 02 июн 2015, 13:17

zed писал(а):
vasketsov писал(а):Какие полигоны? Какие координаты? Какие проекции?

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

Не хотелось бы. Это сильно усложняет интерфейс и реализацию.
zed писал(а):
vdemidov писал(а):Ну, я не очень в восторге от такого решения

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

Запрашивать информацию о прямоугольнике, а при обработке полученных данных фильтровать по полигону.
Чтобы понять программу, вы должны стать одновременно и машиной, и программой.
Аватара пользователя
vdemidov
Гуру
 
Сообщения: 1687
Зарегистрирован: 12 дек 2008, 13:10
Откуда: Киев
Благодарил (а): 191 раз.
Поблагодарили: 136 раз.

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

Сообщение zed » 02 июн 2015, 13:23

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

Т.е. поставить топикстартера перед фактом, что вариант, который он запрашивает не реализуем :) Ок.
zed
Гуру
 
Сообщения: 2888
Зарегистрирован: 16 авг 2008, 20:21
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение vasketsov » 02 июн 2015, 13:33

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

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

zed писал(а):можно и не полигон, можно набор точек 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 писал(а):вариант, который он запрашивает не реализуем :) Ок.

Ну мне вот допустим весьма очевидно, что либо вариант будет сильно тормозной, либо не то что хочет товарищ, либо только после того как карта заполнения будет хранимая.
vasketsov
Специалист
 
Сообщения: 901
Зарегистрирован: 25 июл 2009, 21:15
Благодарил (а): 0 раз.
Поблагодарили: 193 раз.

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

Сообщение zed » 02 июн 2015, 14:48

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

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

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

Ну, объяснение на прошлой странице. По Rect мы проверяем наличие 16 тайлов, хотя нас интересует только 8. Двукратная избыточность в данном конкретном примере.
zed
Гуру
 
Сообщения: 2888
Зарегистрирован: 16 авг 2008, 20:21
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение vasketsov » 02 июн 2015, 15:24

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

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

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

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

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

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

zed писал(а):
vasketsov писал(а):И я не понимаю, почему RECT избыточен.

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

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

За это сообщение автора vasketsov поблагодарил:
vdemidov (02 июн 2015, 15:43)
Рейтинг: 5.26%
 
vasketsov
Специалист
 
Сообщения: 901
Зарегистрирован: 25 июл 2009, 21:15
Благодарил (а): 0 раз.
Поблагодарили: 193 раз.

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

Сообщение zed » 02 июн 2015, 15:54

Понял, возражений не имею. А Papazol теперь пускай сам решает, нужна ему эта фича, с такими условиями или нет.
zed
Гуру
 
Сообщения: 2888
Зарегистрирован: 16 авг 2008, 20:21
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

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

Сообщение vasketsov » 02 июн 2015, 16:23

zed писал(а):Понял, возражений не имею

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

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

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

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

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

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

Но что-то мне подсказывает, что даже при возможности по ПКМ быстро выделить текущее выделение по полигону, вряд ли это всех устроит.
Последний раз редактировалось vasketsov 02 июн 2015, 16:28, всего редактировалось 1 раз.
vasketsov
Специалист
 
Сообщения: 901
Зарегистрирован: 25 июл 2009, 21:15
Благодарил (а): 0 раз.
Поблагодарили: 193 раз.

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

Сообщение zed » 02 июн 2015, 16:26

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

Да нет, с чего вдруг. Я же и сам за первый вариант, просто решил расставить все точки над i и обсудить все варианты.
zed
Гуру
 
Сообщения: 2888
Зарегистрирован: 16 авг 2008, 20:21
Благодарил (а): 89 раз.
Поблагодарили: 525 раз.

Пред.След.

Вернуться в Внеочередное исполнение хотелок

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0